More questions than answers.

August 15, 2008

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.

I don't know who's at the mall, but the sad truth of the matter is that the average javascript programmer at a dot com circa 2000 worked a hell of a lot harder than the typical defense contractor or government acquisition person works today (speaking frankly, I know I did). The reality in this post-mobilization-age war is that America isn't at war. While it's professional class of pointy-end-of-the-spear warfighters are doing their third or fourth tour in the combat zones, the rest of us have been sort of intentionally left out of it so that we can keep the economy humming that pays for the spear. Sometimes it seems like our government just doesn't want to inconvenience us with this whole "we're at war" thing (I might add that that's an odd position to take in a Democratic Republic where the government is *of the people*).

But we defense contractors aren't just anyone in America, we're participants. So why did those javascript slinging philosophy majors work 18 hour days while we continue work, at least collectively, a lot less urgently? What's the difference?

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.

Put another way, let's figure out how we can deliver a range of capabilities. In the commercial world big things like an ERP system are done centrally and with a lot of oversight while smaller scale departmental initiatives are done quicker and locally. We shouldn't be thinking about how to deliver everything the warfighter needs from the center, we should be thinking about how to let the warfighter build or buy stuff locally. Need a web site to share information among all the platoons in a brigade? Let your javascripting sergeants build it locally on platforms that the center is providing for you. Enable the long tail of development.

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.

Comments

Excellent.
Since joining my current team I have made the opportunity to visit our users at the 7th in Korea. The information I gained and brought back was irreplaceable. Seeing how the warfighters used stuff I created 30 days ago was an exciting feeling.

On the topic of delivering incremental capability that doesn't solve the problems for 2011, I couldn't agree more. Back at my former company, a fortune 500 company at the time The Williams Company, I worked in the intranet group developing intranet applications specifically for HR, AP, Solution Center, etc. These weren't top of the line applications. They were "just enough" to make them more productive than staying in outlook, excel, and ppt. We would spend 3-5 months developing it and that was just about it and then we would go onto the next group.

On that subject choosing the right technology to achieve that is what I think about the most. Building things faster and easier are at the forefront of my daily thoughts. Things like rails, grails, ruby, php, flex. Compared to the old java webapp days I can create a simple rails/grails web application in a third of the time it took me with java/struts etc.

I know I’m just complaining (with little expectation of changing anything). But I think there are some (among other numerous) basic economic tenets that aren’t working in this DoD IT market. “Market failures.” Competition matters but DoD processes and long acquisition cycles create barriers-to-entry into this market and protect the encumbents. Too much process has created an environment that makes it very hard for organizations that are beholden to Quarterly earnings to participate in DoD programs. The cost of monitoring programs that take years to get to contract award, the cost of responding to multiple RFIs, etc. makes it hard for any but the entrenched DoD contractors (who are funding this “stuff” in their overhead costs for existing programs) to participate. As a result, potentially high-quality organizations with great product and intellectual capital shy away from establishing a government practice. And competition for government business is not as fierce as it could otherwise be. One good example is the stronghold some of the traditional, big DoD contractors have on contract vehicles that have allowed them to morph over time from hardware (planes, boats, tanks) to software developers. The government has paid for the on-the-job training and funded and re-funded many low performing programs because of the reluctance (based on apparent risk) to use lesser known corporations whose expertise lies outside traditional DoD hardware.
In order to create motivation for the best minds and products to be continually available to the government, we need to reduce these barriers-to-entry. Ha!

The other market failure I notice every day is that these over-budget, under-performing programs are never allowed to fail or be terminated. They just re-baseline. I'm currently thinking that “hangings at noon” in the central market place would be a good idea.

Bill Parcells has taken 4 different football teams to the playoffs and won 2 Super Bowl rings (with the NY Giants). One interesting occurrence that seems to happen every time he takes over a new football team is that some very comfortable, highly paid “super star” gets cut or demoted. In the first 2 weeks of training camp. When he first joined the NY Giants, it was quarterback Phil Simms (who later did take Parcells to his first Super Bowl win). At Dallas, it was Keyshawn Johnson. Most recently, Parcells has taken over the Miami dolphins and Jason Taylor was shown the door. The point is made that nobody is above the law, nobody gets to take it easy and live on their laurels, there’s a new sheriff in town and the standard of performance is very, very high.

When DoD baselines and re-baselines underperforming programs, they continually erode the standards of performance. There’s apparently no real penalty for underperforming. The competitors are vanquished once and for all, early on, in the initial competition. And then the encumbents motor-on at their own pace for a very long time. Especially in the IT world (without naming names), there are numerous expensive programs that deserve to made an example of.

Gentlemen,
As an acquisition officer I can tell you that the long hours committed by many DoD vendors are greatly appreciated by the warfighter and the commands they serve in. In my acquisition career I have mainly worked in the aviation community dealing with communication assets and how they are integrated onto platforms. In most cases the vendors provide a 1-800 help desk that is manned 24/7 and also provide a web-based diagnostic self help service. These services have proved invaluable to both warfighter and the support representatives that are deployed in harms way. I will tell you that this work does have real meaning and that individuals making that kind of commitment should feel a great sense of pride in the work they do. There are, however, some points brought here that I wish to clarify.
First, your point about “exercises not counting” may be too aggressive in that it glosses over a main tenet in ensuring improvements or new technology meet the desired capability requirements and have been thoroughly tested to avoid existing capability being disrupted, which is a common reality within aviation platforms. I am on board with reducing the timeframe needed to deliver a capability but there are minimum steps to this process that cannot be omitted. Aviation, specifically, has its air worthiness requirements that are admittedly complex and time consuming but this process ensures extensive regression testing that negates any possible defect or glitch that could negatively impact operator efficiency or, God forbid, a catastrophic failure.
Second, creating an environment where subject matter experts are working side by side with the warfighter is commendable. The question here: where is the line drawn for how many contractors are permitted in theater at one time. As a commander, I would want any and all support available to ensure soldier safety and mission accomplishment. The reality is, however, that each person admitted into theater adds to the scope that that commander is responsible for and, finally, distracts from his ability to effectively support his mission due to that increase in scope. One way to circumvent this is to cross train support representatives, which I did after being curtailed on the quantity allowed, but this increases the demand on these folks and reduced their ability to support effectively.
I realize my views on this may be out of my realm but I thought it would be beneficial as a different perspective which may point out challenges not considered.

The views I present here are my own and not in any way an "official statement" from the government.
---- MAJ Joe Rush, current student at CGSC.

@ MAJ Rush, I should probably clarify that my points about the use of exercises and the interaction between warfighter and developer are focused directly on the area of software development.

Software has different attributes than hardware platforms and I don't think it is well served by the slow release rhythm that comes from the DT/OT cycle. I should have been more careful in my wording though because I don't want to leave the impression that I don't believe in those processes for hardware. The Bradley experience still resonates and the reasons for DT/OT are as strong as ever; but the way they are done doesn't work well for software.

Software, being morphable, works best when it is released in as-small-as-practical increments and feedback from real world usage is continuously fed back into the development process. "Exercises don't count" in the sense that they are often heavily scripted, and by the time they happen so much has been invested in the system that it is gamed to win / work.

I'd really like to see an approach to software in the DoD that was fast, incremental, and with much better contact with the real users (whether in theater or in the form of immediately-after-deployment interactions).