Building and Scaling a High-Performance Culture

Transcript

Shoup: I want to talk about building and scaling a high-performance culture, and I want to start with, "Why do we even do this stuff at all?" I'm going to quote Dave Thomas, who's a fantastic conference organizer in the Yale conferences in Australia. He's an entrepreneur. He was at IBM for many years, a computer science professor, a brilliant guy, and one of the nicest people that I know. He has this wonderful quip, which I can't find anywhere other than coming out of his mouth, but it's wonderful. He says, "Successful companies need to be able to build a product, they need to be able to sell a product, and they need to be able to get along." We're going to talk about all those things today.

As Dan mentioned, I've worked at a couple of companies, some small, some large so I spent a bunch of time at eBay. I spent some time at Google. I worked at Stitch Fix, which is a clothing retailer in the U.S., just now here in the UK. Please feel free to buy yourself some wonderful clothes, like I'm modeling today. Actually legit. Today, I work at WeWork, which is one of the fastest growing co-working spaces on the planet.

Peter Drucker, who is a business guru, probably you've all met, or at least quoted Peter Drucker, he likes to say this. He likes to say, "Culture eats strategy for breakfast." I think he's understating the case. To me, I think culture eats strategy, and organization, and technology, and process, and anything else I can think of for breakfast. So if I can have a team that has a really excellent culture, or even better, a large organization that is formed out of small teams that have great intra-team and inter-team culture, I think I'm going to be able to do a lot of great stuff.

Westrum Model of Organizational Culture

People have probably seen this book mentioned many times, and I hope they will see it many more times. Since I was here last a year ago, this fantastic book came out in July of 2018. It's Nicole Forsgren as the primary author, with Gene Kim, and with Jez Humble. It's called "Accelerate," and it's about how high-performing organizations and high-performing cultures work. One of the many things that the book discusses is the importance of culture in these high-performing organizations. They quote Ron Westrum, who is a sociologist, an organizational sociologist that talks about three different kinds of organizations. The kind you'd like to be in, which we'll talk about mostly today, is what he calls a generative organization, which is characterized by high trust and high sharing.

There are also bureaucratic organizations, some of which I'm sure people in the room have worked in or are working in. You don't have to raise your hands if you don't want to. Those bureaucratic organizations are characterized by rules and processes, like, "This is the way we do things around here, and that's kind of it." Then the place you really don't want to be in, and I have been in unnamed places, is what's called a pathological organization where people are doing things for fear of losing their jobs, or being humiliated, or something like that.

What the "Accelerate" book tells us is the science behind why the generative organizations are better on engineering metrics and are interestingly also on business metrics. So I want to motivate the problem with that, and then I want to talk about three ideas about how these generative organizations work.

The first is because we're engineers or mostly engineers these are the engineering metrics. The distinction between the higher, as they say, the super higher elite performers, as distinct from the low performers, according to the book, is the elite performers do 46 times more frequent code deployments. That's quite a lot. Their lead time between the time when somebody commits a piece of code, and it shows up in production, is 2,555 times. That's a lot. They have a seven times lower change failure rate. Even though they're deploying more often, the percentage of time that a deployment needs to be rolled back or hot fixed or something like that is actually seven times less.

By the way, they're also 2,600 times faster at recovering from those failures when they actually show up in production. So this is pretty great. I would feel pretty proud if I worked in an organization that was one of these elite performers, but it turns out that those same exact organizations are also two and a half times more likely to do things that people care about in business, which are profitability, market share, and productivity. If anybody thinks that culture doesn't matter, this is why it matters. I think it does matter to be nice to people, but that's just the beginning. Being nice to people helps us give better engineering results, and it also helps us with better business results.

I'd like to talk about high-performing culture today in three sections. First, I'd like to talk about the importance of trust and collaboration, then I want to talk about organizationally, the importance of autonomy and accountability. Those are two things you need to have at the same time. Then finally, I want to talk about the practices that are around pragmatism and constant iterative progress.

Trust and Collaboration

