In this episode we unpack the topic of: Do product leaders make good COO's? with Martyn Fagg, COO of Tillo and Matt Jones COO at ex-COO at ParentPay. 

Bethany and I discuss the following: 

• What does a good product leader look like? 
• What does a good product manager look like? 

We then discuss the following with Martyn and Matt: 

• How did the transition to COO happen?
• Was picking up the people function challenging? 
• How do you get the people function to be more data-driven? 
• How do you get product development and commercial to learn from each other? 
• What product development KPI should be included in the company dashboard?

References

• The Speed of Trust: The One Thing that Changes Everything 
• The Four Foundations of SaaS 

Biography: 

Martyn Fagg is a seasoned CTO with 20 years experience in software engineering and fintech leadership - passionate about fostering innovation, collaboration, and continuous learning. Currently COO at Tillo, a B2B embedded rewards & incentives platform working with some of the world’s top brands to deliver real-time digital gift & prepaid cards.

Matt Jones recently served as the Group Chief Operating Officer at ParentPay, a leading provider of payments and MIS solutions for schools in the UK and Europe. He joined the company in 2017 and initially held responsibility for Product Management, Software Engineering, IT, Service Operations, Customer Implementation, and Customer Support across several early Group businesses (ParentPay, Schoolcomms, Cypad, WIS, and nimbl). Additionally, Matt oversaw the group Security function, ensuring the protection of the company's and customers' data assets.

Prior to his tenure at ParentPay, Matt briefly served as COO at IRIS Software. He also spent six years as Senior Vice President of DevOps at NewVoiceMedia (acquired by Vonage) and held previous roles at Mimecast and MessageLabs (acquired by Symantec).

Summary: 

• Product development in CEO role with Twilio and Parent Pay leaders. 0:06
• Brandon and Bethany discuss their cultural heritage for a school event, with Brandon dressing as a tech bro from Silicon Valley and Bethany dressing as a Canadian with a hockey jersey and maple syrup.
• The hosts joke about stereotypes and cultural representations, with Brandon accidentally saying "boot" instead of "boot" and Bethany pointing it out.
• Brandon M. questions the importance of good product leadership, emphasizing the need for a clear product vision and strategy, as well as effective team building.
• Martin Fag, Matt Jones, and Brandon M. discuss the role of product development in the CEO role, with a focus on product leadership, strategy, and team building.
• Product leadership and CEO roles in tech companies. 4:50
• The CEO and product leader roles require different skills and perspectives, with the CEO focusing on the overall vision and strategy, and the product leader translating that vision into a tangible product.
• The product leader must be empowered to take ownership of the vision and make it a reality, while the CEO can evolve their role to focus on other aspects of the business.
• CEO and product leader have different visions for product strategy, leading to potential conflicts.
• Product management and leadership. 8:51
• Brandon M highlights the importance of product managers understanding users, market dynamics, and stakeholder management to ensure a product's success.
• Bethany agrees, noting that product managers often focus too much on technical details and not enough on validating with customers and stakeholders.
• Brandon M discusses Marty Kagan's philosophy of product development, emphasizing the importance of empowered teams with autonomy, resources, and scope to solve problem areas.
• Bethany agrees and adds that being given a problem to solve, rather than features to build, is crucial for product development teams to make a difference.
• Product management and CEO roles. 13:39
• Bethany and Brandon discuss the role of a good product person and CEO, with Bethany highlighting the importance of being able to pull oneself up and out of the weeds.
• Martin fell into the role of CEO as an opportunity after growing the company from six to 50 people and wanting a new challenge.
• Career progression from CTO to CEO. 16:12
• Matt Jones describes adaptability and willingness to take on new roles as key to his success as CEO.
• Leadership roles and responsibilities. 17:38
• Bethany shares her experience of being the only woman in a male-dominated leadership team and feeling like she's often overlooked or undervalued.
• Leadership roles and responsibilities. 18:56
• Martin, a former software developer and CTO, now CRO, has been managing people for 15 years and enjoys the people side of things, working closely with Briney, VP of people.
• Martin took on the people function as CRO, bringing a unique perspective as he has the largest proportion of the company reporting into him, and he works closely with the executive team to bring a commercial and business perspective.
• Managing people and teams in a cross-functional environment. 21:53
• Matt Jones highlights the importance of managing people as individuals, not just roles, in a cross-functional organization.
• Using data to inform people policies in a business setting. 23:18
• Matt Jones and Bethany discuss the importance of data in people policies, with Matt agreeing that data can provide insights into people's performance and wellbeing, while Bethany struggles with getting people teams to own and use accurate data.
• Both Matt and Bethany agree that there needs to be a clear owner of people data, such as a business ops team, to ensure accuracy and better decision-making.
• Data governance, culture, and retrospectives in a company. 26:22
• Martin emphasizes the importance of data-driven decision making in people operations, with a focus on employee happiness and retention rates.
• Brandon and Martin discuss the importance of collaboration and continuous learning within the product development team, with a focus on embedding retros and learning outside of product.
• Martin highlights the need for a champion within the team to drive initiatives and ensure ongoing adoption, with regular check-ins and feedback to gauge effectiveness.
• Using "5 Whys" to identify root causes of problems in business. 30:05
• Matt Jones shares his experience with using retrospectives to drive improvement in teams, emphasizing the importance of psychological safety and a simple five whys process.
• He faces challenges in implementing retrospectives across different functions and cultures, citing a lack of buy-in and psychological safety.
• Product-dev collaboration, agile methodologies, and software engineering. 32:19
• Bethany and Martin discuss the challenge of different departments within a company not sharing knowledge and resources, despite being in the same industry.
• Martin and Matt discuss the challenges of measuring productivity in software development, with a focus on the differences between short-term and long-term goals, and the need to prioritize creativity and outcomes over process productivity.
• Matt argues that software engineering is a creative undertaking, and that agile methodologies can help align development with personalities and produce better outputs by focusing on outcomes rather than in-process productivity.
• OKRs, product development metrics, and trust in the CFO-CEO relationship. 36:11
• Brandon M suggests cross-functional OKR teams can foster cross-pollination and inspire company-wide collaboration.
• Martin agrees on the importance of measuring developer productivity, citing deployment frequency and ticket turnaround time as key indicators.
• Martin emphasizes the importance of security and stability in a business, while Matt Jones stresses the need for speed and delegation of authority to achieve autonomy and purpose.
• Martin emphasizes the importance of transparency and earning trust from the CEO, citing his experience working with a founder who is hesitant to let go of their baby.
• Matt Jones highlights the need for a mature and open relationship between the CEO and CFO, allowing for flexibility and adaptability in navigating challenges.

