Hacker News Reader

Comment by s_u_d_o | Hacker News Reader

A manager that is not as good as the engineer they are managing / wasn’t ab engineer, would be managing a team where the actual engineers are doing all the job and taking all the critical decisions. The manager would feel weak whenever the technical side of the work is being questioned, reviewed, planned, explored; they can only listen to the engineers, they’d have no say in most topics, weak arguments, will look lost. However, a manager who was previously an engineer that actually worked for years, and got exposed to many projects, will lead by excellence and can intervene in most subjects with high confidence. As for the managerial skills, one could learn them with time (ofc some of them are naturally given), but i’ve seen managers with very little soft skills, learn a lot, and do well.

View on HN

Checkout football/soccer. It acutally varies a lot, some of the best coaches were only "ok" players but some of the best players were horrible coaches.

It's not as absolute as you make it sound. Also because managing a team shouldn't require you to make very technical decisions. You should obviously know what you are managing but if there is a decision to be made, the people who spent hours on that subject will be your best experts and their guidance is essential.

In soccer coaches usually handle the strategic side of things and they have dedicated coaches who handle more player-related things. I think this is how a good manager in a normal company should work too. Make sure the team works as a team and take strategic decisions but not handle the nitty-gritty technical stuff.

> some of the best coaches were only "ok" players but some of the best players were horrible coaches

But very few great (and I'd say probably even good) coaches never played at all.

I was going to say, "ok" here still means "played for years at a professional level," not "did all right on their local Sunday league team."

I’d draw a distinction between management and technical leadership here.

Management, in the face of a stalemate, is going to address roadblocks from a human perspective. They will ask questions and listen. They will get people to talk and sort out their differences. Management will not weigh in with their own heavy handed technical decision unless they (and their team) has failed at the task of teamwork. Because no matter how good their technical chops, they are perpetually too far removed from the actual problem. Management will not really use the product the team is building. They can’t feel the impact of any one technical decision beyond how it impacts the team.

Technical leadership still has skin in the game. Leadership sets technical direction. They evaluate choices and tradeoffs based on technical merits. They are one of the resources management relies on. Leadership is going to have to live with the consequences of their decisions in their day to day work. They must use and build upon the thing they are leading.

Some people fill both roles. Some teams are lacking elements of one or both. Some teams fill these roles perfectly well in ad-hoc fashions, especially when you get teams of people strong in both areas - by far my favorite work experiences, everyone is exceptional and recognizes it in their peers. Then there is no hierarchy or need for it. That dynamic never lasts long, so we implement structures that try to capture it more broadly and often limp along for the sake of continuing to move forward as a group.

“Engineering mindset” is a thing. You don’t actually have to be an engineer to manage an engineering team, but you have to understand what engineering is and engineering culture, as well as grasping the basic fundamental concepts of the field. None of that is particularly hard, but there are a remarkable number of people who have never actually built anything that wasn’t a completely structured and pre-planned/pre proven product. If you’ve never had to figure out a “novel” solution to anything in your entire career, you are going to have a bad time managing engineers.

It works both ways though. Engineers can become enamored with making something novel, when what the customer actually wants is something else or already exists. Or maybe what the budget or market allows won't let the engineers make the best possible product so they're going to need to make something a bit less novel. A (good) manager will negotiate these issues.

That seems to go counter to the widely held idea of "innovate or die". If your company just wants to clone the market leader, what value are you to the customer? Management often wants "safe" so no fingers can be pointed at them. I consider that a failure in leadership.

There are different types of companies, and even within companies there are different levels of innovation needed depending on context. Take a current darling like Anthropic. Even though their main product is innovative, a lot of the nuts and bolts are source code adjacent tooling that is as old as the hills.

Really depends on whether its worth the effort to innovate on that thing?

Is your company's core product a billing system? Then it pays to innovate on billing systems and differentiate from competitors.

Do you just need a billing system so you can collect money and move on with innovating where it actually matters? then buy and don't make.

wasting time on doing novel things that don't differentiate your business only puts you behind your competitors.

How is the "engineering mindset" different from that of any other role requiring problem solving?

My experience has been that those who are too precious about the only role they've ever had (an "engineer") are difficult to manage precisely because of their inflexibility and lack of curiosity. It's ironic isn't it?

> Engineering mindset” is a thing. You don’t actually have to be an engineer to manage an engineering team, but you have to understand what engineering is and engineering culture, as well as grasping the basic fundamental concepts of the field

I wish this was more common but every time I had a manager without an engineering background or one who was a weak engineer, the ride was not smooth to put it kindly.

At a minimum managers need to understand the basics of software: code debts, release cycles, team workflows, infra basics, security, etc.

They don't need to be software engineers but they should have an overview of the industry.

"Breakneck: China’s Quest to Engineer the Future" by Dan Wang takes the converse - what happens if the managers are engineers, and extrapolates it to national scale, with both miracle outcomes and catastrophes.

Reply on news.ycombinator.com