A conversation with Tim Beattie, Global Head of Product of Red Hat Open Innovation Labs

“To me, [DevOps is] a collaboration philosophy. It’s an ideology that is all about breaking down silos and getting communication flows, working through an organization. Starting with dev and ops, that’s where the name came from, but really extending beyond that. It flows through the whole organization, you taking that product mindset approach to everything, continuous discovery, continuous delivery, a foundation of culture.” -Tim Beattie

In this episode of Control the Room, Tim Beattie and I dive into the value of incorporating open innovation groups in your organization to gather customer feedback, as well as the benefits of having direct access to customer feedback when these spaces are created. We discuss the importance of having consistent showcase events, or as Tim’s refers to it, a “walking of the walls,” to invite conversation and feedback between customers and project engineers on upcoming projects. Tim’s approach to gathering these event outcomes can speed up the design process and provide customers with products they truly need. We then look at the power in creating your own culture your way, and we discuss Tim’s perspective to apply the layers of development operations (DevOps) throughout your organization. Listen in to hear Tim’s belief that implementing DevOps can be the evolution and journey forward to take your organization to new levels.   

Show Highlights

[1:37] Tim’s Career Journey in Collaboration & Innovation 
[6:48] Igniting Innovation Groups within Organizations 
[10:56] Walking the Walls of Visualization  
[18:13] Create Your Own Culture That Works for Your Team  
[20:16] Tim’s Take on DevOps in “DevOps Culture & Practice”
[29:02] The Idea of Structure in Orgs & Tim’s Final Thoughts  

Tim’s LinkedIn
Red Hat Open Innovation Labs
Tim’s Book: DevOps Culture and Practice with OpenShift

About the Guest

Tim Beattie is Global Head of Product and a Senior Principal for Red Hat Open Innovation Labs. His career in product delivery spans 20 years as an agile and lead transformation coach. Tim is a continuous delivery & design thinking advocate who brings people together to build meaningful products and services whilst transitioning large corporations towards business agility. He leads Red Hat’s Open Innovation Labs Residency program, which unleashes the power of open processes and technology working together. He is also the author of the upcoming book, DevOps Culture and Practice with OpenShift. 

About Voltage Control

Voltage Control is a change agency that helps enterprises sustain innovation and teams work better together with custom-designed meetings and workshops, both in-person and virtual. Our master facilitators offer trusted guidance and custom coaching to companies who want to transform ineffective meetings, reignite stalled projects, and cut through assumptions. Based in Austin, Voltage Control designs and leads public and private workshops that range from small meetings to large conference-style gatherings.

Subscribe to Podcast

Engage Control The Room

Voltage Control on the Web
Contact Voltage Control

Full Transcript

Doug Ferguson:

Welcome to the Control the Room podcast, a series devoted to the exploration of meeting culture and uncovering cures for the common meeting. Some meetings have tight control and others are loose. To control the room means achieving outcomes while striking a balance between imposing and removing structure, asserting and distributing power, leaning in and leaning out, all in the service of having a truly magical meeting. Thanks for listening. If you’d like to join us live for a session sometime you can join our weekly Control The Room facilitation lab. It’s a free event to meet fellow facilitators and explore new techniques so you can apply the things you learn in the podcast in real time with other facilitators. Sign up today at voltagecontrol.com/facilitation-lab. If you’d like to learn more about my new book, magical meetings, you can download the magical meetings quick start guide, your free PDF reference with some of the most important pieces of advice from the book. Download a copy today at voltagecontrol.com/magical-meetings-quick-guy.

Doug Ferguson:

Today, I’m with Tim Beattie, global head of product and a senior principal for Red Hat, open innovation labs, where he unleashes the power of open processes and technology working together. He’s also the author of the book, DevOps Culture And Practice With Open Shift. Welcome to the show, Tim.

TIm Beattie:

Thanks, Doug. It’s great to be here. Thanks for having me.

Doug Ferguson:

Absolutely, looking forward to the conversation. So let’s get started with a little bit of background on how you found your way into this work around unleashing open processes and helping people collaborate.

TIm Beattie:

Yeah, I mean, it’s been a journey for me. It’s been a real evolution. I have worked the last couple of decades in the world of systems integration and project delivery, working in professional services organizations and over the years, working with many different clients, many different projects, I’ve worked with so many teams, many teams have been awesome. Some teams have been really impeded and they’re held back. About 15 years ago, I was working for a huge systems integrator and I was working on huge program of work, hundreds of people, multi-year program. And I personally felt quite a lot of frustration about the speed that we were able to deliver to customers, to end users. I felt that the whole approach to delivering software in this case, there had to be a quicker way, a better way. I mean, we were literally going year after year without delivering everything, just lots of documentation and lots of process and things that were holding teams back.

TIm Beattie:

And for me then I thought that this is just too big. I need to go and work on small stuff, small projects, small teams. Maybe I will get more of a buzz and not have so much frustration, but I moved to a boutique consultancy. I stumbled upon a number of practices that I just loved. Some of them were I learned later were Agile. I didn’t know Agile at the time, but it made a lot of sense. It was very pragmatic. There was an awful lot more talking directly to customers, releasing more often to customers ,getting feedback from customers. There was just a lot more communication and collaboration. And I loved it. I’m seeing the satisfaction all round within the teams I was working in and with the customers I was working with. It just felt like a breath of fresh air.

TIm Beattie:

And so I enjoy the next 10 years learning more about Agile and Lean and design thinking and all of these frameworks. And I started to realize this is what really ignites my passion in IT. It’s this collaboration. And then the icing on the cake was about four years ago, four and a half years ago, again, in my effort to continuously improve and adapt what I do with my career. The one sticking point I had with the kind of services I was delivering was the teams I was working with all belonged to my supply side organization. So we were project teams. Typically a project would run for six to nine months. The team are awesome because we were using all of that collaboration and there was amazing energy. But my frustration then was, well when this project runs out of funding, those people scatter in different directions and just at the point of awesomeness, the team disappears.

TIm Beattie:

And I think what a shame and I felt this was a little bit almost dishonest around agility. I felt Agile is all about long lived product teams and keeping the team together. So I got an opportunity to come and work with Red Hot. At that time I felt Red Hot techie company… I wasn’t sure if I was the right fit, but the part of Red Hat that was launching them was called Open Innovation Labs. And it was all about seeding long-lived customer product teams within the customer’s organization. The main product that I look after as the head of product for Red Open Innovation Labs, it’s called The Residency and it’s all about enabling teams to use practices to use Red Hat’s culture, which is based on open source on the technology to be a long lived team within the organization. And this felt like a great way to deliver great Agile. And that’s where I am now.

TIm Beattie:

So in the last few years, I’ve learned more and more by open organizations and open source. So I think over the last 15 years it just brought me going this evolution into where I can just work with some great practices, with some great teams and great people and create an infectious enthusiasm of energy within the teams I work with.

Doug Ferguson:

It’s interesting hearing you talk about finding that open innovation group there at Red Hat, because it also is this issue you bumped into around the short-lived nature and how this team spreads like a dandelion and then all the value evaporates, the momentum’s lost. And I had the pleasure of meeting Jim Colson from IBM who spoke at the CTO conference here in Austin and has collaborated with me on some local meetups and things. And as well as Chris Watts, who I think spent some time at Red Hat as well. And then he might be back at IBM now. And they were both telling me about the innovation approach at IBM, which I think Red Hat was doing also independently before any of the IBM stuff.

Doug Ferguson:

But it’s really fascinating because the way I understand it is that there’s a group that’s sitting in between R&D and product who is basically creating points of view and harvesting stuff from R&D and then packaging it up and then working with product to bring that to light and helping provide resources that can make these products really stand up.

Doug Ferguson:

And it really dawned on me that how powerful this is, is this notion is like the liaison group. It’s not necessarily quite a bit different than what we see in a lot of companies that create innovation groups where it’s like, “Oh, these are the people that get to go like have the fancy coffee bars and stuff,” versus enabling the rest of the org to maybe notice these things and then bring them to life within the org within the normal value stream.

TIm Beattie:

What you say reminds me of one of the really cool things I like about our open innovation labs is Red Hat has its own products. We are a software company, software product company. When our customers come into our lab space, one of the things we want to do is get them access to Red Hat, as much as Red Hat as they’re interested in. And I think when I look at our product engineers here developing our products, one of the best things we can do is put them side by side with our customers who are consuming and using their products and it’s a win-win situation. That means our customers get access to those product engineers. They start to learn about what roadmap looks like and maybe some awesome new features coming their way.

TIm Beattie:

But also it means our product engineers get access to the people who are adopting their software and often that empathy doesn’t exist in products. And this is where real innovation happens when we can have that kind of level of a feedback loops between the people who are using value, using features on the people here who are delivering that. And I’m seeing that happen more and more where we’re breaking down those silos so that we can provide that direct access and some of the conversations and the learning that happens when you can create that space in a labs environment. And it was conversation to happen is just enormously powerful and what really sets the way for great outcomes for both sides, really.

Doug Ferguson:

It also reminds me of this phenomenon where a lot of companies create these silos of research. They’ve got the UX team that’s out there doing the research and without the research happening at the team level, it’s hard for them to have that feedback loop. So it’s like if the developers are having to rely on research that someone else did, especially if it’s down the hall or in another building or another city or state or whatever. It’s a lot different than if it’s on your team and it’s like a daily or weekly conversation.

TIm Beattie:

Yeah, exactly. And I think there’s lots of different tools that can help with that. Like you say, having desktop happen in a closed room and a different part of the business park, it’s a world’s difference to an open space where we invite stakeholders or anyone who’s interested in what this team are innovating on to come in and we have a term called walk the walls. You literally walk the walls with someone and you have a good old fashioned conversation about all of the visualization on those walls, all of the information being radiated on those walls, being able to use that kind of transparent way of working that allows you to see what teams are doing, why they’re doing it, how they’re pivoting, what they’re learning, what their product increment looks like, and inviting conversation and feedback. So having that visualization and inviting those conversations is really helpful.

TIm Beattie:

Likewise, having things like regular showcase events, whether they be demos or sprint reviews or just short sessions to be able to show off something that we’re trying out because, at that point, the learning is quite minimal. It’s when we start to share the work that we’re doing and doing it in an environment we’re inviting conversation and feedback. That’s what generates great products, having other ways of getting your workout there, written showcases, project postcards, sketch note visualization. So there’re tons of tools I think that teams can use to just share with the world, show the world the greatness of that that they are trying and experimenting with and get those conversations flowing and get those feedback loops up to many different levels.

Doug Ferguson:

Yeah. It kind of echoes one of the mantras that we believe strongly on this notion that what gets visualized gets velocity. And when you talk about walking the walls, they’re seeing the visuals, they’re peering into the future a little bit.

TIm Beattie:

Yeah. Oh gosh. Yeah. I mean the number of ideas, some of the best ideas for the future come up either during a walk the wall session and the conversations, or a retrospective event where you’re just taking that time to, as a team, reflect on great stuff that we’ve done and we want to do more of, but what would make us out a little bit better and I think back to just some of the most amazing, simple ideas that have come out from just enabling that culture of conversation and collaboration and ideas to come to life.

Doug Ferguson:

So I wanted to come back to one of the things you said in your description of your background and how you got started, and you talked about systems integration and it piqued my interest because thinking about systems thinking, and I’d love to hear your thoughts on how much that background and viewing the world through that lens has impacted your thinking around collaboration and around how teams and people come together to work.

TIm Beattie:

Yeah. I mean, that has been a real evolution in my thinking throughout my career. I think back to some of the big programs of work where big systems integration projects where different system teams operated very independently in a silo. So you may be working for a telecoms company and you would have a billing team and you would have a provisioning team and you would have a customer care team and so on and maybe an integration team who were completely separate. And when we’re doing big systems development projects, these huge teams, sometimes 60, 70, 80 people in each of these teams would never really collaborate. They would each deliver their own bit of the solution. And some months later we would try and put them all together and see if they talk to each other and 99.9% of the time they didn’t because we hadn’t worked together.

TIm Beattie:

