[koonsolo]

I even had clueless managers who demanded I explained the technically complex problem to them, because "maybe our insights could shed new light on the problem". They just don't get that best thing to do is leave us alone and let us do our job. They are just nervous because they are totally powerless in such situation.

In a factory, a manager might be smarter than the one doing manual labour. In tech, it's the other way around.

[pdpi]

Right idea, wrong reason. You have a tonne of assumptions about how the product works that I don’t. If the bug is that subtle, dollars to Donuts says that one of your assumptions is wrong, but you just haven’t thought to question it yet.

When you explain the issue to me, I’ll ask dumb questions about context I lack, so you’ll explain stuff you take for granted. And it’s answering those questions that will make you figure out where the problem is.

[koonsolo]

If I explain the technical stuff to another programmer, spot on indeed.

Managers who don't know what a variable is, SQL or TCP or a while loop or whatever, in my experience it is just that: dumb questions.

[pdpi]

Something's terribly wrong with the hiring if managers for a tech team are that clueless about tech, though.

[Gibbon1]

Sometimes a good manager can help by expanding the solution space or by shifting the problem somewhere else.

[gricardo99]

Spot on.

[setr]

If you assume potential malice (ie a lazy dev just not handling the bug at all) then a manager is required to ask about the bug, if only to try to verify that you've put real effort into the problem (based on say, confidence in whatever you spew). The worst possible scenario is that five months later, it turns out no one actually looked into properly: they just claimed to.

[koonsolo]

In that case, the manager should have fired that dev a long time ago.

Best managers I worked for had trust in their developers, and asked for estimates on planning (not bugs). The worst managers didn't trust us, and pushed their own planning on us because they thought it would make us work faster. They thought planning can be negotiated.

I can tell you which projects were within 7% of the deadline, with good quality. And which ones we were always putting out fires, and some never finished.

[hal9000xp]

I can't agree more. I always maintained that you should hire devs qualified and motivated enough to be self-managed. In other words, ideally, I would hire people which doesn't require management at all.

[themarkn]

I mean everybody wants this but even the greatest ‘self-managers’ need management to do stuff like this:

- put their work in context - remove dumb obstacles for them - ensure that they are working in ways that benefit the team - check they are having an ok time interacting with others and sharing knowledge - check they have not said yes to too many things - ensure they don’t get swayed by better offers - acknowledge their work

Etc etc ... management is not about enforcing deadlines and correcting problems (which you seldom have to do with truly independent people). There needs to be the right level of communication with each employee so you are not in their way but not hanging them out to dry, and this needs to be maintained even in times when there are no problems.

[koonsolo]

As I see it, managers need to be at the service of their team. But a lot of managers think their team is at the service of them.

[setr]

I think one problem is people tend to be locally self-managed: they'll do work assigned just to them, or a close-knit team, but as soon as something is blocked by say the dba team, they'll put very little effort into ensuring the work progresses (unless they have a personal interest in seeing that task through). Or they'll prioritize incorrectly: towards their skill/interests, or what their friends are waiting on (as opposed to the whole team/company), or even a simple misunderstanding of importance.

And of course you have things like deadlocks that have to be resolved, ie dba waiting on programmer, and programmer waiting on artist, and artist waiting on dba.

So the manager serves a distinct, and presumably necessary role. And by necessity, he must be invasive: if there was sufficient communication, the deadlock would resolve itself. But if the manager is necessary, there is not sufficient communication: that is, someone is not announcing important information by their own will (perhaps because they aren't aware its worth announcing). It has to be wrung out.

And if you're trying to stop such problems before they occur, then you'll end up asking seemingly redundant or even arbitrary questions. (Because you can't know the correct questions to ask!)