First, let's talk about trust and collaboration. People, I hope, are familiar with this idea of psychological safety. Google, being Google, collects a lot of data about you but also about themselves. And Google uses that data in something that they called Project Aristotle, to figure out what differentiated the really high-performing teams within Google from the less high-performing teams. It turns out that the biggest predictor of whether teams were successful was not the hypothesis of, "Did the team have more PhDs? Were they more experienced in the industry? Were they longer at Google?"

It turns out that psychological safety, whether the team was safe for interpersonal risk-taking, that was by far and away the biggest predictor for what teams were successful at Google. When we say interpersonal risk-taking, what do we mean? We mean being able to bring your entire self to work, being able to show and employ all aspects of yourself, whether gender, or sexual orientation, or religion, or political beliefs, all these different things that make up the sum total of us as humans, being able to bring those things.

And it doesn't mean we all had to agree on those things. It didn't mean we need to be the same. It actually just meant that we needed to respect one another. Everybody felt safe to bring their own self to work. By the way, why did that lead to great teams? It's because that trust enabled collaboration between the team, and it means that if I'm feeling accepted for myself, I'll be way more willing to suggest improvements that we can make to maybe our processes or our technology or something like that. And the fact that I'm not having to think about, "Are people hating me for those things?" I can bring my full self to work and be more productive than I otherwise would.

Again, as I mentioned, this was more important than any other factor at Google in determining team success. One of the underpinnings sociologically behind this is this idea of Theory X and Theory Y. I don't really like these terms, but I'll explain what they mean. Dr. Douglas McGregor wrote way back in 1960, so now 59 years ago, he was interested in, "What were the beliefs of leadership about what actually motivates individual employees?" He differentiated people. He found that people tended to cluster in either what he called Theory X or in Theory Y. A Theory X set of beliefs is the idea that people are sort of inherently lazy, they inherently avoid responsibility, and they require extrinsic motivation. As a manager, what you would do with this is you would be, "Don't trust your employees." You would micromanage and punish if things didn't go well, etc.

Whereas by contrast, people in Theory Y organizations tend to believe that people are intrinsically motivated, they genuinely want to do a good job, they genuinely want to perform, want to take responsibility, and so then the job of leadership is mostly to get out of their way. This diagram, which I really like, and isn't it all mine, shows Theory X and Theory Y a little more graphically. In Theory X, the management is sort of on top of the employees. It's a very sort of authoritarian, repressive, highly controlled environment, and sort of pushing down on the staff. Yuck. Whereas by contrast, the Theory Y is more like servant leadership where management is on the bottom, and they're enabling and empowering the staff to do a great job. No surprise, it turns out that the managers in the organizations that show these Theory Y beliefs tend to be those generative organizations, which perform a lot better.

The other aspect I want to talk about here is cross-functional collaboration. One of the key things to connect it up to that psychological safety idea is that psychological safety enables us to have open communication within a team. Again, I feel safe bringing my opinions and my thoughts to work. When we have open communication, we can encourage individuals within or outside the teams to work directly with each other without a lot of up and down through the hierarchy. Also, we are able to sort of prefer informal cooperation rather than formal bureaucratic channels. That because we have the trust, and if we as leaders suggest and encourage that people collaborate with one another, we're going to be able to achieve a lot more.

You could look at my hair, like many years in the industry, that the best decisions tend to be made not by one person, but they tend to be made in partnership in collaboration with a bunch of smart people. And interestingly enough, I have found that once we say what our goals and our priorities are, if we are very clear about goals and priorities, then oftentimes, when we're simply talking about tactics, we have a lot more opportunity to agree. I've also found that for the most part, well-meaning people tend to agree when given the common context, but that's the critical part is given common context.

One of the things that again psychological safety can give us, is the opportunity and the encouragement to share all the information that we have, rather than hiding it defensively, share all the information that we have, and get everybody on the same page. What I found is we don't always agree, but often, well-meaning people, given the same context, given the same information, will tend to agree. And when they don't agree, that's when you do this Intel strategy, which they called for many years disagree and commit.

