← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
CTO Series: Mastering the CTPO Role, Katrina Clokie’s Guide to Tech and Product Leadership
00:45:55
CTO Series: Mastering the CTPO Role, Katrina Clokie’s Guide to Tech and Product Leadership In this BONUS episode, we sit down with Katrina Clokie, a seasoned leader in strategy, change management, and building inclusive teams. Katrina...
Loading summary
Transcript39 lines
- [00:04]
Vasco Duarte
Hey, how are you doing? I'm Vasco Duarte, your host on the Scrum Master Toolbox podcast. And I've got some exciting news. So right now, as I record this, I'm holding in my hand the signed contract for our very first Global Agile Summit. We're all in and I couldn't wait to share this news with you. So mark your calendars. May 18th, 20th of 2025 in Tallinn, Estonia. We're gonna have a transformative experience. We're putting together an event that is all about real life Agile. It's not theory or buzzwords. It's practitioners sharing what's working, what's making an impact, and how they've overcome challenges that you too will have to face, or maybe even facing. Right now, we're bringing together the best stories in Agile. From product leaders to engineering wizards to business visionaries, these will be stories that will inspire you to action. This isn't just another conference. It's a chance to connect with the people that are shaping the future of Agile. And here's the best part. Right now, we're in our super early bird phase. And that means you can grab tickets at just 25% of the final price. Look, that's not just half off, it's half off of the half off. It's an incredible deal for our dedicated community members, just like you listening to this right now. So at the summit, day one will be all about hands on workshops. And days two and three, we'll dive into leadership, product strategy, coding, testing, and everything that makes Agile thrive in organizations. Right now remember, these are all first person, real life stories. Now whether you're a leader, a developer, or part of a consulting company, this event is built to take your Agile game to the next level. So don't wait. Go to globalagilesummit.com and grab your ticket. Today, let's all make 2025 the year agile truly transforms your teams, your business and our industry. I'll see you all in Tallinn. And Remember, go to globalagilesummit.com and get your super early bird ticket right now. It only be available until the agenda is announced, so don't wait. Grab it right now. Right now that that's out of the way, on to the episode. Hello, everybody. Welcome to one more episode in our CTO series. And for this episode, pardon me, Joining us from down under is Katrina Cloki. Hey, Katrina. Welcome to the show.
- [02:54]
Katrina Cloki
Hey, thanks for having me.
- [02:57]
Vasco Duarte
Absolutely. So Katrina is a respected leader known for her expertise in strategy change, management and creating inclusive teams. She's Also a keynote speaker at international conferences. Focuses on leadership and communication. Her book, A Practical Guide to testing in DevOps has reached over 7,000 readers. And in 2018 she was a finalist for New Zealand's Inspiring Individual of the Year award. That's quite an achievement. Congratulations on that, Katrina.
- [03:30]
Katrina Cloki
Thank you.
- [03:31]
Vasco Duarte
And you have such a, I would say, like this wide approach to your role in technology. What was potentially the pivotal moment that defined your approach to how you see technology and also your role in leadership of technology organizations?
- [03:51]
Katrina Cloki
Yeah, it's a good opening question. I actually was thinking about what was pivotal for me in my career. And it wasn't something that changed my approach to technology, it was more something that changed my approach to pursuing opportunities within technology. So I engaged with a mentor almost 10 years ago now and she was an ex member of Parliament in New Zealand and a CEO of a shipping company. So completely divorced from tech as an industry. And we talked about how to pursue senior leadership or executive level roles and she said to me, if you keep applying for roles that you can already do, you're not going to progress. You need to look at a job description and feel that you're incapable or unable of doing some of that today because then you know that you're not going to get bored if you get that opportunity. There's going to be learning, there's going to be challenge, there's going to be something that is new and scary and will grow you as a person. And that for me was really when I. You could probably identify that conversation in my employment history where I stopped shifting between fairly technical individual contributor roles and started pursuing engineering, management and ultimately a C level technical role. And I guess you could argue that I have a similar approach to technology where I want to be having conversations about things I don't completely understand. I want the opportunity to grow and learn and I want to create those opportunities for people in my team where we're exploring things and innovating and it's exciting. There's an aspect of unknown. You're not sure if you'll be successful. It's a fun kind of space to be in, I think.
- [06:30]
Vasco Duarte
So taking that fun forward, I noticed that recently on LinkedIn you've taken up a new position that is the Chief Technology and Product Officer. You are the second CTPO in our series. So that means that maybe this role is picking up in the technology world. But what led your company to create that role? First, why did they think that it was an important role? And then why did you think you should be the one taking on that responsibility because technology and product are of course complementary, but significantly different aspects of a technology company as well.
- [07:07]
Katrina Cloki
Yeah. So this is a role that I have also seen increasing number of people having this job title in the New Zealand market. And I believe it's a function of the organizational size. I haven't yet seen a CTPO in a really large organization. Often when you're bigger, you can have a CPO dedicated and a CTO dedicated to each business function. And the scale of the business can support that. I work in a company of around 100 staff and we it's a SaaS company. Product is very important, the technology is very important. But also running the business efficiently is very important to our success and longevity as a business. So having those accountabilities centralized in the executive team is something that the business recently chose to do. Why me? So I have been doing this role over the past six months. We had some other people from the executive team leave and this was a responsibility that, that I've picked up a bit of trial by fire because we spent some time without a CEO, without a head of product, and there was a gap there that needed to be filled. I have some experience and product leadership through my career. In my previous roles at like a GM level, there was product in my portfolio. I was in a product owner role earlier on. I have some skill set there, but certainly I need the support of some strong product managers and a good head of product. But I think sort of to the first answer, I want to back myself in a role that's new and that has some accountabilities that I know I can grow into that are going to challenge me, that are going to give me new perspectives. That's exciting. So I think there's the why me is a mixture of I've proven myself in the role and the role is new and different at the same time. So, you know, there's that base level of capability and there's also the potential for it to become something more for both me and the company.
- [10:11]
Vasco Duarte
And I can totally see how it can become more. And especially because one of the big challenges we have in tech companies is this, I could call it this fine balance between the business and the technology. Right. Given that the technology is not the product, the product is something that is built with the technology. Right. But on the other hand, the technology is the core enabler of that product. There are other things like having salespeople or support people or services, organization, whatever that might be, but the technology is often a core aspect of what the product delivers. So when you think about aligning this business direction or strategy and the technology direction or technology strategy, what are the things that you have started or have already put in place to kind of finally do that or to do the fine trade offs that are needed between these two, hopefully aligned directions, but sometimes kind of going in different directions. Right, that can best sometimes go in different directions.
- [11:19]
Katrina Cloki
Yeah, this is a good question. So at Fergus, I think there's a difference between the trade offs you make day to day and the trade offs you make strategically. So one of the things that I think is important is to set some really clear guardrails, more so on the tech side about things we will and will not entertain changing or fixing. So to give you an example, at Fergus, we have a monolith. It has been the foundation of the product for over a decade. As you would expect, there's a large amount of technical debt in that monolith. I've set a clear guardrail that we're not going to embark on a full rewrite or replatform of that monolith. Like, no, that means we can make trade off decisions within that guardrail. We are retiring technology that impedes our developer experience or costs us money or creates instability in the platform. But the monolith rewrite, clear, no. And so I think the alignment comes first at a very high level, strategically. Here's what we will and will not do. And then for us, we set a balance and where we put our engineering capacity within each work stream that we run. So if you are working in our partnership space, we know that you're going to need to spend time maintaining our existing integrations and supporting customers who have problems and fixing technical debt there. So we're going to allocate 60% of your team capacity to the strategic initiatives and 40% to the BAU. So there's another really clear guardrail that we can work within then in terms of aligning the business and tech priorities within those guardrails, that's when it becomes like the day to day of how do you choose? So if we're talking as a specific example, the 40% of capacity within unlock partnerships and you've got a piece of technical debt, you've got a customer complaint, there's a bug, you've got a request for a small feature enhancement that might take half a day. How do you then decide which one of those things to do? And I think my answer there is the balance which you talked about in the question. Right, the balance. So sometimes it's about where did we choose to invest prior and we want to make a different decision this time so that these things are invested in fairly. Sometimes it's about the benefit is disproportionate, like we're going to get a better return on our investment if we spend that time doing the tech debt fix versus the customer feedback through all of that day to day, I think it's conversation, cross functional collaboration and someone who's in the immediate decision, who's also aware of the wider context, so they're respecting the guardrails, they understand past and future decisions and they can then make a good decision about which thing to do now.
- [15:31]
Vasco Duarte
So when you're thinking about this guardrails you call them so that high level strategic, I guess rules you could call it as well, right? Like high level strategic rules. And then the day to day trade offs that of course need to come from the context and the reality of the business at that time. When you have that you have inherently you have tension because you might say, hey, it's 60% for strategic initiatives, but that there's a large opportunity that happens within the next three months and you may need to shift the whole team or a set of teams into that opportunity that is short term, so not strategic. And this of course brings up the big question of creating collaborative teams within a business. Now in your role as ctpo, you have a prime position to create that collaboration between business and technology. So what have you learned about creating that positive collaboration that allows your teams to overcome the natural tension between the high level guidelines and the day to day business?
- [16:44]
Katrina Cloki
Yeah, that's a great question. I have done this in a couple of different organizations now and I think successfully, where I've had to structure a department so that the delivery teams have cross functional disciplines and they have a unified purpose, they have some really clear metrics that they're trying to influence for the business. And it means that when they're making those decisions day to day, you've got a variety of opinions represented in the room and you've got a foundation from which to argue. Because if you don't know what you're trying to achieve as a team and how the success of that work will be measured, it's very difficult to make a choice. You're kind of flying blind, right. So for us that structure is really important to enable people to have, have the right audience in the room, to have healthy conflict and to then ultimately be making the right decisions for the company.
- [18:11]
Vasco Duarte
And when you talk about healthy conflict, which I think is one of the Core aspects of productive collaboration. Right, because we need to have conflict, but it should be a conflict that moves us forward rather than holds us in unhealthy and even potentially toxic patterns of behavior. But how do you, like, when you look at the teams and you see them kind of heatedly arguing about something that they all passionately believe in, how do you make the difference between is this a healthy conflict or is this kind of, you know, veering off and perhaps starting to turn into a not collaborative conflict anymore?
- [18:53]
Katrina Cloki
Yeah, a lot of the time that detection happens before it reaches me. And so I would say if a conflict has escalated, to me, often it's by nature an unhealthy one because it would otherwise have been resolved in the more operational layers of our organization. But in general, if you're talking about trying to catch it early, as in when a leadership team that includes a lead engineer, a product manager, and a product designer, some of them include the quality engineer in that trio and make it a four, if they're having a disagreement, how do they keep it productive? To be honest, I think the majority of our conflict is healthy because of the structure that we just talked about. When people are very clear about what they're trying to achieve, the negotiation about trade off becomes a lot easier because you can empathize and understand how another person's idea or piece of work will have a bigger impact on what you're collectively going for. So people might arrive at a session with differing views, but it's pretty rare for them to leave a session with differing opinion. Like it's. It's not often that a conflict hits my level and needs me to come and direct a resolution when it does. I'm role modeling the same things I would have expected to happen operationally, where we talk about the impact of the work and try to remove the emotion from the decision as much as possible, look at the data and the influence it can have and negotiate and agree on a path that may not make everyone happy, but that everyone can understand is, I think, an important outcome.
- [21:10]
Vasco Duarte
And I can imagine how that clear and unified purpose that you mentioned early can help us keep conflict healthier. Because we can always go back to that unified purpose or goal and say, hey, how does each of these, whatever many options help us go towards that purpose? And of course, if they all do, then it's just a question of scale or, you know, how much and then it doesn't really matter. But if one of them doesn't, everyone should be clear that, okay, this isn't a good option. Because absolutely.
- [21:46]
Katrina Cloki
And that's the kind of, what's the word? That's the way that people are validating these opinions today. They're looking at the purpose and metrics of their teams and understanding how different people's ideas contribute to them.
- [22:12]
Vasco Duarte
So when we talk about conflict, of course there's one area, especially now for you, since you are ctpo, there's one area of decision making in technology organizations that very often leads to conflict. Now, hopefully mostly productive conflict, sometimes not so, and that's roadmapping. Because all of this collaboration strategy, structure, the alignment between business and tech, all of that comes together in those roadmap conversations. So for you as a leader, Katrina, how do you make sure that you're always keeping in mind in your day to day work, that you're always keeping in mind that you're trying to build a future that is then kind of, I think, brought to life through the execution of a roadmap?
- [23:01]
Katrina Cloki
So I think I somewhat cheat in that the roadmaps we produce at fergus don't represent 100% of our engineering capacity because as a technology leader, I know that estimates aren't accurate. They're estimates by name. We must be investing in things that are non strategic. And so to put forward a roadmap that commits your entire function to what's on that page is a false piece of information to give the company. So for me, roadmapping is about choosing the strategic places we want to invest that align with our purpose as a company, the purpose of the teams, the metrics we're trying to shift. I insist on a linear prioritization so we don't have a first equal anywhere. It's 1, 2, 3, 4, 5, tell me what you want. We'll estimate that strategic work against that reduced capacity that I talked about earlier. So 60% of the team will be working on this. Give me a delivery estimate based on that capacity. Do not estimate this as if the team were dedicated to it. And then we build quarterly roadmaps that are fairly accurate and we can then build go to market strategy around, we can align support and training around the sales team know when they can start to leverage those features to sell. And it's something very clear for our longer term roadmapping. My key thing is that we don't over commit because we know historically at Fergus we've been optimistic about the volume of change we can deliver from engineering. And when you start to put that on an annual roadmap, you're setting the expectation by which your team will be measured ongoing if you set that bar too high, you'll spend a year disappointing people. Even if the delivery is excellent and successful within that quarterly time frame, the annual roadmap is an opportunity to set up the teams to fail if you over promise. So I like to keep the annual roadmaps very light and I also like to make it clear that there's a lot of flexibility. So particularly at an organization of our size, the overarching business goals tend to remain persistent around our growth and our churn, the way the platform operates. But the specific strategic initiatives we choose to deliver, those outcomes, they do shift. And so for us, the annual roadmap, it's light and it's flexible. And I think both those things are really important to set up the teams to be successful on that quarterly cadence within that kind of overarching structure.
- [26:58]
Vasco Duarte
Yeah, I really like this idea of first segregating capacity for roadmap over the day to day business. I think that's a, a really important aspect. I also heard you say, just confirming that the quarterly roadmap is what you use to kind of align the different functions in the organization. And then the longer term roadmap is just a direction. It's not really making any commitments beyond that quarterly, I guess, commitment.
- [27:30]
Katrina Cloki
For us, yes, it's unusual. We do tackle multi quarter delivery initiatives and when we do so, we can give an indicative date of when that thing might come. But broadly speaking, we're trying to release value quickly and often. So we deploy between 120 and 160 changes a month to our web and mobile applications. We want to be releasing change as regularly as we can. So customer facing, you know, switching on a feature flag or announcing that something is available to people. It's unusual for us to be doing multi quarter development to realize value. It's not something we never do, but it's unusual and that gives us a little bit of luxury and that we can have more certainty because the initiatives are smaller, the estimates tend to be more accurate, the margin of error is lower, and that enables the wider business to then plan around the delivery of that feature to market and how we then sell it, support it, train people in it.
- [28:59]
Vasco Duarte
So another aspect of leading a technology company, of course, is leading companies through growth or scaling engineering teams. What strategies have you employed to manage and nurture the teams that you work with during this kind of fast growth periods in your organizations?
- [29:18]
Katrina Cloki
Yeah, this was particularly true for me at Xero, my previous employer. When I was there, we had literally hundreds of open roles at one point. This was during the 2021 kind of boom in SAS. So I have a very specific tip that I wanted to give here and that was give your team a break from recruitment. When you're scaling fast, it's very hard to find good people and some companies go with an always on approach to hiring. I think that is the wrong approach.
- [30:00]
Vasco Duarte
Can you explain what you mean by always on?
- [30:03]
Katrina Cloki
Yeah, I will. So always on means we know that we're always going to need more engineers. So we're going to have a persistent job ad for engineers at all levels in the cities or markets that we want to employ staff and we'll have a talent consultant monitoring applications to that ad at all times and redirecting good candidates to the best teams to talk to based on their skill set that comes through. So you might have three open roles and you might get a candidate a week for four months, where they're coming from the shared general pipeline and being shared out across the different places in the organization that are trying to scale. That approach is really exhausting for the people who are recruiting because they are continuously interviewing, collating feedback, trying to make decisions about whether they've seen enough people or they need to see one more. And there's a time sync that's a little bit hidden. Like the interview itself might take an hour, but that could end up being half a day a week for the people involved in that process, whether involved in screening, they're typing out feedback, they're working with a talent consultant, they're doing the interviews like there's a lot of work that's going in there. So my biggest tip for scaling the team is step change rather than always on as in, I know that in six months time I need four new engineers. I'm going to work with my finance team to agree. How many of them can I hire in a batch right now? So I might get three out of the four and then I'm going to defer so that I can have a longer gap, even out my cost and do another batch in, you know, eight months, say. And what that means is I avoid as much as possible putting my teams back into a storming, forming, norming kind of cycle. I'm holding the team steady, I'm avoiding burnout in my people leaders because they can finish interviewing and have a period where they're not doing that activity where they're focusing on the staff and teams they have, where they can then start to build culture and practice and it be a focused task for them. And it means when we do the next batch of Recruitment, we can then invest, make the decisions, bring people in in a cohort and upset all the dynamics of the team again and then kind of reset and grow. So I definitely prefer that as an approach, having done both and seen the impact of an always on kind of attitude to it. If you can partner with your finance and your talent teams to make sure that you can take the budget in batches and take the candidate priority in batches. So in an always on environment, if you're in a big company, you still might be able to work with your talent and finance people to take this batch based approach. It means you take priority on the ad for a period of a couple of weeks, get all your candidates through and hire and then you're done. It's. Yeah, I think there's a lot of positives to tackling it in a different way.
- [34:08]
Vasco Duarte
I really like the contrast between those two approaches. And of course, as you said, there are constraints and you might need to work with talent or HR and finance and figure out how to make it happen. But I think that's a clear and very useful for our listeners. First person, first person account of your experience. So thank you for sharing that.
- [34:28]
Katrina Cloki
No problem.
- [34:29]
Vasco Duarte
On a different note though, Katrina, when you think about this cto, I guess the CTPO role is too young for you, but when you think about the CTO role, what's been the biggest challenge that you faced and how did you overcome it?
- [34:52]
Katrina Cloki
So in the CTO role, I think the biggest challenge was joining the business where I had come from an extremely high growth environment. Like I just talked about that 2021 SaaS boom, massive hiring. You know, people saw the shift in behavior associated with COVID as something that would persist. And there was a lot of investment into like online tooling and digital solutions and people were, you know, hyped about it. And then coming into a business that is still a growing SaaS company, but not at the scale of growth that zero in particular had enjoyed. And the difference in challenge, like we sort of talked about earlier, where you put the guard rails because in a company that is aggressively growing, you have a much more open, the constraints are much more open because the growth is there and it enables a lot more mistakes and a lot more flexibility because the critique of decisions is perhaps not always there because there's an understanding that there's enough growth to support us if we choose wrong. In a company where there's growth, but it's more moderate, you have to feel a sense that, well, first you have to say no to more things and you have to feel a little bit more sure, not totally sure, because we still want to enable people to be growing and learning and failing. But you need to feel that little bit more sure that the thing you're choosing is going to have a good impact for the business because the cost of getting it wrong is higher, there's less margin for error. And I think that was the biggest challenge for me in the CTO role specifically was coming in. I thought I was operating in a similar environment to my GM role. And then I realized, oh, hang on, I need to fully understand the business metrics here better learn where my constraints sit and make sure that I'm leading within those constraints and I'm going to run technology in a way that enables the wider business to succeed.
- [37:54]
Vasco Duarte
Yeah, this understanding the constraints better like that, that is so important. Right. Because, you know, and that's something that I think everyone needs to understand is that all leaders have bosses too. Right? Leaders can't do what they want. They act within constraints that are either systemic culture and so on, or it is their responsibility to act within those, those constraints. Like, for example, you know, we Talked about the 60:40 split between strategic and business as usual capacity allocation. And I think that that's one of the things that is very hard to convey to many organizations where people are frustrated, they want change, they look up to leaders to bring that change. But then leaders are of course, constrained themselves and we develop, perhaps unwittingly, a little bit of a conflict, as if the leaders are against us. And I'm sure you felt that, right. How do you handle it when you feel that there's this animosity or disappointment in your role as a leader?
- [39:04]
Katrina Cloki
I find it is rare because I like to explain why the decision or guardrail exists. So I speak with my lead engineers about the performance of the business and the sales metrics, the conversion metrics, how people are adopting what our year on year growth looks like. They have a commercial awareness. That means that they understand why the technical guardrails exist. And that means they can understand the decision. The animosity is low because I'm very clear about why the decision has been made. I think the friction comes where people don't understand, where they believe they would have made a different decision in the same circumstance. That's frustrating. I remember being that person as an individual contributor, right? Where I thought, what a stupid decision. You should have done something else. What are you doing? And my reflection on that now as an executive leader is that I worked in organizations where transparency was low. And I didn't have the context and I also didn't have the trust that people who had the context were making the right decisions. So. And I think it's very difficult to build that trust if you can't be transparent, because then how do people know and have faith and confidence that you are making the correct call? So where I can, I do genuinely like to be transparent about why the decision was made in a particular way. And I think I make that choice often enough that where I can't be transparent, people tend to trust that the choice I'm making is a rational and good one because they've seen evidence of my decision making process in so many other situations.
- [41:30]
Vasco Duarte
That's a very good point. Right. Like if we are continuously transparent, in the rare cases where that's not possible, we will get the benefit of the doubt and therefore trust from the people we work with.
- [41:42]
Katrina Cloki
And I definitely have to say, on occasion, look, I can't actually explain this one. This is just how it is and how it's going to be. But most of the time you can, you know, you can help people understand why you're making the choices that you're making and it really removes the animosity and friction because it gives them the opportunity to learn and to understand why it's the right call. Yeah.
- [42:13]
Vasco Duarte
So we're getting close to the end, Katrina, but I wanted to ask you, as a CTO and perhaps now also as a ctpo, what was the book that most influenced you in your approach to the role?
- [42:25]
Katrina Cloki
Yeah, this was an interesting one for me. So I, I don't read that many books, to be super honest with you, but I have a bias towards women in technical leadership roles. I find the advice is more relevant to me and more actionable for me in my job. So the two that I would call out, Resilient Management by Lara Hogan. I still use her manager, Voltron, with my lead engineers especially to talk to them about how they can build a group of people who will mentor and foster them in their career. And the other one I like is the manager's path. Camille Fournier, I think is how you pronounce her surname. She has a book that details the different levels of role and how your responsibilities evolve and how you can then manage those shifting expectations. Both of those. I continue to refer to my leaders within my organization and to other people and have helped shape me to get the role. I've also, I actually have it right next to me. The Engineering Executives Primer by Will Larson. This wasn't one that got me into the role, but it's one that I think is useful now that I have it. It's been a book that I've sort of dipped into a couple of times. I'll read a little bit, you know, scan for something that resonates for a problem that I'm trying to solve today. And so I have it literally next to me on my desk as something I'll flick through if I'm tackling something tricky.
- [44:16]
Vasco Duarte
Absolutely. We'll put the link to those on the show notes so that people can easily find them. Katrina, it's been a pleasure to have you on the show. Thank you for sharing all of those stories with us. But if people want to reach out and connect with you, where could they go?
- [44:31]
Katrina Cloki
LinkedIn is now the only place I'm really active professionally. I used to be on Twitter. I think my account is still there, but I really don't use it anymore. So LinkedIn is the place.
- [44:43]
Vasco Duarte
Absolutely, and we'll put the link to that. Also on the show notes. Katrina, thank you very much for being with us and being so generous with your time and your knowledge.
- [44:52]
Katrina Cloki
No problem. Thanks for the invitation.
- [44:58]
Vasco Duarte
Oh boy, I bet you are buzzing with ideas after listening to this episode. I know I was. Now, there are so many ways we can help the leaders we work with, so I hope this episode helped you get some of those ideas going and getting inspired hopefully also to take action. That's what matters in the end. Don't forget that. Now, if you want to check out the key lessons from this episode, check out the show notes@scrummastertoolbox.org but for now, I'll say goodbye and see you in the next episode. We really hope you liked our show, and if you did, why not rate this podcast on Stitcher or itunes. Share this podcast and let other Scrum Masters know about this valuable resource for their work. Remember that sharing is caring.