Hacker News Reader

Comment by solatic | Hacker News Reader

This is the problem with "Tech Lead" positions in many startups, i.e. ones where the team leader (managerial role) is expected to also shoulder many IC responsibilities (maker role). You end up either being a good team leader and a bad IC, a good IC and a bad team leader, or doing something unsustainable like being a good team leader from 9 AM - 5 PM and then filling in IC work until 9 PM.

Please - just don't hire for this position to begin with.

View on HN

I'm in a 'TL' role and my current schedule is:

* quick dog walk/sunlight

* meetings

* dog walk/sunlight/lunch/exercise

* focus work

* dog walk

* personal development/curiosity/light work

* dinner/etc

I actually really enjoy breaking up the day with walks and exercise. I usually try to have at least one day with no meetings for two focus blocks but I found there is definitely diminishing returns there. I think ideally I'd do the meetings in the afternoon but the timezones involved prevent that. I'm not the highest-volume IC but I'm reasonably good at identifying high-value targets since I have a lot more context so in the one focus block a day I can do some damage. If it's a bigger project I might just try to start it/find the shape of it and then shop it around to get it on the appropriate teams roadmaps.

It's pretty crazy to me that the people making most of the resourcing decisions in companies were maybe once technical but haven't actually pushed a line of code in years so that muscle has atrophied and this leads to a complete lack of nuance in decision making. So I definitely think you need at least few 'blended' roles who keep their technical chops a bit honed but still participate in the 'command'/resourcing discussions (but of course I'm biased).

I try to fix non-urgent bugs or make small DX improvements in the code. It forces me to understand pains in the CI/CD, the codebases in general, but I can drop it for an unplanned meeting without causing problems. I also run toy side-projects outside work.

Ooh, you can still do focus work.

I give it a year and that time will fill up with meetings too =)

While I appreciate this perspective, it can’t happen in isolation. You were enabled to be successful. Someone understood that you can’t be 100% of both in your role, and set clear expectations with your peers, directs, a level and two above.

Many startups have inexperienced first time leaders at the top who are still running on pure adrenaline. They work unsustainably (not realizing that yet) and create such expectations for everyone else.

You’re constantly pushing beyond 100% in peace time. Now imagine war time. It gets bad - toxic even.

I completely agree. I do less exercise and more code than you, but I keep seeing that the best teams aren't run by a scrum master or product manager, but by a tech lead who can negotiate and translate requirements. It seems to produce the best results.

I think it works quite well when they focus on architechture, mentoring, product planning, estimation, cross team communication, code review, devops and small feature/config requests. On slow days they can fix those nasty bugs that have been in the backlog for a while, or on tight deadlines they can help in the parts lagging behind in the important project. But yes I can see how this could be considered "bad" IC, but all that gruntwork is work that doesn't need to distract and slow down your team now.

It's amazing to work with a good team lead like that since you can focus 90% of your working time on getting top priority things done.

What I've seen from the opposite approach is that ICs have a lot of pressure to estimate, plan, document, communicate etc because the managers are too detached from the day to day work. Almost no actual work is getting done because of all the interruptions and endless technical bikeshedding because nobody has either the authority or understanding to call the shots. The ICs compensate for this by working overtime for free.

> I think it works quite well when they focus on architechture, mentoring, product planning, estimation, cross team communication, code review, devops and small feature/config requests. On slow days they can fix those nasty bugs that have been in the backlog for a while, or on tight deadlines they can help in the parts lagging behind in the important project. But yes I can see how this could be considered "bad" IC, but all that gruntwork is work that doesn't need to distract and slow down your team now.

What you're describing is a good manager, period. You can't slot an MBA with no engineering experience into a TL position, to serve as some kind of bureaucrat. When the team's stuck in the weeds, a good leader rolls up their sleeves and helps. It just goes to show what a sorry state the industry is in, that we no longer think of that as intrinsically a leadership skill.

My company had tech leads that are explicitly not managers of the team. There are still managers scattered throughout - some of the tech leads, and some people who are otherwise ICs - but they are always from other teams.

This is an interesting model, because it means when someone disagrees with their tech lead they are explicitly not disagreeing with their manager but with a peer.

The managers also can't assign work (explicitly or implicitly) because they're not even on the same team. This stopped a bunch of non-planned work, such as when a manager said something like "it would be nice if you built x" or asked questions that required a lot of research, as it's too easy for an IC to take that as a directive to actually do it. Now that is more like "good idea, you should ask my tech lead or PM to create and prioritize a ticket so I can do it."

The tech lead position is great. It is amazing to work with skilled technical people.

The real position that needs to go away are EM1, EM2, Director, Senior Director, Assistant VP, VP, SVP etc.

These positions are mere reporting chains. They have so much free time that they end up playing politics and performance review games. Nothing they do actually benefits the product.

The ideal structure imo is Tech lead reporting directly to a director. It is the directors job to make strategic choices, and tech lead's job to split the work into composable parts that lead to delivery.

Multiple tech leads can work together, under the direction of the director.

All pay, performance, bonus nonsense should be offloaded to an administrative assistant person whose job title is called administrative assistant.

Make the company more technical, not more managerial.

I had a good tech lead. They did occasional code reviews and made occasional contributions and did some PoCs. But most of that was delegated to the rest of us. He instead instead managed most of the communication with stakeholders and then product manager.

It is possible. I've done it. You have to guard your time carefully. You and your management have to be on the same page about what you are and are not doing. That's not always the case.

Reply on news.ycombinator.com