������

Neal Ford: Welcome, everyone, to the ������ Technology Podcast. I am one of your regular hosts, Neal Ford, and I'm joined with one of our relatively newer regular hosts, Birgitta. Hi, Birgitta.

��

Birgitta Böckeler: Hi, Neal. This is Birgitta Böckeler. I'm a Technical Principal at ������ out of our Berlin, Germany office.

��

Neal: While she's a very new host, we're joined today by one of our other regular hosts but as a guest today, and someone who's been at ������ for a very long time, and it's frankly a little bit shocking that he hasn't been on podcast before now.��

��

This is a special event podcast, because this is officially episode number 100 of the ������ Technology Podcast, which is shocking to all of us involved, probably, as much as to those of you who are listening to this podcast, that we've had this going for four years now. We thank all of you as our regular listeners, which has been awesome.

��

One of the things that we've never talked about is how does something like this podcast come about within a consulting company like ������? We thought today we would do a deep dive on innovation at ������, and so I'll let our two guests introduce themselves. One of them is another of our regular hosts, Rebecca Parsons, who's also in her role today as the CTO of ������.

��

Rebecca Parsons: Hello, everybody. This is Rebecca Parsons, and I'm happy to be here to talk about how we've built this culture of innovation in this strange organism that is ������.

��

Neal: And a big contributor to that strange organism is our other guest today, who's Chad Wathington. Hi, Chad.

��

Chad Wathington: Hi, I'm Chad Wathington. I'm Chief Strategy Officer for ������, been here about 18 years so really happy to be on the podcast for the first time. It feels like a big honor to finally be sitting in the chair.

��

Birgitta: Yes, we were just saying that I'm the ������ baby in the round coming up on 10 years of ������. If you all now talk a bit about ������ history, and bring up strange terms and names that listeners might not know, then I can bring up the questions. [chuckles]

��

Neal: Let's talk about some of those strange names and themes, because ������ is a global consulting company but we have an inordinate number of books and open-source software, and an enormous presence in the software development community given the relative size of us as an organization, so why is that?

��

Rebecca: Well, I think from the beginning we were relentlessly focused on getting better — on figuring out what we could do to build software better, to build software faster. The upside of that is we are constantly looking for — Okay, if I just had this tool to automate this process, then this would all go a lot faster — and there is CruiseControl, the first continuous integration server.

��

The downside of that is that while we are very good at saying, what did we do wrong here? We don't spend too much time saying, "You know, actually, [chuckles] that was pretty cool what we did.” We are far more focused on how we can make it better. But that's really been true since the beginning. It's this relentless focus on continuous improvement, knowledge sharing, putting ideas out there so that we can learn more because if we put our ideas out there, then somebody's going to tell us, "Oh. Well, maybe if you tweaked it this way…" and then, we've learned something, too.

��

Chad: Yes, I think in general, if you were to say that most company cultures hinge innovation off of something, we certainly hinged ours off of that drive for continuous improvement. I think if you look back on many pieces of open source — for example, Rebecca noted CruiseControl and continuous integration — much of it was in a project trying to solve a problem, and someone said, "Hey, what if we could do this?"

And it just takes one team trying this for the context of one project sprint, or iteration or something like that, and then it becoming something. So with continuous delivery, the team that wrote the original white paper on build and deployment pipelines created this tool called Conan the Deployer. Conan the Deployer was the result of going through an entire development cycle for a piece of software, and the deployment failing at the end, and then missing the deadline. The team said, “How can we stop that? Oh, let's call this tool Conan the Deployer.” That fundamental idea underpinned so much of what became continuous delivery later.

��

Birgitta: It's also, I guess, part of the core of many consultancy companies. Always looking for what's wrong and improving it, because that's the job. One Thoughtworker once said to me, "Oh, our job is to complain… always finding the thing that's wrong." I worked for another big consultancy before I joined ������, and it seems in ������ there's even more drive to always try new things and always push the boundaries.

��

What would you say maybe is different in ������ compared to other companies that also have this core of always looking for things that need to be improved?

��

Rebecca: Well, I think part of it is we really firmly believe in this idea that we are going to revolutionize the IT industry. We have had for almost my entire time here — and I've been here 21 years now, which is a scary thought in and of itself — but we've had that tagline, we want to revolutionize the IT industry. We really can't do that unless we put the ideas out there.

��

