Episode 82: DevOps World 2020 Preview - Chad Wathington of ThoughtWorks on Digital Transformation

Brian Dawson: Hello. This is Brian Dawson with DevOps Radio. We have another episode with another exciting guest, Chad Wathington. 

Chad Wathington: Hello, Brian, how ya doing?

Brian Dawson: I'm doing great, doing great. I'm glad to have you now. Before we fully introduce you and dig in, I wanted to take a moment to talk about how we bring DevOps Radio to bear and ensure that we take a moment to thank CloudBees and their sponsorship of this program. While CloudBees sponsors it, hopefully you find that we always do our best to remain impartial and deliver information that helps our software practitioners and leaders out there deliver software better. 

So Chad, as we get ready to jump in, I'll first do an introduction that won't do you justice and then I'll let you pick up from there. So Chad Wathington is with us, coming from ThoughtWorks where he serves in the role of chief strategy officer; and this is a very different guest. I mean we have leaders on. Usually we don't have leadership in a chief strategy officer role. But make no mistake, I think that title can be very misleading as you'll find as we start to unwrap Chad's experience. But Chad, before I run you through one of my new exercises I told you about, can you tell us a little more about yourself and what you do with ThoughtWorks?

Chad Wathington: Yeah, sure. As you said, I'm chief strategy officer, which means in the ThoughtWorks context I look after kind of our forward-looking how we think about our service offerings, how we go to market, mergers and acquisitions, partnerships, a lot of stuff that's traditional chief strategy officer responsibilities. I've been with ThoughtWorks for 16 years.

Started out in professional services and I'll explain what ThoughtWorks does in a second, but I started out in professional services. Then we started a product division which was called ThoughtWorks Studios or ThoughtWorks Products, and we built Mingle which was the first electronic card wall. We built GoCD. We built Gauge which are still open source products right now. I did that for about ten years, so I learned a lot about methodology and software practice and building tools to support what we knew people would be doing in the future. And then about four years ago took a role to help sort of the larger ThoughtWorks drive forward with what we're trying to do with clients, and a lot of our clients are companies trying to make this digital transformation thing real. Instead of talking about digital and the quotes, we really help people with the technology end of it and the people end of it and the process end of it, really make that transition real. 

Brian Dawson: Awesome. And do you still have a foot in the technical realm, the technical foundation? I mean obviously you're helping with digital transformation. Are you still getting your hands dirty at times? 

Chad Wathington: Yes, I do. On my own time I still code. I still teach my kids how to code. They're heavy into Scratch right now so I've been debugging Scratch code. But they took a Python class over the summer. So I was helping them debug their code. Yeah, so I still code but it's nothing in production now. Now it's for fun for me to understand what's going on, yeah.

Brian Dawson: Nice. I appreciate that. My dad was somebody that – my dad was an engineer, went into computer engineering and had told me even as you move into leadership or management, always leave some time to code and engage at a technical level. It not only helps keep your chops fresh, according to him, but keeps you connected to what's going on. I assume that that's some of the logic driving you there?

Chad Wathington: Yeah. And in my role, you can't understand what's really happening prospectively if you don't have some grounding in it. So let's take a few years back when the Docker explosion hit the world, 2014 timeframe, 2013 timeframe. Well, if you're in a role like mine and you don't understand what containers actually are, then what are you talking about? So, right? So then you just go stand up your own containers, orchestrate them, and get enough of a flavor so that you can speak intelligently about why and how do you talk to senior leaders about it if you don't understand it? So for me it's very much – and in ThoughtWorks we have this concept of a leadership journey where we talk about our journey. For me, being broad but being able to understand different technologies and wade into them is a really important part of doing the role well. 

Brian Dawson: I can appreciate that. So now I want to dig into ThoughtWorks, but before I do, let's dig a little more into Chad. So I've checked out your Twitter. Really appreciate some of the content there as well as other content that you've produced. For listeners Chad's Twitter is @twchad, C-H-A-D. And I want to pick into some things there in your profile. Your profile reads Christian, Tech Zealot, Gadget lover, Product Manager by trade, Chief Strategy Officer by title, Father, and Attachment Parenter, @thoughtworks. Tweets are my own. So there's a lot there. 

Chad Wathington: Yes. 

Brian Dawson: I'm gonna put you on the spot and I'm gonna unwrap a couple of things. So we sort of hit chief strategy officer by title. 

Chad Wathington: Yes.

Brian Dawson: We touched a bit on father. But now, to go back, product manager by trade. Can you tell me a little bit more about that?

Chad Wathington: So when I graduated from college, it was during the first dotcom boom; and I got the opportunity to, as I often say, do a role that I wasn't qualified for; but it was you could get a job doing a lot of things. 

Brian Dawson: It was the beauty of the boom, right?

Chad Wathington: Yes, yes. So I was a product manager at a company called ShopTalk which was early in doing speech rec. So Tellme, VoiceXML, over the phone. So we were building speech applications, and so I had a kind of bootcamp crash course in doing product management. And when we started the product division at ThoughtWorks I was head of product and built the project management team, and then I was managing director of the product organization. So I spent the bulk of my career really and, you know, building great products. So I think I'm always a product manager in my heart even if I'm doing something different and product is something that I have spoken about a fair amount and something that I think is one of those professions that is somewhat ill defined to its detriment and something that the industry could do a lot better about talking about what really works and what really doesn't work. 

