Hackers are not crackers

The story of how hacker culture moved from the margins of the software industry to centre stage in business innovation is a tale of our times. Before turning to this story, we need to clear up a misconception about hacking.

Hackers have a bad reputation. Thanks to the high profile Distributed Denial of Service (DDoS) attacks of hacktivist groups like Anonymous, political hacks like the attempts to interfere with voter registration databases in the 2016 US election, and criminal hacks like the Sony cyber-attack of 2014, in which hackers stole over 100 terabytes of data and planted malware to erase content from the company’s servers, many people have a dim view of the occupation. Hacking is perceived as a subversive, immoral activity. Films like Hackers (1995) and the HBO series Mr Robot portray hackers as lonely outsiders who fight corporations and governments. When hackers appear in the media, the article is typically headed with a shot of a shadowy figure hunched over a keyboard, looking like the Grim Reaper in a hoodie.

This is a misleading depiction of hackers. As Facebook CEO Mark Zuckerberg complains, the media’s depiction of hackers as ‘people who break into computers’ is ‘unfairly negative’, if not frankly untrue (Zuckerberg, 2011). It is true that a minority of hackers spend their time breaking through firewalls and security systems, planting viruses, and stealing money and data. But these activities do not reflect the actions and intentions of the hacker community as a whole. The majority of hackers repudiate the criminal actions of this minority. Hacker elders call these people ‘crackers’ to distinguish them from the norm. Eric Raymond writes:

There is [a] group of people who loudly call themselves hackers, but aren’t. These are people (mainly adolescent males) who get a kick out of breaking into computers … Real hackers call these people ‘crackers’ and want nothing to do with them.

Raymond distinguishes hackers and crackers as follows: ‘Hackers build things, crackers break them’ (Raymond, 2001a: 196). This is a distinction I maintain in this book.¹

Hacker mindsets and practices shape the operation of some the most successful tech companies of the twenty-first century, including Apple, Facebook and Google. Zuckerberg is so enthusiastic about hacking that he added a special section on hacking to Facebook’s initial public offering (IPO) document. ‘Hackers believe that something can always be better, and that nothing is ever complete’, Zuckerberg (2011) claims. They feel compelled to step up and make improvements, without waiting for permission. When a hacker sees a problem, ‘they just have to go fix it – often in the face of people who say it is impossible or who are content with the status quo’. If hackers move fast and break things, it is only to make things better. True hackers are driven by a desire for innovation.

How to become a hacker

Eric Raymond (who edits the online Hacker Jargon File and is responsible for several important publications on hacker culture) wrote the definitive answer to this question for entry-level open source software hackers (Raymond, 2001b). To master the art of software hacking, Raymond explains, you need to devote a few years to skilling up on an open source language like Java, PHP or Ruby on Rails. Once you’ve completed this work, go to GitHub, find a project that inspires you, download the software and play. Get to know the people in the community and share knowledge and ideas. Ultimately, the only way to learn how to become a software hacker is by getting hands-on with code and hacking it.

Raymond concedes hacking is a broader and more general activity than writing code. Hacking is an approach to solving problems. Understood in this light, anyone can be a hacker. Entrepreneurs hack business models, searching for new insights and opportunities. Marketers hack customer channels, experimenting with unconventional ways of growing a company’s customer base. Teachers hack classrooms, engaging students in retooling the educational experience. Musicians hack digital recordings, creating thrilling new mashups and mixes. Artists hack culture, combining creative practices and new technologies to subvert standing cultural frameworks and challenge audiences to think differently. To become a hacker, all it requires is a disruptive attitude, a questioning mindset and the determination to learn by doing.

Hacking is a problem-solving activity. Hackers solve problems by speculating on solutions, forging hypotheses and trying things out. What makes a hacker a hacker is the dogged persistence with which the individual keeps on trying and learns by doing. When you think of hacking, think of the sharp, persistent blows of a hatchet or machete, used to clear a path through a forest or field of grass. Hackers solve problems by running multiple, short, targeted experiments designed to clarify complications and illuminate the way ahead. They keep on hacking until they’ve identified a solution.