We are also very attuned to the fact that many of the practices that we use through our normal software development process hinge on some form of automation. You're not going to integrate continuously if you have to run the build yourself every time — Hence the idea of a continuous integration server. You don't want to have to continually test the same thing over and over again, so let's do automated functional testing.

��

A lot of it is we know it works well to develop software the way we do and so we're going to automate this stuff and then we're going to tell other people about it, because it really is a better way of building software, and ultimately, what we want to do is change the way software gets built and improve that, so that we don't have these massive budget overruns and failures, and all of the stuff that you read about in the press all the time.

��

Birgitta: So have something really strong in the company mission or vision that really drives this example, right, of revolutionizing the IT industry.

��

Chad: And I think it's also a virtuous cycle at some point, and at the point that we realize that, then, we're intentional about it. We're intentional about fostering that people are unblocked from that kind of innovation. I think sometimes people talk about innovation in these very generic terms: "We're going to go after here and build some amazing things." Well what does that matter?

��

What Rebecca talked about automation, we've known that for 15 years. Once you know something you continue to push it and you make sure that people culturally know it as well. Right so we have this idea — and Birgitta you know quite a bit about this on sensible defaults – on a project, people are supposed to think about the sensible defaults first as a starting point.

��Well, once we realized this was a good idea [chuckles] that the juxtaposition of a way of doing things that's somewhat consistent, versus the continuous improvement in learning, and challenging ourselves to say, "We did it that way yesterday, is that the right way to do it today?" How do you come up with a mechanism to embody that, and then you keep going, right? So I think it's really about the intentionality once you understand how the virtuous cycle works?

��

Neal: I think the ethos of the open source software movement was a heavy influencer in the early days of ������ as well, because that's when open source really started coming into its own and becoming respected as a proper thing. A lot of the early innovation at ������ was expressed exactly through open source.

��

We had a huge number of open source contributors — still do — but a lot of very notable open source contributors back in the early days. What are some of the first open source projects you remember coming out of ������?

��

Rebecca: Obviously CruiseControl was one of the early ones, but we've also had some award-winning ones. There was a testing framework developed by one of our guys in India that took advantage of a particular innovation in .Net 3.0 — something came out at that time that could change the way you do the GUI testing.

��

One particular funny thing about that is at the same time someone from our China office was trying to use that same improvement in the .Net ecosystem to create a different tool. One person was raging at me: "Why are you letting two people try to solve the same problem?" It's like, "Because they're doing it differently." We don't know which one's going to work out, so, no, I'm not going to tell them to work together. I'm not going to tell one person to drop their idea. Let's see which one pans out."

��

It ends up the one in India was the one that panned out. It was called White and it won an award from Microsoft for tooling.

��

Birgitta: A misguided goal of efficiency can sometimes stand in the way of innovation as well, yes? So in terms of priority, so you have two people doing a similar thing, that's inefficient, let's just have one person do it, but then you might miss out on ideas, right? It's a matter of priority sometimes then.

��

Rebecca: Exactly, because you don't really know when an innovation is going to pay off/ We all know the best technology does not always win, Betamax versus VHS, [chuckles] the standard example. The same thing happened with Blu-ray technology versus the other competitors. It's not only how well does the technology solve the problem, but how well is that innovation accepted in the ecosystem. Sometimes things fall flat, or they address a particular need.��

Chad, I'd like you to talk some about Rubyworks because it filled a niche — for a time. But we always knew it was going to have a short shelf life.

��

Chad: Yes. Wow, Rubyworks, that's a throwback! I think Rubyworks is an example of us understanding that, on one end, we were doing all of these great, interesting things with Rails and Ruby overall and that we needed a way to deploy better. A lot of people had come up to Rebecca's point about which innovation's going to work, had come up with different ways to deploy Rails projects, and there were problems with all of them.

��

So what we decided to do was really take the time to say, "Okay, in the ecosystem that exists today, what can we do to make this better?" Not try to come up with our own way to deploy Rails from scratch. We created Rubyworks with the hope that it would go away, because we wanted something to come along that was better. We wanted JRuby, for example, and Ruby deployment on JVM to possibly be better.

��

We said, "What can we do now to ease the pain?" And I think the other thing that sticks out to me about Rubyworks was the ecosystem and really having an understanding in open source of what was going on, and trying to participate in that culturally. There's a former Thoughtworker named Paul Hammant, who was really, really, really good at that, and he helped us know who the people to talk to were.He was almost a nexus of activity in open source.��

