How To Become A Great Tech Lead or CTO ft. Niklas Herriger, Tommy Krul, and Avinash Pandey

hey everybody and welcome so how do you become a great technical leader or cto that is the question i asked our panel today in one of the most insightful and deepest conversations ever on the internet seriously though the application for you as a listener even for non-technical leaders is pretty great we discuss the role of tech leads being hands-on versus being a manager biggest problems bridging social skills biggest lessons learned and much much more so in our discussion today we have first nicholas herriger founder of 8-bit coaching who is an executive coach focused on technical founders for gaming companies second we have tommy crull co-founder and cto of super evil mega corp and third avinash pandey co-founder and cto of lila games so we have two ctos and tech leads with

different perspectives and range of experience in terms of stage and focus of their respective companies and nicholas our coach who can provide his perspective working with many ceos and ctos on this issue of what makes a great cto or technical leader so let's get this started starting right now all right hey guys thanks and welcome so i thought we could first start with a question in terms of from your perspective when it comes to the role of a cto or technical leader at a gaming studio as far as like the expectations of that role or what the general responsibilities of that role are i was wondering if you guys could comment on what your opinions are and maybe starting with you tommy oh it's a great question i think it's um what i've noticed is that there's a lot

of different ways people interpret the role and and really i i think i can only really speak for myself so i i it was interesting for me that you approached me for this podcast actually because i i think as you remember like i kind of joked about it saying like you know it's a very ambitious title right like what makes a great cto and like i don't feel like i'm a great cto and like as i've said before like i feel like you know i make this stuff up as i go along and but i think the reality is most people do um and the thing is i think a lot of people a lot of ctos they they have their own interpretation of what the role really means for me i consider myself much more of a crafts person than uh than a tech leader um i you know like for me the the organizational part of the role is it's sort of like the means to an end to be able to express my my craft or my art which is

ultimately technology and ultimately like the technology and service of making a great great game uh or great game technology and um so for me you know the way i look at my own leadership style i don't think i bring a lot of the sort of uh so the known good practices of like leadership or or management and for me it's much more of a role where i try to lead by example by modeling my my uh my direct reports behavior in by setting an example for how i want uh them to shape their their their their execution and their role and and i i try to do this by sort of being the best engineer i can and trying to convey um similar uh practices and similar um

how do you say this uh norms and values right uh to to the team that i work with so it kind of sounds like tommy i don't know whether that is broad yeah so it kind of sounds like you're setting the standard at your company in terms of what's expected is that would that be fair to say yeah that's definitely fair to say that's definitely fair to say and i think um i i try to be fairly hands-on with uh with new employees when they just joined the team but as i sort of like as they become more experienced in our co-pays experience with our way of working and also experiencing what i uh of the standards that i expect from my team i i believe i get i you know i i'm able to be a little bit more hands off because i i've seen them you know do the right thing or make the right choices and then it's sort of like a slowly like you know first you hold their hand and

then you let them walk by themselves and then eventually like you know uh you know the people that have been around for a long time and that i really enjoy working with i have a huge amount of trust in to sort of um uh you know execute largely by themselves and you know there's only maybe once every week or once every two weeks like a touch point where we go through the things that they have done the decisions that they've made um and and we make sure that everything stays on track and um and not just on track in terms of planning but also just on track in terms of vision and execution got it and ava what about you from your perspective what are the general responsibilities and expectations right so i think as uh you know tommy also mentioned this this completely depends on what stage your company is in and also your personal journey of being you know in your own uh path so for me you know i would share my recent experience because

we started leela you know last year and we are in a stage where we are building the team and building building the product at the same time so the challenge is not only to build the game but also build the team build the culture and as a leader is kind of you know i have to be involved i have to wear multiple hats at the same time and i especially feel like cto is a role which you can not say likes completely a management role i cannot imagine myself be a complete manager and not be part of the development processes or development itself so uh you know in my previous role at my previous startup i would also be mostly like you know 60 to 70 hands-on like you know i would be part of sprints i would code and i would also try to set examples for everyone like you know if my team is moving slow i will try to show them in a way that hey even if the problem is complex this is the way to solve it or maybe these are the uh processes you should follow and i don't think those things you can exhibit just

by telling like hey you know follow this design pattern all do this thing the best way would be like you also do those things you also uh you know participate in that process so that is one and at my stage right now one of the most important role for anyone who is just starting a studio would be to build a really strong team so i think you know hiring finding the right people that's kind of you know making or breaking off your company because it's not only the skills which you look for you also look for the kind of culture you want in your company and you know there's lots of resources many people have talked about it but it's very very contextual the kind of game you are building i would not say like you know it's like you know one advice i got from someone was you know you should try to hire journalists like in your initial stage of the company like a person who can do multiple things who can also do for example animations gameplay if i i can find someone with specific

expertise like if i'm building a multiplayer game if i find somebody really really good at networking i would want to hire that person at any cost so you know i think hiring is something which which is very challenging and as a cto you have to or as any any matter you have to be very very careful about got it and nicholas i know from your perspective you are an executive coach focused on technical leaders specifically so now that we've heard from the two technical leads ctos from your perspective what should the general responsibilities and expectations be yeah joe so the first thing i want to say you know i'm i i'm offering an opinion here obviously from the outside i'm not a cto myself you know i can barely code two lines so you know take all this with a grain of salt um but what i'm observing is that um that there are two different kinds of ctos and i think we've kind of heard both right now so the one is what what

tommy really describes is i try to lead by example i try to be the best technical leader that i can you know i try to be the best coder that i can i help where needed but generally my goal is that my team members are as self-sufficient as possible and i'm trying to be very hands-off that's uh that's the first style the second style is ctos that have almost completely if not completely stopped coding themselves right so there is no more uh no more involvement in any of the codes you know i'm involved in the sprints but more on a you know zoom out high level where i direct the team you know where i i really you know service my own team in the sense of you know what is it that you guys need from me in order to be um you know the most efficient uh and and the fastest that you can be and and that is from a different approach so you know two different angles here one is you know i'm very much involved and i'm leading with that example and the other one is i'm very

