The secret to being a Big Swinging Developer is to be a force multiplier; make other people more valuable and you become incredibly valuable. Don't believe me? Which do you think is worth more: improving your own effectiveness by 50%, or improving 10 people's effectiveness by 10%?
There are several ways to improve others' effectiveness: tools, techniques, processes, infrastructure, the list goes on. The most direct way, however, is if you're the manager or team lead. If you've never lead a team before, or are afraid that you're bad at it, here is a dead simple guide to get you started or turn things around.
Step 1: Find out what success looks like for you & your team.
Your team exists for a reason. It's there to build features, or test stuff, or support a system that's in production. Whoever signs your check has a vision for what makes you and your team valuable and what success looks like for you. And if they don't? Easy, you find out elsewhere. There are only 3 ways to provide value to an organization: increase sales/revenue/demand, decrease costs (aka increase efficiency and output), or decrease risks. Your team is responsible for one of these, guaranteed.
Step 2: Determine how each team member can be valuable.
Remember in step one where I said, "Whoever signs your check has a vision for what you valuable"? Well, you're that "whoever" for each of your team members. Even if you don't actually sign their check, you are responsible for knowing what each person can do to be valuable and then communicating that clearly. NOTE: This is the hardest part of management. If you know what someone can do to help out and can communicate that clearly, you have it made.
Step 3: Monitor.
Lack of monitoring is the Heart Disease of management: It kills more teams more quietly than anything else. Even worse, lack of monitoring can look like so many other things. You see, one of the problems with organizations is that they're dynamic. If you're not monitoring what they need, you may find yourself doing what you've always done and unemployed because that's not what's needed anymore. Or you may do what you think is a great job of communicating to your team what you want them to do, but if you don't monitor them and provide course corrections then they could end up working really hard on something that you don't need.
If you put those 3 steps in an infinite loop, you can successfully manage teams for the rest of your career. If you need more supporting evidence, look around where you work for teams who are struggling and you'll probably see lack of monitoring, poor communication, or lack of vision.
That covers the basics of running just about any team. Next time I'll talk about how to build a really kick-ass team.
I'm not big on resolutions, but every now and then I realize that something has to change.
In December of 2006 I started having the "something has to change" feeling. My career was going pretty well, but I always felt bogged down. I started thinking about what was in my way and I came to the conclusion that I was wasting time fighting with co-workers. It wasn't always head-on "2 developers enter, 1 developer leaves" Thunderdome style fighting, but it was fighting nonetheless.
I made a resolution to be more positive.
After telling one of my close colleagues about my resolution he replied, "Dude, you can be as optimistic as you want, this place isn't going to change."
I explained to him that I wasn't going to be more optimistic, that optimism is something you feel and it's VERY difficult to change how you feel. Instead, I was going to be more positive. Regardless of how I felt, I was going to look for the most positive action I could take and pursue it even if it went against my emotions at the time.
It was hard.
It was worth it.
The first month or two were difficult. The most positive action I could think of most of the time was to be quiet. To simply not say any of the cynical, cutting, or downright mean things I was thinking (regardless of how funny they were). A wonderful thing happened: Things stopped getting worse. When an argument or flame war broke out, I no longer made it worse. Things not getting worse is a huge step to them getting better.
My colleague was right: that place didn't change, but I did. In my next gig (where I am now), I practiced staying calm and taking positive action. I can assure you that after 2 years it is not only easier, but it is worth it. I would never have been able to advance to where I am now without my resolution in late 2006.
Being a Big Swinging Developer is about how you act regardless of how you feel. You are paid for your results and I can promise that you will get further faster if you start by being more positive. Give it a try and your workdays will be happier and more productive.
Early in my career I learned that there are 3 types of value to an employer:
Increase revenue (grow the top line)
Decrease expenses (grow the bottom line)
Reduce risk
In an ideal world your employer would understand and value all three equally and you'd be free to pick and choose what you work on in order to be most valuable. Even if your employer could choose to be that balanced, the market wouldn't let them. Instead, you have to read the tea leaves (or the corporate memos) to figure out what's what. If you align what you're working on with what's most desired, you're in for a Big Swinging Payday.
Alright, that's the general rule. Let's get a little more specific for the folks out there who write software for a living. There's a development analog for each of the 3 types of value listed above. In matching order they are:
Increase capabilities
Decrease effort
Improve process
You increase your capabilities (and those of your group) by learning new technologies and tools. This increases the range of what you're capable of delivering. There are times when providing what couldn't be done before is incredibly valuable: typically at the start of a project or during project turnaround. At the beginning there's a much better chance that new capabilities can be incorporated into the project. This also happens when the project hits a, "We've got to change because what we've been doing isn't working" point. Another way to look at it is that if things are moving along, don't risk getting in the way with offering something new.
You decrease effort by bringing efficiencies to the group that either didn't exist, or were poorly exploited. The simplest way to do this is to automate the living daylights out of everything you can. Automated builds, testing, documentation, etc. will help developers focus on the things that only they can do: write code to solve problems. This doesn't mean that developers will end up working less, it means that given the same amount of time/effort they will produce more. This is easiest to do at the start of a project (before things get messy), but is actually more valuable in the middle once bad habits and thrashing have begun.
Improving the development process is almost always valuable, but becomes particularly important between the middle and the end of a project. This is due to the fact that from the middle to the end is the time when the project needs to be set up for maintenance mode. If you wait until the end to do that then you won't have nearly enough time to get everyone used to the process. In addition, from the middle to the end is when people will be rolling off the project and the level of talent should be constantly increasing until right before the end. This is not to say that process isn't important until the middle. Chances are that when a project starts there will be a period of process development that lasts the first quarter of the overall time. Then people settle into a groove and crank things out for a while until they hit the halfway point, when it becomes time to plan for the end of the project. By improving the process, you make development more predictable which lets those around (and above) you plan better and control the end-of-project glide path.
Notice that I'm talking about relative value at specific points the the project's lifetime. All of these things are valuable and you'd be well off learning how to bring any of them into your organization. If you want to really capitalize on them, though, take a look around and align what you're doing with what's most needed.
I recently had a chance to discuss the role of centralized architecture with a colleague. When I say "centralized architecture", I'm talking about a group usually found in large companies that is responsible for technology standards across the organization. In talking with developers over the past several years, I've seen the full spectrum of opinions on central architecture groups: At one end you have the developers who are appreciative of the architects hammering things out so that the organization has a common direction. In the middle you have the folks that have heard such a group exists, but isn't exactly sure what they do. At the other end are the developers who see the group actively impeding their progress.
Given the wide range of opinions and reactions to the architecture function, I started thinking about what I would want such a group to do. I finally boiled it down to this:
The role of central architecture should be to balance the desires of the organization with the desires of the developers.
There are plenty of places where the desires of the organization and the developers are aligned. The org wants some software, the developers want to write it. But from there, things get a little tricky. The org prefers to standardize on certain products in order to reduce cost and simplify maintenance. Developers want to use whatever they want to use. Developers focus on their system, or part of the system. The org sees their system as part of a larger system and wants to make sure it can talk to everything else when need be. The list goes on and on, but an architecture group can resolve these differences by providing the structure with which technology gets built. Not only that, they can help developers work outside of the general structure when it makes sense to do so and provide tools that make staying inside the structure desirable.