We hadn’t designed together. We hadn’t released together an integrated army together. To me at the time I was relatively junior and I didn’t think there was any other way. This is the way big systems are delivered. And that’s always painful when you try to do integration testing. Similarly, when you eventually go live, these big programs finally go into production several years later, they get handed off into a whole separate part of the organization after the operation. We’ve never met the people who are going to maintain or support or fix problems in these systems. They were all handed over through documents. And again, I didn’t know any other way. This, to me, is just a way that I think.

TIm Beattie:

Over the years, as I’ve learned more and more techniques and frameworks and seen more and more examples of great ways of working, I’ve learned about things like systems thinking, and you start to realize the impact that causal effects of not having that collaboration and when you can break down those silos and start to create a more cross-functional, horizontal team that stretches through… Almost turn the organization on its side to deliver much more frequently, you really start to see the impact of it.

TIm Beattie:

So it’s almost like I’ve come through that evolution from seeing how slow we can go by bringing down those barriers, by bringing down those silos, by speeding up that collaboration and sharing and that transparency, we can really see the impact and the effect that has in terms of the quality of releases, the frequency of releases and the time it takes to deliver new ideas to end-users.

Doug Ferguson:

Yeah, one thing that comes to mind is a common theme that we hear around, “Oh, we don’t have time for that.” Whether it’s talking to customers, bringing the team together for exploration session, where we might generate better understanding, better alignment, because they feel like they… To use your language earlier, in the pre-show chat, you were talking about outcomes versus outputs. And they’re in that output mode. And they’re just like banging out features, but they’re not… Maybe it’s the conversation around outputs versus outcomes, but what’s your go-to to help teams understand that we might have to slow down in order to speed up overall.

TIm Beattie:

Yeah. It’s funny because I think in this world of Agile and Scrum and frameworks that have become more and more popular over recent years, what we’re hearing teams talk about is velocity and story points and time to value and how many features that can deliver. And what we’ve ended up with is a world where we can deliver more features faster, but it’s still all output. It’s all about, yeah, how many features… Are those features actually being used? Are they generating outcomes to stakeholders or users or the people that matter? Or the outcomes doesn’t matter. One of the stories I love to tell is about my grandmother who lived in the north of Ireland, where I’m from. And I remember about 15 years ago, she was very frustrated with the TV remote controls.

TIm Beattie:

She had this huge remote control for a TV, and it must’ve had about 40 or 50 buttons on it. And it looked terrifying. And all she wanted to do was switched the TV on or off, turn the volume up or down and change the channel. But somehow or other there were 40 or 50 buttons on this remote control and I saw thought this is a classic example of where we’ve over-engineered on the team, just focused on churning out as many possible functions or features as they possibly can and the chances are 80, 90% of them will never be used. What I actually ended up doing was putting black tape over all of the buttons she didn’t use so she ended up with a six button remote control, which is all she needed to deliver the outcomes that mattered to her.

TIm Beattie:

And I think that’s what more and more organizations need to learn to do. They need to figure out what are the actual outcomes that are going to matter to our customers? What are the measurable impacts that we want to affect on the people using our systems and how can we work in a much more experimental approach so we could learn faster as to how we can deliver those outcomes that matter quicker through experiments. So, I used to recite that… I tee up the conversation that really, I think our approach is, let’s start with one team. Let’s not try and get hundreds of people thinking differently overnight. Let’s see if we can use some practices with one team, one application, one use case working in a different way that’s more outcome driven and let’s see if we can, first of all, create the buzz and the infectious enthusiasm within that team to work that way. But also some mind blowing metrics around the ability to deliver features to shorter lead time, or to a higher frequency of deployments or three.

TIm Beattie:

A shorter amount of time to fix issues on production platforms and things like that because I think if we can do that with one team and break down the barriers and the impediments that prevented them from doing that, then we can open the door and say, “Well, how do we get more teams working like this one? How do we create that infectious enthusiasm across the organization and scale this to more and more teams?

Doug Ferguson:

I like to refer to that as the internal case study. Often people talk about, “Oh, this worked at Google or this worked at Facebook,” or wherever or even at Red Hat and then it’s like, “Well, we’re not any of those companies and it’s so easy to explain away how we’re different and so carving out a case study.

