4 ms·

Here's my usual playbook for onboarding engineers: Start by giving the person a high level overview of your systems and them let them go setup "company things"

by vasco 6y ago

Here's my usual playbook for onboarding engineers: Start by giving the person a high level overview of your systems and them let them go setup "company things" for the rest of the day. This gives the brain a rest from the technical stuff with menial work. The next day, and throughout the first week, give them deeper dives into individual systems. Every time you do this start from the overview again, so they're reminded. Always keep it a conversation, go back to different parts when the engineer asks questions that show they haven't understood something you've gone over before. This is normal as you're unloading a lot of knowledge you've built over time. Make sure you keep focused on the mission of sharing knowledge and do not let yourself get lost into too many side chats about how your pet peeves are never prioritised to be fixed and how you hate technical debt - this is not the time. Once they've setup their company emails and whatever your HR demands, start by giving them a simple task and leave them on their own with the expectation that they will reach out once blocked. Check if they're blocked yourself multiple times during the day. A new dev might be reluctant to reach out for fear of being perceived as too junior. Let them know this is not a concern, the concern is to ramp them up as soon as possible and questions are the best way to do it. Remember to ask them about the pace, how they're feeling, what they're struggling with or if they're eager for more. Some people will prefer a few more days reading docs, others prefer to jump in to the work straight away. I've seen both approaches work and try to adjust myself to the way the person likes to work best. Increasingly give them more complex tasks, have them pair with other engineers. Remember that not only you're onboarding them on the systems, you're onboarding them to the people. Make sure their work is throughly reviewed, take your time to explain why things are done in certain ways, take all oportunities to give further back context. As time goes on, apply a similar playbook to give them extra duties, complex issues to solve, more permissions, etc. PS: Grove's book is great, definitely recommend it

taphangum 6y ago
This is fantastic.
deleted 6y ago
[deleted]
miguendes 6y ago
That's an awesome approach! I wish all tech companies followed this or similar approach. The faster you get a new member on-board the faster they'll start creating value.
yomly 6y ago
This is an extremely concise clear set of instructions of how to give instructions to a newcomer. It's extremely well written - thank you! If this is reflective of your actual on the ground onboarding then your team members are lucky to work with you It's worth pointing out that most of the advice is simple and hopefully self evident. Which is in itself a good thing - as we say about code KISS
ozim 6y ago
This answer is sound but for different question. I think original question is "How do you make devs grow when they are already couple years in the organisation?". On-boarding is quite easy because you know what to teach to a person. It is obvious that person does not know your system and is willing to learn about it, because they are starting new job. What to do with people who know your system in and out? How to get to know what they would be interested in learning? What would be thing they can learn so it aligns with company goals? How to teach a group of 10 devs without burning whole budget on useless stuff?
- scarface74 6y ago
  For technical subjects just give me a reimbursement for training materials - Udemy, PluralSight, O’Reilly, etc. Sometimes it can be as simple as having lunch and learns. For awhile it seemed like every company I went to wanted to have one on Domain Driven Design. Let employees do proof of concept work with new to the company technology and then do a deep dive presentation. But personally, I don’t like to be “taught”. I prefer to learn on my own.
  - nitrogen 6y ago
    But personally, I don’t like to be “taught”. I prefer to learn on my own. I had this view for a long time, and it seems common among engineers I've worked with and mentored. It's such a common view that I was advised never to use the word "teach" or "training" and instead say "knowledge share". And to some extent it is impossible to teach what can only be learned by doing. But more and more I feel like the self-teaching learning curve is an S curve and we all approach diminishing returns. I suspect that in the right group of self- and mutually-motivated, highly talented people (not just engineers), one could level up significantly faster through coaching and interaction than through self study alone, no matter how much of an autodidact one is.
    - scarface74 6y ago
      My favorite way to learn is iterative. 1. Proof of concept 1 or 2 people depending on the scope 2. Get Feedback 3. Iterate 4. Get Feedback 5. Is there consensus (either agreement or “disagree and commit”) to move forward? If no, go back to step 3. 6. Document process and best practices in the Wiki along with a model implementation. Of course this also goes through a continuous improvement process. At the end of the day, results beat theory. This is how we introduced most of our “cloud native” initiatives, security, logging, monitoring, a better configuration process, a CI/CD pipeline,Lambda, Fargate (serverless Docker), moved toward a more performant data store for OLAP processes (Redshift) etc. There was just way too much theory and nothing to show for it before I and one other “architect” on another team basically pushed the issue with the backing of our then new CTO. We started to get a number of other people onboard. Amazingly enough, despite the stereotypes, our off shore contractors (who had been at the company for years before they started adding on developers in the US), were more aggressive about changing the status quo and doing things “the right way” when they had cover from us than the newly hired team leads right across the room. When you have too many people trying to learn at the same time, some learn at a slower pace, some have different interest (I won’t go near the clusterf%%% of modern frontend development) and some don’t want to learn at all and just want to coast.