Brian Dawson: Yeah, agreed, agreed. What I am starting to see that is encouraging is shared services leaders, devops leaders, transformation leaders starting to adopt the product manager title and a product management view on things. I do want to ask though now to tie things together, are you a product manager at home? You're a father and a project manager, product manager by trade. 

Chad Wathington: What I would say to young product managers is that if people realize that you have a talent for prioritizing in your day-to-day life, then you know you're a good product manager. So I would say that I am, you know, people ask me prioritize in life and I would say that I try to work on that before I think we think about product management as often people talk about scrum product owner and things like that about this active prioritizing, but it's not that. It's really having business context and technology context or bringing them together and then working through a lot of things that you see in Marty Cagan's work to drive what's really doable with what we have. And so that prioritization doesn't exist on its own. It exists in that business and tech context. 

Brian Dawson: Okay. And it sounds like it would help with your father and attachment parent as well. 

Chad Wathington: Yes, it does. It does. It does. 

Brian Dawson: So to the jump, let's dig into the matter at hand here, ThoughtWorks. I worry, though I'm not sure that a number of our younger listeners may not know who ThoughtWorks is and the impact that ThoughtWorks has had on software development as we know it today. And you've been there for most of that journey. So I'd be curious, can you, you know, tell us a bit more about what ThoughtWorks does and anything that you have about, you know, the history and your role on that journey?

Chad Wathington: Sure. So ThoughtWorks is a technology consultancy. So we help people, we help organizations build tech, and that's the sort of fundamental start point. It was started about 26 years ago when our founder was building a leasing application for one of his clients. He was in leasing the domain area, and we had to build this very complicated application. That history of building complex applications led to us starting to do project rescue in the early days. So someone would mess up on an application, ThoughtWorks would come in and help solve fixing it. 

Brian Dawson: I didn't know that, okay. 

Chad Wathington: Yeah, that was our really early bread-and-butter. And because of that, the initial folks were really interested in software practices, like what's a better way of working. And there's a sort of seminal project called Atlas. Some people have written about where Martin Fowler and, gosh, I had a little moment for a sec. Martin Fowler and Ward Cunningham were both on that project – Ward Cunningham, if the younger viewers don't know, is the creator of the Wiki – were on the project as consultants. That was where we learned actual software development techniques, largely grounded in sort of XP type thinking in 1999. And so we started doing the advance software practices to help solve these complex projects when stuff wasn't working. We'd come in. We'd have a pretty wide agreement to solve the problem where maybe the client was like "Extreme programming? That sounds like it might be dangerous."

Brian Dawson: Extreme.

Chad Wathington: Right. That might be dangerous. So I think we then created an ethos around thinking about how to build software well. So a lot of our thought leadership and a lot of the folks who've worked at ThoughtWorks have come out of that culture where we think about how to revolutionize tech, how to think about what is excellent software, how to then evangelize that. So from things like patterns of enterprise applications which led to the conversation on MVC or things now that are, you know, infrastructures, code, and microservices. A lot of these things the person who's sort of known for them was a ThoughtWorker or is a ThoughtWorker and those things come from us thinking about how to make software better. 

Brian Dawson: Well, and to jump in real quick – so I want you to continue but I also didn't set the stage because there's a lot of people that are going to know who Jez is and Jez Humble is, think the Continuous Delivery but basically the bible of continuous delivery which is the foundation for so much we do; Martin Fowler, which you can just spend a whole night or a couple of days on Martin Fowler's blog and you'll be that much a richer software practitioner or leader; David Farley, right, and on and on and on. Before I hand it back to you, so just to give that to the listeners, what is it about ThoughtWorks? How did ThoughtWorks either attract these people or help foster and encourage all this innovation that came out?

Chad Wathington: So, I think ThoughtWorks culturally does a few things. One is scan the landscape a lot and there's a technology radar that comes out on a quarterly basis that is a way that we do that. But folks internally are always scanning. Because we have, you know there's about 7500 ThoughtWorkers globally, we have a lot of projects and a lot of software that we're building. So the internal culture around sharing those experiences and learning from them I think is a really important piece. Like when people leave they miss that ability to check in with the hive mind about how things work. I think folks like Martin and Jez and a lot of folks that have come out of ThoughtWorks, Sam Newman, are great also at sharing their platform with people who have interesting ideas and encouraging folks to get those ideas out there. And so I think you take all of that together and we are – and then a missional purpose to revolutionize the tech industry as part of our purpose of existence, and then you put all that together and I think it's a place where people like to come if they have those aspirations but also where people just had a good idea collectively and then we surfaced that and we make sure that other people can consume that. So the story around continuous delivery, and again others have written about this, was that there was a project in the UK that didn't go so well when we had a deployment and that team in the retrospective said, "What can we do to bring the pain of this forward?" and they created this little tool called Conan the Deployer and they started deploying early and often. And then they wrote a paper together on build-pipelines and that was the beginning, right? So I think we created a general way of working that highlights that. 

