Hacker News Reader

Comment by paulcole | Hacker News Reader

> Always doing shit themselves

This is one of the most counterintuitive things about leadership roles IMO.

If you get promoted there, it’s often because you got a lot of things done yourself in an IC role. And then the fewer things you do yourself, the better off you, the company, and your reports are once you’re in a leadership role.

So you have to learn that feeling idle compared to what you used to feel like isn’t a sign that you’re doing a bad job.

View on HN

In addition as a leader your best use is often to be interrupted with questions from junior engineers. This means you can never (or rarely) get into a flow where you are productive, as you are getting close someone interrupts your thought with a question.

As such if you have time to work on engineering (which you should make to stay sharp) it needs to be something unimportant to the business so that you can be late. Trying to add a new warning to your static analysis tool, checking out the latest framework to see if you should switch to it in the future - and other such things that you really want and long term are good but short term won't pay the bills.

> In addition as a leader your best use is often to be interrupted with questions from junior engineers.

I kinda disagree w/ this. I get better results from helping people understand this:

https://www.techtello.com/wp-content/uploads/2022/03/decisio...

And then making sure that they're taking action when they should take action and getting help when they should be getting help. This means they are wrong sometimes but it's better for them to be wrong sometimes and learn than to be interrupting with too many questions when they should just be doing their best.

Admittedly at this point my only direct reports are bosses themselves, but they vast majority of questions they have for me go into a shared 1:1 doc that we address monthly. Everything else they take action on and report as needed.

Kindof, but a lot of time has been wasted figuring out something that someone else already has done.

Better to figure things out on your own than learn that you can always interrupt someone else when you get a little stuck.

Days are often wasted because you do that. That is at best, I'm now up to 4 different implementations of a complex protocol (at months each to build and debug) because nobody asked a question.

sure you shouldn't just ask for every problem, but don't struggle too long when someone knows the answer.

I wonder if there’s a middle ground between interrupting constantly whenever you have a problem and wasting days searching for a solution?

The best advice I heard about the switch from regular engineer to mgmt role was this: A software engineer works to build harmonious productive stable software systems. An engineering manager works to build harmonious productive stable people systems. The product is different.

So many people who move into management don't make this mental shift and keep their hands on the steering wheel because that's how they got there in the first place. But if you don't let others drive, you won't be able to keep the car on the road for long. If you go into that role your job is to mostly get your hands off the nuts and bolts of the software system and create people systems of motivation, trust, and organization to get your team members working well on them instead.

I've never made the transition myself but have increasingly thought about it.

Yeah this is a big point in High Output Management by Andy Grove. That to be a manager (or to do any job really) you need to understand what you're producing and how to measure the quantity and quality of that output – ideally identifying issues with output before they become costly to fix.

Much easier said than done but it was a real Aha moment for me as a boss.

Reply on news.ycombinator.com