4 ms·

A tech lead role is different from a management role. The TL is the person who the buck stops with on technical discussions. While part of the job is providing

A tech lead role is different from a management role. The TL is the person who the buck stops with on technical discussions. While part of the job is providing mentoring for junior engineers, they aren't directly responsible for performance management, headcount allocation, etc, in the same way that a people manager is, and people don't usually directly report to them in the org chart. By definition, no large engineering effort is solitary. It makes sense for the more senior eng to be responsible for the decisions that will affect more people, and that requires talking to and understanding them. If people want the senior eng title, they need to be able to do that kind of work.

closeparen 4y ago
A large engineering org is almost always horizontal, whereas some narrow problems are unusually deep and/or important and therefore benefit from unusually skilled attention down to the micro level. In some cases you want your three wizards supervising the architecture of 100 people working on 25 products… and sometimes you want them lovingly crafting every line of a framework or other core component that is going to mechanically influence all that work even more than design review ever could.
eikenberry 4y ago
To me the main difference is whether I get to work with code or people. Technical tracks are for people who want to work on code, but TLs don't. Technical leads spend all their time working through design documents and in meetings. They are technical meetings and documents, but they are still not actually creating things. They are artists who have gone from making art to helping guide other artists. Definitely a valuable role in a company, but whether you call it management or not doesn't change the fact that they no longer get to make the art. I want roles in companies for the technical artists to progress. Where you get harder problems, work on more complex issues, do things that require more research and autonomy to solve. These skills are also valuable and needed in companies and most don't have a way of retaining that talent as they have no track for them.
- chmod600 4y ago
  A lot of the art though is what not to write. Too much code is written.
  - eikenberry 4y ago
    Generally referred to as negative space in most art. What you don't write is as important as what you do write.
- sokoloff 4y ago
  The vast majority of time, a harder, more complex problem, requiring more research to solve implies more than one person working on the essence of solving it. As soon as you have more than one person working on it, someone is providing guidance to someone else who is, on balance, receiving guidance.
  - lanstin 4y ago
    Or small teams that self-organize. Sort of the axiom behind "Agile Manifesto." And some problems require not large numbers of people thinking a little about it, but rather long periods of time uninterrupted for one or a few people to think deeply about.
- tesseract 4y ago
  I have very little interest in becoming a manager, and when I have been pressed into team-leadership roles in the past I've found it uncomfortable and stressful. That said, I have come around to the view that because of the simple fact that any large engineering project must be a team effort, once one's ambitions become large enough, the ability to manage people is the only tool powerful enough to implement one's technical vision. I believe it was reading Joe Sutter's memoirs (Boeing 747 chief engineer) that really crystallized that view for me. In my own career, I am currently pursuing independent consulting as the "progression" of an individual contributor role. I believe this is fairly common, and I think there's kind of a mutual cause-and-effect going on there with the lack of good senior IC paths at many companies.

closeparen 4y ago

A large engineering org is almost always horizontal, whereas some narrow problems are unusually deep and/or important and therefore benefit from unusually skilled attention down to the micro level. In some cases you want your three wizards supervising the architecture of 100 people working on 25 products… and sometimes you want them lovingly crafting every line of a framework or other core component that is going to mechanically influence all that work even more than design review ever could.

eikenberry 4y ago

To me the main difference is whether I get to work with code or people. Technical tracks are for people who want to work on code, but TLs don't. Technical leads spend all their time working through design documents and in meetings. They are technical meetings and documents, but they are still not actually creating things. They are artists who have gone from making art to helping guide other artists. Definitely a valuable role in a company, but whether you call it management or not doesn't change the fact that they no longer get to make the art. I want roles in companies for the technical artists to progress. Where you get harder problems, work on more complex issues, do things that require more research and autonomy to solve. These skills are also valuable and needed in companies and most don't have a way of retaining that talent as they have no track for them.

chmod600 4y ago
A lot of the art though is what not to write. Too much code is written.
- eikenberry 4y ago
  Generally referred to as negative space in most art. What you don't write is as important as what you do write.
sokoloff 4y ago
The vast majority of time, a harder, more complex problem, requiring more research to solve implies more than one person working on the essence of solving it. As soon as you have more than one person working on it, someone is providing guidance to someone else who is, on balance, receiving guidance.
- lanstin 4y ago
  Or small teams that self-organize. Sort of the axiom behind "Agile Manifesto." And some problems require not large numbers of people thinking a little about it, but rather long periods of time uninterrupted for one or a few people to think deeply about.
tesseract 4y ago
I have very little interest in becoming a manager, and when I have been pressed into team-leadership roles in the past I've found it uncomfortable and stressful. That said, I have come around to the view that because of the simple fact that any large engineering project must be a team effort, once one's ambitions become large enough, the ability to manage people is the only tool powerful enough to implement one's technical vision. I believe it was reading Joe Sutter's memoirs (Boeing 747 chief engineer) that really crystallized that view for me. In my own career, I am currently pursuing independent consulting as the "progression" of an individual contributor role. I believe this is fairly common, and I think there's kind of a mutual cause-and-effect going on there with the lack of good senior IC paths at many companies.