Business
Building the killer development team
The process of building a strong software development team isn’t always an easy one. It’s important to have a good strategy in mind when assembling your team.
The process of building a strong software development team isn’t always an easy
one. You may have a few players that are available to you on the bench, or you
may need to build a totally new group. There will be fires to put out, decisions
to make, and deadlines to meet. It’s important to have a good strategy in mind
when assembling your team. Having been in this situation many times, I’ve
developed a set of rules that have helped me put together teams that
successfully deliver quality, innovative software.
Draft like the NFL
There’s a draft-day saying in the National Football League that you don’t draft for a position, you draft the best athlete available. In football terms, if you need a quarterback, but the best athlete available in the draft is a wide receiver, you take the wide receiver. For a software development team, you look for the smartest developers you can find, not necessarily the developers who just have a skill you require to do a particular job. The great thing about smart people is that they can contribute more than just code to a project—they offer ideas, they fix bugs, and they increase the overall likelihood of success. Don’t get me wrong—if your project has a particular area that requires a narrow skill set that few have or can easily obtain, then you need to hire the smartest person you can find with those skills. But in general, a software developer who is intelligent and can understand the big picture and contribute to it will be much better than one who has a few extra years of coding experience.
Find out if potential team members are up to speed on recent technologies
I’ve always been awed by the lack of depth in most job interviews. In many places, if the candidate can say enough of the most popular acronyms (XML, HTTP, SOAP, etc.), he or she can get a job. I’ve never been content with that approach. I believe it’s important to structure a job interview in such a way that you really find out how a developer is going to perform. My technique is the whiteboard test—hand the candidate a whiteboard marker and ask him or her to solve a problem. Sometimes that problem is a coding problem; sometimes it’s a discussion of an algorithm. The problem description is generally vague enough that it requires some discussion, giving you more insight into how this person thinks.
The candidate will be under some stress and pressure to perform in this situation, not unlike what generally happens a day or two before something is due; you’ll have a good opportunity to see how they perform in these circumstances. This approach will help you find the smartest people.
Identify your go-to people
When assembling your team, it’s extremely important to include people whose skills complement your own. If you are a technical managerial type, you may need to find someone who will help you organize. If you are less technical, you may need to hire someone who is more so. This approach is fractal. At every level of the development team, those who lead need to surround themselves with people who complement their skills. In my case, I’m very technical, but I tend to operate at the software architecture level. To complement my skills, I look for right-hand folks who are more detail-oriented when it comes to design. I also look for folks who are very aware of project deadlines and can keep others on track. This is a key aspect of teamwork—matching complementary skills.
Fear not the prima donnas
This probably runs counter to many other philosophies. I don’t mind prima donnas in my development team as long as they can back up their attitudes with corresponding contributions. As the manager of the development effort, my job is to smooth out the rough spots and keep everyone moving in the right direction. I’ve always been willing to put in the extra effort it takes to make a team of “hotshots” successful. As a habit, I warn new hires that they are about to be tossed into group of developers who live, eat, and breathe software; non-contributors on my development teams stick out like sore thumbs and are not tolerated by their peers.
Expect creative flare-ups
Garry Trudeau commented in an early Doonesbury cartoon that beneath the cool exterior of a football huddle lurks the dynamics of a kindergarten classroom. The same could be said for some development teams. It’s unrealistic to expect that everyone will get along with each other all the time. In fact, it’s a problem if you don’t have occasional flare-ups and shouting matches. If everything is churning along happily with no serious discussions or arguments, then your team isn’t producing the kind of intellectual creativity that you need to be truly successful. The best teams have individuals who take great pride in their work and ideas and aren’t afraid to express them. The ensuing arguments must be managed carefully, but the outcome is greater respect within the group and new ideas and concepts that may not have been previously considered.
Don’t be a cheapskate
When it comes to purchasing a new tool or new piece of equipment, I always assess both the item to be purchased and the reason behind the request. If it’s something inexpensive and the request isn’t capricious, I’ll go to the ends of the earth to make the purchase happen. Why? Developers, in general, like tools and gadgets (so do I!) and if someone feels that something inexpensive will help them become more productive, it almost invariably will make them more productive, whether or not the tool actually works.
For more expensive items, it’s worth having a serious discussion about the request; don’t blow it off by asking the person to send you a written justification before having the conversation. Understand the request, look for alternatives, and discuss the pros and cons. Your team will respect you more if you treat their requests with the same regard you’d expect for your own requests.
Be a firefighter
Every software development project is going to have problems. If you want to be successful, you need to be able to put out the fires as they occur. My best advice is to roll up your sleeves and dig into any problems yourself if you can. If the problem gets too deep for you to handle, call for reinforcements. I’ve earned more respect from my team members by sitting down at a debugger and trying to figure out why something was crashing than from many other actions I’ve taken. Don’t let the fires sit and expect them to burn out by themselves; you may end up with a wildfire if you do. Serious bugs, crashes, memory leaks, unstable code—these are all problems that demand serious and immediate attention. They prevent members of your team from completing the work they’ve been assigned. Put these fires out as soon as you can.
Keep individual success in mind
The funny thing about a team is this—if the individual members of the team are successful, then so is the team, generally speaking. Each individual must be given the opportunity to succeed and be recognized for it. People feel good when their work receives the recognition it deserves. A team is defined when the collection of individual contributions adds up to a successful project. As a manager, you must be sure that each person is successful. This means that you must define what each person is expected to produce and help team members when they run into trouble. Challenge your people to keep up with the most experienced and top players on the team, and reward them when they do.
Wrapping up
This approach may go off the beaten path, but it provides results. Many managers tend to avoid conflict and tough issues, but I believe that the successful development groups tackle them head-on. Conflict avoidance leads to sub-par teams with members who are content to do the minimum amount necessary. I prefer the teams whose members challenge each other to be better at what they do and are driven to that success. Those teams build great software and great products.
Draft like the NFL
There’s a draft-day saying in the National Football League that you don’t draft for a position, you draft the best athlete available. In football terms, if you need a quarterback, but the best athlete available in the draft is a wide receiver, you take the wide receiver. For a software development team, you look for the smartest developers you can find, not necessarily the developers who just have a skill you require to do a particular job. The great thing about smart people is that they can contribute more than just code to a project—they offer ideas, they fix bugs, and they increase the overall likelihood of success. Don’t get me wrong—if your project has a particular area that requires a narrow skill set that few have or can easily obtain, then you need to hire the smartest person you can find with those skills. But in general, a software developer who is intelligent and can understand the big picture and contribute to it will be much better than one who has a few extra years of coding experience.
Find out if potential team members are up to speed on recent technologies
I’ve always been awed by the lack of depth in most job interviews. In many places, if the candidate can say enough of the most popular acronyms (XML, HTTP, SOAP, etc.), he or she can get a job. I’ve never been content with that approach. I believe it’s important to structure a job interview in such a way that you really find out how a developer is going to perform. My technique is the whiteboard test—hand the candidate a whiteboard marker and ask him or her to solve a problem. Sometimes that problem is a coding problem; sometimes it’s a discussion of an algorithm. The problem description is generally vague enough that it requires some discussion, giving you more insight into how this person thinks.
The candidate will be under some stress and pressure to perform in this situation, not unlike what generally happens a day or two before something is due; you’ll have a good opportunity to see how they perform in these circumstances. This approach will help you find the smartest people.
Identify your go-to people
When assembling your team, it’s extremely important to include people whose skills complement your own. If you are a technical managerial type, you may need to find someone who will help you organize. If you are less technical, you may need to hire someone who is more so. This approach is fractal. At every level of the development team, those who lead need to surround themselves with people who complement their skills. In my case, I’m very technical, but I tend to operate at the software architecture level. To complement my skills, I look for right-hand folks who are more detail-oriented when it comes to design. I also look for folks who are very aware of project deadlines and can keep others on track. This is a key aspect of teamwork—matching complementary skills.
Fear not the prima donnas
This probably runs counter to many other philosophies. I don’t mind prima donnas in my development team as long as they can back up their attitudes with corresponding contributions. As the manager of the development effort, my job is to smooth out the rough spots and keep everyone moving in the right direction. I’ve always been willing to put in the extra effort it takes to make a team of “hotshots” successful. As a habit, I warn new hires that they are about to be tossed into group of developers who live, eat, and breathe software; non-contributors on my development teams stick out like sore thumbs and are not tolerated by their peers.
Expect creative flare-ups
Garry Trudeau commented in an early Doonesbury cartoon that beneath the cool exterior of a football huddle lurks the dynamics of a kindergarten classroom. The same could be said for some development teams. It’s unrealistic to expect that everyone will get along with each other all the time. In fact, it’s a problem if you don’t have occasional flare-ups and shouting matches. If everything is churning along happily with no serious discussions or arguments, then your team isn’t producing the kind of intellectual creativity that you need to be truly successful. The best teams have individuals who take great pride in their work and ideas and aren’t afraid to express them. The ensuing arguments must be managed carefully, but the outcome is greater respect within the group and new ideas and concepts that may not have been previously considered.
Don’t be a cheapskate
When it comes to purchasing a new tool or new piece of equipment, I always assess both the item to be purchased and the reason behind the request. If it’s something inexpensive and the request isn’t capricious, I’ll go to the ends of the earth to make the purchase happen. Why? Developers, in general, like tools and gadgets (so do I!) and if someone feels that something inexpensive will help them become more productive, it almost invariably will make them more productive, whether or not the tool actually works.
For more expensive items, it’s worth having a serious discussion about the request; don’t blow it off by asking the person to send you a written justification before having the conversation. Understand the request, look for alternatives, and discuss the pros and cons. Your team will respect you more if you treat their requests with the same regard you’d expect for your own requests.
Be a firefighter
Every software development project is going to have problems. If you want to be successful, you need to be able to put out the fires as they occur. My best advice is to roll up your sleeves and dig into any problems yourself if you can. If the problem gets too deep for you to handle, call for reinforcements. I’ve earned more respect from my team members by sitting down at a debugger and trying to figure out why something was crashing than from many other actions I’ve taken. Don’t let the fires sit and expect them to burn out by themselves; you may end up with a wildfire if you do. Serious bugs, crashes, memory leaks, unstable code—these are all problems that demand serious and immediate attention. They prevent members of your team from completing the work they’ve been assigned. Put these fires out as soon as you can.
Keep individual success in mind
The funny thing about a team is this—if the individual members of the team are successful, then so is the team, generally speaking. Each individual must be given the opportunity to succeed and be recognized for it. People feel good when their work receives the recognition it deserves. A team is defined when the collection of individual contributions adds up to a successful project. As a manager, you must be sure that each person is successful. This means that you must define what each person is expected to produce and help team members when they run into trouble. Challenge your people to keep up with the most experienced and top players on the team, and reward them when they do.
Wrapping up
This approach may go off the beaten path, but it provides results. Many managers tend to avoid conflict and tough issues, but I believe that the successful development groups tackle them head-on. Conflict avoidance leads to sub-par teams with members who are content to do the minimum amount necessary. I prefer the teams whose members challenge each other to be better at what they do and are driven to that success. Those teams build great software and great products.