Hacker News Reader

Comment by bb88 | Hacker News Reader

> Good software teams build quality into projects by introducing continuous integration, unit testing, creating feedback, and tightening these feedback loops.

No. Good software teams are led by competent, technical management. Managers who aren't afraid to get down into the dirty details. Managers who aren't afraid to roll up their sleeves and write code if they need to.

The process doesn't matter. The management of what is or is not important does. Agile is just one process out of many.

Imagine an accounting team led by someone who never did accounting in their life: "Just make the numbers work out! I don't care how you do it! My bonus is at stake!"

View on HN

Sigh... This myth that the only people who can competently manage developers are other developers has been floating round for decades.

For some reason, developers seem remarkably blind to the skills other roles and disciplines require. Only a developer can do that, everyone else is basically useless fluff. Maybe it's a form of arrogance or just deep unself-awareness.

Let's apply your reasoning to medicine. I'm sure you would be completely fine with managers telling your surgeon what parts of the surgery can be 'optimized away'.

How to tell everyone that you never worked inside a hospital ...

Haha, funny strawman. My reasoning is that non developers are capable of managing developers, notably people who have good management skills.

Your contention is that the surgeon should be running the hospital.

Hahah, indeed. So have you seen a law department in a company headed by someone who doesn't come from law background? How about a finance department headed by some schmuck who doesn't know anything about finance?

I've seen plenty of departments managed by people who don't come from the background of the department. My current boss is extremely good and came from a different discipline.

Although I don't deny it can help to have the background, it is not necessary to be a good manager of something. Also seen plenty of good techies promoted to management and failing badly.

This is a lie, and you know it. Even a mere idea about lawyers being managed by a non-lawyer would be laughed at. Same with finance, nobody would be stupid enough to even try it

It's ok to disagree, we don't have to accuse each other of mendacity.

I stand by what I said, although my experience is in the technical domain, not finance or law. Maybe those departments are different, I don't know.

I disagree with you. You are stating it, but you are not giving reasons. Managers who weren’t developers tend to not be able to manage the team. They can’t help with or understand the technical decisions made. The non-technical managers tend to be project managers just focused on dates.

We may be talking about different levels of management here. A manager should not be making technical decisions, they should have team leads and architects who do that. It's their job to manage the team, interface with the business, prioritise work and give cover to the team so they can get on with it.

I guess if you have a manager who is making technical decisions, they are really a hybrid manager/contributor role. Maybe that works better in smaller organisations.

Then what exactly is the non technical manager's added value?

He has no experience to lead the team in high pressure situations. Like production being down.

He can't truly have a first person understanding of the work of the people who he manages. He has to rely upon others to tell him who's good and who's bad. That sets up a pecking order.

He can't help or mentor engineers with design decisions, or provide a historical context.

He doesn't understand the technology so there's an immediate communication and knowledge barrier that has to be overcome between him and his directs.

He doesn't feel the pain of a bad decision, because he's not coding it, and he can't emphasize with them since he doesn't code.

He tends to push feature development without fixing technical debt. Again that's pain he personally doesn't feel.

To me, the role you are describing is a principal engineer or team lead, not a manager.

Simply not true however that a good manager can't lead the team in a high pressure situation. I'd say that exactly what a good manager could do well. Obviously they won't be making overtly technical decisions, that's what you are for. They can make business decisions, provide cover, get resources, communicate to other stakeholders... All the bits that need doing but would be a huge hassle for the techies who are trying to fix the issue.

I don’t see much value added by a manager that you described. What you are describing is more of a product manager role.

Not everything of value is technical. That you don't see the value is either because you have great managers shielding from having to deal with all that, or you have always worked in a place that combines management and technical responsibilities (which I never have except for very small companies).

I wouldn't call what I'm describing as product management, although it's possible they could do general management too.

Sure, but I feel it's easier to teach management skills to technical person, than it is to teach tech to someone that's only been in management.

The head of surgery should be a surgeon, not an accounting manager.

The head of accounting should be an accountant, not a surgeon.

And even at the executive level of a hospital, you would want people who have spent their careers in healthcare, rather than, say, architecture.

> Good software teams are led by competent, technical management.

...or perhaps with no managers at all. I'm less and less convinced of the importance of management in engineering except to give investors an illusion of control.

I sort of agree, and I do think it’s possible depending on the team. But unfortunately developers can be too opinionated and get focused on low priority things.

But that doesn't contradict the parent, does it? I'd say you both make good points.

Well... here's a thought experiment.

Let's say you have a bunch of school children and architects create a skyscraper. I've given both groups the process to design a skyscraper.

So in both cases, I should end up with a safe building?

Why not both? Am I missing something? You can have feedback loops and CI and all that, "good craftsmanship" or "good practices" (not "best" practices because those often suck hah), where of course opinions vary on the details of that -- and then someone who is also good at the craft who spends more or most time on helping the rest work together, i.e. manage/lead them.

I’d bet the children would come out better simply because they have parents who are likely multi-disciplined as a group. A disparite group will (almost) always come up with better results than a homogeneous one (at least in my experience)

Reply on news.ycombinator.com