Quick, name a product that was developed without using software. It’s difficult, if not impossible. Software has become a crucial part of almost all goods and services. It’s used to design and develop just about any product you can think of, from consumer goods to industrial equipment – or any service or experience ranging from retail customer service interactions to luxury hotel stays. Likewise it’s central to buying most anything these days, and is a growing part of the customer and business experience generally.
Software has eaten the world. And as it continues to consume new and diverse industries it’s transforming the way business is done. We are all in the “software business” now, regardless of the product or service we provide, forcing us to reexamine how we structure and manage our organizations.
When I ask managers if their organizations practice “agile” they almost always say yes. Probing a bit deeper reveals that most of this agility starts and ends with the product development teams – specifically software engineering. There is rarely a mention of “agile in the HR group” or “continuous improvement in finance.” And yet, it is in these infrastructural disciplines that agility must take root to support software-driven businesses.
As the nature of software continues to shift towards continuous delivery, we are able to create a new type of conversation with the marketplace – a continuous one. We deploy products, observe, measure, interview, learn, and optimize in hours, not months. Decisions are made quickly. Directions shift overnight. To support this rapid, iterative optimization of our business the internal organizations that staff, fund, manage, and reward our people need to exhibit that same level of agility. “The way we’ve always done it” starts to put the management tier in direct conflict with the potential of the execution teams.
Let’s take a look at HR first. The object around which most HR organizations operate is the job requisition. A traditional job requisition is usually nothing more than a list of tools and capabilities buffered by ambiguous language about “self-starters” and “team players.” These job descriptions are written to fill a gap in a discipline-specific silo (e.g., the software engineering team or the design team). Recruiters, incentivized to fill roles quickly, scour resumes for these skillsets ensuring that anything that makes it through to the next round has “ticked all the boxes.” Three years of Rails? Check. GitHub? Check. Candidates are passed on to hiring managers who are then pressured to make a decision – ensuring the HR teams hit their time-to-fill quotas.
This style of hiring doesn’t build organizational agility. Quite the contrary, it reinforces the barriers between disciplines and minimizes cooperation. Instead, HR teams need to start hiring for creativity, collaboration and curiosity. They need to seek out the non-conformists — the candidates that don’t easily fit into a box. These are the generalists with an entrepreneurial spirit. They’re the multi-faceted tinkerers who have specialized in a discipline like design but turn out to be pretty good coders. They’re the skeptical members of the team. The ones always pushing back on the status quo and forcing the business to rethink the way it presents itself to its customers. New hiring practices have to be put into places to attract these candidates. Interview structures and exercises have to be completely rethought. It’s nearly impossible to assess a candidate’s collaboration skills in a one-hour Q&A. What do we need to change in order to learn if this new candidate is the innovator that will push our company forward? How do we ensure that our hiring practices continue to improve as the nature of our business evolves?
If we’re hiring ever-curious, entrepreneurial team members, the next logical question is how do we incentivize and retain them? In the past, we’d just assign them to a team; give them a project to build and if they shipped on time and on budget (or at least close enough to it) they got rewarded in some way. That’s not enough anymore. Financial compensation is not the main motivator for these folks. Building something meaningful, something they can call their own holds much more value. Is there a way for us to rethink compensation structures to include equity (or at least upside) for the ideas our collaborative teams create?
Project funding is another monolith that must conform to our new reality. CFO’s want to know what will ship in return for funding an initiative. While there is never a shortage of answers (you are trying to get funded after all), the true answer is rarely given – we don’t know. There is an ambiguity in software development that renders the end state unknowable. Unpredictable levels of complexity, market turmoil, and shifts in customer behavior put any product roadmap longer than four to six weeks at a high risk of quickly becoming an outdated artifact.
Taking a cue from the startup world, the CFO’s office needs to start treating each team as an in-house startup – a group of people tasked with solving a business problem. That business problem has an objective, measurable goal that ultimately determines the team’s success. At the end of each funding period, the teams must present their cases to the finance office for re-funding. This builds a cadenced resilience into the way the organization makes decisions, allowing it to make short commitments and then further those commitments or not, based on real-time market-based realities as opposed to lofty predictions of a future state that may never come.
Staples vs. Amazon. As you might expect, Staples has a big web application for online ordering. Multi-function teams build software enhancements that are rolled up into “releases” which are deployed every six weeks. The developers then pass the releases to the operations group, where the software is tested for three weeks to make sure the complete system is stable, for a total cycle of nine weeks. This approach would be considered by most IT experts as “best practice.”
But Amazon has a completely different architecture and management process, which Singleton calls a “matrix of services.” Amazon has divided their big online ordering application into thousands of smaller “services.” For example, one service might display a web page, or get information about a product. A service development team maintains a small number of services, and releases changes as they become ready. Amazon will release a change about once every 11 seconds, adding up to about 8,000 changes per day. In the time it takes Staples to make one new release, Amazon has made 300,000 changes. This represents a truly disruptive management and operating model. Just as Southwest Airlines, for instance, has a low cost, point-to-point operating model that disrupted its hub-and-spoke competitors, Amazon has a radically different and better operating model that will crush any competitors who are making one change in nine weeks, while it is making changes every eleven seconds.
Lastly, decision-making hierarchies need to change. Traditionally decisions are run past layers of management ensuring everyone is bought in before direction shifts. These processes are slow. They provide cover in the event that someone makes a mistake. Agility in the organization requires decision-making to be done as close to the customer feedback as possible. The teams working on the products need to be able to quickly decide how to move forward based on the continuous inbound stream of market insight. Making mistakes shouldn’t be a capital crime. Instead, mistakes should be quickly analyzed and any new information should be incorporated into the next set of tactics.
Incentives should support measuring outcomes, making evidence-based decisions, and learning. The culture of software development allows all of this, but without organizational support, the teams can’t take full advantage of it. At the end of the day, the day-to-day tactical decisions the teams make should not be the concern of managers. Instead, managers should focus on the teams’ progress towards the strategic business objectives. To allay managerial anxiety and ensure broader strategic cohesion, the onus falls on the teams to communicate back to the organization as much as possible. They must proactively report on their tactics, learnings, progress, and next steps. However, without the safety to report the whole process, warts and all, most teams will opt for safety and predictability – effectively undermining their agility.
As our companies turn into highly focused software organizations, we must change the way we manage them. A continuous learning environment fueled by round-the-clock customer insight and feedback demands teams, environments, decision-making structures, and funding models that exhibit the true meaning of the word agility — resilience, responsiveness, and learning.
“The technology world is a cult of innovation. We see that innovation drives success in business, and in the larger economy. Software is an almost-pure form of innovation. We call it ‘soft’ because we can change it and reshape it easily.”