much involved but not on the on the coding side itself but uh really more as a team leader and as a resource that makes uh the other team members shy okay and maybe then i think go ahead oh i was gonna reply to that like i think that makes a lot of sense i've actually even in my own career i've seen both examples um and i think for me the reason why i i fall in that first category is actually twofold a it comes most naturally to me like i was you know i was obviously i was trained as an engineer and so the leadership skill um is some it's sort of like a a secondary craft i have to have but it was never something that was part of my training and then secondly um even in in my own career when i was an employee i think i was very fortunate that

at various um important times in my life i had either leads or ctos that that at the time were people that i and probably still i looked up to and i learned from and it was a very um almost like you know mentoring relationship that that i think was very instrumental in my own career development so as a as an employee i i really enjoyed and appreciated now later i appreciate having had the opportunity to work side by side with someone who was very relatively hands-on and and and and was there to learn from um i think it's very easy i think there's a real there can be a real value in a pure management style engineer or a cto who is more you know reach out to the team and says like well what do you need for me i can be here for you but i i'm not a direct contributor

the risk with that approach and i've also seen that happen is that it's quite easy for that person to lose touch with the actual technical work that has to happen and it requires a real skill like at that point like i think the leadership insight and the people management like skill that you have to bring has to be very substantial in order to still make a you know a a a good contribution to to the team like it really changes the dynamic of what you're bringing to the team and and i mean you know that that that better be you know uh more than you know just telling people what their tasks are or you know like making making sure that they feel okay okay like i think that it that starts to make sense when you you know when you really have that power to inspire and motivate and make the whole team um so function better as a whole

um but again like i you know like that is a that is a gift or a talent that is very separate from from engineering and like there i think there's few few ctos that naturally roll into that that role like it's it's a real you know separate talent that one would have to bring to the team nicholas yeah i can just add one thing where i believe yeah just a small point uh in this one because this is kind of very interesting like yeah i believe the management style of leadership would not work most of the time in if you are just starting off or if you are a small studio imagine like if you're just three programmers and you know you are just doing management that's just not practical like you know so common sense rules like you know if you have like 100 engineers that's the first style is going to be very difficult where you are coding and also managing 100 people so it's naturally like you have to kind of step back and

try to you know manage but if you're just a small team i i would say like you know i would still lean towards you know being a contributor than just being a manager right nicholas i was actually going to ask a similar question along the lines of what avinash was talking about like for those two types of ctos do you see like in orientation around like the more hands-on but based upon stage like the earlier stage single product being more hands-on and then as you start to scale and go from single product maybe to multi-product then you become more more of the manager or just curious in terms of your experience with those two types yeah absolutely like tutu everything you you three just said is obviously not even remotely as binary as i made it sound um it's it's a gradual process and it has to do with um the size of the team and the company you know like if i have two engineers working for me you know it's like what am i gonna do all day long you know trying to manage these guys you know i i gotta get my hands dirty and

contribute here otherwise they're gonna say it's fantastic that you have these management styles you know for all of these different parts but we're only two people so you know what is it that you're doing um so absolutely um that that does only really kick into gear at later stages um another thing that i've observed many many times is it also has something to do with tenure so how long has somebody been in a certain role right um and once again two different styles right um tommy i think you have been in this role for probably the better part of a decade or something right or even if not longer right so um that so that that i would consider you know a very seasoned cto um at the same time you know tommy has made a choice you know this is how i'm gonna lead and this is my style and i think the crucial work that you mentioned earlier was this is what's organic to me right this is like i was i was i was trained as an engineer you know i i grew up as an engineer you know i'm sure this is also where you're passionate and what you what you like and the the people management skills as you called them you know this is something that uh

you know that that came as a necessity along the way but it's not something that was originally there and so you know as speaking of the necessity uh that that emerges along the way of you know being in this role and then simultaneously the company uh growing and the team growing um at some point uh certain things are just not gonna really work anymore um i mean we we know this from the ceo role just you know to hand the mic to you here joe you know we all know that the the ceo of a 10 or 20 people company you know that's a very different role than the ceo of 100 or 200 people company and then of a publicly traded company it takes very different skill sets um very different talent and also a very different mindset and i think that kind of an evolution is also what is at least in part required from a cto as you know a company goes from single product to multi-product uh you know from you know single digit number of

engineers to double digit to triple digit and so forth great and maybe the next question to ask would be based upon you know your stated responsibilities or expectations or maybe just even other general problems i i wanted to ask you guys as a cto or for this role what are some of the biggest problems that you have faced um and and nicholas i know from a coaching perspective maybe you have a broader collection of data points around what you've seen as well but maybe starting with you again tommy oh man so many um where to start i think i wanted to actually follow up on on something that nicolas said earlier about you know like how how roles and expectations and requirements change over the evolution of startup and i i 100 agree with that and i i don't think i quite

appreciated that as much when i just started the company i don't think i you know like i think when you start a company like that's that's your focus right you're just you know like we're a couple of people we have an idea we get together and like i don't think i ever really projected much further into the future other than that you know like those couple of people making a product together but it's absolutely true that you know like um that i mean super evil from the from the from the day that i found it which might be wrong about it i could think it was probably 2009 that i that i started it um you know the requirements and the expectations of what you have to do as a as a technical leader or as any any leader any contributor to the company it really changes so much with each generation that the company finds himself in from the sort of bootstrap to the initial race to the growing the initial team to building the first product to

you know even maybe launching the first product and that product essentially really reaching its peak and then maybe even like going down again after that and then figuring out like what is your second and third product in in the case of a games game studio and and everything in between like all the different so uh phases of maturity of the organization really requires something um very different from from from you as a leader okay and then i can actually talk about a specific yeah specific challenge which uh which i faced in my uh you know years of experience is that as a cto you should never lose the big picture or the overall goal why you know what you guys are doing so it's very easy for a technical person to go so deep in the coding or work or something