Typically, when presented with a problem, we grab at the nearest solution and try to implement it. Hackers will forge a hypothesis and run an experiment. While this adds complications, the process works out faster, as it helps to eliminate mistakes. The process can be reduced to the following steps, which serve as a potted guide to hacking:

The MIT hackers

Students were hacking the Massachusetts Institute of Technology (MIT) campus for decades prior to the birth of computer hacking. A hack, at MIT, is a prank aimed at transforming the campus environment in a surprising and humorous way. Legendary hacks include the time a team hauled a scale replica of a campus security vehicle to the top of the Great Dome, and the year a team turned the windows of the Green Building, the tallest tower in Cambridge, into the squares of a giant, full-coloured game of Tetris.

These kinds of stunts have long been part of the culture at MIT, where people affirm ‘interesting and creative work at a high intensity level’, even when it is distracting and annoying to campus authorities (MIT, 2017). A good hack at MIT is witty, benign and demonstrates considerable technical skill. These virtues were first attributed to computer hackers at the end of the 1950s, when a group of electrical engineers – members of MIT’s Tech Model Railroad Club (TMRC) – discovered a fascination for computers.

Computers at the time were giant mainframe machines, locked in air-conditioned rooms. They were monitored by an elite ‘priesthood’ of lab technicians, who were the only people allowed to touch them (Levy, 2010: 5). The technicians would feed batches of instructions into the machines on paper tape and wait hours for the computers to churn out a response. Members of the TMRC would peer jealously through the windows of the computer lab, seething at the thought that the secrets of computing were being kept from them.

When the Research Laboratory of Electronics (RLE) at MIT acquired a TX-0 from Lincoln Labs, the hackers got a chance to learn about computing their way. The TX-0 was one of the first user-programmable computers. It was officially intended for the use of graduate students and people working on funded projects. Levy commends the ‘canny’ wisdom of John McKenzie, the technician in charge of the TX-0, who ‘tolerated the crew of TMRC madmen who began to hang out at the RLE lab’, ignoring their habit of sneaking into the lab at night to play with the machine (Levy, 2010: 16).

There were no guidebooks to computers at the time. The hackers had to learn how to operate the TX-0 through trial and error. They would book time on the machine after midnight and code until morning. They programmed while the world was asleep, feeding interventions into the TX-0 on paper tape, and gathering about the screen to see the results. There was excitement in the room when an experiment produced a positive result. When an intervention failed, it was a learning experience. The hackers were playing at the limits of possibility, and creating a new engineering subculture in the process.

The subculture kicked into gear in 1961, when MIT acquired a PDP-1 computer, one of the first ‘minicomputers’ designed for scientific and academic research. By present day standards, the PDP-1 was an oversized number cruncher with the processing power of a pocket calculator. For the hackers, it was a vast new realm of possibility.

How was the PDP-1 constructed? What made it work? Removing the aluminum backplate, the hackers would rummage around in the guts of the machine, studying the circuit boards and carefully plugging and unplugging wires to see what made it tick. How might they interact with the machine, they wondered? What could they make it do? There was only one way to answer these questions. This was to get hands-on with the PDP-1 and hack.

The hackers programmed the PDP-1 to learn about it. They created assembly languages, debuggers and text editors – small tools that expanded the functionality of the PDP-1 and paved the way for new possibilities. Everything they built, they shared. Sharing was a core part of the MIT hacker culture. The governing view was that ‘information should be free’ (Levy, 2010: 28). When a hacker wrote a program, he put the paper tape he wrote it on in a drawer of the desk on which the PDP-1 sat.³ If someone wanted to pull out the program and hack it, taking the experiment to a new level, so be it. When a new hacker wanted to learn the tricks of the trade, all he had to do was hang out at the lab, ask questions and watch what was going on. When the neophyte was ready for hands-on hacking, he was welcome to join a project or head up his own. If he wanted to hack his peers’ work, that was fine too.

