These are the instances where I feel it is definitely worth keeping some people around who act as glue. (or old timers).
In our company - we have a tech lead role which is supposed to be the technical point of contact for a given team. This person is expected to have answers or have a way to find the right answers about the nuances of the team.
The good ones are invaluable. Whenever new projects come up, the modus operandi is to write a proposal, review it with your current team for sanity (on whether it achieves its purpose) and then with this group of relevant stake holders / tech leads to ensure you're not getting some giant thing wrong that can nuke some other part of the business.
The problem I see with this role though - we (I am the one for analytics and one of the TLs for Data Infrastructure at Snap) have to handle 20-25 hours of meetings around all these coordination AND ensure some work gets done in your own area so that you are in touch with the code bases you are fiddling with. So as much of an alluring title that is, you are giving up deep dive development (like I was able to do building storage engines for DynamoDB). Tradeoffs :/
And there are cases where the tech leads don't have the answers (new or incompetent) OR they think of a weird case couple of months down the line, but this works out overall.
I probably should write a blog about this - but anyway, I don't know how this works out in the non-software world: Why wouldn't you have a knowledge person/council around?
I'd like to differ slightly: the job of a good tech lead is to be an effective first among equals.
If you're working on a talented team, there should be no presupposition that the tech lead is necessarily the best developer on it. But you should be good enough to break ties and set direction. I've worked on a lot of teams with talented developers who aren't especially interested in leadership, or former leads who've decided they want to go back and hack some more. You cannot, and should not, boss these people around. But you can block management up, and unblock team down, by keeping management out of everyone's hair, and keep the developers from tearing each other apart over complicated technical questions or obscure business ones.
If you're working on a team that embraces pairing, that can ease a lot of the pressure on the lead to do reviews as long as the pairs are well-chosen. Trust but verify.
I had a good tech lead. They did occasional code reviews and made occasional contributions and did some PoCs. But most of that was delegated to the rest of us. He instead instead managed most of the communication with stakeholders and then product manager.
I'm a tech lead in a large, distributed application. I disagree somewhat, there's a bit of a unicorn reasoning. If teams don't work well, a tech lead's job is to revive culture and confidence which is going to be harder.
My day to day as tech lead is mostly looking at our board and seeing if people's work loads are just fine. Do I provide mentoring? Sure, when I need too. Do I provide architectural guidance? Sure, when we have big stories that require my review. Majority of my time is spent taking care of my team. Is my team doing well? Absolutely. We communicate well and aren't shy to help each other out. But being a tech lead my emphasis is quality and making sure that my team is on track with that.
I'd disagree - tech leads are there to steer the team, not the tech. They are supposed to understand why the product designers and owners are asking for constant change, and work to make that change happen in a way that isn't disruptive. They are a liaison between different groups, to help the devs be part of an aligned effort between groups, by understanding the goals of all groups, helping the others understand the needs of the devs, while helping the devs understand how they can help meet the needs of other teams.
Do that well, and you don't have a "product" team, a "money" team, and a tech team - you just have a team.
The article pretty much ignores factors external to the development team. In my experience at a larger company, a key role of tech lead is as a central communication point for other teams / disciplines / projects. It becomes infeasible for every person working on a product to have to know exactly who to talk to for every question. Instead with leads, if I have a sw question, an electrical question, a service question, I know who to go to. This doesn't mean the lead has to know everything themselves. Can always refer me to the expert. But ideally the lead is also someone with above average communication skills.
Tech leads may not make sense for the author and some projects, but they absolutely make sense for other projects. This is why:
1) Development teams have churn, the tech lead onboards new members and gets them aimed(and kept) in the proper direction.
2) The tech leads decides on technology when developer A and developer B are deadlocked over MySQL vs Postgres, or any other stack choice.
3) The tech lead is the one accountable for failures. Once the people above the tech lead have titles like CIO, CTO, CEO and the like - they expect and demand a single point of contact as their visibility into the development process. The tech lead is this person, and should be "professional" enough to interface with the exec-types, as well as have the communication savvy to translate technical issues into management issues.
Finally, an example of when a tech lead is wanted: Image your development team is 8 people, working on a full stack web application. Another department wants to use this web application's authentication capabilities in their own project. Do you want that other project's 4 developers talking to every single one of your 8 developers about how that should be done? That's 32 individual conversations, with 32 different ideas and opinions about how to do it. You want their tech lead to talk to your tech lead, and a reasonable decision made and enforced. You don't want 32 meetings with no outcome.
The author's experience sounds(at least to me) like small teams and small company structures. While that may work well without a tech lead, once departments and companies become large - positions like tech lead really begin to make sense.
I'm surprised to see how many people think a tech lead is a good idea.
Most teams I have worked on have a manager who used to be an engineer. In terms of direction setting, a final authority amd so forth, it is their call. They talk to their management and other teams and tell us what to work on, but are not involved in the technical day to day and are not micromanaging the details. So I might do the Android client, X does the web API which uses JSON, Y is the DBA designing the database schema, Z does iOS and so forth. It is not ruderless as they can make the final decision.
With a team lead, you have one person on the team doing work who is also doling out work. It can lead to all of the problems mentioned in the arricle.
Also - small, underfunded companies usually can not get a good experienced programmer or administrator. So the hires are the inexperienced types who could probably use a team lead. But the companies are too small to have one. By the time someone has a resume to be good enough to join a company which can afford a larger tech team with a manager, an experienced lead and several somewhat experienced programmers - the need for a lead is much less. Besides, people are naturally going to defer somewhat to a more experienced engineer who has been at the company longer.
I think the bottleneck and bus factor points are key. The tendency would be for the lead to own the most high-visible, business impacting piece of the code base, and dole out less attractive and impactful pieces to others. It can waste time as well - they can assign work but are too busy to really go over it, then after a week you show them what you did, but they did not mention they like things done with MVC, or TDD, or whatever, so then you have to spend another week doing it over. As the article says, they're overloaded and often enough away from the team. Instead of having four or five autonomonous engineers going at full blast, you have one overloaded engineer who hogs more of the critical, business visible code than they can handle, and the other engineer whose time it is to waste. Who are usually not much less experienced than the lead.
The flip side to "design by committee" is that one person is designing every thing! That person is too overloaded to design everything as needed, so you have the non-leads writing code for a week, that will be thrown away until the lead has time to come back around and decide how your project will be designed.
An ex-engineer manager does not have their hand in day to day, and many of these conflicts go away, whereas the needed leadership is there if necessary. I'm surprised people feel otherwise. The alternative to design by committee is often everyone waiting on the one overloaded person who has to design the whole system.
Observe your team lead, he/she might be dead weight... or maybe not. It's true that a tech lead should be pro-efficient in the language and technology, but there are tons of things that a tech lead is supposed to do.
Bringing people together, keeping the motivation of the team going, solving conflicts as soon as they happen. Also communicating with management (maybe you haven't realized that you are free to focus on the tech side because someone else is absorbing the drama?)
A tech lead is also expected to be able to distribute work and keep everyone engaged, working through the process and making sure the team has the resources including QA, hardware, other teams, coordinating release schedules, aligning stakeholders, controlling scope creep and product managers. And sometimes the manager relies on him to even do admin work.
Sometimes people are in a position for a reason. The ironic thing that could happen to you would be that someday you get that job and suddenly realize that it requires a completely different set of skills.
Agreed. It happens a lot (in all my previous jobs I had mostly non-technical people as leads), but they have to work 10x harder to be effective. I think that even a limited technical background does a lot of things for you:
1) You can scope your team's features and commitments more effectively if you have some understanding of the technical complexity of each ask.
2) Understanding the technology (and the skills of your people) means you have better intuition about the right people to bring into the room when a problem arises
3) It's easier to be empathetic with your team when you have engineering experience, because you know that many times the spec is just the tip of the iceberg.
4) Credibility. A group of devs will have a lot more respect for you from the start if they know you're not just a bureaucrat and you can code (even if it's not as well as they can)
This is very insightful, thanks. I'm currently in the middle ground where I still want mentoring from the technical leads on some things, but I also have enough seniority to be mentoring new hires. You've articulated the way I think our tech leads are often not great at explaining themselves, while also giving me something to think about when passing on information to newbies.
I've found that tech leads grow organically as a team grows. The go-to guy who knows the products and the tech, and to whom everyone go with questions, if they also have leadership skills and like to help other, ends up falling into that role almost by accident. Whether it becomes formalized or not depends on the organization. I don't think you need to inject a tech lead role onto a team that hasn't already informally started using one.
I think there are probably almost as many definitions of tech lead as there are companies. In my case the tech leads in the company are responsible for turning high level requirements from the rest of the company into actual actionable work, and feeding back up to senior management places where we could improve the existing product by refactoring/introducing new features. Alongside that we do line management for the people on our team, and generally act as a point of contact to try and reduce the level of interruptions to developers.
It’s very much not an IC role - we might throw together the odd prototype, and we’re all very capable of rolling our sleeves up and helping out if a project needs an extra person for a bit, but the general rule is that if we’re on the critical path for implementing a project something has gone wrong.
I've found most tech lead jobs to be heavy on the leadership. Leadership could be separated from management, but I find today it rarely is.
The best tech leads I've worked with have owned that, and helped their team do the tech while leading the work from a high level. The worst have insisted on holding in to low level work, letting their team suffer without direction.
It could be a company problem, it could be a leader problem, but in my experience it's been a company/leader communication problem, or a leader failing to follow through on what they agreed to.
I came out of lurker mode just to reply to this article.
I get the author's premise that capable developers don't necessarily need a lead. However, based on my experience, that is overly optimistic.
I've worked in large organizations for quite a while now and have run in to two specific situations where this mentality just doesn't work:
- Need for a tie-breaker. I've been in places where the Sr Devs on different projects/applications (myself as one of them) have all disagreed on the direction to take the roadmap. As a result, we ended up with four separate projects/applications going four separate ways. All because there wasn't one person to get everyone in line.
- Need for a tech lead to set the right direction. It's been a while since I have worked with a lot of talented, like-minded people that were all capable of making good technical decisions. For the past ten years, I have seen a huge trend to just finding the lowest cost resources. Granted, it has more to do with my situation, but that just goes to show that the author's position may be valid for him, it definitely does not apply to everyone.
I also believe in the following:
- The Mythical Man-Month where the best team structure is similar to an operating room where the surgeon has complete control of everything that happens. He has ultimate accountability and what he says goes.
- Also Peopleware where really good people are worth the money. If you don't get really good people, no matter how willing they are, they aren't going to make a solution as clean. And unfortunately, I'm in a world where we have decent developers who are always willing to jump on tasks, but they don't always make the best decisions. A tech lead would fix that.
Anyway, context is everything. What works for some might not work for others.
My opinion is if you don't need a tech lead, great. But, most teams do. Someone needs to be there making a final decision. Also, it depends on the company and the type of team. If it is a government organization and the majority of the development team are contractors, a tech lead is most definitely needed to advocate in the best interests of the government entity. In this scenario, the tech lead would need to be a government employee.
This is the only thing I was thinking this entire article.
I'm a dev lead. If I had an entire team of my great engineers, my job would be easy. I'd simply delegate my duties to everyone else, and we'd all be nearly equal.
The reality is I have 2 junior people who need to be guidanced through everything. I have one moderately experienced guy who just wants to be left alone to solve bugs on his own, in quiet isolation. I have one moderately experienced guy, who's ambitious, but used to cut corners when he thought no one was paying attention. And I have one senior dev who is a great coder, and can take 1 or 2 juniors under his wing, but hates code architecture with a passion and just wants to make small ui features on the main website.
Who, exactly, then can I delegate everything to? Removing a tech lead would be disastrous.
I'm jealous of people who work in a shop where the teams are so well constructed, that they think you can get rid of the tech lead role.
I'm also willing to bet that those people either have amazing tech leads, and don't realize it, or have amazing managers one level higher, and simply haven't climbed high enough up the managerial ladder to see how lucky or how much work goes into that.
And the other part of “leading the team” is being able to mentor juniors and help them technically.
What good is a lead if they can’t answer technical questions and can’t help other developers with technical guidance?
What will it do for team morale on your iOS team when they know you bought in a “lead” who couldn’t actually help them with the tough technical problems?
In the teams without a tech lead that I have seen, people just defer to the most senior/confident developer in the team to resolve deadlocks and decide between some tougher choices. That person essentially becomes a tech lead without a title.
Edit: I agree with the child comments. It makes things easier, less prone to miscommunication, and efficient to have an actual tech lead in the team.
You're describing individual personality shortfalls, not problems intrinsic to the role.
> In the best case, they do split work, delegate, mentor, and lead meetings, but always end up doing the business critical or challenging pieces themselves (because why would I take the time to explain this when I could just do it...)
The best case scenario is seeing yourself as a facilitator first and foremost. A tech lead that succeeds at delegating, mentoring, and developing their peers does not need to do the business critical work ... peers should be able to do so, with some light oversight (design/code reviews). If some complex/business critical work is a couple months away, the lead should proactively work to disseminate their knowledge.
This parallels management - a bad manager micro-manages execution, a good manager builds mostly autonomous teams... a bad lead engineer micro-manages execution, a tech lead oversees a team of mostly autonomous engineers.
Sure, your team will move slower at the beginning. But think long-term, maximize the integral.
In our company - we have a tech lead role which is supposed to be the technical point of contact for a given team. This person is expected to have answers or have a way to find the right answers about the nuances of the team.
The good ones are invaluable. Whenever new projects come up, the modus operandi is to write a proposal, review it with your current team for sanity (on whether it achieves its purpose) and then with this group of relevant stake holders / tech leads to ensure you're not getting some giant thing wrong that can nuke some other part of the business.
The problem I see with this role though - we (I am the one for analytics and one of the TLs for Data Infrastructure at Snap) have to handle 20-25 hours of meetings around all these coordination AND ensure some work gets done in your own area so that you are in touch with the code bases you are fiddling with. So as much of an alluring title that is, you are giving up deep dive development (like I was able to do building storage engines for DynamoDB). Tradeoffs :/
And there are cases where the tech leads don't have the answers (new or incompetent) OR they think of a weird case couple of months down the line, but this works out overall.
I probably should write a blog about this - but anyway, I don't know how this works out in the non-software world: Why wouldn't you have a knowledge person/council around?
reply