you are building that you forget that this game is being made for for players for gamers and as a technical people most of the you know i would say technical leaders they they are not they might not be gamers they might be like coders but they might themselves not be you know the players of the game which they are building so this this takes a step back like you have to always step back and look at the bigger picture okay what are we building whom we are building it for and then you know those will influence your decision so much that you will not be able to think that if you have not considered that part so i will give you one example if you are building some tool a tool can be built as complicated as you want you can spend like you know months building a specific tool because then you want to cover all the scenarios you know has to be really optimized but is that required for the game you are building you know you have to launch this game you know this has to go to players and they are going to decide whether your game is fun or not not this efficiency of this tool so i think being aware of it being involved that you are aware that what you are doing and then you are taking step back

and making right calls and this is this is easier said than done so yeah all right what about you nicholas what are some of the big problems that you've seen or that you've counseled technical leads about well one once again the caveat is this is all from the outside right so this is all me observing um piggybacking on on what avinash just said i think that the the problem of not seeing the forest for all the trees is a is a very common c level problem that is uh is one that i have heard from numerous ctos that's also something that i've often heard from ceo clients and just you know for explanation here um i also coached ceos uh that originally came up you know the engineering track and have a technical background right and now find themselves you know the ceo seat but i think generally you know and also just looking at myself in my own startup

career yeah not seeing the forest for all the trees is is a common problem and in retrospect i wish i would have reserved three hours a week you know where i would have stopped everything and just zoomed out and asked myself what is it that i'm doing and what's the purpose here right and oftentimes i would have probably recognized that 50 of the stuff that i was really chasing was maybe not so important you know for the bigger picture so absolutely agree with that um the other thing that i'm seeing is and the biggest issues that are that i'm hearing about are always related to other humans uh if i if i may say so so it's usually you know uh how the cto is dealing you know with his peers on the executive team with other team members with business partners etc um it's very much about working together speaking your mind you know taking new directions dealing with other people's ego dealing with your own ego resolving conflicts you know firing people procrastination and all of that um maybe to illustrate this a little more

uh i like to quote a client of mine that recently told me 12 hours of like or recently you know said 12 hours of coding don't worry me uh but one hour of people does right and and that obviously made both of us laugh when he said that but um i think there's a deeper point that that he's making and and and to me that is that the gist of what many engineers feel the business world looks like is you know that managing a machine you know like communicating with a machine as in like you know writing code putting input into a machine and having you know a very predictable output on what the machine does you know there's a causality chain that they are very used to and this is something that generally makes them comfortable um managing humans uh oftentimes comes with high levels of discomfort because at least that's what i often hear from from an engineering point of view humans are inherently unreasonable and unpredictable and and have all of this

additional stuff going on and and and it's sometimes you know really hard to wrap your head around it's like hey i think we agree two plus two equals four so why are you not just doing this you know what's getting in the way and why do i have to deal with it right um so that's actually you know goes back to a more you know scientific if not binary approach again and um that's a lot of what i hear and a lot of what uh you know my my clients struggle with and a lot of the situations that we work through together now i actually really liked what you said and i think it's very true like the one anecdote i i i had about that because like um what i've noticed and i it applies to me but maybe it it it it is a it's a broader insight into sort of what the engineer's mind is like i think engineering is all about creating order in chaos it's all about organizing it's about cleaning up your room and it in in cleaning up your room is is a it

is in a way exerting control right you have to control the chaos whether that is you know a a source repository of many thousands tens of thousands of files you have to create create this in you have to make sure that this entire bowl of spaghetti somehow stays structured in a way and and that's hard and and i think the engineer's mind like the perfect engineer's mind is all about the enforcing control on the environment and creating this uh order where sort of the natural laws of uh entropy would create chaos um and and i think that's why often uh sort of the stereotype of of of engineers or or or uh technical people having difficulty working with other humans comes in because it is a much more chaotic process like there are as you say a lot fewer um predictable elements to it uh

and i yeah i think that's and it's that's very true um uh also to to bring it back to you know how how hiring and growing your team is is one of the extremely important elements of of being a good cto or or a general starting a company and and even from my own experience like i think there's been cases where i've hired great people that for some reason just didn't work out and it wasn't because they were bad people it wasn't because they were bad at their job but like something in the collaboration or in in in the way we worked didn't gel and then it can still create a very chaotic process that actually even to myself was very unsettling and very uncomfortable because i didn't know how to like you know you know uh untidied a bowl of spaghetti to make something structured and and comfortable out of it again um anyway that was that was the one thing i wanted to uh you

know uh add to add to your your comments right and nicholas like one of the questions i have for you is that i think the point you raise is certainly relevant and as a former engineer myself i can say that i had zero social skills coming from a technical background and so when you think about technical leaders at companies that may not have this these social skills which is more art less science and you've got technical people who are more oriented around that science aspect as tommy was alluding to then how do you bridge that gap as far as you know if you're a technical leader and maybe but maybe you're not great at managing maybe you're not great at giving feedback maybe you're not great at if there are two members of your team that are having a conflict you're not able to help resolve those conflicts and you know you're just more of a you know hermit crab or something like that like what have been some of the techniques or to kind of resolve that issue in a

technical team and then i think the other follow-on question i would have for you is like when do you try to improve the technical leader and then when do you actually try to give that technical leader a supporting cast or somebody else to help bridge that gap in the technical for for that technical leadership position whoa we're going deep here um but i think they're all they're all related so so let me take a shot at answering this um so first of all um as always no one size fits all i think the the the answer to your first question is like hey what's the magic trick here you know to to make yourself you know more social have more social skills you know be a more relatable person and leader um i think that that's highly individual what i can say and i think that's also related to the second question you were

asking in regards to you know when you know when is it time to try to grow an individual as opposed to when is the time to uh give that individual support i think it very much has to do with a mindset and the mindset goes back to leaving your comfort zone um and and maybe to illustrate that you know let's look at the other side of you know people in the tech world which are all the business guys right and and and how often have you heard something like this like i don't i don't get it you know the guy can code like the most magic thing ever you know why can he not be normal during that coffee shop meeting you know with the investor or something you know how hard can it be you know why is that so super awkward and all that and what business people oftentimes forget is that they have grown their social skills and their ability to you know keep up a conversation and you know relate to other people um you know make a lasting impression and and build relationships that's something that they have you know two or three decades of experience with right they started that probably as kids