��

I remember going to Oz Con with him and just everybody knowing who Paul Hammant was, [he was] really trying to participate in the ecosystem. We understood what the JRuby development team was doing; we understood what Rubinius was doing. We understood all of these players trying to solve this problem, what they were doing, and then we said, "Okay, what is our behavior in that? What are we going to do in the short term, and what are we betting on for the longer term?"

��

Birgitta: You just gave an example of how people are really important in the culture of innovation, like with the example of Paul, but another person that in ������ was really integral in the culture of innovation was our founder, Roy. You were talking about Ruby, as far as I know, and you are the older Thoughtworkers, right? He was one of the people who really pushed everybody to use Ruby, and then ������ became one of the earlier adopters of using Ruby on a wider scale, as far as I understand the history.��

��

Can you talk a bit about Roy's role in innovation in ������?

��

Chad: Yes. Roy was very good — probably was isn't the right word — is very good personally at collecting people, listening to what they're talking about, and spotting patterns. Roy made himself available, which is probably another thing to talk about in terms of leadership, but Roy made himself available for people to come pitch him ideas, and tell him the latest thing.

��

He was always trying to connect the dots and pattern match. What I think happened around Ruby was a really big internal conversation, not about Ruby itself, but about dynamic languages versus static type languages and how, from a productivity perspective, the world was going to play out in the long term. What Roy identified in all that was that we needed to make a bet on dynamic languages. Then he went about listening to people again, to figure out which one. [chuckles]

��

And so he did a bunch to figure out which ecosystem: the Ruby ecosystem and the Rails ecosystem, versus the Python and the Django ecosystem etc. to learn and to listen to people. Roy ultimately ended up pushing Ruby quite a bit and we ended up making a bet as a company on saying, "Hey, dynamic languages can be used in the enterprise and here we're going to show you how." But I think that was just a symptom of a long arc of Roy trying to help us be more productive and then listening to all these voices and synthesizing around.

��

Birgitta: Yes. Even not being a developer himself, right? Like really good at just listening and finding what it means, without maybe understanding what it is, if that makes sense. [chuckles]

��

Rebecca: Yes, he did write code long ago, but he wasn't an active developer, but I want to amplify something that Chad said there, because I do think it's central to our ability to have this culture of innovation, which is: Roy made it clear he would listen. Specifically, Roy, even though he was the CEO of the company, and the President of the company and the Founder of the company, he also made it very clear that technology was at the center of who ������ was, and is, and will be.

��

We actually have this phrase that we use tech at core. It didn't matter how long you'd been in the company. It didn't matter that you were only a developer. Roy wanted to hear your ideas about technology, and that emphasis on our technological roots, the influence that technologists have always had in the business decision making of the company is a lot of what brings this culture of technical excellence and this feeling "Yes, it is in the company's interest to continue to push this envelope and continue to innovate," and recognize that, it's not like I can say, "Birgitta, you're going to come up with a fantastic idea on Thursday."

��

Great. Thanks.

��

You have to have an environment where ideas can flourish, where people can experiment, where people can feel like it's okay to try and experiment and have it not necessarily work out all that well. I think that central role that technologists continue to play in the decision making at ������ is an important part of that.

��

Neal: The way I thought about Roy was I thought he had a great instinct for informed disagreements about things. He could tell when people were really knowledgeable about those things, but had legitimate disagreements. He knew there was something there in that disagreement, that even if he didn't have the details, he could see exactly what that was, but I think that's — so I think we've touched on two of the key elements required to nurture this innovation.

��

One of them is, what we've just been talking about with Roy, because one of the things that Roy gives a technologist who has a new clever idea is hope, because in so many large organizations, you have a clever idea. You tell a bunch of people and they say, "Hey, that's a really clever idea." And that's it. You get credit for a clever idea, but there's hope in ������ that if you get Roy excited about it, then the whole direction of the company will change, because it happened several times. [chuckles]

��

That was something that informed the passion that people have. But I think the other side of that coin is when we were talking about Paul. Chad was talking about Paul as being this nexus, where everybody came to Paul to show him stuff. Part of the reason was that Paul was involved in everything and he was brutally honest about what he thought about things. There was no doubt with Paul that it might be that he was just being polite because he never was, but that was good. That was a feature, not a bug because you always got good honest feedback, and so that combination, of course.

