The First 90 days in a Private Equity-Backed Firm with Tony Young, CTO at Linkly

all righty let's uh we'll we'll start kicking this this discussion off um yeah tony if you want to want to switch on your video and and join us hey tony how you going hey scott good thanks um all right so today is the first in our cto chat series where we're going to be chatting to ctos from across the australian tech community tony's volunteered to be the first which could be a good thing or a bad thing for tony well we're about to find out um and the so we're going to experiment a bit with this format but but the idea is look we want to hear from all the great um ctos and technical folks that we've got that are building like really interesting technology companies and all the ins and outs that go with that like how did how do you get teams to work together how do you think about technology how do you enable growth we're going to try and cover the gamut of topics that we can cover um what we're going to focus on today is we're going to center it a bit around a topic where which is the first 90 days in in private equity uh but we could go anywhere the idea is to be a bit informal so like i said pl please jump in and kind of become a part of the discussion it's as much about tony and i having a chat as you getting involved in the in the chat as well what i'll do i'm going to do some quick some quick intros and then we're going to jump straight into it i'm going to start uh peppering tony with with questions but we're just going to kind of go through it however it evolves so um to get started so just a little bit about terms so we're a tech product development and strategy firm uh we work with enterprise tech companies and government and look we just love we love building products we love working on a strategy and we love working with with organizations to help help make those internal capabilities better that's us in a nutshell um i'm the ceo and founder i've probably been involved in 61.70 or so major product launches now i love making sausages and i love uh i love sailing it's one of my other passions now uh tony i've had the good fortune of knowing for a while so tony there's a bit on the screen there but i think one of the the things that i i definitely know and love about tony is deeply considers what's going on has a mind for uh the business which we'll probably chat about it in a bit a mind for the business as well as like that the ability to get get deep technically so i'm really looking forward to chatting about today with tony today i think uh so tony's the cto of linkley tony you've been here about almost six months uh yeah nine now march i started almost nine months prior to that tony was at nyo what's that almost nine that's it seven months nine months seems like nine the prior to that tony was at nyob where uh i think hey it was about a couple hundred people the organization you led there at nyb the yeah as i left the team was probably around 140 or so as i left there yeah yep and you started your career as a database administrator is that right i did um what database technology that was back on uh well as a mix so it was predominantly sql server on os2 systems um so okay pda working on some of the branch systems yeah okay and what's your favorite memory from from back then god we've never spoken about this before you know i actually don't have a lot of good memories from that time that's the reason why i got out of it pretty quick um i just remember as a junior i was doing a lot of overtime 70 80 plus hour weeks trying to do branch updates overnight so it wasn't all that good in experience but it did kind of um you know one of the things there is one i think well the one thing i did there that actually got me my next gig where i spent 20 years at the integrated research was i actually managed to reverse engineer the nt performance registry data stuff to be able to pull out more detailed performance metrics than was provided by the task manager yeah right it gave us a much deeper distribution or understanding of all our branch performance uh across the whole network across australia and it was that and the ability to do that that actually got my next gig in integrated research that was all about performance monitoring yeah okay you didn't end up in cyber security no it didn't end up in cyber security reverse engineering nt it sounds like fun yeah well it and it it was fun it wasn't easy but it was the fun part of the job yeah yeah and and uh so changing fast forwarding to your more recent couple of months so i think interestingly it well at nyob you mib recently was a public company and then was acquired by kkr the private equity giant and now at linkley for those that kind of don't know so linkly is a payment processing technology company is that if i got that kind of spot on nice enough at a high level yep and and what and i think linkly's in that uh you do the payment processing at harris farm is that just to give people is it harris farm or harris farm i'm not sure about um so some of our key partners um we provide the uh main merchant suite or b point solution for cba so yeah if businesses are using the cba on online side of things they'll be using us uh if you've ever gone into a woolworth store where we we provide a lot of the um infrastructure or the you know enablement there for your everyday pay and your payments and and the like bunnings is another big one jb hi-fi so some pretty big names yeah yeah yeah okay large penetration in the market yep and uh i before i knew about payments i didn't realize how deep payments goes with so many layers in order to facilitate what seems really simple i tap my card and money goes to the merchant it's actually quite a complex uh industry and and then um so nyb was accounting software the private equity firm and linkedly sorry jumping or linkly linkley was purchased or a group of companies were bought and merged together under a private equity uh firm and so the topic for us today is really understanding from hearing from you tony having seen different sides of of different technology companies you know what is it about a private equity journey as a cto that might be a bit different and then we'll kind of go a bit broader but i'd love to first hear about what's what what's the first 90 days look like in a private equity backed technology company it's a good question and i think one of the things i struggle with the question a little bit is i don't know what it's like as a cto in any other type of company yet but uh linkedin is my first cto gig i think what i grew into at nyb was definitely a cto level role given that you know 140 people looking at i think yeah all the heads of delivery at mib are kind of division ctos but being the cto what i've learned is it's still different yet again so being a cto of a public company i couldn't really talk to i think is you know inferences that you can make um through my time at my b as to you know what was driving us as a publicly listed company and then what might have been driving us as public equity as private equity for linkedly you know the the core thing that i focused on initially was listening to everybody that i could um so for probably the first month i was just in for the most part back-to-back meetings with anybody whose name came up in a conversation it didn't matter really who they were i made sure i spoke to everybody that was in my team i also talked to people in other teams across devops ops support marketing sales product um so it's really just a matter of you know trying to understand who's who in the zoo but also given the history and you touched on a little bit the history of linkley being actually you know one company that acquired two others so essentially three companies that were trying to bridge the the cultural and product sets across the dynamics there were challenging um there was uh you know i spoke to quite a lot of people and i probably came out of my discussions there with 40 to 50 number one priorities that had to be dealt with um some of those were cultural in that you know we're still talking there's still us language across the different companies um so there wasn't a we are linkedly one team kind of concept or pro road map or product set um it was all quite disjointed and working through you know any sort of acquisition um of that sort of nature almost any acquisition i guess um there's things that happen that people aren't necessarily happy with um and we were dealing with a situation where as part of the acquisition or soon after it there were ceo changes there was attrition uh there were redundancies that occurred as a result of that so uh i came in in february in march uh malta the city ceo came in in february and we're both kind of dealing with the repercussions of stuff that you know we weren't here it wasn't under our control but you know kind of got to learn what's going on what the landscape is and and what are the right things to focus on next and that was probably a big part of the first 90 days really is listening to that conversation and working out okay what's most burning right now and what do we put attention to and and just uh one thing we didn't cover just people-wise how how big's link linkly people-wise just to give a bit of sense for the audience like the scale of how many people you had to have coffee with by the sounds of it in a month so um right now linkly has grown over the last several months since we started so we're currently around 110 or so people in the technology division that i'm looking after there's 36 in that group when i started in march we're around 20 people in the development team and probably i want to say 60 or 70 uh company wide um probably closer to the 60 uh now that i think back on it um so quite a lot of growth um yeah yeah it's almost a doubling of head count which is hard no matter what size you are abs absolutely but um to the question there i think you know over that first month yeah i probably spoke to probably 50 or so of the 60ish that were there and i might have the the total number there wrong i'm just trying to think back but um yeah there's a good number of conversations yeah and and um so you went through you you spoke to everyone uh you know is it hard as someone who's been quite solution driven reverse engineering nt performance issues and that that kind of stuff just to you know how did you find just sitting back and not jumping in and being like i've got the solution did you put it really purposefully just put on your listening hat and yeah no i like your opinion it has to be purposeful it definitely has to be purposeful um i kind of had the [Music] benefit if you like of the nyb experience there too so with both the changes coming from integrated research i was there for 20 years i started as a training software engineer i went went through you know the various software engineering ranks up the architect to dev manager and then ultimately gm of the r d group of around 70 or so people so it was an area where i was able to learn my leadership skills but also i i still knew the stack i i still technically knew pretty much everything oh yeah yeah i built it up i was part of the journey even if it wasn't something i built i knew who to talk to and i knew you know tangentially what was going on yeah yeah yeah as i went into nyb it was uh you know i had to just focus on the leadership element um i had no technical background of what the team were dealing with i kind of had to learn that as i went and that's true any role you go into right you don't understand or you don't know the technical solution that's there you've got to learn it um but also having to learn the domain so that experience at nyb i think was a good one for me to really realize okay there are people around me that understand the technical aspects and yes i've got to challenge that i've got to provide guidance and guard rails around that and on occasion dive in and help out with the design and potentially implementational solution hearing of what's going on but for the most part my core role is providing them an environment to get that done yeah so at nyb it was a similar sort of journey where i joined there there was probably about 30 people in the team i started there as a dev manager looking after probably a half a dozen of those but working across the full 30 or so and we grew that i think you were part terum was part of that growth journey for us as we partnered with you guys on a number of key projects as we grew out 240 and you know you're talking about that number of people you can't maintain technical yeah yeah yeah impossible you've got to rely on the people that you've got on your team to be able to do that so in some respects that mib experience set me up for being able to do that a bit more effectively so as i started it at linkley it was a similar sort of journey or problem i i had no idea in the technical stack i'd never worked in the payments domain before the reason i was brought on was for that leadership and the growth and scale experience and agile methodologies and uplifting some of those modernization of practices um less so my technical experience so the idea was we'd hire to fill that technical experience gap and then we have yeah so in in that sense having learnt that at nyb it was a little bit easier for me i think to step back and kind of go okay you know where are the key technical problems i've got to solve and where are the more systemic you know people organizational or business problems that need to be addressed yeah yeah and um chris i think we had chris in the audience wanted to say something chris you want to just stick your hand up or write a comment i can try the allow to talk to let you jump in all good sorted okay maybe it was all good um yeah so that's interesting that that uh you know stepping out of the technical have you what have you changed your approach the second time around doing this are you keeping more out of the technical this time or do you still feel you need to have a grasp of that like yeah look it's one of those almost um it's a bit of a buzzword perhaps but it's almost an existential crisis kind of thing for anybody i think that steps into senior level roles who really come from technical backgrounds do i wish i could be closer to the technical knowledge and and detail definitely um is that where my skills are best applied probably not and and that's what kind of guides me a little bit i need to have any cto does but i think you know there's one of the things i learned as i took on the cto role and tried to work out what does this mean for me what does it mean for linkly is you know there's ctos that are on one level you know the principal developer for a shop particularly in a startup mode and there are ctos that you know you've got architects and engineering managers and principal devs around you that are fulfilling that and you've got to provide a bit of more high level guidance so i'm probably you know somewhere 50 above that spectrum if i really kind of call that out yeah um and you know in order to be able to to do that i've had to have a close look at or where do i need to get into the detail and where not and what's guided me so far at linkley is where our burning problems are and while when i joined i i don't i know that some of the linky people are on the call and some of my uh nyb peers are on the call um so he's gonna say lots of offensive stuff so hang around but they'll know what i'm talking about um is that now i've lost my train of thought um but look at as i go through that so when i started at lincoln as an example you the board talking to the board talking to the ceo talking to a lot of the key technical people across the space the key call out there was you've got to fix our cloud stack you've got to fix and uplift the capability and scalability here and it's you know it's held together with you know duct tape and we've got to kind of uplift some of those practices all of that was true um and all of that needed some focus but having come out of a lot of those conversations and further conversations with the board um you know i kind of uplifted things and realized look that is a problem but things are working right it's a problem but things are working but there's this whole a bunch of other stuff that's not working right the teams aren't talking to each other the teams are overloaded we had i within the second month i think we did a bit of an order to the number of projects we had across the technology team and there were some 45 or so projects across the team across 16 developers right so that level of whip is just unsustainable and not possible so people were burning out people were leaving because you know hey nobody nobody's actually managing my workload here so a lot of the initial focus i did was was trying to you know manage some of that whip reduce some of that with but we've been working progress just to get yeah yeah yep um and then focusing on you know scaling out the teams to actually provide a little bit of breathing room for people um and so you know we're now getting into the point where i've hired on a brand new uh architect who's got really solid cloud experience who i've also worked with in the past we've hired some really key um terminal payments people um and we've got a very solid um online payments team and and uh core skill set there with a couple of people there from the online side of things that are keeping that churning away um so we're starting to address some of those technical concerns but you know some of the people on the call or some of the people who might watch this later might sort of lends to this or or aligned to this well but like i was saying i came out of all those conversations with 40 40 plus number one priorities you can't deal with them all at the same time yeah so there's going to be people through that whole journey where you haven't solved my problem yet and there's still a good number of problems that we need to solve but again it's a matter of looking at okay you know where is my attention best allocated we've got some really solid technical people i need to give them room and make sure that they've got the room the accountability the understanding and the you know decision making capability to make some decisions there around what needs to be done without having to worry about escalating it up to me or asking me for permission to make decisions on a technology stack that you don't know anything about like you probably know a bit about it now but it it and so just just with you the 90 days so you spent the first month just listening and then it sounds like in the second month you started auditing these projects going through them all the stuff that was going on uh is that is that what your second month was what it was you start making changes then or yeah i'd love to hear what you went through in the second month yeah so the second month was a bit of what you were talking about there around auditing what was going on but it was also working through some of the reflections of what i'd heard excuse me so i spent a bit of time putting together a bit of information that i could share with the executive team we had at the time but also my leadership team and anybody else that was needed there as to okay and i did this in a town hall for the for the whole team to be completely transparent is you know here's what i heard from everybody you know these are the key call-outs this is the you know the general spread of sentiment that i've got here's what i'm reading as you know the main you know top 10 15. i can't even remember how many or what format i used for this but um what are the key call-outs that i heard and then i kind of you know started matching that into different dimensions in that you know here's the things we need to do on a technical side of things is with things we need to do on the scalability or side of things here's what we need to do on our ways of working here's where i see some of the friction points that we've got and then just calling out okay here's what we're going to work on first or the top number of one and two things that we're going to work on and it was coming out of that that we kind of worked through and said you know okay doing a bit of an order here of kind of saying i keep i'm hearing one of the dimensions i'm hearing is i've got too much on my plate we had a real key person risk problem both in those that had left but also those that were then left behind in the amount that got loaded up on them um and working through okay what are we going to do about that how are we going to manage this and coming out of that then was that okay well you know we can't deal with 20 people in the technology team 16 of them being developers it's just not enough people so we need a growth element here yeah so within that second to third month that's when we started ramping up the hiring so i had had conversations with the board and with the ceo to kind of say look here's what you asked me to do here's what i've found here's what i want to do with that and keep part of that is we need to scale the teams up if we're going to survive this and they got buying and this was one of the things that i felt really valuable back to that private equity versus not conversation we've got a really engaged private equity board i understand i believe for the most part uh software development tim reed is our chairman and is a partner in the in the bc fund he was ex-nyb ceo um so they're a board and they're a private equity firm that focuses on software development so they understand software development so when i was able to sort of turn around and say here are the problems i'm seeing and here's what i want to do about it there was a lot more yep yep yep understand go and do it kind of messaging than what i'm used to for example with trying to do something similar between public listing and then kkr where it was more about to be fair cost reduction and cost management and making sure that you know our profit margins stay high private equity firm obviously concerned about profit margin but they're more concerned about the growth right so they're about investing into the company understandably um they're about investing in the right way in order for that to have a sort of you know broader growth than that might be in the investment but they understand the need to kind of say you know we can't actually grow the company if we don't have enough people there to do what we know needs to be done there and then invest in new initiatives as they come up so that was an easy i know when a bit of a segue there but that was an easier conversation than i expected it to be to be honest yeah yeah even then i was asking to double the team right i was asking go from 20 people to double the cost base yeah yeah yeah and and was that in the um i'm coming back to this because i i'm kind of liking getting just really specific for for everyone listening around the first 90 days so did you start making recommendations in months too started making recommendations in month two probably started acting on them in month three now yeah it's not necessarily that black and white right there there were some things i was hearing around um transparency and visibility of what was going on that you know i acted on pretty quickly i might it's like the easy fix yeah real stuff no-brainer yeah it's not hard to run a town hall and say hey everybody here's what i'm hearing and here's what i'm doing so within the encore two i was running town halls um i personally do uh something i started to do at nyob a little bit on and off um but really dived into it linkedly as i do weekly video logs where friday morning as i'm out of my morning walk to try to get outside you know particularly under lockdown right now trying to get out and yeah exercise i'm just running a bit of a video log saying you know here's what my week's been like and here's what i've been focusing on and you know any questions let me know so it's a quick four or five minute things but a lot of that sort of stuff all together when you've got you know the video log and you've got open and transparent town halls and you take the opportunity to actually listen and provide a high trust environment not everybody engages with it straight off they've got to learn but a high trust environment where anybody can ask me anything and i'll give them a straightforward answer really changes the landscape particularly from any sort of organization that you know not to uh you might prick years up at this scott but a lot of founder-led businesses tend to be very much driven by the founder right what are you trying to say tony exactly and i know you don't operate like this but no no no it's it you know it's even it's hard for me even as a like you've got to be consciously aware of this because there is an element of i've been in this i'm five steps ahead of you i know what's happening and i see it in myself and i see it because i have the good fortune of working with lots of founders and ceos as well it's funny when i see it in them and i'm like what are they doing why are they doing that and then i walk back to the office and do the exact same thing with my team and i'm i'm like it's a it's a it's a blessing and a curse i believe and you've got to be like super aware of it because on the one hand you've got to make some of the bets that no one else like can see or do and you kind of just got to say this is what we're doing because that's kind of that founder ceo journey that they've got to go through on the other hand there's instances where you do it you leave everyone behind and your plan falls flat on its face so it's it's a very finding that balance between what you need to drive and what you need to engage with other team yeah yeah yeah 100 and and i think a lot of founder-led businesses and i think true was both for both of the core businesses that uh were part of this acquisition so one pcf plus one premier technologies that a lot of decisions went up to that founder the ceo and answers went back down so there was a lack of empowerment people were used to escalating something getting an answer and coming back so a change of environment between both malta who's very open and transparent and myself who engages well with that too um people just weren't used to that so there was a bit of and you know those listening will probably not mind me saying because i've shared it openly with them too is there's a bit of a shock moment right there's hang on a minute i've got opportunity to make a decision here what do i do right yeah yeah yeah yeah get through this yeah so there's an element there is being more used to it that you've got to train and educate people in how to deal with that right it's not just a matter of and this was a couple of mistakes i made during the first six months even in kind of you know i built the nyb teams to a point where i can kind of say okay here's what we need to achieve go and work it out versus being able to do that here at lincoln everything froze right and i had to actually get in there and help them help everybody you know work through it and and come out with some other end the growth area that people will need to get used to there's a really interesting question from alex alexander richter on this actually which is super relevant he's saying would you love to hear would love to hear about your experience on copay kpis and okrs and that i mean this ties into that it sounds like if i'm just reading between lines like you kind of tried to set some and linkedly you tried to set some goals and say look here's what we're going to go achieve go go and achieve it or maybe even work with the teams to say what goals are you going to achieve but that didn't work and you had to work through it or it worked differently to how you'd done it at nyb would love to hear like yeah it'd be great to unpack a bit of that more did you set like okrs or or kpis or something no really good question so at the moment at linkley we don't have okrs or kpis what i did um or where the dimension now i'll talk to them more in detail because we did work through this at myob um so i'll talk to it there but also integrated research at linkley um you know where the dimensions i'm talking to there are a little bit more situational so type of thing that i was talking to is as part of that initial growth area where we're saying okay we're currently you know within the first week somebody was looking over my shoulder as i was looking at the org chart and they said i don't bother looking at that because that's not how we work i'm like okay you know problem number one to fix right let's reorganize ourselves around how we actually operate so that we can actually you know provide some level of understanding and accountability and dependency management and so on and so and ask i put to the broader team was you know you guys know what's going on how should we work how should we structure ourselves and that was a real challenging experience and i don't think they'll mind me saying because the the reaction there was i don't know i've never actually thought about that before i've just kind of the structure's been there and i've done what i've spent yeah yeah being given the yeah so so all of a sudden having the ask if you like or the expectation put on them was unfair of me right it was unfair of me to kind of go hey you guys thought this out because they weren't used to it they weren't experienced in it they weren't actually enabled to be able to do that so it's that sort of stuff that was a call out for me around setting a high level goal and helping execute so we instead went through some workshops with the team and said okay here are different options that we might have what do we want to try how do we want to put it forward and let's put it through as a trial now that's just as an example of trying to explain what i was referring to now on the topic of okrs and kpis the journey i went through starting with integrated research was at integrated research our kpis were bonus related so that devs even had bonus components yeah yeah they could you know profit share out of and kpis started off being driven by the business in fact from the board level right here are the kpis everybody that cascaded down here's what you got to do teams just didn't engage with that there was no understanding for them as to how what they did actually impacted profit or what they did actually impacted tune or what they did impacted how it impacted you know the the revenue or the cost space right they just didn't understand it so you know it was something that they didn't have to care about and therefore didn't aspire to and therefore the kpis didn't actually change or improve in fact most of the time they got worse and so then you get the expectation or the outcome coming back and hey i didn't get the bonus i was expecting because this kpi i had no control over told me i couldn't yeah yeah yeah and that's a core failing i think of kpis in general alexander's saying yes yes that's my life i'm hearing like that's what's going sorry goes on so often right but but a lot of that comes down to how you define the kpis right too often they're just completely misrepresenting what you're actually working on or what the team or individual is doing yeah so at integrated research i've worked with the team there and the in fact i was working with the architect i've now got at integrated research working on this problem where we kind of collaborated a bit more and with the gm at the time and said okay the business has some core level of concerns i want to see profit quality and whatever else they're like three buckets that they will yeah how about we say that everybody's kpis sub is you know 30 subject to those dimensions right the business wants to be able to control something i think at the time there was an element in there of you know if things go pear-shaped then there's a multiplier in there that the business can say nobody gets any bonus everybody gets 10 off yeah replied to whatever so a bit of a multiply there but then there's a big chunk 60 70 whatever it was percent that we went to the teams and said how do you want to operate and measure yourselves right this is going to be driven by you and that's where we kind of put again some guidance on it and said okay you need to have dimensions there around outcomes or productivity you know we moved from productivity to outcomes and also quality right and they do need to be balanced yeah yeah a whole pile of and excuse the french and and you know um get your bonus it's got to be high quality at the same time as high delivery right um or it's got to be quality at to whatever expectation if delivery might be set so each team i had ultimately around 12 teams there each team had different variances of the kpis that they might have but they're all along those dimensions and i got buying from the business to be able to do that and so the teams actually bought into that the teams measured it it became part of their agile agile measurements and so it was less about hey there's this kpi in my bonuses driven on that and more about here's how i monitor my day-to-day my sprint sprint outcomes and am i doing well or am i not and then that just naturally transitions to getting bonus at the now at nyb there was no bonus component but what we did try to instill is that same sense of the teams set and control the measures that they're looking at at a team level as to how they want to measure themselves how they want to work through that at nyb i think you know we got relatively i want to say advanced in that there's this uh book called the seller accelerate that talks about four key dimensions and i'm not going to remember them all off the top of my head but there was like mean time to resolution high level cycle time time to glass some of those dimensions um we got to the point where those were kind of guiding how we operated and there was a lens of you know that guided how the team themselves operated and then those measures you know across 140 people i had it my my b practice that was partnered with another division uh led by a guy um another head of delivery who i i still keeping heavy contact with and i know he's gonna call but i won't call him out um out of new zealand uh who had a similar sort of size team that we were working together we were managing a progress program across 28 teams by the end of what we were looking at so that level of consistency of reporting between the teams meant that we could correlate things up to an overall program view of how things worked and from that we could as a business unit match that against the business ok okay now it wasn't until probably the last 12 months or so of my time at nyb that we started looking at okrs and i don't think we got them to a point where they were really useful or measurable i think that was still very much driven by what the business lens was um which was really hard to kind of correlate um you need to find a way to kind of at a high level yeah there's business goals or objectives that you want to achieve but then at a division level you need to construct your own that are aligned to that but not necessarily a cascade of if yeah especially when you've got like you know it's like our goal is to we want to uh you know release another version of a product or a new new product that is going to create x revenue it's like well okay the development and and product and design team can do something about that but you know it's still dependent on marketing reaching the right number of customers and the sales team getting through the right number of pipeline like it's still there's a lot of moving parts so it makes it hard to say well we we can't attack that we can't say we're going to hit that revenue because we've got these other dependencies right and it comes back to what we've got in our control so at a division level we we were at the point there with uh i mentioned uh my peer in in new zealand so we were heads of delivery there were two heads of product that were paired up with us we had a full senior leadership team that included head of marketing head of operations head of sales and so on so we had you know vertical is what we call the time coverage of the whole plane so at that level we could talk about you know what are the key cross-functional objectives we want to achieve but then you need to to the technology team to the delivery team and product combined kind of going okay what are the objectives that actually make sense to what you've got control over to drive off that so while at a high level you know we may have revenue targets or churn targets or you know new seat targets what is it that you can do as a delivery or product team to enable that and support that and from that we construct what those objectives are it's a chris has got a question which is did you have goals slash okrs maybe an nyb as an example that spoke to how you delivered as much as what and i think you were touching on it there with your time to glass your cycle time that was your how wasn't it like how quickly are we able to get a release out uh how many bugs does that release have that's right so the objectives themselves at a very high level were often about the outcomes um so you know what you're ultimately trying to achieve but as you break that down yes there needs to be an outcome might be just to make it super specific and outcome might be uh release version two of one of our accounting products exactly um and then as you break that down you've got a similar sort of challenge that i think chris is alluding to there where you know i talked about before that balance between productivity or outcomes and quality your kpis your measures your metrics how you measure yourself needs some level of balance otherwise things get misweighted and go wrong i mean it's it's like a salesperson having a kpi of just reaching x number of dollars and focusing on there for the high volume high paying products that maybe the wrong customers as well yeah exactly right so you want some something that that's kind of actually going to reach what you're trying to drive and so yes as much as what you deliver as how you deliver it needs to be encapsulated in some of those measures yeah so there were things that we were looking at as as we built out particularly across the larger number of teams as we scaled over the final 18 months that i was there was around process adoption and cadence as to you know do your sprints actually complete right do you deliver what you say you were going to do with the quality that you said you were going to so sprint completion was a metric that many sprints actually many teams actually had as to you know this sprint was 80 80 complete let's say as a base we want to make sure that that grows over time or that when it dips we understand why it dips and we can make a change to kind of correct that yeah so to chris's question yes it needs to be a balance of both the how you do stuff and the what and that's a big focus of what i'm i've been sorry scott oh it's good it sounds like you're about to go i was gonna say and then how have you applied this to to getting it working at lincoln or building the foundations out it sounds like and and that's the core of what i have been doing at lincoln in that dimension so we've had and i've had conversations with my leadership team not not so much with the technical team at a you know a developer or qa level but certainly with my leadership team around you know okay what are the quarterly goals that we might want to achieve what are the monthly goals that come out of that how does you how do you as an individual contribute to that we've started to have those conversations but one of the things that we were challenged by in that and i took a step back from it quite deliberately and i told the team i was taking a step back quite deliberately yeah is as we came on board as i came on board with malta and some of our other new leadership team we didn't really have a business strategy that would help guide what those okay ours kpis are just yeah yeah yeah yeah yeah so you'd be setting it in a vacuum exactly so first six months or so we were really you know there was a business strategy in the sense of we kind of had some road maps we knew what we were doing but a lot of it was protective and reactionary yeah that is perhaps a good way to put it so for that six months we're really playing catch up you know we've been to the point where okay now we've got some capacity in order to do what we know we need to do now which then starts giving yourself some mindshare and bandwidth to start thinking about the strategic element okay what next how does this actually look for us going forward what does our next three to five years actually look like yeah so it's only recently over the last quarter i would say the also q 3 calendar year that we've worked through that and we've been transparent with the teams in working through that as to you know here's our evolution and depth of that business strategy we realized you know the strategic thought that we had needed articulation but it was essentially along the right path we just needed to execute yeah and now we're in that execute mode and now as we get into that execute we need to start structuring out of that okay here's the business strategy therefore you know between the pillars we've got in that business strategy here are the goals or objectives we want to achieve and how do we you know derive the detail from that so that's that's kind of a next step please but all the way through as you alluded to before it's been about setting that foundation right in order to do some of this stuff we've got to get and start driving some consistency in our agile practices in our ways of working and we've still got many gaps there my team will you know if i turned around here and said hey we've made major improvements there and we're just about done they'd laugh me out of the room but i think we've made some good projects and we're probably you know 50-ish sort of percent of the way there yeah what we've been able to achieve but there's more to go yeah and and um i just just quickly probably there's a question from lily that says it sounds like when you're setting these objectives you've been setting it at a team level not the individual level a little bit of both um so one of the dimensions that i've been working through or had started working through with the team before we kind of put pause on it so my my direct reports was here are the high level things that we know the business is trying to achieve therefore here's what we're trying to achieve as a division but then how do you contribute to that and also what are your personal goals right yes there's questions there um you know i don't want to sort of uh go into too much depth here because people names might people's names might come out of the wash but you know one of the things i have learned in the past is that a lot of the time people move into leadership roles because they see that as their only next step in the career not because they're necessarily aspiring to leadership or whatever oh yeah yeah they instead they may be more suitable to principal engineer architects technical track rather than yeah yeah yeah and sometimes they want both right so there's a certain lens that i've been having with uh or conversations i've been having with people as to what do you actually want right and then that starts driving personal goals as far as what we want to do there yeah double down and dive into some uh you know coaching conversation around how to improve your leadership skills what do we want to find ways to you know uplift your technical system yeah opportunities for your loved one it's a good question lily but i think we do need to make sure that and it's also to chris's questions as you start setting okrs and kpis that personal element that personal growth needs to be a big part of what you're doing there and people need that sense of okay the business actually cares about my personal growth as well as its own growth and how i can contribute to both and and just to unpack so there was a moment where you were asking the team to set objectives goals whatever we will call them objectives for now that's true you were getting them to set what was the moment where you where you kind of adorned on you were like hold on a second i haven't given them enough information because it's really your responsibility and your ceos of not like in a way right not providing the was it talk me through that moment where you're like oh so that moment was more applicable i think to some of the things i was asking around organizational structure and how to set that up yeah from a goal side of things um the the realization was as we started to work through some of the detail i realized you know there were some really good things that people were coming up with and we were able to set division level goals or guiding frames frameworks for us to to work towards so there was some benefit to that but i kind of realized that you know most of the time people were looking at okay well i'm not sure exactly what goals to set that made us realize okay well we haven't provided enough structure here yet yeah on the organizational structure piece it was a real learning point for me and it was actually uh you know hey i kind of set up the expectation or the guidance that you know by date x you know friday a week away i want to have a conversation so start thinking about you know how you might want to restructure yourselves and let's get together and then as we got together and i realized how much people were struggling with it i realized what i'd done right i realized the mistake and and i called it out and i said look sorry it's obvious here this isn't going to work because i didn't set this up right yeah and so i took a step back and put some focus in setting it up right and how does that work with your board and your shareholders to kind of turn around and say hey um all right and you and your ceo and your peers to kind of say well hold on a second uh because one thing to say to your team as well but it's another to kind of report upwards so to speak and and sideways and say hey look we went to set some strategic objectives but we we're not going to because we're not ready um so we had was it we have no goals or yeah we're gonna wait like talk me through that because that's probably in some ways the more awkward part of the conversation look look it is but i'm not sure what insights i can draw for you out of it because that could be relatively engaging and collaborative so yeah the world structure side of things there was an uh a fast enough you know turnaround there that you know the board didn't really notice right it was a concept i had with the with malta the ceo and other parts of the leadership team to kind of go hey this is a mistake and you know i'm stepping back and here's what i'm doing but you know we're still able to turn that out turn that around within a couple of weeks so it was still enough that you know one board update to the next board update we still have the answers that we will look yeah yeah um so and and our board um isn't you know they're not looking for the detail to kind of go you know where did you stuff up and let's take us through there they're looking at you know okay are you actually doing what you said you were going to do and and we got there with that element yeah on the api side i'm speaking for somebody else because i wasn't part of these conversations but between the ceo and the cfo they were having those conversations with with the board um and again it was fairly amicable there was a realization with that conversation that we really needed to focus on defining the strategy and obvious at that point for everybody involved you can't set goals and kpis until you've got the strategy the clarity so we kind of had some near-term you know we need to achieve xyz or we need we need to keep putting out a fire over here make this customer happy for a moment yeah but it was very amicable in the sense of going yep that just makes sense so let's take a step back give you time to define what that strategy looks like and and then define what those objectives and kpis might be now we're kind of running out of time a bit so what i want to do is open up just to any any kind of questions we've got we've got a first one that changes tack a bit from david shorter david thanks for the question and the question is tony what's your advice to new leaders to be great that are coming from a tech background like yourself like how do you make that transition from i'm gonna i may be putting words in david's mouth but it's one i thought about a lot when i was an engineer like how do you make transition from i'm coding to i'm now leading people it's a hard one and it's also to reuse the term a little bit existential too for most um and i know scott you and i have spoken about this over various coffees at times too um for if i look back through my journey i'm trying to be quick because i know we are low on time and i want to make sure we get questions but there is a real shift that any person needs to take when stepping into a leadership role where they move from um you know finding satisfaction in what they do to finding satisfaction in what they enable right what they allow others to do and a big part of my leadership journey i never aspired to being a leader um it was always a step up and it's only recently that i've kind of done that aspirational thing to say hey my next gig is the cto as a step up it's not to do an engineering manager role or a head-on role i i need to and want to be a cto it's only recent what's guided me all the way through and i know that if everybody looks at leadership things on linkedin it's a common sort of frame of reference is be the leader you want to be the reason i stepped into leadership first was because the leader i had wasn't doing what needed to be done so i started saying okay well here's what i need to do for myself for my peers and you know because of that i then got recognized and started stepping up but the key thing for for most is that realization of needing i think to step away or that step away part from being technical to being a leader is finding a way to bridge that gap between it's not about what you do yourself it's about what your team can do and that's hard and i still struggle with that today right i've been in leadership roles since 2000 2001 or something and uh so a good 20 years and i still struggle with it today as far as you know am i getting deep enough am i actually you know doing enough for the team and uh you know it's it's almost uh an element there is that um you know mindset around you know am i doing well enough or am i sort of doing the role that's fit for me the key part there is you know looking at the success of your team looking at how well your team are operating and whether they're happy or not so a little bit round about but hopefully the answers in there somewhere is that a big part of that is switching from that doing to enabling and finding satisfaction in doing that yeah well thanks for that that's a one of the ones i found challenging is not jumping in and um because i can code i still i'm probably not as good as i used to be or even if it's like solution architecture or something and a big part of that you've got to not make in the room realizing that if you're the smartest person in the room you're in the wrong room i know that's a quick yeah yeah yeah well it's kind of your fault too because you're the one that set up the room big part of what i often take in those sessions that's also a tool that i think many people are aware of but as a leader is be the last person to speak um so at integrated research this was a key learning for me as i found that because i'd been there so long and i knew what was going on if i spoke first everybody kind of went okay well tony said this so that's yeah he's got the right answer and we'll just do that so you tend to kind of just listen absorb and be the last person quite often somebody else will come up with the idea that you've got or the answer that you've got and because they've come up with it it'll actually succeed um whereas if you try to do something top down it's less likely to so taking that mindset of shutting your mouth listening and being the last one to say something can be a tool to help with that i think one of one of the interesting transitions that i see people go through when they they're transitioning out of the technical side to the non-technical is um the letting go of the technical competency because there kind of comes a point with with really good engineers where you know like all right cool you could go learn that next framework the latest like thing that's out and i and i'm probably a bit far away from it now but it's like you could go learn rust or you could go learn uh more about like graphql and how that's going to work with whatever you're doing but to be honest you're probably going to pick it up in two minutes anyway you'll go and read half a web page and bang you you know you've you've done it and it's like spending time realizing there's value in spending time on the soft skills yeah and learning about the soft skills starts to become that's like a really interesting jump that i often see people kind of shifting around because you you used to like all right i'm going to learn the new framework i'm going to learn the new library i'm going to learn that new because there's always something new being released and actually it's stop paying attention to that and and start paying attention to all the non-technical things going on like are you taking people on a journey with you when you try and um put a solution forward instead of the uh i was a very abrasive young engineer instead of the like i'm right and you're all wrong approach you know like maybe listen to them outside of the meeting there's a lot of stuff around that that i often see as the big you know go spend your learning time there even if you are going to take the technical track you know still those are the skills that are going to help you not so much like i know the latest uh you know i can quote the latest framework release and the five function whatever it might be that's been released instead how you have an effective conversation how you have an effective discord how you disagree with each other perhaps and look on that dimension you know i've got browser windows with 30 plus or more tabs of various training courses technical and otherwise that i still want to do i don't need to dive into azure fundamentals i need to dive into aws i need to get more up to speed on some of the latest tech but given the background at least i've got the the engineering now to kind of understand conceptually even if i don't understand in detail how react js works for example i understand you know the satellite things as to how it fits in the hole and what to do with it yeah but a big part of my journey too and i know we don't have a lot of time to go into this in much depth but my reason for going and doing an mba was kind of a realization that you know there are many technical people who really build technical depth there are not many technical people who take a leadership route and can provide solid managerial leadership capability to a technical team and when i realized and had coaching advice that that was something i was capable of i dived into it and said okay well you know it was a big area that i saw as failing in my leaders and managers very early on so you know part of that be the leader you want to be is kind of going okay well i can help other juniors mid-level senior engineers through that through that journey yeah you know what you pay attention to and does it mean that i'm no longer technical i don't want to be technical absolutely not um but it means that i'm kind of looking at it and going okay well i've got an architect and i've got you know senior developers who really know their space if i actually start diving into some of that and doing their job for them i'm doing them into service as much as anything and there's a there's a really interesting question on that point actually from alex alex has said i struggle he's just i struggle with getting into the flow eight hours coding versus eight hours let's just call it managing stuff um you know how do you how do you balance that if you're making that transition out of yeah i don't have a clear answer to that look the reality is most of the time where i find that flow in what i'm doing is on the weekends it's in the evenings we instituted a similar to a meeting free day we instituted a meeting-free afternoon at lincoln every wednesday afternoon so there's opportunity there to provide a bit of flow and and just say well i've got no meetings the whole business doesn't have any meetings so we all get to have a bit of a flow but the reality is that you know my days on any leaders days probably uh full of back to backs switching context from one issue to another from one domain to another so you need to learn that context switching but there's also something that um i can't remember who it was but i think it's actually something i got at the nba through some of the one of the philosopher courses um where there was somebody there or a message that stuck in my head where as a leader your impact is in the conversations you have it's less about what you do and it's more in those conversations you know you're helping people work through a problem you're helping people make a decision or you're making a decision or you're understanding the context of how things fit together by listening to them be able to make an engaged choice and so that switch too is to it's less about what i feel like i'm doing and what i'm achieving personally and more about what you're enabling that that helps that and what you're getting out there is like i helped alex make a better choice about how to spend his time versus i finished the thing that i needed to do or i finished you know and giving yourself a bit of a a bit of a you know a nice friendly stamp like i'm thinking about kid's school like a nice stamp of hey you achieved something today and then that's right i might i might just go you go through a period where at the end of the week i started looking at what i'd achieved and kind of going i haven't achieved anything to realizing that no through all those sessions you know people have you know worked through they had or you've helped them you know through a tooling change or you know some something that you said prompted an extra thought in how to solve and troubleshoot an issue right yeah all of those things help they feel a little bit light right when i say it like that yeah yeah yeah might look at that and going oh what do you actually do as a leader um but you know it is it is often those conversations that really do help the team out you then have your day job post that right so you know i'm not going to shy away from it there are after hours work as a leader and you know you do want to find a way to balance your family and work life and it is hard the only way to really carve that out or work that out is to carve out time like meeting free afternoons or big blocks where you can kind of just sit and get in the flow of what you need to do and have allocation to help others out yeah it's something i can can just touch on something that alex is what you're saying is like the i've found often it's about with engineers that are making that transition um sharing with them that hey you've got to take control of your time now and if you need a morning if you're a team lead or you know you're in that role and you need a day or two days or whatever it is to get your thing done it's up to you now to do that it's not on your team like you're the one that's got to say i'm i'm out on wednesday i'm out because i've got a feature that i've got to punch out and there is that delicate transition period that everyone seems to go through of like where you're coding and you're also managing and it's really up you you've got to be the one to take control of that has been my observation but also i think the sooner you can also get your team to help you with that that the better as well because it's in that mid point that's the most dangerous to i think where you're you're not really coding and you're not really managing either that's there's it's a bit of a danger zone i've seen too um helping out that time could be hard too because quite often when you're carving out that time uh the right type of leader for one of a better phrase that and kind of go well i'm actually not there and being responsive to my team and that's bad so you still watch your slack messages or your yeah yeah yeah yeah whereas there's a level of you know as much as you as a leader want to respect your team's time you need to realize that they kind of need to respect yours too and while you may be carving two or three hours out to get your stuff done after that two to three hours you're fully available to them then and there's a quid pro quo that needs to go back and forth there and we need to be nice to ourselves mr watson the ceo of ibm used to have no meetings before 1pm i could not book in with him every day of the week that that's running a company this site that was like ibm's heyday but that's something i always always think about it was very controlled by that we've run out of time um tony thank you so much for for having us um thank you thank you for the questions that came through those were really solid engaging yeah excellent questions i'm just going to do a quick we've got the can i share my screen in time we've got a session coming up uh next week with doug from air tasker doug's going to be talking about scaling empowered engineering teams we've had a great chat today about really like goal setting i think what it came down to the first 90 days and next week we're going to be talking to doug about how do you get that empowerment happening probably like the foundations that that tony and i have been talking about really looking forward to having you all back thank you so much for being part of the conversation it was it was so much fun uh hopefully speak to you all next week or sometime in the future bye everyone thank you thanks everyone thanks scott

Channel: Terem

Views: 226

Keywords: aussie, tech, CTO, CTOs, chats, interview, tech leaders, goals, team, OKRs, KPIs, Growth, Team Growth, working as a CTO, Linkly, MYOB, foundations for growth, set up goals for your team, Agile, Australian Tech leader, tech CTO, Private Equity-Backed Firm, Equity, Private Equity, Is an MBA really worth it?, Establishing ways of working as a CTO

Id: XXb0huexHNk

Length: 63min 56sec (3836 seconds)

Published: Thu Oct 28 2021