or as teenagers right and it's a skill they've grown ever since and the same holds true for a lot of engineers on the engineering side it's not like they really only started that in college or in grad school or wherever right this has been like a lifelong passion i'm seeing the nodding here from our ctos um you know that has been going on for for a while so um it comes back to you know what's your comfort zone and where do you have a lot of experience now in order for you to evolve from an individual contributor you know to a manager to a you know cto level or something i think the number one thing that's required is the willingness to leave your comfort zone um you have to be willing to leave the relatively safe world you know at least to your safe world of coding by yourself in a controlled environment environment and and open up to the world of managing people which at first is going to be a pretty brutal experience right um that's one thing the other thing uh i

would say is from my experience engineers love processes right they love you know that there is a certain structure that might uh resemble a decision tree or something and i've read about this great thing and this is how we're gonna divide our team and this is how the workflow is gonna go and we have this self-prescribed idea of how we are gonna do that and um and oftentimes there is this idea that you know oh yeah we just adopt the right process and then you know all 50 people are going to go in there and that's going to be the solution to everything but what is often missed that no matter how well thought out and sophisticated the process is you need buy-in from the other people that are supposed to subscribe to this process and um that's i think the point i'm trying to make here being a leader and managing people has a lot to do with listening it has something to do with listening um with developing empathy with the

ability to put yourself into other people's shoes and with figuring out you know who am i talking to what is it that they need and how do they approach something there's two reasons why that is so crucial first of all unless i know who i'm talking to i don't really know what the right you know approach is and how i can help that person you know thrive that's number one that's the more obvious one the oftentimes less obvious one is the one that we as human beings all have needs you know we have the need to be hurt we have the need to be appreciated to be loved and all of these different things so if you want to open someone up right and and and get them to a point where where they are pushing the envelope forward right where they are going out of their comfort zone where they're taking on the additional project that they weren't weren't working on before and all of that things that leaders generally do it's very very important to relate to that person um and the way to get there is yeah to listen a lot to have empathy and to ask a lot of questions so um i'm not entirely sure if that really

answers your question but this is what i have seen and this is what i would always recommend as a starting point in order to evolve again at one thing uh from my recent experience and i think joseph has been kind of uh helping me with that uh i think if you don't have social skills that's not the most crucial thing you should uh you have to work on it that's good to have like uh as a cto you don't have to be able to give a speech like steve jobs where you know everybody's like wowed by like now you know i'm motivated but one crucial thing which you can practice and be better at and you should definitely work on is receiving and giving feedback so and that's that's very very important for any leader whether you are managing two people 100 people or you know whatever number that is and that's that's not easy because when you give feedback you have to be very honest and that's one of the values which we follow here is like you know give honest

feedback be respectful but it should convey the exact message it should not be sugar coated so much that it loses its meaning you have to if you see a problem don't shy away don't wait too long like the other person should not be surprised later on like hey you know everything was going well what happened like if you see a problem identify that point it out so i think that's one thing which is very important which we should focus on okay so one of the themes that we've been talking about and nicholas you you mentioned very specifically is this transition from individual contributor to manager to leader and so wondering if if i could ask you guys as far as some of the differences in terms of these roles and as far as your own transition i know tommy you started like very early back from very small company and so i think you've seen that full life cycle over a long period of time but it'd be great to kind of hear your thoughts in terms of that transition and maybe even specific issues that you may have come across as

you kind of shift it from one roll to the next and maybe starting with you tommy yeah it's a good question it's um let me think about that it it definitely changes a lot uh from from one phase uh to another i think when you run a startup it's you're so you're it is easy to actually miss the miss the moment of the transition um because uh as nicholas said uh uh reflecting back on his own career it's so rare that you take that you know a few hours a week to step back and like look at the big picture right if you want to start up your if there's always this sort of existential threat like or at least i have felt that where you're always running to the next milestone the next race the next deliverable the next product feature so

it's only in retrospect that you can look at the trajectory and actually either see where the transitions happened or even see where you in retrospect should have made that transition and didn't and that's why you know like you know in this phase of your company you had certain issues um looking back to my own career i i definitely went through the phases where you know very early on it was just like three founders in a single room we were all engineers and it was you know just do whatever needs to be done and then you get to the phase where the company is like 10 15 people and you start to have to work with other people and um and i think there's at least for me there definitely been cases where i didn't take that you know like two or three hours per week take a step back and look at what the company really needed out of me and i you know continue to be either an individual contributor to too long um or or didn't provide the guidance uh

to my team like as nicholas said you know like people all have different needs and i think there were definitely cases where i i didn't recognize that i think we all like it as humans it's very natural our i think our natural instinct is to look at the world through our own eyes right so i it's very tempting to just project on other people what you need or what you need it in their shoes and it's it's and that's not true right that is just whatever you needed at that point in career and and different people are very uh have different needs and um and there's definitely been cases where i just missed what certain people that joined the team needed out of me or out of the company or in in terms of their own career and um you know like i i think i was just in in some of these cases like too busy

running towards the next deliverable because of this excellent existential thread to to really take the time and notice so so that's definitely like one of the things that uh that if i if i could tell my you know my own if i could talk to my myself 10 years ago it'd be one of those things actually what what nikola said like take that one or two hours per week and sort of try to reflect on what you're doing what your real overall goal is and then you know both for the company as a whole as well sort of in the in the small with your team um [Music] of of what the team and what the individuals need i think my own role at super evil has evolved multiple times and i don't think just linearly it's not that like you always start out as an individual contributor then as a manager then as a so like you know hands-on cto and then as a hands-off you know management cto like it's i think different phases of the company

