"Should I keep doing what I'm doing or become a manager?"
While I hear that a lot from software developers, it's a universal question. Should you practice your craft or become a manager? I'll weigh in with my opinion in a moment, but let me first say that everyone is a manager. As I mentioned in the post Walking the Walk, no one is as interested in your career as you are. By the same token, no one has as much control over what you do as you do. That's right, even if no one else reports to you, you do and that makes you a manager.
Maybe you're just really bad at it.
Just because you aren't managing doesn't mean you're not a manager. We've all had "managers" who don't manage and if you're not consciously and actively managing yourself then you've just joined their ranks. There's some good news though: You don't have to stay that way. As a matter of fact, you can become the best manager that you've ever worked with. There are tons of books on management and I recommend picking one up and applying its lessons to yourself, but here's the short version of what makes a good manager. A good manager:
Knows what needs to be done.
Equips the team with what they need.
Clearly defines success.
Removes roadblocks.
Measures progress against the plan often enough to correct deviations.
Manages up to ensure that the team is making the big boss happy.
Find a manager who does those six things consistently and you'll be incredibly successful in your role. Be a manager who does those six things consistently and you'll be incredibly successful in whatever role you choose. People who can make other people successful are both successful themselves and in high demand.
So start with yourself. Practice those six things on your own work and get good at it. Once you do, then ask yourself, "Do I want to make other people successful, or should I stay solo?" Regardless of the answer, you'll continue to be a manager throughout your career.
Starting a new job is a mixed blessing. Sure there's the honeymoon period where everything is new, excited, and untainted. At the same time, you often feel (and rightly so) that you're slowing everyone down while you come up to speed. Even in places that do on-boarding well — the ones where your computer is ready, your network account is set up, and you get your parking badge day one — you'll still have a ton of questions you need answered before you get started on real work. This is especially true for developers since you'll need to know all about the systems you'll be working on, the build process, version control locations, dependencies, tool chains, and everything else. As much as you need this info, though, it's no fun being the one asking question after question that "everyone" else knows. Wouldn't it be great if you could show up on day one and have the answers to all of the basic questions sitting there for you to read until you know enough to ask good questions? And therein lies the secret:
Volunteer to write the on-boarding manual.
Who else will understand the needs of the newbie better than a newbie? Writing the thing shouldn't be that hard since you'll need to learn everything that it contains anyway. As an added bonus, people will be a lot more tolerant of the constant questioning if it leads to you being the last one that has to ask so many questions. Besides, you can't do anything anyway because you don't yet know enough to do anything. This is beyond "2 birds, 1 stone", this is, "The entire flock, no shots fired".
Now, there may be a few reasons that it doesn't make sense for you to write the on-boarding manual:
You can't write very well.
You don't like talking to people.
It's too much work.
Notice that these are also reasons that it doesn't make sense for you to remain employed.
So the next time you start a new gig, start writing down all of the things that you wish you could have learned without asking. You'll learn more, help the newbies of the future, and actually be able to contribute during your own awkward newbie phase.
Yesterday I talked about the basics of running a team. Today I want to go a bit beyond the basics and talk about how to build a kick-ass team. NOTE: There is an upper bound to your team's ass kicking potential imposed by your organization. This doesn't mean that you can't kick ass, it just means that you are going to have to calibrate your measurements or implode under the weight of your frustration. I learned, for example, that the AKP (ass kicking potential) of a large oil company is lower than that of a small or medium software products company. This doesn't mean that I give up and walk away, I simply have to set my expectations accordingly. With that out of the way, let's get to it.
Step 1: Have it mean something to be on your team.
You need something to make your team swagger. The good news is that there are SO many ways to do this that absolutely every team in your organization can do so without conflict. Swagger is unlimited and does not have to be mutually exclusive. Here are some examples:
You do more work with fewer people than anyone else.
You have fewer defects BY FAR than anyone else. Some number indistinguishable from zero.
You have the best hardware.
You have the worst hardware and still do better work.
You have the best software.
You're faster.
You're more creative.
You generate more revenue.
I could keep going, but you should see the point by now. If it means something to be on your team, people who identify strongly with what you're doing will want to be on your team. Almost as good, people who feel negatively about what your team is doing will stay away. Which brings us to the next step.
Step 2: Prune.
If it's one thing that team leads do poorly, it's prune. If it means something to be on your team, then not everyone will (or should) belong on it. Chances are that someone who doesn't belong will end up on your team and it's your job to fix that. Now, before you start thinking that I'm filled with some sort of managerial bloodlust, let me point out that pruning is a last resort. If someone on your team isn't working out, first assume that it's your fault. Go back to yesterday's post on the basics and make sure that you have all three covered squarely. Then counsel the team member with specific behaviors to change along with measurable steps to take. And, if that doesn't work out, come to grips with the fact that they simply aren't a good match for your team and that keeping them there is a disservice to them, the other team members, the organization, and yourself. Prune so that they can find a place that fits.
Step 3: Be on the lookout for new talent.
You will probably have turnover in your team either through pruning or through your team members kicking so much ass that they get promoted. Always be on the lookout for people who you think would fit, especially people who aren't fitting somewhere else.
Step 4: Replace yourself.
A team doesn't truly kick ass until it can do so without you. If you don't have a "next in line" identified, then you aren't done building your team. Having the team depend on you too much is a risk to you, them, and your organization.
Follow these steps and you can make a career of building kick ass teams wherever you go. Leaving such teams behind when jumping to the next opportunity is the hallmark of a Big Swinging Developer.