Hacker News new | ask | show | jobs
by felizuno 1381 days ago
I work with a lot of technical founders who struggle to accept the inevitable truth that taking the time to specify, coordinate, and resource what they want to do leaves no time to be the one doing any of those things. They eventually solve this problem by hiring other engineers to focus on the implementation step while they keep everything on the straight and narrow. When the company grows and they run out of time to directly supervise every engineer an engineering manager is born.

Engineers who don't appreciate the role of the product/marketing/management layers don't seem to understand that if they had to take on those responsibilities it would leave them with no time left over to write any code. If nobody takes on those responsibilities then our company won't make money to pay anybody to write code. It's not chicken and egg, it's cart and horse.

If you don't want to become a marketing expert as well as a product design expert for the sake of doing all these things simultaneously consider being glad others are taking things off your plate and coordinating work without you so you can focus on writing code.

3 comments

I think that a helpful abstraction is that writing code is just one of many "levers" that one can deploy to transform one's ideas into a massively impactful, scalable system. Writing specifications, unblocking colleagues, and building team culture are equally powerful and often provide even more leverage. And if it's 10x better leverage, even if you're a slightly less efficient manager than you were a coder, that can still result in a net enhancement in your team's ability to turn ideas into reality. Of course, this won't be for everyone, and one's enjoyment of the day-to-day is perhaps even a larger factor. But if what you enjoy is seeing things come alive, it can be worth taking the plunge into uncharted waters.
Over the first 10 years of a an engineers career they might only be exposed to a few different management roles. It's possible that the manager isn't fulfilling the actual role so what you have left with is just the distraction.

Regardless if the manager is helping the team they almost always drain resources to aggregate information that they can synthesize upstream. It's a system that is so fragile it's not hard to see why we have an industry full of people that experience this.

I think you'r point is that people with 10 or fewer years of experience (which I think is many people in this thread based on the comments) might have a sample bias issue that stems from working around fewer total managers and fewer companies, where those companies also may be worse than average at selecting managers? I would agree that there are probably plenty of people who fit that mold given the state of our industry recently.

As for "draining resources" to do whatever reporting they need to do I don't think I understand what is fragile about it or why it would be anything other than necessary. It's like log aggregation/introspection, you do it because you want to see what's going on at a lower level without dealing with the minutia of every point of data.

To this end as engineers we design code that fills management roles all the time in our systems, and we understand perfectly why their role is needed but sometimes fail to realize that human systems are analogous. Nobody is arguing why a load balancer can be an important part of a system, or the values provided by ORMs, but here we are arguing about what managers do in a complex human system.

or the values provided by ORMs

I'll point out that the world is pretty diverse and there are actually lots of people who think that ORMs were a mistake and lots of people who think that using them is always a no-brainer. There's an interesting phenomenon that it seems like a lot of folks manage to build up reasonably long careers while only running into one side of this divide or the other and not even realize that the verdict on ORMs isn't a settled fact where one choice is always right.

Perhaps it's similar with engineering management and we should be having a more nuanced conversation.

> there are actually lots of people who think that ORMs were a mistake and lots of people who think that using them is always a no-brainer.

This doesn’t mean that both groups are right though.

I would argue that neither group is right. Both are myopic and only see things from a limited perspective.
Ironic. Correctness is indeed a curse on the few.
I see that the phrase "draining resources" can be taken to only mean a net negative. I was attempting to state that it takes time away from the team for the manager to function. That manager could see positive or negative returns on the time it took.
I still think there's an issue here just from the phrasing. "Taking time away from the team" implies that the team has better things to be doing. A manager isn't stealing a team's time by aggregating information to share upstream. A good manager is keeping the team aligned and informed so that they're working on the right thing at the right time. If the manager isn't there, the team needs to do that work, or be potentially wasting their time.
I see this as a rephrasing for a bias towards the management. Obviously a manager can completely waste the time of the team and company. Anecdotally I've had more managers do this than not that reported to me. I have been lucky with the people I've reported to myself especially earlier in my career.
>it takes time away from the team for the manager to function.

I think a more accurate take is that it can "drain resources" from the individual to provide a net positive impact to the team (ideally). The problem with a lot of the cynical takes here is they appear to be only considering the perspective of the individual.

It's like the idea that if somebody stops by my office to ask a question; it's great for them to get an answer, but a detriment to me because it interrupts my work. If all I cared about was personal productivity, I would lock my door but the overall team productivity would likely suffer. A good manager puts together a system/culture that balances all those competing goals to the betterment of the team.

> they almost always drain resources to aggregate information

Here’s an idea: Provide this information before they have to ask, when it’s convenient for you. Like between tasks.

Took a 5min break? Move the damn story over to done. Got stuck and seeking clarity but are blocked? Leave a quick comment.

If your manager has to ask what’s going on, you’re not communicating enough.

Sure, but none of this is free. That's all extra work that has to happen. The fact that I'm doing it in "down time" doesn't make it free, I have a million other things I could theoretically do at any given down time.

Not to say this work is necessarily not worth the cost, but it absolutely costs something.

Of course, the managers don't rely on the ticketing system either, because not enough people are super diligent about updating the tickets.
> Here’s an idea: Provide this information before they have to ask, when it’s convenient for you. Like between tasks.

Sometimes that's all the manager wants, and the team lets them down. Sometimes the team takes hours estimating work that no one can reliably estimate, because management wants a burndown chart to feel good about, even though the last n burndown charts were wildly inaccurate.

As with any situation, issues happen at every level. What's unique to managers, though, is that they combine overwhelming power on the team with zero accountability to the team. Obviously when something goes wrong the team is going to be mad about it.

That is technically an idea.
> Engineers who don't appreciate the role of the product/marketing/management layers don't seem to understand that if they had to take on those responsibilities it would leave them with no time left over to write any code. If nobody takes on those responsibilities

Spending on marketing is like building and maintaining a nuclear arsenal in this respect: It is to everyone's detriment (yes, everyone) but if the competition does it, you must also.