Way back in 2011 I ended up landing a job at the now defunct Forward Internet Group in London. I joined as the only junior member of a team of very capable and welcoming engineers who were all at the tech lead level of experience. They gave me countless chances and challenges to hone my nascent ability and drill in some important technical/non-technical skills.
Within months of leaving Forward I found myself in my first leadership position at RefME, and that Forward team were a large reason for why I was considered for such a role not long after joining. Practices such as ownership, observability, understanding the business needs, writing explicit code with optionality in mind, and encouraging descoping vs cutting quality - all of these are somewhat obvious in hindsight, but being given the opportunity to leave my comfort zone regularly as a junior engineer with a strong team supporting me meant I learnt these from tacit knowledge rather than purely theoretical knowledge. I’ve been lucky enough to make strides into tech leadership over the last 5 years from that point, taking those early lessons, asking questions and trying out new techniques and making numerous mistakes along the way to try and keep a high performing and happy team.
I’m a big believer in there being no right way to be an engineer or a tech lead, just ways that are less wrong, and there are a number of principles that I’ve tried to adhere that I’ve wanted to document today, and I hope you find them useful too.
1) Understand the wider context deeply
The tech lead role is primarily related to strategy and delivery of technical solutions, working with your product manager, designer, stakeholders and the business to come up with reasonable well-scoped plans for delivery. That relationship with stakeholders and the business is especially critical and often under estimated, and too easy to just leave to the product manager. A good tech lead understands the technical and product goals, but also understands what the business is trying to achieve and why - you will come up with better solutions the closer you are the problem space being defined, rather than hearing it secondhand. This will also let you build trusting relationships with stakeholders as a team, as you are less likely to overpromise and underdeliver due to better expectations being set. You want to be an example for the team and always champion understanding the why behind the software you are writing.
2) Learn to communicate to different functions
Similar to the above, it’s important that any engineer learns to communicate effectively with the other engineers in your team, in different teams, to product managers, to designers and any non-product teams in the business. You are accountable for the critical craft of transforming business needs into software, and also the champion for non-functional requirements in tasks such as architecture and deciding when to tackle inertia in the codebase. Therefore you want to make sure you can both interpret requirements (and question them thoroughly) but also explain technical concerns (tech debt, inertia, scope creep) to non-technical people through analogy rather than using intimidating jargon. This is hard skill to learn but there will be so many changes to practice, make sure you take them.
3) Be an enabler
Rather than being the only high-performing engineer on the team, aim to create a team of high-performing engineers around you by being an enabler. Understand what your team members’ aspirations and strengths are, understand what they enjoy doing innately and what they need encouragement to improve. Encourage ownership of each task and of the services you own, discipline to stick to the process you’ve agreed to as a team, and psychological safety to change that process, to make mistakes and ask questions constantly and give each other feedback. Personally I even go as far as saying I am interrupt-driven and try to keep coding and non-critical meetings that don’t help the team to a minimum to make myself as available as possible to the team.
4) Encourage empathy for your future selves
This is one which is sometimes hard to sell from a theoretical point of view and often requires enough years on the job to experience tacitly. This involves encouraging the team to think of their future selves looking back at their code (or better yet other team members) when approaching a task or an investigation. Encourage your team to spend just enough time documenting decisions on tasks in PRs and card comments, writing PR descriptions and valuing explicitness over implicitness in the code. All software by default lives indefinitely so encouraging empathy in the team to make changes easier to make later by making the current changes easier to understand will reap benefits even in the short-term. Trying to avoid silos of knowledge in the team functions in the same way.
5) Don’t covet coding time
This is a slightly controversional one, and I’ve read various pieces advising different amount of coding time for tech leads. My personal feeling is that if you overcommit to how much you yourself as a tech lead should be writing code, you are going to do damage to the overall health and performance of your team. That is not to say you shouldn’t be involved in discussing designs of solutions, or spending a large amount of your time reviewing the code, because you absolutely should to not lose touch with the product area you are being asked to lead. However, the deep focus required for all but the most trivial of tasks will likely take you away from the other tasks that will make you a good lead such as being an enabler or unblocking others, and if the task is critical and you are being distracted by other needs, you will block progress on that task. Pick enough coding tasks to keep you sane, but don’t lock yourself away.
There are more nuanced breakdowns to each of these, and further points that could also be documented, and of course your mileage may vary. That said, these cover the main areas I try to keep myself accountable for as a tech lead, and what I think makes someone of my personality (at least) an effective lead. I would love to know of any other tenants leads have stuck to you, or whether there are
Acknowledgements:
- I was inspired to write this after reading Habits of High Performing Teams as it a) is a great read and b) covers everything I love about the best teams I’ve been in.
- Forward is lost in time these days, but the style of engineering team I joined was known as Programmer Anarchy