Brandon M 0:06

Hello everyone and welcome to another episode of the operations room a podcast for Clos. I am Brandon Mensa joined by my lovely co host, Bethany Ayers. How are things going, Bethany?

Bethany 0:16

Pretty well, thanks. We had our equivalent of Roman day this morning. I don't know if you've ever watched Michael McIntyre. So there's a Michael McIntyre stand up moment where it's like 803. And his sudden goes, Oh, by the way, today's Roman day, I need to show up as a Roman. So we have the equivalent of today is Heritage Day, Culture Day, something like that at school, where he needs to show up dressed as something that represents

Brandon M 0:45

his culture. Okay, his culture, right being your culture. Yeah,

Bethany 0:50

exactly. And so, my husband Scottish. I'm American, right? We have 10 minutes to figure out what our culture is like, do I own a kilt? Like, no, no, you don't own a kilt. And we're not going to just magic up a kilt out of anything. So we went American, he ended up going to school with a St. Louis Cardinals baseball cap, because my family's originally from St. Louis, and Albuquerque t shirt, and jeans and trainers and a blazer. And I just like, Oh, you're just going as a tech bro. You're a Silicon Valley, entrepreneur.

Brandon M 1:26

So a tech bro from Silicon Valley. I love the niche orientation of this figure.

Bethany 1:31

And then he started to just like, do How would he partner? And I'm like, No, you're not from Texas. So if I can only do a Texas boy, yeah, he's a cowboy. Like, no. You're from California. Like how do people from California sound? Just neutral. And then we had to do a whole American accent thing for about 10 minutes over the last 10 minutes. Yeah, my

Brandon M 1:52

daughter for this exact same event. We basically put a hockey jersey on her, gave her a bottle of maple syrup and pushed her out the door. So that was our national heritage. And that case, you know, it feels a bit ridiculous because all you're doing is like alright, what do people know about Canadians? While they know a couple of things, they know that we love hockey, they know that we produce a lot of maple syrup. Here are the stereotypes of my country. And there you go. And you say a boot. And we say boots. Yes, yes. Yeah.

Bethany 2:19

Every time you say it, it makes me laugh because you just sound so American most of the time, and then you see in a boot and then I'm desperately trying not to point it out. Do I actually say that, by the way, every so often, like it's not as a boot. It's a boot. But there's like a there's a twinge. I also feel sorry for like the English Kids, what are they going to do? Show them bowler hats and umbrellas?

Brandon M 2:38

Yeah, if your heritage is UK heritage, I mean, how I was gonna say boring. It's not boring, obviously. But how creative can you get with that?

Bethany 2:44

Yeah, in your own school. And I was like, Well, you know, just wearing school uniform is pretty English for the rest of the world.