TIm Beattie:

And we can’t expect people to copy. It’s like the number of people that want to apply the Spotify model because they hear about what Spotify did, but you’ve got to create your organization’s own culture, your own way. You’ve got to go through that evolution yourselves and this is why this is what really motivated me around our residency model, because we were really focusing on giving a team within an organization that experience. So they had that internal case study themselves, but something that they could then use as a seed to them, enable, educate, inspire others to create their own stories as well and grow those internal case studies and do a portfolio of case studies, really.

Doug Ferguson:

Yeah. The Spotify example is pretty interesting and for those of you that aren’t familiar, Spotify released a blog post saying, “Here’s how we run our product development organization,” really focused on the development and the things and how they organize people in the squads and their delivery units and then there’s a guilds and things that might be more topical or more functionally driven. But the fascinating thing about it that I think is really interesting and I’d love to hear your thoughts here is that when I talk to the folks that are at Spotify or familiar with them, they talk about how we don’t really do that anymore. We kind of evolved past that. So if you really want to apply the Spotify model, then you should be taking an experimentation approach and you should be looking inwardly at our culture and not just thinking, “Oh, devops is Jenkins or Docker,” or whatever, or continuous deployment. Sure, those are best practices, but how do we improve our culture? How do we make our people more effective? How do we focus on that developer experience?

Doug Ferguson:

And I think your book really focuses on this trinity of people, process and technology. So how do we help people collaborate together? And what’s the process users might use and borrow from, or… I think that’s really fascinating. It really gets to that ethos of focusing on the developer experience rather than saying, “Here’s this roadmap for how to automate our deployment or whatever.

TIm Beattie:

Absolutely. Yeah. And I think that the book one of the things we really tried to focus when we wrote the book was not to make it about technology. So it is a book about devOps. People think devops is a techie thing. To me, it’s a collaboration philosophy. It’s an ideology that is all about breaking down silos and getting communication flows, working through an organization, starting with dev and ops, that’s where the name came from, but really extending beyond that. I’m thinking about everyone involved in the value chain including and users, including some of the stakeholders like security and operational people. And I think to achieve great devOps requires an adaptive approach. You can’t go to the Spotify website or go to Spotify and ask for a copy of their business model and then to copy paste and say, “There we go. We are now like Spotify.”

TIm Beattie:

It’s something that needs to emerge and it’s something that will involve a lot of learning along the way. The book we’ve divided it into a number of sections. So first of all, we talk about the importance of building a foundation. And that foundation is all around culture and collaboration. I’m putting the platform in place to provide the technology because there are some great accelerators we can get from the technology, but a large focus on that is really about the people on the cultural practices that enable the people to operate with increased psychological safety, with an increased level of energy and enthusiasm and autonomy. And we talk about autonomy, mastery purpose a lot in this to create that foundation that our teams can then work on top of. And then the next part of the book talks about the importance of continuous discovery and continuous delivery.

TIm Beattie:

And this is really… And we have a section all about the different practices. Most of them are really collaboration practices that help us discover our why, why are we here? What problems are we trying to solve here? We trying to solve for and what are the target measurable outcomes we’re trying to achieve? Then we have a section about, how do you then decompose those outcomes into experiments? How do you prioritize those experiments? How can you in a very modern way of delivering software, how can we use some of the really advanced capabilities to run experiments and learn from our users really very fast? And then we have a section all about delivery, which is what are the practices and techniques that allow us to deliver in a much more iterative and incremental way?

TIm Beattie:

So those sections, the foundation, discovery, the options on the delivery, we’re not even really talking about tech at all in any of those. It’s all about the people. It’s all about the collaboration and the practices. We do then have some sections about building it, running and owning it which for the techie people, they can get their hands messy, but we also think it’s something that the last techie people will learn from. And then finally we get into sections about, well, once we’ve been around that loop of discovery and delivery, how do we continuously learn from that and how do we sustain that cultural foundation on how do we grow from it? So, yeah, a book about devops, which is at very most, one-third about technology. And I would actually say that the real focus, the really interesting part that our many tasks readers have come back to us as being the stories about collaboration and breaking down silos, which is what’s enabled great devops to take place.

