This makes it sound like "Tech Lead" is a switch that gets flipped on your job description, and suddenly invokes a major change in your daily routine. And maybe it is, in some organizations.
But in my experience, groups of technical folk self-organize. No matter what the formal hierarchy is according to management/HR, an informal meritocracy will form, and natural leaders will emerge... normally being those who are not only good at tech, but also at seeing the bigger picture, including business knowledge and soft skill. These people won't be spending 30% of their time coding, they will be spending 80% of it coding... and 20% helping everyone else out, and talking to leadership about strategy. People who spend 70% of their job organizing the coders are not tech leads, they are project managers (or just managers).
Maybe I am just arguing semantics, and "Tech Lead" means something else to the rest of you... it appears from the few comments here already that every organization labels themselves differently.
Even if your team is self-organizing, eventually you'll need a "Tech Lead". This person really isn't a boss. They're more of a facilitator that handles all the cruddy work so that developer productivity is maximized and the dev team is free of distraction. They also manage the "politics" of the dev team to the outside -- like making sure strong devs get recognized for their performance, and weaker ones either get mentored (or if that doesn't work out, fired).
I've worked under 30% leaders before and didn't care for the experience as a subordinate. I always felt like POs and PMs broadsided the team, good people weren't recognized or rewarded, shitty people got to hang on, etc. The experience wasn't awful, but it wasn't that great. It would have been much happier had our boss spent two fewer hours each day coding and 2 more hours managing each day.
Also some 30% tech leads tend spend that 30% needlessly micromanaging developers on their team by doing stupid shit like constantly having them move classes or modules around the codebase for no rhyme or reason towards better "organization" rather than just telling the team "I think the way x y z exist is messy. When you have downtime, or are sick of working on whatever and need a break, can you folks think of a better way to re-org and refactor them?"
In my org, a Tech Lead usually worked more closely with Product and Engineering Managers than any other developer. The Tech Lead's primary job was to help Product break down tasks and make them more technically feasible. The management usually elected Tech Leads mainly as a way to give raises, but often the individual would use the spotlight to act as an envoy between Product and their team when the team lacked an Engineering Manager or the manager lacked competence (more common).
The Tech Lead role, in my experience, is a confirmation of execution and aptitude (in the eyes of management), but certainly not a certification of technical competence. Many teams had Tech Leads who were not as capable or as key of technical contributors as others on their team.
Across orgs, my experience is that Tech Lead is always a social spotlight and is only mildly correlated with technical competence. Tech Lead is much closer to junior manager than senior engineer.
These people won't be spending 30% of their time coding, they will be spending 80% of it coding... and 20% helping everyone else out
Oftentimes companies think they need a "Tech Lead", when what they actually need is a really good Technical Writer who understands code. A lot of time (80 percent) spent "coding" isn't necessarily great / productive / effective if it's just creating more piles of code. But coding good documentation, or refactoring documentation around even mediocre code? That's the quickest route to making the sum of the developers' lives easier.
I've found that spending a good chunk of my time documenting things has paid off in spades in for my team. Writing out common processes (what is our particular flavor of gitflow, how do we use it with Github, how are issues tracked, etc.) and common interfaces (what do you pass to this endpoint to get what results) makes every single person on the team function better.
It also reduces the amount of time I have to spend answering questions--link to the wiki and move on.
Now, actually getting others to buy-in to this is a different story: they don't usually see the point in working to sow the same sort of benefits they reap on a daily basis.
I think a good lead needs to constantly strive to spread knowledge about the work as widely as possible.
If time spent "coding" is just creating piles of code you are doing it wrong. Coding can involve removing and restructuring efforts as well. But more importantly, having skilled programmers working in the code base is one of the greatest ways to drive architecture and establish patterns for the entire team. This is very important.
I do agree that documentation is important, but just felt you really downplayed how large a role an architect/tech lead that actually writes a lot of code can play.
i would recommend listening to the part on "common mistakes of new tech leads".
do you really want a project manager -- who hasn't contributed anything to the code base -- to evaluate skills, make recommendations, organize, and mediate for a team of a 8 or 10 software developers? probably not.
as a "tech lead" in a very, very large organization, i would say finding 30% of your time to code is very hard to do. especially given you are the one sitting in the meetings explaining progress, deflecting new arbitrary "but can't you just..." tasks, and speaking with authority on cross-team dependencies all day.
Your comment regarding technical folks self-organizing reminded me of a book I enjoyed: "Great Boss, Dead Boss" by Ray Immelman.
The book suggests that people in organizations self-assemble into tribes, ignoring the org chart, exactly as you note.
Tribes are one of the oldest organizational structures, the author suggests. He goes on to give advice about how to use this to improve organizations without getting crucified in the process.
I think it can be helpful when org-sactioned. Just heard Evan Spiegel of Snapchat talk about how everyone is part of a 10-person group. Similar to Jeff Bezos's 2 pizza rule. Thanks for the book rec.
To fit these concepts into my experience, I'd call what you're describing a senior developer.
A "Tech Lead" is in part a manager, yes. Project management aspects are part of it, product management aspects are part of it. From my experience, the difference is chiefly in making decisions that define strategy, and making decisions that implement strategy.
For the most part, a single person can't do both well, and, extrapolating from your numbers above, spending 10% or less of your time thinking about and working on strategy means strategy simply isn't being considered by the tech team.
I'd draw the line like this: a tech lead must appreciate the trees while focusing on the forest, while a senior developer, or someone of the sort, must appreciate the forest while focusing on the trees.
We self organized on previous projects, and one day I came back from a holiday to find that on the most recent project I and a colleague had been promoted to tech lead for that project. It was more an official recognition of what was already de facto.
I have to say though that having official recognition that you're in this role by management also helps a lot. You need buy in so everyone in the org recognizes you as someone with "technical authority".
> These people won't be spending 30% of their time coding, they will be spending 80% of it coding... and 20% helping everyone else out, and talking to leadership about strategy. People who spend 70% of their job organizing the coders are not tech leads, they are project managers (or just managers).
I think this is the different between a "Tech Lead" and a "Team Lead".
This happened to me, but in my own experience I find myself spending >40% of my time doing things that are not programming. This may be a symptom of the org I work in, but I suspect it's not uncommon for people in these positions to double up as SCRUM masters, code reviewers, mentors, and/or meeting organizers.
In my experience, leaving that 70% to Project Manager's usually means giving it up to someone who doesn't understand software. Sure, they might have a business school understanding of what software is, but it's not the same as someone who has been in the trenches and understands software smells.
But in my experience, groups of technical folk self-organize. No matter what the formal hierarchy is according to management/HR, an informal meritocracy will form, and natural leaders will emerge... normally being those who are not only good at tech, but also at seeing the bigger picture, including business knowledge and soft skill. These people won't be spending 30% of their time coding, they will be spending 80% of it coding... and 20% helping everyone else out, and talking to leadership about strategy. People who spend 70% of their job organizing the coders are not tech leads, they are project managers (or just managers).
Maybe I am just arguing semantics, and "Tech Lead" means something else to the rest of you... it appears from the few comments here already that every organization labels themselves differently.