From Individual Contributor to CTO: Chris Bertram's Leadership Journey

One of the things I thought would be quite different would be moving into a role that as well as having technical leadership would also have people leadership because previously I wasn't individual contributor and now I'm moving into becoming a people leader as well. I thought that that may be an area I was weakened and that is something that I'd have to focus or concentrate on. To my surprise it actually flowed quite well because a lot of the same techniques that I'd used as an individual contributor to engage with people to motivate them to show them what good looks like as an individual contributor those skills were transferable into or the direct people management side of a business as well. Introducing agile and product management ideas into a business was a time of change so we started to say no to things we can say actually it's okay we don't have to build everything that my customer asks for. If we've got one customer who says they want the product to do this but we don't see other customers who are lining up to purchase the same thing. Hey there's not actually build this it doesn't make sense for us. If you can build shared understanding with the team at the beginning of his sprint or even at the beginning of a quarter when you're doing your quarterly planning. Yeah. It's so important that what I've found is that shared understanding at a point in time is great but what I've found is that information and shared understanding starts to break down and it degrades over time and distance. Welcome to the TechWacker podcast where we dive into the journeys of New Zealand's top tech leaders. Your host for today is Jakob bringing you conversations with tech leaders and innovators from across our Tearoa. Join us as we uncover the experiences, challenges and successes that shape our tech community. Hello everyone. Welcome to another inspiring episode of the TechWacker podcast. Today we are diving into the remarkable journey of Chris Bertram the city of UZIT. Chris shares his transition from nearly two decades as a technical leader in the tech industry to embracing people leadership role in a new industry. We will explore how he adapted his skills, navigated organizational change and embraced agile and product management principles to drive innovation. Whether you're an aspiring city or a city tech leader, this episode is part of insights to help you on your own leadership journey. Hi Chris. How are you? Hey I'm doing great. Thanks Jakob. How about yourself? You're very good. You're a city at Fuse IT and you're quite new to that role aren't you? Yes I've been there six months. I would love to explore that experience of being in a new role, a city or role for six months but before we do that could you give our listeners a bit of overview of your career thus far? Yeah I'd love to. So I started before Fuse IT. I was at a company called GenTrack for a very long time. I think I was there for over 18 years before I decided to move on. So this is a little bit different to when I talk or listen to other people's career stories and that a lot of my career or all my career development was done inside the same business. So what that kind of looked like was as a fresh graduate out of university when I applied for a job and got to that GenTrack and back in those days I think we were all called analyst programmers and those were very much hands-on coding, understanding requirements from a customer and delivering to that and I started off delivering professional services to customers and GenTrack for those who don't know work with utility companies so those energy companies for electricity and gas as well as water companies and they deliver the billing and utility information solutions for those customers. And so what I found pretty quickly when I was in the role was that the industry itself was actually quite interesting and so what I found as the longer I spent there the more kind of comfortable I became working with the customers and understanding the challenges that they were going through and it was one of those cases where everyone in the industry were running into the same problems and so as I was going through my different roles and as I progressed to more of an intermediate role and a senior role I became quite comfortable having conversations with customers, I spent time as well as doing professional services focusing more on research and development and building the core products that we would then tailor make to different customers so because it was very much a business to business environment I would often be a lot of customization or configuration to the product and so I would spend time building a product and then I'd spend time implementing it or helping other teams to employ into with customers and I think one of the things I liked about it was I was always able to see the changes that I made and how it impacted those businesses so you could actually see the difference that the software was being made in the ground. I always get a bit of a buzz when I was walking around the customers call centres who are using our software or talking to the billing team who talked about how they were able to improve the cash flow situation by being able to invoice earlier in a month because of our software so that was what motivated me and kept me there as I move through changes new technologies came along and new ways of working came along and I started to work in delivering our products which were more SaaS-based or cloud-focused products and I learned a lot from that as well and started to lead teams technically not in the people leadership team but definitely in terms of a technical leadership team for those. I moved through to becoming a principle engineer and as an individual contributor I got to work with a lot of different teams across company. We had teams in New Zealand and Australia and the UK. We even had professional services team coming on board in India just before I decided to resign. So that was a little bit of my progression there which was slow bit steady and always loved getting involved in solving the customer problems. Wow. I want to go back to some of these experiences in a minute but before we do I think it's really interesting to talk about your current or because you had this 16 or 18 years of experience a gen truck and then to resign and you moved to a new role. New industry I guess very new role and not longer an individual contributor moving to an executive team. How did you find that? Well after 18 years of utilities I decided I you know we're interested to explore some new industries and fuse IT is quite different instead of coming from GenTrack which was working inside a single industry vertical. Fuse IT works across many industries in a horizontal market play. So the focus is on the customer relationship management systems, the CRM systems and connecting those to other parts of the enterprise systems. So whether that's connecting it to a website to boost digital engagement and website personalisation or whether that's connecting it to your electronic document and record management systems it's focusing on building those platforms which can then be tailor-made into different verticals. So that intrigued me that made me interesting in that role there because it was quite a change in terms of industry for me. But kind of the other change that I saw was moving from a medium-sized business in terms of GenTrack with hundreds of employees down to a much smaller company with less than 20 was a big change for me. I really appreciate the change in size and scale that goes along with that you're able to have a much more personal connections with everybody in the team and that was really one of the key things. One of the key things I also found when joining a new business was that I'd found I had become super comfortable where I was before I left. If you spend 18 years you know where everything is you know where the The skeletons appeared. you know who to talk to in the business when you need to know something. Moving into a new business, you don't have that and it takes time to build a bit of that knowledge. I found the way that I really grew in that space when I joined the company as I spent a lot of time talking to the staff members who had been there before me, but also talking to people who used our products or used our professional services because that helped me to build a lot of the contexts that I needed to start making decisions. I can see how some of the experiences you had from GenTrack, how you had to work with your customers, you know, most daily how you had to understand their needs, how you had to empathize with them. I think that translates quite well into people leadership. I completely agree. Yeah. And maybe before we go back to GenTrack, one more question around the CTO role. What did you find in the recruitment process or interview process for a CTO role? If someone is maybe now applying for a role like this, what would be some of the things that you would expect that may happen or a question that might be asked in an interview process? Obviously the questions that I would have been asked as a principal engineer at Commitio CTO would be quite different in terms of less focused on technical skills or architecture skills and more focused around understanding product, strategy, operational aspects. And what I found was in terms of the questions that get asked. There's less right or wrong answers. It's more about how well do you fit? And you'll get asked a question and then there'll be a follow-up question and then there'll be another follow-up question. And it's really that kind of third or fourth follow-up question where they actually are really trying to get down to understand who you are and what you bring. So I think the thing is, questions will be varied, questions will be deep. And there isn't necessarily a right or wrong answer for those. You're just going to have to see and try to understand how you can add value to the business. One of the things that I did when I was being interviewed was fuse IT is based in Nelson and I'm based in Auckland. So it was really important for me to spend some time down in Nelson in the office for face-to-face talking to the other members of the executive as well as talk to the board members as well. But actually talking to the people on the ground who I would be working with in the future as well. So I felt it was important to get to know the people in the engineering team. It was fortunate to get to know the executive assistant who was helping organise travel and all those types of things. I think it was quite important to actually get a sense of a feel of how they treat people. Because at the end of a day, that's the most important thing. You need to make sure that you're working with these people day in and day out. You're beside them in the challenges and you're beside them in the celebrations. So it's really important in my view to get an understanding of who the people are. And the interview works both ways. They're trying to find out about me and I'm trying to find out about them as well. I couldn't agree more. I think you read that the people aspect is so important both ways because yeah, they're going to be hopefully moments when we celebrate and hopefully there's going to be more of those moments. But there will be moments when things go wrong. Either the market shifts or there's an incident or there's a bridge and how we react in those moments, how we can work together in those moments and rely on those foundations of common values, trust. I think that's where the magic happens. Absolutely. And what I was very impressed was when I first joined, within the first two to three months, we actually ran an exercise of everyone in the company, which is easy to do when you're a smaller company, right? When we went through and we did an HBDI assessment, which is where they look at how your personality or your brain reacts in certain situations. And so that helps you to understand am I the type of person who is an analytical thinker, am I the type of person who is very creative? Am I a people person? And you're not necessarily only going to be one or the other, but you kind of land in a range of those and you have something you're generally more strong on, stopping you less. And then they look at how that works when you're under stress and how it changes. So I may find that when I'm under stress that I become more introverted, I try to solve everything. I try to take work off other people and do it myself because I believe that's a way to get things done, which isn't always helpful. And so what they did by running the exercise together as a team, we're able to look at understand how we complement each other and how we work together. And we share these with other people so that we can understand and lean in on people. So you can say, "Hey, today I'm stressed. This means I'm more likely to do this kind of behaviour. If you see me do it, can you help me out?" And so I think that was really valuable to do. And again, that's how people work well together. Let's go back to your gentrack experience because that's almost 20 years. I wonder in our industry, we often change jobs after three years, two years, I think, every few years that the duration is actually shorter and shorter. What kept you going? What kept your fire burning a gentrack? The thing that kept me going the longest was for people. Again, coming back to people, it had an absolutely fantastic group of people that I worked with. Locally inside New Zealand, but also in Australia and the UK, I've had, you know, when you work with someone for almost 20 years, you have a lot of trust and faith. You know that you can rely on people. And that means that you feel comfortable taking risks or putting blind trust in someone to back you up on things, which is very, very important. The other thing that kept me going was for learning, always wanting to learn something new. And I had that in the form of the industry because the industry was always evolving. And even now, the industries continue to evolve. If you look at the rise of solar on rooftops, on electric vehicles, on distributed power stations from communities, pooling their energy together into local battery storage, there's all kinds of innovations happening in the industry. Each market that you go in and work with a customer with it would have very different needs. And operate differently. Some of these markets were regulated markets. And some of them were deregulated whether it was competition. And so going into each of those markets and learning about them was also very interesting. Yeah, those were the key things that kept me going all that time, always something new to learn and always people that I enjoyed working with. We often actually avoid change. It seems like something you embraced, which I think is quite unique in this industry. Yeah. So there was change in me industry and there was change in technology. When I first started working, it was common for doing B2B software. You had often built a product and then a customer would license it, they'd take it, install it on their own server, sitting in their office or data center, and then they'd run it. And then as time has gone on, SaaS software became the driving force in the market and everyone was looking on the best way to do SaaS. And we were looking at the best way to do SaaS as well. It took us a while to figure out. It's a journey that never finishes right. I SaaS products, you never finish the product, you keep building it and you keep building it. And parts of it may fade away because they no longer required by the industry and then there's new things to build. So it's also part of it. So understanding the life cycle of products is interesting as well. So for example, we had an older product which was used to take data that was being collected from electricity meters. And you'd receive data coming from these meters and they record a data point for every time interval, whether that was half an hour or 15 minutes or five minutes. And so that was very large volumes of data when you think about millions of meters that are out there in the world. And it was a problem that we solved originally through technology. We had a solution, where we would store those values in a database and when it came time to build the customer, you would put the biggest processor you could on it and it would chug away for hours or days until all the computations were complete. And we found that that was expected in a normal at the time. But as technology has evolved, there came a point where that wasn't really good enough anymore. It wasn't okay to have this system sitting there that would just process and do a lot of computation over and over. So that's when we had to look at other approaches, other technologies that we could integrate to be existing technology as well. So that's when there was a bit of a transition to starting to build cloud native products and cloud native services. Moving away from a big monolithic product that had spent 30 plus years of development and moving into smaller, more composable services that teams could work on. Instead of having to have a big team that would understand a really big product, you could have smaller teams that could understand parts of that product and you could put them into composable services and make them work together. And that took us a few years to kind of figure out how to do that at scale. Because we started off doing it as a bit of a light house project. We had a team who was building the cloud native services. We decided to go all in on serverless. We didn't have dedicated database administrators. We didn't have dedicated cloud infrastructure experts or a small team. So we focused on building the product and didn't focus on building the underlying infrastructure. We built new products in this manner. The metadata example I gave you before with all of the different electricity meters, we were able to scale that much more as a cloud native product than we ever could have in a monolithic traditional application server. That was something which was very instrumental because it proved that we could take the industry knowledge that was so important and apply it to new technology, new ways of working. We moved into a team which was you build it, you run it on a small business domain. And it worked and there were challenges along the way in getting it to work. And as it's matured, the support model had to change because you build it, you run it, meant that we spent more time running it than building new things. So you had to look at how you then transitioned to take people who had built up the experience and working with the modern technology and use that to seed new teams. And have those new teams start to build it and look at how as one of those composable services, matured, moves on to a different part of a product life cycle, you have different teams looking after that and different ways of working. And if you look at, we started in early 2000s and that's when Agile was starting overseas and 2001 I think Agile manifested came out. I'm guessing that there was quite a lot of these movements coming to GenTrak like Agile product management or product life teams and maybe tinterpologies or DevOps. And other things that came through. Yes. Any of those times that you kind of go back to and you think it was either especially challenging or especially exciting or maybe both. I'll actually go back to a time when one of your other guests you interviewed recently, Jan Sparance, when he joined the CTO. I was working as a senior engineer at the time. Jan joined as the CTO. And within the product development or R&D side of a business, we were relatively small compared to the professional services side of a business. So we would build the product and then the professional services side of a business would implement that for customers. And we weren't strictly following Agile manifesto before Jan's joined. And when he joined, he realized that we could probably benefit from adopting some of it. And so we went through a process of bringing on board some of the standard practices, sprint planning and retrospectives. We started to hire product managers up until that point. We had been a very engineering lead organization. It had been that engineers who decided what features to build or what was the highest priority or being, I'd say, engineering lead but also sales lead as well. So we would follow where the sales were happening. If we were going to win a big deal in a particular market, then that's where engineering time would go. So it was a bit of a focus of sales, lead development and engineering, lead development. Introducing Agile and product management ideas into the business was a time of change. So we started to say no to things. We said, actually, it's okay, we don't have to build everything that my customer asks for. If we've got one customer who says they want the product to do this, but we don't see other customers who are lining up to purchase the same thing. Hey, there's not actually build this. It doesn't make sense for us. So I really enjoyed that transition period. It was coming back to something that motivated me was learning. And learning some of those product techniques as well was definitely an area of growth for me. Up to that point, I would have considered myself very much a traditional engineer, but that was kind of a bit of a tipping point where I started to think of myself more of as a product engineer or someone who would work alongside a product manager and product owner in a product team and start to deliver products that were probably a bit more fit for market and being able to do more with less. So making a bit of a smarter investment on some of those choices. I love that because I often think when I think about the engineers or engineering is a domain of solving problems and now the question is what problems that we solve do we decide to be engineering, let and solve engineering problems or technology problems or are we moving to being customer focus? We have customer who at the end of the day, they need to choose to pay for our product or our services. They have other things they could purchase, but they're deciding to pay us. So I think that's a big change of what problems are we solving. What's the next shiny thing or are we solving? The real important customer problems, even though sometimes we may need to accumulate some that they can call that or we will not play with the newest tech, but we do solve real problems. Yes, and understanding the customer and not just doing what they've asked for, but actually understanding the context of a problem they're trying to solve and solving for that, that is very powerful. Yes, and I think that's where the real good product management comes in when they can extrapolate for a number of customers and from the market the actual needs and the actual problems and then we can find new ways to solve those problems. Often you know that customers didn't know that that was possible or that was they needed. So I think that's where the magic of having product management, we've designed, we've engineering three disciplines just working together or trying to solve problems for customers. Taking that product approach and I like how you talk about that free coming together as one. I always like to think about other things as well. So I think that gives you a really stable core and then I like to think about okay so what else can we wrap around this core. How do we tell the customer, so we've built the best product. How do we now get that in the hands of a customer and helping them understand that? So it comes down to your training right and how your delivery methods. There are some delivery methods like SAS where it's easier to deliver new things. There's other methods where it's much harder. If you have to convince a customer to take an upgrade before they can try something new, that's really hard work. The other thing I like to think about is like the marketing of that as well. So how do you let people know that you've built something that they need that will actually make sense for them in their business context. So I always try to think about when I'm building something I actually think about when this hits the market, how am I going to explain it to a customer. Something that I've seen done at the likes of Amazon is where they have their PR FAQ or their press release frequently asked questions where before they really even build something they're thinking about what is the press release going to look like for this new thing I'm building and that helps to build understanding within the business about what are the problems this thing is going to solve. And it can also be used for when you're the having those customer conversations and you can start to validate what you're going to build with a customer. You can say, hey, we're considering this. Is that something that is actually going to move the dial in your business? And you can start to gauge excitement and buy in from customers, isn't that? So yeah, so that's something that I find interesting as well. I love this practice of press release. I think it helps you to really clarify what you're going to build and also why you're going to build it and as you said, how it's going to be used in the past when I was coaching teams. Many teams I found would struggle with sprint goals. I think that was often misunderstood practice so that they wouldn't do that. And I would encourage them to think if you are at the end of a sprint, hopefully you're going to release it, what would be the press release for that sprint? And that often creates a lot of interesting discussions. how are we going to frame and how do you slice the work that something that's going to add value. And of course, there is never that easy, but I think that's a good conversation starter for teams. And as you said, that's also often a good possibility to validate or invalidate your ideas, because that's how your customers react to that. Of course, until they actually sat paying for that, you don't really have full confirmation from them, because that's a different conversation when someone needs to pay for that. But I think if you can get some initial feedback on your paper prototype or your press release or whatever else that you can create in a simpler way and cost effective way, it's often much better than going and building it for month to month, half a year, and then learning, oh, actually nobody wants that. Absolutely. It's not solving the right problem or it's solving the right problem, but not in the right way. Early validation is key there. One of the things I liked from that is understanding and building shared understanding. So if you can build shared understanding with the team at the beginning of a sprint or even at the beginning of a quarter when you're doing your quarterly planning, yeah, it's so important. What I've found is that shared understanding at a point in time is great, but what I found is that information and shared understanding starts to break down and it degrades over time and distance. And what I found is that I would wonder why people in the other officers that had worked with in different time zones would sometimes struggle with if something would be delivered and they said, oh, I don't know about that. However, people around the team that was building it would know what was going on because they were there, they were hearing it all the time, they were seeing it back in the day before everybody started to work remotely and we just had big whiteboards of sticky, people could see the progress. So really, it's very important, I believe, to build that shared understanding and then keep reinforcing it, keep saying what you're doing. Even if the other person has heard it before, it's okay because it may need a refresher. Don't assume just because you've told someone something once that they'll take the same understanding away that you did. And so it's really important to keep reiterating on that. It's something that I've noticed over the years that I've seen executives fall into a trap of, they will come along and they will give an outstanding presentation about company strategy, about the mission and the vision and where we're going and everyone is enthused about it. But then you may not see as a developer, you may not see that executive for months or maybe not for another year. They may not be in the same side of a world as you. So it is important to keep reiterating it or have people who can talk to the development teams to keep reiterating it. And it's not just for development teams. It's a commercial team. It's all of the people who are involved in delivering product to customers. Very true. And I think it goes back to, I think it was in the 50th discipline book by Peter Sange when he talks about different mental models that we have these filters and mental models. What we hear one thing, but we actually make it something else in our mind. So there's no one reality. There are billions of realities because everyone of us see things through our mental models. So even though you as a CTO, you may present something. If you have 100 people in the room or on a call, they will have 100 understanding of what you just said. And hopefully they're going to be aligned or they're going to have common cards that's going to be good enough. But as you said, they will look through the perspective of their role, through the perspective of history in the company, from the perspective of history in previous companies, through conflict in their team, through their alliance of their product manager, like all of this will influence how they hear and what they see and what they remember and what decisions they're going to make today. Absolutely. And I've felt that on both sides, right? I've felt that as somebody presenting to the room and I felt that as someone in the room. Yeah. Yeah. One of the things that I try to do in my practice is when I'm introducing concepts or plans is that I like to present it and then I like to write it and then share that asynchronously with people and try to collect feedback and ask questions of people to kind of gauge their understanding or get them to play it back to me about what what did they hear? Yes and I think overall writing it down is also a great practice to actually clarify what you mean because I find my idea seems so clear until I have to explain it to someone and instead of wasting someone's time I can try and write it down and then I realize I didn't truly understand what I mean or I have this ten other questions that I should actually answer first before I propose something. It's just about making sure we can communicate in a clear way to our people so that they are not confused. I think that's absolutely great. It was a pleasure talking to you Chris. I learned so much and it's great to see someone who managed to say with one company and see how it grew and also how it was changing and how the market had to change and of course technologist and never stopping to change but also someone who was courageous to take a leap and try something new. Someone who said yeah I am confident that I will go to an other song and I will get that CDO role. I think that's a great example of courage and great inspiration hopefully for our listeners. Thank you. Oh thank you so much. Thanks for listening to this conversation with Chris Petramp from his early days solving customer problems at GenTrak to his boss transition into a CDO role at FuseIT. Chris's story is one of adaptability, courage and commutes learning. I hope that his experiences inspire you to embrace change, sharpen your leadership skills and build meaningful connections in your career. Don't forget to subscribe, share this episode with your network and join us next time on the TechWalker Podcast for more stories from New Zealand's tech leaders.