Brandon M 2:52

Bethany 4:50

So my first question is, what happens would your product leader or like the person who really has the strategy, the Vision is the CEO. And that happens a lot in tech businesses, because the CEO is the one who saw the idea in the first place knows the gap and spent the most time thinking about it. And so I think it was an interesting that you used understanding of the vision, understanding of the strategy, and not necessarily creator of the vision and creator of the strategy. Because I have also seen clashes when you have two visionaries. In the CEO and product role, you're

Brandon M 5:30

right, the founder has been the product person has been the visionary role, but the product, you know, it needs to look like and then so on your heart, that first legitimate product leader, that CEO has to be able to release the reins to that individual, they're releasing and empowering that product leader to take on that vision that the CEO had, and really make it come alive from that point going forward and taken on to its next journey. It's no different than any other function in the company, which is the CEO has to be in a position to delegate components, whether you know, it's a sales founder, or they're really good at sales, but they have to hire a VP of sales, in this case for the founders, fantastic and marketing. And as to hire marketing leaders, the same principle. I

Bethany 6:07

don't think I have any examples of where a product CEO has actually moved away from the product successfully. Because they just have such a depth of understanding of the market, that I think it's almost like another partnership that needs to be found. And often, the very visionary CEO, can't create a roadmap, can't think through the detail and need somebody to do that, but doesn't actually need somebody who can own the vision solver, somebody who can translate what's in their head into something that everybody else can do. Yeah,

Brandon M 6:44

I suppose. But I think that shortchanges what the product leader should be, I mean, I guess maybe I've had a different experience, it's very much that leader has to be empowered to take that vision to own that vision, and to make it come alive for the company and allow the CEO to evolve themselves in terms of what their what the CEO position should be in that case.

Bethany 7:01

I think so. And maybe it's also like a time element of like, you know, the time horizon elements. So because the CEO is still going to ultimately own the strategy and be thinking about the moves in the market, and may be thinking a couple years out, and have I think we're talking type tech businesses here where the product is the business and is the strategy. But maybe in the more short term, 12 to 18 months, or even six months out, like the product leader needs to be thinking about those areas of thinking like, you know, acquisitions, and mass changes in the market and getting ahead of the competition. I just have never worked with a CEO who isn't obsessed about thinking about those things all the time. And not so keen on letting go of it. Because that's what they do. And that is I think a lot of what their job is, at

Brandon M 7:56

Bethany 8:57

it's always hard have to keep letting go of things.

Brandon M 9:02

The second one was this question of? Do we have good product managers, and I have a very particular focus on this, given my background coming in. And the real question is, do the product managers actually understand their jobs? And in my view, there's four components to their jobs. The first one is, do they actually understand the users and or the customers on a qualitative level? So have they actually gone out to speak to customers? Have they actually gone out with user research folks to really understand the users if it's more of an end user product, in this case, we're maybe done both. And pulling that qualitative piece together in a very clear, crisp way from themselves. The second part is how the product is actually used. So this is more of the quantitative side of things when they get into the application, what are they doing? And then the third piece is the market dynamics. Do they really understand the dynamics around the product that they're focused on in this case? And then the last piece, most importantly, is the stakeholder management within the company and what the business is trying to achieve? Are they clearly shepherding the stakeholder? Does it ensure that the business is going to be satisfied with the direction of the product in this case? Is that what they're doing? Or are they doing something else?

I mean, what you're saying makes a lot of sense. Sounds reasonable, but I think I see a lot of product managers actually doing is, I don't even know what to call it like organising the roadmap and trimming stories and like getting really in the weeds and spending a lot of time with developers on the order of the buttons being developed, and not as much time validating with customers validating with the outside world or internally what's needed. But I guess you need to do both. So if the product manager is doing what I envision, which is what you've just laid out, then who does the what's there's a term for it, you'll

be paired in a triad with your product designer and your lead engineer, in this case, and between the three of them, they'll really be crafting that programme. And the question in those three individuals is how you parsing out the roles and responsibilities related to trimming the backlog or problem reports that are coming through or what have you. And the red flag to me is when you have product managers that are doing exactly what you just said, and they're not doing these other pieces, we have a problem, basically, and this is where I get concerned, I would say when it comes to businesses, and this is where it this kind of rolls up to that product leader doing their job, but also very much knowing what good looks like when it comes to product managers, and how best to ensure that the triad between those three individuals does what it needs to do to ensure that the product is built in a way that makes the most sense. Point number three that I wanted to talk through with you. Again, when I come into an organisation, I asked this third question, which is, do we have empowered teams, this is really this Marty Kagan, philosophy of product development, where you really want to have product development teams that are truly empowered to make a difference. And the empowerment in this case has three basic elements to it. It's not rocket science, but are they teams focused on problem areas? The second bit of it is, do we have all the tools that we need to solve this problem area? The tooling in this case, mostly is people do we have the right people in place to make it happen? And then the second question is, do we have the right tooling systems and processes to allow us to make it work as well. And this might be data related or what have you. And then the third piece of it is, do we have the appropriate scope or remit to respond to this this problem area, so of the room that is super small and tight, but the problem area is massive, that doesn't really make a lot of sense. So they have to be given a proper scope to really respond back to the problem areas where it's aligned in my case. So with that, Bethany, I'm just curious what you make of that makes sense.