require different things and i i feel like some some phases of the company i was more hands-on and other phases of the company so the company required more babysitting more attention than the technology did and i and i switched roles in those those cases um even thinking back i'm not sure that i i can tell you why certain phases had these different requirements but um but it was definitely the case and it's like when you notice that it's important as a as a founder of a company that you can recognize that and and adapt your own uh contributions to what the team or what the company uh needs okay and avinash what is your experience been i have to quickly reset up the site okay go forward go okay i think we have to delay again yeah

i i just wanted to uh uh uh you know back up what what tommy said i i think you know hit the nail on the head here um it's it's there are no clear-cut differences you know between all of these different phases right like it's not so so first of all i think very very interesting comment is like you know hey thinking back of my own career i think i missed that point many many times in a row right it just like happened and i wasn't even aware of it so that's number one uh which i think is absolutely classic and it's like it's it's not like in the stock market where somebody rings a bell and all of a sudden you know we're off to the races here it's it's it's something that uh i think you're more likely to discover afterwards than you know the moment it happens and then you have to readjust and speaking of readjusting um i think for any c-level person you know or for for any lead in in a company especially you know in a fast-moving you know startupy or like say small company you know not like the

100 000 people company but but something that's you know much faster and more evolving and that in some ways you know feels like this this snake that's constantly skinning itself you know because as you also you know said tommy you know we're dealing with all of these existential threats right so either we are raising or we are we're going for the marketing campaign or we are we're trying to get the product out right or we have this catastrophic you you know roblox style meltdown where all of a sudden you know that that wipes out all other priorities right and and this is what you have to deal with and in dealing with the circumstances that life throws at you you also have to adapt your role in all of these moments right and you cannot just say well you know i recently transitioned into the role of of a hands-off cto and i'm not you know willing you know to to jump in the weeds with you guys anymore and figure out where the bug is you know this is this is not what your team needs in that moment and this is not um going back to another thing that you said tommy you know um you know maybe

i would want to be the engineer that would be left alone in that moment you know but my job as a leader here is to determine you know what these guys need from me right now completely regardless of what i would need if i if i were in their shoes and um yeah so you you have to you have to stay flexible and you have to adopt to adapt to the situation as needed sorry back to you uh joe and avinash so i mean uh yeah i mean this is a journey which you have to go through and uh it's uh i would say it's not easy transition like one fine day you don't switch from ic to being a leader and i would actually quote uh uh a book so in this group he has this really famous management book where he says the output of a manager uh is the output of the team so what i believe is like it's it's a mental model shift like when you are operating as an ic and when you you are responsible for you know a team or number of people it's actually a shift

in the way you change uh because as an ic you are always focused on what is your responsibility but now here your responsibility is like the entire game or the entire product is your responsibility so like what every engineer is doing is comes under what you do so you know that's kind of a very big mental model shape like that's how you measure your own productivity because you know as an ic we measure our productivity by how many number of lines code i wrote how many features i completed but as a leader your productivity is like you know as a team where i'll be progressing you know that's that's that's the mental model shift and the other thing uh and this is i think also very critical is as as a cto or as a leader you have to be aware of the biggest risks of your company i'm talking about the tech like you have to identify these are the biggest risk how do we solve them and and and then you are going to be the decision maker and as an ic when you make a decision you know you know and then you are not going to be blamed for that thing like if you choose a

technology stack or if you choose some technology you know like there are managers who will approve it but as a leader if you choose something like and then you have to own it so you have to be very very careful and you have to invest time in those sort of things so yeah i think from ic2 this thing is also a ownership realization as well nicholas do you have any other thoughts or should we move on to next question yeah if i'm if i'm honest i have i just like that those guys are just saying great things so so i feel uh if you feel the need to add a little to that um i i wrote this quote down the o the output of the manager is the output of the team right which is you just said you know that's that book and i i couldn't agree more because i think the goal for any team always has to be that the team is better than the sum of its parts right um which goes back to you know individual contributors um as opposed to you know coherent team and um

and and being better than the sum of the parts cannot just be achieved by adding up you know skill sets within the team it's just like you know joey does this and nancy does that and carol does this and all of that and then everybody you know is is is off to you know to their own tasks and skill sets uh skills and and you know completing sprints and all of that so the team needs to be coherent and and then there's always the question well yeah you know which i think goes back to the social skills so how do you make it team coherent i'm personally you know not a big believer in these pre you know described methods that are supposed to get you there right like the classic you know hey let's do the team event and we go rock climbing and zip lining and you know this is the team building because if i'm holding you know the rope while you're you know um hovering over the canyon you know then that builds fantastic trust i mean you guys are laughing but i think we've all been through at least one of those at least i have and it's always like oh my god

right um so just because we were talking about quotes uh a minute ago um one of my absolute favorite leadership quotes and if any of my clients listen to this right now they're going to roll their eyes because they've all heard this before but it's it's from max dupree um who is the former ceo of herman miller uh the the furniture company so you know different ball game but he once said the first responsibility of a leader is to define reality the last is to say thank you and in between the leader has to be a servant um so what to me what what the pre is saying is this so first of all to be a leader you need to be credible right um you you need to because without credibility you're not trustworthy and not a lot of other things so in order to be credible um you can only be credible if you cut all of the bs and if you start defining reality which goes back to what avinash has said you know what are the biggest risks

right the reality might be you know we are considering library a versus library b right now once we've made that decision we are committed and if it doesn't work out it'll throw us back six months you know that's the reality that's something that we are dealing with right now and um i think the opposite of defining reality is something where um [Music] where you have somebody who has a tendency to avoid inconvenient realities and hard conversations and i think those people have never been named outstanding leaders right like people that shy away from the hard stuff which goes back to what avinash said it's like hey we're working a lot you know at leela on you know giving and providing feedback right these things should not come as surprises which once again goes back to defining reality where we are where are you you know how can you contribute and how can you improve um and so just to tie this up as a leader um the performance metric that that you have right like how well are

