For a startup CTO, dealing with performance issues is probably one of the hardest things they will do as a leader. Usually, performance issues arise when the team goes beyond ten developers. Not that there weren't performance issues before, but when the team is small, the CTO or another senior engineer is always there to fix someone's code or work through the night to meet a deadline.
When the engineering department becomes bigger, individual contributors should be more autonomous, and it's physically impossible for the CTO to be behind everyone's back to review their code. As Sam Schillace, Deputy CTO at Microsoft puts it:
"Once you grow past this phase, however, problems like attrition, low quality, politics and poor communication are a lot harder to fix. Once you get going, culture gets baked in, and it's super hard to change. It's really worth thinking about it now."
Having clear standards for performance
When it comes to engineering teams, bad individual performances (like missed deadlines, incorrect estimates or bugged code) directly impact the team's performance. Since individual contributions have a multiplier effect, the project won't launch if one team member misses their objectives. The first step to adequately address consistent performance issues (emphasis on the "consistent") is to ensure that you have a clear and transparent standard for good performance for each role.
This standard could include metrics like objectives completion rate, code quality or documentation quality. It should also include behavioural characteristics like solving problems autonomously or cooperating efficiently with other team members, based on your company's values. If the performance standard is well documented and is regularly addressed during one-on-one(s), team members should always know where they stand in terms of performance. There is nothing worse than someone discovering that they did not perform well during their annual performance review.
Building improvement plans
Performance management techniques usually tend to focus on the communication part. If you give critical feedback often, team members won't be surprised and will act on their apparent shortcomings. But in reality, I've found that bad performance is not about awareness but rather about acting on it. When a team member is not able to perform tasks they're supposedly able to do, it's either because they lacked:
- Knowledge (aka information)
- Skills like architectural perspective, test-driven development or documentation
- Behaviours like autonomy, cooperation, curiosity, initiative-taking
For each case of performance improvement, you first need to understand what the team member lacked (usually a blend of the three) before coming up with an improvement plan. If they lack knowledge, it's an excellent opportunity to update the documentation or make it more accessible. When the team grows, information tends to get centralised in key people's heads rather than decentralised and easily accessible.
If the team member lacks skills, the appropriate answer is training. Depending on the skill and the number of people in the organisation that should possess it, you can organise individual or collective training sessions. Some things to consider when it comes to training:
- Training is a structured learning experience with a clear output and a timeframe.
- Training is about practically applying selected skills and knowledge, not about sharing knowledge (you have documentation for this).
- The best way to learn is to teach, so it's always better to have someone in the team performing the training.
Lastly, if the team member has behavioural shortcomings, the only answer is coaching, which can unlock a person's potential to maximise their performance. Behavioural patterns are so ingrained in us that they're super hard to change even if we know about them. Some things to consider when it comes to coaching:
- Coaching is about listening and asking questions.
- If you have a definite answer for a situation, it's training; if you don't have the answer, it's coaching.
- Usually, you think you have the answer, but you don't 😉
Unlike training, coaching shouldn't have a definite time frame, but it helps to keep a structure. Remember that every documentation/training/coaching action you undertake is an investment in your company's human capital and your long term goals, even though they seem like a loss of time in the short term.
To go further
📝 One Rubric Changed Box's Engineering Performance - First Round Review
📝 Building a Learning Organization - Harvard Business Review