Doug Ferguson:

It’s really fascinating to just watch the evolution of devops. Thinking back into the early days where operations and development were two separate units and often developers weren’t allowed to even have production access. And the ops team were the ones that were the experts in how to configure the Sun systems and the storage arrays and all this stuff which required their own programming languages. And really was the shift to commodity hardware. That was maybe the first moment that’s allowed this opening where, oh, wow, maybe we can automate. The difference between a development environment and a production system is starting to diminish, right?

TIm Beattie:

Yeah.

Doug Ferguson:

So this notion of having to have someone that’s going to be responsible for how the software runs in production versus how it gets coded is… If you think about it, looking back on it, how just like dysfunctional that is, right? You think about operations. Sure. You might want to have people that know how to keep the systems running and get alerted in security and these kinds of things, but the software only being responsible to write it, not how it is stable and runs. Wow. You’re not really… Talking about the outcomes versus outputs, right? If you’re only responsible for writing it, that is an output task versus making sure it runs and it doesn’t fall down. That’s a lot more outcome driven.

TIm Beattie:

It is and it’s funny because I think over recent years, we’ve really shifted the focus towards the end user when we’re building products, human centered design and design thinking and Lean UX. And so we know how much greater empathy on users pinpoints and how we can make their lives, their jobs that they do easier, simpler, automated. And I think devops is really the next evolution of that. We’re thinking, well, these practices work so well for creating that empathy with users. How can we create that same empathy to developers from the people that build platform on the underlying infrastructure that we’re developing on.

TIm Beattie:

How about we create the same collaboration through connections between those platform engineers on those developers, high boat. We put the developer, heart of the experience so that we are continuously learning from them and thinking about how can we remove points, and this idea of taking a product approach, a product mindset to platforms, I think is really an exciting space where we’re effectively using what’s worked really well in building products over the last decade and my thinking, well, how can we apply the same principles, the same philosophies, the same ideologies to the underlying infrastructure and that to me is what is really exciting about devops.

Doug Ferguson:

Yeah. I think in general, anytime people can imply design thinking, devops, Lean, Agile, any of this more modern approaches to collaboration and the way we work, if we can point that stuff inward to our teams and redirect it to different audiences, that’s when we find real nascent opportunities that aren’t necessarily the stuff you’re going to read about in a book. You were talking earlier about these discovery moments, where we find out something that’s unique about ourselves. And I think, whether it’s developer experience or employee experience or the platform team experience, or like the more we can get curious about what others are going through and how we can best create ease in their experience, I think we all will appreciate the job more and the work becomes more fluid. We can hit flow states more easily.

TIm Beattie:

Absolutely. Yeah. And it flows through the whole organization, you taking that product mindset approach to everything, continuous discovery, continuous delivery, a foundation of culture, I think. Dev teams, platform teams, even leadership. I think that this mindset of evolution and inspecting adapt, probing and sensing and responding based on change. We’re in a world where change is happening all the time. So at every level of an organization, whether it’s an application, whether it’s an underlying platform or whether it’s a leadership strategy, having a system of work, a way of thinking that allows us to pivot and adapt when we get feedback or when we get learning, or when we get measures that are telling us, that’s the next best thing to do, I think it’s really very important. And that’s been particularly true in the last 18 months in the world of our pandemic, I think.

Doug Ferguson:

What are your thoughts on structure? Specifically I think about Conway’s law and how our org charts can sometimes limit our ability to create or even develop software systems that can be resilient or can be compatible to this way of thinking. Right. There’s lots of folks that are managing legacy systems that it makes it very difficult to do iterative development on. Whereas you’ve got folks that are building from scratch and it’s like, it’s really easy to add continuous deployment if you’re starting from nothing. You just start with it, right. I often coach people when they’re founders and young CTOs and stuff when they ask me about this stuff. I’m like, “Put it in place, but don’t overcomplicate it.” Even just using Docker, but not trying to automate everything means that you already are on that foundation. So you don’t have to rip everything out and re add it later. But the point is, love to hear your thoughts just on structure in general, structure of the organization, structure on the software. How is that impacting people’s abilities to lean into this way of thinking, this way of working?