Brian Dawson: Awesome, awesome. So there are many places to go here. I'm gonna want to talk about ThoughtWorks culture a little more, but first I wanted to call out what should be recognized as a notable moment in the history of software development and that is it recently was or is the tenth anniversary of the Continuous Delivery book that we discussed, right? Any comments on that?

Chad Wathington: Yeah, so I think it is obviously transformational. We built what became GoCD before the book. And Jez –

Brian Dawson: I didn't know that. 

Chad Wathington: Yeah, Jez was a product manager in our studios group and we had – this is before sort of Lean Enterprise and Lean Startup and customer development becoming popular methodologies on the product side. We had built our product because we knew a lot of our clients were struggling with things like parallelized builds and dependencies across builds. We were trying to speed up build times, and we also had this idea of this build pipeline. So we built this product, and we launched it, and we went around talking to customers and clients, and no one understood what we were talking about and –

Brian Dawson: Right. Our build pipeline is a guy, is our build and release engineer or girl that we just hand our code over to and then make stuff happen, right?

Chad Wathington: Right. They do a merge. It takes days. It fails often. That was the environment that we released the product under. Dave Farley and Jez had been thinking about writing a book from the moment I met Jez. So when the book came out, it actually gave us the foundation to talk about all the things that continuous delivery really meant not just saying, okay, there's some build pipelines and deployment pipelines and you should implement them and people looking at us scratching their heads like "A deployment pipeline? Why would I want to do that?" It's like, "Well, Greek heroes" and you know, we were dropping all this stuff, Netflix and Flickr, tying in. So it gave us the intellectual underpinning for people to really understand what we were talking about. I think it really changed the conversation. I think there's still some parts of the conversation that are still ongoing, you know, ten years later. But it was a watershed thing I think for what we now know are some of the best ways to build software. 

Brian Dawson: This is phenomenal to hear. This is a treat. I didn't know I was going to hear this coming in. Take an opportunity to thank the team, right? Thank ThoughtWorks, thank yourself, Jez, the environment, the customers where you guys trialed some of this stuff for what it's sort of given us today, right? The industry but not just the industry, right, the economic impact of it but what it's empowered for organizations, businesses, and practitioners. Now one of the things – I hate to say I could sometimes be cynical, but I'm listening to some of the pushback and I'm kind of thinking, yeah, a lot of people are still asking those questions today. 

Chad Wathington: Yes.

Brian Dawson: We're kind of going, look, it's obvious. As I said, read the book or read some papers or think about it. It doesn't have to be dogmatic but read this to kind of give you a foundation. People are still struggling. One of the things when we talk about an ideal CI pipeline, you know, which then by extension, and ideal CD pipeline which then extends itself to how we deploy is this, what for some enterprises would call a radical concept of mainline-based, trunk-based development. 

Chad Wathington: Yes.

Brian Dawson: And you have some thoughts on that you'd share with us?

Chad Wathington: Yeah, it's, again, one of these long-running things. I remember my first project at ThoughtWorks in 2004. We were looking at Perforce's document about the old what – I think it's by Steven Vance – that has, you know, mainline and defining all the branching concepts. And we've known certain things since then, that working in small batches, that integrating on a continuous basis actually improves team productivity, it removes that need for lots of code reviews. It does all these great things. Many of those things are proven empirically in the Accelerate book. But we've known those things for many years. I think because of perceptions on the best way for teams to work in a context, those are really hard things for people to adopt. It feels like if I'm a developer and I'm sitting in my team context and I have a feature that I'm supposed to be working on, I don't want to be merging that constantly and expose that. But it's actually, you know, we have the tools for it. We have feature flags, Branch by Abstraction. We have the ways of working that can make it work. It's just that I think the conversation, yes, just spins, yeah. It spins. People are not allowed in a way to explore it. Then we have things like Gitflow and GitHub flow which I think are great for open source projects. But we know that small branches are better, you know, no branches, small branches, and then long-lived branches in that order; but yet people still argue about these things. It is mind boggling. 

Brian Dawson: Again, you know, a moment to fork on that as it's interesting and I was spinning the conversation spins; but I also encountered in my time as a consultant that there was psychological resistance and it was driven by a number of things. You know, it was largely couched in fear and uncertainty and general resistance to change; but one particular thing that always caught me is that oftentimes in this space, as developers, practitioners, technologists – and push back at any time. I want to test this theory and see if you experienced it. We value knowledge so much; and we often suffer from imposter syndrome; and that tends to translate to a not immaterial resistance to go, "No, my code is never good enough to push back in with everybody else, to have everybody see what I've written." And I can explore that different ways, but had you see or do you believe –

