Build Or Die
To truly survive and thrive in the digital era, either as a potential disruptor or an incumbent fending off the disruptors, you need to think like a software person.
A software person isn’t necessarily a developer. It’s anyone who, when faced with a problem, asks the question ‘how can software solve this problem?’.
It’s because being a software person is a mindset. It’s not a skill set. Software mindset starts by listening to customers, rapidly building potential solutions to their problems, getting real feedback and then constantly iterating to improve. With this constant progression, anyone can apply a software mindset to solve more and more of the world’s problems.
Consider what Apple did to the TV remote control. Before Apple released Apple TV, set-top boxes came with a remote control with a hundred buttons. Some even advertised the number of buttons as a selling point! The first Apple TV remote had only seven buttons. Why? Because all the smarts of the Apple TV resides in the software running on the device. That means Apple can learn from customers and update the software constantly with new features and functionality. Developers can’t iterate on things that are fixed in plastic and metal—once the gizmo leaves the factory, its functionality is set for life. The decision to remove the buttons isn’t just aesthetic, it’s incredibly strategic.
Another example is the Tesla. The average car has dozens of buttons on the dashboard. Most Tesla cars, by contrast, have just four buttons and two scroll wheels in the steering wheel. Everything else is software running on that giant screen. The buttons in a Tesla don’t even have labels. That’s so everything can be treated as software and updated constantly as Tesla gets customer feedback. That can mean fun things like the infotainment system, where they’ve added things over time like Caraoke (yes, an in-dash karaoke system) and YouTube, but also critical safety advances.
The Rise of the Software Supply Chain
Until recently, the software industry had no such thing. Most software companies—think of companies like Microsoft, Oracle, or SAP—pretty much wrote all of their own software end to end. That worked when software was a highly specialized field and there were relatively few software companies, right up through the 1990s and into the 2000s. That notion was especially true when software companies sold products as downloads or CD-ROMs.
Until recently, most software companies like Microsoft, Oracle or SAP wrote all of their software end to end. But now almost every company is becoming a software company. Just like any industry, software industry needs a supply chain. But the software supply chain looks different. Instead of specializing in speedometers or steering wheels (think of an automotive industry), software supply chain companies deliver reusable chunks of code that developers bring together to make finished applications, called Application Programming INterfacs (APIs). Each API supplier provides only a piece of the solution. Take for example Amazon Web Services (AWS) delivers the data center. Zoom provides communications. PayPal enables payments. Modern apps integrate dozens of these partial solutions into a unique value proposition for the customer. This ‘shift’ is the next big leap in the evolution of software industry. The author calls it the ‘Third Great Era of Software’.
Build And Buy
There’s a constant debate surrounding which microservices to build and which to buy. Ashton Kutcher has invested in dozens of startups, including the likes of Airbnb, Spotify and Uber. He says “I think what you don’t build is as important as what you build. The only things companies should build themselves are the things that are core to their business. A lot of times people end up building things where there’s already a product you could buy or license for a relatively low cost. Should you build your own benefits and payroll system? I would never try to rebuild Twilio, or Slack, or Gusto.”
According to the author, the rule of thumb is that for anything that differentiates you from the rest, you should build. This mostly includes software that faces your customers. When your customers care, you need to build. But for most back-end operations that won’t give you any differentiation, you should consider buying. After all, you aren’t going to build your own email, HR software or ERP programs. Those are areas where you can gain any clear competitive edge.
You can’t buy differentiation. You can only build it.
The good news is that building has become a lot easier. Before the maturation of software supply chain, the answer usually was to buy because of the tremendous efforts to build. You had to be as good as Microsoft or Oracle to build software. But now thanks to the digital supply chain enabling companies to build with unprecedented speed and ease, it’s not just possible for companies to build software. It’s required. Competitive nature of business dictates it.
Code Is Creative
Most software are pretty simple. They are what developers call ‘CRUD’ applications – Create, Read, Update and Delete. This isn’t a rocket science.
It’s when developers care about their work that makes the difference. When developers care, intrinsic motivations kick in and unlock even more creative ideas. When developers are merely reading a specification document, they become separated from end-users who will actually use the software. The code becomes clunky, error-prone and above all, misaligned with the actual use case. Not only that, writing a code feels like forever because of the lack of passion and intuition.
User Empathy = Better Products, Faster
Including developers earlier in the discussion isn’t just about being nice and not hurting their feelings. It also creates real advantages. How can managers commit to deadlines when they don’t understand the actual work that needs to be done? What if the specified solution can’t be built in the time frame given? Either features will get cut, work will be hastily implemented, or the developers will burn out and quit. None of which are good outcomes.
There’s an old story about NASA trying to develop a pen that astronauts could use in space. It was tricky to get ink to flow upside down, and pens kept failing. We spent millions of dollars trying to come up with a space pen, until someone realized how the Russians solved the problem—they used pencils. Unfortunately this story is an urban legend, but it still gets told a lot in the software world. Like all good fables, this one illustrates a common mistake—the one where people set out to solve the wrong problem. The problem NASA needed to solve was not “How can we make a pen that writes upside down in zero gravity?” The real problem was “How can we write in space?”
Give developers problems, not solutions.
People in any field rise to the expectations set for them. It’s about setting high expectations for developers—not how much code can they grind out, but how well can they use their ingenuity and creativity to solve the world’s biggest problems.
Experimentation Is The Prerequisite to Innovation
Like trees, every big idea starts small.
Sometimes ideas come from teams on the front lines, and sometimes leaders might have the ideas. Wherever the idea comes from, the next steps should be the same. First, vet the idea. This doesn’t need to be exhaustive; there should be low activation energy for starting a new experiment. What you really want to know are just two things:
- What assumptions about customers, the problem, or the market are you making, and how will your experiment prove or disprove those assumptions?
- If you are wildly successful, will it be a big outcome? The point is to grow a big tree, so ask whether the seed you’re planting has that chance if it’s successful.
If the answers to the two questions listed above are reasonably good, then start with a small team. Maybe it’s a new team, or maybe it’s part of the work of an existing team, but five people should be sufficient to get the ball rolling. The key is not to tell them what to build, but to tell them which customer to focus on and which (hopefully) valuable problem you can solve for that customer. Those are the customer and mission parts of the team definition.
Next, agree upon metrics of success. The small team needs a set of metrics to define what a successful experimental outcome looks like. Note that these aren’t long-term business metrics; these are short-term experimental outcomes.
One common mistake companies make is not having a hypothesis that predates the experiment—meaning, they invest in testing out a technical hypothesis and even building prototypes without stopping to find out whether there is sufficient demand for the product. Someone says, “Hey, wouldn’t it be cool if we could . . .” Or sometimes an executive falls in love with an idea and commands engineering to pursue it.
That enthusiasm is cool, and great things often start there, but you shouldn’t proceed before developing the idea into a business hypothesis. Without that, you won’t know what your experiment is measuring. Success or failure will be ambiguous, and you’re just left with “Is it moving the needle yet?” To which the answer will almost always be no.
Recruiting and Hiring Developers
Recruit a Greater Leader—and the Rest Will Follow.
When Kevin Vasconi joined Domino’s Pizza in 2012 as the CIO, his mission was to build a completely new technology organization. At the time, Domino’s had 150 workers in IT globally. Eight years later that number has grown to 650, of whom only 50 were part of the group Kevin inherited. He began by turning to his professional network and hiring a strong core team. This wasn’t just executives. A good technical leadership team consists of senior architects, principal engineers, and line managers. The main thing is to make sure your early hires have strong technical chops. The first hires might also be the toughest. But over time it gets easier. Kevin’s advice to others—don’t rush and don’t settle.
Domino’s radical change over the past decade is a result of building a world-class software organization and turning developers free to create innovative and even eccentric software experiences. Think about using voice recognition or tapping an emoji to place an order. Some of those ideas started out with a whim. Ordering pizza at a stoplight might seem like a weird idea but it turns out it’s a real use case – the busy parents who don’t want to cook but order a pizza on their way home. This simple hypothesis opened up the door for years of innovations that make ordering and tracking your pizza a whole lot easier.
Continue Reading: < Developing Your Developers >