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.

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.

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.

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.)

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.