Speaking with Adam Furtado, Chief Product Officer
The US Air Force is a wing of the United States military. With a budget of $715 billion, it has been described as the world's largest bureaucracy.
What was the challenge
Federal IT programs are 96% behind schedule or over budget and 40% never deliver a single thing. The average time was 12 to 15 years to get an idea into a user’s hands. General Mike Holmes, the commander of Air Combat Command, has said
Years of institutional risk aversion have led to the strategic dilemma plaguing us today, replacing our 30-year fleet on the 30-year timeline'.
And that risk aversion realises itself in a multitude of ways. We constrain ourselves by these bureaucratic safety nets that protect us from ourselves, but in reality, they make us less safe because we're not able to adapt to change. We constrain ourselves by treating our software organisations the same way we treat our hardware organisations, the same organisations that build and deliver aircraft and aircraft carriers, and the byproduct of that is you start receiving your software on those same timelines.
What kickstarted the initiative?
The defence innovation board, a group of Silicon Valley CEOs, and innovators, chaired by Eric Schmidt, traveled out to the air operation center in Qatar to learn how we execute air warfare. Eric Schmidt described what he learned saying the DoD violates every rule of modern product development. People were planning on whiteboards and manually inputting the results into different systems. If anything changed, they would have to start from scratch again.
Where did you start?
It isn't possible to change an organisation in one go. So a small team was set up to tackle a single problem - refuelling planes. It is incredibly expensive and riddled with inefficiencies. Eric Schmidt called the current manual process “the most ridiculous thing I have ever seen”. So it was a good place to start.
Did you have the skills needed?
We had no idea what we were doing. None of us had any skills in modern software development or how to manage a digital transformation. We sent a small group of active-duty Air Force members, who had shown a growth mindset and willingness to learn, to Silicon Valley and ask for help.
We partnered with a company called Pivotal Labs to not only help us build a cloud-native platform for us to deliver capability to our warfighters, but to teach us how to change the way we thought about products and the way we thought about our organisation.
Pivotal taught us a bunch of things on Lean principles, user-centered design, DevOps, extreme programming, Test Driven Development. But the most important thing they taught us, was how to change the culture within your workplace. It’s one thing to read slides, and see talks on why culture is important, but it's another to see in action actually on the floor. Seeing people collaborate and seeing ideation happen, people happy at work.
What outcomes did you achieve?
Within a few months, we had an MVP for the refuelling problem in customers' hands. It instantly produced savings of $214,000 per day and paid off the development costs in less than a week. But that was only our MVP. After a few more iterations we had doubled the fuel savings and reduced the number of people required by two. In some places that could be seen as a negative but in the military it means two fewer people leaving their families going into harm's way and being pulled from their aircraft.
How did you communicate your success?
We used the cost of delay to build consensus on the power of the new approach. We made the argument that if you would have waited five years to deliver the same products using our traditional waterfall development methods, we would have had a cost of delay of $384 million. That was enough to buy us some more time to keep experimenting.
What challenges did you encounter?
A lot of organisations tout that they're doing agile and it kind of hurts the messaging a bit, especially for an organisation that doesn't understand it - there is a language barrier. So, we had to spend a lot of time educating upwards and cultivating downwards.
Another thing we learned is to not forget about our platform or whatever our delivery mechanism is. We got distracted by the applications and the products. We weren’t concentrating on how to make sure that we were efficient in getting that into the user’s hands. So, we started emphasising our platform in our delivery and the actual doing the DevOps, and we saw a rapid increase in our software delivery performance. And when you get to this point, where you want to think about delivering anymore, you can concentrate on mission applications that are above your value line.
What structural changes did you implement?
We shifted from a functional structure to a cross-functional product team structure. As we mentioned our focus on usability led to us employing product designers for the first time. We use a balanced team model with product managers, product designers and software engineers focused on lean principles to make sure that we're building and learning the next most valuable thing in the simplest possible way.
We now have 18 product teams all delivering products that our airmen are beginning to love.
How did you change how you work?
We shifted from the traditional Waterfall procurement and delivery models to lean product teams.
Focus on Usability
Traditionally in the DoD you'd have some subject matter expert write a 60 page spec, they farm it out to a defense contractor they'd find some front-end developers to fit everything they could into a screen. Usability was an afterthought. Now, with bringing in user-centered design for the first time, at least in our world, usability is a first-class citizen again.
Traditionally we would finish a software product and give it over to cybersecurity folks, and they would take about a year to 14 months to approve it to go on the network. We're using extreme programming, test-driven development, over 80 % test code coverage and automated release and security pipelines which led to us getting the government's first-ever continuous authority to operate (ATO) to go directly into production every time we iterate, which is multiple times a week at this point.
We're now deploying over 300 times a week to our staging environment and 30 times per month to production. We now average, across all of our teams, 124 days from whiteboard ideation into our classified production environment - our benchmark was 10 years. We're at this point now where deploying is almost a non-event for us, which is where we want to be.
What changes to leadership and culture did you implement?
Google did a study called Project Aristotle, where they focused on the team effectiveness traits that drove teams to be really good performers, and they came up with five things. Dependability, Structure and clarity, meaning of work, impact of work and psychological safety. The first four of these marry up very well with military culture. But the last one, this idea of psychological safety, is the one where we don’t have at all. The military is based on this hierarchical top-down leadership, which is imperative to being successful in the battlefield but a really a bad way to build good products.
The whole idea behind uniforms is to strip away your individuality when, in reality, that individuality is what we need to solve complex problems creatively. So we got rid of the uniforms. We got rid of the ranks. You could have a lower enlisted product manager working with a higher-ranking officer, they're talking on a first name basis and they feel free to be safe, to fail, to iterate and free to give you their opinion, which is new for the military.
In the military feedback is inherently negative. If you're getting feedback you did something wrong and we're trying to change that model within our organisation, so people can find their blind spots and want to learn and grow and get better. We knew we had to build a learning culture. It's been difficult but is it something we've been prioritising. Admiral John Richardson, the Chief of Naval Operations, the highest-ranking officer in the Navy said
It's about the team that could bring the people, technology, and processes together to learn the fastest. That's the team that has the advantage.
I hate "It depends"! Organisations are complex but I believe that if you resort to it depends it means that you haven't explained it properly or you don't understand it. Having run UXDX for over 6 years I am using the knowledge from hundreds of case studies to create the UXDX model - an opinionated, principle-driven model that will help organisations change their ways of working without "It depends".
Free Community EventsSee all
Get latest articles straight to your inbox
A weekly list of the latest news across Product, UX, Design and Dev.