Chad Wathington: Yes. I think that's part of it. I think the other practices that reinforce it, right, that reinforce the feedback loops to make it not scary all come along, right? So test driven development, pairing, unit testing as distinct from test driven development. All these things allow you – refactoring – to make small changes and to be sitting with someone with a lower almost psychological barrier. But if you've implemented piecemeal things and you don't establish the team cadence where that kind of way of working feels good, that's really hard, right? And there's a thread – oh, I forget. Gosh, I was just remembering it the other day. I forget her name. She posted it I think in 2018 about Agile practices and sort of that some of them haven't caught on given the signers of the manifesto. What was really interesting in that thread – go back and look at it – the ThoughtWorkers or the former ThoughtWorkers on that thread are like, "Hey, we don't experience that phenomena. We haven't experienced pairing dynamics in that same way. I think it's again because of the full – you have to do the full thing. You have to understand the full culture and behavior set for it to work. And I think when you adopt a beast, it does feel like, aw, man –

Brian Dawson: It's scary. 

Chad Wathington: Yeah. 

Brian Dawson: I'm excited. So I got to slow down a bit here, but yeah, there is the – look, even for me, look, I'm comfortable, just give me my cube. I'd often wait till, you know, my coworkers were home at night, put on headphones, hunker down, knock some stuff out. I would crawl under my desk and wake up when everybody came back, but my productive time was when I was alone. So this idea – and I'll admit, I'm here. I kind of was not actively developing day-to-day professionally to the extent that I had to practice port pair program, and I get it now, but I was kind of like I don't want to sit next to a person and code while they watch me figure stuff out. So what I'm hearing is – and there's often the term DevOps Trinity, people and culture, process and practice, tools and technology. And I'm hearing that you're saying you need to implement all of them simultaneously or some of each of them simultaneously or this resistance is more likely to occur. 

Chad Wathington: Yes. And what I think is you can drop the things ultimately, right? It's not dogmatic, but you have to have enough of the fluency to understand the feedback loop to then understand the tweaks to drop things and move beyond doing all the things simultaneously. So it's a little counterintuitive, right? You can get to a stage where you don't need to do all those things; but to understand it, first you have to try it. 

Brian Dawson: Sort of the chicken and egg. That is really, really interesting. What I would like to ask, Chad, is as we talk about that. Do you have any examples from your time spent with multiple organizations, resisting the convention, I guess, or going against the convention to help him do better and implement things like continuous delivery, continuous deployment, trunk-based development, pair programming. Any quick, actionable tips for our listener to help bring forth that change for their clients within their organizations?

Chad Wathington: Yeah. One of the things that I think is generally a good pattern in the space of changing software practices is to find a place to try it. It doesn't have to be on your team in the context of your things right today; but if you have an adjacent team or subsection of your team or something that you can do where, hey, you know what, we're going to right a bootstrap loop that just does this one little simple deployment, we're going to try this very simple thing. I think when you can create feedback loops that show positive results, you get a little bit more room and a little bit more room and a little bit more room. And so what I think often happens is there's obviously a dichotomy of me saying, well, the practices are reinforcing so you kind of got to do them all; but with people's resistance to change, no one adopts a bunch of things wholesale. So I think it's about trying to understand where you don't have the right feedback loop in place, compensating and then trying to do a little bit more, a little bit more. And people will make adjustments once they realize, oh, that's how that works. Okay, cool. We can deploy to a test environment and now we can stand up to the environment and all of that works well, okay. Is there a way to move beyond having a static-free test environment because that gets ugly? Or ooh, man, we're just running a lot of test automation against these set of machines over here and you look at the AWS bill and you go, wow, is there a different way to do that? Right? So it's like these additive little ways help people go through the change journey. 

Brian Dawson: Well, so wait, wait, wait here. I keep hearing you say feedback loop. Now, I've, you know, I've read a couple of vendor whitepapers. I've been to a bunch of talks and no one's telling me about feedback loops. I understand agile to develop iteratively. 

Chad Wathington: Aha.

Brian Dawson: CD is so you can get stuff out the door faster. DevOps is so dev and ops can work together. I maybe heard about feedback loops years ago when we were talking about agile, but what's this feedback loop stuff you're talking about? Where is it? Why is it important? 

Chad Wathington: So if you think about original experience and go back and read the book or if you think about Lean process improvement or continuous improvement in general, what you're really trying to do is establish I make a change, I see the result of that change, and I have a fast way to see those results and adjust, right? So let's take a product manager hat. I did a talk at NASSCOM – It's like on YouTube, it's embarrassing – that's like from 2010 where we had people make pets. It was like a big game, 150 people. The idea was that they made pets. We had fake customers where we had created a market telling each customer, "This is your profile. Now, go around. The teams are going to make pets. Customers, go around and really buy stuff. Here's your fake money." And they walked around the room. The team said, "Here's my pet." And then people bought it, like, nah, I don't like that, and they went to the next table. And what the point of that session was to show that you could use agile software development techniques as a product manager to move quickly, to change, to say, ooh, customers don't like that. When customers tell you they don't like that, that's a feedback loop, right? So when we're optimizing all along the path, right, from does this work in production to does it actually help solve the user problem, do customers like it, are they willing to pay for it? All of that is, you know, a feedback loop. When cloud formation fails, that's a feedback loop. When we can minimize the distance from people who need to understand the feedback itself to the actual event, then that's where real speed comes. That's where real customer value comes. And I think if you look at, again, XP, what Ken Beck was really saying is, hey, let's remove a lot of the things in the way. I can pair with the business owner. That's a great feedback loop. And I remember my first week at ThoughtWorks when I was questioning a lot of the agile practices. Had a guy who lives in Chicago – his name is Bill Caputo, old school agilest – tell me, like, he drew all the feedback loops on a whiteboard. And he said, "Look at all these. Like you pair so that the team has a feedback loop about, you know, the quality of the code. At the standup, the standup process is a feedback loop about what's working, right? So all of these things are really about optimizing the continuous improvement cycle so that we learn fast. And I think what DevOps has done which is really great is say there's a way for developers and ops people to get fast feedback about what's working and ultimately that helps our end customers, the end users. That there's a cultural way that makes things better for our profession and our craft and not like having to get up and have the pager but also that enables a set of product people to be like, "You know what, that's not working. Let's change. Let's do this."