The hacker culture that emerged at MIT in the 1960s was haphazard, self-organized and largely unfunded. Nonetheless, it produced incredible results. In the early years of the 1960s, the MIT hackers created the first word processing system, the first interactive debugger, the first computer chess program and some of the earliest computerized music.

The computer game, SpaceWar!, was the MIT hackers’ most popular achievement by far. Initially created by Steve ‘Slug’ Russell, SpaceWar! enabled two players to guide rocket ships around the periphery of a television monitor, volleying missiles back and forth at one another against a background of stars. In the late 1960s, as US government research teams built the ARPAnet, the beta version of the internet, the best and brightest computer engineers were engrossed in SpaceWar! – not just playing it, but hacking and improving it.

By the 1970s, the hacker ethic had filtered out into wider society. Hacking moved west with the sixties counterculture, appearing in the pages of the Whole Earth Catalogue, and mingling with the spirit of DIY progressivism that defined the zeitgeist. In the heady atmosphere of 1970s San Francisco, the cyberculture and counterculture came together in the personal computer movement and hardware hacking scene (Turner, 2006). Hacking played a major role at the Homebrew Computer Club, facilitating the creation of the Apple I and other personal computer prototypes. Apple cofounder Steve Wozniak was a hacker. Wozniak wasn’t interested in building a company. He just wanted to build innovative circuit boards to show off to his friends at Homebrew (Levy, 2010: 256–257).

On the early internet, hacker researchers were building tools that would take hacking to new levels, like the programming language C, the lingua franca of the UNIX hacking community, and Whitfield-Diffie’s public key cryptography, which enabled secure communications over the internet. At the more playful end of the cultural spectrum, hackers were contributing to the early gaming industry, creating online games, Multi-User Dungeons full of monsters and treasure, and persuading video gaming companies to make ‘moddable’ games that could be hacked by the people who purchased the software.

The breakthrough moment in the history of hacking was the creation of the open source computer operating system, Linux. Linux was the moment when hacker culture scaled.

The Linux experiment

On September 17, 1991, Finnish computer science student Linus Torvalds announced on UseNet that he’d completed a rough version of a MINUX-based computer operating system. Linus was excited about his achievement, but he had taken the system as far as he could develop it independently. He was looking for suggestions towards improving it.

Torvalds had built the operating system using the toolkit developed by the Free Software Foundation (FSF), a hacker collective led by MIT veteran Richard Stallman. Stallman had been working on a ‘free’ (in the double sense of freely hackable and cost-free to download and use) operating system since the mid-1980s. While the FSF had completed chunks of the system, Stallman had failed, to this point, to create the kernel for the system. Unfortunately, this was the essential component, without which there is no operating system to speak of.

Torvalds had cracked it, working alone. In hacker style, Torvalds announced that he intended to share the source code for the kernel under a General Public Licence (GPL), a ‘copyleft’ agreement created by the FSF to distribute its work. Code licensed under a GPL can be hacked and adapted to any use, but the GPL applies to derivatives, so any products of the work must also be made available for use.

Torvalds (1997) claimed: ‘Making Linux GPL’d was definitely the best thing I ever did.’ GPLing his code, Torvalds launched the Linux experiment, the largest sustained hackathon the world has ever seen.

In 1991, hacking was a fringe element of internet culture. The 1983 Matthew Broderick film, War Games, had stereotyped hackers as teenaged computer nerds, clever but essentially clueless, mucking around in the margins of the military–industrial complex. This narrow depiction underplayed the diversity, erudition and impact of the hacker tradition to date, but it got one thing right: hacking was marginal, even in the context of tech culture.

Linux’s success changed that. Linux signalled that hacker culture had come of age. When Torvalds placed his source code files online and invited people to hack and improve them, he drew a line in the sand between the old world of planning- and management-intensive software development, and the new world of agile, experimental, collaborative hacking. This act was a rallying cry for hackers the world over.

