The Tech Lead Engineering Manager (TLEM)
I had a discussion this week about whether or not the Tech Lead (TL) and Engineering Manager (EM) roles should be combined in the same person (AKA, the Tech Lead EM Archetype
). I’ve noticed the TLEM works well when dealing with:
- A small team;
- A relatively simple product domain with simple technical complexity; and
- A relatively experienced team
Let’s look at each of these.
A small team - As a team gets larger, the overall “surface area” of activities increases. This might include running design sessions, code reviews, running 1-1s, planning activities, etc. As the team gets larger, the TL or EM finds they have less time to take care of the tasks that increase due to each person, or new stream of work, and they often start to have to prioritise these. If the TLEM finds technical work more interesting (often the case), they start to neglect some of the EM responsibilities which might lead to less frequent/missed 1-1s and poor communication or alignment with other departments. If the TLEM enjoys the people side more, they might step away from being more hands-on, or involved in technical discussions which means they might be unaware of significant technical debt being accrued, or less optimal technical decisions which increases rework or bugs in the future.
A relatively simple product domain with simple technical complexity - Imagine maintaining a simple customer sign-up process. It’s more or less a CRUD workflow, leveraging a product or library component for standard sign-on/password management processes. Now imagine dealing with a complex pricing engine that needs to take into account customer history, location of orders and a set of historical contracts that each affects a final quoted price. A more complex domain, or area of high technical complexity (think scalability, availability, etc) requires more time from the TLEM as there is inherently more complexity and risk. Managing this risk, even if the whole team is involved, will require more time and attention from the TLEM which leaves them will less time to take care of their normal duties.
Relatively experienced team - A relatively experienced team allows the TLEM to immediately delegate more of their responsibility to different team members. They are still accountable (i.e. need to make sure the outcomes are being reached), but they don’t need to be as active driving each activity. This might include examples such as working with an internal customer and designing a technical implementation to meet their needs, or running team design sessions and code reviews. If the team is significantly less experienced, then the TLEM needs to both be responsible (i.e. do the work) and is still accountable for many of the activities.
When I see TLEMs deal with larger teams, a more complex product domain or technically complex system and a relatively inexperienced team, I can guarantee you there will be some activities that get missed, even by the best and most experienced TLEM because they simply don’t have the time. For newer or inexperienced TLEM, they are definitely going to be overwhelmed and risk burnout trying to succeed in an environment that’s not set up for them.
The most common way of handling any of these changes is to have two people play each role - one person playing the full-time Tech Lead, and another playing the Engineering Manager. This allows both to have more time and to complement each other to make sure the team has everything they need. Just like with most things in life, there is no “right” answer, but a set of trade-offs.
Enjoy this week’s newsletter, and please pass it on to a friend or colleague who might benefit.