Hacker News Reader

Comment by slongfield | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

As someone that has been on that spot as well, consulting seems to be the only safe path to grow old and keep doing tech.

Most companies don't have any issue bringing in the aging expert that will code and lead their internal team, teaching them the in-outs of the technology they should master, yet have serious issues having such skillsets in-house.

You can progress to highest IC levels as someone who wants to work with their hands directly on code/issues (saw that myself at 2 different big tech). But it’s harder and more one off.

Reason for that is simple - in most areas you can achieve more, if you can properly guide dozens of engineers than lock yourself in the basement. Main exceptions are crazy specialized perf gurus.

A lot of the art though is what not to write. Too much code is written.

Generally referred to as negative space in most art. What you don't write is as important as what you do write.

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.

Reply on news.ycombinator.com