The idea here is that we all put everything on the table. We say, "I think we should do X," and Mike says, "We should do Y." We make our best case, the team in the room reaches a consensus, and then if it's Y or whatever, doesn't go my way, whatever I said, I say, "Okay. Well, I disagree, but guess what? I commit to making it successful." I'm not going to backdoor try to undermine the thing that I didn't agree with. I'm not going to stonewall. I'm going to fully commit even though it wasn't my suggestion. This is how healthy organizations behave. The general idea here is this Japanese proverb as was often quoted by Bob Taylor, who put together the Xerox Palo Alto Research Lab in the 1970s, where they invented Ethernet, and object-oriented programming, and the laser printer and bitmap graphics. He liked to say, "None of us is as smart as all of us."

I'm going to give a quick example of putting these ideas into practice. When I was at Google, I lead engineering for Google App Engine, which is Google's platform as a service. Even though it's Google, it wasn't all roses and unicorns. We had issues. We had a particularly terrible issue when I was there, where the entire global App Engine system was down for eight hours. Nobody could do their Snapchats. Nobody could play their Pokémon Go's or the predecessor called Nemesis, so lots of ugliness all around the world, which was my team's responsibility to fix. Once we were able to mitigate the incident in production, we sat down with all the people, and we had a postmortem, or retrospective, or however you want to say it. I'll talk about quickly about the steps that we went through because it really had a great effect on the culture.

First, we sat down, and we identified the problem. We got all the stakeholders from my team and other related teams together. We enumerated all the known and all the potential threats to the reliability, because we had a bunch of those reliability issues sort of accumulate over time. At the end of this meeting, we consolidated those things into sort of 8 or 10 themes. Then we assigned, or more precisely, somebody volunteered for each to take forward each of those 8 or 10 themes. We timeboxed the investigation for a week, and then they came back after a week with some suggestions of what things we could do short term, medium term, long term to fix the issues.

That step three was mostly the same people, a few other leadership people in there, and we did a sort of consensus and prioritization, where we looked at everybody's suggestions across all those different themes. We said, "What are we going to do this week, this month, this quarter, this year, etc?" Then we got going. Then, as we were implementing a bunch of those things, which we ultimately called the reliability fix-it, we had engineers working on mitigating a bunch of those issues, fixing them, preventing them in the future, and so on. It took very little effort from management. That was me. It took me about an hour a week to keep everybody coordinated, but the results were amazing.

We got a 10X reduction in reliability issues going forward from that point, but even more importantly, was the team cohesion and the team participation that we all got around co-owning the reliability issues of App Engine going forward. When I meet with the people that were on my team, this was now six years ago, people still remember that particular issue, and that particular retrospective as something that really made a step change in the culture of the team. That's something that I was really proud of.

Coincidentally, literally, coincidentally, tomorrow I'm going to be running the exact same playbook at WeWork where I work today. We had not the same issue, but an issue around people being able to sign up for our services. I'm going to run exactly the same playbook. So we're going to get people in the room. We're going to identify the problem. We're going to understand the problem deeply for a week. We're going to come back together for a consensus and prioritization, then we're going to get going.

To underline something that Katherine Kirk mentioned in the first talk today in this track, "the follow-up," right? So it's all well and good to write a postmortem, and to put a bunch of action items in there, but it's only important if we do them. Then what I suspect is, I think I'm supposed to say profit at the end of this, right? Results profit, etc.

Autonomy and Accountability

That was trust and collaboration. Now, I'd like to talk a little bit about autonomy and accountability. All of us try to hire really great people in our organizations. I love this quote from Steve Jobs, which is, "It does not make sense to hire smart people and tell them what to do. We hire smart people, so they can tell us what to do." I just love that idea. Let's talk a little bit about what that means.

As an engineering leader, what I like to do is rather than telling my teams what to do, I give them a goal, even better if I give them a goal that has some clear customer valuable metric associated with it, driving some customer metric or some business metric. Then I want to give the team the autonomy to own the best way to achieve the goal. I'm not telling them how to do it. I'm saying, "Here's what I need you to do. Please figure out what's the best way to do it. I'm very happy to help and give advice, but you are autonomous in the sense of being able to complete the task."

