Hacker News Reader

Comment by carschno | Hacker News Reader

I think the Peter Principle addresses a good point, but misses a critical one: the hierarchy itself. Obviously, a manager requires different skills than an engineer, so why should a good engineer be a good manager? This holds the other way round: a good manager is not particularly likely to be a good engineer.

Both is fine, these are just different jobs. However, the problem is that the manager is 'above' the engineer in the generally accepted hierarchy. Consequently, engineers are pressured to become managers for the development. As long as this hierarchy exists, the problem will exist.

View on HN

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.

“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.

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.

My experience in a large ‘industry’ (not IT) is that we: a) are very bad at knowing how to measure performance b) mostly only measure performance as an individual contributor, and not as a manager or leader. (Which is to say: of course managers and leaders have their performance assessed, but it is often via the same tools/questions used for individual contributors, rather than specifically measuring skills in management or leadership domains) Then you overlay this with human factors such as nepotism, conflict aversion, politics, friendships… and of course we screw it all up overall. —- So, to your point, absolutely we’re bad at selecting people who have the aptitude to be a good manager or leader for such roles, and terrible at weeding out people who aren’t suited.

> As long as this hierarchy exists, the problem will exist.

I would encourage you to try to setup a place where no hierarchy exists and see how it goes. In my experience people have wildly different opinions on multiple (even minor) things and without someone to "take a decision", things end up just going in circles.

Of course, if the person taking the decisions repeatedly takes decisions that have a negative longer term impact (much easier to asses on longer term than at the moment you have to take the decision), something should change, but that can include contributors looking for other companies ...

I've worked in teams where both Team Lead and Product Manager were peers to everyone else. Everybody reported to a manager above the team. They were some of the best performing teams in my career.

You put agreements/processes in place to make decisions in a flat hierarchy, and as last resort business (PM) makes the calls.

I also find that essentially 100% of the time - if there is no formal power structure, and informal one forms. Every time. And that informal one is essentially always relationship-based.

> these are just different jobs

This is a point I came to make. Different jobs also different skillsets. A good solution taken on by some industries is decoupling promotion and salary rises by having separate engineering and management streams where both have similar opportunities for career progression but you can stick to the actually job that you yourself are best suited for. People who have the people/social/political/organization/high-level-view skills and like exercising them can go into management, and those with focus/deep technical expertise/creative problem solving skills, can stay in engineering. People do usually have bits of both of these, but you know if you are stronger in one or the other.

Many companies do not offer a clear promotion path for engineering roles. It is very common for the promotion path to be senior -> team leader -> choose between engineer manager and staff engineer / architect, meaning that the reward for being a good engineer is to be promoted to a manager role, even if the person is ill suited to pick up such responsibilities.

A manager requires very different skill sets from a low-level developer. However, for your senior developer, you need very similar skills as a manager. The manager can skip all the engineering skills, but the senior engineer cannot skip all the manager skills.

Senior engineers and above, they need to know all the engineering skills, but they are most of their time not being engineers, they're being a people person. They're talking to others, they're explaining to other developers what's going on, how to do their job. There is somewhat difference as the manager is thinking only about the organization structure and how good people are, whereas the senior engineer is thinking about how to use people to make the engineering parts better.

They are different jobs, but I think still being an engineering manager benefits from having spent time as an engineer, more than the other way around.

I have to somewhat disagree. Being an engineer makes you a better engineering manager. However, that puts a floor on how bad you could be. It doesn't put a ceiling on how good you could be. I've had great managers who never were engineers. However, the floor for managers who have never been engineers is lower than the floor for engineers who have been.

In my org, we have "tech manager" roles, where the compensation is similar to people manager roles. Some sr. tech managers end up with a direct report or two. At the end of the day, upper management asked and got the message that we care more about compensation than titles and implemented this in response. Everyone is encouraged to switch roles, but it feels like it's less about development per se and more about auditioning for upper management (both finding out who plays ball and has the skills).

Reply on news.ycombinator.com