I'm just trying to summarise it. So it's basically have the autonomy to make decisions or have the power to make decisions, have the resources that you need, and the right remit, so enough remit to solve the problem. And that's basically what's necessary, actually

spliced one thing into two, which was great, actually, which I forgot to mention. One is the being given a problem to solve, as opposed to, here's a bunch of features you need to build. And then the second slice of it is what you just said, actually, which is autonomy, which is a slightly different concept. And the autonomy in this case is being given every possible thing you can have from the organisation, to make yourselves autonomous, where you're not tied dependency wise to other things, essentially. Because once you start tethering that group to other teams, where you're dependent on Team B to produce something, or there's a dependency on data or this dependency on whatever, it's so much harder for the product development team to make a difference. So that is a good point. Last question I wanted to ask you was, and this is on a slightly different topic, but I'm curious what you think, why does a product person in particular make a good CEO? Do you think, possibly, because

we always talk about like a good product person is the CEO of their business. And what you're talking about is like the deep thinking, the collaboration, working across different areas, being able to go big picture and into the detail. And I think that actually going back to one of your original points of when can you see if you have a good product manager or a bad one is are they always in the weeds? Or can they pull themselves up, and that's obviously something that we need to be able to do as a CIO. That's what Charlene was talking about in her episode. This is what makes you a good CFO, and a good product manager, product leader.

So I agree with that completely. And I feel like in the CEO capacity for Sass companies in particular, I feel like this product inspired CEO, I think we're gonna see more of that going forward if I was to make a better prognostication for the future. And I think maybe just to wrap that piece of it. I think product people are phenomenal at identifying the highest value opportunity to solve and pulling together a team to solve it. And when you think about what a CEO does, it is very, very similar.

Hi, everyone, I am delighted to welcome Matt Jones and Martin fg to the podcast today. I thought it would might be nice to just give you a bit of background as to how I know both of these two fine gentleman, Matt and I worked together at new voice media 2010 to 2015. And so Martin and I have known each other for about, I don't know, two years, 18 months, two years, and have met each other in real life twice. But we did a great best of zoom friends. Which brings me into the first question that we have, which is, you both have product and development backgrounds? Did you decide to become CEOs? Or did it just happen? Martin, you want to get started on that one.

So for me, I kind of fell into it as an opportunity. It wasn't something that I had actively been considering as this sort of future plan for my career. I've always enjoyed the sort of engineering and product side of things and building. But as I've been tillow, for about five years, and I've grown from the company being six people in the room to where we are now with nine to five people and offices in America and Australia, I'd kind of wanted a new opposite new challenge, I guess. And it coincided with one of the two founders leaving the business, that other opportunities and moved on. A CFO at the time stepped into the CEO role. So I saw an opportunity, I thought I'd put myself forward for it and try a different challenge the next few years.

For me, it was more more of a survival move, actually, I was hired to be CTO for a leading UK software company. And while I was working my notice back in 2016 2017, newvoicemedia, they restructured and the role disappeared. So I spent the first few weeks in that position, defining a CIO role trying to get some support for it. That was my first CFO position, I found that the job apparent pay, took it primarily because it was still the same kind of remit across product and development and an operations. But it was it was slightly broader in that it had the customer functions in in terms of support, as well. And all of the it, I held them our CTO as well, because that challenge got significantly bigger through various acquisitions. And was the to be fair and recognising my own shortcomings as as not a software architect or a die hard technologist, that it made sense to get somebody in that would focus on that. And that allowed me to broaden my remit and pick up some other functions. I was often asked to adopt functions, and sometimes foster the mother's leadership changes. So that kind of adaptability and willingness I think to take on, sometimes the unknown, is what makes the CEO role interesting.