Brian Dawson: Yeah. And so thank you for that. I think that's important. I do feel like we have lost some of that intent. That the speed, while it may be cyclical, it's not there just for the sake of speed. Right?

Chad Wathington: No.

Brian Dawson: We're not getting to market faster just to get to market faster. We're getting to market faster so we can learn quicker. And I worry that sometimes people aren't – they've gotten so focused on getting out the door that people aren't building that larger, at least that macro, outside feedback loop to be better, right?

Chad Wathington: Right. And when you talk about culture, right, across a lot of things building feedback loops are the way you improve. And you look at the, you know, obviously a lot of the things that came out of the Toyota Lean, what became Lean. 

Brian Dawson: Production.

Chad Wathington: Yeah, total production system and what became Lean and it's really about optimizing that. And so when we don't move fast to learn but move fast to execute, then you're assuming you're right. It's good to assume that you might be wrong and that you can benefit from that. Back to the exercise we ran at the product conclave, the team that won was a team that had the best idea from jump. They just got the brief. They understood what pet to make. It didn't bite. It wasn't that cheap. It was right down the line of what the brief said. The teams that came in second and third though started off pretty poorly but they realized they could learn, right? And so then they caught up, right? So yeah, you may have a brilliant idea and your brilliant idea may help you win in a marketplace; but you might be wrong; and if you don't build the feedback loops, you'll never know. 

Brian Dawson: Or the marketplace may shift. The technology, you know, at a practitioner level, architecture level, technology is going to shift. The one thing that is constant is change, right?

Chad Wathington: Yes, yes. 

Brian Dawson: And we've seen disruption which actually takes us in another direction, right? We are in the midst of unique times, right? Unique times in the sense that both we have the pandemic, we have what I'd say is a level of political division in the country, and then we're quarantined, we're working remote. Meanwhile, the cloud's coming on, technology is changing. And atop of that, what has been a historically grossly under-diversified industry, unfortunately, right, within tech, we also have a real recognition and an awakening around racial injustice, racism represented now by George Floyd and the Black Lives Matter movement. I'm curious on your thoughts, right, either personally, right, what has this disruption meant to you and how have you responded to it but then also, as someone that has to look forward at the landscape and we talk about change, what has this disruption meant for organizations in the industry?

Chad Wathington: Yeah. I think one of the things that's really grounding for me is that I think the tech industry is changing. I, you know, have been in this industry for 20 years and one of the things that strikes me a lot when we talk about social change and movements and, you know, strife in general in society, you know, you're gonna look at the lens of class on the pandemic, let's say, is that we're in an industry where people are often intellectuals and like knowledge but there's a distinct lack of historical understanding of many of these things. Like you have arguments with people and lack any understanding what actually happened. And in my generation, we were taught a very McDonald's Happy Meal version of the Civil Rights Movement, slavery, many things where as an adult you're like, whoa, that's what really happened? Wow. And there's a deeply ahistorical event and many western education systems, not just the US but there's a deeply ahistorical lang. So when you're in the tech world, you have these esoteric conversations about, you know, diversity of thought and these kinds of things and you're like, but man, that's deeply ahistorical. Like you're not taking into account that, oh, you know, why don't people pull themselves up by the bootstraps and it's like, you don't think people have tried? And actually if you – an example I love to give is Gangs in New York, the movie. Everyone loves how raw the movie is and loves the story. It's like that actually is true. The gangs of New York were like that. And you know how New York solved that? It gave people jobs. It didn't say, "Oh, well, those base gangs, they just don't know how to pull themselves up by the bootstraps." They said, "Actually, man, these people are a wrecking shop. So let's actually –" and so why we have so many Irish police officers because of a decision to say, hey, let's actually fix this. And when it comes to a lot of issues in the US, we lack a lot of that substance to say, ooh, okay, wow. You know, I always recommend for people to read Michelle Alexander's book, The New Jim Crow. It tears down a lot of essentialist arguments about, oh well, there's increased criminality in the Black community and you're like, well, there is but it's not commensurate with the arrests or the – there's so many in there. 

Brian Dawson: And even, and I'm going to give the floor back to you, but that's one that's been a lot of discussion. But right, even when there's some truth in the statistic or the data, right, if we consider ourselves scientists, right, you gotta look at what's underneath the data, right? And that's where New Jim Crow starts to play in. 