��

Birgitta: Can also backfire in the culture. You're then afraid to bring up ideas because there's a really straightforward, brutal person.

��

Neal: I think that's part of — I think that's a really great point because if you know Paul you know that personality is not personal. It's just him, but you have to get to know him enough to get past that, which is always a struggle sometimes with people like that. I think that's the two key things is the platform, the fertile soil to grow those ideas, but then good feedback to iterate on them to continually make them better in an environment, where you're encouraged to keep making things better.

��

Birgitta: What you just touched on with knowing a person as well, that works a lot better in a smaller company than in a larger one, which is often a struggle in companies, when as you grow and you actually have to put more structures in place, there's more people, leaders actually become less approachable because company is bigger. So then, how do you scale that?

��

Neal: That's a good question for Rebecca and Chad because as the company got bigger, Roy became more and more difficult for him to be this innovation mascot that he was, when he could fly around to each office and try to shame people into doing new things, that doesn't scale globally forever.

��

Rebecca: We actually spent a lot of time thinking about scaling culture. One of the many titles I've had at ������ over the years, I was actually the Vice President for Innovation and Culture. At that time one of the things that we were grappling with is we needed more organizational structure because there was Roy and then 999 other Thoughtworkers. And that's when he broke.

��

Now, most people cannot scale to having in excess of 900 direct reports, but Roy actually could. But he couldn't get much past that. We spent a lot of time talking about what was important about that flat culture. And what was important had nothing to do with whether or not somebody had a title. It was who you could talk to, what the lines of communication were.

��

In a traditional hierarchical organization, you talk to your direct boss and your direct boss then talks to their direct boss. You don't hear what your boss says to their boss. It can get shaded a little bit. You got a long enough chain and the message is unrecognizable by the time it gets to the top. What we said in that context was, "Regardless of who you are, you can talk to anybody else."

��

People still ping me, out of the blue, with ideas, because we try to continue to tell people, "No, you might think this person is unapproachable because they're the CEO or the CTO, or the chief strategy officer but, no, we encourage you to go talk to them." It does get harder when you get bigger, because that's just more people who are going to be pinging you. There's only so many hours in a day to answer emails, but that was a lot of it.

��

Going back to the innovation question, we didn't have a center of innovation. You people are allowed to innovate; you people are not. That doesn't make sense in our culture. It's everybody's responsibility to continually look around them, and see, are there ideas that they think will improve how we work, the work that we deliver, etc.

��

It is that lack of hierarchy, shared accountability, but shared accountability in a way that doesn't let everybody off the hook. Very often people will say, "If five people are responsible, nobody's responsible," but we do have a shared accountability for continuing to innovate, continuing to come up with new ideas, and validate them or not, to continue to experiment.

��

Chad: I think one of the things that Rebecca talked about I want to highlight, We replaced hierarchy with network connection. Not every company can do that in terms of their culture and organizational structure, but I think there's an important bit in it.

��

As you scale, you're still trying to find signal from noise, and in a network node you can see signal. Roy always used to talk about, "Who are the five people you know as a leader, who are going to give you, basically, the word on the street?" This goes beyond innovation, but that kind of thinking allows you to say, "I may not be at 11,000 people, I may not know the person in this country who has the great idea, but hopefully I know a person who knows a person."

��

If you can create that ethos where you can start to try to see signal from maintaining connection as a leader with people in different parts of the business who also are maintaining connections and essentially trying to spot things.��

��

I feel like one of my jobs is, when I get that Google Chat message that Rebecca was talking about — people still reach out to us — how do I say, "Hey, okay, what's in there? What's actually interesting?" And then who do I connect them to, who has more expertise in that thing than I do? Somebody's talking about how to think about Istio and service mesh in this kind of context. I know enough about that to be dangerous, but I don't know enough to actually sus out what the next step is. Really, having those connections and knowing how to almost play an air traffic control to help ideas get some legs or to sus out is that a good one or a bad one? –�� that's super important.

��

Birgitta: I think it's also important what you just said with knowing a person that knows a person that knows a person, because, what you said before Rebecca, this reassuring people: "Oh, yes, you can just reach out to Chad. You can just reach out to Martin Fowler." That actually also didn't scale, right? I know people these days or even five years ago say, "Yes, you might say that, but I'm not going to do that."

��

You need people in between. And Chad, you also know this — I think you had some research done as well about social capital in ������, and that we run on social capital. This former Thoughtworker, Stephanie Grewenig, she had this great idea of turning it into a talk about how everybody has a responsibility to share their social capital, to say, "Oh, I actually know Martin. I see you have a good idea. I'm going to put you in the spotlight and forward this."

��

This sharing your social capital, sharing your privilege is super important in a networked organization like this. And then also if that actually works, that can have a huge impact on innovation.

��

Neal: I think that's a great example. If you build it, they will come. If you build an organization that really values collaboration and people who really like collaboration will come join that organization. I think that's why we end up with so many authors of open source software and books because we're known as a destination, like a bridge in that way I think. We definitely like collaborations, that's been one of the keys to our success since the early days, I think.

��

Chad: To your point, Neal, I think reevaluating what it takes to make it work at every stage. As you get bigger, the scale effects change. Saying, "Okay, what principles can we rely on and what mechanisms can we rely on to make that work as we get bigger?" It's a hard challenge every time, but I think it's one that you have to be intentional about.

��

Neal: A lot in the early days, we purposely built projects in a way that we can harvest useful utilities out of them; things like CruiseControl and Selenium and inunit and tools like that. But at some point, we decided to become more intentional about this and created ������ Studios. Can you give us a little bit of history and background about what ������ Studios was, and what was happening there?

��

Chad: Yes. I'll start, Rebecca, and I'd love to hear your thoughts too. We got to this place where we were recommending things to our clients and to the world — in terms of revolutionizing IT — and then people would look at us a little bit sideways and say, "Yes… but how do I do that for real? Good idea, but where's the underlying tool support for me to do it?" It's a lot like the initial continuous integration story that Martin talks about where everybody had read the XP book, what it says around CI and then trying to do it with tokens was hard. Then, eventually, we automated it to what Rebecca was talking about earlier.

��

How do you actually underpin all of these things that we're talking about in a real way? That was our first motivation. The second was that there were some innovation things that we thought, "Hey, if we could innovate here over here, that would be great. Can we proactively try to innovate, and not just have it bubble up from the ground?" We started Studios to address that.

��

We learned a lot along the way about how to continue to innovate in that structure. When it's top-down, what goes wrong? [chuckles] Or how do you coexist with — You may be sponsoring an idea, and there's four other ideas that are similar, that are coming from the bottoms-up, how do you deal with that stuff? I think Studios was–

��

Birgitta: Studios, Chad, just for listeners, it was like a product company for —��

��

Chad: Oh, yes, I should have explained that. [crosstalk] ������ studios was our product company within ������ that built tools largely around software development practices and the kinds of automation that Rebecca talked about earlier. How do we think about how teams build great software, and what can we do to support it?

��

Rebecca: Yes. And to the point Chad was making, how do you have a top-down intentional innovation cycle coexist in this bottoms-up, everybody's idea [culture]. I remember having many questions from people during Studios' existence: "Well, does that mean that we can't innovate anymore?" Absolutely not. We want you to continue to innovate, just because studios is over here doing this, doesn't change anything.

��

We had all kinds of open source projects that came out from the professional services side of the house while Studios was in existence because we were able to say, as I said earlier, we don't believe in an innovation center of excellence where only people over there are responsible for innovation. But a lot of what we were trying to do as well, when we thought about how we want to go about delivering software — as Chad said, the tools didn't really support it.

��

When I think of something like Go, which is one of the later Studios' products, what we're trying to do there is, we're not going to just solve the simple part of the problem. We're going to address the hard parts of the problem in all of the complexities. I think that's, again, something that is a part of our culture. We don't want to just solve the easy 50% of the problem, we want to take a look at it and say, "Okay, what are the innovations that are going to allow us to push that boundary into what we can automate?"

��

That's just the way that we've always approached problems. I think if you look back into our history, and Neal and I will often say the most important, least appreciated book from early in the 21st century is the book Refactoring Databases. That was Pramod [Sadalage], our colleague, in conjunction with Scott Ambler, taking a look at how do you actually evolve databases, because, of course, once you're in production, you have data to migrate. How can you really address all the complexities of that problem?��

��

Over and over again, that is how we try to address these is, "Okay, let's not do this the easy way. Let's actually tackle the problem." Unfortunately, when you look at something like Mingle, which is our project management solution from Studios, it was almost too flexible because people were almost bewildered about how to get started.