When hackers around the world discovered there was a URL address they could visit to collaborate on a free operating system that anyone could download, install and use, they stepped out of the shadows and into the light. Linux gave the international hacker community a home. It created a platform for hackers the whole world could see and gave hackers everywhere a reason for being.

In addition to raising the profile of the hacker community, Torvalds systematized the hacker way, enabling it to operate at scale. As Raymond (2001a: 27) claims, ‘Linus’ cleverest and most consequential hack was not the construction of the Linux kernel itself, but rather his invention of the Linux development model.’ By ‘open sourcing’ his code, making it freely available to a community, Torvalds enabled any number of contributors to participate in the project. People could download the code (a time-consuming task in the age of dial-up internet connections), scour it for bugs, add fixes or take things in a new direction. Once they were satisfied with their work, they would submit their changes to Torvalds, who would vet the submissions and add them to the codebase.

This development model took the best elements of MIT hacker culture and updated them for the era of the internet. It harnessed the connectivity of the World Wide Web to make space for innovation at a global level. The model proved astoundingly successful. It enabled Linux to enlist an army of contributors, rapidly scaling the development project. The model made difficult jobs easier by maximizing the talent and attention applied to them. The more hackers worked on Linux, the greater chance there was of someone having the right set of skills to identify a problem and develop a fix, fast.

Raymond (2001a: 30) calls this Linus’s Law: ‘Given enough eyeballs, all bugs are shallow [i.e., easy to solve].’ Linus’s Law is the underlying principle of ‘open innovation’, a crowdsourcing strategy used today by companies including IBM and Intel, and websites including Wikipedia, Quora and Stack Overflow (Chesbrough, 2003).

By the late nineties, the business community was paying attention. ‘Who would have thought … that a world-class operating system could coalesce as if by magic out of part-time hacking by several thousand developers scattered all over the planet’, Raymond (2001a: 21) muses, reflecting on the sense of astonishment at the time. Linux’s growth was something to behold. The more widely known the project became, the more talent and diversity flocked to it. The more talent and diversity flocked to the project, the better the codebase became, and the more companies and institutions trusted Linux and used it.

Today, Linux is used in finance, science, military and government. The New York Stock Exchange automated trading system runs on Linux. CERN, the European Organization for Nuclear Research, uses Linux on a massive scale. The US Army is ‘the single biggest install base for Red Hat Linux in the world’ (Wikipedia, 2017). The Industrial and Commercial Bank of China uses Linux in all its 20,000 branches. Federal and civic governments all over the world run on Linux software, which is agreed to be more reliable and secure than the Windows operating system, with the not inconsiderable additional benefit of being free.

As of 2015, the Linux kernel had received contributions from over 13,000 people, who’d added more than 19 million lines of code (Phoronix, 2015). The Linux system is constantly being hacked, debugged, updated and worked over by thousands of people, including lone operators, employees of software-as-a-service companies like Red Hat and SUSE, and teams working for large software companies, including IBM and Microsoft.

Linux, moreover, is just one of many free and open source (FOSS) projects. GPL allows hackers to ‘fork’ projects, taking them in new directions. Thanks to this provision, there are dozens of Linux derivative projects, including Debian, Ubuntu and Mint, each with its own family of derivatives. Open source licensing enables anything to be open sourced, from code, tools and systems to designs, policy documents and genetic material. GitHub, an online hosting service for open source projects, has over 19 million software repositories coded in more than 316 open source programming languages (GitHub, 2016). GitHub’s slogan encapsulates the essence of the FOSS movement: ‘Build software better, together.’

The success of open source captured the imagination of a generation. It decisively impacted the innovation culture of the startup industry, where hackers, designers and entrepreneurs work cheek by jowl building digital products. By the mid-aughts, hacker entrepreneurs like Mark Zuckerberg and Twitter’s Jack Dorsey, who’d cut their teeth on open source projects, were building online social networks that mirrored the collaborative norms of the Linux community, coding these platforms using open source software.

Hacking, for these entrepreneurs, was more than an approach to software development. It was an approach to business development and to life itself. As the aughts rolled into the 20-teens, the hacker culture championed by these entrepreneurs spread across the tech and business landscape, in Silicon Valley and elsewhere. The hacker culture shift had begun.