It's not enough, though, to give autonomy. You also have to hold teams accountable, and this is the same for people, by the way. I say you are fully autonomous in figuring out the best way to meet this goal, but I'm actually going to hold you accountable for those results. By the way, the team and I have talked about the goal, so it's not like I just told them. But you're responsible for producing business value within your team, and you're also responsible for the results of the choices that you make within that team boundary.

To see why you have to marry autonomy and accountability together, imagine if you only had autonomy. I'm a single parent. I have a 12-year-old son who's quite autonomous right now. But when he was one or two, a child is very highly autonomous, but not very accountable. That's a child. But most of us have probably also, sadly, experienced in our professional life the accountability without the autonomy. That's every nightmarish, ugly enterprise situation where, "Yes, I'm going to hold you responsible for this metric." "Yes, but can I change all these?" "No, you can't change that stuff." It's important that those things be together. If I'm going to hold you accountable for something, I need to empower you to be able to move that thing and vice versa.

Most of us have probably seen these kind of traditional organizations. Thankfully, they are less common in the modern world. It used to be that there was a team of idea people, maybe we call them business, or we call them product or something like that, and they throw ideas over the wall to the well-paid typists who are basically us in the room. Those well-paid typists then throw their code over the wall to some quality people to make sure that they type correctly, and the stuff that they built in didn't completely crash. Then we through it over the wall to operations people who we never talk with. This is not a great way to build software as we have learned.

A much better way to build software is putting together all those different disciplines into one place. I'm using particular examples from WeWork here, where we have a team that builds tools for our real estate professionals. We have teams that build software that are around finding new members, growing our membership, and then we have my team, which is around building software for members and community managers that come and operate our spaces. You'll notice the colors. We're putting together the idea and the development and the quality and the operations in one place.

Why? We do that to empower the team so that they are able to be autonomous and accountable, but we also do it so we can shorten those feedback loops. If I have all the skill sets that I need to do my team's job within my team boundary, I can move much faster, and I can move independently of the other people in my organization. That is hugely empowering and a huge force multiplier for high-performing cultures.

The other thing is to make sure that those teams are aligned with something that's important, so aligned around a particular business problem, whether it's a customer problem or something that we have internally to the business. Clear goals and metrics are really important, and then also making sure that that team has a well-defined area of responsibility. Then typically, Dan mentioned that maybe I would talk about the duality between culture and organization and technology, and I'll just give a nod to it here, which is typically in our kind of microservice-y world or component-y world, one of those teams would be responsible for maybe a single application or a single service or maybe a set of related applications or services.

Then the other aspect is to make sure teams have end-to-end ownership around the stuff that they do. Teams should own their own roadmap, within the context of the goals that we collaboratively set together. The well-performing teams are going to own their service from design to deployment all the way through to retirement. What's critical is to make sure that we don't have like the team that builds the new sexy stuff and the other team that maintains the old terrible stuff. Has anybody had that experience? Let the record show that a substantially large number of hands went up and even more laughter. I suspect there was even more there. That's terrible.

Again, why? Because that team boundary needs to be that boundary of accountability and autonomy. If you say one team gets the new cool stuff, but isn't responsible for fixing the old stuff, or vice versa, that we have a team that's responsible for maintaining the old stuff, and they are not able to influence or use their knowledge, that's been a hard one, use their knowledge to help improve the existing parallel new system, that's not a great place to be. A much better way to do it is to have a team own a particular, again, business area, whether there's old legacy stuff, or new sexy stuff, or whatever.

Pragmatism and Progress

The last area that I want to talk about is what I like to call pragmatism and progress. I'm trying to be, I guess, a little alliterative here because that makes it sound nice. I particularly tend to respect engineers that I work with that are highly pragmatic. They want to get the job done, and they want to get it done well, but get it done minimally. If you take nothing else away from this talk, I'd like you to take away these seven words, which will serve you very, very well. These seven words are, “What problem are you trying to solve?”