��

I seem to recall similar kinds of things about Go, where I just don't know how to make this work because it's so comprehensive and covers so many of these special cases. How do I just get started? [chuckles]

��

Birgitta: Studios is, also, I think a great example of what we had before about putting something explicit in the mission, because as far as I know, it was not set up to make money, right? [chuckles] It was set up to actually have a space to push the boundaries, and push them out into the market as well so that other people would start developing software in a different way, right?

��

Chad: I think we started out hoping to make money. Then, when we saw the economics of developer tools, we changed our mindset a little bit. I think missionally, yes, we wanted to make sure that Rebecca talked about those hard parts that you're a large organization trying to manage all of this infrastructure and there's complexity in that, we wanted to make that complexity better. We wanted to really encode that in all the things that we were doing.��

��

A great example, even today, as many tools in the continuous integration and continuous delivery, continuous deployment space, GoCD is probably still the best at managing dependencies, and fan-in fan-out, and how do you take like 15-

��

Rebecca: Complex pipelines.

��

Chad: Yes, complex pipelines. How do you take 15 different pipelines and make sure the version that comes out of that is a working piece of software? That's a hard problem to solve. In fact, the original algorithm that we came up with was so nuts! [chuckles] We decided like, nobody's ever going to be able to understand this. We have to redo it and make it simpler.

��

That kind attention to the edge cases, the nuances, the details was something that was really important to us, because we wanted Thoughtworkers, we wanted our clients, we wanted people who picked up the software and tried to install it in complex environments to really be able to solve those heavy use cases. I also think, one thing I want to get back to with Studios is, Rebecca was talking about managing the bottoms-up and the top-down.

��

One of the things we also seeded culturally, was that we wanted the bottoms-up ideas to come talk to studios. I remember, clear as day, being in Bangalore, sitting at, we had this really big open space with, I know people deride these days, the [chuckles] big team room with like 15 million tables, we had that. I was sitting at a table, got up for a walk, and I had just done a talk to the whole office.

��

This guy pulls me over and starts talking to me about all his ideas with continuous integration. He's super excited and he is telling me all these things and I'm like, "Okay, that's cool." Again, we talked about Conan the Deployer earlier, that person was just humble. He was talking about these ideas that became CD and him and Dave Farley worked on that. It was interesting, right? Because we had started down the road of saying, "How do we improve continuous integration tooling?" We had this CruiseControl, how do we go to the next phase of that? We weren't starting from the point of, how do we start continuous delivery? We were working on improving CruiseControl, and Jess shows up with all these ideas. Then we said, "Okay, actually that."��

��

So we wanted the bottoms-up to affect the top-down, and that's a tricky thing. [chuckles] There's no easy answer to how to make that happen. I think some of the principles that we talked about with bottoms-up are really crucial if you are doing a top-down kind of thing.

��

Neal: Well, in fact, since we're talking about so much nostalgia, when I joined ������, the company motto was "The art of heavy lifting," which is exactly this idea of, how do you lift heavy things in an elegant way. That's been baked into the ethos of the company for a long time.��

��

To prevent this from being purely just nostalgic, what are some things that our listeners can take away from this, as to foster this kind of innovation in modern companies right now?

��

Rebecca: Well, to me, one crucial aspect is this idea that there is not a designated group of people who innovate and a designated group who just do the grunt work, that everybody has the chance to get their ideas out of there. One of the things to accomplish that is to make sure that there are different ways people can contribute. This podcast is a great example of that.

��

For some people sitting down and writing an article is incredibly painful, but I haven't met a Thoughtworker yet who didn't love to talk about technology. We have our hosts who steer the conversation, and we get voices on this podcast that wouldn't necessarily be able to get their ideas out. To me, that's a big part of it, is helping ensure people understand that as an organization, we value innovative ideas. We value experiments, even when they don't go well.

��

We're going to have multiple mechanisms by which you can pursue those ideas. Some people write books, some people give conference talks, some people do podcasts, some people do videos, some people do all of the above, some people innovate directly through open source, some other people are good at doing things with our clients, but aren't necessarily good at being able to harvest that.

��

How might I apply that somewhere else? We try to get people to have conversations about, "Okay, what kinds of things have happened there?" Maybe we can harvest those ideas and advance them, because this person could come up with the idea, but really didn't know how to make anything of it.