If a single date could mark the point when hacker culture crossed into the mainstream, it would be January 31, 2005, when Linus Torvalds made the cover of BusinessWeek, posing alongside the Linux penguin. Steve Hamm claims: ‘Linux Inc. has emerged as a model for collaborating in a new way on software development, which could have reverberations throughout the business world’ (Hamm, 2005). Few people at the time were aware how deeply these reverberations would be felt, and what hierarchies they would topple over.

The startup triad

Crises can be cathartic. When the dot.com bubble burst in 2001, it popped the pretensions of a generation of entrepreneurs who believed their every idea was gold. Venture capitalists, at the time, were too eager to believe in the potential of a dot.com based on a business plan alone. When the bubble burst, these entrepreneurs and investors were forced to admit that most of their business plans weren’t worth the paper they were printed on.

The dot.com crash forced the tech community to pause and rethink. With investors running for the hills, entrepreneurs had less money to build software systems from scratch. They began using open source tools to build businesses, and hacker strategies to launch and scale them. They took the advice of their technical cofounders, who encouraged them to work iteratively, running experiments by building prototypes and testing them with customers to see what worked. Instead of launching their vision in a single go, entrepreneurs bootstrapped businesses in development cycles and sprints, focusing on learning as much as they could about the markets they were entering, customer preferences and behaviours – all the things they needed to know to make their businesses successful.

Hacker culture took hold in Silicon Valley by changing the way entrepreneurs approached new business development. It introduced a note of humility into entrepreneurship, forcing entrepreneurs to admit that they didn’t know what they needed to know about customers, markets and technologies in advance of launching their businesses. They needed to prototype something and test it to find these things out.

Three key innovation practices crystallized the hacker culture shift: agile development, lean startup method and design thinking. These practices, which became paradigmatic in the startup scene in the 20-teens, express mindsets and values that infiltrated the industry in the decade before. I call these practices: ‘the startup triad’. Like the three notes of a triadic chord, agile development, lean startup method and design thinking resonate together, facilitating communication between developers, entrepreneurs and designers, enabling them to easily revise and improve on their work and to innovate on the process of innovation itself. They share the following common elements, reflecting their hacker origins:

i. Agile development

Scrum is the most popular and influential form of agile development. Developed by Ken Schwaber and Jeff Sutherland, two of the signatories of the Agile Manifesto (2001), scrum involves small teams working in short, iterated cycles called sprints. Scrum method integrates the values and principles outlined in the Agile Manifesto, a document developed by agile practitioners for agile practitioners. To capture the flavour of agile development, it helps to reconstruct the process of a scrum team working on a standard project (Figure 1.1).

The scrum process involves a continuing series of interactions between the customer and the development team, mediated by a team representative known as the product owner. The process begins with a requirements meeting between the customer and the product owner, in which the customer explains everything they need the product to do. Following this, the team gathers for a sprint planning meeting, in which they discuss what they will attempt to build in the first sprint. Instead of planning to build the entire product in one go, the team tries to figure out what it can achieve in the duration of the sprint, which is typically between one to four weeks in length. The goal in each sprint is to complete a chunk of working software that meets some key requirement of the functional whole. The customer can then play with and reflect on this software before deciding how to proceed.

The sprint planning meeting is a highly collaborative session. Each member of the team volunteers their skills to tackle different parts of the work, and seeks to coordinate their activities with those of other team members, so as to maximize the productivity and effectiveness of the team. Once the team has determined the work they will attempt in the sprint, they draw up a sprint backlog listing the jobs to be done and launch into the work.

Sprints are fast, fluid and cooperative. Each day begins with a 10 to 15-minute stand-up meeting, in which team members stand in a circle and share what they did yesterday, what they are doing today, and what is hindering or blocking their work. This keeps the work transparent and gives team members the opportunity to help one another out, suggesting workarounds or volunteering for unexpected tasks that pop up during the sprint. While each team member is free to decide what he or she will work on in the sprint, it is taken for granted the team will collaborate to achieve its common goals. The level of trust and team spirit implicit in the process inspires everyone to pitch in with their best work and ideas.

