Situation
A large manufacturer interested in selling more software makes an important strategic deal. As part of purchasing a much larger system, its customer said it was willing to buy its software on a pilot program. If it works well, they'll keep paying for it. If not, they'll return to its original software supplier.
The manufacturer is new to selling software--even for its own products. But it has yearned to be in the software market for years, not understanding why it couldn't win software business when its manufactured systems had always sold well. Its software program was led by a group of intelligent software visionaries who developed it by improving its prototypes over time. It was good software, but it was developed by researchers, poorly documented, and thinly tested in production environments.
Task
The manufacturer was thrilled to sell a system with software included. The good news was noted to its highest executives; all set about building the combined system even before the final contract for sale was signed.
The software division assembled a small group of its best software minds to adapt the software to the required system and directed that it worked with the manufacturing-led program that would accomplish final assembly, software installation, and delivery.
Conflict
Conflict immediately erupted.
The manufacturing delivery team was put off by the software researchers who were supposed to be meeting its customer's needs:
- The software team was a tiny fraction of the team size of any other part of the manufacturing process. Delivery team leadership wondered how it could ever meet deadlines.
- Software researchers noted that anytime their software was installed in a new system, it needed to be "tuned", a chaotic trial-and-error process whose progress was hard to measure.
- The software was intended to be used for many systems sold by the company, and manufacturing delivery team was confused as to whether the software team was working for them or someone else whenever its efforts benefited more than one product or more than one delivery.
Innovation Hypothesis: Controlled vs. Uncontrolled Chaos
The Innovation Hypothesis invoked here is "Controlled vs. Uncontrolled Chaos". Innovation is an inherently chaotic process. If anything is truly innovative, we haven't done it that much. So some things work; others don't. Most business efforts are right to remove as much chaos from their execution as possible. But if it's an innovative effort, the price of killing all chaos is killing the innovation that comes with it.
We can control chaos without killing it all and taking the innovation with it.
Wrong Action
By the time a contract was signed for a combined system including both hardware and software, the manufacturing delivery team decided it had a problem. It was suddenly on contract to deliver software that the tiny team assigned to it was "obviously" (in their minds) not competent to deliver.
The manufacturing delivery team took several actions avoid the blame they saw inevitably coming when software failed to deliver:
- Fearing the software team's small size, they:
- demanded it hire more people and gave it earlier funding to pay them
- transferred engineers from its manufacturing division to work on the software team
- They demanded precise project plans and rejected any plan that seemed "experimental" to them. The "tuning" tasks that adapted software for their particular product were rejected first.
- They forbade any of their funding being spent to benefit any other product or project. In particular, they defunded several critical work packages that would have benefited multiple projects including their own.
Wrong Result
Disaster ensued.
The newly-hired software engineers were young and inexperienced. Training them slowed software development. The manufacturing engineers moved onto the software project resented being there and didn't help because they didn't understand software very well.
Software project plans were authored, reviewed, and approved before falling nearly immediately behind. Because of confusion over "tuning" work and "work performed for other projects", they didn't include all the work necessary to deliver and install software.
Dedicated software engineers endeavored to do the necessary--now defunded and unauthorized--work anyway, causing scheduled and funded work to fall behind schedule and over budget.
Poor software project performance shortly became apparent to customer, who cancelled its order for software and maintained its order for hardware. The manufacturing delivery team agreed with the customer's decision and were grateful customer didn't blame them.
The company decreased R&D funding for software, concluding that it just couldn't compete in the market.
Better Action
The manufacturing delivery team brought their program manager a problem: they were newly on contract to deliver software with their hardware system and the software team assigned "obviously" (in their minds) couldn't deliver it.
That manufacturing program manager made a smart decision. He didn't disbelieve his team or the threat they were concerned about. However, he recognized he was responsible for new growth opportunities at their company and didn't assume he had the full story. He sat down with the manager of the software team. They worked out a series of compromises:
- As long as they could show progress toward on-time, on-budget project completion, the software team was allowed to be small.
- Some authorized software work could be unpredictable tuning work, but most of it would need the same level of predictability as the hardware efforts.
- Software work could benefit multiple projects or products, but all work paid for by manufacturing would demonstrate it was required to complete contract requirements.
Better Result
Both the manufacturing manager and software manager faced leadership challenges when returning to face their teams. Manufacturing delivery teams complained software received special treatment. Software teams complained they were being slowed down by manufacturing's outdated methodologies.
But after reassurances were made and work began, the software was installed properly and worked well. The customer was happy with the combined system and bought more.
Discussion and Conclusion
It's critical to note where the manufacturing delivery team program manager was not willing to compromise. He required software to track progress, timelines, and funding and prove they would meet customer needs on time and on budget. That didn't stamp out the innovation they all had the opportunity to do. That's controlled chaos. It's OK, and it's the way innovation happens.
Afterthoughts
To be fair, I only told part of this story. I left out...
- ...that the software division wasn't ready to serve a customer. It was happy with the freedom and funding that came with being an R&D organization. It resisted taking care of a real customer with needs even while they appreciated the funding it brought. In a future narrative concerning "We Never Pathfind", I'll tell you the rest of the story.
- ...that involved managers needed to apply particular leadership techniques to keep disgruntled teams under "Better Result" working together. I'll say more in a future leadership-related article.
Comments