��

Chad: I think the other thing is about leadership, and not all leaders need to be good at fostering innovation, but you need to definitely have some. I think Rebecca and I, I remember Rebecca and I sitting down in 2012 I think it was — or maybe even 2010 —�� saying, "We need to scale Roy." The two of us taking on as an accountability that what Roy did, it couldn't be just him.

��

Really saying, "Hey, I'm accountable to spot good ideas, and make sure they get fostered." Most people wouldn't list that in their corporate [chuckles] senior leader accountability, but it's part of our job. And it doesn't need to be everyone but there needs to be critical mass for your scale of leaders who can do that. It's building a muscle too, when you think about investment and you think about portfolios of investment, how do people pick things to invest on. It can't be just because somebody wrote a good business case, and there's a good ROI!

��

To Rebecca's point about what people are good at, someone might not even be good at articulating that. If you can, as a leader, say, "Hey, well, this person's not going to write a great business case, but they got something." If you can't do that then the bureaucracy of the process will mean ideas get surfaced based on who's the loudest, who has the shiniest deck — and that's not what works. It's the leaders taking accountability for spotting the diamond in the rough, for spotting the person who might sound a little bit zany at first [chuckles] but there's something in there.��

��

That's super important, and I think Rebecca and I have really worked intentionally to scale that.

��

Rebecca: I think related to what Chad was just saying as well — very often people look at the combination of the person and the idea; sometimes you do need to separate that. But sometimes you can't. We have had some things that didn't go nearly as far as they could have because, even though the potential is enormous, we didn't have the person that we could allocate to that with a vision and the passion for pushing it forward.��

��

You do have to have both. You do have to have the person who can execute the idea, but you also have to have the person with the vision of, this is why it's not a completely zany idea and here's the potential, here's the difference that it can make, the impact that it can have. And so often we end up looking for unicorns; I need the people with the zany idea, but with enough of an execution gene, that they can actually see it through. They don't always go together.

��

Having a mechanism by which you can connect the visionary with the execution engine and make that work, and see how they can collaborate to make that vision a reality. That's a big part of it. And accepting that who knows where those things are going to come from.

��

Chad: Talking about lessons we've learned from Studios, we made various iterations of that mistake many times of having the right visionary, and not the right execution, or the right execution person, and not the right visionary. Figuring out how to do that consistently is a challenge, but I think it's doable. I think it's doable: building an execution engine that knows how to, "Okay, there's some good ideas there, how do we then do the right customer development, right understanding with market research, et cetera, and then move to the next phase to build the right thing?" That's very doable, it just takes some work to get it right.

��

Neal: I think it points to one of the strengths that ������ has always had and valued, which is collaboration, and to overuse an old metaphor, all these different odd-shaped puzzle pieces, but you get the right combination of them together, and you can get them all to line up, and you can create something that's much bigger than the sum of the parts.

��

Having some wacky visionaries running around, but then having execution people also running around that, they can be tied together easily, I think is one of the keys to building an engine that enables you to keep innovating over long periods of time.

��

Chad: I think there's an interesting point there about — in diversity, equity, inclusion, we talk about safe spaces. Is it a safe space — your company — to be just an execution person? Is it a safe space to be a visionary? A lot of times, it's an either/or proposition in the company culture, when, actually, sometimes you need both.

��

If you don't make it a safe space to be a little bit off-kilter with some great ideas, and if you don't make it a safe space to be like, "You know what? I'm not an idea person, I don't need to be strategic, but I'm good at execution." If you don't make it safe to have both those personas you can run into a road where you have neither.

��

Neal: Absolutely, I think that's where a lot of companies end up, and happy that we did not end up there.��

��

That's probably a pretty good time to wrap up. [music] I'll thank again our two guests, Rebecca and Chad, and Birgitta, and all of our listeners for hanging with us for 100 episodes. I hope you enjoyed it. Hope you come back and listen to a few more. Thanks, everyone, for joining us today.

��

Rebecca: Thank you.

��

Chad: Thanks for having me.

Ashok Subramanian: Hello, everyone. I'm Ashok Subramanian. On the next episode of the ������ Technology Podcast, I will be joined by my co-host, Dr. Rebecca Parsons, and our colleague, Andrew Harmel-Law. We will be discussing architecture metrics: what they are and how you should go about measuring them. Please join us for the next episode.