Ideally, scrum teams will include a cross-functional set of talents. Commercial teams have a scrum master, whose job is to facilitate the work. The scrum master helps team members resolve internal tensions, overcome blocks, make decisions and generally stay on track. The scrum master additionally seeks to ensure that team members exemplify cultural values conducive to collaborative hacking. If there are tensions between team members, or if someone is poisoning the well by exhibiting pessimism or unconstructive behaviours, it slows everything down. The scrum master should lead by example, encouraging people to invest themselves emotionally in the work, and to create a safe space where everyone feels empowered and supported, unafraid to propose ideas and to explore creative solutions.

Scrum teams build software the hacker way. They start by identifying the riskiest assumptions implicit in their proposed designs and build prototypes to test them. If a strategy doesn’t unfold as expected, the team tries a different approach. Their goal is to complete the jobs they committed to in the planning meeting by any means necessary.

At the end of each sprint, the team demos what they’ve built for the customer and solicits their feedback. The customer reflects on what the team has created, and considers any factors that may have changed during the sprint that might lead them to reconsider the project. The customer can reorient the project at this point by changing the product requirements. For customers, this agility is incredibly valuable, given the uncertainties involved in delivering software products to volatile marketplaces, where new technologies and competitive forces can transform the field overnight. It helps customers to manage the risk involved in development projects and to avoid building products no one wants to use.

Once the customer has reviewed the product requirements, the team engages in a second sprint planning meeting to decide how to proceed. Depending on the customer requirements and what the team has learned in the first sprint, they might keep on working in the same direction or pivot towards a new one. The team draws up a new sprint backlog, and launches itself into a second sprint. The team repeats this cycle until the product is complete. In each cycle, they build on and refine the work they’ve done before, assembling the product piece by piece, responding to the customer’s changing requirements.

ii. Lean startup method

Lean startup method is the hacker way applied to entrepreneurship. It is a fast, agile approach to testing business ideas, finding product-market fit and scoping out a viable model. Like hacking itself, lean startup method is fundamentally a form of knowledge work. Lean entrepreneurs work to test business model ideas under marketplace conditions. They iterate their ideas through multiple experiments, perpetually sustaining the possibility of pivoting on their business model design, until they zero in on a model that works (Figure 1.2).

Usually, accounts of the origins of lean startup method begin with the seminal work of Steve Blank and Eric Ries, whose reflections in blog posts and published writings popularized the lean approach. Blank initially articulated the principles of lean in his book, Four Steps to the Epiphany (Blank, 2005). Blank is currently writing a multi-volume series of guidebooks for lean entrepreneurs with Bob Dorf (Blank and Dorf, 2012). Eric Ries audited Blank’s course on business development at Stanford in the mid-aughts. Ries clarified the importance of Blank’s ideas for web entrepreneurs in blog posts leading up to the publication of his book, The Lean Startup (2011). The Lean Startup was a bestseller and launched the lean movement.

Without denying the importance of Blank and Ries’ work, it overstates their achievement to say that they invented lean startup method. Blank and Ries happily admit that they synthesized the method from their observations of what innovative entrepreneurs were doing at the time.⁴ Blank and Ries picked up on the way that startup entrepreneurs were learning from agile method and hacker culture. Their achievement was to document and formulate these practices, much like Luca Pacolini documented the principles of double entry bookkeeping used by Italian merchants in fifteenth-century Venice (The Economist, 2014).

What impressed Blank and Ries about agile is the way it focuses entrepreneurs on learning about market conditions, instead of egotistically assuming they know their way around. The hacker way is an evolutionary adaptation in the context of rapid technological and economic change. Lean startup method increases a startup’s chance of survival by forcing the founders to focus on what they don’t know but need to know in order to deliver the right product to the right market in the right way at the right time. Relative to hacker entrepreneurship, the management-intensive, stage-gate innovation processes of traditional companies look like cumbersome relics from the age of the dinosaurs.