Here's one way we can deploy these seven words. Has anybody had a situation where one of those idea folks, who we love, will come and say something like, "Hey, Randy, could you and your team add a button to the website to do a thing?" Anybody had that experience? Let the record show that very many hands went up and then lots of knowing laughter. You should say, "Yes, we could totally do that," but humor me for 5 minutes, 10 minutes, 15 minutes. What problem are you trying to solve?

What you're not saying is, "Talk to the hand. I don't want to do your thing." But what you are saying is, "Help me understand what you're trying to achieve because guess what, if you tell me what you're trying to achieve, and I understand it deeply, I can tell that to the team, or maybe hopefully the team is listening as well. Also, I might be able to have other suggestions that would be better, easier to maintain, faster to implement, etc., that you might not have considered."

It turns out craze. My background is weird. I have a political science degree, and I also have a degree in applied math. I learned very disjoint, interesting things in both of those things. In political science, I learned a lot of interesting stuff like appreciation of nuance and understanding of tradeoffs and the importance of history, but I did not learn disciplined problem-solving. That is what we often learn whether we like it or not, or whether we even know it or not. That's something that whether you have a degree, or you just simply practice engineering in the real world you have learned how to break down problems and approach them in a disciplined way. Not everyone practices this as much as we do. This is not, "We are smart, and other people are not." It really isn't.

But we are maybe uniquely able to be in those conversations and break down what problem people are trying to solve in conversation with them, and make suggestions that offer different tradeoffs and different tradeoffs that we can talk about. That is something that we uniquely as engineers can bring to the table, and that's not particularly given, I'll say, the average kind of personality type of an engineer, which I super am part of. That doesn't always come easy to us, but that's our unique value. We're not doing our jobs if we're not asking this question. We're not doing our jobs. Don't take five hours and beat them to death, but like 5 minutes, 10 minutes, help me understand what we're trying to achieve.

When we understand the problem very deeply, we also get a lot of other benefits. I love this quote from Charles Kettering, who used to be head of research at General Motors in the United States, "A problem well-stated is a problem half-solved." Oftentimes, if we can really understand the problem deeply, we are halfway or more to an implementation that makes sense, that is straightforward, that is minimally viable, etc.

The other thing that I would say is we don't always have to solve problems in the same way. To me, engineering is about solving problems. Sometimes, we solve those problems by writing code. I have worked now in several physical businesses, so now at WeWork, and then before at Stitch Fix. Often, when I work with people that do the physical stuff as part of the business, again, part of that engineer training can be, "Hey, you want me to add the button to the website, which I can totally do, but let's talk through the business process that you're trying to maybe automate or you're trying to add on to."

Oftentimes, that conversation will mutually realize, "Wow, we should just change the business process, without even changing the technology at all." That happens surprisingly often. So again, I strongly suggest that you bring your entire engineer mind to these conversations. It's not about how many lines of code we ship, obviously. It's about how many business problems are we able to solve.

The other reason to understand the problem is this. I love so much Mary and Tom Poppendieck. This is a 2003 book called "Lean Software Development." I highly recommend reading it because even 16 years later, it's amazingly apt. It was revolutionary 16 years ago, by the way, but this idea that, they characterize seven different wastes in software development, but building the wrong thing is the biggest waste. There's lots of wastes that we have in our industry. "I did it inefficiently blah, blah, blah." If I build the wrong thing, it's like 100% of my effort was wasted. It would have been better to go on vacation than to have shipped this thing. That's one idea, what problem are we trying to solve?

Once we have that in our head, let's do the next thing, which, again, if I can ask you to remember four more words, it would be these, "Fewer things, more done." Traditional organizations, and I have led these things, even relatively recently, before I saw the light. Maybe I have five people on my team, and I have more than five things to do, of course, and maybe I put each of one person on one of five features. Who organizes their teams in this way? You would think this is great. Actually intuitively, "Oh, we've got more than five things to do. Let's get started on all of them." It turns out that's not great. Here's a better way.

