6 Happy hacker teams
2004 was a big year for the startup industry. New application frameworks were refiguring the way people thought about the web and the products that could be built for it. Previously, the web had been a one-way street, where businesses posted content for customers to consume. The new ‘web 2.0’ (a term popularized at an O’Reilly Media conference in October 2004) was a two-way street, a place for user-generated content, sharing and co-creation. The social web was taking shape, venture capitalists were taking out their wallets and the tech industry buzzed with excitement.
Tech entrepreneurs, meanwhile, were exploring new ways of building businesses. The dot.com crash of 2001 had scared off investors from startups. In the intervening years, entrepreneurs had learned to make do with less, building agile, launching lean and designing in collaboration with customers. The agile practices of the software industry were filtering into the business world. The hacker culture shift was underway.
Jeff Lindsey was 20 years old in 2004. A native of Los Gatos, in Santa Clara County, California, Lindsey skipped college in the early aughts to freelance as a web developer and to immerse himself in the thriving tech startup scene. Lindsey’s true love at the time was indie gaming – LAN parties in particular. LAN parties are gaming events in which online gamers link their computers in a Local Area Network (LAN), enabling them to enjoy multiplayer games in physical proximity to one another. At LG LAN, the largest LAN party in Los Gatos, Lindsey explored virtual worlds with hundreds of players in the room. Being able to call out to players across the way made online gaming a more social experience. It integrated the conviviality of traditional desktop gaming into the pixilated interactions of Massive Multiplayer Online campaigns.
Lindsey loved how LAN parties mixed internet culture with real life. Having grown up online, he was familiar with the jargon and jokes at the parties, culled from conversations on internet relay chat (IRC). ‘We used to say: “We are from the Internet”’, he recalls. Online culture was landing, touching down in tech hubs around the world, changing the way people worked and played.
Lindsey wanted more. Some nights, when working late, he would invite friends over to hang out in the office and hack. They would play games, work on projects and share tips and tricks. While they could have done most of these things on IRC, being in the same room created a richer experience. It was easier to communicate, explain things to people and inquire into complex topics. The small group bonded like a team.
‘What if we could do this at scale?’ Lindsey wondered. An idea was taking shape in the back of his mind. Lindsey imagined an event like a LAN party crossed with a hackathon, where people hacked passion projects, collaborating face to face, and where everyone could follow their obsessions and interests. Lindsey lacked the contacts and resources at the time to make it happen. But he couldn’t let the idea go. It felt like something that needed to exist.
It was around this time that Lindsey met David Weekly. Weekly, a hacker and startup entrepreneur, ran the California Community Colocation Project, which provided donation-based hosting to open source teams and non-profits. Weekly was famous for throwing huge, outrageous parties at his home in Hillsborough, called SuperHappyFunHouse after the Saturday Night Live skit, Happy Fun Ball.
Lindsey wound up attending a few of these parties, which were loud, cool, drunken and debauched, and frequented by members of the Silicon Valley hacker elite. ‘It wasn’t like these college kids’, Lindsey reminisces. ‘It was a bunch of professional-ish adults in the tech space, like Google engineers … I didn’t really know big parties at the time, so looking back they seem even crazier. But they got too big, so they had to stop.’
After SuperHappyFunHouse ended, Weekly started running movie nights, and Lindsey and his friends Chris Messina (whom we met in the section on coworking in Chapter 3), Joel Franusic and Andy Smith would drop in. Weekly was hunting around for ideas for another social event. One night, Lindsey pitched him on the idea of a party for hackers and thinkers.
It sounded weird. But Weekly thought it was worth a try. Referencing the popular house parties, they decided to call it: SuperHappyDevHouse (SHDH).
SHDH 1 took place at Weekly’s house on the night of May 28, 2005. Weekly made his home Wi-Fi network available for use, and Lindsey arranged the couches, tables and chairs to give people the opportunity to hang out or knuckle down to work as they saw fit. Two dozen people turned up, laptops in hand, with no idea of what they were supposed to be doing.
The party was an experiment. Some people treated it like a LAN party and sat around playing online games. Other people teamed up to work on projects, taking the opportunity to get advice and input from friends. Most people just hung out and talked. There was beer, pizza and a social vibe. The party was full of smart, friendly, talented people, with no shortage of interesting things to discuss.
By midnight, SHDH 1 was in full swing. The party continued until 6 a.m. the following morning.
Weekly set out to fly the hacker flag. Inspired by Wikipedia’s success, he had been nurturing the idea of a web business that would enable people to create their own wikis. Weekly holed up at a table around 1 a.m. and hacked at his design until morning. By sunup, he had a prototype for a system he called ‘Peanut Butter wiki’, or PBwiki for short.
The SHDH team used PBwiki for their website. Within weeks of the first event, PBwiki had thousands of users. Weekly set aside his other projects and focused on building the business. In 2009, PBwiki received USD2 million investment from Mohr Davidow Ventures and morphed into PBworks, one of the largest private wiki farms in the world.
On the morning of May 29, 2005, Weekly and Lindsey agreed that SHDH 1 had been a success. They decided to run a second event in six weeks’ time. This became the cycle for the team: one party every six weeks. Over the next seven years, they would iterate this cycle over fifty times.
SHDH scaled fast. Thanks to Weekly’s networks and reputation, there was excellent word of mouth. ‘It was largely just the people who made it along to those first events, who knew a lot of people’, Lindsey explains. ‘We had a lot of social hubs to spread the word.’
Chris Messina drew up some posters with a stylish logo and designed some business cards, which gave the parties an aura of legitimacy. Lindsey drafted a guide to inviting people to SHDH and posted it on the wiki. He included a shout-out to participants, which captured the philosophy and spirit of the events:
SuperHappyDevHouse is a non-exclusive event intended for creative and curious people interested in technology. We’re about knowledge sharing, technology exploration, and ad-hoc collaboration. Come to have fun, build things, learn things, and meet new people. It’s called hacker culture, and we’re here to encourage it.
(SHDH, 2014).
A standard SHDH party went something like this. Imagine the sun is setting over a large, well-to-do house on a leafy suburban street. You stroll up the garden path and join a press of young men in hoodies and sneakers funnelling through the front door. Inside, there is music and a lively buzz of conversation. Hackers line the tables in the living room, drilling code into their laptops. You spot several minor legends glued to their screens. Many of your friends have arrived, gathered in groups with beers in hand, talking tech and telling jokes. The night is young and the house is filling fast. It is going to be a great party.
You have food for the fridge, so you head for the kitchen. On the way, you bump into Cal Henderson (Chief Software Engineer at Flickr) and Matt Mullenweg (Founder of WordPress), who are chatting with Jeff Lindsay about WebHooks, a pattern he is exploring for integrating websites (used today by Google, GitHub, Slack and others). Wandering down the hallway, you run into Tantek Çelik (ex-Apple, ex-Microsoft, Chief Technologist at Technorati) talking to Brad Neuberg about Citizen Space, the coworking space he is setting up with Chris Messina. Messina, meanwhile, is on the back porch chatting with friends about OAuth, an open standard for website authentication he is developing with some Twitter engineers at SHDH, which enables website users to share information with other applications.
At the front door, Joel Franusic is greeting arrivals. Having noticed that people would come in, see a bunch of hackers with their heads down and leave, Franusic decided to be the usher for the party. As people arrive, Franusic greets them and asks about their projects and interests. When he sees the opportunity for a productive encounter, he says: ‘You should talk to this guy – he’s working on something like that.’
The opportunity to have surprising encounters is what drew people to SHDH. The chance to learn cool new things is catnip for hackers. Ultimately, SHDH was more than a party. SHDH was a co-learning environment – a space of serendipitous connections, ground-breaking conversations and dizzying insights.
In this respect, the parties replicated the dynamic of a healthy, cross-functional team. People came to share their gifts and contribute to the common store of knowledge. Business strategists talked tactics with open source hackers. Data analysts debated the merits of Facebook’s social graph with activists concerned about the political implications of the technology. Robotics engineers bounced ideas off designers who sought to translate them into concepts people could understand. Nothing was off limits. ‘We had a liberal definition of hacking’, Lindsey claims. ‘It was just being creative, basically.’ When people felt their neural circuits starting to fry, they’d jump into the hot tub to bliss out for an hour before reengaging the fray.
Word of the parties soon spread beyond Silicon Valley. SHDH surrogates began popping up in London, Zurich and Mexico City, though none had the energy or longevity of the Silicon Valley event. ‘Silicon Valley is the progenitor of this culture’, Weekly told a journalist from the San Jose Mercury News, who reported on the SHDH phenomenon (Wong, 2007). The article caught the attention of Lee Felsenstein, the original moderator of the Homebrew Computer Club. Felsenstein dropped in on one of the parties to check it out. The lack of structure bewildered him. But it didn’t stop him from becoming a regular attendee (Felsenstein, 2007).
If Homebrew was a lightning rod for the hacker hobbyist scene that built the first personal computers, SHDH was a catalyst for the new generation hacker culture that built the social web. The parties were cultural incubators. Between 2005 and 2012, SHDH served as a living lab for hacker innovation culture and the practices, mindsets and values associated with it. When people teamed up to work on projects, they’d acknowledge hacker protocols, if not explicitly, then by unspoken consensus. Agile development, lean startup method and design thinking were lingua franca and common currency.
‘Half the engineers who worked at Eric Ries’ startup IMVU were DevHousers’, Lindsey recalls. ‘The culture of iterative experiments, all those best practices, came together around the DevHouse community, and everyone who came into the community picked up on them.’
In the business world, the tech set was learning fast. In Bay Area startups, and larger companies with one foot in the tech scene, project managers were trialling agile practices and team structures that seemed crazy a few years before. Business leaders were paying attention, wondering how they could teach their teams to play by the new rules. Corporate recruiters and Chief Innovation Officers started frequenting the SHDH parties, cruising for talent and soaking up insights into how to rewire their cultures. Soon, Google, Microsoft and Sun Microsystems were hosting huge SHDH parties with hundreds of people involved.
SHDH was a conduit for the rapid cycles of learning and change that transformed Silicon Valley and ultimately the world. It was appropriate, then, that in March 2012, the City of Palo Alto blocked off High Street to host SHDH 50. Over 2,000 people participated in the giant tech party, jamming offices and cafes and spilling out onto the streets. It was a fitting send-off for the SHDH series and a tribute to the team who had put it together, who by this point were ready to move onto other things.
SHDH inspired and incubated some of the most interesting social developments in tech of the aughts, including coworking and the BarCamp movement. It served as a launch pad for innumerable ideas, experiments, friendships, projects and startups. It played an important role in establishing the value of hacking for the web 2.0 era.
Hacker culture, by this time, was colonizing startup hubs around the world. If we focus on SHDH, we can see what makes this culture tick. Hackers aren’t social beings, not in a traditional sense, at least. How could they be, when they spend their lives glued to their screens? Hackers tend to be cerebral, introverted individuals. But hackers will jump at the chance to gather face to face when there is something exciting to learn.
Learning and discovery are core values and motivators for hackers. SHDH’s success bears this out. This is a key insight for any company interested in building an environment for hacking. The ultimate gift, for hackers, is the chance to learn something important and new.
To create super happy hacker teams, give people the chance to hack and learn. Set them a challenge and give them the time and space they need to run experiments and build a hive of strategic knowledge. This is how you set hackers’ hearts on fire. It is how you will bring the best hackers into your company and bring out the best in hacker teams.
Smart creatives
Chris Messina is someone any hacker team would be happy to work with. Messina has a legendary reputation in the US hacker and open web communities. He came up in the Mozilla community before helping launch SHDH, coworking and the BarCamp movements in quick succession. In 2007, Messina invented the hashtag, proposing it as a convenient way of grouping topics and organizing conversations on Twitter.
Messina is an active proponent of open standards and authenticated user data. He is the Director of the Open Web Foundation and a board member of the OpenID Foundation. Messina has worked for a variety of startups, from Vidoop to Uber. Few of his friends were surprised when Google tapped him for a position in January 2010. Messina joined Google with the prestigious title of Open Web Advocate.
Google was a good fit for Messina. The company hires ‘smart creatives’ (Eric Schmidt’s [Schmidt et al., 2014: 16–20] appellation for hackers), so Messina was in good company. Google’s culture resonated with Messina’s experience of working on open source projects and hacking at SHDH. Google grants its developers an extensive licence to set their own goals and explore their passions and interests. Its celebrated 20 per cent time (where employees are encouraged to spend 20 per cent of the week working on side projects that interest them) is more an idea than a formalized process, but it reflects the innovative spirit that animates the company.
Google’s project management philosophy is as straightforward as it gets. As Messina explains: ‘You hire the best people and you put them to work on really difficult problems.’ Don’t micromanage them. Set them free to iterate and explore. Give them access to all available data and the authority to make their own decisions, based on what they learn. Let them learn the hacker way, by building something, launching it and learning about customers’ reactions through feedback loops. Let them use what they learn to enrich their understanding of the problems they’re dealing with, line up an experiment and do it again.
Messina was impressed with this system. It ‘allows each team to get smarter and smarter and build solutions in its own context’, he explains. The high level of autonomy and opportunity for self-directed learning is deeply engaging and rewarding for teams. Managers have a role to play, but they shouldn’t interfere in team learning cycles. Management’s role, instead, is to facilitate the work and to coordinate the activities of different teams into a dynamic learning system that interacts with the marketplace.
Messina compares this to the organization of the human body. ‘Having an arm, by itself, is useless’, he observes. ‘But having two arms, connected to a spine, connected to a brain, enables a complex functionality and dexterity.’ In a similar way, Google’s strategy of letting teams lead and relegating managers to a facilitative, coordinating role, enables the company to scale agility, growing an army of aligned units that don’t require top-down control. The system works by enabling hacker teams to do what they do best – hack and learn – in an open, transparent environment. In Messina’s view, this is ‘the future of work’.
Google’s approach is not without its challenges. One challenge lies in maintaining the motivation levels of individual team members through the various phases of a project. At Google, self-organizing, cross-functional teams manage projects from ideation to launch and beyond, tackling a range of tasks that would ordinarily require the input of several departments. The problem is that different skill-sets become important at different points of the project, which means team members have varying levels of responsibility as the project proceeds. A designer, for example, might lead the project while the team is figuring out how to engage the customer. While the team is focused on data analysis or market research, the same designer might find she has little or nothing to add.
This can become an issue in a company that relies on high performing hacker teams. Hackers are driven to achieve intrinsic rewards like reputation, mastery and learning. When there’s nothing to aspire to, master and learn, hackers get bored and their motivation levels decline. Unless managers find a way of channelling individuals into meaningful work, they lose focus and fall out of alignment with their teams. Over time, this can undercut teams’ aggregate levels of enthusiasm and performance.
Managers can address this issue by shuttling people back and forth between different teams. But the more they do this, the less people feel like they’re autonomous agents. Managers are thus caught on the horns of a dilemma: either they set people free and risk them not having sufficient challenges to keep them motivated and inspired, or they keep people busy working on multiple teams and risk them feeling over-managed and controlled. Neither option is ideal. Fortunately, Google has found a third way.
Aspire to OKRs
How can organizations maintain team focus and motivation in the absence of top-down management, acknowledging multi-phased development cycles with varying opportunities for input? Google does it by requiring every employee and team to define a set of audacious goals to achieve by the end of the quarter and year. This is the system of Objectives and Key Results (OKRs). The OKR system is a form of employee-driven aspiration management.
OKRs turn free time into ‘me’ time, enabling employees to make productive use of their downtime by throwing themselves into passion projects they’ve selected for themselves. The system is designed to align the audacious goals of individuals and teams with the high-level goals of the company. Once a quarter, everyone at Google sets their OKRs, starting at the top. CEO Sundar Pichai sets OKRs for the whole company. Managers set OKRs for their departments, ensuring that they coordinate with Google’s OKRs. Teams set OKRs regarding their broad ambitions for the quarter and year. Finally, individual employees set their OKRs in negotiation with their managers. Because they are aware of the OKRs set by senior managers, they can set goals that add value to whatever is going on. The system enables everyone in the company to align their work. It encourages people to look for ways to creatively contribute their specific passions and skills to the evolving company mission.
OKRs bring transparency to an autonomous workplace. Everyone’s OKRs are displayed in the staff address book, right alongside their photo and contact details, so everyone can see what everyone else is aspiring towards. Leaders can scan the OKRs to confirm that everyone is contributing something to the company mission. Employees can signpost the problems and issues they really care about. Thanks to the system, Googlers can easily identify other people in the company who are working on similar problems or who have skills and interests that complement their own. When they find someone with similar interests, they can reach out and chat, or team up to work with them on a project during 20 per cent time.
Googlers set OKRs for each quarter and year, allowing that their annual OKRs may change depending on their progress quarter by quarter. Setting OKRs is simple. It involves determining a set of objectives and three results that would indicate they’ve achieved them.
At the end of each quarter, employees sit down with their managers to review how successful they’ve been at achieving their OKRs. Because their objectives have measurable results attached, it is easy to tell if the objective was achieved, and if not, how far the individual fell short of their goal. The individual’s success is rated on a scale of 0.1 to 1.0, where 0.1 represents abject failure and 1.0 is complete success.
Importantly, employees aren’t expected to get a 1.0 on every OKR. A score of 0.6 or 0.7 is ideal. Google’s philosophy is that it is better for employees to aim high and fail than aim at an easy target and hit it out of the park every time. If employees are regularly scoring 1.0s on their OKRs, they are not being ambitious enough. Ideally, employees will hit their goals around 70 per cent of the time – frequently enough to be encouraging, while leaving room for learning and growth.
Google’s ‘aim high and fail’ philosophy can seem counterintuitive, particularly to Millennial employees fresh out of college, where the best students expect to score top marks in each assignment. What these employees fail to understand is that the point of the OKR system is not to drive high performance, but to inspire outrageous ambition. It is an aspiration management system. The object of the system is to encourage employees to constantly extend themselves by shooting for targets they know they will struggle to hit. This works to embed the hacker values of autonomy and continuous learning at all levels of the company.
OKRs are a great way of maintaining motivation levels on hacker teams. The system challenges people to challenge themselves, while contributing to their team and company’s success. Messina describes OKRs as ‘a hamster wheel for each employee that keeps them intrinsically motivated’. The system is used by a growing number of companies based in self-organizing teams, including Uber, Atlassian and Zynga.
Making moonshots
Astro Teller is a cultural engineer. As CEO of Alphabet X, Teller’s job is to enable the smartest researchers in the world to create breakthrough innovations. Business units that have graduated from X include Glass, Google’s head-mounted optical display system; Waymo, Alphabet’s self-driving car startup; and Brain, its artificial intelligence (AI)/machine learning division. High-flying projects currently under development include Loon, an attempt to build a network of balloons floating in the stratosphere that would deliver internet coverage to people in remote areas, and Makani, a system of wind turbines fixed to kites, designed to transmit energy to local grids.
Teller is serious about crazy ideas. When vetting projects, he looks for ideas that could deliver an exponential, ‘10x’ impact over existing solutions. As Teller explains, an X project must meet three conditions: (1) it must solve a problem that affects millions or billions of people, (2) it must have an audacious, sci-fi sounding technology, and (3) there has to be at least a glimmer of hope that it is achievable in the next five to ten years (Teller, 2016a).
Experimentation and failure are meat and drink for the researchers at X. Teams are taught to kill their ideas fast to meet their metrics for success. The faster teams can get unworkable ideas off the table, the faster they will arrive at breakthrough solutions. Consequently, the research teams at X spend most of their time ‘breaking things to prove they’re wrong’ (Teller, 2016a). By ‘tackling the monkey first’, targeting the riskiest assumptions underlying a project, teams ensure that they waste minimal time on projects that won’t work. It doesn’t matter how much they love the idea. If it doesn’t add up, it dies. Wishful thinking contributes nothing to their chances of success. Like NASA engineers preparing rockets for a space mission, the researchers at X need to know the project will fly.
Killing ideas is devastating. It can be tantamount to having the dream of a better world vanish before one’s eyes. Consider the fate of Project Foghorn, one of many instructive failures at X. The Foghorn team was developing a technology that turned seawater into hydrogen gasoline. The technology worked. If the team had found a way of making it commercially viable, it would have revolutionized the automotive industry. But, because of the cost of conversion, it was impossible to achieve this goal. The team hit the kill switch two years into the project when they realized that they couldn’t reduce the conversion costs sufficiently to secure a viable consumer price point (Peters, 2016).
Pulling the plug on Foghorn was traumatizing for everyone involved. But the team let it go, because their fundamental responsibility was to identify projects they could turn into big successes and get these out the door as quickly as possible. It was ‘a question of opportunity costs’, team lead Kathy Cooper explains. The team decided their resources were more valuably directed elsewhere (Peters, 2016). The Foghorn team disbanded and set to work on other projects. This reflects the uncompromising nature of the hacker mindset at X: we are here to launch moonshots, not just dream about them.
What inspires the teams at X and keeps them motivated is knowing that they really do have the potential to create breakthrough innovations that will positively impact on the lives of billions of people. Realizing this potential requires the researchers to be single-mindedly focused on rapid learning and achievable results. They need to trust the process and support one another through the highs and lows of the journey.
Teller and his teams have worked hard ‘to create the processes and culture [to] systematize innovation’ (Teller, 2016a). Today, X applies a phased approach. The first step of the process is to whittle down the vast number of ideas submitted to the lab. Visionaries inside and outside Alphabet constantly submit ideas to X. Eliminating 99 per cent of the ideas is straightforward. They are either not ambitious enough, or too ambitious and manifestly infeasible, or unachievable within the five- to ten-year timeframe.
X researchers apply 10x thinking to reflect on the impact of the idea at scale. Are there enough resources to scale this product? What problems might emerge as flow-on, ancillary or side effects? What happens to the waste? Thinking about an idea at scale can reveal difficulties in the concept that immediately removes it from contention.
Distilling the potential breakthroughs from the remaining 1 per cent of ideas can take months or years. Again, X has a clear process for achieving this. First, in what is known as the ‘rapid evaluation’ phase, a team gets ‘a few weeks and a few thousand dollars’ to tackle the monkey, identifying the biggest risks involved in an idea. They reflect on the assumptions underlying the idea that could be fatal for its success and test them.
Successful ideas enter the ‘extended evaluation’ phase. In this phase, teams build prototypes to test the technology behind the idea. They plot out a business model for the idea and rigorously evaluate it from all angles. For an idea to make it through extended evaluation, it must be clear that it ‘could survive in the real world as a large business with a real market and real applications’ (Teller, 2016a).
Ideas that make it through extended evaluation enter the Foundry. The Foundry is X’s design and innovation workshop. Projects can spend a year or more in the Foundry. In this time, researchers go all out to break the idea, testing every factor relevant to its success.
All of this is hard work. There is an immense amount of ideation, questioning, deliberation and debate, building, hacking, testing, measuring, head scratching, nail biting, long days and sleepless nights involved in the process. Imagine, then, how hard it is for the researchers, after months or years of work, to face up to the fact that the project they’ve been exploring is doomed to fail. Worse, they are the ones who must make the call. Their job is to identify why this project, into which they’ve poured their collective heart and soul, will not work. They must take their baby and kill it.
This is where the moonshot factory must contend with the vagaries of human emotion and desire. There is a big difference between vetting not-so-great ideas (which, for a trained mind, is fun and enjoyable) and eliminating truly great ideas, which seem to have everything going for them. People become attached to these ideas. They speak to their intrinsic desire to break a path to the future. Because hackers love the sense of being on the verge of a breakthrough discovery, it can be hard to convince even the best researchers to set aside their hopes and dreams and stick to the data when the data tells them the idea won’t work.
X achieves it by harnessing gift culture. Teller explains: ‘Effectively, this is not about process. It’s about creating an environment where people feel like they are rewarded [for taking ideas off the table]’ (Teller, 2016b). Killing unworkable ideas is a gift. Given the temporal and financial constraints of research, it is a gift to the organization, which might otherwise continue pouring funds and resources into a doomed project. It is a gift to the team, who are there to change the world, and whose potential is wasted on a project that is destined to fail. The people who have the courage and integrity to face up to the fact that an idea won’t work are chiefs. By calling time on the project, they are gifting to the organization and doing everyone a service.
Teller celebrates these people. ‘When something breaks, we’re like – awesome. Did we get a tool out of that? Did we learn how to do something different?’ (Teller, 2016a). The true innovation champions are people who throw themselves into the jaws of defeat time and time again, and return with valuable lessons to share with the team and the organization. Teller encourages his teams to celebrate these individuals, thereby balancing their innate desire, as researchers, to break new ground with their intrinsic desire, as hackers, to earn egoboo and the regard of other hackers whom they respect and admire.
This is pure hacker gift economics. It works because hackers are fundamentally concerned to establish their merit in the eyes of their peers, and to forge reputations as people who do good work and who are worth having on a high-impact team. In a talk at Stanford University, Teller turns this into a general observation about human nature:
What people want is recognition. They want you to say thank you … that they’d be worth having on the next project … So, create environments in which people say to each other: ‘Hey I really appreciated that, I think you’re special.’
(Teller, 2016b)
At X, the more ideas you kill, the more special you become. The responsibility for creating an environment where people feel rewarded in this way ultimately falls on the entire team. The leader’s job is to embed this attitude and outlook in teams. Teller reflects:
There’s lots of ways [you can do this] – you could just give out cool points. Make little pieces of paper that say ‘One cool point’, and then hand them out … You don’t need cash and you don’t need promotions to do what I’m describing.
(Teller, 2016b)
Monitor vital signs
High performing hacker teams are rapid learning organizations. Given the right leadership, and the freedom to hack and learn in an open, culturally rich environment, these teams aim higher, learn faster, dispense with dead-end projects and execute on achievable goals more innovatively and effectively than any other kind of human organization.
The more successful a hacker team becomes, the more exciting, enjoyable and intrinsically rewarding the work becomes for its members. The intrinsic value that hackers derive from learning and discovery, coupled with the value they place on peer reputation and personal merit, creates a virtuous dynamic in teams that compels people to aspire to top performance. The more valuable the work becomes for team members, the more they invest themselves in the work, right up to and including the point of embracing failure.
High performing hackers enjoy intrinsic rewards and get a powerful sense of achievement from their work. On the flipside, they run the risk of burnout. Both these outcomes play out at Amazon, where the highs and lows of hacker innovation boost and break employees.
In a 2015 article in The New York Times, Jodi Kantor and David Streitfeld lifted the lid on the punishing work culture at Amazon, where employees have screaming arguments over different interpretations of data and teams work 36-hour stints to deliver on deadlines. Kantor and Streitfeld cite Amazon employees who claim: ‘Nearly every person I worked with, I saw cry at their desk … The pressure to deliver far surpasses any other metric. I’d see people practically self-combust’ (Kantor and Streitfeld, 2015).
Susan Harker, Amazon’s top recruiter, defends the company’s culture. ‘[Amazon] strives to do really big, innovative, ground breaking things, and those things aren’t easy’, Harker claims. ‘When you’re shooting for the moon, the nature of the work is challenging. For some people, it doesn’t work’ (Kantor and Streitfeld, 2015).
This argument is disingenuous. Harker knows better than anyone that Amazon employs the most talented, capable and motivated people on Earth. If the company can’t operate without crushing these employees, its entrepreneurial management system is broken. The system is failing to monitor the vital signs that ensure happy, healthy teams. The upshot is that Amazon treats its most valuable assets like expendable resources.
Burnout is always a problem for high performing teams. This is why it is incredibly important to implement measures for monitoring and managing team health.
Let’s look at some tools and strategies for managing team health. In keeping with the idea that it is always best to let teams manage themselves, we’ll start with the team health check. Some kind of health check should be a regular part of the routine of any continuing team. The following exercise comes from Atlassian, a company that takes teams seriously.
Run a regular team health check
Employees love Atlassian. The company has won numerous awards for its culture and teams. In a recent survey, 91 per cent of Atlassian employees claimed working at Atlassian is ‘great’. Some 96 per cent claimed Atlassian offers ‘great challenges’, with 97 per cent claiming it offers a ‘great atmosphere’ (Atlassian, 2016).
Atlassian offers its employees generous perks, which undoubtedly feed their enthusiasm. Employees enjoy a collaborative workplace, catered meals, fitness classes, paid parental leave, five days charity leave and a robust employee equity scheme, so that everyone benefits from the company’s success. Atlassian, furthermore, is known for creating autonomous, empowered, high performing teams. Atlassian hires people who love working in teams and trains its teams to operate at peak levels of performance. For people with a passion for collaborative hacking, Atlassian feels like home.
Atlassian’s teams are empowered to innovate on their conditions of work whenever and however they see fit. Dom Price explains:
We are purposefully loose in our structure, because chaos makes us nimble. This means our teams are morphing and evolving every day, in tiny little steps. We’ve got no transformation people and no change managers. Those roles don’t exist, because the teams self-organize and self-direct.
Teams, however, don’t always function like they should. Even on the best teams, there are misunderstandings, lapses of communication, commitment and resourcing issues, and bad behaviour. If team leaders do not deal proactively with these issues, teams begin to show signs of dysfunction. Tempers fray and team morale declines, and members must work harder to maintain forward momentum and esprit de corps. Over time, this can seriously damage a team’s performance. It sucks the energy and joy out of collaboration.
To minimize levels of dysfunction in the workplace, Atlassian developed its Team Health Monitors, using categories based on data from hundreds of successful teams. The company uses different Health Monitors for Projects teams, Leadership teams and Service teams, with a different set of health attributes for each. The list of attributes featured in Figure 6.1 reflect the qualities of a healthy software development project team. To adapt this exercise to use with a different kind of team, you’ll need to identify the attributes appropriate to that team. For inspiration, see Atlassian’s online Team Playbook, which contains Health Monitors for Projects teams, Leadership teams and Service teams as well as over twenty-five exercises for unleashing the potential of teams (Atlassian, 2017).
Equipment
The Atlassian Team Health Monitor is a reflection and discussion exercise for four to eight people. The exercise helps teams get clear on key issues for high performance agile teamwork. It is a great way of checking the vital signs of teams – surfacing problems, resolving tensions and enabling authentic conversations about how things are proceeding.
A Health Monitor exercise takes around an hour to complete. Allow at least 20 minutes to complete the exercise, and 40 minutes to reflect on the results and discuss them as a team.
STEP 1. Draw up a Health Monitor chart on a whiteboard. The chart should display the attributes of a healthy team in the left-most column, with four to eight additional columns (one for each team member) to the right-hand side.
Each participant writes their name at the head of a column.
STEP 2. If this is the first time the team has done the exercise, give people time to read and reflect on the attributes of a healthy team before you begin. Give everyone the opportunity to ask questions, discuss and clarify the meaning of these attributes.
Atlassian’s eight attributes of healthy project teams are:
STEP 3. Participants place a coloured Post-it note in each of the cells of the column headed up by their name. Each Post-it corresponds to one of the attributes of a healthy team. Participants select a red, orange or green Post-it to indicate how they feel about this aspect of the project. It is important that they ‘own their truth’ and express themselves honestly.
Atlassian recommends that participants use their intuition in interpreting the meaning of the coloured Post-its. There is a concern that nailing down the criteria for each colour ‘risks turning this into a check-the-box exercise’ (Atlassian, 2017). If people find the colour coding confusing, suggest that the colours correspond to traffic signals, where red means STOP, yellow means SLOW DOWN and green means GO. People can make of this what they will.
STEP 4. Ask the team to stand in a semi-circle around the Health Monitor. Give people a few minutes to reflect on the spread of colours on the chart. Then go through each attribute one by one, asking people to explain their red, yellow or green ratings.
It is worth emphasizing that there are no ‘right’ or ‘wrong’ answers in this exercise. The objective is to make visible how people feel about the project, so the only right answer is an authentic one. The goal is to enable the team to have an honest discussion about how things are going. If there is a lot of green on the chart, things are going well. If there is a lot of red and yellow on the chart, this is an opportunity for people to dissect the issues, figure out what is going wrong and put their heads together to resolve the problem.
To wrap up, ask the team to identify two attributes they want to improve. Brainstorm some ideas to move the red and yellow to green. Assign the task of executing on the best ideas to individual team members. Set due dates and a system to monitor work in progress.
Deal with conflict – fast
There will always be tension on high performing teams. Irrespective of the effort devoted to ensuring that the elements required for team health are in place, leaders should anticipate a certain level of grumbling and frustration. When a group of talented, self-motivated people gathers together aspiring to achieve great things, it is inevitable that sooner or later someone will act out or step on someone else’s toes. Ideally, people apologize to one another and move on. When tension boils over into conflict, the team has a problem.
Conflict is a hostile virus in a team’s operating system. When tension degrades into conflict, it depletes lines of communication, amplifies negative emotion, multiplies inefficiencies and reduces team morale. Left to fester and spread, conflict can seriously undermine a team’s performance. Leaders should address conflict when it arises, zero-in on the causes and fix them as quickly as possible.
A common approach to conflict in large organizations is to institute a formal conflict resolution process. This amounts to flicking the problem up to management/HR. Processing conflict through the bureaucratic apparatus of the company or organization takes time. While the process drags on, the team’s performance suffers.
Here are some techniques leaders can use to resolve conflict more quickly.
When dealing with conflict, leave your prejudices at the door. The first step is always honest conversation and listening. If you engage the situation with the preconception that a certain person is causing trouble, you’ll inflame the situation. Moreover, because you approach the situation in the belief that you already understand the problem, you are unlikely to derive any fresh insight. Deeper issues go unnoticed and unresolved.
Start with the point of view that everyone on the team is an asset who deserves your trust and respect. Even if people on the team are pointing fingers, it doesn’t mean the real problem is being pointed out. Take time to have a genuine conversation with everyone involved in the conflict. This often turns up surprising insights.
The kinds of strategies to apply to deal with conflict differ depending on the nature of the conflict itself. The first question to ask is: what is bugging people? Causes of conflict on a team can include: (1) cultural misalignment, (2) pessimism and (3) mutual antagonism. Let’s consider these problems and their potential solutions in turn.
Cultural misalignment. Nothing bugs hackers more than a team member who doesn’t understand ‘how we do things around here’. No one wants to have to justify their behaviour, especially when they think that their reasoning and motivations should be perfectly obvious to any right-thinking human being. Cultural misalignment on hacker teams invariably creates frustration and hostility. It is rare in high performing teams, but in other environments it’s the rule, so be ready for it.
In the ideal world, culturally misaligned employees would be vetted out at recruitment stage. Inevitably, poorly aligned agents slip through the net. The first thing leaders should do when it becomes clear that a team member has a mindset or value system that doesn’t mesh with the team is to call this individual aside and have a conversation about teamwork. Take the example of a high performing team and use it to reflect on how the team members engage in collaborative knowledge work geared towards learning. Point out how this requires emotional work from the people involved. Review the practices, mindsets and values discussed in Chapter 5 and ask the individual how she feels about them.
Once you have evidence of cultural misalignment, check the individual’s willingness to proceed towards a solution. If the individual is amenable to being coached, offer her training in hacker cultural norms, or see if she will buddy up with a mentor on the team. If the individual continues to display apathy or hostility towards the cultural norms of the team, take her off it. Hacker culture, perhaps, is not for her.
Pessimism. Pessimism, for hackers, is unnecessary. If the project has a slim chance of success, so what? The worst that can happen is that the team fails, people learn and the team pivots in another direction. Life goes on. What’s the problem?
What indeed? When a pessimist raises hackles on a team, take him aside and have a chat about why he is feeling pessimistic. Clarify the positive role of failure for the team. Underscore the role of emotional work in team environments. The root cause may be cultural misalignment rather than pessimism per se. If the pessimist doesn’t understand why his attitude might be a problem for the team, you can assume this is the case.
If the pessimist understands why his attitude is upsetting people, but still feels pessimistic, the problem may lie elsewhere. It may be that the pessimist is struggling with personal problems. Tread carefully if you suspect this is the case. The individual may feel uncomfortable discussing these issues with you. It is important to create a safe environment, so he can speak openly with you.
Another possibility is that the pessimist may be tuned into problems in the team dynamic that undermine its performance, which he feels reluctant to discuss for fear of being accused of finger pointing. In this case, the pessimistic attitude is an expression of concern for the team. This is a more interesting and valuable situation from a leadership perspective, since it can help surface deep problems on the team and improve team performance.
Tribal leadership is a good way of diagnosing if the pessimist’s problem is personal in nature or if it concerns the team. Start by highlighting the team’s mission and make a show of affirming its potential for success. Use the language of greatness to locate the conversation on a Stage 4 cultural plane. A leader might say, for example: ‘I really believe in this team. I think we are great at what we do’, then ask: ‘What is your view?’
If the pessimist is dealing with personal problems that affect his work, he may respond by saying: ‘Sure, the team is great, but I’m not in great shape right now.’ This is a positive step forward. It indicates the pessimist understands the importance of a healthy team dynamic and recognizes the negative impact that his attitude is having on the team. If your company offers counselling services, recommend this individual speak to someone. Perhaps he needs time off. He should appreciate, in any case, why his attitude is undermining the team.
If the pessimist hesitates to agree that the team is great, ask him why. Point out that criticizing a dysfunctional team is a good thing. You might share a story from your own experience where some problem in the team dynamic left you feeling upset. Underscore that no team is perfect and that you’re keen to find ways of making this one better.
Sometimes, a pessimist is the proverbial canary in a coal mine. Pay attention when people are negative and down, because it may indicate other problems that need to be addressed. If you take a supportive and constructive approach to your discussion with pessimists, the conversation can produce surprising results. Alternatively, it may reveal that the pessimistic individual is not a good fit for the team, in which case he should be removed.
Mutual antagonism. Hackers generally understand the importance of emotional work for maintaining the spirit and energy on a team, so they try to maintain positive relationships with other team members, even if they don’t like them. Sometimes, though, people just can’t get on. Often, this antagonism remains buried then erupts into open conflict under pressure. This can be a disaster for the team. Leaders must move quickly to deal with antagonism before it brings everyone down.
A certain low-level antagonism between individuals is not always a problem for teams, as long as it doesn’t upset the other teammates. Kept within limits, low-level antagonism can be advantageous, amplifying the spirit of virtuous competition on the team and inspiring individuals to work harder to elevate their status.
Mutual antagonism becomes unhealthy when it upsets people, disrupts work and negatively impacts team performance. Leaders have three options in dealing with it: (1) give the individuals involved the opportunity to resolve their differences in a private discussion, (2) initiate a mediated coaching session or (3) refer the problem to HR. The final solution is the most disruptive for the team and hence the least desirable of the three.
To ensure a private discussion doesn’t devolve into an argument, prep the interlocutors by emphasizing that, while they are valuable members of the team, their antagonism has become a problem and they need to find a solution. Establish that, in their discussion, they need to be non-aggressive and non-judgemental. Rather than trading perspectives, they should take turns in proposing tactics and solutions to resolve the issue between them.
In a mediated coaching session, talk tribal leadership. Emphasize how strong and capable the team is as a unit, and express your concern that the antagonism between the individuals is undercutting its potential. Assess the individuals’ willingness to proceed towards a mutually satisfactory solution. It may be that the problem lies with one individual, who is a bad cultural fit. Listen out for a dismissive attitude towards talk of team ‘greatness’. It may suggest that the individual doesn’t appreciate the potential of Stage 4 level collaboration.
If the individuals are values- and mission-aligned, yet still can’t find a way to get on, it is possible that there is an intractable dysfunction in their relationship. Ask the individuals to propose solutions to the problem. Stipulate that these solutions are cast in non-violent, non-judgemental language. If the conversation becomes antagonistic, refocus it on the problem of maintaining team cohesion. Tell the individuals: ‘If you believe in the potential of this team and you want to be part of it, we need to find a way to figure this problem out.’ If all else fails, consider the option of moving one or other of the individuals to another team.
Cultivate resilience
Hackers run experiments and experiments often fail. In the process, hackers learn about the problems and systems they deal with. But learning doesn’t make failing any more of a pleasant experience. Failure is disappointing. Worrying about failure makes us anxious, which is taxing over time. Every time we fail, we must pick ourselves up, dust ourselves off and muster up the energy to take another shot at the problem. This can be exhausting.
Earlier, in the section on X (‘Making moonshots’), we reflected on how leaders can harness reputation-based gift culture to take the sting out of failure. If leaders make a point of celebrating people who have the courage and tenacity to push ideas until they break, they heroize the attitude of embracing failure and enable people to earn reputation capital for taking this stance.
Still, even the most heroic souls get worn down over time. To deal with the frustration and disappointment that is an inevitable part of hacker innovation, it is important to cultivate a basic level of resilience. Without the resilience to bounce back after failure, people get tired and manifest negative, unproductive attitudes, like pessimism, apathy and hostility. Hacking becomes a painful experience and the whole team suffers as a result.
Mark Brouillette is a UX designer with years of experience working for leading tech companies including Hewlett Packard and Uber. I spoke with Brouillette about the personal challenges of working on hacker teams. Brouillette offered the following recommendations for individuals and teams that are trying to cultivate resilience, based on best practices he’s observed in the field. To cultivate resilience, individuals and teams should: (1) be objective, (2) serve the customer and (3) cultivate the self-discipline to fail and learn.
Be objective
Sometimes when people get stressed, they lose perspective. They get caught up in emotional responses that cloud their judgement and distract them from dealing with the real problem. They express anger, sarcasm, irritation and resistance. These kinds of attitudes can sap team morale. Leaders should deflate these attitudes by encouraging the offending individual(s) to focus on the problem.
One easy way to deflate a negative attitude is to highlight that it is an attitude. Brouillette explains: ‘If someone is showing anger [for example], we say: “Well, my attitude towards this is …” so we call out the attitude.’ This gently prompts the individual to reassess their behaviour and take a more objective perspective on the situation at hand.
The objective truth of the situation is: we have a problem. ‘Being angry is not going to solve the problem’, Brouillette observes. The best way to counter a negative attitude or perspective is to say: ‘Fine, that’s your attitude, but this is the situation. Let’s deal with it.’
The less time a team spends stressing about problems, the more time it can spend dealing with them. By encouraging everyone to be objective and focus on the problem at hand, teams can move quickly and easily through work, with less emotional turmoil and trauma.
Serve the customer
When the going gets tough, people start thinking about giving up. If there is one thing that should inspire a team to keep at it, it is knowing that they’re trying to solve an important problem for a real person: the customer or end user. Achieving results for customers and end users is (or should be) an important source of strength, dignity and resilience for a team. These are the people for whom the team is working – indeed, for whom they exist. High performing teams focus on serving customers and end users by learning about them, solving their problems and improving their lives in distinct and dramatic ways.
When teams are focused on serving customers and end users, working with them becomes a source of pleasure. For Brouillette, it is the most inspiring part of the job. Testing a prototype with customers is a uniquely rewarding experience. Brouillette relates: ‘Even if you only get feedback from a few people, it still makes your day. You go home feeling so good.’
Getting to know the customer humanizes the work. Work becomes meaningful and infused with purpose. Suddenly, there are stakes involved. Get the product right and you might make a real difference to someone’s life. Fail in the attempt and you’ve let someone down.
Brouillette calls this ‘good stress’. Good stress involves sustaining creative tension with a sense of purpose. When a team is focused on serving the customer, the pressures and anxieties of the work are offset by the intrinsic rewards they get from creating value for them. A healthy hacker team seeks to find a balance between these experiences. Brouillette calls this ‘the game mechanics of just the right amount of stress’.
High performing teams seek to find the point of equilibrium where creative stress is offset by the intrinsic rewards of the work, and feed off this experience. The constant flow of ‘good stress’ energizes the team, motivating people to stay focused and pick themselves up when something doesn’t work. When an experiment fails, they bounce back and try again. Their intrinsic sense of purpose fires them on. Brouillette relates:
It’s a bummer, but you know you are up to it. You feel determined, like you could still solve the problem. Even if it’s the seventh time you’ve failed, you’re like: ‘No there has got to be a way around this.’ You get up, and you try again. You use the momentum of failure to rise up and continue on.
Cultivate the self-discipline to fail and learn
To cultivate resilience, you need to cultivate the self-discipline to fail and learn. This kind of self-discipline is hard to achieve. It can take years of practice, self-work and refinement. It reflects the kind of work one must do for oneself, on oneself, by oneself.
Creative work is full of challenges and compromises. Brouillette’s job, for example, involves mocking up fake media pieces to describe future product releases. Brouillette creates these pieces at the start of each project to articulate a big picture vision of what the team is trying to achieve, to create clarity and alignment around the purpose, goals and vision of the project. He pours his hopes and dreams into each of the stories, imagining how the project will unfold and how it will impact on customers’ lives.
This is an inspiring task. Unfortunately, it usually results in crushing disappointment. When Brouillette shows these pieces to his team, reality bites. The developers on the team start taking his vision apart and reassembling it in an achievable form. Brouillette claims:
The engineers start whittling me down … saying ‘unfortunately we don’t have the technology required to give this an operational form, but here’s what exists, and if we plug this in and link this up and turn this thing that way, we can make this thing a reality’.
This is all part of the creative process. But seeing your dream brought down to size is disappointing. Dealing with it takes self-discipline. Brouillette explains:
You have to swallow a vision that you think would’ve been supreme and start all over again. This is going to happen hundreds of times during a project. You’re going to have to go back to the drawing board and rethink a problem because some aspect of what you dreamed is not achievable. It is draining, for sure.
Brouillette’s approach is to look for the opportunity in failure. While it is vital to learn to withstand the disappoint of failure, dealing with disappointment won’t necessarily propel you to start again. In addition to processing disappointment, you need to learn how to grow through failure, and to use failure as a springboard to new insights and achievements.
Failure should fire us into the future. Instead of just accepting that things haven’t turned out how we wanted, we should focus on seeing the upside in failure by looking for positive outcomes we hadn’t expected. Failure becomes a positive opportunity to rethink our strategy, to alter our outlook and change trajectory.
When I asked Brouillette how he’d developed his creative response to failure, he cited his artistic practice and lifelong love of drawing:
Learning to be okay with failure came through drawing. In drawing, you’re constantly making a movement and course correcting along the way. The best work of painting or illustration involves millions of failures before the artist finds success.
Martial arts are another source of inspiration. Brouillette explained how martial artists are trained to absorb a set of blows from an opponent and use the force to come back with a counterstrike. ‘You string together a series of really good blocks and throw one good punch, then pull back and take a couple of hits, but allow that momentum to swing you back around so that you get an uppercut.’ It is a brutal metaphor, but the metaphor connects.
To thrive in creative environments, individuals need to cultivate the self-discipline to fail and learn. To take the blow and return with an uppercut. To see a dead-end and course correct. Brouillette observes:
In a world built on process, you don’t have much room for course correction … But it’s not like that in the tech world, it’s not like that at all … There’s got to be some way that failure is pushing you towards the next step, the next advance, thinking about solving the problem differently.
This attitude drives high performing hacker teams. These teams are driven and inspired by a resilient, optimistic passion for learning. Every setback is a learning experience. When a prototype fails, the members of a high performing team say: ‘Great. What did we learn from that? How do we pivot on our original plan to make this failure an opportunity?’
References
Atlassian. (2016). ‘Atlassian Employee Review, 2016’ (online). Available at: http://reviews.greatplacetowork.com/atlassian. Accessed: 29/06/2017.
Atlassian. (2017). ‘Project Team Health Monitor’ (online). Available at: www.atlassian.com/team-playbook/health-monitor/leadership-teams. Accessed: 08/09/2017.
Bock, L. (2015). Work Rules! Insights from Inside Google That Will Transform How You Live and Lead, New York: Hatchett.
Felsenstein, L. (2007). ‘SuperHappyDevHouse’, The Fonly Institute (online). Available at: http://fonly.typepad.com/fonlyblog/2007/07/superhappydevho.html. Accessed: 29/06/2017.
Kantor, J., and Streitfeld, D. (2015). ‘Inside Amazon: Wrestling Big Ideas in a Bruising Workplace’, The New York Times (online). Available at: www.nytimes.com/2015/08/16/technology/inside-amazon-wrestling-big-ideas-in-a-bruising-workplace.html. Accessed: 29/06/2017.
Peters, A. (2016). ‘Why Alphabet’s Moonshot Factory Killed Off a Brilliant Carbon-Neutral Fuel’, Fast Company (online). Available at: www.fastcompany.com/3064457/why-alphabets-moonshot-factory-killed-off-a-brilliant-carbon-neutral-fuel. Accessed: 29/06/2017.
Schmidt, E., Rosenberg, J., and Eagle, A. (2014). How Google Works, New York: Grand Central Publishing.
SHDH. (2014). SuperHappyDevHouse Front Page (online). Available at: http://superhappydevhouse.org/w/page/16345504/FrontPage. Accessed: 04/12/2017.
Teller, A. (2016a). ‘A Peek Inside the Moonshot Factory Operating Manual’, Alphabet X Blog (online). Available at: https://blog.x.company/a-peek-inside-the-moonshot-factory-operating-manual-f5c33c9ab4d7#.tp07w4hsy. Accessed: 29/06/2017.
Teller, A. (2016b). ‘Celebrating Failure Fuels Moonshots’, Keynote at Stanford Technology Ventures Program (online). Available at: www.youtube.com/watch?v=wtCBCa7DiHo. Accessed: 29/06/2017.
Wong, N.C. (2007). ‘Young Software Developers Eat, Drink Beer, Talk Code’, SHDH Wiki (online). Available at: http://superhappydevhouse.org/w/page/16345672/SHDH_Article. Accessed: 29/06/2017.