you doing on on a scale from zero to 100 is really the overall performance of your team and not anything that you do individually so your job at least from my perspective is to do whatever you can to create an environment that allows people to thrive and to collaborate um and that can very much be you know as tommy said i'm leading by example i'm you know working you know really hard i'm contributing a lot to our code stack right and and i make myself available you know as a as a very experienced engineer to all of you other guys um but there can also be other styles and and i think that's a highly individual decision but you know speaking of the three hours a week you know zooming out what am i really here for what's my job well i want to build a coherent team the performance metric that i am looking at for myself is the output of that team and in order to improve or optimize the output of the team what i have to do is

create the environment that allows the team to collaborate as well as it possibly can and for all the individuals to thrive and um i think that's the that's the leadership style style that you know i i like uh just as a as a starting point uh in order to yeah like be any sort of you know c-level person not just the cto okay great so as a next question i wanted to actually ask about the focus and maybe more the day-to-day as far as you know in terms of the cto or technical leadership position so maybe tommy and avinash like as far as how you're splitting up your time or your focus whether it's between tommy you mentioned you do a lot of hands-on so actual coding versus focusing on let's say processes or recruiting or other specific tasks i was wondering if you could kind of give us a breakdown in terms of what that focus looks like and what that kind of day-to-day looks like

maybe on a like a percentage basis or something like that and then maybe nicholas a question for you would be you know after you hear this maybe you could also give your thoughts on it and maybe some other some other tasks or issues you think that a cto should be spending time on for example like a retrospective or something like that for three to four hours a week or something like that but again sorry starting with you thomas organizing rock climbing intensive yeah it's a good question um so i earlier i described myself as a as a sort of lead by example and fairly hands-on uh cto which i think is true the little nuance there is that i think that there is a there is there is a slight difference between how you mentally think of yourself and of your skill set and what you and again in different phases of the company actually end up doing so i would say that you know i i even to this game and as i said we're about 10 years into the company um

i vary from month to month between either between probably being 30 percent hand on contributor and 70 management and the as well as the exact opposite like if i'm in the middle of like a real a feature and i'm sort of like in in a good headspace and i feel like i i need to be the individual contributor working on this i might be even like 70 individual contributor and like 30 of my time sort of management and and and guidance so it really sort of ebbs and flows with what the company needs what the features are that we work on there are certain things that i feel that there's many very capable people in in some areas even more capable people than myself and our company that can work on those things and there are certain areas of code or certain problems that i feel deserve my own personal attention so it sort of so it really just eps and flows again like sometimes

thirty percent direct contributor sometimes 70 direct contributor and then in a very practical way like how my day typically flows um we are a distributed company so we have um oh actually since the pandemic we are a distributed company and and uh and and and given how the last two years have actually gone we've decided to keep it this way so uh pre-pandemic we had our majority team in an office in san mateo and then we had a couple of satellite locations all around the world either people working from home or or a little bit like clustered together in like small offices um but now that we're distributed um and i have team members in like south america i have team members in in europe typically my days start with essentially just one-on-ones like reviews of the work that they've been working on things that they want to bring up things that they've built overnight

while i was asleep and they just want to sync up with me tell me like where they are any of the problems they're running into and then we sort of like flow into the morning which is a more company-wide like sync up and and calls and meetings then usually my afternoons are uh are mostly direct contributor focus so this this afternoon depending on how long my mornings last can be anywhere from like 30 to 70 and then my end of day is usually making sure that uh you know for the next day night cycle for people all around the world people are not blocked right so like i make sure that um whatever additional tasking whatever additional support or documentation or explanation that people need that i know will be working overnight did i write that that i you know either record a video or write it in a ticket

or on slack or maybe even some calls with if people are still awake and i make sure that i do that um during my my end of day so that's sort of my very practically speaking what my what my what my day looks like got it yeah i think it's uh totally need of the moment so i would say right now i'm in uh 70 30 ratio 70 hands-on and 30 management and sometimes you know very rarely it goes off mostly you know when we were recruiting you know we were interviewing like six seven candidates a day so you know that's like you know six seven hours of interview assignment evaluation so uh that goes on one thing i have always found very helpful is uh so you know i have certain expertise in terms of when i code for example you know these are the kind of features where i'm really good at and i generally try to pick up those because you know because as an engineer i can do better in that area but recently i

realized as a leader if you can work on any part of the game so like you know if somebody is working on less for example ui framework what i would try to do is i will just take a small feature of that ui framework and work it by myself what it gives me like one is as a leader you are just aware of high level things like hey this is the framework this is what it does but once you build something on top of it by yourself then it gives you so much you know in-depth experience you know you you should be part of code reviews you should also so that's i think something which i i always prefer uh doing like you know actually building being part of the development process itself of every area of the game whether it's like ui gameplay or anything else so so yeah that's that's that's like really helpful nicholas what do you think well first thing i think is that as far as what tommy and avinash are doing you know on a day-to-day basis you know i would not be you know in in the position

to you know um you know say that that's right or wrong or anything like that you know also these ratios because as both of them said it highly highly depends on what's going on right now and i think the the example that abhinav gave is great you know if i'm hiring right after doing seven hours of interviews a day you know like like which is absolutely part of my job you know as the tech lead of this company you know i'm obviously doing way less you know but if you know in a different phase you know where it's crunch time we're trying to complete you know a certain sprint um and we have like four days left and you know maybe there's even something that i very much enjoy doing that i'm really good at and fast obviously i'm gonna pick that up so so i think you you have to stay flexible there what what i can you know if we're going back to the zooming out thing right what i can say there is um well essentially two things the one is for yourself i i believe self-reflection um

you know is is very important and that i know that sounds super new age and life coaching and all of that but i think self-assessment is is is a really good way to you know figure yourself out you know understand what it is that that that you like that you dislike you know what's your comfort zone and all of that and what what i've you know recently done um with a client was you know i just asked him hey just think about what you've been working on for the past 10 days right and then you know think about all of these different tasks and you know write them down and then ask yourself you know what did i enjoy the most and then also ask yourself what did i enjoy the least you know what was dreadful you know write these down and it's going to be relatively surprising you know what what makes it on you know the oh this is what i really enjoy list and then also this is like what what i didn't really enjoy this and by the way you know any leader any manager you know this is not a cto specific thing that would work for anybody but it's still interesting to see what lands on these