Chad Wathington: Right, right. 

Brian Dawson: Yeah, it's interesting. Over and back to you though. Sorry.

Chad Wathington: So I think there is a change afoot, and I think there a lot of voices that are saying, hey, in the tech industry we have to do better, not only because we need to do better internally within the industry, but we're building the very core of society in lots of ways, right? Tech intersects with everything. And so if we don't do better, if we don't understand ethical uses of technology, if we don't understand algorithmic bias, if we don't understand data and privacy, if we don't understand access, if we don't do these things, if we don't design interfaces with accessibility despite the fact that that's a conversation for 30 years, if we don't improve these things, that's not okay. And I think that is starting to germinate in the industry. 

Brian Dawson: Okay. And I want to dig into the ethics as well as the future. And I think you gave me a place to dig into on both. At some point we would like people to change their framing. I think part of what's really powerful about the movement, that also correlates to going into organizations and talking about a build pipeline and they go, what is that right now there's a certain foundation and framing through which they've experienced the current context.

Chad Wathington: Correct.

Brian Dawson: Right? And we now have that framing being shaken up and hopefully we get to a point where people get a fuller breadth, a fuller understanding. But I think it's going to be a bit to get there, right? And so you know, I'd say at some point here, look, even if the business, even if the justification for diversity and diversification of your workforce and getting diverse input in your feedback loops so you can solve problems better is a business motivation to start because you don't get it. There's enough of a business motivation, would you say?

Chad Wathington: Yes. Yes. And so we've been talking a lot about ethical tech and there are, you know, the business motivation. There's a huge downside, right, where people notice algorithmic bias and it becomes a big story. We talked about how we had our webinar on ethical tech last week? We talked about employees. We did some research, I think it was in 2018 on Gen Z and Gen Z wants their employers to care more about their effect on society whether that be climate, et cetera, et cetera. And so you are seeing people go, wait a second, do I want to be a part of that, right? There are a lot of downsides. There are also upsides, right? If you, as a you know, set of actors building some tech or a company organization can say, hey, we're not on some tech utopian, tech's going to solve all the problems but we are building things that are at the fabric of how people, you know, buy their food, work, interact with their schools and their friends. Like what can we do in this moment to build this in a way that takes into context the constituencies we're building for, that takes into context the effects of bad choices and to involve because it's hard. It's like threat modeling and security. It's hard to systematize all the things. So you need to involve the right people. You need to create the cultural ethos to have that understanding. And I think, again, we're getting there. The conversation is happening, but I think it's going to take quite a bit. 

Brian Dawson: Yeah. I think if we can get everybody starting to row in the same direction, right, understand that with the limits of people's base understanding that hopefully most of us enter this with good intent. And yeah, so let's start with a business motivation. I think it's clear, right? I think as practitioners we like to deliver stuff that matter and solve real problems which means we have to have a full view of the problem and who our users are. I also contend and curious on your thoughts before we shift that this is also the new economy, right, especially, I mean globally absolutely. And then when we look at North America, right, where we live, this is where income, wages and salary are being generated. And I think we're in for a rude awakening if we find that we don't make this inclusive of everybody in society. 

Chad Wathington: Yes. And I also think that, you know, there's been tons of ink spilt around automation and artificial intelligence. We have to think holistically about not just there's some business problem, let's make some technology to solve it. It's like, well, is this the right technology to make at the right time to solve the right problem and how does that affect how humans work with machines, how people get paid, how – it doesn't mean that we should not solve our immediate customer issues but we got to think about the downside effects of these things. We gotta really understand if our choices today could have a downside, that we've done our best to mitigate or to at least look at the different angles. And I think employment, I think access. We talked in the webinar about the digital divide. If people, you know, the future of work involves tech and people don't have access to tech, that's one set of problems. If the future of work involves tech and people are consumers of tech and not builders of tech, that's another set of problems. 

Brian Dawson: Right. Well, spoken like a true economist which is when we talk about sort of the intersection of society and understanding how we diversify the industry. You came here through a pretty unique path. I'd like to talk about it for a bit. So first for the people that don't understand, Chad actually has a BA in economics from Harvard University, traveled the path as you said of being a product owner. You've always, it sounds like you've been a coder. And you've arrived where you spent 16 years in a transformational organization, and you hold the role as chief strategy officer. Obviously somebody that has found their place, right, and is really bringing value in that role. But where did it start? How did you find computer science? How did you choose to take this path and how'd you end up, how'd you end up taking a waypoint through an economics degree?