That reminds me of when we had our new chair at newvoicemedia. Gi Dubois, a man who's petrified me and is still in my nightmares. But in a good way, mostly. I think I have to say that, like definitely made me raise the bar. When we were first when he was meeting the exec team. And going through what all of our roles were and listed out everything that I did. He was like, Ah, you're Miss shit list. Yeah. And I feel as though like, COO was basically the official shitless job of everything that nobody else wants, and then you go and fix, and then get none of the glory for and somebody else takes it now after you've shaped it in a way. Martin, you're laughing? They're similar. And so I was curious. Actually, Brandon, this is a question as much for you, just for anybody who isn't aware of Brandon's background is also a product background. So I'm like the little odd man out in more than one way odd woman out what functions were you leading? And what about all of the actual like normal ops stuff, the CFO, the people, the Rev ops, did that end up sitting with you or not?

When I was CTO as engineering data, it or business it. And the operations team was already reporting to me. So we had this sort of Client Services, it just kind of when we were small, as software engineers are doing with the customer support, so they kind of it just kind of sat with me. And then I'll build out an operations team for the client services and onboarding. So I was already doing fairly operational side of the company. And then when I took on the CEO role, expanded, the main sort of official team I gained was the people team, but then just a broader remit across the company. In terms of finance, we already have a strong CFO in our business. We're fintech. We're processing hundreds of millions of pounds of card transactions a year. So it was important for us to have a strong finance function led by a CFO who's in that exec team, and he's runs legal as well. So it's sort of interesting to me, when I look at CEOs and different businesses, you see so many different mixes of responsibilities, I guess, coming from my background, it made sense to continue to own the engineering and that side of things and all of the ISO compliance and with a partnership with our CEO He's very sales, background, new business focus marketing, and on the product side, so we kind of complement each other quite well in that sort of mix of skills. Yeah,

maybe double click on to that one. So picking up the people function as a former software developer and technology person, it tends to be that technology, people aren't the best when it comes to the the people side of things. Can you kind of walk us through the evolution, I guess in terms of your misgivings, or anxiety heading into leaving that function, what ended up happening and how you've kind of come to the I was gonna say, come to terms with running people, but I guess really becoming a, maybe he loves it become a master and mastery of the people function as part of your portfolio.

I've been managing people for about 1516 years in my previous role as I started a company, a software engineer and progressed to Head of Development. And within the first few years, I was managing other developers. So I've always had that sort of people, people management side of things. And I enjoy the kind of one to ones and talking to people about what their challenges are, and trying to get the best out of them and help them progress and help them grow into managers themselves and leaders. And so I've always had an interest in that side of things. And I've always worked very closely with people team to life. And we've got Briney, who's our VP of people at tillow. And she she came on to manage that function, and was worth reporting to the previous era. But we work very closely together, and we have a very good working relationship. So when I came on a CRO, I hadn't really considered taking on the people function, particularly, I would say, coming to the people team with a different perspective, I have the sort of largest proportion of the company reporting into myself. So I've got sort of a unique perspective through that side of things. And then I work with our executive team and the, and I bought very closely so I bring that sort of more commercial and business perspective as well.

Yeah, I actually asked for the people function. I've been managing teams, people and teams since the late 90s. I've always had line management responsibilities since then, I've gotten better at it over the years. I think one of the things about coming from a product development background is, as I said earlier, you've got various parts of the kind of machine if you like, building and releasing, an operating software is very cross functional. And when you're leaving those functions, especially when they're all under your control, there's a really broad breadth of personality types in there, you know, without being, you know, archetypically prejudiced against people, there are lots of different innate personalities that do different roles within that lifecycle. So I think you get a pretty good sort of coverage of how different people operate. And it becomes a really interesting exercise, when you run the people function is you actually get a kind of Spyglass into what's going on not just in their roles, but in their lives. For me, that's key, you know, you have to be able to manage people as people rather than just as bums on seats. There is a kind of drama that plays out through an HR team, which you don't see in the rest of the business. And it's important that the business understands it. Because if you don't, then you end up in a position where you're not really attached to your people, so they're not really going to be attached to you. So

just wondering what you mean by the drama that runs through the people team and having the people team, I think you mean that people tend being detached from the rest of the business.

It's just the drama of everybody's lives, you know, people that get sick people that that drop dead, people that commit crimes, you know, people that raging because they're not being recognised. This whole kind of soap opera of people's lives is it's something which you don't really see directly from the top table. A lot of the time, there's some interesting insights in that. And that trauma, which, you know, businesses need to be aware of, sometimes there's circumstantial to do with to political, environmental things. Sometimes they're purely to do with your own culture and the way that you run your business.

Yeah, that's an interesting point. Because there's a few things first, like, because Matt, we work together, I know that you're very into your frameworks and patterns and not reinventing the wheel, but just finding like the right pattern that matches most of the wheel that's going on, which I could see with lends itself very well to data driven people policies, basically. Yeah. So it's like the combination of, of the data and the people. My experience working with people teams is they don't tend to be the most data literate or thinking that way. Because a lot of the time they're spent in the drama that you're talking about. And the reason why they've gone into people is for that emotional connection and making a difference individual lives rather than through the system. And this is one just to be open I struggled with because I'm also another very data driven person is like, not just getting them to think about the data, but getting them to own the data have accurate data. And then informed decisions through it. And I felt like it was a battle is not the right word like a bridge that kept breaking? How have both of you dealt with that? And were you able to build a bridge that stayed upright?

