3 The agile organization
Few people would associate Microsoft with agile innovation. The software giant is still shaking off its reputation as a lumbering, bureaucratic corporation that made a ridiculous amount of money in the nineties selling boxed software to desktop computer users. Until recently, Microsoft was notorious for its long production cycles and delayed releases. Internally, Microsoft had a reputation as a software sweatshop, where understaffed teams worked ‘death marches’ of sixteen hours a day, seven days a week, fixing thousands of bugs.
In 2011, Microsoft quietly began transitioning its Developer Division to agile. The transition was a big deal for the division, with over 4,000 employees working in hundreds of teams. It required a considerable effort of funding, coaching and cheerleading.
Microsoft Corporate VP Brian Harry was an agile evangelist from the start. ‘It’s clear that the Agile family of development practices have become very well established’, Harry told the Visual Studio team in 2011. Agile practices have become ‘table stakes’ for teams, Harry observed, with many companies using ‘the best of Lean and Agile together’ (Harry, 2011). Innovation culture was evolving fast, and Microsoft could not afford to be last to the party.
Microsoft was facing an extinction-level event. The ‘waterfall’ development approach the company had used for decades was too slow for the digital economy. Prior to 2011, Microsoft developers built software in two-year cycles. These cycles included four to six months of planning and design, followed by six to eight weeks of coding, and a four-month stabilization cycle of testing and debugging. After a public beta release, there would be another four months of stabilization before the product was complete (Bright, 2014).
By 2011, this laborious process was impacting on Microsoft’s bottom line. The software industry had changed, and customer expectations were changing with it. Customers expected to receive software updates at regular intervals, delivered directly from the cloud. They expected also to be surprised and delighted by updates, not just to have them smarten up an old product. Microsoft needed to deliver on these expectations, or it was finished.
It took Microsoft ‘about a year’ to figure out how to apply agile method (Denning, 2015). The cultural shift required to calibrate agile practices took even longer. It wasn’t until 2015 that Microsoft felt confident enough with its performance to publicize its transformation. The company’s buoyant share price since 2015, and its rising profile as an innovation leader, testify to the success of the strategy. Microsoft’s Windows 10 operating system, and its new lines of smartphones and tablets, are offspring of its agile regime. With the release of its HoloLens augmented reality suite, Microsoft is leaping ahead of the competition, breaking open new markets and creating the consumer technologies of the future.
IBM transitioned to agile around the same time as Microsoft. Remarkably, IBM seeks to apply agile right across the company. Chief Information Officer (CIO) Jeff Smith saw agile’s potential as a management tool while implementing agile at the Australian bank, Suncorp. With Smith’s help, IBM has learned to see agile as a broad purpose management system, a set of ‘methods and practices for running a company’ (Smith, 2016b).
IBM is leading a trend. A 2015 McKinsey report found that large companies in a number of industries are experimenting with agile practices and ‘realizing modest benefits from them’ (Comella-Dorda et al., 2016). The philosophy of small teams, working in sprints, taking bite-sized chunks out of project backlogs that are constantly revised in light of new learnings is taking shape as a management paradigm.
The trend is particularly evident in the banking industry. In Australia, the four major banks have all implemented agile management, not only in their technology and digital teams, but in other areas such as marketing and consumer and business banking as well. Commonwealth Bank started using agile in 2012. Since this time, it has trained over 3,500 staff in agile work practices. Commonwealth Bank currently has ‘45–50 scrum teams working on digital apps, with a further 150 delivering projects to other parts of the bank’ (Gluyas, 2017). Agile has decisively changed the bank’s culture, focusing the entire workforce on customer engagement, digital innovation and rapidly responding to market needs.
McKinsey cautions that not every company is able to scale agile management practices into a full-blown agile transition. It notes in its 2015 report that less than 20 per cent of the companies trialling agile projects consider themselves to be ‘mature adopters’. Yet, in industries like banking and telecommunications, marked by the widespread adoption of agile practices, companies have little choice but to learn to play by the new rules. McKinsey estimates that companies that are able to scale agile practices can ‘[accelerate] their innovation by up to 80 percent’ (Comella-Dorda et al., 2016). This gives these companies a powerful advantage over traditionally structured competitors. The question in these industries is not whether companies should embrace agile management practices, but how quickly they can do it.
The fact that large, well-established companies outside the software industry are applying agile practices, not just in their IT divisions but in core business functions, indicates a fundamental change in the way that business leaders think about work and innovation. The rise of hacker innovation culture is driving deep, structural changes in organizations, resonating from the upper echelons of management right down to the work of junior employees. Progressively, in fits, starts and sudden leaps, large companies are become agile organizations, deploying new leadership, management and cultural practices to enable small teams to hack at problems, working with customers to rapidly produce solutions that are developed, iterated and perfected in sprints.
In the process, these companies are shedding layers of management. Agile method and hierarchical management do not mix. Old-school dictators are a spanner in the works. Leaders must be Chief Experimenters, delegating responsibility for decision making to people working directly with customers in scrum environments. Management’s role is primarily to get the right set of experts and stakeholders in the room, and to put a minimal set of metrics and controls around the creative process – just enough to give teams clear guidelines for their work, but not so much as to kill the spirit of innovation.
Agile is a cultural practice and like any cultural practice it needs room to flourish. Companies that start with culture, train people in the appropriate practices and limit management interventions to keeping the work on track find that agile method practically runs itself. The main challenge traditional companies face in embracing agile method lies in making space in the organization to enable teams to do their work, free from organizational politics and meddling managers who can’t resist quantifying progress and cracking the whip.
This chapter examines the unique combination of hacker leadership, entrepreneurial management and innovation culture that makes agile organizations work.1 In keeping with the cultural focus of the book, we start by reflecting on the mindsets and values required to enable high performance in agile teams. These mindsets and values can be seen in coworking spaces, which are often the preferred work environments for agilists and hackers. The fact that the mindsets and values required for agile work feature in coworking spaces should come as no surprise, since agile development and coworking share a common cultural ancestor. Both are descended from hacker culture.
Coworking culture
‘HUBBERS DO EPIC SHIT.’ These words, stickered to the lid of a laptop, grabbed my attention when I arrived at the ‘Coworking in the Park’ event organized by Hub Australia in February 2013. The park was Wynyard Park, perched above Sydney’s central business district (CBD), a stone’s throw from the Harbour Bridge. On this day, it was occupied by coworkers. Distributed at tables around the park were dozens of coworking teams, representing members of ten local coworking communities. The coworkers had assembled for the day to promote the coworking movement. The Hubbers stood out by the insouciant stickers on their laptops.
At one end of the park, a crowd of young people milled about a brightly coloured geodesic dome. Local entrepreneurs were delivering lightning talks to the crowd, relating tales of their triumphs and challenges. Hip young folk reclined in low black beanbags, lap topping away, taking advantage of the free Wi-Fi. A bubble machine blew clouds of translucent spheres over their heads. The mood was sunny-side up and a little bit quirky.
‘Now, this is working’, I thought. Though it looked suspiciously like play. The lorikeets in the trees and the ibis that patrolled the park’s perimeters knew us for the interlopers we were. I like to imagine that the tourists who saw us gathered in Wynyard Park that day left thinking that, in Sydney, coworking is the most natural thing in the world.
Hub Sydney didn’t have a coworking space at the time. Its Darlinghurst premises – two floors in a renovated warehouse on William Street, near Kings Cross – were under construction. In the interim, the Hubbers had occupied Wynyard Park. I wandered through the park, wondering what the social norms were in a space that wasn’t quite a workplace and wasn’t just a public park. I figured I should try not to bother anyone who looked busy. Then again, as a banner bearing Hub Australia’s motto – ‘innovation through collaboration’ – reminded me, coworking is all about making connections. The scene was set for unexpected encounters. The coworkers set the scene by holding space, together.
Mention coworking and people immediately imagine an open plan office, in which people rent desk space. But coworking doesn’t require a room per se. A coworking space is fundamentally a social space, created through cooperation and solidarity. The ‘Coworking in the Park’ event demonstrates this idea. By holding space together, the Hubbers and other coworkers transformed Wynyard Park into coworking space. This was a space without walls or fixed boundaries, a space of human interactions and possibilities that existed only to the extent that the coworkers kept it alive. They kept it alive by investing themselves, cognitively, emotionally and behaviourally, in the mindsets and values of coworking culture.
Theatrical performers create space in a similar way, using actions, costumes and props to conjure up imaginary worlds for audiences to enjoy. But theatre implies a division of labour between the performers, who establish the space, and the audience, who enjoy it. Coworking requires that everyone participates in the space-making activity. By holding space together, coworkers create an environment for conversations, encounters, learning and discovery. Agile innovation teams create space in a similar way as a condition of their work. Their way of holding space expresses a shared understanding of ‘how we get things done around here’, which, like coworkers, they have inherited from the hacker tradition.
Coworking spaces evolved out of hackerspaces – community spaces for programmers. The first hackerspaces emerged in the 1990s, with the birth of the open source movement. C-Base, the world’s first hackerspace, launched in Berlin in 1995. It offered its members desk space, an internet connection and a community, which is no small thing for bedroom-bound hackers, who collaborate online, but rarely get the chance to meet in person.
The early hackerspaces gave a technological tribe, who already shared mindsets, practices and a complex jargon, the opportunity to connect face to face. They brought online hacker culture down to earth, introducing a new generation of engineers and hobbyists to the hacker ethic and the value of sharing, collaboration and experiments.
Through the nineties and aughts, the hackerspace movement scaled internationally. It fed into the maker movement, inspiring MakerSpaces, FabLabs and not-for-profit organizations like Tech Shop. It inspired the rise of Biohacker Spaces, where DIY biologists apply the hacker ethic to genetic engineering. It simultaneously inspired a generation of entrepreneurs to reinvent their conditions of work. This was the origin of coworking.
Brad Neuberg launched the first official coworking space in San Francisco in 2005. Neuberg, a programmer, was looking for work–life balance. He was working for a startup at the time, but he yearned for independence. The trouble was, when he worked from home, he struggled to stay motivated and he missed the collegiality of the office environment.
When Neuberg learned that the Spiral Muse Feminist Collective had rooms to rent, he decided to try an experiment. Neuberg decided to create a shared work space with the culture and feel of a hackerspace, which would be open to everyone, not just hackers. It would be like working at Google, without having to work for a corporation. Neuberg had a cool name to help market the concept: ‘coworking’ (Neuberg, 2014).
The Spiral Muse space launched with minimal fanfare. Neuberg had eight folding tables, which he set up and dismantled himself. Rather than lavish money on the layout, Neuberg focused on creating the right cultural norms in the space. Members of the Spiral Muse space enjoyed shared lunches, meditation breaks, free back rubs and bike rides around the local streets. It was very San Francisco. For Neuberg and his friends, it hit the sweet spot.
At first, others were unconvinced. The coworking concept took a while to catch on. The idea of cheap desk space had obvious appeal. But not everyone appreciated the cultural dimensions of what Neuberg was trying to achieve. Neuberg tried spruiking the concept at local cafés, without much success. It wasn’t until Neuberg’s friends, Chris Messina and Tara Hunt, started spreading the word at Bay Area Bar Camps that memberships at the Spiral Muse space picked up.
Bar Camps are informal ‘unconferences’ for hackers. Participants use Open Space Technology (see Chapter 4) to create highly social, participatory environments for sharing knowledge and ideas. Bar Camps had only been around a few months when Neuberg launched Spiral Muse, and people wanted more. Messina (who happened to be one of the founders of the Bar Camp movement) suggested that coworking was an opportunity for hackers to do Bar Camp every day. The idea clicked and people began signing up in droves.
The Spiral Muse space soon filled to capacity. To accommodate demand, Neuberg, Messina and Hunt opened two more coworking spaces in quick succession: The Hat Factory, in 2006, and Citizen Space, in 2007. When people approached the team, asking how they could help promote coworking, they replied in open source style: steal the idea. People complied. Before long, coworking spaces were springing up across the US and the world. When The New York Times ran its first article on coworking in 2008, there were hundreds of coworking spaces in existence (Fost, 2008). Today, there are over 8,000 coworking spaces worldwide, with numbers increasing (King, 2016). WeWork, a global coworking company, has more than 120,000 customers in 156 offices and is valued at over USD20 billion.
In 2017, coworking is mainstream. Property developers build coworking spaces into their corporate developments. Corporations, meanwhile, look to coworking companies for insights into how to revitalize their stale and uncreative workplaces. These corporations are losing some of their best people to coworking spaces. Hub Sydney is full of corporate refugees – people who have left high-paying jobs for a freelance career, sick of the hours, stress, culture and the uncomfortable sense of compromising their values.
For a talented freelancer – a videographer, designer, developer, recruiter or business strategist – coworking has clear advantages. You escape the leaden atmosphere of the corporate office, for a start. You get to work in a chilled-out, social space, where people have fun and the rules are informal and relaxed. The primary advantage of coworking for freelancers is the in-house network of partners, contractors and leads that comes with the space. Combine this with a community culture that makes it easy to connect with people and create opportunities and you have a recipe for small business success.
A coworking space is more than just a physical space. It is a human operating system that works to bring people together and connect people with similar needs and interests. Coworkers eat together, congregate informally during the day, and gather at workshops and community events in the evenings. They get to know each other as people, not just professional ‘types’, forging friendships and, not infrequently, new business opportunities.
The social dynamic that enables these personal and professional connections doesn’t happen by accident. The participants in the space build it themselves. Coworkers don’t passively cohabit space. By being open-minded, friendly, helpful and authentic, coworkers actively make space for collaborative engagements, creating the cultural milieu that binds the community together. At Hub Sydney, the members of the community are constantly giving to the community so as to derive benefit from it, working at sustaining a social vibe and feeding the space with care, knowledge, expressions of talent and generosity of spirit.
Caroline McLaren, a cofounder of Hub Sydney and Principal at CoActiv8, a company that creates coworking spaces for corporate and government clients, argues that a gifting mindset is crucial for coworking success. ‘People who come to coworking spaces looking to share their talents and networks tend to thrive’, McLaren observes. By investing themselves in the community, they mark themselves out as ‘givers’ rather than ‘takers’, which encourages others to give back to them in large and small ways.
Self-interested people, by contrast, don’t fit in. These people ‘aren’t open to the possibility of what could be’, McLaren claims. They fail to grasp how generosity creates an environment for reciprocity, fostering the conditions for opportunities to emerge. They are blind to the emotional dynamic that keeps the community humming and holds it together.
This insight into coworking culture applies equally to agile organizations, and indeed any environment where people work collaboratively in teams. A shared workspace is not a coworking space, any more than a group of people who happen to work together are a team. It is only when people invest emotional labour in their work that a workspace becomes a coworking space and a group of people becomes a team. Emotional labour is the glue that holds coworking communities and collaborative teams together. The more emotional labour people invest in the work, the better they cohere. As Seth Godin (2012: 43) claims, ‘emotional labour scales in that a little more emotional labour is worth a lot’.
Investing emotional energy in teamwork seems like a simple thing to do. But it is hard to sustain under pressure. It takes work – emotional work. Emotional labour is an important precondition of agile work, essential for creating the shared values and mindsets that enable teams to manage themselves. This is something that traditional managers tasked with implementing agile practices often fail to appreciate. Successful agile work requires healthy teams, comprised of people who proactively contribute to maintaining team health by investing emotional labour in every conversation, interaction and collaborative exchange. This simple insight is fundamental to building agile organizations based in hacker culture.
Making agile work
There are two kinds of work required for successful agile teams: knowledge work and emotional work. Both these forms of work have deep roots in the hacker tradition. Hacking is a form of knowledge work – a kind of work focused on wrestling with unknowns and transforming them into knowns. This kind of knowledge work can be taxing for practitioners. It takes emotional work to sustain it and to sustain the teams that do it well.
To clarify the nature of hacker knowledge work, consider the case of an early-stage startup entrepreneur. The entrepreneur has an idea for a tool to solve a certain problem. Since she is a hacker entrepreneur, her first step is to question her assumptions about why this tool will do the job. The entrepreneur believes that she knows the customer for the tool. She has a vision of the supplier network, key partnerships, potential sales channels and a price point that will make it both a viable business and a desirable product. However, being a hacker entrepreneur, the entrepreneur places a question mark over these ideas. She accepts that she does not know for certain that any of her assumptions are correct. She forces herself to accept that she is dealing with a field of ‘known unknowns’ – things that she knows she does not know, yet needs to know in order to successfully build a business.
By systematically turning assumptions into hypotheses that they test through experiments, hackers transform unknowns into actionable knowledge. This work of converting assumptions and testing them is a kind of knowledge work. This knowledge work is the foundation of every hacker innovation project. Hacker knowledge work is the common thread that unites agile developers, lean entrepreneurs and design thinkers. It is what enables hackers to be effective innovators. It obliges hackers to work collaboratively in teams, and requires them to invest considerable emotional labour in their work.
Questioning is a team sport. The ancient philosopher Socrates knew this, 2,500 years before the birth of hacking. Socrates would wander about the marketplace in Athens putting difficult questions to everyone he met. The oracle at Delphi claimed he was the wisest man in Athens, but Socrates didn’t believe it. ‘If I have any wisdom, it is because I know how much I don’t know’, Socrates insisted. Socrates had a hacker mindset.
Socrates worked hard to achieve what little knowledge he possessed. He sought to turn unknowns into knowns by asking questions and discussing them with the people he met on the street. Socrates irritated these people. Many of them were high-ranking, well-appointed members of the Athenian elite. These people were convinced that they knew everything they needed to know. They found Socrates’ questions tiresome and disturbing.
Confronting the possibility that we might not know what we think we know makes us feel foolish and vulnerable. For the Athenians, chewing over questions in conversation with Socrates was exhausting. In the end, the Athenians decided Socrates was a threat to their way of life. They charged him with impiety and corrupting the youth, and put him to death.
In modern societies, people who ask difficult questions don’t get condemned to death, but they can be ostracized for their questioning attitude. In many traditional companies, questioning is frowned upon. Knowledge workers are employed to solve problems that everyone agrees are important, not to create new problems by asking hard questions.
These companies don’t have a culture of questioning. Consequently, when employees find they have to ask difficult questions, perhaps in order to rethink longstanding business strategies or to produce innovation, they feel awkward and out of place. Drilling down into unknowns feels like breaking the rules. It is often unclear how far people are allowed to take a line of questioning. They don’t feel supported. They feel like they are ‘going out on a limb’. Questioning doesn’t feel like ‘the way things get done around here’ – because it’s not.
It is not unreasonable for people to feel uncomfortable asking questions in public. Questioning is an inherently risky endeavour. It leaves us vulnerable to attack. When we ask questions in public, we expose the limits of what we know, and we open ourselves to the judgement and ridicule of others. A sharp response can cut to the bone: ‘I have no idea what you’re talking about.’ ‘What a dumb question.’ ‘What would you know, anyway?’
The fear of looking foolish crushes the questioning spirit. In an unsupportive environment, it is safer not to ask any questions at all. In these environments, people tend to clam up. Rather than ask difficult questions, they pretend they know the answers, even when they don’t. In some cases, this can destroy a company. This is what happened at Enron prior to the accounting scandal that brought the company down. Enron VP Sherron Watkins claims:
Creating a highly competitive environment where employees did not want to appear weak or unintelligent was a root cause of Enron’s problems. Smart people stopped asking questions for fear of looking like they didn’t ‘get it’.
(Watkins, 2007)
To embrace hacking and agility, companies must stamp out this kind of performance anxiety. Hacking requires safe and supportive environments, where people are free to ask hard questions and admit they don’t understand things, without fear of censure and rebuke.
The appetite for questioning must start at the top. To kickstart an agile transition, senior leaders must concede that they don’t know how to shift the organization from command and control to a horizontal management paradigm – not yet, at least. Any leader who claims he knows how to transform an ‘800lb gorilla into a herd of nimble gazelles’ – as Nilofer Merchant (2012) colourfully describes the agile transition – is a liar or a fool. Such a leader may profess to understand the principles of hacker culture, but he plainly does not.
Hacking is knowledge work. It demands that practitioners frankly admit that they do not know what they need to know to forge a path to success. Leaders need to make peace with their ignorance to license experiments and set out on this path. Self-inflated know-it-alls kill a culture of experimentation before it gets started. Sometimes this is unintentional. Some leaders shut down the opportunity space for hacking through the power of their personality.
Sustaining a culture of questioning requires a concerted emotional investment from everyone involved. This emotional work is a condition for creating productive hacker teams. In most service industries, emotional work is window dressing. The smile you get from a restaurant employee as you place your order might brighten your day, but it is not essential to the transaction. This is not the case in agile organizations. On agile teams, emotional work is everything. The emotional energy invested in maintaining a healthy team spirit and an open mindset keeps the work running. Small acts of support and generosity, such as working to resolve tensions, kindling people’s enthusiasm for the work, sustaining optimism in the face of adversity, and gently challenging one another to keep on questioning and learning make a big difference to the team. The level of emotional work a team invests in their activities can make the difference between an awesome outcome and a mediocre one.
Here are some examples of the kind of emotional work required to sustain an agile team:
The agile journey
Some leaders don’t believe in hacker culture. For these leaders, hacker culture is a fantasy, as real as hobbits and unicorns. I like to remind these leaders that unicorns, at least, exist. Unicorns are startup companies that blast from launch to a billion-dollar valuation, disrupting markets and transforming industries in the process. These companies start with small teams, generative cultures and lots of experiments. Hacking doesn’t guarantee that a startup will become a unicorn. But hacking is how the magic happens.
One of the most exciting and important developments in business today is the phenomenon of large companies trying to transform themselves into agile organizations by learning how to think and act like startups. These companies face the challenge of coming to grips with hacker culture, and figuring out how to embed it into their hierarchical, bureaucratic operating systems. For these companies, hacker culture is a foreign country. It is no wonder that the leaders of these companies tremble at the idea of embracing hacking and agility. There is a long journey required to transition from one paradigm to the other.
Companies embarking on an agile transition should think of it as a journey – a long, perilous journey of steps and stages. No company would set out on such a journey unless it had to. Business is about minimizing risk, not diving into the thick of it. Those companies that are leading the way do it as a matter of necessity, not choice. They are trying to stay ahead of a tide of new technologies and competitive forces that threaten their businesses. More than a few of them are running from a marauding horde of hackers riding unicorns.
There are five steps required to complete an agile transition:
Each of these steps is essential to the agile transition. Let’s consider them in turn.
Redefine leadership
To kickstart an agile transition, companies need to redefine leadership. Leadership must be clearly distinguished from management, for a start. Leaders have the job of motivating and inspiring people with a powerful vision. Management oversees the execution of the vision, organizing people to do the work, and setting performance measures and controls to ensure that it is done efficiently and effectively (Kotter, 2001).
A defining feature of hacker paradigm leadership is that leaders inspire people to believe they can deliver on the vision themselves. Hacker teams can and should operate with a minimal set of management controls, taking responsibility for meeting deadlines and making decisions, and taking ownership of projects overall. Hacker paradigm leaders encourage team members to believe in themselves by carrying risk for the project, defending it against detractors and advocating for the team, its capacities and goals. Instead of trying to direct team activities, these leaders empower team members to take the lead, liberating individuals to express their powers and freely contribute what they can.
On a high performing team, there is no room for average. Teams should be great. Nothing less will do. Hacker paradigm leaders set their teams on a course for greatness by leading with purpose and cultivating a high-level tribal mindset. By setting teams an audacious goal and encouraging team members to believe in themselves, they create autonomous, self-directed teams, inspired by intrinsic factors to achieve things no one has achieved before.
Some business leaders find it terrifying to concede they don’t have all the answers. This is precisely what people need to admit if they are to embrace the hacker way. The threshold step into hacker culture is to admit that there is a wealth of unknowns that need to be addressed to determine a path to success. Hacker paradigm leaders must lead the way by questioning their assumptions and designing experiments to test them. Leaders must be Chief Experimenters, challenging teams to hack their way to success.
These experiments should be focused on creating customer value. In agile and lean environments, any activity that doesn’t add value for the customer or end user is a form of waste. Leaders, therefore, must be hardcore customer advocates. The whole point of hacking in a commercial environment is to figure out how to create maximum customer value as quickly and cheaply as possible, while eliminating actions that count as waste.
The concept of making space for innovation unites the diverse aspects of hacker paradigm leadership. The fundamental task of a hacker paradigm leader is to create shared environments where teams feel empowered to self-organize around problems and hack. Once they have achieved this, the leader can blend into background. Hacker paradigm leaders are often indiscernible on teams, because everyone is behaving like a leader, playing an equal role in advancing the work and keeping the culture alive.
Implement an entrepreneurial management system
The second step in an agile transition is to implement entrepreneurial management practices. This should happen at the same time as the organization is redefining leadership. There is little point in leaders trying to liberate the energies of hacker teams if the company’s reporting structures, metrics and performance systems counteract the work. Leadership and management wind up at loggerheads, with innovation teams caught in between them, and the agile transition grinds to a halt.
An entrepreneurial management system isn’t designed to replace traditional hierarchical management. Numerous business activities benefit from hierarchical management, even in agile organizations. There is no reason why established operations with well-defined targets, roles and processes shouldn’t be managed in a top-down, bureaucratic way. These units are up and running. If a stern eye and steady hand is all they require to deliver value, traditional management fits the bill.
Hacking and innovation require a different kind of management. Innovation projects, by their nature, tend to be fledgling operations, lacking clear targets, roles and processes. While the teams responsible for these projects may have a general sense of their goals and objectives, they are often unclear about how to achieve them. Since it is impossible to measure progress towards targets that can’t be defined, traditional management is no use. Because teams can only speculate on the ROI, financial managers have no idea of how to evaluate the project, and budgeting for innovation feels like pouring money into a hole.
The solution is to manage innovation projects like startups. Instead of managing teams like mature units, tasked with executing on established business models, treat them as entrepreneurial units, tasked with searching for new business models. Through his work with companies transitioning to the hacker way, Eric Ries developed a system of practices for managing these kinds of exploratory units. Ries’ system of entrepreneurial management has three key components: islands of freedom, learning metrics and metered funding.
Islands of freedom
Entrepreneurial management is designed for small teams that want to test a new idea for a product, service or solution. The system encourages teams to take a lean approach to achieving their objectives. The team starts by identifying the riskiest assumptions built into their idea – assumptions they need to get right for the idea to work. The team approaches their manager and requests a period of grace from other tasks and responsibilities to run an experiment to test these assumptions. Ries (2016: 218–219) calls this period of grace an ‘island of freedom.’
The island of freedom might only be a day or two, or it may be as long as a month, depending on the nature of the experiment. During this time, the team can put other projects on hold, step outside their normal roles and duties, and run experiments with a view to making a case to support their project proposal. It is in the interests of the team, and the project, for the manager to grant them the minimum time they require to test their idea. Urgency is the mother of creation. As the saying (attributed to Leonard Bernstein) goes: ‘To achieve great things, two things are required: a plan, and not quite enough time.’
Metered funding linked to learning metrics
Determining the value of an early-stage project is a bit like asking for the ROI on an interplanetary mission. Prior to landing on the alien planet, it is difficult, if not impossible, to tell what the return might be. What if the planet contains rivers of molten minerals? Craters full of gold? Hidden cities of friendly aliens with technologies they’re happy to share? The return on this could be priceless. The trouble is, launching a space mission is the only way to verify the return. Space missions, unfortunately, are expensive.
Early-stage innovation projects have a similar problem. At the start of a project, no one has any real idea of what the return might be. The project leads have big aspirations, no doubt. But their best estimates of the payoff are usually back-of-the envelope estimations. They have no real data, and thus no real idea of how much the project may ultimately be worth.
This creates a classic impasse. Finance wants numbers. If the organization is going to invest in research, it needs to know what the return will be. But it is impossible to gauge ROI based on early-stage experiments. The ROI on most experiments is negative. On a financial spreadsheet, innovation research looks like a colossal waste of money.
Confronted with this impasse, many teams try to boost their project using ‘vanity metrics’ (Ries, 2011: 128–136). Working on the assumption that their best guesses about the project will bear out, they produce amazing numbers out of a hat. They try to wow investors with projected ROI, market share, profit margin and so on. In the absence of hard data, however, these numbers are just hot air.
In an entrepreneurial management system, teams evaluate things differently. They measure progress in terms of actionable learning metrics, based in agreements about what they need to learn next to succeed at what they’re trying to do.
The process of setting Iearning metrics begins when a team approaches their manager with an idea for a project. Ideally, the team will have assembled some data to pitch the manager on the project, showing how the project addresses a real problem and has genuine potential to solve it. The parties agree that a lean approach is the fastest, cheapest and least risky way to go about exploring the project. The team is given the task of identifying their riskiest assumptions about the project and figuring out how to validate them, fast.
Setting learning metrics is a way of holding a team to this task. To set these metrics, the manager asks the team: ‘What is the most important thing you need to learn first to advance this project?’ No doubt there are dozens of things the team needs to learn about their customer, costs, returns and so on, to execute on the project. To start, however, they need to pinpoint the riskiest assumption they are making about the project, an assumption that would derail the project, if it turned out to be incorrect.
Surfacing risky assumptions can take a lot of critical thinking and soul searching. Once the team has completed this work, they return to their manager. The team says: ‘Here is what we are assuming. If we are right about this, the project has potential. If we are wrong about it, we’ve been fooling ourselves.’
The manager says: ‘Okay, figure it out.’ She gives the team a timeboxed period to validate the assumption and a modest level of funding (or in-kind support) to run experiments. Validating the assumption within the allotted timeframe becomes the team’s metric of success. This learning metric takes the form: ‘Team X agrees to learn answer Y within period Z’, where Y represents the validation (or invalidation) of a risky assumption, and Z is an ‘island of freedom’, a period in which the team is sponsored by the company (through funding or by being given time off their other tasks) to run experiments and learn.
If, at the end of the island of freedom, the team has failed to achieve its learning metric, it cannot expect to receive management’s continued support and there is no guarantee it will be awarded a second island of freedom. If the team meets its learning metric by validating the assumption (or, alternatively, invalidating it, but in doing so learning something important that advances the project), it can request a second island of freedom to continue its innovation work. In this case, management will offer a second funding injection, with further funding conditional on the team meeting a second learning metric.
Ries calls this a ‘metered funding system’. It is similar to the approach used by venture capitalists to fund early-stage startups (Ries, 2016: 282), who offer modest levels of funding that are scaled up when the startup achieves its growth metrics. Metered funding reduces the risk of wasting large amounts of money on projects that look good to start with, but wind up foundering on unquestioned assumptions. The approach incentivizes teams to determine the desirability, feasibility and viability of their idea as quickly as possible in order to establish the value of their project and scale up the flow of investment.
With an entrepreneurial management system in place, small teams can emerge out of the ranks of a company hierarchy, self-organize around urgent problems and search for innovative solutions. These solutions can be rolled out as independent business units or grafted into the existing structure of the company. Assuming that a team can demonstrate value at every step, it should be granted end-to-end responsibility for developing the solution into a product or service. This includes the responsibility for building a viable business model around the solution, launching it, scaling it and running it as a business unit.
Create metrics and structures that encourage collaborative behaviours
When Jeff Smith joined IBM as CIO in 2012, he was faced with a monumental challenge. IBM wanted to roll out agile method, not just in its engineering divisions but right across the company. Smith had to figure out how to build and manage thousands of agile teams.
This called for the creation of a new entrepreneurial culture at IBM. It involved transforming leadership at IBM, weaning people off command and control, and convincing them to become coaches, facilitators and transformational leaders. It required creating environments that inspired employees to be their best and that empowered teams to do something special. None of this was simple. The challenge overall was incredibly complex.
Smith started by stripping out layers of management. Smith knew from previous experience that ‘when your process density exceeds your talent density … things plain don’t work’ (Smith, 2016a). The only way to get small teams working autonomously on problems is to strip out the overheads and let the teams decide how to get things done.
The problem was, removing managers from the picture meant removing an important layer of carrot and stick incentives. Smith figured that the intrinsic rewards of agile work would motivate the top employees, but he wasn’t sure if they would motivate everyone. Reflecting on how agile teams are inherently competitive, Smith decided to set up a competitive environment, using a standard system of agile metrics to rank teams in relation to one another. Inspired by the English football leagues, he shared these scores on a leaderboard. Now the teams could play against one another and compete for premium status.
Smith kept these metrics to a minimum. His list of metrics included:
By posting data on team performance on the leaderboard and updating it regularly, Smith created a virtuous competition between teams. Team members would check the leaderboard, see how their performance compared to other teams and work at making improvements in areas where they fell short. This system worked to encourage teams to self-manage their performance for the sake of team status and prestige. When a team found that it was struggling in certain respects, it could identify a team that was performing better, relatively speaking, and go to that team and learn from them.
Team metrics are useful when companies are managing large numbers of agile teams and need to ensure they achieve maximum productivity and consistent performance. They can hamper performance, however, in small organizations with an established innovation culture, where teams expect to be treated with a high degree of trust and respond to the show of trust by committing to and meeting their targets and deadlines.
In Part 2 of this book, we look at an alternative system for encouraging collaborative behaviours, which is more in keeping with the startup way and the spirit of hacker culture. This system involves creating a gift economy within organizations. A gift economy hinges on intrinsic rewards that team members distribute among themselves in exchange for voluntary contributions to work. This informal system can be a highly effective way of motivating and rewarding collaborative behaviours in small team contexts. It replicates the generative dynamic of the best hacker teams, inspiring contributions without the imposition of a formal system of metrics to quantify and manage team performance.
Revise budgeting and create financial incentives to support and reward innovation
The annual budgeting and planning cycles of traditional companies are too slow for agile innovation. Agile innovation requires a more nimble, piecemeal approach to budgeting, where road maps and plans are revised quarterly or monthly, and project funding is reprioritized on a flexible basis to keep pace with learning and discovery.
Budgeting for innovation teams should be transparent and clearly linked to the company’s vision and mission. Setting budgets for teams of in-house entrepreneurs (or ‘intrapreneurs’) who are trying to transform processes and conditions within the company should be specifically linked to the challenge of enabling the company to complete its agile transition. It is vital that intrapreneurs know that money is there to support their projects. The onus is on the intrapreneurs to form teams and propose ideas to claim this funding.
In companies with a flourishing innovation culture, the pursuit of intrinsic rewards, like autonomy, peer reputation, learning and technical mastery, serves as the primary motivator for teams (Pink, 2009). Still, traditional bonuses and incentives can be important motivators as well. These bonuses and incentives should be systematically linked to innovation, so that innovators feel motivated to propose ideas and rewarded for taking risks.
At the electric car company, Tesla, for example, bonuses and promotions are built around a 1-to-5 rating system for innovation performance, where a rating of 1 and 2 signifies sub-par performance, a rating of 3 is average, and 4 and 5 signify ‘great’ and ‘phenomenal’ performance respectively. ‘Great’ and ‘phenomenal’ are cashed out in achievements. Elon Musk explains: ‘You don’t get the two highest ratings … unless you have done something innovative. It has to be significant in the case of phenomenal, something that makes the company better or the product better.’ Notably, you don’t need to be on a front line innovation team to score a rating of 4 or 5. ‘Anyone can be an improver’, Musk explains. ‘HR, finance, production, they can all figure out how to improve things’ (Dyer et al., 2015).
To encourage individuals to aspire to top performance, organizations transitioning to agile should also consider implementing KPIs that encourage innovation and entrepreneurial activity. It is crucial that managers set metrics around the process of innovation, not just the achievement of outcomes. Dan Gregory and Kieran Flanagan recommend that managers replace KPIs with ‘Co-PIs’, performance indicators that ‘provide incentive for thinking and acting collaboratively’ (Gregory and Flanagan, 2013). The goal is to reward employees for playing well in teams, working together to generate ideas and contributing to the process of inquiry and learning, so that they bring their best selves to work, inject confidence, optimism and joy into collaborative activities, sustain team health and resilience, and generally help the team achieve its best performance.
Culture hack the company to embed hacker mindsets and values
In 2013, the online shoe retailer Zappos became an agile organization. Zappos, famous for its customer focus and zany, team-based culture, had recently been purchased by Amazon. Flush with money and confidence, cofounder and CEO Tony Hsieh decided to take the company culture to a new level by implementing Holacracy, a ‘bossless’ organizational operating system. Holacracy seemed like the perfect way to empower Zappos’ teams, and to enable everyone in the organization to contribute their gifts.
Holacracy flattens organizations, getting rid of rigid, hierarchical power structures. It distributes power to teams, who work in nested ‘circles’ to execute operational functions. Within each circle, team members negotiate over who does what and how before committing to timelines and delivering on tasks. Hierarchy exists in the holacratic organization, but it is called ‘holarchy’, to indicate that it is a hierarchy based in the self-organizations of ‘holons’ – nested circles of circles (Bernstein et al., 2016; Robertson, 2016).
A significant number of Hsieh’s employees didn’t see the upside. By 2015, 85 per cent of Zappos’ employees had transitioned to Holacracy, but the remainder refused to change. Faced with protracted resistance, Hsieh made an executive decision. He issued an ultimatum: embrace Holacracy or quit. In the end, 260 employees (roughly 18 per cent of the workforce) decided that holacratic self-management was not for them and left the company (Feloni, 2015).
Zappos still struggles with Holacracy. Disgruntled ex-employees regularly pop up in the business press to complain about the system. In 2016, Zappos fell off Fortune’s list of the Top 100 Companies to Work, after eight years on the list. Critics blame Holacracy itself, which puts a lot of extra work and responsibility on employees’ shoulders, tasking them with self-organizing to complete management functions in addition to completing their work. Holacracy is far from perfect, it is true. But the buck stops with the CEO.
The fact that, two years into the transition, a sizable chunk of Zappos’ employees were still reluctant to embrace Holacracy should have rung alarm bells for Hsieh. It suggests the system was an awkward fit for the company. Had Hsieh taken a hacker approach to transitioning to Holacracy, he would have treated the transition as an experiment and put the brakes on the project at this point to figure out what was going wrong. Instead, Hsieh acted like an old-school CEO and said: ‘My way or the highway.’
Hsieh insists he has no regrets (Guzman, 2016). Still, this is not a good example of hacker leadership. As Gary Hamel and Michel Zanini observe, ‘there is something inherently contradictory about using authoritarian means to implement a management model aimed at enhancing self-determination’ (Hamel and Zanini, 2016). It strips employees of their autonomy and reduces their sense of ownership over the transition. It suggests that the CEO is a Chief Decision Maker, not a Chief Experimenter. This inevitably undercuts people’s willingness to contribute to the process in constructive ways. The Great Experiment is a game played out at the executive level. Everyone else is simply expected to play along.
There is another way of approaching an agile transition, one more in keeping with the hacker tradition and more appropriate for the agile organization itself. This involves starting with hacker innovation culture. An agile transition should be a collaborative journey of experiments, learning and discovery. Rather than being implemented by force, the elements of the transition should be introduced provisionally and experimentally with the full engagement of employees, starting with discrete pilot projects and scaling from there.
I call this approach: culture hacking. Culture hacking is a practical technique for companies and organizations seeking to transition to hacker innovation culture. It involves hacking the organization from the ground up by enlisting the energies and ideas of regular members of the organization, opening people’s minds to a different way of doing things in the process.
A culture hacking campaign should start small, like any experiment. Leaders should identify departments or divisions in need of innovation, and call on employees in these contexts to propose ideas towards transforming their conditions of work. Employees should be encouraged to propose experiments that they can run themselves, seeking to change their practices and processes, and the dominant view of ‘how we get things done around here’. After singling out the most promising culture hacks, leaders should offer the people responsible the chance to run experimental pilots to demonstrate their practical value.
These hacks should be managed like any other kind of innovation project. It is vital to ensure that intrapreneurs have clear learning metrics and gather data to support their experiments every step of the way. Beyond this, teams should have carte blanche to develop their ideas as they see fit. Managers should step back from their traditional roles as planners and controllers and focus on facilitating the projects, signing off on funding and approving new islands of freedom as the teams meet their learning metrics.
A culture hacking strategy empowers employees at all levels of the organization to think and act like hackers. It serves to cultivate hacker mindsets and values across the organization, while facilitating acts of employee-led organizational change. The approach scales organically, as the initial pilot projects prove their worth. A culture hacking campaign brings everyone on board the agile journey. It turns the entire organization into a dynamic, cross-functional hacker team, focused on change.
In an article in the Harvard Business Review, Hamel and Zanini propose a culture hacking approach to reducing layers of bureaucracy in organizations. Hamel and Zanini recommend that companies that seek to slash bureaucracy invite their employees to participate in an online hackathon, with the objective of producing ‘a portfolio of risk bounded experiments designed to test the feasibility of post-bureaucratic management practices’. The winning experiments are run as pilots in various corners of the organization. The results of these experiments are documented and shared on enterprise social media, and used to create a compendium of best practices for future culture hacking initiatives. Hamel and Zanini reflect: ‘Some hacks would fail, but the best of the rest would be replicated by units eager to reduce the costs of bureaucratic drag’ (Hamel and Zanini, 2016).
Part 2 of this book outlines a range of culture hacks for shaking up entrenched managerial mindsets and behaviours, consolidating team dynamics and changing the physical, social and cultural space of the workplace. These hacks are practical and purpose-designed for agile transformation. Ultimately, they are just suggestions to get you started. Every organization is different. A culture hacking campaign should be tailored in response to the unique character and constraints of the organization as it is.
Start with this intuition. Your company culture is a wall, blocking you from a bright future of creativity and innovation. As a leader, have the humility to accept that you don’t know how to break through this wall. Process this insight then hit it like a hacker. Embrace the unknown as a positive challenge and use it to catalyse a new spirit of questioning and experimentation in your organization. Gather the passion, creativity and intelligence latent in the company and refract it through the lens of hacker culture, so that the entire organization is laser focused on shattering the wall and breaking through to the other side.
Beyond the wall lies the future. Start hacking. Your time begins now.
Note
1I use the term ‘agile organizations’ to refer to organizations that can and do employ a suite of hacker innovation practices, including (but not limited to) agile development, lean startup method and design thinking. In referring to ‘agile work’, I am thinking in the first instance of teamwork guided by agile management practices, with the caveat that these teams are also capable of employing a broader range of innovation practices as required. Teams limited to a single method are not especially agile.
References
Bernstein, E., Bunch, J., Canner, N., and Lee, M. (2016). ‘Beyond the Holacracy Hype’, Harvard Business Review (July–August) 94 (7–8): 38–49.
Bright, P. (2014). ‘How Microsoft dragged Its Development Practices into the 21st Century’, Ars Technica (online). Available at: http://arstechnica.com/information-technology/2014/08/how-microsoft-dragged-its-development-practices-into-the-21st-century/. Accessed: 06/06/2017.
Comella-Dorda, S., Lohiya, S., and Speksnijder, G. (2016). ‘An Operating Model for Company-Wide Agile Development’, Digital McKinsey (online). Available at: www.mckinsey.com/business-functions/digital-mckinsey/our-insights/an-operating-model-for-company-wide-agile-development#0. Accessed: 06/06/2017.
Denning, S. (2015). ‘Surprise: Microsoft is Agile’, Forbes (online). Available at: www.forbes.com/sites/stevedenning/2015/10/27/surprise-microsoft-is-agile/#13d5cd6b4b9e. Accessed: 06/06/2017.
Dyer, J., Gregersen, H., and Furr, N. (2015). ‘Decoding Tesla’s Secret Formula’, Forbes (online). Available at: www.forbes.com/sites/innovatorsdna/2015/08/19/teslas-secret-formula/#2233bad5653c. Accessed: 07/06/2017.
Feloni, R. (2015). ‘Inside Zappos CEO Tony Hsieh’s Radical Management Experiment that Prompted 14% of Employees to Quit’, Business Insider Australia (online). Available at: www.businessinsider.com.au/tony-hsieh-zappos-holacracy-management-experiment-2015-5. Accessed: 07/06/2017.
Fost, D. (2008). ‘Coworking: A Cooperative for the Modern Age’, The New York Times (online). Available at: www.nytimes.com/2008/02/21/technology/21iht-cowork.1.10263648.html?mcubz=2. Accessed: 06/06/2017.
Gluyas, R. (2017). ‘ANZ Discovers Agile Work Practices, Long After Rivals Embrace Change’, The Australian (online). Available at: www.theaustralian.com.au/business/opinion/richard-gluyas-banking/anz-discovers-agile-work-practices-long-after-rivals-embrace-change/news-story/13b1b44cc7f93be1d088b0232026986b.
Godin, S. (2012). The Icarus Deception: How High Will You Fly? New York: Portfolio Penguin.
Gregory, D., and Flanagan, K. (2013). ‘Collaboration: CO-PIs™ Not Just KPIs’. The Impossible Institute (online). Available at: http://theimpossibleinstitute.com/co-pis-not-just-kpis/. Accessed: 07/06/2017.
Guzman, Z. (2016). ‘Zappos CEO Tony Hsieh on Getting Rid of Managers: What I Wish I’d Done Differently’, CNBC (online). Available at: www.cnbc.com/2016/09/13/zappos-ceo-tony-hsieh-the-thing-i-regret-about-getting-rid-of-managers.html. Accessed: 08/06/2017.
Hamel, G., and Zanini, M. (2016). ‘Top Down Solution Like Holacracy Won’t Fix Bureaucracy’, Harvard Business Review (online). Available at: https://hbr.org/2016/03/top-down-solutions-like-holacracy-wont-fix-bureaucracy. Accessed: 08/06/2017.
Harry, B. (2011). ‘Agile Project Management in Visual Studio ALM V.Next’, Microsoft (online). Available at: https://blogs.msdn.microsoft.com/bharry/2011/06/14/agile-project-management-in-visual-studio-alm-v-next/. Accessed: 06/06/2017.
King, D. (2016). ‘By 2020, There Will Be 26,000 Coworking Locations with 3.8 Million Members’, SmallBusiness.com (online). Available at: http://smallbusiness.com/facilities-manage/coworking-growth-forecast-2016-2020/. Accessed: 06/06/2017.
Kotter, J.P. (2001). ‘What Leaders Really Do’, Harvard Business Review 79 (11): 85–96.
Merchant, N. (2012). ‘Traditional Strategy Is Dead. Welcome to the #SocialEra’, Harvard Business Review (online). Available at: https://hbr.org/2012/09/traditional-strategy-is-dead-w. Accessed: 04/08/2017.
Neuberg, B. (2014). ‘The Start of Coworking (from the Guy that Started It)’, Coding in Paradise (online). Available at: http://codinginparadise.org/ebooks/html/blog/start_of_coworking.html. Accessed: 06/06/2017.
Pink, D.H. (2009). Drive: The Surprising Truth About What Motivates Us, New York: Riverhead Books.
Ries, E. (2011). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, New York: Crown Business.
Ries, E. (2016). The Leader’s Guide to Adopting Lean Startup at Scale, Kickstarter Publication (online). Available at: www.kickstarter.com/projects/881308232/only-on-kickstarter-the-leaders-guide-by-eric-ries. Accessed: 02/08/2017.
Robertson, B.J. (2016). Holacracy: The Revolutionary Management System That Abolishes Hierarchy, London: Portfolio Penguin.
Smith, J. (2016a). ‘IBM CIO Leadership Exchange - Build a Next-Gen Agile Culture’, IBM thinkLeaders/YouTube video (online). Available at: www.youtube.com/watch?v=3zduSKajK64. Accessed: 02/08/2017.
Smith, J. (2016b). ‘The CIO of IBM on How to Create an Agile Enterprise [Interview with Jacob Morgan]’, Forbes (online). Available at: www.forbes.com/sites/jacobmorgan/2016/03/21/the-cio-of-ibm-on-how-to-create-an-agile-enterprise/#4fc07ac24e70. Accessed: 06/06/2017.
Watkins, S. (2007). ‘Constant Warning’, Fraud Magazine (online). Available at: www.fraud-magazine.com/article.aspx?id=583 Accessed: 08/06/2017.