Chad Wathington: Yeah, so it's funny. When I started, my school had Commodore 64s, and I started, I wrote my first basic program when I was six years old. I had a lot of opportunities along the way. So when I think about my own privilege, I grew up in a town that, you know, really thought about how they could drive different types of education. Like we had a computer lab in 1984, whatever it was. And so I was able to do some of that. And then in seventh and eighth grade, I had mentors. AT&T had a program for Black and Latino kids to expose them to software development. So at first I did some like graphing programs, some simple stuff in seventh grade. And in eighth grade, I worked in the network security crew and used the TCP/IP to build a file transfer protocol in Pearl in eighth grade, right? So I had people who invested in me. And then there's a program in Monmouth County, New Jersey where I'm from called PACE where a lot of the people who ran that program were the sort of first set of computer science grads that were African American from MIT and Stanford and North Carolina A&T and some of the historically Black colleges and universities. So then I got, you know, some mentoring from them. So I always wanted to be a technologist. And I took a sort of segue into economics because I had like my whole childhood I wanted to go to MIT. And it actually made more sense financially for me to end up going to Harvard, and so I did, and I really disliked the computer science program at the time. It has much improved. I've read a lot about it as an alum, but at the time I took the Intro CS50 class from Brian Kernighan who wrote the original C book, and it was a great class, but I really didn't like – and part of it was me. I probably built up some bad habits, but some of it was me thinking about abstraction and then we're doing a, you know, a computer science assignment with like 50 levels of VIF statements and just inside, you know, just my clean code before I even knew it was a thing just making me feel like –

Brian Dawson: Dirty. 

Chad Wathington: Not dirty. It was problematic. So I actually switched to economics because I had a really – again, a transformative experience in high school where I got to do this program called The Fed Challenge that was the Federal Reserve put on this competition where high school kids could talk about monetary policy. So I learned a lot about macroeconomics and monetary policy, had a great high school economics teacher who was a great mentor. And then I decided to switch, and I graduated during the boom and really wanted to get back to technology. So I kind of took a circle path and decided to code on my own. I also had some bad experiences in internships in corporate America. I won't name the companies, but man, I saw some really dysfunctional things in corporate IT which now I look at it from the ThoughtWorks lens and revolutionized IT and see so many of those things that we can change. There was a guy at one of the places I worked for whose full job – this is no exaggeration – was to debug production. So they would do a release every Thursday. He would like get in at 2:00 in the morning, and then he would trace all the bugs and debug production, and that was his job. His nickname was Debug. Right? So you know, I've taken internships and looking at this stuff going, man, I don't think I want to be a developer. Also this organization had weekly reorganizations and just a lot of things that we look at now as dysfunction in technology. And so I said, well, maybe this economics thing is kind of cool and maybe I should try that. I've gotten, you know, the ability to dabble in a lot of different things across the last 15 years at ThoughtWorks. And so that's helped me stay close to technology while not writing production code anymore. 

Brian Dawson: Well, that's a phenomenal, phenomenal story. And I'm once again in a place where there's no possible physical chance that I'm going to be able to ask you all the questions that I want to ask you. So no, I appreciate that history. So first before we move on, look, I think that story's really important and I love the fact that you recognize some privilege. You had the mind. You had the interest, but you were not here alone.

Chad Wathington: No. 

Brian Dawson: You had people that supported you. You were given access. I think that that's important for people to understand. Shifting. I do want to ask, when we talk about or a key component of our DevOps Radio episodes – and I'm going to reset this – on DevOps Radio, we have a tradition and that is that we ask our guests about a DevOops moment. That is DevO-O-P-S, like Dev Oops – that was an opportunity for you or your teammates to learn from a mistake, again, in the spirit of feedback loops and in this spirit of continuous learning optimization and improvement. Would you happen to have a DevOops moment that you can share with us?

Chad Wathington: Yes. I think probably the one that jumps greatest to mind is when we first released what would become GoCD. Despite what ThoughtWorks talks about with testing, you know, because again for the listeners, Selenium was first created at ThoughtWorks and Selenium 2 which was WebDriver also. Simon Stewart worked on that at ThoughtWorks. So open source test automation from JBehave and a lot of the BDD frameworks are either by, you know, existing ThoughtWorks, former ThoughtWorkers. A lot of testing things came out of ThoughtWorks. We had not tested very much, and our functional test suite was not what I would be proud of, and we were building a tool to help people do it. So the first release was chalked full of problems. And in fact, I think one of the things that we really learned about maintaining quality is after the first year, we had a series of some production issues and it was installed software. It slowed down our roadmap so much. We were kind of mired in fixing things so much 'cause we moved so fast that the actual speed lost us time, that we spent chunks of our roadmap fixing things. And we committed to doing better later and sort of living to our own values. We actually did, within the product group, we did book clubs on the Continuous Delivery book. 

And we're like we should really, you know, eat our own dogfood. 

Chad Wathington: Yeah, we should eat our own dog food, right? And then we improved dramatically from there. But yeah, that first release, I would say we had, you know, oh man, maybe 15 core strain functional tests. We had unit tests, but we like hadn't done the rest of the things that we would advocate or even that the product enabled you to do. And yeah, it was painful, very painful.

Brian Dawson: So what would you say is kind of the summarized takeaway from that experience for our listeners?

Chad Wathington: I think that when we think about testing, especially now that developers do more testing than historically where it was really separate and there were some testing group who were on the side. 

Brian Dawson: Still a lot of that. 