pbhjpbhj 6y ago
I agree with thorough review. As I've been initiated recently into a new company I've felt it's a great time to get a deep review - potentially from an expert - of ingrained/embedded systems. In theory you have someone, you deem as competent, taking a fresh view of all your systems to a deep level. Things that seem wrong might be because they are wrong - people learning will be inclined to think they are the problem. Thorough review might reveal systemic faults.
NalNezumi 6y ago
I know this is a 8 day old comment but I just wanted to say it is fantastic. I've had the unfortunate situation of graduating and only ending up in workplace that treat the new guy with content only. But after managing myself I'm in a position where a new guy start soon and I'll definitely keep this in mind when I interact with him!

by vasco 6y ago

taphangum 6y ago

This is fantastic.

deleted 6y ago

[deleted]

miguendes 6y ago

That's an awesome approach! I wish all tech companies followed this or similar approach. The faster you get a new member on-board the faster they'll start creating value.

yomly 6y ago

This is an extremely concise clear set of instructions of how to give instructions to a newcomer. It's extremely well written - thank you! If this is reflective of your actual on the ground onboarding then your team members are lucky to work with you It's worth pointing out that most of the advice is simple and hopefully self evident. Which is in itself a good thing - as we say about code KISS

ozim 6y ago

This answer is sound but for different question. I think original question is "How do you make devs grow when they are already couple years in the organisation?". On-boarding is quite easy because you know what to teach to a person. It is obvious that person does not know your system and is willing to learn about it, because they are starting new job. What to do with people who know your system in and out? How to get to know what they would be interested in learning? What would be thing they can learn so it aligns with company goals? How to teach a group of 10 devs without burning whole budget on useless stuff?

scarface74 6y ago
For technical subjects just give me a reimbursement for training materials - Udemy, PluralSight, O’Reilly, etc. Sometimes it can be as simple as having lunch and learns. For awhile it seemed like every company I went to wanted to have one on Domain Driven Design. Let employees do proof of concept work with new to the company technology and then do a deep dive presentation. But personally, I don’t like to be “taught”. I prefer to learn on my own.
- nitrogen 6y ago
  But personally, I don’t like to be “taught”. I prefer to learn on my own. I had this view for a long time, and it seems common among engineers I've worked with and mentored. It's such a common view that I was advised never to use the word "teach" or "training" and instead say "knowledge share". And to some extent it is impossible to teach what can only be learned by doing. But more and more I feel like the self-teaching learning curve is an S curve and we all approach diminishing returns. I suspect that in the right group of self- and mutually-motivated, highly talented people (not just engineers), one could level up significantly faster through coaching and interaction than through self study alone, no matter how much of an autodidact one is.
  - scarface74 6y ago
    My favorite way to learn is iterative. 1. Proof of concept 1 or 2 people depending on the scope 2. Get Feedback 3. Iterate 4. Get Feedback 5. Is there consensus (either agreement or “disagree and commit”) to move forward? If no, go back to step 3. 6. Document process and best practices in the Wiki along with a model implementation. Of course this also goes through a continuous improvement process. At the end of the day, results beat theory. This is how we introduced most of our “cloud native” initiatives, security, logging, monitoring, a better configuration process, a CI/CD pipeline,Lambda, Fargate (serverless Docker), moved toward a more performant data store for OLAP processes (Redshift) etc. There was just way too much theory and nothing to show for it before I and one other “architect” on another team basically pushed the issue with the backing of our then new CTO. We started to get a number of other people onboard. Amazingly enough, despite the stereotypes, our off shore contractors (who had been at the company for years before they started adding on developers in the US), were more aggressive about changing the status quo and doing things “the right way” when they had cover from us than the newly hired team leads right across the room. When you have too many people trying to learn at the same time, some learn at a slower pace, some have different interest (I won’t go near the clusterf%%% of modern frontend development) and some don’t want to learn at all and just want to coast.

pbhjpbhj 6y ago

I agree with thorough review. As I've been initiated recently into a new company I've felt it's a great time to get a deep review - potentially from an expert - of ingrained/embedded systems. In theory you have someone, you deem as competent, taking a fresh view of all your systems to a deep level. Things that seem wrong might be because they are wrong - people learning will be inclined to think they are the problem. Thorough review might reveal systemic faults.

NalNezumi 6y ago

I know this is a 8 day old comment but I just wanted to say it is fantastic. I've had the unfortunate situation of graduating and only ending up in workplace that treat the new guy with content only. But after managing myself I'm in a position where a new guy start soon and I'll definitely keep this in mind when I interact with him!