Hacker News Reader

Comment by katzgrau | Hacker News Reader

"What makes engineers sad? Their boss(engineering managers, Directors, VP’s) do not know what they face on a day to day basis and does not know how to build something, whether it is a feature or architecting something from scratch."

If that's true, then it's probably mutual. Engineers typically do not realize that their manager's role is to manage people and process (which is a bit of a specialization in itself), and knowing how to build software is not necessary but definitely useful - mainly for questioning your engineers when they tell you something that sounds crazy.

If any engineers are under the impression that their job is harder or more important than management, sales, etc, they're being arrogant.

Coming from a former strong engineer who started a company and now manages people more than code.

View on HN

There are different types of hard. Digging ditches is hard work, getting people to do what you want them to do is hard work, writing complex software is hard work. When engineers think about hard work they usually think about it being intellectually difficult. It isn't arrogance, more that they are just focusing on the definition of hard work that they are used to.

I disagreed with this point in the article. I do not need a manager that has done my job before or spends a week a quarter doing my job. I need a manager that knows how to get my team the resources it needs and knows how to to deliver a product. Most importantly, I need a manager that trusts the team.

I've had great managers that couldn't code their way out of a paper bag.

Yeah i agree and think it can even be phrased as just not micromanaging. You understand which resources benefit the team and delegate a certain amount of trust to trustworthy individuals. Then hold them accountable to that trust. Dont dump stuff on them and dont jerk the wheel. Share your constraints; etc. Learn who is good at leading, communicating, etc. Do skip level 1:1s to validate your assessments and understand boots on the ground.

I use to also think being technical was a part of that but now i think being a good manager is worth much more on its own.

Do you think someone is qualified to manage a process they don't understand?

Do you think it’s impossible for someone to understand a process without having years of experience doing it themselves?

At least a few days, yes, it's impossible.

But more importantly, it's impossible to manage a process that you don't know how to do yourself. The closest you can get is on a client-seller relationship.

The inverse question, is it even possible to have a manager who understands every nuance of the process they manage?

I find that, in practice, the more a manager knows about how things are done - the more they have the urge to micromanage and resist delegation, especially if they're perfectionists.

Doesn't sound completely horrible in theory but in reality it's bad for everyone.

There's a group of these people called CEOs and they get paid a lot.

They manage a process they do understand (in theory): getting groups of people to do valuable stuff without irreparably imploding.

I don’t understand any of the tools I use in my own work (how does VS Code do syntax highlighting? How does the electricity make my laptop screen show me high resolution colors?). But I’m still able to produce plenty of value for my clients.

> Engineers typically do not realize that their manager's role is to manage people and process

In my experience, where ever engineers are not realizing that, it is when management is not managing process and people. Both management of process and of people are visible - when manager is doing it, engineers and know. But, fairly often management is preoccupied much more by activities directly visible to their bosses and and much less with those that can improve internal functioning of the team.

> and knowing how to build software is not necessary but definitely useful - mainly for questioning your engineers when they tell you something that sounds crazy.

If you are supposed to manage process, you need to know what engineers, testers, analysts, customer support do on daily basis. You dont need to be star, but you need to know where they spend time and what their issues are. Otherwise your process wont solve issues that are occurring in your team. You will be solving imaginary issues some other teams have you read about on the internet.

And the above is greatly frustrating for everyone under you.

By far the hardest part of that transition (at least for me!) is going from being able to create measurable impact on the order of days to most things taking months or years to create real change.

As a coder, I could get a bug report, build a fix, test it, get it deployed within an hour if it was urgent and simple.

Now I do a lot of listening, a little bit of talking, a bunch of thinking and discussing with the rest of the executive team, and mostly make small corrections which might show meaningful results in 6 months' time. Every so often there's still something really amazing and valuable, but it's much rarer and less predictable when that's going to be.

And yeah tons of new learning to do. Being a good programmer doesn't automatically translate to being good at running a company (though understanding tech and having been there certainly helps both for understanding what your staff are going through, and having their respect)

I strongly agree that managers do not need to be technical or understand dev work. However, I don't have much sympathy for managers who are "misunderstood" by engineers. Companies that have issues with disgruntled engineers grumbling about management and process are mismanaged almost by definition.

Reply on news.ycombinator.com