Onboarding and Mentoring: or how to refine raw talent into a loyal professional and a monster contributor.
It’s happened to all of us. At some point in our career, we’ve started a new job, excited about the seemingly boundless possibilities, maybe eager to get a fresh start. Looking forward to that first week, I think we universally hope for at least two things: 1) time and attention from some of our colleagues, to help us understand and adjust to our new work environment, and 2) patience from our manager as we get up to speed, until we can contribute at a significant level. And, wouldn’t that be great?
But what actually happens? Even at places with good intentions (my experience tells me that even that low bar is not usually met), but especially at places without, the most common experience for new software engineers is pretty much the same industry-wide: sink or swim. On your own. I personally see this is a barbaric practice, on the order of a frat-boy hazing ritual, certainly not appropriate or effective in a professional context. (Yes, I can see the value of it in certain circumstances, with certain people, but I’m not here to argue that point…and for the sake of staying focused, let’s agree at there are better methods than sink of swim, and let’s agree to discuss the various advantages & disadvantages of other methods, and our experience with them)
I want to focus on how we can do this better, and specifically what I am doing to make this better. I’d love to hear from all of you about how you do things. On a personal note, this topic is extremely relevant to me right now, as I am currently building the engineering organization for Awesome Games studio at ngmoco:) (We Rule is my studio’s flagship title). Recent organizational restructuring has created a void of engineers to work on my projects, so the major focus of my job right now is to successfully create and execute a strategy that brings engineers onto the team, gets them up to speed as quickly as possible, and then supports them contributing at a high level consistently and sustainably. The current job market has made it difficult for me to even find any senior engineers, much less hire them, so I am planning my program around the assumption that I will be hiring relatively junior engineers
I’ll be the first to admit, I’ve never done this before at quite this level of magnitude. Compared to all hiring and employee development I’ve done previously, it has never been so urgent, so important to the business, and so undeveloped. I’m basically starting from scratch, and the whole studio is relying on me. Hey, what more of an opportunity could I ask for? =)
So, here is what I’ve got:
Hiring – It all starts here. Only certain people will ever onboard well, and you have to choose who will work for you and your team. I focus on people who are open and flexible to learning a lot, learning quickly, and who have the right attitude towards working with new systems. ”Excellent Generalists” is our mantra. Another way of saying it: I look to hire people who have the potential to be productive in any area, and have the attitude of being eager and willing to do absolutely anything that needs to get done. No ego. Nothing should be too low or too intimidating of a task for you. No matter what the context, dive in, be resourceful, and do whatever it takes to get things done.
Hiring is obviously big enough to be its own post topic, so I won’t linger here. The point I want to make is that your onboarding will fail if it is not aligned with your hiring practices. Hire the people who are best for you, even when that means turning down amazing programmers because they aren’t flexible, or don’t play well with others, or for any other reason just don’t fit with your culture. I know it’s painful to turn down excellent technical competency, but it’s nowhere near as painful as hiring overwhelming personality jackassery. I’ve seen otherwise top-notch fabulous companies ripped to shreds and completely fail, because their engineering hiring decision makers were unable to say no to a good coder, regardless of the collateral damage.
Onboarding – This is the step most engineering teams delegate to HR, or solve with a lightweight solution that often looks something like a link to an outdated wiki page, and maybe an assigned “buddy,” who is often just as clueless as you are. I understand why: coming up with any material, much less good material, i a lot of upfront investment, and often in startups you just don’t have that luxury. Still, not even making an effort is unacceptable, and as professionals who are proud of what we do, we should hold ourselves to a higher standard. I’m starting with me.
Here are the practices I’ve started with, the steps I’ve taken so far, and the material that has been generated:
My first project is to create a New Engineer Handbook that I can hand (or email) to new engineers on their first day in my studio.
To begin, I went into a room with a big whiteboard and my team, with the goal of articulating the whole of our work context. Basically, defining the scope of what we do, and the major pieces, so that someone new could easily get an accurate sense of what we do, and what we do not do. The format we ended up with was 3 lists of topics, which forms a great outline for the handbook, and also acts as the raw material for the program discussed below.
The three lists are a Skills/Technology list, Application Domain Knowledge list, and Engineering Landscape & Workflows list. I will discuss each in turn below, including how I use the material in each.
1. Create a Skills List. Come up with a comprehensive list of all of the single-line-item technologies, skills, systems, languages, concepts, etc that are a part of your project’s technology stack or your daily engineering workflows, and any other related areas. I did this as a free-form whiteboard brainstorm, and then sorted the list into general categories: Client/Server, etc. Our list looked something like this, edited for length and privacy.
Skills/Technologies -- General: git/svn Server: ruby/rails mysql bash/sh passenger capistrano memcached json Client: xcode/ib objective-c opengl/cocos2d
These are all technologies that we interact with on a daily basis, and I expect everyone on my team to know what these systems are, and have at least a basic understanding of how they work, and how to interact with them. I use this list as a general baseline, from which I generate a personalized learning program for each new engineer who joins my team. The process I use goes something like this:
Personalized Skills/Technology learning program
a. During our first or second 1-1, we look over the list of technologies and skills, and create a new checklist that just includes the items that the engineer needs to spend some time researching/practicing/learning.
b. From that checklist, I work with the engineer to create a schedule that maps each checklist item to a specific day, so the learning time is very structured. I think this is the key step to making this program effective, because it provides goals to aspire to, a clearly structured plan to achieve the goals, and measurable progress at each step, which allows both the engineer and the lead to track progress with precision.
c. On each day that a skill or technology is “due,” the engineer shows me something tangible that they have produced during their learning process. It may be a small demo, it may be some sample code, it may just be them walking me through some application code and explaining what it does, if they were working to understand how that system worked for example. This step adds an element of accountability that is absolutely necessary, and forces the engineer to prove that they have mastered the skill they were working on, which is an incredibly strong motivator during the learning process.
2. Application Knowledge List. This list contains an enumeration of systems at the application abstraction level, one conceptual level deeper than the skills/technologies list. It could very well include features, especially core features, data models, etc., as well as design and infrastructure systems on the example list below. This is the kind of information that ideally exists in technical design documents and other such things, but in the real world would typically be hidden away in the deep dark corners of the application architects and designers and any senior engineer who has been working on the project for a long time. The goal here is to make explicit all the topics that tend to become implicit once you’ve been working on a project for a long time. Again, using my own project as an example, this an edited part of the list we came up with for We Rule:
We Rule Application Domain -- We Rule Configuration System Client/Server API New DLC Content Patching System CDN Analytics We Rule Database Schema (Data Model)
This is all knowledge that must be learned after joining a team, no matter what your level of experience is, and usually it is best learned via dialogue with senior team members. For these types of topics, my personal believe is that it is of minimal importance to attempt to document each item in depth, since typically they are fluid and dynamic, and the amount of effort to produce comprehensive documentation is too expensive in terms of opportunity cost. However, I do believe it is immensely valuable to have a clearly enumerated list of all of the most important topic areas, so that the scope of the application specific knowledge is something everyone has access to. Also, and maybe more importantly, it gives new people an initial mental framework within which to organize all of the information they will be inundated with during their onboarding.
This provides two major benefits: 1) the new engineer starts off immediately using the same shared framework that everyone does, providing enough context to jump right into teamwork immediately. 2) the new engineer is able to more quickly and easily create meaning out of raw information, and for that meaning to match up with how everyone else understands things.
The handbook material generated by this list is twofold: 1) some amount of written documentation on some of the topics where appropriate, as our senior engineers have time to do that documentation work. 2) a calendar of meetings & discussions about each topic, as the new engineer needs to know a particular feature more in-depth to accomplish their work. Sometimes we preemptively schedule a list of topics, sometimes we leave them to be scheduled on-demand, depending on the person and their particular role & responsibilities.
Most information a new engineer hears during the first couple weeks often is completely wasted, because there is no framework within which to organize the discrete facts. This is my attempt to remedy that problem in the most lightweight way I could think of.
3. Engineering Landscape & Workflows. This contains all of the basics about day to day life being an engineer in Awesome Games studio. A large amount of this is written down and documented well on our wiki (this is the rare kind of info that I believe actually works well living on wikis), and anything that is not already there, is being added. This is work that I split up across everyone on the team; we all chose a couple topics to write up. In terms of going through this material, I will sit down with new engineers on my team, and walk through most of this info during their first or second day, and then point them at the rest of it for them to look up as they need it. The example list from my studio for We Rule looked something like this:
Engineering Workflows/Landscape: -- servers: list of them, what is on each, what do we use each of them for, how can you access them logs, which ones to we use, where do you find them how to push code to servers how to start a server, how to restart how does the patching workflow work, who does it dlc workflow content pipeline (what is it, who does it, how to run it, how to make changes how we work with QA, bugs builds (where, who, what info) release plan (what is a full project schedule, what do the different milestones mean) what is the submissions process task tracking code reviews design process (feature design -> tech design -> implementation) post-mortems
Most professional software engineers will understand most of this intuitively, so it doesn’t take a lot of effort to go over it quickly. Where I have found this to be really valuable, is when working with entry-level engineers. Hiring entry-level engineers is not something that most start-ups do, but as an engineering lead/manager/director, if you are able to take entry-level recruits, and turn them into monster contributors…you are creating value for both your team & company, but also for our profession as a whole. It’s a rare and valuable skill. Someone has to train the next army of what recruiters love to call ^Rockstars^ (yes, ironic carets); why not let it be you?
One Last Technique…. I realize the bulk of this post (which is now really long and I admire your focus if you are still reading) is all about the techniques vis-a-vis my New Engineer Employee Handbook concept. That’s cool, but I can’t discuss onboarding without discussing the single most effective practice you can implement to ensure a successful new employee transition, and an easy technique to implement at that. Pair Programming.
Pair Programming – I realize pairing is a bit of a divisive topic, though I think much more less so than it has been in the past. Regardless of your personal preference, or your religious or philosophical tendencies, there is no more thorough or effective way to integrate a new person into an existing team, project, and codebase, than by having the new engineer spend time pair programming with the old engineers. You get general knowledge transfer, workflow habits, personal interaction with people from other areas, code design knowledge, system design knowledge, so many great technical things, and it happens faster than via any other method. By pairing, senior engineers are able to pass on all of the application-specific idiomatic expressions and ways of doing things, so that new engineers can better understand the systems, why things are done in the particularly arbitrary-looking way that they are, and so the new engineers will pick up the existing idioms and continue them, maintaining continuity and keeping things consistent.
Additionally, by pairing, the new engineer will spend a lot of hours working very closely with everyone on the team, allowing very easily for personal connections to be made, and for trust to begin to be established. I can’t state how important it is for new engineers to feel like they are an important part of the team, and developing strong social fabric early on should be a top priority. Pairing does that.
Mentoring Mentality – I’ll just mention this briefly here, and maybe post about it separately in the future. I believe strongly in mentoring, I think everyone should have a mentor, and everyone with enough experience to do so should be a mentor to someone else. It’s both a great way to grow, and a great way to give back, in both directions. As it applies to a game studio, I mentor some of the engineers in my studio directly, and I ask senior engineers in the studio to mentor other junior engineers. All in all, I expect everyone in the studio to be involved in the mentoring process, hopefully on both the giving and receiving ends. As I discussed this with my Executive Producer, and talked about how I was thinking about mentoring and wanting to implement mentoring practices, she coined the term Mentoring Mentality, and I like it. So, in my studio, I do cultivate a mentoring mentality…I talk about it with my team, they talk about it with each other, we all work on being better role models and learning and growing, and it has already had a really positive effect on the team culture. It’s something my senior engineers will take with them to other teams inside the company, and spread our best practices.
In closing…I thank you for your time to read all of this, and I hope you found something valuable. I want to exhort you, whatever your current position, to take action and contribute to the new engineer experience at your own company. I encourage you to experiment with different things, and find what works best for you and your team. Any engineer can implement and execute almost all of the things that I discuss in this post, most of it is all about writing down broad context information, and being explicit in your communication with new people. You don’t need to be a manager or a team lead, you just need to step up and set an example.
I am currently in the middle of creating this onboarding program for my studio; some of these things I have done, some of them I am looking forward to doing. How well does it work? So far, it has gone very well; I’ve been testing out my ideas and practices on an engineer who recently transferred onto my team from one of the other teams inside of ngmoco. But the real test, my very first external hire for Awesome Games engineering, starts tomorrow…so stay tuned, let me know your feedback & ideas in the post replies/comments, and I’ll let you know how things go. =)
Thanks
Ryan