Skip to content

Comment on "My boss says we don't need any engineering managers"parent

Comments

I really don't see managers as decision makers. They do help communicate strategic direction, but in terms of tactical decisions, they are too removed to really have valuable input.

OTOH, unless you are the team lead, the amount of bike shedding from simply taking initiative and just making a tactical decision can be overwhelming. It's framed as "not building consensus first."

A PO recently chastised me after I worked with a user who wanted a date field to default to today. I was asked "who told you to do this, where is the JIRA that described this work?"

Many orgs do not view engineers as decision makers, simply as do'ers, which really I think highlights how the role of a software engineer is just misunderstood. Software engineers are more like writers than they are like carpenters. Consider for example the number of decisions made when writing a single sentence, let alone the upper management that can barely make a decision more fine-grained than the title of the book and whether it should have one or two main characters.

I really don't see managers as decision makers.

At this point we are almost certainly talking past one another. I've never been at a company where management didn't have the final say. In your world where managers don't decide anything important, I guess they are just HR secretaries? They have 1:1s with people and try to figure out who needs to be replaced and who should be promoted? What is that like?

A PO recently chastised me after I worked with a user who wanted a date field to default to today. I was asked "who told you to do this, where is the JIRA that described this work?"

This is really the root of the problem. Implicit in all these titles ending in manager is decision making authority, and the selection process does not in practice produce better decision makers. A competent engineer experiencing a customer problem first hand is the smartest and best informed person in the room. They should be expected to make the best decisions about how to use their time and skills. But there is a charade that plays out involving * managers, who have been given decision making authority. They either agree ceremoniously or look stupid with little corrective consequence.

We potentially agree on quite a bit and maybe might not talk past each other.

With regards to our differences, I view software management more as a leadership role rather than as a decision making role. We won't quibble that leaders need to make important decisions, we both agree there. Yet, providing direction is different from deciding direction. That is my point, software managers are deciding neither "what" nor "how", and thus their role is (IMHO) primarily more leadership rather than decision making.

By one metric, I'd suggest software managers are most responsible for helping their team maximize the ratio of time spent focused on-task to the time spent dealing on noise. While that is an interesting metric, it's still hard to tease out the effects of organization and team structure from the role of just one person who is meant to largely coordinate (AKA: direct or lead) and enhance those networking effects.

My MO is deciding anything myself where I feel my chosen solution is Pareto better and force the PO to clarify/specify where customer feedback is contradictory or unclear.

I think this varies wildly from company to company, especially your experience in the first two paragraphs. I've worked at companies where what you're saying rings true (especially about "not building consensus"), and at companies where taking initiative is a hard requirement - written down in company documents - for any sort of advancement into the Senior Software Engineer & beyond levels.

"who told you to do this, where is the JIRA that described this work?"

My standard joke is: We must be doing incredibly well if you have time to ask me that. Ideally the standard joke is followed by a [long] list of things they should or could be working on and then I force the conversation into that direction. If they ever bring it up again I remind them that they had already mentioned it and change the topic to actual work again. I've had a good few burst out in laughter going though the process specially the 3rd or 4th time.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.