Extreme Development Management

The FuzzyBlog!
Marketing 101. Consulting 101. PHP Consulting. Random geeky stuff. I Blog Therefore I Am.

Who is FuzzyBlog?

Extreme Development Management

Once upon a time, in a galaxy far, far away, at a point when DOT COMs still roamed the earth like the extinct dinosaurs they become, I was promoted to VP of Engineering at a DOT COM. I came into a very, very, very bad development situation and I applied what I personally call "Extreme Development Management" to meet the goals. I have used these several times in my career in difficult, challenging release situations but they are not for every product or every release. Please, please, please see the Note at the end before using these.

Here's the situation:

Fixed, unmovable shipping date as if God himself had specified it (we sold into the higher education market so, for us, September was all that mattered).
Between 35 to 45 developers depending on how contractors were counted.
Most of the developers worked for a consulting company that we hired but were required to work onsite at our office.
The bulk of the developers were excellent but they were Indian and there was a communications gap that varied from developer to developer. Some were outstanding. Others less so. Still, we had the same problem with the non-Indian engineers we had so it does all balance out..
Deploy a new version of a previously totally unscalable web application to an audience of 300,000 students at 65 + universities.
Software platform of SQL Server 7, Windows 2000, ASP Pages and Visual Basic COM Objects (don't wince, I didn't pick it, I was given it).
Hardware platform of all Compaq boxes, hardware load balancers, a 20x20 cage at Exodus and 80+ rack mount servers (the servers were paired with a load balancer for every 2 servers), an EMC terabyte array and 2 db servers.
A stupid and ridiculously inefficient database architecture that hinders you, limits you and sets you back at every turn. And a software architecture that wasn't much better.
A premier client, Columbia University, that you, the VP of Engineering, have to handle personally and meet with at least once per week (overnight trip to make it worse).
Between 4 and 6 custom code integrations such as a Kerberos/LDAP authentication system for single sign on at Columbia.
Between 30 and 45 days from your promotion to when this whole mess goes live on a rolling basis (i.e. every school had a different start date so we brought things online piece by piece).
Lots and lots of last minute discoveries like MS SQL 7 databases with Full Text Indices don't support replication! GAH!

Here is what extreme development management meant for this project in a sort of random, disorganized fashion. A lot of this sounds silly, stupid or ripe of dot com like overspending and there's some truth to that. You have to judge this for yourself but I would point out two things:

What's the cost of being late to market?
What's the average $ value of an engineer's time? If, for example, it works out to a loaded cost of $70 per hour and you get that developer to come in on a Saturday for 8 hours then that developer just gave you $480. Across a large development team that buys a lot of pizza / caffeine / toys / etc.

Scott's really silly but fairly useful Extreme Development Management techniques:

Budget. Find out what your discretionary budget is on day one. Stuff it into Excel and estimate costs such as "Dinner for 10: 175 delivered). Keep a running total. Don't screw this one up. Budgets matter.
Lead by Example. This is damn simple: You are the first one to arrive and the last one to leave 90% of the time. You can't expect people to work hard if you aren't.
Cool T-Shirts. As tradition demands, a cool t-shirt is just required. Add the date to the t-shirt so people see it every single time they wear it. If you're in charge then wear the t-shirt every single day to build morale. Hopefully you personally get more than one in this situation.
One Location. Everyone works in the office. No working from home, no exceptions -- unless they are a company founder / someone who will quit over it. And even then be careful.
Know the Key People. Identify at the start who are the key people. Treat these people even better than the rest but don't be obvious about it.
Contact Info. Ever get a midnight bug before a CD-ROM has to be burned (maybe not but you get it)? Get every single team members contact info including:
- Home phone #
- Cell #
- IM Addresses
- Address
- Whether or not they have a spouse or significant other and if so, how early / late is it ok to call
  
  If you use this then be polite! Be really polite!