This is assuming that the tasks can be combined, let's assume that for a moment. Maybe I put two people on feature one, and we get it done in half the time. I put two people on feature two. We get that done in half the time. What's great about this? We've released the two highest priority things in half the time, right? Already I'm ahead, and maybe the fifth person is working on feature three, something like that. Then, of course, once those pairs are finished up with feature one and feature two, then I can put them on four and five. So I've already made the world a better place by simply doing instead of five things in parallel, three things in parallel, already made a great improvement. Let's see what else we can do.

What if we crazily enough broke these things up into smaller chunks, and we ship them iteratively? I'm making this up, but maybe we could break feature one into four reasonable individual releases, and lots of times, honestly, it takes a bunch of thought ahead of time to figure out what are good things that we can release on a smaller cadence. Also, by breaking it up, what I've done is, again, I've released value more quickly to my customers, and so with the time value of money, I'd rather have $100 today or £100 pounds today, than tomorrow or next week or next month. I produced value more quickly, but also, I've made myself immune to this. This I took at the last QCon London as I was walking to the venue. I love this.

Who worked in a place where they've worked on something for a long time, they weren't quite finished, but then priorities changed? Let the record show that almost every hand went up, right? It doesn't mean priorities don't change, but what it does mean is that you don't get 7/8 of the way through something and then produce no value. I hope this is obvious, but sometimes we have to remind ourselves of the obvious stuff. It doesn't matter how much effort I put into something if it doesn't ship. If it does not ship, all of my effort was wasted, right? Maybe I learned something. But I didn't produce the value that I was intending to produce.

The last idea in this section is that quality matters. What do I mean by that? Actually, let's do this little thought experiment. Who has heard this, "We don't have time to do it right"? Knowing laughter and half the hands went up. I'm going to give you another cool response, which is this, “Do you have time to do it too twice?” That is often the tradeoff. It really is. We can talk about experiments as a separate idea. But if I'm doing a feature that we know we're going to build or that we know we want to do for serious, and we don't have time to do it right. What we're really saying to ourselves is that we're going to do a little bit now, we're not going to quite finish, and then we're going to come back around, and maybe more expensively fix it later.

By the way, if I'm doing an experiment, right is as cheaply as possible. So right is very context dependent to doing something right. Still, I suggest that we try to do a small number of things with high quality, rather than a large number of things with low quality. Let's do another thought experiment. A bunch of us carry around supercomputers in our pockets, which we call mobile devices. Remember the last time that you updated the operating system on your device. Who said, "Wow, when I got iOS 12.2, I'm so glad it has 57 new features in it"? Let the record show no hands went up. You're learning.

Rather, we would probably go, "Wow, there are one or two features in there that matter to me." Sometimes, some of those 57 features are going to matter to some people and other people. I'm not suggesting that 57 is terrible. What I am suggesting is that I'd much rather do a small number of great things rather than a large number of half-finished things. Interestingly enough, this is quite counterintuitive but stick with me. This whole week, we don't have time to do it right idea. In my experience, the more constrained we are in time and resources, the more important it is for us not to have to build it twice.

It is so much more important when I have limited time, limited resources. I can only do one or two or three things. Those things better be good. I'm not suggesting they be perfect, but they at least have to be solid. They need to be solid so that I don't feel like I have to go back and fix it for it to be finished. Since I mentioned iOS, I should tip my hat again to Steve Jobs, "Don't try to do everything, but do one thing really well."

The last thing that I'd like to suggest in this quality idea is how we might approach in a high-performing culture, how we might approach technical debt. I'd like to contrast what I have often seen, and I'm sure some of you have the misfortune of experiencing, is a vicious cycle of technical debt, where we do something quick and dirty. We didn't do it kind of properly from the beginning. Again, I don't mean perfect. I mean, just solidly and minimally. We did something quick and dirty. We've accumulated some technical debt. Now we don't have time to do the next thing right. So what are we going to do? Quick and dirty, more technical debt, no time to do it right, round and round, and we sort of spiral down, and it becomes very difficult to get ourselves out of it.

