In the latest episode of the ‘groCTO: Originals’ podcast (formerly Beyond the Code), host Kovid Batra welcomes Paul Lewis, CTO at Pythian and board member at the Schulich School of Business, who brings extensive experience from companies like Hitachi Vantara & Davis + Henderson. The topic for today’s discussion is ‘Team Building 101: Communication & Innovation’.
The episode begins with an introduction to Paul, offering insights into his background. During the discussion, Paul stresses the foundational aspects of building strong tech teams, starting with trusted leadership and clearly defining vision and technology goals. He provides strategies for fostering effective processes and communication within large, hybrid, and remote teams, and explores methods for keeping developers motivated and aligned with the broader product vision. He also shares challenges he encountered while scaling at Pythian and discusses how his teams manage the balance between tech and business goals, emphasizing the need for innovation & planning for future tech.
Lastly, Paul advises aspiring tech leaders to prioritize communication skills alongside technical skills, underscoring the pivotal role of 'code communication' in shaping successful careers.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He has more than 25 years of engineering leadership experience. He has been a CTO for organizations like Hitachi Vantara and today, he's working as a CTO with Pythian. Welcome to the show. Great to have you here, Paul.
Paul Lewis: Hi there. Great to be here. And sadly, it's slightly more than 30 years versus 25 years. Don't want to shame you.
Kovid Batra: My bad. All right, Paul. So, before we dive into today's topic, by the way, today's topic, audience for you, uh, it's building tech teams from scratch. But before we move there, before we hear out Paul's thoughts on that, uh, Paul, can you give us a quick intro about yourself? Or maybe you would like to share some life-defining moments of your life. Can you just give us a quick intro there?
Paul Lewis: Sure. Sure. So I've been doing this for a long time, as we just mentioned. Uh, but I've, I've had the privilege of seeing sort of the spectrum of technology. First 17 years in IT, like 5, 000 workloads and 29 data centers. You know, I was involved in the purchase of billions of dollars of hardware and software and services, and then moving to Hitachi, a decade of OT, right? So, I get to see what technology looks like in the real world, the impact to, uh, sort of the human side of the world and nuclear power plants and manufacturing and hospitals.
Uh, and then, the last three years at Pythian, uh, which is more cloud and data services. So, I get to see sort of the insight side of the equation and what the new innovation and technology might look like in the real future. I do spend time with academics. I'm on the board of Schulich School of Business, Masters of Technology Leadership, and I spend time with the students on Masters of Management and AI, Masters of Business Analytics.
And then, I spend at least once a quarter with a hundred CIOs and CTOs, right? So, we talk about trends, we talk about application, we talk about innovation. So, I get to see a lot of different dimensions of the technology side.
Kovid Batra: Oh, that's great. Thanks for that quick intro. And of course, I feel that today I'm sitting in front of somebody who has immense experience, has seen that change when there was internet coming in to the point where AI is coming in. So, I'm sure there is a lot to learn today from you.
Paul Lewis: That sounds like a very old statement. Yes, I have used mainframe. I have used AS400.
Kovid Batra: I have no intentions. Great, man. Great. Thank you so much. So, let's get started. I think when we are talking about building teams from scratch. I think laying the foundation is the first thing that comes to mind, like having that culture, having that vision, right? That's how you define the foundation for any strong tech team that needs to come in. So, how do you establish that? How do you establish that collaborative, positive team culture in the beginning? And how do you ensure the team aligns with the overall vision of the business, the product. So, let's hear it from you.
Paul Lewis: Sure. Well, realistically, I don't think you start with the team and team culture. I think you start with the team leadership. I know as recent in the last three years, when we built out the Pythian software engineering practice, well, I started by bringing in somebody who's worked for me and with me for 15 years, right, somebody who I trusted, who has an enterprise perspective of maturity, who I knew had a detailed implementation of building software, who has built, you know, hundreds of millions of dollars worth of software over a period of time, and I knew could determine what skill set was necessary. But in combination with that person, I also needed sort of the program management side because this practice didn't exist, there was no sense of communications or project agility or even project management capability. So, I had to bring in sort of a program management leadership and software delivery leadership, and then start the practice of building the team. And of course, it always starts with, well, what are we actually building? You can't just hire in technologists assuming that they'll be able to build everything. It's saying, what's our technology goal? What's our technology principles? What do we think the technology strategy should be to implement? You know, whatever software we think we want to build. And from that, we can say, well, we need at least, you know, these five different skill sets and let's bring in those five skill sets in order to coordinate sort of the creation of at the very least, you know, the estimates, the foundation of the software.
Kovid Batra: Makes sense So, I think when you say bringing in that right leadership that's the first step. But then, with that leadership, your thought is to bring in a certain type of personality that would create the culture or you need people who align with your thoughts as a CTO, and then you bring those people in? I think I would want to understand that.
Paul Lewis: I'm less sure you need to decide between the two. I know my choices usually are bringing in somebody to which already knows how to manage me. Right? As you can imagine, CTOs, CIOs have personalities and those personalities sometimes could be straining, sometimes can be motivational, sometimes could be inspirational, but I knew I need to bring somebody in that didn't have to, that already knew how to communicate with me effectively, that I already know knew my sort of expectations of delivery, expectations of quality, expectations of timeliness, expectations of adhering to technology principles and technology maturity. So, they passed that gate, right? So now, I had sort of right out of the gate trust between me and the leadership that was going to deliver on the software which is sort of the first requirement. From then, then I expect them to both evolve the maturity of the practice, in other words, the documentation and technology principles and build out the team itself from scratch.
So, determine what five skills are necessary and then acquire those skills and bring them into the organization. It doesn't necessarily mean hiring. In fact, the vast majority of the software, which I've built over the time, we started with partnerships with ecosystems, right? So, ecosystems of QA partnerships and development partnerships. Bring those skill sets in and as we determine, we need sort of permanent Pythian resources like software architecture resources or DevOps architecture resources or, you know, skilled senior development that we start to hire them in our organization as being the primary decision-makers and primary implementers of technology.
Kovid Batra: Makes sense. And, uh, Paul, does this change with the type of business the org is into or you look at it from a single lens, like if the tech team is there, it has to function like this, uh, does it change with the business or not?
Paul Lewis: I think it changes based on the business objectives. So, some businesses are highly regulated and therefore, quality might be more important than others. The reality is, you know, the three triangles of time, cost, and quality. For the most part, quality is the most fungible, right? There are industries where I'm landing a plane where quality needs to be, you know, near zero bugs and then tech startups where there's an assumption that there'll be severe, if not damaging bugs in production, right, cause I'm trying to deploy a highly agile environment. So, yes, different organizations have different sort of, uh, appetites for time, cost, and quality. Quality being the biggest measure that you can sort of change the scale on. And the smaller the organization, the more agile it becomes, the more likelihood that you can do things quickly with, I'll call it less maturity, out of the gate, and assume that you can grow maturity over time.
So, Pythian is an example. Out of the gate, we had a relatively zero sense of maturity, right? No documentation, no process, no real sort of project management implementation. It was really smart people doing really good work. Um, and then we said, "Wow, that's interesting. That's kind of a superhero implementation which just has no longevity to it because those superheroes could easily win the lottery and move on." Right? So, we had to think about, well, how do we move away from the superhero implementation to the repeatable scalable implementation, and that requires process, and I know development isn't a big fan of process holistically, but they are a fan of consistency, right? They are a fan of proper decision-making. They are a fan of documented decisions so that the next person who's auditing or reviewing or updating the code knows the purpose and value of that particular code, right? So, some things they enjoy, some things they don't, uh, but we can improve that maturity over time. So, I can say every year we want to go from 0 to 1, 1 to 2, 2 to 3, never to pass 3, right, because we're not, like Pythian, for example, isn't a bank, right, isn't an insurance company, isn't a telco, we're not landing planes, we're not solving, uh, we're not solving complex, uh, healthcare issues, so we don't have to be as mature as any one of those organizations, but we need to have documents at least, right, we need to ensure that we have automation, automated procedures to push to production instead of direct access, DBA access to the database in a production environment. So, that's kind of the evolution that we had.
Kovid Batra: So, amazing to hear these kinds of thoughts and I'm just trying to capture how you are enabling your developers or how you are ensuring that your developers, your teams are aligned with a similar kind of thought. What's your style of communicating and imbibing that in the team?
Paul Lewis: We like to do that with technology principles, written technology principles. So, think of it as a, you know, top 10 what the CTO thinks is the most important when we build software. Right? So what the top 10 things are, let's mutually agree that automation is key for everything we do, right? So, automation to move code, automation to implement code, uh, automation to test, automation in terms of reporting, but that's key. Top 10 is also we need to sort of implement security by design. We need to make sure that, um, it has a secure foundation because it's not just internal users, but we're deploying the software to 2,000 endpoints, and therefore, I need to appreciate endpoints to which I don't control, there I need, therefore I need a sort of a zero trust implementation. I need to make sure that I'm using current technology standards and architectural patterns, right? I want to make sure that I have implemented such a framework that I can easily hire other people who would be just as interested in seeing this technology and using technology, and we want to be in many ways, a beacon to new technologies. I want the software we build to be an inspirational part of why somebody would want to come to work at Pythian because they can see us using an innovating current practical architectural standards in the cloud, as an example.
So, you know, you go through those technology principles and you say, "This is what I think an ideal software engineering outcome, set of outcomes look like. Who wants to subscribe to that?" And then, you see the volunteers putting up their hands saying, "Yeah, I believe in these principles. These principles are what I would put in place, or I would expect if I was running a team, therefore I want to join." Does that make sense?
Kovid Batra: Yeah, definitely. And I think these are the folks who then become the leaders for the next set of people who need to like follow them on it.
Paul Lewis: Yeah, exactly.
Kovid Batra: It totally makes sense.
Paul Lewis: And if you have a set of rules, you know, I use the word 'rules', you know, loosely, I really just mean principles, right? To say, "Here are the set of things we believe and want to be true even if there's different maturities to them. Yes, we want a fully automated system, but year one, we don't. Year three, we might." Right? So, they know sometimes it's a goal, sometimes it's principle, sometimes it's a requirement. Right? We're not going to implement low-quality code, right? We're not going to implement unsecured code, but if you have a team to buy in those principles, then they know it's not just the outcome of the software they're building, but it's the outcome of the practice that they're building.
Kovid Batra: Totally, totally. And when it comes to bringing that kind of people to the team, I think one is of course enabling the existing team members to abide by that and believe in those principles, but when you're hiring, there has to be a good talent acquisition strategy there, right? You can't just go on hiring, uh, if you are scaling, like you're on a hiring spree and you're just bringing in people. So how do you keep that quality check when people are coming in, joining in from the lowest level, like from the developer point, we should say, to the highest leadership level also, like what's your strategy there? How do you ensure this team-building?
Paul Lewis: Well, on the recruiting side, we make sure we talk about our outcomes frequently, both internally in the organization and externally to, uh, you know, the world at large. So internally, I do like a CTO 'ask me anything', right? So, that's a full, everybody's, you know, full board, everybody can access it, everybody can, and it's almost like a townhall. That's where we do a couple of things. We disclose things I'm hearing externally that might be motivating, inspiring to you. It's, "Here's how we're maturing and the outcomes we've produced in software over this quarter.", let's say. And then, we'll do a technology debate to say, "You know what, there's a new principle I need to think about, and that new principle might be generative AI. Let's all jump in and have a, you know, a reasonably interesting technology debate on the best implications and applications of that technology. So, it's almost like they get to have a group think or group input into those technology principles before we write it down and put it into the document. And then if I present that, which I do frequently externally, then I gavel, you know, whole networks of people to say, "Wow, that is an interesting set of policies. That's an interesting set of, um, sort of guiding principles. I want to participate in that." And that actually creates recruiting opportunities. I get at least 50 percent of my LinkedIn, um, sort of contributions and engagements are from people saying, "I thought what you said was interesting. That sounds like a team I want to join. Do you have openings to make that happen?" Right? So, we actually don't have in many ways a lack of opportunity, recruiting opportunity. If anything, we might have too much opportunity. But that's how we create that engagement, that excitement, that motivation, that inspiration both internally and externally.
Kovid Batra: And usually, like when everyone is getting hired in your team like, do you handpick, like at least one round is there which you take with the developers or are you relying mostly on your leadership next in line to take that up? How does that work for your team?
Paul Lewis: I absolutely rely on my leadership team, mostly because they're pretty seasoned and they've worked with me for a while, right? So, they fully appreciate what kind of things that I would expect. There are some exceptions, right? So if there are some key technologists to which I think will drive inspirational, motivational behavior or where they are implementing sort of the core or complex patterns that I think are important for the software. So, things like, uh, software architecture, I would absolutely be involved in the software architecture conversations and recruiting and sort of interviewing and hiring process because it's not just about sort of their technology acumen, it's also about their communication capabilities, right? They're going to be part of the architectural review board, and therefore, I need to know whether they can motivate, inspire, and persuade other parts of the organization to make these decisions, right? That they can communicate both verbally and in the written form, that when they create an architectural diagram, it's easy to understand, sort of that side, and even sort of DevOps-type architects where, you know, automation is so key in most of the software we develop and that'll lead into, you know, not just infrastructure as code, but potentially even the AI deployment of infrastructure as code, which means not only do they need to have, you know, the technical chops now, I need them to be well read on what the technical jobs are needed for tomorrow. Right? That also becomes important. So, I'll get involved in those key resources that I know will have a pretty big impact on the future of the organization versus, you know, the developers, the QAs, the BAs, the product owners, the project managers, you know, I don't necessarily involved in every part of that interview process.
Kovid Batra: Totally, totally. I think one good point you just touched upon right now is about processes and the communication bit of it. Right? So, I think that's also very critical in a team, at least in large-scale teams, because as you grow, things are going hybrid, remote, and even then, the processes are, and the communication is becoming even more critical there, right? So, in your teams, how do you take up or how do you ensure that the right processes are there? I mean, you can give some examples, like how do you ensure that teams are not overloaded or in fact, the work is rightly distributed amongst the team and they're communicating well wherever there is a cross-functional requirement to be delivered and teams are communicating well, the requirements are coming in? So, something around process and communication which you are doing, I would love to hear that.
Paul Lewis: Good questions. I think communication is on three fronts, but I'll talk about the internal communication first, the communication within the teams. We have a relatively unique set of sort of development processes that are federated. So, think of it as there is a software engineering team that is dedicated to do software engineering work, but for scale, we get to dip into the billable or the customer practices. So, if I need to deliver an epic or a series of stories that require more than one, uh, Go developer or data engineer or DevOps practitioner, then I have the ability to dip into those resources, into those practices, assign them temporarily to these epics and stories, uh, or just a ticket that they, that I want them to deliver on and then they can deliver on them as long as it's all, as long as everybody's already been trained on how to implement the appropriate architectural frameworks and that they're subscribing to the PR process that is equivalent, both internally and externally to the team. We do that with standard agile processes, right? We do standups on a daily basis. We break down all of our epics in the stories and we deliver stories in the tickets and tickets get assigned people, like this is a standard process with standard PM, with standard architectural frameworks, standard automation, deployments, and we have specific people assigned to do most of the PRs, right? So not only PR reviews, but doing sort of code, code creation and code deployment so that, you know, I rely on the experts to do the expert work, but we can reach out into those teams when we need to reach out to those teams and they can be temporary, right? I don't need to assign somebody for an entire eight-week journey. Um, I could just assign them to a particular story to implement that work, which is great. So, I can expand any one particular stream from five people to 15 people at any one period of time. That's kind of the internal communication.
So, they do standups. We do, you know fine-tuned documentation, uh, we have a pretty prescriptive understanding of what's in the backlog and how and what we have to deliver in the backlog. We actually detail a one-year plan with multiple releases. So, we actually have a pretty detailed, we'll call it 'product roadmap' or 'project roadmap' to deliver in the year, and therefore, it's pretty predictable. Every eight weeks we're delivering something new to production, right? But that's only one of those communication patterns. The other communication patterns all to the other internal technology teams, because we're talking about, you know, six, seven hundred internal technologists, and we want them to be aware of not just things that we've successfully implemented in the past and how it's working in production, but what the future looks like and how they might want to participate in the future functions and features that we deliver on.
But even those two communication patterns arguably isn't the most important part. The most important part might actually be the communication up. Right? So now, I have to have communication on a quarterly basis with my peers, with the CEO and the CFO to say not only how well we're spending money, how well we're achieving our technological goals and our technological maturity, but even more importantly, are we getting the gain in the organization? So, are we matching the revenue growth of the organization? Are we creating the operational efficiency that we expect to create with the software, right? Cause I have to measure what I produce based on the value created, not just because I happen to like building software, and that's arguably the most difficult part, right, to say, "I built software for a purpose, an organizational purpose. Am I achieving the organizational goals?" Much more difficult calculus as compared to, "I said I was going to do five features. I delivered five features. Let's celebrate."
Kovid Batra: But I think that's the tricky part, right? And as you said, it's the hardest part. How do you make sure, like, as in, see, the leaders probably are communicating with the business teams and they have that visibility into how it's going to impact the product or how it's going to impact the users, but when it comes to the developers particularly, uh, who are just coding on a day-to-day basis, how do you ensure that the teams are motivated that way and they are communicating on those lines of delivering the outcomes, which the leaders also see? So, that's..
Paul Lewis: Well, they get to participate in the backlog prioritization, right? So, in fact, I like to have most of the development team consider themselves in many ways, owners of the software. They might not have the Product Owner title, or they might not be the Product Manager of the product, but I want them to feel like it's theirs. And therefore, I need them to participate in architectural decisions. I want them to buy-in to what the priority of the next set of features are going to be. I want to be able to celebrate with them when they do something successful, right? I want them to be on the forefront of presenting the value back to the rest of the team, which is why that second communication to the rest of the, you know, six or seven hundred technologists that they're the ones presenting what they created versus I'm the one presenting their credit. I want them to be proud of the code that they've built, proud of the feature that they've implemented and talk about it as if it's something that they, you know, had to spend a good portion of their waking hours on, right? That there was a technology innovation or R&D exercises that they had to overcome. That's kind of the best part. So, they're motivated to participate in the, um, in the prioritization, they're motivated to implement good code, and then they're motivated to present that as if it was an offering they were presenting to a board of decision-makers, right? It's almost as if they're going and getting new money to do new work, right? So, it's a dragon's den kind of world, which I think they enjoy.
Kovid Batra: No, I think that's a great thought and I think this makes them feel accountable. This makes them feel motivated to whatever they are doing, and at the end of the day, if the developers start thinking on those lines, I think you have cracked it, probably. That's the criteria for a successful engineering, for sure.
Apart from that, any other challenges while you were scaling, any particular example from your journey at Pythian that you felt is worth sharing with our audience here?
Paul Lewis: The challenge is always the 'what next?'. Right? So let's say, it takes 24 months to build a substantial piece of software. Part of my job, my leadership's job is to prepare for the next two years, right? So, we're in deep dive, we're in year one, we're delivering, we're halfway delivering some interesting piece of software, but I need to prep year three and year four, right? I need to have the negotiations with my peers and my leaders to say, "Once we complete this journey, what's the next big thing on the list? How are we going to articulate the value to the organization, either in growth or efficiency? How are we going to determine how we spend? Is this a $1m piece of software, or is this a $10m piece of software?" And then, you know, preparing the team for the shift between development to steady state, right? From building something to running something. And that's a pretty big mindset, as you know, right? It's no longer focused on automation of releases between dev, QA & production. It's saying, "It's in production now. It's now locked down. I need you to refocus on development on something else and let some other team run this system." So, both sides of that equation, how do I move from build to run in that team? And then, how do I prepare for the next thing that they build?
Kovid Batra: And how do you think your tech teams contribute here? Because what needs to be built next is something that always flows in, in terms of features or stories from the product teams, right? Or other business teams, right? Here, how do you operate? Like, in your org, let's say, there is a new technology which can completely revamp the way you have been delivering value so that tech team members are open to speak and like let the business people know that this is what we could do, or it's more like only the technical goals are being set by the tech team and rest of the product goals are given by the product team. How does it work for the, for your team here?
Paul Lewis: It's pretty mutual in fairness, right? So, when we determine sort of the feature backlog of a piece of software, there's contribution for product management, think of that as the business, right? And the technology architecture team, right? So, we mutually determine what our next bet in terms of features that will both improve the application, functionally improve the application technically. So, that's good.
When it comes to the bigger piece of software, so we want to put this software in steady state, do minor feature adjustments instead of major feature adjustments, that's when it requires much more of a, sort of a business headspace, right? Cause it's less about technology innovation at that point. However, sometimes it is, right? Sometimes I'll get, "Hey, what are we doing for generative AI? What new software can we build to be an exemplar of generative AI?" And I can bring that to the table. So, I have my team bringing to the decision-making table of, "Here's some technology innovation that's happening in the world that I think we should apply." And then, from the business saying, "Here's a set of business problems or revenue opportunities that we can match." So now, it's a matching process. How can I match generative AI, interesting technology with, you know, acquiring a new customer segment we currently don't acquire now, right? And so, how do I sort of bring both of those worlds together and say, "Given this match program, I'm going to circle what I think is possible within the budget that we have."?
Kovid Batra: Right. Right. And my question is exactly this, like, what exactly makes sure that the innovation on technology and the requirements from the customer end are there on the same table, same decision-making table? So, if I'm a developer in your team, even if I'm well aware of the customer needs and requirements and I've seen certain new technologies coming up, trending up, how do I make sure that my thought is put on the right table in front of the right team and members?
Paul Lewis: Well, fortunately, like most organizations, but definitely Pythian, we've created like an architectural review board, right? So, that includes development, architecture, product management, but it's not the executive team, right? It's the real architectural practitioners and they get to have the debate, discussion on what they think is the most technologically challenging that we want to solve or innovation that we think matters or evolution of technology that we think we want to implement within our technologies, moving from, you know, an IaaS to a PaaS to a Saas, as an example, those are all decisions that in many ways we let the technology practitioners make, and then they bring that set of decisions to the business to say, "Well, let's match this set of architectural principles with a bunch of business problems." Right? So, it's not top-down. It's not me saying, "Thou shalt build software. Thou shalt use Gen AI. Make it so." It rarely is that. It's the technology principle saying, "We think this innovation is occurring. It's a trend. It's important. We think we should apply it knowing its implications. Let's match that to one of a hundred business problems to which we know the business has, right? The reality is the business has an endless amount of technology problems, of business problems. Technology has an endless amount of innovation, right?
Kovid Batra: Yeah, yeah.
Paul Lewis: There's no shortlist in either of those equations.
Kovid Batra: Correct. Absolutely. Perfect, perfect. I think this was great. I think I can go on talking with you. Uh, this is so interesting, but we'll take a hard stop here for today's episode and thank you so much for taking out time and sharing these thoughts with us, Paul. I would love to have you on another show with us, talking about many more problems of engineering teams.
Paul Lewis: Sure.
Kovid Batra: But thanks for today and it was great meeting you. Before you leave, um, is there a parting advice for our audience who are mostly like aspiring engineering managers, engineering leaders of the modern tech world?
Paul Lewis: Um, the gap with most technologists, because they tend to be, you know, put their glasses on, close the lights in the room, focus on the code, that's amazing. But the best part of the thing you develop is the communication part. So, don't be just a 'code creator', be a 'code communicator'. That's the most important part of your career as a developer, is to present that wares that you just built outside of your own headspace. That's what makes the difference between a junior, an intermediate, senior developer and architect. So, think about that.
Kovid Batra: Great, great piece of advice, Paul. Thank you so much. With that, we'll say, have a great evening. Have a great day and see you soon!
Paul Lewis: Thank you.
Implement DORA metrics, gain dev visibility & drive success in your teams.
Try Live Demo
