August 15, 2008 by jimstogdill
Why We Work (and Why We Would Work Harder)
I was recently asked "to provide some thoughts about how contractors should or should not perform differently or be incentivized differently during wartime." The query came as part of a research project started by an acquisition officer who is concerned that they are not seeing "exceptional performance or motivation" from either the contracting base or the government's own acquisition apparatus.
Perhaps they are worried that we are at the mall with the rest of America.
In short, immediacy of impact. They had it, we don't.
I do not believe that money or monetary incentives would make one whit of difference. Face it, if it was really about the money we'd be in financial services or somewhere else where the money pools around your ankles. If you want your defense industrial base to work like it's at war, it has to feel like it is at war. You have to strip away the layers of industrial-age bureaucracy that makes our work feel less like winning and more like an abstract intellectual exercise. There's a reason why WWII war heros toured defense manufacturing plants.
My work is in defense IT. So, sticking at least a bit to what I know, here are some suggestions to create the kind of immediacy that will lead to meaningful performance; performance that comes from the sense that the work has real meaning.
One. Connect the warfighter to the people building stuff.
It's no mystery that direct contact with your customer raises the stakes. This is one of the reasons why scrum development works to improve the degree of customer engagement. I think of this every time I'm leaving our office and pass the team area of one team that is always here late. It might be that they just have a hard ass team leader, but I don't think that's it. I think it's the fact that the software they work on is deployed around the world and they have a direct conduit to the warfighters that use it through a 1-800 help line that is staffed inside their team. Sure they have to do standard acquisition system stuff like program reviews, but they regularly talk directly to the warfighters that use their stuff.
Remember the Automated Deep Operations System (ADOCS) story? Acquisition people hate it because it "was off the reservation," used non-standard architectures, and yada yada. But it has provided tremendous value, has served the warfighter well, and was built by engineers who were working overseas side by side with the warfighters that were using it. Let us do more of that. It works. No one in the commercial world would work as hard as the DoD does to separate the people slinging code from the people running it.
While we are at it, let's better connect our acquisition conduit to the warfighter too. There are fewer acquisition people in the DoD now than there were ten years ago, but there are still more of them than there are front line M-16 carrying troops. In an era when even Navy submarine officers are being rotated into Iraq between sea tours I think we can rotate our acquisition people in there too. They can see first hand how the stuff we are building for them is doing and gain an intuitive sense of what works that will be so useful later. Is it relevant? Is it usable? Is it providing value for the dollar? Will the operators be able to reconfigure it to meet their local needs? Etc.
CDD's and requirements documents are low bandpass filters. Being on the ground eating their own dog food in a war zone will make it easy for our acquisition folks to put the high frequency band back into the requirements comms. Be a warfighter for a while, think like one forever.
In situations where you can't put people over seas, bring the warfighter back to us through simple and available technologies like help lines, web forums, email, VoIP, mailing lists, etc. Heck, build those little active chat help things right into the apps if it is on an unclass network. Actively work to make a direct connection between the people writing code and the people running it.
Two. Add value to your customers, now.
The warfighter needs stuff now. Have us build stuff that you are going to rapidly deploy to them now, rather than spend all the money on stuff you think you'll deploy in 2011. Sure, we'd like to help build the longer term big programs that have well known and well worn acronyms, but let's get real, we're at war. If we want IT to help us stay inside our enemy's OODA loops we need to be roll out stuff our troops can use now. Imagine how frustrating it must be for the deployed warfighter to ask for something during their first tour knowing there is little chance of them seeing it before their fourth. Use those acquisition folks you've deployed into the war zone in step one to be on the ground product managers. Plan to deliver stuff to the warfighters they are embedded with while they are still there.
Three. Build it incrementally.
I have never felt nervous perspiration on the back of my neck when facing a deadline that was three years away (and I don't mean those intermediate soft deadlines, I mean the real ones). Use agile incremental development along with the power of product platforms to quickly and incrementally deliver stuff to the field. Give us deadlines that are three months out, not three years. Exercises don't count.
Don't think in terms of "requirement" = "tool." Think in terms of generative platforms that will let the warfighter self serve on the little problems and will let small contractors quickly and innovatively deliver on the slightly more complex problems.
How is that possible you say? How can we deliver stuff without operationally testing it first? By engaging much closer with the warfighter while you build it (e.g. like the way ADOCS was built), using product platforms that have gone through pre-certification and operational use, and etc. First, believe you can be relevant to the warfighter now and then make it happen; we would love this. We are dying to be relevant today.
Some years ago a company I was working for sent me to a career planning seminar. The instructor gave us a framework for thinking about our careers that said satisfaction comes from balancing compensation, competency, and meaning. I think many of us in this business derive a large amount of satisfaction from the meaning associated with our work. Thinking back to my time in a B2B startup the meaning came from knowing that the thing I was building today was going to be deployed and earning revenue next week.
If you want to get even more from us, help us improve the meaning dimension by making it easier for us to do work that makes an impact now. Clear out the bureaucracy, help us get closer to the end customer, and deliver stuff quickly that will really make a difference. You might be surprised what happens.