TIm Beattie:

Yeah. We talked earlier a little bit about that thing, that first team, and not internal case study and not… In some ways that’s easy, but like you say, is that click clearing the path for that one team to work in a new way is inspiring and can be easy. But when you want to apply that kind of philosophy to the wider org, you very quickly run into challenges around the way the org is structured. You mentioned Conway’s law and that the cognitive load that hits people whenever we’re having to deal with many different parts of the organization, switch contexts many, many times. That’s what really slows us down. A great book book, I don’t know if you’ve read it… Tim’s Apologies, by Manual Page and Matthew Skeleton, who we’ve been working with recently, and this idea of stream aligned teams around the product and the business value and having that cross functionality and the platform teams, giving a platform that enables developers to do their job much better and to allow them to focus on delivering the value in their streamlined teams.

TIm Beattie:

And then the enabling teams, coming along with this the function I see as what we often do. So I think it’s an evolution. It’s a journey. I don’t think it’s one of these things that we do as operating model, refresh and suddenly just install a whole new… Something that has to evolve with time as we grow on spreads, the culture and the ways of working and the practices more towards those streamlined teams of cross-functional product teams. And I think, finding ways to measure the cognitive loads within teams, finding ways to see where that almost damage has been caused. That’s what’s slowing us down, having these handovers, having these silos, having these systems in place where in order to get something done and you’re having to raise tickets on teams and you’re having wait times and delays all over the place.

TIm Beattie:

I think being able to visualize those identifies where the bottlenecks are within org structures and that can almost start to create a case for change and a prioritization for changing some of the org structure so that we can break those bottlenecks apart.

Doug Ferguson:

Great thoughts. And I really appreciate all of that. And I had to recognize that we’re quickly running out of time, and I know that we could easily geek out on this stuff for hours.

TIm Beattie:

We could, yeah.

Doug Ferguson:

… Taps into my years of CTO background. And so I don’t always get to talk about devops with folks, but want to just make sure to give you time to leave our listeners with a final thought. So where can they find the book? How can they learn more, et cetera? Maybe just moment to share.

TIm Beattie:

Yeah, sure. So I’d love to collaborate with anyone who wants to continue this conversation. The book it’s called DevOps Culture and Practice With OpenShift, which is all about delivering continuous business value through people, process and technology. It’s a book I wrote with Mike Hepburn, Noel O’Connor, Donal Spring. And it was illustrated by Alaria Doria. We’re really excited about this. It’s a huge book. It’s like a travel guide that you might… You can dip into different parts if you’re interested in culture or discovery or a tech. There’s something for everyone in there, but it’s also something relevant for everyone. So it’s available on Amazon. So you can buy either the hard copy or the Kindle version on Amazon. You’ll also be able to download it from Red Hat, so if you Google Red Hat, DevOps Culture and Practice with OpenShift, it will take you to our page where you’ll be able to get a PDF copy of it. I love feedback. We said, devops and everything we’re talking about is a never done state. It’s always evolving. It’s always adopting. So yeah, we’d love to hear feedback.

TIm Beattie:

My Twitter handle is TDBeattie. So T-D-B-E-A-T-T-I-E. Feel free to get in touch with me on Twitter. I’m also on LinkedIn and would love to hear any thoughts or ideas people have got about anything that I’ve written or have said about.

Doug Ferguson:

Awesome. Definitely check out the book you all and look up to him on Twitter. I’m sure you’ll be hitting the speaker circuit and getting the book out there. So I’m sure there’ll be lots of opportunity to hear more about your philosophies on devops, et cetera. It’s really great. I love that this book’s out there and it’s been a pleasure chatting today, Tim. Thanks for joining.

TIm Beattie:

Yeah. Thank you so much for having me. It’s been a great chat.

Doug Ferguson:

Thanks for joining me for another episode of Control the Room. Don’t forget to subscribe or receive updates when new episodes are released. And if you want more, head over to our blog, where I post weekly articles and resources about working better together. Voltagecontrol.com.