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.
At the company I currently work at we have "tech lead" (lead dev) as a role within a project: it is not in your function description. As you grow as a developer you will take on this role again-and-again in ever larger projects, it helps devs to grow.
I've copied the section below from our wiki, to show what we consider to be part of this role. I'm interested to hear what anyone thinks of it.
# What is expected of a lead developer?
* Technically in charge of the developer capacity within the project team
* Works in close cooperation with the PM and is crucial in technical meetings with client.
* Explains technical choices
* Recognizes when client wishes (tend to) go out of scope
* Facilitates efficient software development within the team
* Involves other parties when needed (i.e. ask designers for input when needed, etc.)
* Also develops prominent parts
* Understands the technical architecture
* Assesses (judges) any design-input for being complete and realistic (a check-list exists for this)
* Oversees software quality: has decent knowledge of all used technologies
* Knows best practices (i.e. w.r.t. security, documentation, testing, SEO)
* Verifies and then moves post-its from "verify" to "done" (except his own)
* Escalates to PM/AM whenever he/she foresees planning goals may not be met
* Can estimate the time it takes for his/her team to complete common tasks
* Possibly: technically architect the software at stake (for technically challenging projects we have an architect role)
* Possibly: supply time estimations for the project planning
* Chooses the tools and technologies used for the project (within the lines the architect has set)
* Allocate tasks over the team members, detailing the planning
* Takes the lead in translating requirements to tasks (Post-Its)
* Can deploy the project
* Knows the processes of our company
* Identify process improvements and speak them through with PMs/ AMs/ head of technology
* Applies the final checklist (and improves upon the list when possible)
As a "tech lead" I think this is a great list of expectations. I don't allocate tasks on an individual basis, but I may suggest an individual dev work a track of features. I also work with devs from other companies who work with our products and APIs. I like to think I have a tactical view of the problem space while my VP or CTO works strategy.
Very useful list and I kind of like the idea of having "tech lead" be a project-based role, rather than your job description. It will definitely force more accountability.
I am not the type to believe management is bullshit or in the way of getting real work done and still this interview is triggering my BS detector. It feels like an endless stream of confident generalities. Nearly all of the interviewee's comments seem like the kind of thing you say to make your vague role sound challenging to justify its existence.
I think being a tech lead in a flat organization is more of a matter of being the techy that other techies want to talk to. Sure, those other people aren't your direct reports... but there are still plenty of leadership and mentor opportunities.
That's what is called "leadership without (formal) authority." If you are knowledgeable, helpful and approachable, your teammates will naturally gravitate toward you when they are in need of guidance. This sort of organic leadership is in many ways much more valuable than the artificial leadership provided by formal, top-down authority.
The last 2 jobs have been "We're flat here. No team leaders, senior or junior devs." but there are clearly people that take on more responsibility and are more experienced than others.
If you wanted to practice command and control, that is difficult in flat organizations. If you wanted to practice impress and influence, there is no better place. Impress and influence is a lot harder, because instead of just convincing one less technical person, you have to convince every technical person.
I have found striving to impress and influence has caused me to become a much better developer and communicator. I've also seen a lot of developers come, say a few smart things to the boss, and sit back expecting to be given a team to boss around. They often don't currently possess the skills or communication abilities to convince any technical people, and rather than work on those, they go elsewhere to find a team where they can be unjustly rewarded.
Nah, "impress and influence" should be a super-rare thing for actually organizing a team. Individuals can be impressed by one another, but in software development everybody has their own strong opinion on what is good and what is bad, so it is next to impossible to come to a consensus.
Really, just try collecting a group of people and discussing who they think is a great developer and why.
By the way, I have been that person who was promoted from a team of peers.
That is fine, many companies have teams so used to command and control it would be impossible to change that without changing them. I am a dev manager who doesn't use command and control, knowing full well that my teams will self structure themselves around the business needs. To their credit, they are all seasoned at self organization, so come to consensus quickly, and would do so with or without me.
I'm not sure what I would do if everyone on the team was passive and expecting orders, I think that wouldn't be a very good match for our styles.
Personally I am skeptical of self-organizing teams because I have had strictly negative experiences with them as a developer.
It seems that having a self-organizing team of evenly qualified and experienced professionals is probably almost guaranteed to work, but 'working' does not mean 'optimal'.
I am almost certain that when self-organization works, command and control would still work better if you put the right person in charge.
Still, I do not think that command and control is the absolute optimal form of organization. It seems to me that true self-organization requires a number of very special ingredients that maybe the humankind is yet to discover.
Just simply declaring self-organization will lead to more or less disorganization. A disorganized team will not necessarily fail though. It depends on a number of conditions, such as the complexity of the project, the qualifications of the team, time/budget pressure, etc. If the team's proficiency greatly exceeds the project's complexity, then probably any form of organization will do.
A reasonable disorganization is probably what is actually being exploited under the buzzword of so called 'self-organization'.
There are many types of leader and a flat organisation just means that you won't get to be a "type 1" leader, or an imposed leader if you will. That doesn't mean you can't rise to the position using skills and personality.
If you really want to go for leadership in your career look up some courses and books on the subject and talk to a mentor or even HR about developing a career plan.
Ideally, people are paid what they are worth - so that would imply there would be instances where people had the same title, but vastly different pay. The challenge always seems to be how to reliably determine who is really having more impact and who is positioning themselves to look like they are.
If you want to work in a more structured environment, look for larger engineering organizations born in the last 20th century. There are tradeoffs, of course.
To be honest that seems like the daily job functions of a developer. Not a tech lead.
It's hard to say but the one most important thing for a tech lead is "never compromise on standards"
It's the point of leadership to take people places they would not have got to without the leader. And most of us are human, and the place we get to is the path of least resistance - less tests, less refactoring, less user feedback and suddenly it's a mess.
Tech leads are the entropy fighters. Telling us to clean up our act and leading the way by example.
Tech Lead is a nice sounding phrase but what does it actually mean? Pat Kua (the interviewee) talks about architects, lead developers as well as team leaders with budgeting and hiring responsibilities and to my mind these are all quite different roles within an organisation on any reasonable size and require different attributes and focuses.
As for the soft skills that were strongly emphasised in the interview I fully agree that it is a necessary trait of anyone who wishes to lead in whatever form or context but techies are no different than accountants or any other inherently individualistic professional in that regard.
Having worked at both, I can assure you that ThoughtWorks are thought leaders in the agiile development and change. It's hard to get in and you have to be talented to stary there.
Accenture on the other hand, they make it hard to get into the consulting arm, but the tech arm (Accenture Solutions) is easy to get into (although you'd be surprised at how maby people tank in the interviews) and even easier to coast through, producing crappy software and bleeding their clients dry.
Having worked at both, I can assure you that ThoughtWorks are thought leaders in the agiile development and change.
Trying to convey the perception of "thought leader" (which is really a horrible term), and how they are perceived by the software development community are two vastly different things.
I have experience with ThoughtWorks, they turned a mildly complicated problem into a massive architectural wonder of the world, perhaps practicing their design patterns.
I witnessed a similar project unfold. Eventually, I believe, most of them were kicked off the project and it was brought back under control of the company I was working for.
He mentions the book Crucial Conversations. I had it given to me in October and it has impacted my life more than just about any book I've read in the last few years. It really is quite good.
I had a tendency to come into tense or emotionally charged situations with a pretty simple process. First I would decide if I really cared. If I didn't, I would just keep quiet. If I did really care I'd fight to win. Crucial Conversations has helped me to see how many more ways there are to speak up more often and more effectively.
I read it for work but I was so impacted by it in my personal life that my wife and daughter ended up reading it and it has had a huge impact in my home as well as my workplace.
I know this sounds like an infomercial - but I'm in no way associated with anyone related to the writing or selling of the book. I just really appreciate it as a resource.
These terms are a little puzzling to me, because I always thought of a 'tech lead' as a leading programmer, and someone who organises a group of techs but doesn't do tech themselves as a 'project manager' or 'team lead'.
That's basically how things are where I am. We have a group of ~20-25 developers and everyone reports to one of 4 managers (who are also technical, but that's neither here nor there).
Every project in the group has a tech lead, who may be one of those 4 manager or it might be someone else that's relatively senior. That tech lead is in charge of the folks under them for the purposes of that project.
Any given developer might be working on a single project or sharing time between a few, so they'll have their manager and 1 or more tech leads.
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.