Hacker News new | ask | show | jobs
by prmph 1277 days ago
Were they a great manager simply because they let you do what you wanted, without any deeper guidance or feedback?

On a basic level, yes a manager needs to have reasonable trust in his team members and be able to interact with them well. On a deeper level, however, a manager who lacks any clue about the work being done will either frustrate the team or leave them to their own devices altogether. The former is bad under any circumstances; the latter is bad unless the management provided is supposed to be at a very general level.

2 comments

One of my scrum teams is all very senior developers working in a new area with lots of unknowns and technical challenges. I purposely "leave them alone" not because I'm a clueless manager, but because this type of work is always messy and will have false starts. The phrase "reasonable trust" screams "FAKE!" to me. You trust until it's broken, or you don't trust. I think what you might mean is trust but verify?
You're conflating "guidance" with lack of trust; the two things are entirely separate, and I'm not sure why they are being confused.

I'm leading a small (4 person) team working on a large multi-year greenfield project, and I sometimes schedule the entire team to meet with the client, who is a domain expert, so that we can hash out some fine decisions that he has unique insight into. My insights, as someone who bridges the technical and domain sides are also key to the success of these meetings.

Would you say I don't "trust" the team by not allowing them to work in a silo?

> Would you say I don't "trust" the team by not allowing them to work in a silo?

Yes, this means you don't trust them.

As I've already said, I've been doing this for roughly 25 years now. I can tell the difference between a technical decision and a business decision.

Even the wording ... "by not allowing them" implies both that you don't trust them and you don't have enough respect for the authority you wield to avoid using it cavalierly. I mean "by not allowing them to kick kittens". Sure, if they're about to start kicking kittens, #savethekittens. Otherwise, let them work.

Because here's the thing. Shitty managers don't know they're shitty, if they did, they would stop being shitty because recognition is the first step to becoming a non-shitty manager.

Because it's one thing to tell me all of the developers are inexperienced and don't have these skills so you don't trust them. It's another to claim you DO trust them and treat them as if they're inexperienced developers.

I'm not sure if you are capable of understanding the point I'm making, but I'm going to try again (hopefully for the last time):

Please read this sentence again in my comment above: > I sometimes schedule the entire team to meet with the client, who is a domain expert, so that we can hash out some fine decisions that he has unique insight into.

Without getting into specifics, the team simply does not have all the domain knowledge they need to successfully complete the project. I believe you understand what domain knowledge means. It does not mean I think the team is incompetent. No, but the client has some specific domain knowledge (not exactly related to software engineering) that should be incorporated into the project.

Now, according to the team structure, I bridge the gap between the client's domain knowledge and the team's core skills. And this is what shows that I trust the team: I schedule meetings where we all meet with the client, not just me, so that we can figure out some of the decisions together.

If my use of the word "allowing" is what is throwing you off, then let me phrase it this way: how do you expect the team to deliver a successful project by working without interacting with me and the client to acquire the domain knowledge that is needed? If you want the client and I to leave the team alone, how do you expect the team to even know what the client actually wants? The project is a large project; we are refining the specs as we go along. These are not rhetorical questions. I await your answers.

> Were they a great manager simply because they let you do what you wanted, without any deeper guidance or feedback?

Why do I get the feeling you're a technical manager trying to rationalize why you don't trust your developers?

The entirety of your second paragraph speaks to a belief that developers can't manage themselves. That without a manager, no work would get done and no software written.

But having been in this game for roughly 25 years now, I promise you I know how to get software written successfully. What I need is the manager to __believe and trust__ me when I tell them something. There's a vast difference between a negotiation to figure out what can be done in the next 2 weeks and arguing with a fuckwit who thinks they know better than you despite moving into management after 2-3 years of software development.

Most managers I've known would love to have someone to "believe and trust" to delegate stuff to.

I feel like the micromanaging managers simply don't have enough work to do? I personally celebrate everytime I find a developer who can manage themselves, their work, and if they can also manage the team (at least partly) that's amazing!

Desiring a coworker you can trust and trusting the coworker you have are too very different things.

I'd love to be a good person, but these pies aren't going to steal themselves.

> Why do I get the feeling you're a technical manager trying to rationalize why you don't trust your developers?

Because you're not reading my comment carefully, and ignoring the caveats I've put in my comment (it's a problem I've noticed with communication in general; people respond as if I don't mean them).

This is what I said: > On a basic level, yes a manager needs to have reasonable trust in his team members and be able to interact with them well.

So I do agree that trust is important. Feedback and guidance is not about lack of trust, and I'm not sure why you're confusing the two.

For what it's worth, I prefer a manager who is engaged with what I'm doing, not micro-managing me, but helping me to align my efforts with the overall picture.

> and I'm not sure why you're confusing the two.

pegged you correctly.