What those high-performing cultures tend to do, and it's not easy to do this transition, but we'll talk a little bit about how to do it, is transitioning to a virtuous cycle of investment. Instead, what if we make an investment in building something with reasonable minimally viable quality? Now we have a solid foundation for the next thing we're going to do. That gives us confidence to build the next thing. That next thing comes out faster and better than it otherwise would. Now we freed up a little bit of maybe development time or resources or kind of management goodwill, and we're able to make more investment in quality. We can have a more solid foundation. We can be more confident. What I'm suggesting is that we can actually bend or turn with some good practices from that vicious cycle into this virtuous cycle.

One of the suggestions that I have about how to do that, how to approach that, is from this even newer book by Barry O'Reilly called "Unlearn." I strongly recommend it. I think it came out in January, so it's very, very new, a fantastic book. Several of the things that he suggests is that really high-performing organizations and high-performing people are good at noticing when they need to let go of previous habits and adopt new ones. Was anybody here for Katherine Kirk's talk at the beginning of the day? Remember how important it was to recognize our habitual reactions, and to maybe change our habits going forward? That's how we get personal change, and how we get culture change as Katherine told us.

This is part of that process. It's that recognizing those behaviors and mindsets that may have been successful, in our previous lives, in our previous organizations, let's say, and we try to unlearn those behaviors and at least question those behaviors and mindsets. We then open ourselves up to relearning new skills, new strategies, new innovations, and then that allows us to break through those old habits and learn something new. Does it make sense why this would like lay the foundation for making forward progress?

Does it also make sense why this is not just something that you would do as a person, but that you might also do as a team or as an organization or as a company? This isn't just for a person. This is for all the kind of units in the organization. We talked about trust and collaboration, we talked about autonomy and accountability, and we talked about pragmatism and progress. I want to leave you with some other, maybe I don't know, deeper thoughts or things to watch out for.

Has anybody heard this quote, “The culture of an organization is shaped by the worst behavior the leader is willing to tolerate"? This is true. I'm not going to give any example, and you did not see the logos legit today in my presentation. I've absolutely worked in organizations, not just one where the leader was willing to tolerate and often foment, like really terrible behavior. That's one of the key dysfunctions or toxicities, that's what tends to make a company one of those pathological organizations that I suggested in the beginning.

I do want you to genuinely try to change the culture and the behaviors of your organization. But recognize that sometimes, you're only one person, and you should give yourself the permission to not be able to always make those changes. If you are in that situation, then I have a wonderful quote for you from Martin Fowler, which is, "If you can't change your organization, you can change your organization."

Entirely unrelated, and I'm not even joking, we're hiring at the place that I work. Maybe surprisingly for a commercial real estate company, or one that's known as commercial real estate, we have 700 software engineers globally, all over the place, Europe and Asia and the Americas. Thank you very much for your kind attention, and I think we have some time for questions.

Questions & Answers

Participant 1: The first point that you mentioned was about trust and collaboration. The other one is autonomy and accountability. With accountability, we could potentially have any impact on psychological safety and the opposite because, if you have low psychological safety, then maybe you are having a bit of a high accountability and vice versa. Would there be a relation and how can we balance that?

Shoup: I think there is a relation. I don't think that they are mutually exclusive, but I love the question. I think that in an organization or in a situation where you have high trust and high collaboration, you're able to safely give people more responsibility. I don't think what you're suggesting. It's not like I don't want people to be responsible, and that somehow makes it safe. In a psychologically safe environment, in one of those generative organizations, in one of those Theory Y situations, people genuinely want to take on responsibility, right? That's something that we want to encourage. We need to make sure that it's safe for people. We need to make sure that when I hold somebody accountable, if what you're hearing is holding accountable, meaning shaming them if they didn't meet, that's not what I mean.

It comes back to parenting. I don't know how many are parents are there in the room. As I mentioned, I'm a single parent. My son is wonderful, but sometimes he does things that aren't great. He's a kid. It's totally normal. Rather than berating him or making him feel ashamed, we can have a conversation about better behavior. I think often, if you're a parent, if you can think about what you would do with this other person that you're working with, if you were in a family together, oftentimes you're going to find the right solution. Again, being responsible for something is not bad. That's part of being human. It's actually part of, I think, doing a good job. It's a great question. Thank you.

