
Note: this article is part 10 of a series called Accelerated Velocity. This part can be read stand-alone, but I recommend that you read the earlier parts so as to have the overall context.
“Confident. Cocky. Lazy. Dead.” This admonishment against complacency was the mantra of Johnny “Dread” Wulguru, the villain in Tad William’s Otherland saga. As true as it is for assassins like Dread, it’s also true (though perhaps not as literally lethal) for teams and companies that choose to rest on their laurels and stop challenging themselves.
Complacency is the enemy of innovation. This has been proven over and over throughout history in every domain as once successful or dominant players suddenly found themselves lagging behind. This is also a leadership failure. Good leaders strive to prevent comfort from becoming complacency.
Jeff Bezos at Amazon has baked this into the DNA of the company as enshrined in his “Day 1” message to shareholders. Of note is what Mr. Bezos says happens when companies get comfortable on Day 2:
“Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1.”
Confident. Cocky. Lazy. Dead.
It’s not easy, though. Comfort is the reward for success after all. “Don’t fix something that ain’t broke.” Right?
Wrong. The reward for success is being in position to hustle and build on that success. Period.
Getting Uncomfortable
It’s no different in software development teams.
By 2016 we’d made significant strides in velocity and efficiency in Bonial product development. Processes were in place. An architecture roadmap existed. Teams were healthy. The monolith was (mostly) broken. AWS was being adopted. All signs pointed to very successful changes having taken place.
At the same time I felt a certain sense of complacency settling in. The dramatic improvements over the past couple of years had some thinking that it was now “good enough.” Yet we still had projects that ran off the rails and took far longer than they should have. We still couldn’t embrace the idea of an MVP. We still had mindsets that change was dangerous and scary. And, perhaps most important, many had a belief that we were as fast as we could or needed to be.
Yes, we were better and faster, but I knew we had only begun to tap our potential. It was time to get uncomfortable.
Engineering Change
Changing a deep-seated mindset in a large organization using a head-on approach is tough. An easier and often more effective approach is to engineer and successfully demonstrate change in smaller sub-groups and spread out from there. Once people see what is possible or, better yet, experience it themselves, they tend to be quite open to change.
So we looked for opportunities to challenge individual teams to “think different”. For example, on several occasions the company needed an important feature insanely fast. Rather than say no, we asked teams to work in “hackathon mode” – essentially, to do whatever it took to get something to market in a few days even if the final solution was wrapped in duct tape and hooked to life support. Not surprisingly we usually delivered and the business benefitted massively. Yes, we then had to spend time refactoring and hardening to make the solution really stable, but the feature was in the market, business was reaping the benefits and the teams were proud of delivering fast.
On another occasion we had a team that struggled with velocity due, in part, to lack of test automation and an over-reliance on manual testing. So I challenged the team to deploy the next big feature with zero manual testing; they had to go to production with only automated tests. This made them very uncomfortable. I told them I had their backs if it didn’t work out – they only needed to give it their best shot. To their credit, the team signed up for the challenge and the release went out on time and had no production bugs. This dramatic success made a strong statement to the rest of the organization.
Paradigm Shift
We also took advantage of our new app ecosystem. Over the past few years the company has started several new “incubation” initiatives to explore new possibilities and expand our product portfolio. We didn’t want to do these initiatives with our core product development teams because (a) we didn’t want to be continually wrestling with questions as to whether to focus on the new or old products, and (b) we feared that doing things like the “core” teams would be too slow.
So we spun out standalone teams with all of the resources needed to operate independently. Not surprisingly these “startup” teams moved much faster than any of our core teams. In part this was because they were not burdened by legacy systems, technical debt, and risk/exposure of making mistakes that affect millions of users. But I think the bigger part was sheer necessity. We ran our incubation projects like mini startups – they received funding, a target and a timeline and they had to hit those targets (or at least show significant progress) in order to receive more funding. As a result, the teams were intensely focussed on delivering MVPs as quickly as possible, measuring the results in the market, and pivoting if needed.
Between 2015 and 2017 we ran three major incubation projects and each one was faster than the last. The most recent, Fashional, went from funding to launch in less than 12 weeks, which included ramping up development teams in two countries, building web and native mobile apps and lining up initial partners and marketing launch events. This proven ability to move fast made a strong statement to our other teams.
We soon had “core” teams making adjustments and shifting their thinking. Over the next few quarters, every team had embraced a highly iterative, minimalistic approach to delivery that enabled us to try more things more quickly and, when needed, take more aggressive risks. Now each team strives to deliver demonstrable, user-facing value every sprint. Real value, not abstract progress. Just like the agile book says. This isn’t easy but is fundamentally required to drive minimalistic, iterative thinking. The result is dramatic improvement in velocity while having more fun (success is fun).
For sure this hasn’t been perfect. Even today we still have teams that struggle to plan and deliver iteratively and we still have projects that take way too long. On the flip side we have a much deeper culture of challenging ourselves, getting uncomfortable and continually improving.
Confident.
Closing Thoughts
- It’s easy to become complacent, especially after a period of success. This is deadly.
- Leaders must act to remove complacency and force themselves and their teams to “get uncomfortable” and push their own limits.
- Break the problem into smaller chunks. Work with entrepreneurial teams on initiatives that challenge the status quo. Have them show the way.
- Reward and celebrate success and make sure you have the team’s back. Honor your commitments.