Leading Without Deep Technical Knowledge
In my previous jobs, when I’ve been promoted to a leadership role it has been as a result of being the most experienced member on the team. Having a deep knowledge of the business, the code base and the technologies we’re using meant I was already an authority on most topics of the team needed to discuss, and could weigh in on a discussion with a well formed and considered option.
When I changed companies at the end of last year I came to Ocado Technology as a team lead for an existing team, using a technology stack I wasn’t familiar with. In fact Ocado are a Java based company, which I had never used before, so not only was I not familiar with the frameworks and libraries used, but I wasn’t even familiar with language the code was written it either!
Leading in a situation like this required a complete change in how I approached problems. When a stakeholder or the product owner approached me with a challenge rather than immediately being able to respond with a rough solution, and vague estimate or a timeline I need to defer to my team, and let them propose a solution, estimate it, and then I could fit it into our schedule. I might challenge them on some points, but it was their plan. I quickly needed to learn who knew the most about which systems, so I could get the right people involved in discussions early.
Previously although I was able give initial feedback on a potential project, I would still allow the team to discuss them, to propose alternate solutions and to estimate. The change is that now my contribution is much more about making sure the right people are talking and helping to avoid misunderstanding when the business and my developers are accidentally talking at cross-purposes.
While this change has definitely pushed me out of my comfort zone, it has also given me space to focus a different area of my leadership skills. Ocado prides itself on its values, one of which is its servant leadership philosophy. By not having the knowledge to make decisions myself I am forced to empower my team to make decisions on how they want solve problems.
It’s not just case a facilitating discussions though. I may not know the details of our code base, or the intricacies of library, but my knowledge of software design patterns and systems architecture is valid whatever language is being used, and my opinions are as strong as ever. It is normal for developers to immediately jump to the simplest solution to a problem within the framework of the existing code. As an outsider my first instinct is usually to take a step back and ask why the system is designed like that, and to propose a bigger solution that resolves some technical debt, rather than focussing on the issue at hand.
This change in role has made me realise that even when I was the most experienced in the code, language or framework I should have made more of an effort to devolve the decision making process. Not to stop expressing my opinions, or involving myself in the discussions, but to explicitly encourage others to contribute, and make sure they are taking part in discussions. This has resulted in people being more bought in to solutions, and encouraged a much closer team with a greater feeling of ownership over our code. Being forced to make this change to my style has undoubtedly made me a better manager, and a better developer too.
Comments