Transcript
Foster: This is Air Florida Flight 90 loading passengers in Washington, D.C. in 1982. The crew of this plane were based in Florida in the U.S. One thing you probably know about Florida is you don't often get weather like this. As they sat on the runway, the captain and copilot begin to work their way through the checklist as they've done thousands of times before. As they work through the checklist they're on autopilot. The exact dialog has been captured thanks to the black box, but it's full of quite technical terms. I'm going to radically simplify. Do we have two wings? Check. Do we have a landing gear? Check. Is the engine anti-ice on? No. That would have been the correct answer 9 times out of 10. In this case, they hadn't taken into account the unusually cold conditions. Why is this important? The engine anti-ice thingamajig is a little measurement device that sits near the back of the engine. What it does is it allows you to accurately measure how much thrust the engine is producing. If you haven't got the engine anti-ice on, then you're in this really dangerous situation where what the instrument panel is telling you as a pilot is really different to what's happening in the outside world. This is one of the most dangerous situations you can get yourself in.
Let's move on to the runway now. This is the exact dialog captured thanks to the black box recorder. I want you to pay really careful attention to the language that the copilot is using. The copilot has noticed something is a bit wrong. "God, look at that thing. That doesn't seem right, does it? That's not right." He's noticed something's wrong, but he's bringing his attention to the problem obliquely. For some reason, he's too frightened to say this could be a fatal problem. The captain just dismisses that. He has that air of authority. "Yes, it is, there's 80." The copilot tries again, "I don't think that's right. Maybe it is." Deference to his superior. The captain just ignores the copilot in this case. "120," the copilot tries one last time. "I don't know," as the captain announces they've reached vee-one speed. This is the speed at which takeoff can no longer be aborted. This is the point at which the fate of the plane was sealed. Now we're reaching towards the end of the runway as the plane is approaching takeoff. Finally, the captain has noticed something isn't right. He's throttled high. He says we only want 500 because that's what the instrument panel is telling him. It's not a true reading. The plane is going too slowly to generate lift. At this point both the captain and copilot realize the severity of what's happening. "Larry, we're going down." "I know it," says the captain. The plane failed to take off. It crashed at the end of the runway with the loss of everyone on board.
There were many reasons behind Flight 90's crash, but the one I want to talk about today is culture. If the culture on board this plane had been an open, transparent, and honest culture of equality, then this crash simply wouldn't have happened. The copilot would have been able to share his concerns directly with the captain, takeoff could have been aborted, and lives could have been saved. This crash and many others like it caused the airline industry, or more generally any industry around safety critical things, to introduce techniques and practices to allow for critical conversations to happen in difficult circumstances. In this talk, we're going to explore how we can take some of these ideas and apply it to our work as software professionals. I'm Jeff. I'm Head of Product Engineering at Redgate. Redgate as a company has been around for about 20 years, as you can see from our staff formation photo. We make tools for database professionals to help you bring them in line with your continuous delivery practices. I was in a book recently, "97 Things Every Engineering Manager should know." The thing that really gets me out of bed in the morning is actually quite selfish. I want to create the organization that I'd like to work in. For me, that's working with small teams creating great software, where I've got the freedom to act, clear purpose, and space to learn. Throughout this talk, I'm going to be presenting the work of a whole bunch of excellent people at Redgate. All the good stuff that you'll see from them, is them. All the mistakes, they're mine, and I take full responsibility from that.
What Is Culture?
When organizations talk about culture, you might see a stock image like this. This is a bunch of people with really big smiles putting their arms in the air, and they are clearly winners. There can be no debate about this. Unfortunately, you can't define your culture with cheesy stock images like this. A lot of companies also seem to confuse perks with culture. Maybe you have yoga with goats or something similarly daft. I recently visited the HQ of a big company in Seattle. It was awesome. I'm pretty spoiled at Redgate. This place was off the chart. There was an Uber system for traveling between the offices. There was bulletproof coffee on tap. The disgusting stuff with butter and coconut oil. It was free. This place was amazing. The food selection was brilliant. I don't know about just putting Redgate to shame. It put Cambridge to shame. Absolutely amazing. When I sat down with the engineers over lunch, they were all miserable. Why were they miserable? It turns out another big company in Seattle actually went one step further. You're allowed to take a portion of lunch home with you for the evening. Perks don't define your culture, though they can have unintended consequences.
Your value statements, mission statements, and company values do not define the culture of your organization. If you go to almost any company, you'll find some pithy statements on websites like, "We value the team over the individual," or, "We're committed to our customers." That's only any use if that's how your company is. I went back in time and looked at Volkswagen, the emissions scandal company. In 2013, their purpose was to offer attractive, safe, and environmentally sound vehicles. Didn't really live up to that. Did they? Enron, we are satisfied with nothing less than the very best. Losing all that money probably doesn't count. Value statements have to come from the culture you've already got. Put another way, you aren't going to get to the culture that you want by holding a focus group and asking what your values should be.
What is culture? Culture is the way you do things in your organization. It's just the essence of your organization. When you open the door to your office on a Monday morning, and you get the warm and fuzzy feeling. You've got a good culture. It's how you do stuff. It's how you work. It's how stuff gets done. Peter Drucker might have said this, sometimes it's breakfast, sometimes it's lunch. This quote is not actually very legit. Regardless of whether it's a real quote or not, the way you work is the biggest indicator of success in your organization.
That's really easy to say, when you're an employee. Because when you're an employee, you go into work, you get the warm and fuzzy feeling, and everything is good. If you're in a leadership position, as I suspect some of you are, then you should be asking the question, does culture really matter? Is it something you can invest in, in your organization with a straight face? Ultimately, you're asking the question of, is there a graph going up and to the right that links culture and performance? The answer is a resounding yes.
Organizational Culture
Hands up, if you've got this book. That's good. You are the enlightened. Hands up if you've read it. This is pretty good. There's still quite a few hands that didn't go up. This book's really important. Why do I think this book's important? This book from Nicole Forsgren, Jez Humble, and Gene Kim is an important read for everyone involved in software. Because it's taken a survey from about 6000 companies. It covered all aspects of how those companies work, the organizational success interviews with people. It's put it through a rigorous statistical process, which is not something we often do in software development. It's produced a model for predicting organizational performance. This is a predictive model. It says, if you improve your organizational culture, you get better job satisfaction. That's obvious. As an employee, if I work somewhere horrible, I'm not very happy. If I work somewhere nice, I'm happy.
If I invest in organizational culture, I get better software delivery performance. This is a truism from this. If your culture is better, your software delivery performance is better. They also showed a direct causal link between the organizational culture you have and your organization's performance. You can invest in culture with a straight face, it really does matter.
You've probably heard of Google's Project Aristotle. If not, you're in for a fun internet surf. It's a great read. What they did was they studied 200 teams at Google, and looked at the factors that made those teams successful. The single most important factor for those teams was something known as psychological safety. This is a prerequisite for the culture you want to create. Psychological safety seems to have been talked about at every conference I've been at for the last few years. It also seems to be massively misinterpreted by people on the ground. For some reason, it seems to be interpreted as gentle or passive, not being able to say boo to a goose. It's anything but, if you've achieved true psychological safety, then you can talk really directly and bluntly about the issues that matter. The lack of psychological safety was the cause of Flight 90's crash. If the copilot had been able to turn around to the pilot and just say something is wrong, we must abort takeoff. Lives would have been saved. Lack of psychological safety cost people lives.
Psychological safety is more important than whether your teammates are all sitting in the same office. It's more important than the individual performance of team members. It's more important than seniority. It's more important than team size. This stuff really genuinely matters.
A Pathological Organization
Like most things, if you want to improve, and if you believe me, you need to improve things. Then you need to know where you are. This is where Ron Westrum, showed that organizational culture can be defined by the way information flows around the organization. He brought out three different types of organization. The first type of organization, I hope no one works there, it's called a pathological organization. In a pathological organization, messages are suppressed. Anomalies or warning signs just never come out. If you want the best example of this, tune into HBO's version of Chernobyl. That is a perfect example of a pathological organization.
A Bureaucratic Organization
The next one, somewhere between public relations and local fix, is what he termed a bureaucratic organization. In these organizations, everyone reports incidents in the best possible light. I've definitely worked at a few places like that. As an example, you might imagine a development team and a QA team working to meet a deadline. The development team will claim success. We got that code shipped to the QA with hours to spare, brilliant, we did a great job. The QA team similarly say we did a great job. We ran through the test plan. We found all the problems. The reality is they both did terribly. The goal is to win, is to deliver winning software for our end users. It doesn't matter whether it was shipped or whether it was tested. What matters is whether we solved the problem for the end user. It's about reporting things in the best possible light.
A Generative Organization
This brings us on to the organization that we must create if we want to win in software. That's called a generative organization. In this organization, any failure should prompt inquiry. It shouldn't be pointing fingers. It should be trying to find out why we didn't meet the deadline, or why the production outage happened. It's this organization that's the most resilient. They're able to tackle problems, adjust, and learn. What are some of the characteristics of a generative culture? Firstly, you need alignment. When I say alignment, you don't develop software just to develop software. You develop software to solve a problem for someone. That should be the higher mission of your company. You need a sense of ownership.
Whatever it is you're doing, you need to be able to be in control. You need to be able to change things. Information should flow proactively around the organization. You don't need to wait for the next monthly status planning meeting to talk to marketing to say you're going to miss the deadline. You should bring that up early. You need that sense of psychological safety. You need to be able to confront the issues that matter. Finally, you need organizational learning. That's both the ability to reflect on things you've just discovered or things that have happened, but also the ability to bring in new ideas and try them out without fear of failure.
How Do You Change Culture?
We opened with the story of Flight 90 and why that crashed because of a lack of psychological safety. We've shown you what culture is and what culture isn't. We've set out a model that we're trying to attain, which is this generative culture. I'm sure this is familiar to most of you. The real question is, how do we actually change the culture? I want to illustrate this with an example from General Motors in the early 1980s. This is the Fremont plant in California. At the time, this was the worst car manufacturing place in America. Think Lada and Skoda of the early 1980s, if you want a reference point. This place produced the worst cars imaginable. It wasn't just the worst cars, it was the worst staff as well. Staff were routinely drunk on the job. Sounds quite fun, but it's probably not that fun if you want them to build your cars. There were even petty acts of sabotage. One of the favorite things they'd like to do is put coke bottles in the door panels so you get this constant rattling noise. It's probably quite funny once but it's not when you're shipping it to end users. Absenteeism rates from this plant were sky high, especially after sports games.
You might wonder why they didn't do anything about this. The unions had a completely iron grip on this plant. Management wasn't allowed to confront anything, or there'd be wildcat strike action. Management was basically stuffed. Each department was looking out for themselves, just like that bureaucratic organization we saw earlier. As an example, the people in charge of the production lines, they were assessed on how long the production line was running for, not the quality of the output or anything like that. This meant the production line never stopped. Engines going in backwards, doesn't matter, wing mirrors, steering wheels forgotten, doesn't matter. As long as that production line keeps rolling. One of the workers described a situation where an employee managed to get stuck in the pit underneath a car and had to wait for the evening shift to be able to get out again. This place produced the absolute worst cars in America. This place sucked.
Obviously, things had to change. As you heard, GM produced small cars at pretty crappy quality. In a stroke of luck, Toyota needed to build cars on U.S. soil due to U.S. import restrictions. They formed an unlikely partnership known as NUMMI. GM would get the benefit of all of Toyota's high quality ways. Toyota would get to produce cars on U.S. soil. The plant closed down, and about six months later it reopened. After all intents and purposes, it was exactly the same plant, just had a different badge on the outside. Eighty-five percent of the workforce was still the same and that included all the troublemakers. The unions were still the same. Within just a few months of opening, this plant was producing cars with much higher employee satisfaction and a much higher quality at the same speed. The culture change at NUMMI was transformational. How did it happen? Put simply, they changed what they did.
At GM, once you're on the production line, you were in the same position for your 12 hour shift, grueling, boring, back breaking work of just monotonous stuff. There was probably a motivational poster in the canteen saying teamwork was important. When you got to the production line, you just did the same thing for 12 hours every day. Under the Toyota practices, teams switch roles every few hours or so. This gave them a chance. It showed them that management actually cared. Teamwork wasn't just that motivational poster in the canteen. At GM, the production line never stopped for any reason.
The Toyota practice introduced this yellow cord you can see up here. This is known as the Andon Cord. I'm sure most of you are familiar with it. If you're not, it's a cord that runs the entire length of the production line. It empowers any employee to be able to pull that cord which lights the Andon, and in turn stops the production line. The power was inverted. Now the employees are responsible for quality. A worker described this in action after seeing the production line stopped just because of a single misplaced bolt. He said, "That makes sense. You fix it now, so you don't have to go through all this stuff later. That's when it dawned on me, one bolt changed the way I work."
John Shook, he was the guy that headed up the Toyota side of the partnership. He described it this way. It's easier to act your way to a new way of thinking than to think your way to a new way of acting. The old model of culture change would have worked something like this. The guy from General Motors would have turned up and he would have given a rousing Churchillian speech to all of his staff, how quality is super-duper important. We must beat the Japanese by producing high quality cars. Then workers would have gone back. Nothing's changed. The production line would still be running all the time. It's just words and hot air. What they showed at this plant, Toyota or the NUMMI partnership, was the way to approach culture change is easy. You change what you do. Then you look up a few months later, and you find you've got the culture you want.
Shaping Culture at Redgate
We opened with a story about Flight 90 that crashed because of a lack of culture. We showed what culture is and what culture isn't. We've shown the culture that you want to strive for. We've seen how we get there, we change our practices. How do we do that at Redgate? Redgate isn't like General Motors. We aren't producing cars, obviously. We aren't producing stuff that's utterly terrible. We're not that bad. I promise. I probably legally have to say that. There is rarely any drinking on the job. We definitely don't code drunk most of the time. Our software doesn't rattle when the customers use it. We are a software company and that gives us a whole bunch of shared challenges. Technology is moving really fast. The way we do things today is probably wrong for tomorrow. We're also made up of humans, and creating high performing teams with a bunch of humans, regularly, is actually pretty hard work. We're going to look at some of the case studies of how things have gone wrong at Redgate and what we've learned from them.
New Team + New Project
The Greenfield project. This is a dream of developers the world over. Who doesn't want to start with a project with a clean slate with none of that legacy code, which is, in reality, code that anyone else other than you wrote? We really thought we had a fantastic opportunity here. We had a new team and a brand new project. We had the entire team engaged. We had the whole company engaged. We had everyone behind this thing. This team was really and truly set up for success. Within a few weeks of starting, they fell into complete decision paralysis. They had a clean slate.
How should they structure their code? What frameworks should they use? Should they use object oriented, all these new functional shenanigans? How should the React code be structured? On the other side, they had all the product things as well. With a brand new project, what should we be doing? What should the next feature be? How should we balance time to market against the quality of the code? The tech lead described a situation where this team of six people will be locked in a meeting room vigorously arguing for four hours. To get to the end, they realized they were arguing for the same side of the same coin. They were literally just generating hot air despite being in rigorous agreement. The new tech lead was struggling. This team just wasn't firing on all cylinders.
Occupy Hand Signals
A suggestion came from within the team, said, why don't we try these occupy hand signals. If you haven't come across this before, they're a way of visually indicating exactly what it says there? A suggestion, the simplest win, raising your hand to communicate in meetings. That sounds silly. It sounds like we're at school. It works. Raising your hand to talk in meetings really works. Why does it work? It raises the level of psychological safety. Now that person who needs a bit more time to think doesn't get drowned out by the loud voice in the corner. It encourages more equal participation in meetings. It really works. The biggest win according to Toby, the tech lead, was the jazz hands of agreement, where you just do this motion to indicate that you agree and you can move on.
In a team where they don't really know each other that well and everyone wants to get the right words in, actually just being able to do this motion. I'm not sure whether you actually have to wiggle your hands or not, it might be Toby winding me up but I'm doing it on camera now. This allowed the team to just fast forward discussions really quickly. This really helped with facilitation. This wasn't a silver bullet. I'm not going to try and claim that if you've got a team that can't agree anything for introducing some hand signals at work. For us, it was part of the solution.
What do we learn from this? Simple things can make a really big difference. Raising your hand to talk can balance out that participation. This didn't automatically fix all the problems in the team. We still had to deal with those norming, storming, performing things that all those management books tell you. That stuff's still important. This was a little trick that really helped get the team over a hump. One thing I'd like you to take back, is when you next see your team in a meeting, just sit back and observe and look at the equality of the speaker ratio. Is everyone contributing? Is someone dominating the conversation? Is someone not contributing? Work out your own way, how can you get equal participation from everyone?
Celebrating Learning from Failure
Our next problem, we want to create a generative organization. That means we want to try stuff out that is going to hideously run. We need to encourage people to be able to take risks. How do we do that? How do we celebrate learning from failure? There's a Spotify thing here, you probably think I'm going to talk about tribes and squads. I'm sure there's another session right now talking about that. This isn't that. If you talk to an engineer at Redgate. One of the stories you'll probably hear is the story of the Spotify installer. You'll be regaled by the story of the poor intern, and we never name Chris because we don't want him to get embarrassed. He was tasked with doing some demonstrations on our test network of how we release our product.
We have our own homebrew release app, makes it available to the website, and you can download it. He was a very diligent guy. He sat down, and he released each and every one of our products using the only executable he had at hand, which happened to be the Spotify installer. However, through a series of rather unfortunate events, we found out that he wasn't actually on the staging environment, he was on production. He'd inadvertently managed to replace every single one of the products on our website with a copy of the Spotify installer. We had to field calls from international institutions over the world that just spent six-figure sums buying stuff and they'd got the Spotify installer. This was rather embarrassing.
I dug back through our history. You can tell it's out because it's on Yammer, which is the social network people used before Slack. This was a mistake. Actually, the story isn't as dramatic as it sounds when you see what happened, ripe was the timing. It was fixed within a few minutes. We did the usual things. We held a postmortem. We made sure it didn't happen again. We did that root cause analysis thing. Every company does that.
I'm sure your organization has made screw-ups like this as well. You probably don't talk about that openly. It's probably the thing if I give you a pint, you'll probably share that story. Every company has gotten them. What Redgate did that I thought was really excellent is we immortalized that story in our employee handbook. This is from about 2012. This is one of the pages of our employee handbooks. We gave that to all new employees. It also served as a really useful recruitment tool, so I highly recommend that. Through this page, we reinforced the cultural meme that visible mistakes are ok, because whatever you do, you're not going to replace our entire product catalog with the Spotify installer. We even introduced what we call the golden brackets award to celebrate cock-ups like this. This story has become a meme at Redgate. People who weren't even there at the time talk about it as if it happened. This helps people feel that it is ok to screw up. Screw-ups are what happens. It's tech, nothing ever works. You can share that in confidence at Redgate.
What have we learned from this? We learned that a story captured as an artifact has tremendous power. I'm sure you're all there thinking about what story happened at your company? My challenge to you is, can you identify those stories that really shaped the culture where you work? Then the next challenge is, how can you immortalize them? How can you make something of that history so that others can learn from it?
Recruitment and Interview Rotas
Recruitment, as I'm sure everyone is aware, is really hard. We have to do a lot of interviews at Redgate to find the right candidate for us. For peak times, that's 12 to 15 interviews every single week. I'm afraid I don't have any silver bullets here on recruitment. If anyone does, please see me afterwards and I will give you money. Recruitment is really important for us. We try to involve everyone in development in recruitment. That means if you've been at Redgate longer than six or so months, you're expected to be part of the interviewing team. Interviewing is never going to be as much fun as writing code. We started to try and organize a rota to balance it out a bit. Each week we have six or so engineers on the rota. They're responsible for all the interviews in a week. Sounds good. Software engineers aren't particularly great at keeping their Outlook calendars up to date. They'd almost always rather be somewhere else. They'd like to work from home. Computing is flexible, you can work anywhere. We even had one guy who went on sabbatical for three months to Peru, and didn't update his Outlook calendar. He was booked in for interviews, he just never turned up.
On the supply side, finding people to interview is actually hard even with a rota. On the other side of the table, we've got the people who we're interviewing. I'm sure Cambridge is like everywhere else, but if we don't interview someone like that, some other company just leaps in and nicks them. We have to interview people really quickly. It's not unheard of for a candidate to say I've got a competing offer on the table, I need an interview today. We have to do that. That's the market that we're in. Somewhere between this, we've got our people team, which is a friendly name for the human resources team. They were literally being driven to the point of insanity with this calendar scheduling problem. They've got engineers who don't keep their calendars up to date, who like to work from home, who go on sabbatical without telling anyone. We've got candidates who need to be interviewed within half an hour, or we're going to lose them. In the middle, we've got the poor people team with a mountain of paperwork, rescheduling interviews at the last minute. Something has to change.
At this point, we had a choice. I'm going to call them theory X and theory Y. The first one, let's call that theory X. Under this model, management could help by setting up some rules and regulations. For example, we could decree that if you're on the interview rota, you can't work from home. I think that's fair. It's only one week in six, that's not too bad. We can also declare that your Outlook calendar must be up to date as a matter of priority. Every engineer on the interview rota was expected to spend their first half an hour of the day, updating the rota. I'm pretty sure that will solve the problem. It will make the people teams' life less stressful. It's not the place I want to work.
Our second choice is the one I'm going to call theory Y. Under this model, it's much simpler. We could just let the engineers work with the people team and get out of the way. This is conceptually much simpler but it's a bit scarier. What if they don't? Our theory Y is based on the assumption that people are intrinsically motivated to do a good job. Everyone understands how important recruitment is at Redgate. They all want to do a good job. If you want to create a generative culture, and you do want to create a generative culture, then you should choose theory Y every time. Because the behavior we want to encourage is that generative culture that values high cooperation and problem solving. You've got to choose theory Y every time.
How does that work? We still kept the interview rota. At 9:30 a.m. on a Monday morning, the recruitment team and the interviewing team get together, and they sort it out themselves. We've seen some really good behaviors in here. We've seen that horse trading where Bob wants to work from home on a Friday, Sarah wants to work from home on a Wednesday. They sort the interview stuff out themselves, and they can do that locally. No approval chains or any of that rubbish. They can just get stuff done. We've even seen them come up with some new ideas. Despite the fact we were doing all this horse trading and so on, we'd still find that there was that candidate who'd demand they were interviewed in the next five minutes or they would get a job somewhere else. We started to introduce a stand-in candidate, who you can see at the front. That's someone who takes responsibility for any last minute interviews. They can be paged if we need to do a last minute interview.
Things still do happen at the last minute. Trains never work, buses never work. When that happens, we just have a Slack channel, and the teams sort it out themselves. This has been brilliant for us. We no longer have to give any management attention to the interview rota whatsoever. The engineers are just solving the problem themselves. It's not all sunshine and lollipops. Because when we grab a bunch of people to be on the interview rota, they're often six different people who have never talked to each other before. Sometimes it can be a bit difficult to get the conversation started. We've introduced someone who we nominate as the lead who's there to stoke the conversation. By and large, this works really well for us.
What did we learn from this? Creating an environment where people can solve their own problems is the way to create a generative organization. This is what you have to do. My question to you is, thinking about the areas of business, if you're a team leader, or a boss type person, what areas are you controlling, where you can give up a little bit of that control and let others in the organization get involved?
Silos
Our next problem is silos. Redgate is a portfolio company. We make a whole bunch of different products. We're organized as small teams who often look after just a handful of products. By and large, we don't have any dependencies between those products. This is absolutely brilliant from a delivery point of view because no team has to talk to any other team. They can just get their heads down. Write some code, ship it to customers. Don't need to do anything. Obviously, this has some downsides. We see people getting overly specialized. If you've worked on the same team for three years, you're missing out on whatever the other teams are doing. If you've got good practices on that team, they're not being shared. You also don't get that new starter superpower that I'm sure you've seen as well, which is when someone new joins your team, and after a while she scratches her chin. Looks at a bit of code that you've written and said, "Why are you doing that?" Then suddenly, a whole bunch of complexity disappears.
Silos are actually a real problem for us. We're looking for a way to break those silos down, to transfer people between teams. If we're going to do that, we've got to be consistent. We've got to apply the same principles that we applied for our interview rota to the way we choose our teams. Let's just let people choose where they want to work. What could possibly go wrong? This isn't a novel idea. Dan North visited us and he suggested that we give it a go. Someone called Heidi Helfand has written an entire book about it. I'd encourage you to read.
The idea is simple. People are intrinsically motivated to do a good job. If you give them the right context, then they know where they can make a big difference. As a leader, if giving up control of the interview process was a little bit scary, this was an order of magnitude more scary. If we give people a choice and can't fulfill that choice, they're going to be massively let down. Some of the risks we saw was, what happens if everyone wants to be on the Kubernetes team? Because that's the exciting thing at the moment. Equally, what happens if no one wants to be on the Kubernetes team, because I've actually read something about it? This was a really tough thing for us. We thought we had to put a bit of structure in place to help everyone understand the context.
We started by getting the leadership groups in each team in place first. If you're a leader, you get less flexibility about where you work. It's the cost of doing business. For us, the leadership group is a trio of a tech lead, a product designer, and a user experience person. We give them a briefing. We help them deeply understand why the company is funding this particular team? What difference this team is going to make. We give them that briefing, and we ask them to reflect that back in the form of a charter, which is every bit as professional as the one you see here. The purpose of this charter is just to define the mission for the team. It also tells you how the team is going to work, what skills they're going to look for, how they're going to celebrate the people you might work with. What they own, why does the team exist? This is basically a sales pitch for the team.
Then we hold an expo. Given all those charters, we ask each of the team leads to assemble in our biggest meeting room. We let every engineer walk around and talk to all of the teams and understand where they would like to work. This is scary. What if it doesn't work? At the end of this process, we ask every engineer to fill in the top two preferences of where they want to work. We have 12 or so teams in the last round that we did that. It's a little bit scary. The math doesn't quite work out. What we're hoping is that by setting out the charter, giving clear expectations, people understand the business context. That somehow magic will happen. The next step after people submitting their preferences, is to lock our development managers in a room and run a very complicated constraint solving process.
Here's where we've ended up. Eighty-three percent of people are in a team that they have chosen to work in. Just think about that. At Redgate, at the moment, in the teams you see here, 8 out of 10 people are in a team that they've had a genuine choice about where they can work. That's pretty cool. I couldn't tell you why it works. It does. Even more amazingly, 97% of people are in a team that satisfies their first or second preference. They only had two preferences. Almost everyone with the exception of one or two individuals, is in a team that they have voluntarily chosen to work on where they believe they can make a massive difference. It's not just that people are standing still either, one in three people moves between the teams. This is pretty cool. We've done this three times. Each time the stats have been around the same. I'm pretty amazed that this actually works. It seems to.
What have we learned from this? This really is helping form stronger connections across the teams. It is genuinely breaking down silos. We're seeing novel practices transfer from one team to another. We're seeing according to our internal engagement metrics, better employee engagement. That seems obvious. If you've chosen where you can work, you're going to be more engaged. We've got a whole process around this, which is available online there. I'll encourage you to read more about that. This really works for us. I really think this has been transformational for Redgate at solving that problem of silos. How can you experiment with reteaming? What's the smallest slice of your organization you could do something this scary with?
How to Increase Focus on Learning and Development
How do we increase focus on learning and development? Redgate is quite good at delivering software. We've done that for ages. We're not that good at looking at the outside world. We're not that good at bringing in new ideas or spending enough time investing in ourselves to get better. How can we increase our focus on learning and development? Our first attempt was to try and create some time. We got buy-in from the executive team, and our CTO, Mark, posted this in the summer of 2016. This isn't a novel idea. I think Google pioneered 20% time, which I'm reliably informed is now 120% time. We thought this would be a relatively quick fix. We got smart people, give them a bit of space, magic happens. We learned pretty quickly that that just isn't the case. Once the novelty of 10% time finished, then 10% time just became that time to do all the work you'd wish you'd done previously in the week. If you'd added some tech debt accidentally on Monday, then maybe it'd be ok because you can patch it up on Friday. There were exceptions. There were people who were really driven to learn, who made the most of this time. By and large, 10% time was a failure really. It definitely wasn't the utopia that we were hoping for.
Our next solution was to introduce a bit more structure for Friday afternoons. We tried out a thing called an open space. You probably realize what an open space is, but if you don't, it's a conference where the agenda is in no way predetermined. You literally turn up to a blank sheet of paper, and you hope that people are going to suggest good ideas for the afternoon. This is a pretty scary thing to do. What if no one turns up? What if no one suggests any ideas? What if people suggest the worst possible ideas, the exact opposite of what you're expecting? As it turns out, these concerns were pretty unfounded. I think this is the actual board from our very first open space session. We had a fantastic range of topics. We have all the usual technology things, the dreaded Kubernetes, Linux, F#, all these things. We also had topics from a wider group of people such as sketchnoting. We've even run topics where we've learned sorting algorithms with bells. Apparently, there was an interpretive dance on message buses. Apparently, video is on YouTube somewhere, do not find it. The concerns were unfounded. People had great ideas, we just need to give them a forum to share.
What have we learned from open spaces? For some people at Redgate, open spaces are the missing part of the puzzle. It allows them to collaborate with their co-workers. It gives them a forum to share their ideas, and so on. It doesn't work for everyone. What we found is there are some people who want more structure to their learning and development. The ad hoc nature of an open space just doesn't work for them. My take for you is what would it take to try an open space where you work? You need an afternoon, some enthusiastic people. Every organization's got those. You can try an open space out. I really think you'll be surprised at how awesome they can be.
Guilds
The next silver bullet that we thought we'd found was guilds. This time, we really did drink the Spotify Kool-Aid. We fell into this trap of implementing someone else's idea without understanding why. We thought if we get a community of like-minded people together, give them 10% time, give them a bit of funding, give them a bit of support. That magic will happen. Iteration 1 of guilds at Redgate was an utter and abject failure. It wasn't so much a failure of execution. We did the right things. We created a buzz around it. We gave funding. We trained up the guild leaders, or at least we thought we did. Really, many guilds were created and many guilds died. This is our Slack channel. It probably goes off the page here. There were a million and one guilds that were created at Redgate and just died because no one was interested in them.
In retrospect, the problem we have there was we didn't have any accountability. You could create a knitting guild if you wanted to. Didn't have to align with the needs of the business. That lack of alignment meant the interest died off. There were a few guilds that stayed around. The Kaizen guild stayed around, the Agile guild. It actually mainly just became a talking shop. They'd go into a room and debate the merits of Scrum versus Kanban. Do some arm wrestling over it. Then come out and nothing would change. It was just a lot of hot air in a room, a complete waste of time. We learned a lot from this.
Iteration 2 (In-progress)
Iteration 2 is in progress at the moment. We've done the generative culture thing. We've done that root cause analysis. We've tried to really understand where we screwed up. We've learned as well. We started speaking to other companies who've implemented communities of practice, or guilds, and understood what went right and wrong for them. We've read all the books that we possibly can. We've tried a much more deliberate model. Firstly, we've taken ownership of it. Guilds are brilliant for Spotify. If you're Spotify, they're obviously the right solution for them. At Redgate, we're calling them communities of practice. We've introduced a bit more of a barrier.
If you want to start a community of practice, you need some form of sponsorship from someone in a leadership role. This helps. This gives accountability and alignment. We aren't going to fund the knitting guild. If there's a Kubernetes guild, if there's a test automation group? That makes sense. I call them guilds. I should have called them communities. Naming is important. We've also focused on having less communities. These are the things we've got at the moment. We've got many fewer. We've got support for them in place on a continual basis. Now we get the leaders of each group together, and try and discuss the things that work and don't work. We try to set some accountability and give some platforms for that group to share.
What have we learned from that journey? If you're going to try and implement communities of practice, or just any cross-cutting group at your organization, I think there's three core things you need. You need sponsorship. Someone in a leadership role needs to have a vested interest in that group. They don't need to tell them what to do. That's definitely not it. They need to ensure that it's aligned. It should be aligned with where the business is going. Leading a community is hard work. You need to give continual support to anyone doing this because they'll often be volunteering to do it. At least in Redgate's case, it wasn't a formal role. We've seen that when they work, they really do drive change across Redgate. For example, our release community has made releasing apps completely painless. It's now scripted with PowerShell. It's beautiful. It's got rid of all the annoyances that we used to have. Now over to you. If you were going to invest in communities of practice in your organization, what one community would you start? How would you invest in that to make it work for you?
Run Our Own Conference
Our latest attempt at winning this L&D battle has been to hold our own conference. This is for everyone at Redgate. It forms the centerpiece of our learning and development strategy. Our byline is, "By redgaters for redgaters." This is an internal conference where everyone standing up and doing speaking is a redgater. You can see the program over here. We actually had 20 or so people standing up and giving a presentation in a massive auditorium, like you saw downstairs. We really invest in this. We have fancy programs. We have fancy posters. This looks and feels like a real conference. It's excellent. We really invest in support for those people. All those 20 people speaking, they've all had training. They're all now confident sharing their ideas with the wider community. We found that this has been the missing link in our level-up strategy. This encourages cross-role and cross-company communication. It gives everyone at Redgate exposure to topics that you might not choose to go to. I think one of the secret sauce of this, is that, at the company conference, there's a captive audience. Obviously, we're not holding people against their will. It does give us a chance to get a message across to everyone at Redgate. There are no silver bullets. This is just one thing in conjunction with others that works for us.
Current Generative Culture at Redgate
This is where we are at the moment, with all the things we do at Redgate to try and get this generative culture working, especially that piece around organizational learning. I think we're in a pretty good position at the moment. It's taken us four years. I think we started this journey in around 2016. The big question is, do I feel this has made a difference to Redgate's ability to try new ideas out? Yes. I think we're better at taking new ideas in. I think we're more comfortable with failure. I think we're more comfortable trying new ideas out. I think we're heading in the right direction.
What's the meta learning from all of this stuff on learning and development? Firstly, there is no one size fits all. If there's a training provider out there that's trying to get you to spend outrageous sums of money on a one size fits all thing. It's snake oil. Avoid it like the plague. People learn in different ways, and you've got to find a multi-targeted solution for that. Change is really scary. If we look at giving up control of the interview rota, that's this scary. Then we think about giving up control of where people work around the organization, that's off the chart scary. You've got to find experiments to ease your way there, where the cost of failure of that experiment is minimized.
If you're in a leadership role, then you've also got to accept that you are going to try out some crazy ideas and they are going to go hideously wrong. You just got to keep persisting, so those open space events. We could have given up after the guilds, and so on. We could have just not bothered trying. If we'd done that, Redgate would have been in a worse position.
Conclusion
Culture matters. If you're not working to build a generative culture at your organization you're in neglect. A generative culture is an incredibly powerful tool for transforming the way your organization works. The way to shape culture isn't stand up and give a rousing Churchillian speech. It's to change how you work. It's to introduce new things, try new ideas out. Did this work for Redgate as a whole? If I take those three examples that, organizationally, culture should improve? Did it improve our job satisfaction? Yes. I don't know whether it's correlation or causation.
When we compare our organization's retention metrics with similar companies in the area, we're not doing too bad. Things are trending in the right direction. Did it improve our software delivery performance? We've been tracking what's known as the four key metrics from the "Accelerate" book. Over the past year, we've released more software, better, and faster. Software delivery performance is going in the right direction. Ultimately, is Redgate getting more successful? We're not doing so bad. We had a record year last year. Can I link that up to the cultural actions here? Sadly not, otherwise, I'd probably get paid a hell of a lot more. You can find out more about some of the things we do at our blog, Ingeniously Simple, that's about how we work.
See more presentations with transcripts