Chad Wathington: Yeah. And that, it's really interesting because out of the book that Glenford J. Myers wrote on software testing in like 1976 or something like that recommends that. That's where that practice came from. But people view sort of testing as slowing things down, and especially if you have like tons of functional tests that you haven't curated and you've built the – we've seen Selenium nightmares of people building up this crazy test suites that they haven't really thought through or curated, and there's some debt there. But I think there's a perception that building really robust test regression and being able to underpin that stuff with automation is sometimes too much work and we should, you know, just stick to the lightweight contract testing that we do. Maybe we've got good basic unit tests, which is awesome. You should. And then we got some contract tests and we're good. We've got microservices. We're good. But what we found was the better that underlying functional regression suite was, the faster we could move. I think that's kind of again one of these attitudes that we learned a long time ago that is still not adopted today, but it's certainly from the ThoughtWorks product crew perspective really changed how we built software to learn that tough lesson. 

Brian Dawson: Yeah, that's interesting. I also hear that while we should be pragmatic and not dogmatic, there's some room for dogma sometimes because it sounds like even when we cognitively or logically know we should do it, we can miss it. So another question is what is a book, a podcast, or other resource that you would absolutely recommend that our audience go out and pick up? And I'm going to start to put – it can't be Phoenix Project. It can't be anything from Gene Kim. It can't be Jez or Nicole. 

Chad Wathington: Okay, cool. Yeah, so trunkbaseddevelopment.com, Paul Hammant and version of control. He just came out with his Leanpub. I haven't read it yet, but there's many articles on trunkbaseddevelopment.com about Branch by Abstraction and trunk-based development, lots of diagrams. So I would highly suggest that since he just released that, I think today or yesterday. My approach to information gathering is I follow a lot of different folks on Twitter. I also, you know, try to follow as many strange reddit subreddits as I can just to be aware of the conversation because I find that there's no good resource anymore. Like back in the days of RSS, I feel like there were a lot more really good aggregators and now I feel like you gotta construct your own aggregator. So I feel like the people almost directing the conversation on Twitter are often really interesting. In the infosec world, Ian Coldwater and Erica Joy about general software engineering and diversity. Yeah, so there are folks – Elisabeth Hendrickson obviously. She was on the show recently. 

Brian Dawson: Fantastic, yeah. 

Chad Wathington: Yeah. So I find that I follow people who are augmenting the conversation or, you know, surfacing the conversation and then I go down rabbit holes. I even have tried to rig Apple News to like have – because Apple News really just loves to surface mainstream big news publications, but I've tried to like rig it to surface a lot about software development by adding tons of topics to it just to see if I can get it to work. Sometimes it does. Sometimes it doesn't. But I have this elaborate scheme to surface information. 

Brian Dawson: Well, when you get it figured out, you're gonna have to let me know because I actually live Apple News. I kind of start my morning with it after moving off of HuffPost and various other things. But yeah, I'm stuck in kind of the political loop on Apple News, missing a lot. No, those are great resources. Thank you for sharing that, also your process. Before we wrap, Chad, would you please share some final thoughts with us? What is important to you that is conveyed to our listeners, be it around the future of development, approach to practices in technology, diversity? What are some final words?

Chad Wathington: Yeah, I think we're in like a moment of not only societal change but tech change, right? Some people have called it the beginning of the fourth industrial revolution. Whatever you think about the philosophy of it, I think we're in a moment where things like machine learning are going to fundamentally change how we build software. Probabilistic development might change how we build software. AR and VR, there are big companies making real bets on the next computing platform. So all these things are converging, and I think our place as technologists is not just to react but to be proactive in saying what we want the world to look like. And some of that can be from a practices perspective. Some of it can be from an ethical tech perspective. Some of it can be from an intersection of tech and society like, hey, we need to drive some big social change. But it's our place. Again, we talked about privilege a little bit. Being a technologist now is the, you know, most dynamic time in probably history, at least of the, you know, last hundred years of western civilization to affect things, right? You're building things that affect, again, people's daily life. And so if you don't take the view that, hey, what we do today people are going to look at 50 years from now and say we did a good job or a bad job. And then that's a real missed opportunity. I said at the end of the ethical tech webinar that we did last week is to engage, like show up, think about these things, have the conversations, try things. When we think about DevOps culture and continuous improvement – we talked about that already – there are a lot of things that we do in DevOps that apply not just in the narrow but when you think about observability and control. We talk about these things. Well, what about observing the effects of our things that we do in a societal context, right, and how do we instrument those things and think about those things? I think there's a fair amount we can do if we just put our hands up and engage to do it. So I encourage everybody who listens to take this moment in history and time and show up. 

Brian Dawson: Fantastic. Take this moment in history and time and show up. Thank you, Chad Wathington of ThoughtWorks, Chief Strategy Officer. This has been a fantastic conversation. I've enjoyed it. Hopefully we'll be able to get you back again and we can drill down or really pull – we yanked on a bunch of threads, didn't have enough time to pull them out fully. Hopefully, we can get back together again sometime soon with our listeners and pull some of these threads a little deeper. But I appreciate your time. Thank you very much. 

Chad Wathington: Would love to and I totally enjoyed the conversation too. I hope we got some benefit for everybody out there listening to DevOps Radio. Thanks for having me. Thank you. Bye-bye.