top of page
  • Tom Bellinson

Coming Up to Speed - Part 2: Technical Skills


In the eight-part series I started yesterday, we explored the many aspects of onboarding new team members. As discussed, high-tech turnover rates will unlikely come down anytime soon. So, let’s get good at bringing new team members up to speed.


Most companies eliminate resumes that don’t pass the technical skills hurdle in the first round. Technical skills are more teachable than intellectual and emotional intelligence. Great agile companies might get real bargains if they focus on those attributes.


It’s highly likely that no matter how great the match, new team members will need to learn a raft of technical skills. The most common approach is osmosis. You pair them up with a more tenured team member, and they absorb as they go, fumbling until they “figure it out.” Intelligent people (who, as mentioned, should be highly prized) will “figure it out” quickly. It is a weak strategy to rely on this.


The better strategy is to have excellent documentation and a well-defined process. Agile teams often poo-poo well-defined processes as being an anti-pattern. Where did that come from? I suspect it is from a misreading of the Agile Manifesto. The word “over” emphasizes the relative priority between people interacting and predefined practice, suggesting that good processes emphasize interaction. This situation is no exception.

Great Documentation

A great practice I learned while at ITHAKA was writing instructions for setting up a new developer laptop. All developers need to go through this process. Load an image or have someone else do it. The setup process teaches the developer about their working environment. Each carpenter assembles their tool belt. The tools, like developer laptops, might be the same, but the specific arrangement will differ.


As the new developer went through the instructions, if there was an error, they were tasked with correcting it. In this way, the documentation became better over time. Other developers were always available to assist should the new person get stuck.


Developers need to have a hierarchy of knowledge. Until we can spontaneously download knowledge into their heads, we must find a way to get it in there systematically. Here’s an order of knowledge we must transfer:



I’d be foolhardy recommending a specific sequence of imparting this knowledge to a new team member. Circumstances will suggest the best order. The important thing is that you systematically create and maintain reference documentation for each of these things.


The team decides how to implement the various components of this documentation. It will likely be in different places and different formats. Talk with new members about what is intuitive for them, and be prepared to evolve the documentation as you receive more feedback continually.


There may be aspects of this information too dynamic for documentation. Don’t force it! Remember, we’re not trying to replace the interactions.

Interactions

What does it mean to have a process for interactive onboarding? You will establish a systematic approach to ensure new team members learn about the abovementioned areas. Documentation alone won’t get the job done—schedule sessions as compactly as possible without overloading your new team member.


Make sure they are meeting with the right people. Some people may be outside the team. Encourage mentors to have a good outline of what they will cover. Presenters must receive feedback after each session, followed by refinements. As the information surrounding these sessions changes, updating the materials must become standard practice.


Finally, evaluate how fast new teammates become productive. Everyone is different, so you can’t necessarily use one person as a benchmark for improvement. However, over time, you will likely get a sense of whether or not you are moving in the right direction.



bottom of page