lists and then the goal with that is not to become you know super judgmental and say oh yeah you know this went there again and man i wanted to be better at this you know five years ago and here we go um it's more to understand you know what's your comfort zone and what's challenging uh to you and then i think the next step is you know see how this all feels in light of your responsibilities and your job title which i think goes back to an earlier question that you asked joe you know when is a time for somebody you know to start you know like like you know rolling up the sleeves and you know making a real push to evolve as opposed to when is it time for somebody you know to you know bring someone else and have a helping hand and then also i have seen people in cto spots that two years later said this is just not the job i want to do i'm a co-founder here right but i enjoy you know programming and being an individual contributor and i think i'm way better at that than at this whole people management skill thing so let's just bring in someone else and i'm

happily have that person manage me but i don't want to be that so self-reflection and some self-assessment i think is really good because not always is you know brute force and you know trying to you know make the right-handed person a left-handed person or vice versa the the real way forward i think it has a lot to do with you know what you're willing to do and what you're interested in and um it's you know it also goes back to the old question what's more important to overcome your weaknesses or to play to your strengths right and i think that's also a highly individual topic smiling right now right a highly individual decision you should look at so that's one thing as far that's the inbound uh you know piece of uh i guess advice that i can share um on more on the outbound side you know towards your team and the people you work with um the number one thing i can say stay curious uh that is super important right literally you know stay curious stay humble ask a lot of questions and own it right

own the feedback that that you're giving to people the feedback that you're receiving own the decisions that you are making paint a clear picture of reality and stay curious as in you know you always try to figure out a little more of you know how this team works what what people need how all of this is going because that in itself will allow you to grow more than i think anything else and what it will also allow you to do is um is is to be more empathetic towards your team members but while being more empathetic also trying to be less emotional yourself right because that's really you know this like uh you know you want to be that steady rock you know to the highest degree that you can you know that is always open you know to feedback uh to hearing about you know people's problems and whatever is going on but that ideally doesn't get unruffled

you know in in light of having to deal with all of that so to sum up um self-reflection and self-assessment on the inbound side and staying curious and being more empathetic outbound that is quite powerful and try it for a month or two and see where it takes you great thanks nicholas so just to kind of wrap up this conversation i thought maybe the last question i could ask from the group here is you know what would be in your opinion maybe some of the biggest the one or two biggest lessons learned or advice that you would give to a new technical leader that you believe could be the most helpful for them and again since you're first in my window starting with you tommy i feel like i get the first pass and all the questions really these are hard questions man um what is what is what is good advice that you would give

someone um before i forget i actually i was i was laughing when nicholas said uh i i you said it so eloquently it's uh what what is more important uh to overcome your uh your weaknesses or or play your to your strengths i don't think i've ever formulated it like that in my in my mind i'm sure you know it's it's uh it's maybe it's it's common wisdom i think that that's extremely insightful uh i just wanted to call that out like that is so true um and uh i might have to like take my two hours this week and actually reflect on that one i think that i know where i met out but but it's still it's a it's a very interesting you know you know how some some statements are just like really straight to the point into the core and they just make you reflective well like that that isn't that is an important consideration and i think they are different for different people and like there's different pros and cons to each approach anyway um advice uh

advice oh man okay let me just throw out a couple bullet points stay humble in your own approach uh stay flexible in your own needs to yourself and also what in your role uh to your company what what you bring to your company it has to change over time and be cognizant of that and try to it's gonna be hard to preempt it but like you know take that one or two hours a week to try to reflect on you know whether that the contribution that your company needs that your startup needs that your that your that your product needs is changing at the moment and whether or not you need to change your your contributions uh you know like if you are in your comfort zone being a direct contributor maybe that is not what the company needs right now make sure that you are aware of that uh and then and then try to adapt your your contributions

third one would be hire good people uh and that is much easier said than done um i have hired some absolutely fantastic people i've hired some people i deeply regret it and everything in between i've also hired people that were great people and it just didn't work out for all sorts of reasons sometimes it was my fault sometimes it was a i think it was a it's like you know like a a dynamic between either me and the person or even between other people on the team um and and the final thing is like uh we we said about um we we talked a little bit about like always having this um this fire on the horizon like this this this existential threat and there's two sides again to that like um hey it's really it's really tempting to to to to be sort of enslaved to this constant fire on the

horizon uh because it it it it is a real threat um and you have to uh there's a real risk in in in in in just responding to that fire all the time but then there's the other side and i think there even to this day like i don't know that i have the answer in this area that existential threat on the horizon is very real all the time so it's easy to say like you know don't be led by it but at the same time i mean that fire better not catch up with you because if you are a small startup like i mean that is life or death for you so there it there is no common part like it i find it sometimes a little bit too easy when people say like oh you know you just have to you know like take the time and make sure you do the right thing uh and you know don't be distracted by this fire but it's like i'm like dude my house is burning down like i

need to not like i need to focus on this fire and um and and so to to to take it out of the metaphor and into the the more practical um is as a as a technical leader or as a startup founder in general i mean this is a marathon and it is it it is a it is a fight every single day and and um if you you know let go of that fight if you if you ease into it you know that is a real risk as well like you have to be aware that if you are not working incredibly hard if you know if you are not delivering on your milestone if you are not pushing for this like you know public beta that you are supposed to like put out or this release that you said you would have you do next year someone else will and um and and that's just it's there there is no i think there's no real lesson in that there's no uh right or wrong way of doing it but know that time is

you know time is not on your side when it comes to like startups like money is running out uh other people are uh you know creating competing products and it's just it's it's a really tough balance to hit um just be aware of that be be aware that that is uh something that will be on your path and something that you will have to deal with and uh i don't think i have any deep insights into how to do that better but like i always think that you know uh being aware of something is like step one so let that be my one learning in this like at least be aware of it and then you know you will have to figure out the rest yourself avinash lessons learned advice whenever you talk yeah i i get enough time to think [Laughter] so yeah we actually covered most of the things which are personal learnings for me but two things i can specifically

