My recommendations for a perfect engineer-ication
My recommendations for a perfect engineer-ication
The 9 most important ingredients to make the most out of this experience
In my previous post I've told the story of my first Engineer-ication, and the reasons why I recommend anyone in an engineering leadership position to do the same. If you don't know what an Engineer-ication and why it might be relevant to you, I recommend you start by reading the first article.
In this second post I'd like to share some recommendations to get the best out of that experience, in case you decided to try it out.
These are based on my own observation, and might or might not apply depending on your specific situation. As usual, YMMV, and this is definitely not financial advice 🙂
So let's go with the list of recommendation that I could have advertised with a clickbait-y title such as “The 10 most important ingredients for a perfect Engineer-ication”.
Too bad I ended up with only 9 of them, such a missed opportunity!
Ingredient 1: Pick a context that will minimise disruption for the rest of the team
Keep in mind that, unless you're already very familiar with the codebase, you will be asking questions and will require support from the rest of the team as if you were a new joiner. You do have knowledge of the business and the organisation, but you're likely new to the systems and processes of this specific team.
How is code deployed to production? How are code reviews organised? Who is the expert on system X or Y?
You likely lack answers to many such questions.
The net effect of you joining the team for a week is likely to be negative, i.e. you'll consume more time from the team members than the time you'll save them by completing your assigned tasks.
When a new person joins the team permanently, this initial investment as will be paid back with interests once the new member becomes proficient and autonomous. In your case this doesn't apply. The benefit for the team, all your team, will be much more indirect in the form of the improvements in processes and systems you'll drive as a consequence of your discoveries. From the team's perspective, you will be gone after one week, and with you all the investment made to train you on the code base.
These are all good reasons to make sure you minimise the amount of disruption for the team. You should obviously not leave behind any unfinished work, but that's just the bare minimum.
Consider also the following aspects when picking the team that is most likely to handle your presence with minimum side effects.
Which part of your business are you more familiar with? You might want to prioritise teams working in those areas as to limit the amount of context and business domain related questions you will need to ask
What's your technical background? If you're coming from the backend / infra / architecture world, you might not want to join a team that is building a frontend heavy application that relies on external APIs and Services. This is not a coding bootcamp or a hackathon, pick an area where you can be productive.
Prefer more mature teams over more fragile ones. All teams are different, both due to the individuals in it as well as their maturity as a whole team. I do recommend you pick a team that has a good combination of seniority, as these engineers are used to train and onboard new members into the team, and mature processes overall. Definitely avoid a newly formed team that is going through a storming phase.
If you feel there is a potential risk of confusion on who calls the shots between you and the actual leadership of the team, make it very explicit that you're joining as an Individual Contributor, and refrain from engaging in discussions where big technical decisions are made. Some people might take your opinion as a direction given to the team. If you are faced a situation that requires your intervention as a leader, make it very explicit you're stepping out of your temporary role. Try to avoid those interventions as much as possible.
Share visibility on your calendar with the team in case you have engagements you were not able to postpone or cancel. This will help setting clear expectations on your availability, and avoid people waiting for you on something urgent while you're on a 2 hours staff meeting.
Ingredient 2: Take a long enough “vacation”, but not too long
You want to spend enough time with the team and have a variety of tasks to deal with to maximise your exposure to the underlying systems. At the same time, you can't leave your current job unattended for a month and expect that to be fine.
You might be tempted to just commit for a couple of days, as that's easier to fit into an already busy schedule. If you go with that approach, there is a risk that you will barely finish one task and you'll not have a chance to observe a full development cycle within the team. It could end up feeling just a waste of time.
My recommendation here is to take a full week, Monday to Friday, as this will give you enough time to read up on documentation, ask questions, try things out, and make sure you follow the team's coding standards without feeling you have to rush things.
It will also give you a chance to interact with the team in some of their common ceremonies such as planning sessions, stand-ups, etc.
Ingredient 3: Test your onboarding process
This is a great opportunity to observe first hand how effective your onboarding process is. Make sure you follow the standard onboarding process that any new engineer in the team goes through, rather than requesting any special treatment. Just skip the parts that you're already familiar with.
What is very important though is that you go through all the material that your new team has developed over time for introducing engineers to the team dynamics and its codebase.
If you spot inconsistencies or gaps in the documentation, this is an opportunity for you to contribute and make the process better by amending the documentation. If you find something that can be improved in the overall process or experience, make sure you share your thoughts with the team's manager at the end of your week.
Generally speaking, if your onboarding was not successful, you will want to spend time with the engineering manager of the team to make sure the issue is addressed, the process is improved, and future new joiners have a better experience than yours.
Ingredient 4: Give up your manager's schedule, embrace the maker's schedule
As managers we have the need to context switch regularly due to the amount of topics that require our attention, including both planned work and unexpected events or requests.
In a single day you might spend one hour on long term strategic discussions, two hours in total for 1to1 meetings, half an hour to an hour reviewing documents that require your input, a similar amount of time producing document, and then a long list of short interactions through email or slack.
When you engage in an engineer-ication you might struggle to keep focus at the beginning. You might be tempted to check your emails and slack messages out of FOMO or just habit. If you indulge in too many context switches during this experience there is a high chance you'll not really get a lot of benefit out of it.
You want to really focus on the tasks at hand as you'd like other people in the team to do. As such, make sure you plan long stretches of focused time during the day. Tell yourself that the rest of the organisation believes you're on holidays, and that if something really urgent is happening someone will find a way to get your attention via a phone call or other means.
Try to limit your usage of internal communication tools to the channels relevant for your team, and allow yourself to ignore all those white bold channels staring you all day. As you will see in Ingredient 7, you'll find a way to deal with them that don't get in the way of your coding experience.
This is also a good opportunity to make sure the engineer's schedule in the team is not full of meetings interrupting the coding flow. If that's not the case, you will have something more to review with the team's manager.
Ingredient 5: Participate to all team's rituals
The main goal of an engineer-ication is for you to observe and collect data about your organisation, systems and processes.
Team meetings tend to have a very high signal-to-noise ratio in terms of insights on team dynamics and performance.
Be mindful that your presence itself might change the dynamics of these meetings, and you should actively - or rather passively - try to minimise that risk.
Resist the temptation of trying to lead conversations or provide strong opinions. Limit yourself to a listener role. If you need to report on your progress, do so like any other member of the team.
Keep in mind one bad planning session might not be an indicator that there are profound issues in the team, it might just be an exception caused by special circumstances, including your own precence.
The recommendation here is to collect your observations in all the interactions you'll be witnessing, and share them with the manager at the end of your engagement period.
Ingredient 6: Don't be afraid to look incompetent
This is probably my favourite.
As leaders we often preach to our team the importance of recognising how much we don't know. We often repeat them that the best way to learn is to start by acknowledging your gaps and then ask a lot of question.
We also know that one great way to build trust is to show vulnerability and honesty.
Take this as an opportunity to role model good behaviours in tour team. Show that you are not afraid of asking questions that will expose your lack of knowledge on certain technologies, patterns or even the internal lingo of the team.
Just make sure you do a bit of homework before dropping questions that can be easily answered either through the internal documentation or public sources, as that will perceived as a lack of respect for other people's time. Do your own research, but if you can't find the answer, just ask.
In some cases you might be surprised to discover that other members of the team had the same questions but just never dared to ask them.
Ingredient 7: Schedule an end-of-day catch up slot
In Ingredient 4 I recommended you to follow the maker's schedule and give up your manager's schedule. That can be a source of anxiety and unwanted side effects on people that might require your attention.
There is one simple trick to deal with it in a way that gives you piece of mind and provides people with timely reactions: schedule a 30 to 45 minutes slot at the end of your day to play catch up with all the messages waiting for your attention.
This way you can limit the context switch from engineer to manager to once a day. Batching and time boxing the catchup will also make your more efficient and productive.
Try to avoid doing this at the beginning of your day. The temptation might be there to just check one or two messages before going into focus mode, but it takes only one ‘bad news’ to keep your brain distracted for the rest of the day, undermining your productivity.
If that has to happen for whatever reason, I suggest you deal with the matter at hands as soon as possible so that you can then take it off your mind and be fully present in your coding sessions afterwards.
Ingredient 8: Write your impressions down
You will need your working memory and your short term memory fully available to deal with the coding tasks, as such there is a high risk that you will forget most of your observations, impressions and ideas by the end of the week if you don't capture them somewhere.
I recommend to keep a simple journal page that you add to every day in an unedited way, in the form of quick notes and impressions.
It's convenient to review your notes at the end of each day, before or after your “catch up slot”, and edit the content to add more details, overall reflections, and overall enrich the material you've been collecting.
At the end of the week you should have 5 days worth of notes.
In the days following your engineer-ication, I recommend you to reprocess all these notes, and produce a document summarising your findings, with highlights and lowlights. It's a good idea to share the document with the whole organisation to make them aware of your findings and recommendations.
Ingredient 9: Follow-up on your findings
There is value in an engineer-ication even if it doesn't lead you to identify any major improvements required in your organisation: knowledge. You'll learn so much about the reality on the ground that you'll be in a much better position to make decisions and help unblock teams going forward.
In most situations though you will find clear opportunities for improvement, which you will have captured in the write up you shared with the organisation.
Make sure you don't leave it up to good will for these recommendations to be turned into actions and then executed. Make sure you follow up with the relevant managers to make sure they're actively looking for capacity in the team to execute on them. That, or they might have come up with very good reasons not to follow your recommendations, in which case you'll want to be informed.
Conclusions, and share your 10th ingredient!
These are my 9 recommendations if you wanted to try out the experience of an engineer-ication with one of your teams.
They are based on my own experience, and I'd be very curious to hear about yours. Did you find these 9 ingredients apply to your case as well? Is there something you'd like to add?
I'd love to hear about your secret 10th ingredient in the comments section!