A startup is not a business per se. It is a proto-business, the idea and aspiration of the founder and founding team – untested, uncertain, ultimately little more than a dream. The startup idea is uncertain because it is full of unknowns. The founder may have an idea for a product or service, but she probably doesn’t know who the customer is, whether the customer will pay money for the product or service, or if they will, how much they will pay. She doesn’t know what the company’s overheads will be, or if she can rely on the partners and suppliers she has in mind. All she really knows is that her idea has potential. As an entrepreneur, she is looking for a way to actualize this potential and make it real.

Blank has a word of advice for startup entrepreneurs: ‘Get out of the building!’ The answers that the entrepreneur needs will not fall from heaven. Instead of wasting time speculating about things, entrepreneurs need to get out of the office, find people who might like their idea and see what they make of it. They need to run some customer experiments.

Like agile developers, lean startup entrepreneurs test their ideas by building prototypes and trialling them with customers. This might involve building a Minimal Viable Product (MVP) – although an MVP is often unnecessary at the early stages of business model development. The most important thing an entrepreneur needs to do is to identify the riskiest assumptions inherent in her business model and test them (Higham, 2016). Risky assumptions are assumptions the entrepreneur needs to get right for the businesses to succeed. Facebook, for example, started with the risky assumption that students at colleges with a thriving social scene would be interested in online social networking. Zuckerberg tested this assumption by launching Facebook through a series of experiments with select Ivy League colleges before opening membership to a wider community of people.

Ries’ iteration of Blank’s ideas coincided with the publication of another influential text, Osterwalder and Pigneur’s (2010) Business Model Generation. This book popularized the Business Model Canvas (BMC), which has become a familiar tool for entrepreneurs and consultants. Using a BMC, entrepreneurs can detail each element of their business model, including their value proposition, customer segments, sales channels, cost and revenue structures, and more. Mapping these elements helps entrepreneurs to identify the assumptions they are making, so they can step back and start questioning them.

Lean startup entrepreneurs test each aspect of their business model the hacker way, by building prototypes, testing them with customers, learning from the experience and feeding these learnings back into the business. Ries calls this process the ‘lean feedback loop’. The process of designing a web startup involves running multiple, adaptive A/B tests, each one geared to cast light on the costs, risks and opportunities related to the business. Ries underscores the value of working at speed. The faster entrepreneurs can cycle through the lean feedback loop, the more they de-risk the project, reducing costs and discarding unworkable ideas, and the faster they can define a path to success. With each iteration, the team learns more, enabling them to fine-tune their offering and create something special.

This is hacking for entrepreneurs. It involves building lightweight prototypes, testing them with customers, measuring the results and iterating the design based on what is learned. Failure to identify a viable model doesn’t necessarily doom a startup. If, after many experiments, it turns out the original idea won’t work, the founder and team can consider pivoting in a new direction, leveraging what has been built and learned along the way to seize opportunities they may not have been aware of at the start of the process.

iii. Design thinking

In the early days of the hacker tradition, hacks were rarely pretty. They tended to be rough and ready, fit for purpose. The iterative nature of the hacker way encouraged the view that it was unnecessary to fancy things up, or even finish them off. Someone else would knock the design into shape further down the line. What was important was to get the job done. Most hackers were happy to leave aesthetics to someone else.

Even if they are ambivalent about beautiful design, hackers have always been passionate about elegant solutions. To hackers, an elegant solution is the most beautiful thing in the world. Elegance is a mark of excellence. A good hack is elegantly simple and effective.

Hackers’ appreciation for elegant solutions permitted a marriage between software hacking and design, which bore design thinking. Hacking and design were introduced through UX design, a branch of digital design that specializes in creating pleasurable and intuitive experiences for users. UX designers work with cross-functional teams to solve complex problems, building prototypes and working with customers to find solutions that delight them. UX design forged a bridge between software development and product and service design, allowing the agile practices of the former realm to flow into the latter.