Version Control. Learn your version control system rippingly well. This will save you at least once per release, guaranteed.
Hire Consultants. Don't be afraid to bring in a specialized consultant for 1 or 2 days to solve specific problems. It's often cheaper and faster than solving it yourself -- if you get the right consultant.
Backup. Get your IT guys to do everyone's backup for them. No exceptions. Their PST file for mail is often more important than code on their own machine (that's handled by version control). If they don't have the history of their mail and the bugs and stuff, they're toast.
Dates. Figure out personal critical path events. It's not fair to ask someone to skip major life events such as a friend's wedding, etc. Here's what you want to know about:
- Someone's anniversary
- Any upcoming births
- Any upcoming weddings
- Any vacation time already paid for
  
  And, while you may not want to interrogate someone for this (or even be legally allowed to), nothing says that you can't write it down if they tell you. Just having lunch with a group of engineers and actually LISTENING to them tells you what their plans are.
Anger is Unacceptable. Never, ever lose your temper.
Praise Publicly. Criticize Privately. If I have to explain then then turn in your manager badge and clipboard and go back to coding.
Tact but honesty at all times. If someone screws up, let them know. Be tactful. Be honest. Be gracious when someone does the right thing. Never take credit for someone else's work.
Reverse the Order of Normal Tasks. Handle the tasks you normally do last early. For example installation -- do it early because otherwise you'll be so burnt out that you'll just screw it up. Sure, it's going to need to be changed but you've got a real head start.
Mid Release Party. "Geeks Just Wanna Have Fun" (apologies to Cyndi Lauper).
Free stuff including:
- Weekly grocery run so that snacks are always available. Go around the team and find out what people's real preferences are (doritos versus chocolate for example) and then cater to those preferences.
- Unlimited supply of caffeine in everyone's preferred style and form factor (example: to me cans of diet coke taste better than 2 liter bottles)
- Dinner if you stay late. Set up a billing relationship with a delivery service or make available a credit card number. And, most importantly of all, it's your responsibility to handle food acquisition.
- Donuts every weekend morning. I used to bring in between 4 and 6 dozen donuts if the whole group was working on the weekend.
Be a Human Being. When it's important send someone home. I know that you won't believe this but during this release, the lead developer's dog actually died. This happened on a Friday night and he still came to work on Saturday morning and Sunday morning. Both days I sent him home. It didn't matter what it did to my schedule, for this person, this was more important.
Don't Waste Time on Decisions. When decisions have to be made, just make them. You just don't have the time to analyze forever. Any decision you make could well be wrong. No decision is wrong.
Don't Be Afraid to Cut Features. 'Nuff Said. Sometimes it just has to be done and then make the decision and move on. The longer you wait the worse the impact.
Destress Periodically. I give out Nerf guns (even the Indian developers like these, Nerf transcends culture). And I keep a football around to go outside and hash out issues. You may have other approaches. Just something to cut through the pain when it's needed.
Know that Significant Others Count. Send flowers to key team members significant others / spouses with a promise "We'll return NAME soon. Thanks for understanding". This only works a few times but it's easy (800flowers.com -- you already have their home contact info), cheap and makes your staff member's home life better. If you are really smart then you will let some of your key staffers send the flowers themselves but take the credit even though you paid.
Take Care of Yourself. The biggest mistake I made during all of this was to not take care of myself through all this and that ultimately led to my quitting the company in disgust when I had a conflict with the CEO. A single weekend off could have prevented this.
Final Stage. Appreciation. Every single person on a big release of mine gets an unexpected present at the end -- a framed certificate of appreciation that is specifically and humorously tied to the release and their role in it. "Thanks to Gloria whose insistence that Netscape isn't a dead browser gave us cross platform". And you give these out in a public "awards" ceremony at the end of the project that is limited to the developers themselves.

You'll notice that I didn't specify anything about project planning, requirements and specifications. As far as I am concerned in this type of situation you either know what needs to be done or you don't. Project plans aren't a panacea. To me managing this type of awful, painful birthing process (because it really is a birth) is fundamentally a people and motivation problem. If you know how to knit together a team then you'll do ok if you don't brutalize them or otherwise convince them all to run away.

NOTE 1: I am not endorsing this approach to shipping a product on time. It violates my "Programmer Safe" credo i.e. "No Programmer was Harmed in the Release of this Software Product". Still these can be useful but apply them wisely as they have very real consequences.

NOTE 2: Just in case you got the idea that my (not intentionally) somewhat brutal ruthlessness do get the product out led to people hating me, wanting my cats to die, slashing my tires, etc. Here's an interesting card they gave me.