From my perspective? I totally agree. I think that the data, it can be captured, you know, there are metrics that you can use to gauge performance and general wellbeing and circumstances of people. I think there is a reluctance among some HR people that you can't really instrument human beings, and I understand that, but you can still access data, you can still provide and gauge and measure data about how people are performing how people are feeling, you know, that data can give you immediate snapshots of how people are performing, and it can give you insights into potential problems that certain people might have.

There's also like the accuracy in the custodian, like who's the custodian of accurate data. This is something that we talk about a lot on this on this podcast, because clearly data matters. It's like, who owns it? So in terms of people data, is it the people team? Is it a business ops team? Because you own both? Can you control it and have better and more accurate data?

Yeah, I think, for us, the ownership of data sits with the team that is responsible for that day to day. So we have recreated the data guild within our company, and have representatives from different teams, we don't currently have a people person sitting within that data guild team, but we have marketing and finance and engineering and product in there. But we still, as part of that process, the data guild have created this data governance sort of framework where we've defined all of our data sources and owners within the business for each of those. So the VP of people owns any data related to that function. And we have these kind of typical metrics, where we're tracking employee happiness ratings, and we've kind of shifted our employee surveys towards more quantitative metrics that we can track those over time, it'll be easier. And I think in terms of introducing the people team into that more data driven rigour, it's been about trying to introduce it slowly and not try and just lump a whole load of KPIs on in one go.

What are the couple of metrics you'd recommend? So for us, we have one,

that sort of employee happiness, which we're recording on a quarterly basis, we don't be asking the team to fill in questionnaires too often. And then another key one is the sort of retention rates, which we were doing at a company level, and we're starting to move that down to an individual team level.

Martin, maybe a broader question for you, which is, what do you think about good culture within the company? Do you think there's any actual difference between good culture for the product development side of the company versus the rest of the company? Do you think it's the same thing? Or do you think there's anything special the product development side that's noteworthy in terms of delta or GAAP,

from a product point of view and development point of view, the team's they're very used to working collaboratively and problem solving and trying to make things better. And I think if you look at some other teams, they can be more used to just getting things done, and not necessarily trying to change or improve processes over time. Having that sort of culture within the product and engineering teams have collaboration, of problem solving, and trying to demonstrate that outside of the team to the rest of the company has been useful. So as a sort of a related example, our engineers will go to conference, and they come back and they present that to the rest of their team and what they've learned. And we've started showing that within our all hands meeting with the whole company, so that they can see that kind of continuous learning and improvement process that they're working towards, and how they then use that to change the way they're working. And we're trying to encourage that within other areas of the business as well. So, you know, it might be there's a finance conference or a marketing conference on SEO, we had recently one of our team, in the marketing team, were there and they could bring back those learnings and just try to encourage that same behaviour outside of the engineering team and really embed that into other areas as well.

How do you do that? Because I've tried, I've tried to embed retros and learning outside of product because I see it in product I haven't like oh, look at this, look at this, like rhythm of the week and this lovely schedule. And every Friday, everybody does a retro and like, okay, sales team, let's do this. And like one and a half weeks later, none of it, it's all died.

I think it's finding a champion in that team, when you're kind of driving any initiative in that team where you're trying to change behaviour, trying to get somebody on side early on, who can really be that champion on on the ground, because a CFO, you can't be in all of their meetings all the time. You might go to the first few weeks and try and encourage it and demonstrate it but you need somebody who's then going to own it and whether that's the head of that team or somebody just within that team who's being that champion, I think working closely with them to really push it on an ongoing basis is necessary and checking in on it on a regular basis as well. And maybe just being over to their feedback as to whether it is genuinely useful, are they finding value from it or not? Yeah, and

