As some of my readers know, I’ve taken the last year off from the corporate world. I’ve done some things on my own, sold some things on eBay, and worked as a contractor for a mining pool. Now that I’m back into interviews, one thing I get asked more than ever before is about my management style.

I prefer to think of it as a management mindset, as the style would adjust to each minion’s needs and “work language” for lack of a better term. And despite relatively little formal management training, I’ve come to a coherent and occasionally appreciated position.

You can only be as good a manager as your manager is to you.

A large part of team management is proxying in both directions between the people who report to you, and the person or people you report to. Your reach and control is probably limited — you can’t usually spend more than the budget allows on salary, or eliminate 7am calls for your west coast team because a manager three levels up wants 10am meetings from his east coast office.

But on a more granular level, if your own manager isn’t supportive of what you need for your employees, there’s only so much you can do to make that happen. This is often because your manager’s manager is limited, and on up many levels.

This can be an uncomfortable maxim to present to a prospective or current manager, as some will take it as a personal affront. But good managers (leaders) will understand that it’s reality, and they can’t do more for you than their manager permits (generally speaking). They probably know it even if they haven’t specifically thought about it.

It’s also worth noting that giving someone the title “Leader” doesn’t make them one. An image search for “boss leader” will give you the usual comparisons. That’s not to say a leader can’t have the title or epithet “Leader;” it’s not a measure of minion count or organizational rank, but rather an indicator of their behavior and impact on those they lead.

Your experience as a managee should inform your methods as a manager.

This applies beyond the workplace, but since most employees spend more time as employees than as managers, you probably know what works and doesn’t work for you, what motivates or demotivates you, and what you wish past managers had done differently.

As a manager, subject to the first element above, you should consider what you need/needed as an employee and provide it to your employees. But of course, verify that it works for them, and if not, dig further into what they need from you – you’d want your manager to do that for you.

You may find this perspective useful in limiting churn in your team. People usually leave because of a boss, not because of the company or the work itself, as many studies, anecdotes, and articles have suggested. Think about what inspired you to leave companies in the past, and avoid those things in your own managerial role (easier to say than to do, but it’s worth aiming for).

And speaking of beyond the workplace, you can think of this whenever dealing with people who are in roles similar to what you’ve done in the past. I take this perspective when dealing with tech support, because I remember the bad and unactionable requests and the helplessness I felt when the customer wouldn’t help solve (or even identify) the problem, and my boss was more focused on closing the ticket, getting off the phone, or getting to an easier-to-solve request. My current support role doesn’t have this issue, but

A brief detour for a story from the 90s.

The title of this post calls back to my second Silicon Valley job, and a day when a core server for my 100+ engineers was down.

I was on the floor in the server closet behind a Sun Enterprise 450 server, probably an hour into the remediation, when my boss came into the room holding a note paper cube (from the contract firm I was placed by) bearing photos of disasters from history on all four sides (including Hindenburg and Titanic–I don’t remember the other two). The legend at the bottom of each side suggested calling the contract firm to get people to repair and avert disasters.

He showed it to me, said something like “look what your people sent over. Good timing, right?” I agreed, it was auspicious. He asked if I needed anything from him, I said no and told him it was about fixed, and he left. I checked in with him later when the problem was resolved and his engineers were back to work.

The best managers are there when you need them, and out of the way when you don’t.

The best managers I’ve worked for, the most inspiring and productive and influential ones, were there when I needed them. Whether it was resources, connections, feedback, a break from something, career advice, tips on picking a propane smoker, and so forth, I could count on them to provide what I needed from them when I needed it (subject to the previous two maxims, of course).

But when I was doing my work, whether supporting engineers or partners or colleagues, building collateral and content, doing training, preparing for events, and so forth… they would be out of the way. Sometimes that even involved actively removing or deflecting obstacles, but sometimes it was just setting expectations quickly and then reconnecting later.

They understood that they (or their predecessors) hired me to do certain work because I could do it and was good at it, and would enable me to do it rather than preventing me from doing it.

I’ve also worked for managers who felt that if you were working on something critical, whether an outage or a major project, the most helpful/useful thing to do would be to interrupt you regularly to check status, offer criticism, and impair your efficiency.

This often came with other forms of micromanagement, like reviewing daily backup logs line by line, requiring frequent reports that nobody would look at, and so forth. Think Mordac, the Preventer of IT, from Scott Adams’s Dilbert comics. Or Lumberg from Office Space. The daily backup logs manager actually thought Lumberg was an inspiration rather than a cautionary tale. No joke.

If you’re managing people you hire, you probably hired them for a reason. If someone else hired them, they probably did the same. Let them fulfill that reason as best they can, and everyone looks and does better.

Where do we go from here?

Well, with the holiday break coming up, probably not too many interviews, but I’ll be watching what’s out there and preparing for what comes next. Sixteen node Kubernetes cluster maybe?

What tips and mindsets do you have around management in the tech world? Share in the comments please.

Updated 2022-09-02: Nobody mentioned that I misspelled Hindenburg in the headline. Oops.