pinpoint one is uh this advice which you always get is you know hire smart people most probably hire smarter people than you so this also comes with a challenge as a leader is you have to be very open-minded in terms of uh the the this control nature which engineers generally have like they have this certain belief like hey this is the right way of doing things and if someone proposes you some other solution your first reaction is no no you know this this way is better but you have to let go of that you know you you trust like when you hire someone you have to trust that person you know let them do think deeply about like what the solution is so i think the one message like you have to be open for new solutions and evaluate it truly and then decide like okay maybe the previous approach which i knew is better but don't just blindly you know take the call like hey no we already did that that works you know let's let's not try something new so that's one second which tommy actually touched upon it is as a leader you have to be aware of the progress of your company

on technical front like if you set out a milestone to release a game in one year it's been four months somewhere you you will have better insights than your for example ceo or anybody else than where actually you are and you have to be aware that of that and you have to make actions you have to take action if you are you you are sure like hey we are not going to hit them this milestone in one year you know you have to communicate with your team and you have to do changes or make it clear like hey guys you know this is not going to happen in one year this will take four more months or five more months let's do changes if you want to push it in one year so i think that's that's one very critical things which you have to vary aware and you have to take action on so yeah all right nicholas as a coach i'm sure you have a lot of advice and this is sort of your bread and butter so great advice what do you got we are all we are all listening right now yeah exactly and and and and now you

know other coaches out there would say you know coaching is the exact opposite of providing advice so be be careful what you do um a couple of things i i i still want to say so um first of all [Music] i think some general startup observation whatever screams the loudest is not necessarily the most important um i wholeheartedly agree with tommy uh you know whoever tells you it's like no no no man you should just stay course you know persevere and blah blah blah and all of that if if you're going down and you're about to not make payroll not make rent you know houses on fire uh you know whatever it is there is no choice right it's just like you have to focus on this and you have to fix this problem or else you're out so um that's that's true but what you will see in the middle range oftentimes is that that

we are all biased to attending to yeah whatever screams the loudest whatever is the most nuisance in our inbox and all of that and and somehow that bubbles up to being the most important thing um more often than not and i'm guilty of having screwed this up many many times that is not the most important thing that you're working on this is this is just something that is you know a side plot and uh and and should you know deserves the attention of a side plot but this is not like your main mission or anything so if you can if you can zoom out which is hard with all of these different signals that you're receiving uh uh you know on a daily basis um take a moment or two and ask yourself you know what what the the number one or the top three things that you're working on right now are and try to focus on these um easier said than done but i think very very powerful so that's one thing the other thing i obviously have to respond to because both of our ctos have brought this up is like the challenges around hiring right

oh my god uh yes we we i don't need to argue here that you know whoever you hire and you know the the culture you bring to your team and how you grow that that those are some of the most important decisions you'll ever make as a leader everybody knows that um but one thing that i think is fairly tangible and that i might want to leave this with is keep in mind skills can be learned passion usually can't um i wholeheartedly believe that so there might be somebody you know that comes in and and that is absolutely super passionate about your product and you know that first person shooter that you're building and you know it's like oh my god i have to work on this right this is like my mission and all of that and then you say well you know how how how good are you with python you know maybe he's only because that's the programming language you know that you guys are using right now and then maybe you know the the answer is well he's only you know mid-level over there right and then you

have somebody else who's absolutely freaking excellent in python but he doesn't really care you know whether he works on a first person shooter or on a you know automated plant watering system or maybe you know in a paper company or something so who do you go for i mean it's a toss-up but you know i think you know having somebody who's really really passionate about whatever it is that you're doing that from my experience go further than somebody that has a great skill set but that could theoretically also be applied to a lot of other things because those skills like the first person that i'm mentioning you know if he really wants to he'll get excellent at python the other guy if he doesn't really care about first person shooters you know is he ever gonna get there not so sure about that so um i guess having the right people in the right positions uh for me is not so much a process of you know persuasion you know or forcing them into the role which is also true for you know existing team members i think it's rather a process of discovery which goes back to

you know the curiosity and all of that you know figure out what it is that people really want to do that they are passionate about that place to their strength and all of that and um yeah and and use that as the momentum um and keep in mind when hiring people because uh more often than not uh that goes deeper than some of the other things that we might be looking for in got it all right gentlemen well i think that's it and maybe like the one last thing we could end on is if anyone is interested in contacting you or if you're hiring and maybe nicholas you could tell us a little bit about your coaching service as well if anyone's interested but just to wrap it up as far as like the contact information tommy do you want to start yeah of course super evil mega corp definitely hiring lots of different roles go to our website i think most of them are listed there uh across all disciplines not just engineering uh but uh we have some in

production we have some in art many different roles i think even a qa role um are open so definitely go to superevilmegacorp.com check it out um yeah maybe i'll talk to some of you guys there all right so you know uh we are lila games and we are building a really ambitious shooter game and this is like this has been absolutely fun and challenging journey in one year so you know if you want to work on something really ambitious once in a lifetime opportunity then you know just apply at leilagames.com games.com so you know looking forward to talking to you nicholas yeah my website is so as people have figured out by now i i do executive coaching for ctos and ceos um clients typically you know from companies anywhere between five to let's say 150 people um that's my sweet spot

because i'm i'm a two-time recovering startup founder and all of that so you know speaking of empathy that's where all of my empathy is i i know what you guys are going through my website is eight so the number eight bit coaching dot com uh as a shout out to you know the 8-bit consoles you know of the of the of the 1980s um i think there's a calendly link there that you can click you know i i happily do you know free consultations if you just want to get to know me and you know figure out the way i work and all of that you know casually um we can totally do this so yeah 8bitcoaching.com all right guys thank you so much for your time and your insights i thought this was super helpful and for the rest of our audience catch you guys next time bye everybody [Music] do [Music]

you