Posted on 05/10/2002 8:31:39 AM PDT by bvw
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.
Expect to find and learn to deal with ... bugs (Your own are easier to fix but do more damage to your pride)
Trudeau has obviously never been in a football huddle.
be a cheapskate- lowball all developers except for the ubergeek who you could not do without. Make sure the ubergeek gets all the good assignments and training. Keep other developers in an unmarketable niche. Tell your developers that line employees value non-monetary forms of recognition (pats on the back) while the executives pull millions out of the business.
Make sure that putting out fires is the most valued attribute. Oddly enough you will also have systems that seem to generate a lot of fires in need of being put out.
Have tech managers who have never programmed or who have long retired from programming. Then have these managers make decisions on architecture, technology and design.
Establish deadlines based on arbitrary calendard milestones (Ex: next week, in a month etc...) without any recognition of the actual work involved or resources available.
Make sure that you schedule a half a day for testing, desbugging and deployment.
Pay lip service to design and capacity planning.
Make sure that your testing staff are non-technical holdovers.
Save on labor costs by having your developers do support, network administration and business analysis in their spare time.
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.
If you are still brainstorming a day or two before a project is due, you are sunk. Even as a developer, this time had better be spent running tests on a completed system.
This notion is the reason why so much software sucks. If you spend time thinking and testing, 1) you won't need to spend a lot of time writing a lot of code, and 2) the code you write will be compact and reliable.
Spewing mountains of code quickly is just a waste of everyone's time. You end up with a buggy, impossible to maintain mess.
Testing should be done the day before final release - when it's too late to actually make any changes.
Never let your developers interact with designers or actual users.
System requirements should be finalized before the development staff reveals capabilities.
The first step in any project should be to produce a releae schedule. Only then should you discuss requirements.
Having worked in Germany during the summer, I put a high priority on team members' familiarity with soap.
Microsoft strategy - testing should be done by the first couple year's worth of customers.
I've worked with French developers. I second your soap resolution...
Mark W.
PHB: Analysis and desing of the architecture time???? WHAT!!!!
T: We need to figure out how the system is going to work first. Ther are lots of processes that need to be well defined first.
PHB: We don't have time to do that. We need to get something out the door, and any time you arn't coding is wasted time.
PHB:A technical writter(depending on size of the project)?? You want a WHAT!?!?!?!
T: Since we are on such a tight deadline, we need someone who can document our code(ie Java doc), write up use cases, and test plans, and ...
PHB:NO WAY!!!! That's another $*0K dollars that will be wasted on this project(and will directly come out of my bonus). We don't need to do that.
And the most obvious one.
PHB:OK, it seems that the system now not only has to serve our local division, but must able to be used by all divisions throughout the world. So that means internationalization, local time zones, international addresses, ....
T: Uhhhh, that would have been nice to know from the beginning and not 2 weeks before the deadline.
PHB: Actually the deadline has been moved up to next week. And I thought this might happen, but I was being nice and not bringing it up to you guys until it was a must have. I was doing you a favour.
*BANG* - Sound of Techie blowing ones brains out.
Make sure your developers' time is filled up filling out endless status reports and activity logs in order to inform higher management why the project isn't being completed by the arbitrary deadline.
I once worked for a manager who had an ironclad rule of thumb embedded in his brain: Every feature/addition takes four days to implement. He set his deadlines, and made delivery promises to clients (without ever asking the developers) based on this rule.
Some people respond to stress by just shutting down and you do not want any of these on your team. (I cope with excessive stress by playing games and taking naps...work for 2 hours, play a game for 15 minutes, work for 3 hours, take a nap, etc. which works great when you work from home - because my supervisor is 170 miles away. I always work my hours, just not consecutively. And I find that the time I do work is very productive. Plus, so often the elusive solution comes to me as I fall asleep or in the middle of a game.)
Gum
Ain't that the truth? My last boss embodies this description. The only thing he knew how to write were Perl scripts. That's it! He could talk to you all day about hash/key pairs, but couldn't tell a pointer from a struct from a function call.
But he was not alone. The entire IT department had managers who were editors at their previous jobs. Most of these came from bureaus of The New York Times, and yes, they were flaming Lefties.
I was very upset when I was laid off. But now that my business is starting to gel, I'm thankful that I was laid off.
No more dealing with managers who have absolutely no business anywhere near a programming environment!
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.