I've had similar problems as Beth and trying to broaden it. And newvoicemedia, the team that I worked with there, we went through some, some pretty toward stability issues, and some enforced kind of stability drives, which were horribly unpopular. But the team that the leadership team that that I worked with there, began to get much more sort of automatic around retrospectives using a very simple five why's process. And that became habitual, it became part of the fabric of that team. And every time somebody stubbed their toe, there'd be a five why's and a whole stream of actions coming out of it, which needed quite keen prioritisation, but it was, it was good at driving improvement. And it did a really good job of making teens empowered to solve these problems in a way that they wanted to, rather than being told by the brass to do it. And that was that was much more effective at getting things moving and getting things stable. And I've used that subsequently. And it is a kind of serious tool in my toolbox now for every function. So I have tried to get that working in other places. But I think there's a bit of a kind of tribe mismatch when it comes to developers versus the rest of the business. And if there's data and they can get value from that data, then they're much more inclined to use it. I think it's, it's been more challenging for other functions to sit around the table and say, Well, what went wrong? How did we fuck that up? And how did how do we fix it, so we don't fuck it up again, in the future, is a cultural aspect, which is quite difficult to promulgate around the whole business, especially when you've got different personality types who are, may not be hitting a number in sales, and they're feeling pretty bad about it. And they're imposters looming large and they're beating themselves up on a regular basis, the last thing you want to do is sit through a meeting and raked over the coals of performance, you know, it's not ideal. So it has to be done within the context of psychological safety. Unfortunately, that's just not ubiquitous across all businesses, you know, it's this kind of thing I'd like to try and generate from the top down, that components seems to be the barrier to allowing these things to happen where people don't feel the blame. And actually, if you boil things down to what went wrong, it's usually a failing of process, rather than a willful failing of people.

I think it's also like, it's interesting, how little from product has jumped the gap into commercial. And it's like, there's just kind of two languages, two sets of information that you learn. So as a CRO, or, you know, cmo as somebody coming up on the commercial side, like the SAS metrics, Sastre, we all speak the same sales language, it's a process, these are the KPIs that you're looking at. And then on the product and development side, there is the same set of resources, I don't know what they're called, because I'm not on that side, but like, agile and how to do it, and retros. And I guess it's like all of the rituals around agile. And so all of the tech leaders read all of that stuff. And for whatever reason, people not like switching over and reading and cross pollinating, even though you're in the same business, and you kind of hear stuff on the other side. And then I think as a leader, you're not very comfortable to really implement it, because you only know the surface level of hearing what somebody else in your team has talked about, like me going, I think it's a ritual, but maybe it's not. And then, without like, deeply inhabiting it, you just don't use it. And I bet there's stuff within like the SAS sales and marketing world, that would be super helpful and Dev, but I bet you guys probably like without a lot of effort, don't know a lot about it, either. It is

hard to get different functions working together collaboratively to learn from each other, I think they just see themselves as so different. And that they are being measured in such different ways, you know, your CRO, or commercial team are being measured very firmly on that sort of financial results on new deals in the pipeline, and can have such a short term focus on this month, and getting things done now that they're very focused on delivering in the short term, and less so on the kind of longer range whereas a product person might be thinking more 12 months ahead, what does my roadmap look like, I know I can only get so much done this month, I need to plan out for the long term. So maybe there's that sort of disconnect in that sort of long range versus short range kind of functions as well.

There's also kind of misunderstanding around certainly software engineering, in terms of what it actually is. It's not a mechanical engineering thing. It's not a we're going to build a tool that's got these exact dimensions and we will be able to validate it perfectly when it comes out of the factory. Software Engineers is intrinsically a creative undertaking, and people don't tend to realise that then For me, in trying to get development organisations to be as productive as possible, it's about enabling that context for them where they can be creative, and sit down and think about the things that they need to be doing. And it's much more akin to an artist or a designer than it is to an engineer. But because there's software engineers, they kind of get mislabeled, I think, in the consciousness of senior management. And, you know, that whole problem is evidenced in how developer productivity is tracked. And, you know, it's it's the Holy Grail of data, which is how do we know our engineers are doing what we need them to? My feeling is, is that the way agile works, in my opinion is they do something they step back and they look at it, they do something else, they step back, and they look at it. And you can imagine any famous painter doing exactly the same thing, they go right into the detail, and then they step back. And so how does that look? That's what Agile tends to be more aligned with development, personalities, and it tends to get better outputs. And I think, you know, what you're looking at there is you produce something that gets released, and then you look at what the results are. And I think that's how we need to look at software engineering, look at the outputs and the outcomes that you're getting rather than the in process productivity.

Right. Yeah. And I think there's two things that have popped in my head. One is on the collaboration front, across product development, and the rest of the company in particular sales and marketing. I think what's been very useful to me in the past is cross functional teams that come together as an OKR team to respond back to company challenges. Because when you get that OKR team put together and you have a business person or you have a salesperson, rather you have a marketing person, you have some product developers, you got a product manager and so on, they have to figure out together as a unit, how are they going to operate cross functionally, what kind of meetings are they going to have? How are they going to run? What kind of retros? Are they going to do? What's the cadence going to look like a little bit. And when you have that mash up, and you have those types of discussions, this is where the cross pollination really starts to happen. And I think the learnings that came out of that OKR, cross functional format really inspired me as the CFO to really try to leverage that across the entire company going forward at that point. And I think the second point is to what you just said, Matt, and this kind of dovetails into the next question here, which is, is there any legitimate product development metrics or KPIs that should be in that company level dashboard, to your point, that my last company, the CTO, I worked there, he felt that having Dora metrics on the release velocity was the single KPI or metric that he felt at the company level would be useful. And I guess my question back to you, Matt, into Martin is, what do you think? Is there a legitimacy for company KPIs to include product development?

