Hacker News Reader

The best-liked and most effective managers that I have worked with did not always show support for the company's decisions. Instead, they would say "we have to do this, but: (1) here is how I can make it as painless as possible for you (2) here is how we can make sure that you still achieve your personal objectives"

Sometimes (depending on the sensitivity of the issue) they would also tell the team what they were doing to try and get the decision changed.

I have been fortunate to work places where the higher levels of management welcomed dissenting opinions - maybe that is one of the key bits to look for when determining if a (traditionally-structured) company is a good place to be a mid-level manager.

Agreed - I don't think that all honesty has to go out the window just because you are in a management position. Communicating decisions is one aspect, but effectively implementing them in your team is a whole other thing. Honest discussion of concerns and what can be improved is important, and as much as management likes to think their poker face is awesome, employees are smart and see straight through bullshit.

Secondly, what I heard in your comment (and agree with) but don't see in the original post is anything about engaging to be an advocate for your employees up the chain, giving them an opportunity to tell you what they need, the questions they have, the things you can do. To a certain extent this might make you lonelier on the "who do I talk to?" side, but helps a great deal as a reminder of the purpose of the job.

For a middle manager running a technical unit the job is often to serve as a buffer between upper management and workers. This doesn't necessarily involve lying to people but rather focusing on different priorities with different groups.

A middle manager is two APIs: one for upper management to interface with the workers, and one for workers to interface with upper management. The two APIs have distinct areas of responsibility, but both of them should include sanity-checking on their inputs rather than just passing them on to the layer above/below, and sometimes they should definitely throw exceptions.

This is what makes middle management a difficult role: it is literally two-faced. Internally, however, there should be a single state machine that maintains some kind of consistency, balancing the current corporate direction with the well-being of team members and the desired career track of the middle manager.

Unfortunately the ideal balance often involves all parties being about equally unhappy.

> Middle managers have to not just follow it, but enthusiastically agree with it.

Reminds me, when I was offered such a job by my boss and didn't get it, because the rest of the management team didn't think I was "loyal" enough.

I never heard such a justification for positions I had before.

Most of the time people give me jobs because I knew to do something they didn't or didn't have the time to do it on their own.

In the end some "more loyal" person got the job. And I thought, oh so they really just wanted a person who didn't disagree with them...

I believe the job of a manager is to be effective, not to be right. If you feel compelled to disagree then you may be more worried about being right than effecting positive change. Of course you must engage with the institution and the choices it makes – but in my experience there are usually better ways to do that than disagreement.

It is hard to be effective if your reports don't trust you.

I was doing that when I was a engineer. Work around their crappy ideas. My idea was that I could openly disagree with them, when I was on a higher position. But seem's I was wrong :)

Well, in the end I packed my things and left.

> Middle managers have to not just follow it, but enthusiastically agree with it, even if they think it's stupid or counterproductive.

Clearly, my colleagues and I are doing it wrong, then. If you enthusiastically agree with everything the higher levels hand down, you are completely superfluous. In any decent organization, it is your job to disagree when necessary.

You are higher up than your reports, so you have a bit more context that helps communicate/explain things that come down from "on high". At the same time, you're still close enough to the trenches that you can speak up about issues that just weren't visible at the level above you.

Yes, ultimately higher management can override all your decisions. But if they are any good at their job, they listen to your input. That's the whole point of having layers of management - separate abstraction levels, and the ability to communicate important concerns up and down the abstraction ladder.

Yes, the manager who's just the megaphone to "his master's voice" is a common pattern, but it's not the pattern of a good manager. The same way that the copy/paste "programmer" is a common pattern, but not the pattern of a good programmer.

I'll add that those decisions I have to support as a manager are not necessarily wrong, but I am limited in the tools to even analyze them. Or at least in the past, in the face of a challenging problem with no right answer, my tendency would be to discuss, to put forward an opinion, to see feedback and challenges to that opinion, etc. And to watch other people doing the exact same thing about other hard problems, often saving me the effort. Good decisions coming from above don't relieve me of the need to understand and assimilate those decisions.

On the positive side, when I do have the opportunity to assimilate those decisions and the motivations behind them, I feel suddenly far more powerful – then I can engage positively both up the chain and down. Which makes the impasse a middle manager so often finds him or herself in so disappointingly counterproductive – my imaginative self feels there must be another way.

One way to address this is to have an explicit commitment as an organization that managers at all levels will regularly explain to their teams the context in which their piece of the organization is operating, and a process to make that happen.

[This is a concept I first heard about in Elliot Jaques' thinking around what he calls Requisite Organizations... I don't agree with all of his thinking, but this context-setting piece has always seemed crucial to high-performing larger organizations]

This has two big benefits: first, it should make it easier to assimilate higher-level managers' decisions and understand the motivations behind them and second, it puts everyone in a position to make better-informed decisions on their own.

As a simplistic (and not particularly realistic) example, if I am a dev manager trying to decide whether to devote time to new feature development or a refactoring effort, making the 'right' decision is dependent on knowing whether we have things in place to put a marketing push behind new features and generate new sales, whether we are at risk of losing existing customers due to latency issues that the refactoring would resolve, etc.

If the right context-communication process is in place, I know that answer and can easily both make my decision and communicate to the team why it is the 'right' one.

When I was a middle manager, I never had a problem implementing decisions I didn't believe in per se. Reasonable people can disagree on strategy and tactics without having to sell their souls.

On the other hand, I had all kinds of problems working for upper management I didn't believe in. When I didn't trust the folks above me, it was very difficult for me to implement even fairly benign changes.

Lower level employees (should) expect to have a relationship of trust with their manager. The manager should trust that the employee is capable of doing the work the employee was hired to do and that the employee is comfortable raising issues with that work to them. The employee should trust that the manager respects their competence and will take every effort to maintain a suitable environment for them to do the work.

Middle management should also have this relationship with the upper managers. Upper management should trust the middle managers are capable of leading their team and will raise issue doing so with them. Middle management should trust that upper management respects their ability to understand the needs of their team and will take every effort to maintain a suitable environment for them to lead their team.

The role of middle management is to have relationships on both sides. If middle management is lonely this chain of trust is broken.

This is an undoubtedly challenging position to be in because they are required to maintain relationships on both sides and the trust of each relationship must go both ways. If middle management is unable to express their concerns to upper management, either because upper management doesn't trust the middle manager is raising a important concern or because the middle manager doesn't trust upper management will listen (or raising the issue will threaten their career), they do not have a relationship of trust. The same goes for middle managers and their employees.

But my job can suck too. I've have also been asked to find solutions to problems with variables outside of my control, or take on a project bigger than anything I've worked on before, or to do something outside my experience and knowledge. Two valuable lessons that have come from of these challenge for me have been 1) asking for help and 2) saying no. Both of these lessons are about communication, and communicating with other people is the best cure for loneliness.

This is exactly why I resisted getting into management for a long time while other developers at my level were doing it. They rarely seemed happy or to be in a position I'd want to trade places with.

Right now I have a great position now where I still do a significant amount of development but also have authority and a fancy title and a management structure above me that's mostly concerned with business decisions and lets me make the technical ones. It took me longer to get the title but it was worth it to wait. I couldn't have done it at a large company.

"generally sucks as a job" probably means that someone who is good at it is extremely important to a company's success.

1. Often non-technical people have not the skills and experiences in being good managers to lead engineering teams. 2. Having strong technical skills (engineer or programmer) and then moving into middle management can often help you get buy-in from those above and below you. They may look up to you, ask for your guidance or defer to you decisions.