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 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.
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.
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.
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.
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.
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.
[+] [-] codingdave|11 years ago|reply
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.
[+] [-] spamizbad|11 years ago|reply
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?"
[+] [-] choppaface|11 years ago|reply
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.
[+] [-] shawnee_|11 years ago|reply
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.
[+] [-] m3mnoch|11 years ago|reply
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.
[+] [-] jes|11 years ago|reply
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 found the book interesting and worth my time.
[+] [-] mattlutze|11 years ago|reply
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.
[+] [-] davedx|11 years ago|reply
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".
[+] [-] pgl|11 years ago|reply
I think this is the different between a "Tech Lead" and a "Team Lead".
[+] [-] d4mi3n|11 years ago|reply
[+] [-] stevebot|11 years ago|reply
[+] [-] perdunov|11 years ago|reply
In my experience, groups of folks self-disorganize.
[+] [-] cies|11 years ago|reply
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.
* 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
[+] [-] Hominem|11 years ago|reply
[+] [-] _djvl|11 years ago|reply
[+] [-] ritchiea|11 years ago|reply
[+] [-] gaius|11 years ago|reply
[+] [-] nsxwolf|11 years ago|reply
[+] [-] drhayes9|11 years ago|reply
[+] [-] hackerboos|11 years ago|reply
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.
[+] [-] JackMorgan|11 years ago|reply
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.
[+] [-] grecy|11 years ago|reply
I'm the only technical person on the project, so the only person I'm leading is myself!
[+] [-] ukigumo|11 years ago|reply
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.
Good luck!
[+] [-] falsestprophet|11 years ago|reply
[+] [-] ebiester|11 years ago|reply
[+] [-] lifeisstillgood|11 years ago|reply
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.
[+] [-] ghuntley|11 years ago|reply
edit: Direct URL -> http://embed.wistia.com/deliveries/a5152426e67b75a366891a6f7...
[+] [-] ukigumo|11 years ago|reply
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.
[+] [-] gaius|11 years ago|reply
[+] [-] cl0rox|11 years ago|reply
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.
[+] [-] ukigumo|11 years ago|reply
[+] [-] zeendo|11 years ago|reply
[+] [-] stoolpigeon|11 years ago|reply
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.
[+] [-] mattxxx|11 years ago|reply
the "tech lead" codes and leads. this idea that it should be a strictly managerial position is pretty gross, and seems like it's an ego thing.
[+] [-] vacri|11 years ago|reply
[+] [-] jghn|11 years ago|reply
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.
[+] [-] hackaflocka|11 years ago|reply
This makes it very stressful to squeeze more work from one's team.
Great Tech Leads need to have 2 characteristics: openness of mind, and empathy. Here are 4 TED videos that any Tech Lead would benefit from watching:
http://tempr.org/54e5723f558e8.html
[+] [-] adaml_623|11 years ago|reply