By the mid-aughts, leading designers in Silicon Valley were reframing their practice in light of the new thinking. David Kelly and Tim Brown, cofounders of the design firm IDEO, coined the term ‘design thinking’ to capture the new mindset. Design thinkers are less interested in making things look pretty than they are in solving problems. They start out by developing a rich and detailed understanding of the customer’s problem(s), brainstorm a set of potential solutions to these problems and test them for desirability, feasibility and viability.

IDEO’s model of design thinking has become a standard reference for students of design and design practitioners. The five phases of the model – Empathize, Define, Ideate, Prototype and Test – are not meant as stages to be worked through in a linear way, but as key modes of thinking and doing that designers should employ in the process of solving problems. The IDEO model is taught at the Hasbro School of Design, or ‘dschool’, at Stanford University, effectively the home of design thinking in Silicon Valley. Students at the dschool come from the arts, sciences, business and engineering. They work in multidisciplinary teams to solve social and economic problems. They build 3D prototypes of their ideas and test them with users. They hack at problems until they have identified desirable, feasible and commercially viable solutions.

Like agile developers, design thinkers work in self-organizing, cross-functional teams. Cross-functionality ensures that a wide range of knowledge and experience are included in the design environment. With many eyes, all design problems are shallow.

In the context of the team, the design lead has a role akin to the scrum master. His job is to focus and steer the collaborative energy, facilitating the process of co-creation instead of directing it. Customers and other stakeholders are enlisted as co-designers on the team, with an equal voice in the proceedings. This creates a democratic, non-hierarchical environment, in which everyone has an equal opportunity to input ideas and shape outcomes.

Like in agile, the design team starts with a simple brief providing them with a broad understanding of the problem they seek to address, without stipulating a solution. The team’s job is to collaboratively propose solutions through a process of hacking and learning.

The design thinking process (Figure 1.3) begins with an attempt to empathize with the end user – the person for whom the team is designing. Usually the design team will spend time with the user, trying to develop a holistic, contextualized understanding of their life, world and challenges. This process helps the team to enumerate and distinguish the various elements of the problem they are seeking to address and to carefully specify the jobs to be done.

Once they’ve come to grips with the problem they’re dealing with, design thinkers brainstorm ideas to generate multiple potential solutions. They go wide with ideas, giving themselves licence to come up with crazy solutions that probably won’t work. After exhausting the possibilities, they take a critical approach and draw up a short list of options. Zeroing in on the best options, they put the ideas to the test by building lightweight prototypes and trialling them with customers. This is where hacking comes to the fore.

Prototyping design concepts to show to customers has always been a part of design practice. But design thinkers cycle through the process of prototyping and testing at pace, transforming prototyping into a kind of rapid-fire experimentation. Like lean entrepreneurs, design thinkers iterate the process of building and learning as quickly as possible. They are always prepared to rethink their approach and pivot. Testing ideas reveals customer ‘pain points’, clarifying the precise nature of their problems and needs. Often, the process brings to light features of the customer’s experience that the team hadn’t noticed before, which can shift their perspective on the challenge. This can lead a team to reconsider their initial assumptions and return to the empathy phase of the design thinking process to start again.

Thanks to their common roots in hacking, agile development, lean startup method and design thinking are easily mixed and matched. Often, teams working on complex challenges will take different elements of these practices and combine them to suit. An example is the Design Sprint, pioneered at Google Ventures. The Design Sprint is a five-day problem-solving process for cross-functional teams. In the space of a week, the team defines a challenge, sketches competing solutions, selects one, prototypes it and tests it with customers. The process combines elements of agile development, lean startup method and design thinking, mixing them up to create something unique and exciting (Knapp et al., 2016).

Design sprints reflect the continuing evolution of the startup triad. This is a complex, messy process of experimentation and learning. It is far from complete. Despite their considerable impact, agile development, lean startup method and design thinking are simply the first iteration of the new generation hacker toolkit. They are prototypes, waiting to be hacked.