Yeah, it's definitely a tricky area, and it's one that we've iterated on over the last few years, it can be very hard to measure developer productivity. And I think you'll CTOs, former CTOs approach of door metrics, or release cycles is a key one, the deployment frequency is a great indicator of the maturity of the team and the platform. So if you're able to release multiple times a day or once a day, that's a really good sign. If you are taking every other week or every other month, that's not a good sign that your platform is stable and able to be iterated on quickly. And another one I like is the length of time it takes for a ticket or a job to be raised to when it hits production. If you've got a nice short cycle time, it's good indicator, they've kind of maturity of the team that they can get things out the door fairly quickly. Although you met,

I talked about the four foundations of SAS. And it's kind of not just SAS orientated, but it's where I've come from. So for me, the security is the first directive in every business that I've worked in, I've always held that as the prime, you mustn't not invest or underestimate how important security is. Because if you've got a business and it's not secure, someone can take it away from you like that. So the kind of security maturity level is key, something that we've reported on routinely reporting on routinely through the various functions that I've had, then you come down to stability, which is your availability metrics, your five and three nines or five nines, your two nines, or your no nines if you're in serious trouble. That's important. And I think it's kind of overall view of health. And then how quickly you can scale, you know, can you actually provide a platform and a context that is adequate for the kind of sales pipeline that you've got? So can you actually scale it? And then the last one is speed. And that all comes down to developer optimization and the kind of maturity level that Martin was talking about? How quickly can you get product to market, but it's broader than that as well. I mean, speed really is a function of, of trust, proper delegation, well, working delegation of authority, if you've got everything that needs to go back up to the top team before you can actually make any decisions, then you're just going to literally grind slowly with sparks and trying to get things done. I've always been an advocate. And I've always tried to build Daniel Pink's kind of three pillars of autonomy, mastery and purpose. So the more autonomy you give to people, when they come and tell you what they're going to do, or they come to you with decisions ready to be made. Here's how I've got my teams to work a, they put the work in B, they then own the work because it's their work. And see if it gets approved, they get the satisfaction of having done it, that helps everything move quicker. I think Stephen Covey's book The Speed of Trust, it's well worth listening to. And it's a great manual for how to clog up a business by removing trust.

So trust, this is something that we talked about in a recent episode on the relationship between the CFO and the CEO, and being trusted by your CEO. And what do you do? Often founder see Aeos, where it's their baby, and letting go and trusting anybody else with their baby is really difficult. Have you had that challenge? And if you have, how have you dealt with it?

I think transparency is important, keeping people informed, keeping the CEO up to date, so they know what's happening, and don't feel like they've lost all control. I work with a founder, CEO and his his baby, this company that we've grown, and it's important for him to know that things are happening, things are being delivered, that is seeing the results. So earning that trust through delivering, it's important. From

my side, I've not worked with many founding CEOs, I've usually entered businesses, as they've stepped back with it with a new team. For me, I think trust between the CEO and the CFO is pretty important. Personally, I've always vetted the CEOs that I've decided to go and work for. I've either either known them previously, or I've spent time getting to know them before I take the job. But that doesn't necessarily protect you, because CEOs are dispensable, or they opt out or disappear for you know, for no apparent reason, on occasion, better thing, you can probably remember that you have to pick up the pieces. So you have to do what's right, you have to do the right thing next. So what's the most important post correct thing to be doing at any given point. And even if that's off the plan, you have to be able to go and have a conversation with the CEO and say, Look, we're doing this differently, we change the order, we're going to scrap this and do this instead, because it makes sense to do it. So you have to have a relationship that is mature enough and open enough that you can have those conversations because, you know, plans or plans and not in fact, and ultimately, holding everyone to a plan that doesn't make any sense is futile. And the CEOs role is to have those gnarly conversations, I think, which is when things are when wheels are coming off trains and ships hitting the fan. It's about explaining what's going on how we're going to navigate that challenge. And quite often it is just a case of dealing with it and going through it. And I think that kind of level of resilience and grit is another CEO coo attribute which is you know, not necessarily present in every other C suite position. Ladder.

So that's a wonderful way to finish up the podcast. So thank you Martin and Mac for joining us. And if you like what you hear on the operations room, please subscribe or leave us a comment and we'll see you next week.