A friend of mine just asked if I had any advice for a person who’s just starting his first management position at a startup. Even though I have minimal management experience myself, I’ve been in all sorts of work environments, including a startup that grew from 40 people to 150 people and went bankrupt a year later, so I’ve seen a variety of managers and management strategies. I thought I’d share my advice here, even though I’m still learning to apply these lessons in my own nascent career as a manager.
- Your responsibility as a manager is to make your group as productive as possible. You are a shield for your group, protecting them from the rest of the organization so they can get things done.
- You go to the strategy meetings and sit for two hours, so that your group can be working during that time and get your two minute synopsis later.
- You deflect requests from the rest of the organization that will distract your people.
- You deal with schedules and Gantt charts and requirements documents because upper management wants those things, and your group’s time is better spent actually doing work on the project.
- If you’re a manager, be a manager. If you are trying to do anything technical while you’re a manager, you’re probably making a mistake. Your job is to be the interface of the group to the rest of the organization – give the technical tasks to the people you hired to do those tasks.
- There’s no such thing as authority. You can’t be granted authority by your bosses, no matter what the org chart says. To be a good manager, you have to earn the trust and respect of your employees and coworkers and bosses. If you have the org chart position, but not the trust that goes with it, you will be circumvented and undermined at every opportunity. You have to earn the respect of the people working for you by doing the things in point 1 above to make their lives better. To earn the respect of your bosses, your group has to consistently deliver what you say it’s going to deliver.
- Keep the lines of communication open. You can’t do your job as a manager if you don’t know what’s going on. If something is going wrong and your team won’t meet the schedule, they have to trust you enough to tell you so that you can do something about it. You also have to know what’s going on in the rest of the organization that might affect your group. This means you should be spending a lot of time talking.
- Fight the battles that are worth fighting. When I was younger, there was Right and Wrong, and when something was not Right, I attacked it with all guns blazing. I once ended up in an email flame war with the CEO over a topic that’s so stupid I can’t even bear to repeat it. It’s rarely good when the CEO starts an email with “I don’t know what the hell you’re smoking…” Save your social capital and your energy for the battles that are important, and let the other things slide. If your boss wants reports indented in a certain way, just do it – your credibility isn’t worth losing over that. If your boss wants your group to produce on a completely unrealistic timeline, that’s when you fight.
As an aside, I highly recommend picking up the book Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp. Lopp writes at Rands in Repose and the book is a collection of some of his best articles. I really like his advice on how to be a good manager, and much of what I suggest here is similar to the advice in his book. You can browse around his website instead, but I found the book form factor to be better.
8 thoughts on “Advice for managers”
Good advice! I also learned #5 the hard way, though it sounds as if your way was harder 🙂
Personally, I would soften #2. Especially in a startup environment, it can be important for team morale and overall productivity to chip in with technical duties when your team is overwhelmed.
Since you have fewer people and less process in a startup, conversations go a long way and it’s often possible to take care of the purely managerial responsibilities in say 2/3 of your time, leaving time to fill gaps. I generally kept my eye out for simpler, shorter tech duties that I could squeeze in between other items, which also worked nicely because these were often though of as busy work by my team so they were excited to do meatier things. While this approach might be problematic for those that believe in top-bottom authoriteh (too ego threatening to take the easy bits), it goes a long way toward building a cohesive team that will be honest enough with you to let you help them be more effective.
“Thereâ€™s no such thing as authority. You canâ€™t be granted authority by your bosses, no matter what the org chart says.”
Ooh! But those are two different statements. You’re thinking “authority” as in “hierarchy” but there’s also “she is an authority on X” or “he wrote the authoritative Y” and those are positions within, not above, a productive community. “Luckily, my boss has the authority to tell [executive pain in the ass Q] that we’re not going to do his project.”
I think this also relates to your #1; you tend to describe all of those interface / high-level / organizational tasks as busywork or even bullshit, from which you shield your team. But they can also be the product of a broad vision, so that you advocate for your team while understanding–for instance–how your team will benefit from ceding resources to another related group. (That’s different from “I gave them this so they’d give us that,” too.)
Oh, and if it’s not totally obvious: a lot of my thinking about authority changed when I started teaching. My instinct is to be cooperative and egalitarian but that is so, so, so much harder for the students. Sometimes the right thing to do is to tell them the answer, and to do that you need to create an authority figure (which, of course, has to be earned) so they’ll believe what you tell them. Not everything is best derived from first principles.
Following along Jessie’s second comment, I got a couple minions (student assistants) last summer, and in retrospect, I think I should probably have acted more authoritatively than I did. (Which was basically not at all — I was very “well, what are you comfortable doing? Do that.”)
It was a weird situation, though, because I wasn’t looking for them, and I wasn’t involved in the hiring process, they were just kinda handed to me. So I didn’t really feel like I had any right to be particularly demanding about what they produced. Plus, I didn’t want to be demanding or pushy anyway. And double weirdness with the coder, who has worked here for longer than I have, but left to go back to school, and was also managing a project with a million-dollar budget at the same time. And was theoretically a great Java coder, but I think was just a lot more familiar with all the Java libraries and suchlike, and not actually as good at structuring and thinking about code as I am. Knew lots of things I didn’t; didn’t write code that was as good. Okay, that might count as triple weirdness.
“Here, these people are reporting to you!” Yeah, a very awkward “management” position to be in.
I will note, though, that I’m finding a lot of stuff like this that I read on management very useful for self-managing as well.
I should have known that making unqualified statements would get my friends to comment.
Roopa: I agree you shouldn’t hold yourself “above” doing coding. But the instinct of mostly newly minted technical managers is to keep doing technical things, and to avoid the new stuff they don’t understand. So if I’m giving advice, I need to overcompensate for that instinct.
Jessie: Sure, there’s such a thing as authority derived from excellence, but that’s rarely the type of authority exerted in the workplace. New managers are the ones most likely to actually believe the org chart, not realizing that they have to earn their nominal position. Oddly enough, your husband convinced me of #3 at Compadre’s when he was describing how he got promoted to VP.
And I agree that there are productive aspects to those meetings, but technical people often don’t know or don’t care about those aspects and just want clear specifications to work from. There’s still work to be done to convince them of the importance of stuff they perceive as “busywork” though.
Beemer/Jessie: There are definitely times when it is appropriate to just tell people what to do, especially when dealing with undergrads. But one of the reasons #3 is so important is that for those who don’t go to grad school, there’s no initiation into independence. Kids graduate from college, get a job and expect people to keep telling them what to do. They treat the management hierarchy as if it were divinely ordained, because they’ve never lived in a non-hierarchical environment – there’s always been an authority figure in the form of a parent or teacher or professor. Realizing that managers are just people too is a big step in taking control of one’s work life.
Hrm. Maybe I should follow this up with a real post.
I normally look at number 3 from the opposite direction.. you can’t be given “permission to manage” by anyone other than the person you are trying to manage. How you get that permission from a new managee really depends on the people involved.. for young pups it is just automatic.. for old cynical folks it normally takes a bunch of effort in understanding how you can, as a manager, help them succeed and then walking that walk.
I disagree strongly with “there’s no such thing as authority”. It definitely does. But it is a big ugly stick that often causes collateral damage rather than furthering item 1. Knowing when to use your authority is one of the keys to leadership and management. Bad managers tend to either never use it or use it too much. The great managers out there strike the right balance.
The one thing I would add (thought you touched on it) is your job is also to make your people as comfortable as possible. I’ve spent many late nights at the office refilling water glasses and buying dinners to help people. I say if sweeping the floor under someone’s feet makes their job easier, sweep the floor.