Participant 2: Great talk, Randy. You had a slide on full-stack engineers, and you talked a lot about autonomy. Can you speak a bit to the limits of autonomy, and one could listen to this and hear there's total autonomy for a lot of engineering teams?

Shoup: It's so funny that you asked that, but in a conversation over, let's say, adult beverages last night, I was talking with other people about that. I couldn't fit it in. But I do believe that teams should have autonomy. I like the Google model and the Stitch Fix model and other models and Netflix too where there's kind of a paved path. There's an easy way to do things, which is enabled by the system. What I don't like is a monoculture where you can only do it one way, but I strongly believe in the idea of, "Here's a way that's really easy," so each team doesn't have to reinvent the wheel. If and when there's like substantially order of magnitude better way to solve the problem, then I should be able to do that.

There are some problems that are just way better solved in Haskell than Java, for example, right? That's why we have different programming languages. If I am in that situation where I have a very Haskell like Haskell full problem, I should be able to do that. But the accountability is the other aspect; it's on me to figure out how to integrate that new service into the monitoring system, into the deployment system, etc. You suggest, "Is it full autonomy?" With the accountability, I think that's partly the counterbalance. Thanks for the question. That was great.

Participant 3: About the second part – Autonomy and Accountability - I totally agree on the idea that if you have the scenario, where you have teams that do the cool thing, and teams that do the legacy things, you solved it by basically having a team that touched the whole thing. I find myself in the past, in a situation wherein within the team there were the team members that are, let's say, willing to do the hard work and willing to dig the mud, getting stuck into the mud, and people who kind of that were a bit better at, let's say, dodging or just working on the smaller and quicker task. They were always free to do the cool thing while the others were stuck in the other. How would you tackle that? Is there a solution for that?

Shoup: I think honestly, simply recognizing that is almost, you’re 80% of the way to the solution. If that's something you could imagine within your team recognizing that, "Hey, Wes always takes the terrible, dirty task, and Randy always gets the new cool stuff." Does that seem right? Oftentimes, if we just make everybody aware of that, we can come to a conclusion that makes sense. Let's also recognize that not everybody is motivated by the same things. I'm not going to get metaphors right, but they’re farmers and they're warriors, and they're just different. That's not a great analogy, but that was Martin Thompson's talk from earlier today. There are different people, a lot of people are motivated by, "Wow, that's terrible. I want to clean that up," and there are other people that aren't motivated with that at all.

I think asking the question and making sure maybe it's in a team setting, or maybe a one on one, that might even be better. Wes, are you okay with constantly getting that, and if you have trust and psychological safety, you'll get a legit answer, and then you can as a leader, help to encourage the right behavior. I just love just noticing that and recognizing that. I think you're well on the way. It's the toxic dysfunctional teams where you make assumptions, or you just let it happen without maybe challenging it.

Participant 4: I only ever ask awkward questions. How do you make this persist beyond management changes? Because that's been the challenge I've run into it. But making it sticky is really hard.

Shoup: That's good. It depends on which 'this' you're talking about. We can have a conversation more deeply later.

Participant 5: The cultural change to something better, and I would say generally.

Shoup: The honest answer is it depends. It really depends on the old person, the new person, etc. It is hard to change culture as we've learned, if you attended this track for most of the day. They're actually even as people had experienced, I certainly have, coming in as a new manager, or even a new executive in a team or an organization that was already functioning there correctly. There's a lot of inertia and weight behind the existing practices and the existing culture. It's funny, if you've gotten to a good place, it's well, easier to destroy a good place than it is to fix a terrible place, but there is a weight behind that. I guess that's part of it.

I would also suggest that as an executive now, I would be looking for somebody to continue. At one of my hiring criteria, to be honest, of putting somebody or hiring or moving around whatever criteria, to put a leader in this particular part of the organization is to make sure that to the extent that there are great things going on there that that leader is going to continue.

See more presentations with transcripts