#229 - The Management System for High-Performing Engineering Organizations - Michi Kono

[00:01:27] Introduction

Henry Suryawirawan: Hello, guys. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me a CTO at Garner Health. His name is Michi Kono. Today, uh, we plan to talk about, a lot about, you know, how to grow and scale engineering team, building cultures, and things like that. Michi particularly also has some tips in terms of building some kind of a management system, engineering management, things like that. So, I’m really excited to have this conversation today with you, Michi. Welcome to the show.

Michi Kono: Great to be here. Thank you.

[00:02:10] Career Turning Points

Henry Suryawirawan: Right. Michi, I always love to invite my guests first to maybe share a little bit more from your career. Any turning points that you think we can learn from you?

Michi Kono: Great. So early on in my career, I used to worked at a, a few startups and one of the things that I realized is that, you know, when I was looking for roles, I applied for a role once. And my friends had told me I’m not qualified for that role. And I ended up getting the role. It was for a lead engineer position, and it was actually a big turning point for me, because that startup did really well. I was one of the early hires and it sort of started my journey into management. And so I always tell people, don’t reject yourself. Like that’s someone else’s job. What’s the big harm in, you know, interviewing and not getting the role? And so I look back at that moment as like one of the most important decisions in my life.

Henry Suryawirawan: Cool. Yeah, that’s very good thing to, you know, give as an advice, right? Because sometimes when we get rejected, we kind of like put yourself into the box, right? We think we are not good enough based on whatever feedback that people gave. So I think thanks for sharing that.

So maybe if you can a little bit, dig a little bit deeper into that particular role, right? What makes you actually think that’s a career turning points? Is it like the kind of growth, the kind of learning, the kind of opportunities and things like that?

Michi Kono: That role at that company wasn’t a CTO role, but it was the first sort of IC engineering role. And so I ended up writing the whole code base. And because I was the first on the team, it sort of led to opportunities to lead the teams. And over time, eventually, I was promoted into management. And you know, that was very early in my career. You know, I’m not necessarily saying that was the right time for me at the time, but it was an opportunity that I wouldn’t have had, and I certainly wouldn’t have had that if I applied for the outside as a manager, for example. And so just taking a bet on myself there was pretty important.

[00:03:55] Skills Advice for Engineers

Henry Suryawirawan: Yeah. So I think, uh, if I saw your career, right, so you started from this startup, it got acquired, and then you moved on into, you know, bigger companies like Capital One and then Meta and then Stripe. And now to Garner Health, right? So maybe from your journey, right, it seems like pretty unique and interesting, because you have seen, you know, being acquired in a startup, right? And working in a big tech, a big enterprise working in a, you know, I dunno like, financial services and now in health. Do you see some kind of, I dunno, like skill sets that you think you learn from when you are younger up to now that is still pretty relevant regardless of industries and companies?

Michi Kono: I think the most important theme, maybe we’ll see this in other parts of my answers is around just communicating well. A lot of times as engineers, we can be really focused on like, how to write the code right? Or how to build the system, and then maybe not solve the problem when you finish building whatever you’re building. And that was something that I learned early on, I think. First of all, I did some consulting at one point and that was very helpful ‘cause that forces you to focus on like what the client wants.

But also, uh, I remember, so yes, my startup was acquired at one point and I joined Capital One. And it was interesting because Capital One was kind of in the middle of acquiring a lot of startups at the time. Little acquisitions, not, not huge ones, but they were just kind of trying out the whole acquisition thing. And there was a small community of us, sort of people that were acquired. We were all about the same title. We all were about the same company size, same org level size.

But I remember speaking to most of my peers and all of them were just waiting to quit. They were all just, they were just there to hang out and then leave in 18 months or whatever it was. And I remember thinking distinctly, and I told my team, hey, you know, we’re here regardless for the next few years, so let’s make the best of it. Let’s commit to being here and understand what it means to be in a bigger company. It’s not like being in a small company. There’s skill sets here that we probably don’t appreciate, and so let’s build on that. And so that was, um, and I would say that’s like maybe a second big learning was really committing to a situation and, you know, embracing the things that seem kind of bad from the outside and making sure that you understand what, you know, maybe if it is bad, you get to understand what makes it bad.

Henry Suryawirawan: Yeah, i’ve heard about, that huh? Sorry.

Michi Kono: Like, it wasn’t bad. I was there for five years, so it was a great employer, just in case people might misinterpret what I was said there.

Henry Suryawirawan: Yeah, I’ve often heard about this story, right, when people got acquired. So there was, they would have to spend like a certain amount of years, let’s say one year, two years, right, in order to serve within that company. And I always heard that people think, you know, it’s like the free time for them, right? You just roam around, you know, do maybe less and, you know, think of your next adventure. So I think thanks for, again, sharing this important advice that probably you should commit, right, whatever journey that you are in the company, right, and try to make some contributions.

[00:06:46] The Challenges of a Hypergrowth Company

Henry Suryawirawan: So today the first topic that we want to talk about is about scaling and growing engineering teams. I think now that you are working in Garner Health, you are experiencing a rapid or hypergrowth in your company, right? So tell us first of all, like what kind of challenges that you typically see within such a company, right?

Michi Kono: I think that as you grow very quickly, people’s roles evolve. That includes even my role. So like it’s very different if one person is writing all the code, like I was at that one startup. And at some point, you’ll cross a threshold where nobody does the whole code base. Nobody understands truly what’s going on across the business.

And so there are both, uh, knowledge, like sort of the way you operate changes that have to happen, but then there’s also like a much higher overhead for like communication and coordination that happens. And if you don’t adapt to that as it happens then, you know, your career could stagnate, or in some cases, you know, you won’t make it in the company. And I’ve seen this pattern, you know, usually the ICs tend to survive that, because they can just become a master of the domain that they started with. But a lot of times, managers who are managing those teams can’t sort of shed the skin of what they were good at in the previous role and adapt to the new circumstances that the company’s in.

And there’s some rules of thumb for that. But the way I think about it is each new layer of management you add substantially changes the job required for success in that role. And so sometimes people will say, oh, great, I’m managing managers now and they’re focusing on learning that skillset, but they haven’t realized that the whole environment of how they operate with their peers, everything has changed. And so this happens very rapidly over the course of, you know, it could be 12 months, six months even sometimes, right, if you think of a doubling, a doubling out of a layer.

And I’ve seen that like normally, you get years, right, in a corporate environment you can spend years working and then get promoted, and you can kind of see someone else doing the job and you kind of copy them. You don’t get that. Like this happens almost in real time and everyone together is getting a new job. I always tell people, like my old manager, Nick, the CEO. His job substantially changes probably every year. And so the job that he was doing a year ago, all of his lieutenants have to do now. And so in some extent, we can copy each other. But sometimes the leader that you’re copying from may not make it. And so that sort of mindset that you have to constantly reinvent yourself, I think is a cool opportunity for being in a startup. But it’s also sort of the risk and reward of the situation.

[00:09:09] Learning and Growing in a Hypergrowth Company

Henry Suryawirawan: Yeah, this is, I think, one of the main struggles that I can see often, you know, people in this type of companies, right? I personally have experienced working in such a scaleup hypergrowth company, right? And it’s always difficult to, you know, continuously evolve yourself in such a rapid time, right? So for example, maybe this year you’re like, I dunno, 50 engineers. So maybe next year, it could be double and more than that, right? Especially as the business grow not so much in terms of just the size of people, but the size of problems, right? The domains that you’re dealing with. The size of maybe, I dunno, like solutions, services and all that. And I think the size of counterparties as well. So there might be new leaders, business leaders, tech leaders that are also hired along the way.

So I think if you can give maybe some tips for people who are experiencing this kind of stage, right, where they have to keep reinventing themselves, you know, over a certain period of time, what will be your best advice for them to actually learn and grow along the way?

Michi Kono: I think the first thing is to never be complacent of your past success. Like I said, the people who are most likely to not make it in these situations are actually the managers. Maybe I could be wrong. We can pull some numbers and look at it, but that’s just my two cents on it, is that their job changes the most. And so you have to operate from the mindset, you’re always basically sort of auditioning for your job, not because you’re bad, but because the job that you’re auditioning for is constantly changing and it’s literally a moving bar. And so you just have to stay humble to what you’re good at and say, hey, you know what I’m good at last month is no longer.

And then don’t forget that we’re also in a technology org. So in parallel to that, the industry is also shifting. And a typical vast period for someone might be four years, right? So in four years, tech changes enormously. Like four years ago, I wanna say ChatGPT had just come out, you know, there was no such thing as AI, right? As a, or at least, it’s at scale in the industry. Uh, and then four more years prior to that, like ML was hardly being utilized at scale in most companies, right? That was like if you were doing ML eight years ago, you were, you were a hot startup.

And so I think in every company, you have to balance both those things. You need to be innovating. And so just in the same way that when you first joined the company early on, the tech engineering systems that you had overseen were state of the art in four years or not. And so either you’re part of reinventing those systems or you’re part of the problem. And so in those ways, like you have to just constantly be looking at yourself and the systems that you manage critically.

Henry Suryawirawan: Yeah, I can, uh, actually relate to that thing that you just mentioned, right? So in the past in that previous company, right? We do have a solution, right, that we built, you know, from the, from zero, let’s say. And then over the time, right? It brings business, it keeps the company growing, but at certain point in time, it actually creates a lot of bottlenecks, right? Maybe challenges in terms of growth. Challenges if we wanna even keep on scaling it up, right? So I think as the manager or people who have experienced that before, right? I think it’s really important to actually know, you know, how to evolve your system, how to evolve your team such that you can keep on continue scaling. And you don’t slow down in terms of pace, which is, uh, what I want to ask you next, right?

[00:12:07] The Slowdown in Engineering as You Scale

Henry Suryawirawan: Because typically when people grow, we think that we will just indefinitely grow so fast. But I think one important phenomenon that always happen is that as you scale larger and larger, actually typically, the engineering delivery or maybe the output right, becomes much, much slower. So maybe from your point of view, do you experience the same thing? And if so, what typically are the root causes?

Michi Kono: So yes, delivery can slow, although I think the true slowness comes when you’re much larger, where the average person just doesn’t have an understanding of what the big picture is. But I think that it is still, again, sort of the inability to reinvent yourself plays a role for sure. Maybe triaging less the symptoms, but more the incentives I think are important. So like a lot of times when you’re really small, everyone understands what they’re supposed to do. You may not even have to assign work. People just sort of do the right thing, right? And then as you get larger, people no longer can do that or at least very few people can do that, right?

And so I was, one of the things I saw at Meta in particular that I really liked, inspired maybe by, was that they ruthlessly hold teams accountable to outcomes. And so what I mean by that is, you know, I’ve worked at employers, most employers, in fact, where you’ve got this big deadline, you know, let’s call it end of the year, you’re working towards it. And you’ll celebrate getting the coding to production. Say, hey, we shipped it, right, and that’s your, that’s your success finish line. And so maybe you ship it on December 31st and you win. Like and then you all get promotions and raises, right? But at Meta, that would be considered under expectations. So they look at the outcome. So what’s the outcome that you’re doing for the business? And so shipping code in itself is zero outcome. No. Unless the system is being used, right?

So I remember a situation where we shipped something to production. There was no traffic on it, but it was celebrated, right? But at Meta, I remember a situation where a colleague of mine had spent six months working on a system. They shipped it at global scale and it had, you know, a couple hundred users a month using it, which is considered like basically non-existent. And so even though they had worked six months to ship it and build it and deploy it and get it used, they ended up getting a below expectations rating, because the outcome they were being held to was that this metric had moved or whatever thing was in that team. And obviously that sounds terrible. Like you could spend six months deliver everything you’re supposed to do, and yet you get below expectations.

But what that did, if you zoom out and think about what people do in, you know, as individuals is when you get assigned work to work on this thing for the next six months, you will audit that. Be like, well, hold on. Is this actually something that’ll get used? Is there a way I can ship something in two months, maybe test the waters and if it’s bad I got four more months to work on something else. Like it really creates the incentives down at the individual level to really understand the picture. At least, you need to understand the big picture for your part of the work in a way that I think creates global outcomes that are optimized.

And so I always thought about that of like there’s gotta be some, like, I think Meta, maybe it does it to an extreme that can be quite stressful. But I, but I always thought like that’s, that mentality of holding engineers accountable for the outcomes ultimately helps them make better decisions and really empowers them. There’ll be times where I saw engineers who would say no to their own leadership ‘cause they would say, hey, you’re gonna put me in a situation that I don’t want to be in. This is not okay. This is a bad idea, we shouldn’t do it. And that kind of stuff you just don’t see anywhere else. But that’s, it comes from the incentive structures of be holding them accountable if it goes poorly.

Henry Suryawirawan: Yeah, that’s exactly what I wanted to ask the next, right, because in many organizations, typically also sometimes the order or maybe the instructions are given from the top, right? The top feels that this strategy might work. You know, you just go and deliver. You know, here are the set of high level requirements. The teams need to translate that into whatever shape, and then they just deliver it no matter what the timeframe.

[00:15:55] Designing Organization Structure Well

Henry Suryawirawan: So I think with your explanation just now, right, I think this probably could not happen because you know, sometimes, uh, I mean as engineers or maybe the product managers within the team, they know that sometimes these ideas are not working. And because of that, right, actually people are reluctant to work on it. So tell us maybe in terms of changing the culture within the company, what should the top management do much better in terms, I dunno, maybe give more independence or maybe the team should push back a little bit more to the management. I think this all comes back to the culture as well. Maybe a little bit here as well.

Michi Kono: One of the things that we emphasize here at Garner is to design your orgs well. Like you start with what does the shape of the team look like? Not who do you have and what, where do you put them? And so that’s an alluring concept in a startup. You, you’re a small team. You’ve got four people, like you give them each one thing and you know, you have an org chart, right? But as you grow, and it’s easy to sort of keep that model. And so you’ve got this person in charge of something and they stay in charge of it.

But what we start doing in the company as we’ve scaled and said, okay, hold on, where do we want to be? What are the boxes then the org chart look like? And then you put people in as best fit. And that might, what this does is it starts from first principles. And so there could be a reorg that gets caused by that. But the idea is that you’re evolving your business based on what you actually need, not so much who you have right now. ‘Cause you can always hire more people to fit the right skillsets that you’re missing.

And so how this relates to your question is that org charts sort of, they dictate both incentives. They dictate like what people prioritize. And so if you create your org chart in such a way where teams don’t have autonomy, you create huge problems. I guess like an extreme example is each different type of engineer reports to a different manager, right? So you’ve got like a QA engineer, a frontend engineer, a backend engineer, and they all report to different managers, right? So you’ve created like a very complex matrix organization, and that makes sense. Like your marketers are marketing, your… sales people are in sales, obviously. But the problem is that if you’re not careful with how you structure that, you’re creating overhead in a way that makes coordination difficult. And more importantly, different managers might prioritize different things. And so you can imagine the extreme world where two managers are just incentivized to do two different things, and then you have bad outcomes occur.

[00:18:11] Effective Organization Chart Tips

Henry Suryawirawan: Yeah, so I think I’ve heard this from James Stanier as well regarding org chart, right? I think that’s the one of the most powerful tool in fact to actually shape the culture, that’s the first thing. And second thing is about, you know, the communication, the flow within, you know, one team versus the other. And matrix organization, uh, even though some companies are still adopting it, probably that’s also kind of like creating a lot of tensions, because like different managers will be aligned to different incentives, different outcomes, right? And sometimes for the IC themselves having to report to two different managers, sometimes it’s not easy and tricky to actually align what should be the work that they’re doing.

So I think org chart definitely is a much, much, play much bigger important role in any organization. So do you have like, I dunno, an evolution from a startup to a bigger company, a typical org chart that you would want to suggest people?

Michi Kono: Ideally, you want the manager to have as much autonomy as possible to deliver what they’re working on. In other words, let’s use that example of the frontend, backend, and QA person. Like you would just have a team that’s responsible for shipping a feature. Some feature that you’re working on. Let’s say, it’s update a button or whatever. And so they’ve, that manager owns the responsibility for designing the backend, designing the frontend and QA. Now, at some point that gets difficult cause the more further you go down, the more it’s like different from like the button push. The idea is that you wanna have the business sort of decision making to be in one place. And so eventually you’ll have some collaboration, but you wanna make those as minimal as possible in the places that are sort of not gonna have opposing interests, right?

So if you have two different buttons being worked on, and you have one engineer, that frontend engineer managed by someone else, you’ve now created a situation where you’re fighting over that one engineer, right? So you have to say, you know what, we’re not gonna, we’re gonna put that engineer in the team for button A and button B doesn’t get a team. Or it’s not. Or it’s under the same manager or what, and that would cause a reorg, right? And so the idea is that you’re designing from, first of all, like autonomy, but it’s also like what the business needs and that could change your gear.

And so you might see when you’re like, oh, this one thing that used to be pretty clear and straightforward owned by one team, over the years, it’s evolved and now two teams own it. And you might think like, well, maybe your options, you have two options. Either you acknowledge that it’s shared and you create a platform. Or you would do a reorg and move that scope into that. It doesn’t have to be reorg, I guess. We can move the project into one team and so that there’s no longer a multi-team dependency. And that’s greatly oversimplifying it. Like this is hard, like hard emotionally for people obviously cause you’re changing people’s work. You might like take someone’s project away, that’s their baby. But these decisions, if you don’t do it, can really cause harm across the org, because everyone is sort of, you know, handcuffed to inertia.

Henry Suryawirawan: Yeah, I like the way that you emphasize, uh, you know, aligning in terms of autonomy and also like decision making, right? So try to make as much as possible decision making centralized in one place, right, instead of, you know, having two different managers, two different teams trying to align a certain priority.

[00:21:05] Nurturing a Good Engineering Culture

Henry Suryawirawan: So I think in terms of culture as well, these kind of things, definitely not so easy to evolve, uh, especially when you hire so many people from outside, right, coming in. So, you know, growing engineering culture is always like a very hard thing to do, but it is a very important thing to do. So maybe in your CTO role currently at Garner Health, what’s your tips and strategy to actually, you know, nurture a good engineering culture? And what kind of engineering culture that you’re building anyway?

Michi Kono: So yeah, every company has a slightly different culture. For us at Garner, you know, we’re very mission driven. Our website has these values, and, um, uh, I would say like they’re not just marketing. Like we actually hold ourselves to them internally in a way that’s very hard to explain to an external person. But we live these values. And so there’s no room for politics.

Politics is another way of saying human, human social interactions. Like it happens, but to the level of, you know, deception or anything like that, you know, or ego getting in the way of good outcomes. And so one of the things we do, for example, is every time we mess up, we diagnose the situation to its root cause.

In engineering terms, you can think of that as like an incident review, but we do this for all processes. And the other thing is that it’s not blameless. It’s actually, like fully we try to figure out the accountable individual. It is not, not to blame them and fire them, but really to learn to understand. It’s just like an incident. Like we need to understand why did team push the button that caused the outage? Not just that the button got pushed, because there’s a reason behind that button push. Maybe the manager told them to do it or whatever. We need to understand that and so we can learn from it.

That’s probably the most unique part of our culture, in that it’s, there’s no room to hide about from this kind of stuff. We really make sure that everyone is operating in the clear and that we all understand what’s going behind the things. And we don’t let seniority titles or org chart determine who’s right. Like right is like a factual statement, not one based on like social hierarchy. And I think that’s probably the most important cultural thing that we do.

And then I think also from, uh, this gets maybe the management stuff, but I think a good engineering culture is one that focuses on engineering. In other words, the ICs. You know, we, as managers, we oversee the work. We might guide folks and coach people. But ultimately the person on the ground writing the code is these engineers. And if you forget that fact, um, and you manage top down too much, then really bad outcomes will happen.

I remember being at the bank and again, I love working at Capital One, but being at the bank, and there were times. There were explicit times I can remember where someone with a VP title would come into a meeting and say, hey, the API should be built this way, obviously. Everybody, you’re all wrong. This is how we’re gonna build it. You know, there was the, you know, you showed the executive leadership like two very good options, A or B, of like how to build something. And you always got option C. That was the joke. And option C was always suboptimal from an engineering perspective. And, you know, it was most of the time fine, like we’d figure out a way around it. But there was a couple times where I did literally tell that person, hey, you know, you said something that’s like actually nonsensical and it’s not right. But if I hadn’t said that, it would just have autopilot been approved and everyone would’ve just followed orders and we wouldn’t end up with the worst system.

And so that’s the extreme. We don’t want that. And so you want a world where your best engineers are engineering the right systems. And I think the only counterbalance is really the business outcomes because sometimes building the best system might take you four years. You don’t have four years. And so you have to balance that.

So at that part, I understand, but don’t let the manager’s 20 years of engineering experience overrule the two years of engineering experience, because that 20 years of experience was a decade ago, you know, and so it’s out of date. And so the two year of experience person might actually be more correct, right? And so you have, we have to evaluate the ideas, the engineering ideas for what they are, not like the title of the person who said them. And sometimes even, as a CTO, I say stuff and I always tell people like, I could be totally wrong. I know I have this nice title, but don’t take what I say as an order. It’s just an idea. You are welcome to tell me I’m wrong. And I, and again, going back to right diagnosing root causes, the last thing I want is the diagnosis of the root cause to be because Michi said so.

Henry Suryawirawan: Yeah, thanks for sharing such a good story, right? So because in many typical organizations, sometimes, it’s the role that actually determines, you know, the kind of work that you do, the kind of things that you prioritize.

So I think the most important thing just now, when I heard you mention is also to emphasize a lot on engineers, right? So engineering culture means like, yeah, you really care about the engineers and you don’t just, you know, manage them as a, as if they are just resources for you to do the work.

[00:25:37] Nurturing Psychological Safety

Henry Suryawirawan: I’m a little bit intrigued when you mentioned about, you know, like your kind of like root cause analysis is slightly more nuanced than the blameless, right? Because typically people talk about blameless, postmortem, root cause analysis and things like that. And you emphasize a lot on accountability. How can you do that, uh, in such a way that still, you know, nurtures psychological safety and people are not kind of like blamed or people aren’t afraid to actually admit things that they’re doing. Or maybe even like they are afraid to take actions simply, because they don’t wanna be accountable at the end.

Michi Kono: Yeah. I’ll start to say it’s very difficult. You know, once you start using, if you had in incident reviews that always sort of said who did the thing, it can certainly cause problems over time, incentives where like, especially junior people, they’re gonna be more less likely to speak up. I think a big part of that though is don’t let this become a delegation of bad outcomes exercise, right? Like there’ll be plenty of times where the root cause is literally because Michi said so. And so the learning is Michi needs to be more careful about what he says. Like I have done these diagnosis myself and taken accountability where I messed up. And so it’s truly not meant to be, you know, it’s all everyone else’s fault exercise.

And I think, as a leader, I have to step in and say, well, here’s where how I contributed. Because there’ll be very few cases, especially outside of incidents, there’ll be very few cases where I’m fully blameless. There is some level of accountability I have, to like, it could be as simple as like, I’m the one that assigned the person and they were three weeks at the job, right? Like it could be me that assigned it or it could be me that set the conditions for success, but it was the wrong conditions.

So I think by demonstrating that culture, like I said, we live it in this company at the top of the organization, including with Nick. I think that it sets the tone that this is okay, that you don’t, you’re not gonna get fired just ‘cause you mess up. As long as the conversation that’s happening is how we’re gonna learn, then everyone will be fine. Whereas like hiding the truth would definitely be bad. Or using politics and ego and not admitting that would be bad. But you could literally say, I did it because in certain political reason, you could say that and say, my learning is to be less political, right? So I think that it’s all about demonstrating those values for everybody and making sure to show grace when it happens and focusing more on the learnings and less about punishing people.

Henry Suryawirawan: Yeah, so I think, again, the leadership sets the tone, right? So if the leaders also kinda like admit mistakes, be part of the, you know, the root cause analysis and try to learn for themselves as well and train people, I think that’s really important thing to build that culture.

[00:28:14] Learning from Mistakes & Performance Review

Henry Suryawirawan: Another thing is like whenever people make mistakes, how do you actually make them learn from the mistakes? Do you put it as part of their performance review? Do you put that as part of the team performance thing? How do you actually ensure people learn and grow from the mistakes?

Michi Kono: I don’t know if I’d couple mistakes with performance that tightly. Like we all make mistakes. I make mistakes every week for whatever the, whatever the topic is. Even if you really experienced, you’ll still make mistakes. You know, otherwise, there’d be no car crashes. We spend lots of time driving cars, yet, we still get accidents, right? So that’s inevitable. There’s gonna be mistakes. And maybe, so let’s start with that.

Like performance reviews are not a place to call out mistakes. Now if it’s a thematic problem, right, versus instance. In other words, you make the same mistake over and over and over. You’re always, you know, hitting cars when you’re reversing. Then we should talk about taking away your license, right? So only then would I consider it a performance problem. Like I’d be very clear, hey, this is actually like the eighth time. This is a performance problem versus, I mean, we all make mistakes.

And performance should also be about success. Like there’s just as much. In fact, maybe even more so performance reviews, you should think about the outcomes that were good. You shouldn’t even get to the performance review process step if the person is bad, because they should have been coached. And if they’re not learning, like you probably don’t wanna get to that point where you’re having a performance conversation in the performance review, if that makes sense. Like you want to start, like you want to make sure people that are not performing are not there much sooner. Cause you only do performance reviews once or twice a year. But so if you are getting to that point with someone, then they’ve probably been successful. And I think that the conversation needs to be, what are the things that they’ve done well? First of all, recognizing that work. And then you can have the coaching conversation of, you know, here’s the gap that here’s the learning so we, we can do better. And then here’s where you’re like, understand the career goals and say, hey, where, what’s the gap between where you are today and your career goals.

Henry Suryawirawan: So I think it’s very important, like you should not wait, uh, when you see some people, you know, kind of like maybe, I dunno, misaligned or make mistakes or repetitively make mistakes, right? You don’t wait until the performance review cycle happening, right? So you actually coach them, maybe put in one-on-one agenda, like try to actually understand the root cause and try to actually help them to perform better in their role, right? So I think thanks for emphasizing that.

[00:30:27] Being a Mission-Driven Company

Henry Suryawirawan: One other things that I always get intrigued when people say mission driven, right? Because almost every company, mostly startups, right, they think they are mission driven. They are, they live by the values that they are, you know, like they put in their websites, products and all that. How do you actually become really mission driven? Is there something in particular that we can learn from how you run Garner Health?

Michi Kono: I was just thinking to myself, is the average person mission driven in a startup. I feel like there’s a good chunk of people that are just excited by the adrenaline and the money. But we, at Garner, obviously, like the average employee here is more mission driven than ever encountered at any other company, most. It was not uncommon for me to speak to an engineer in the past and they would say in the interview process at the end of it. So what do you guys do here? I saw that you guys do Python. I love Python, so I know I’m here, but what do you, what do you guys do with that? That was very common for someone to not understand the business model of a company, especially if it’s a complex business model like Garner or healthcare tends to be complex in terms of the financial model.

But it, but here, it’s been incredible to see how mission-driven everybody, everyone really cares cause healthcare is very personal. I would argue it’s, in that sense, it’s quite easy because what we do is, you know, our company’s technology, if it’s successful, ultimately helps people get better healthcare. So it’s a very easy mission to sort of get people to aligned with. We’re not trying to like, make insurance premiums, you know, 20% cheaper or like improve margins at a hospital. Like those things are a little bit harder to relate to. I think personally, even though, yeah, you’re making healthcare better, this is literally about giving you a better doctor. So it’s, I found that it’s been an easy sell to sell people on the mission. And make sure that, again, going back to root causes, really making sure that we’re focused on the mission and not so much on like the ego and the politics of a situation. I hope that answers your question.

[00:32:11] Aligning Mission and Values in the Day-to-Day Work

Henry Suryawirawan: So one as aspect as, uh, maybe an extension from what you just mentioned, right? How do you actually ensure that the day to day, you know, the employees that work within the company always get aligned to that mission, or maybe that values that you have in the companies. Do you actually put it as part of performance review? Do you actually put it as part of, I dunno, like your communication often that, hey, we have these values, you have to embody it, and this is how you show examples and things like that. Maybe some practical tips, how do you actually align your mission and vision and the values within the day-to-day work?

Michi Kono: So we do. I’m reluctant to say this because the performance management process evolves as quickly as the company. So, you know, I’ve been here for a little less than a year, and my understanding is it changes every year. That’s how it was at other companies. That’s how it was even at Stripe, it changed every year. So I’ll reluctantly say yes. Our performance management process does incorporate the values and literally ask, does the person operate under those value assumptions? And there’s a rubric and we author it and change it year to year. But there’s a, there’s core tenets, uh, on the website and internally of like what the values are. And then we think about like for a given level of seniority, what should you do with that value? So for a new grad, you know, maybe it’s just good enough that you, you know, you like being at work and that’s like the mission. But I think as you get more senior, you should think about like really putting the mission first. And you know, so I think that we do do that. It’s just the process might evolve year to year.

And I will say that aside from mission for the engineering culture as well, like we’ve been, one of the things that we’ve been working on is evolving that culture more meaningfully, like more explicitly. If you worked for those of you who’ve like been at a big company, some companies may or may not have like a cultural statement in engineering or what it stands for, what good engineering looks like, the definition of good engineering. I mean, that’s something that we’ve been working on because I want the team to understand that.

And then, if the last part is like, how do you get the team to like operate under that? And that’s like, you have to talk about it. You have to repeat it, you have to, to some extent, uh, you can incentivize it. I wanna be careful about, like, you can’t, if you have a cultural statement of like be happy, you can’t tell people to be happy and expect it to work out. So uh, you know, you get a low performance review for not being happy, right? So there’s more to it than incentive structures in my mind. It’s about living it, demonstrating it, and then elevating those who do that well. That’s an incentive structure. But I don’t wanna make it a stick for culture, at least. And so we do things like recognition and stuff for people who live those values.

[00:34:45] The Importance of Management System in Organization

Henry Suryawirawan: Yeah, and also probably also celebrate those kind of, uh, you know, values that people embody, right? So that maybe, you know, some examples that people can learn from. And I think I laugh when you say like, if your values is like, be happy, I don’t know how you actually can assess someone happiness, uh, in your performance review.

So, uh, maybe let’s move on to the next topic which you have touched on a little bit as well. So in a pre recording of this conversation actually, you mentioned that you put a lot of emphasis in, you know, building management systems in your organization, right? So first of all, maybe tell us a little bit more about what is management system and why is it so important?

Michi Kono: So in a nutshell, it’s about scaling repeatable outcomes. To give you an example of like a really rudimentary was, it’s like to have a standup. Everyone understands that what a standup is, at least these days. You know, if you go back 20 years, maybe not. And like why does that exist? Well, it’s a reliable thing that we can all look at and say, this happens. And that’s the place that you tell your manager, hey, I’m stuck. Before standups existed, there was no form for that. So you might send an email and then you’d wait around. But that’s not a system, because maybe your manager is different than other managers and they don’t check their email until the end of the day. Now you’re now a whole day goes by. And so someone created that notion of a standup to set an expectation to how to interact with your manager. And so, you know, Agile and stuff are systems like that, right?

And so management systems are about how you can run a group of people. It’s a set of processes and expectations that can scale. And key to that is that it’s probably not stationary. And it falls with the company and the team but you wanna stand and formalize that. And so if you don’t formalize it, then, you know, going back to the boxes, it’s basically tribal. And so if the person that runs that thing disappears, you can lose that system. And so what you wanna do is you wanna make sure that as you scale, you codify these things.

Much like a code base, right? Like you’re writing code and you’ve got coding standards. Imagine trying to set coding standards without writing it down. But you just all sort of know what the coding standards are, right? Like you might get there, but then as the team grows, at some point, someone’s doing really bad stuff and everyone is upset and no one knows why, right? And eventually you just lost that standard. So it’s very similar. You want to think about like yes, you’re doing certain activities. People probably understand what they are, but you’re gonna benefit a lot if you can just write it down.

Henry Suryawirawan: Yeah, maybe some, give some, I dunno, tangible practice here. Because like coding standards, many engineers understand, you know. Probably you have, I dunno, the line width, tabs vs space, and you know, variable naming and things like that. How do you actually do that for management standards, right? So maybe give us some practical tips and examples. And how do you actually put it as a artifacts, right?

Michi Kono: Yeah. Like to give you like a really rudimentary example that we do, that we introduced is, you know, we do like a pretty standard process most companies do now where we do Scrum of Scrums. So Scrum is like a meeting. You have here the team, you talk about stuff. And the question is, one of the questions that’s prevailing is when, how often, and in what forum to two teams that need to work together meet. And how do you keep, okay, but that, that times like 20 teams? How do you do that? And so a common solution to that is to do the review of projects that require interdependencies that are at conflict. In other words, Joey and Susie had to talk to each other to get something done. They couldn’t quite resolve it for whatever reason. Probably good reason. Where is the forum to fix that or to resolve that? Or maybe Joey lost an engineer and needs help. Like what’s the forum for that? So you create a standing forum for that. So that’s an example.

Um, another one that’s like quite common is like, in engineering at least, is like an operational review where you look at the health of the systems with the goal of being proactive not reactive. And this gets into like yes, at the team level, you should be doing it, but you can do it at the organizational level, at the whole team level, at the very top of the organization in my view. “How are we doing?” That’s a hard question to ask cause we’ve got dozens and dozens of systems so how do you, how do you know what’s going on? And so you basically trickle that down and say, okay, I wanna see this data. Let’s get that point down the org.

You can see here though, a lot of this is about having good accounting. Uh, accounting is not the right word. But having good systems that track things, right? Whether it’s work or it’s metrics, data, whatever it might be. And I think, you know, there are standard HR things as well that evolved that maybe didn’t exist at the beginning of the company’s journey. Like there again, like you have no, non-existent HR when you’re a team of three people and then you’ve got, you know, like the whole department of 10, 1,000 people when you’re like 100,000 employees. And somewhere in that journey, things like coaching plans get created or like performance management expectations. Like when we talk about performance management, so much of those expectations is about like the ICs feeling like, oh, great, now management team has this tool, this stick that they’re gonna go and use on us and make us work harder. But that’s actually a secondary point. Like there is an expectation on the managers to do that.

And so there, this is again, the evolution. There are times where managers, I mean, we’ve all worked in a team where the manager wasn’t doing their job. The person is bad. And for some reason that person is still here six months later. And you’re, and you’re sitting there losing respect for your manager every day. You’re like why isn’t this not person not doing their job? Well, I’ll tell you why. It’s like because there wasn’t an expectation on that manager to hire good people, but also fire bad people. And hopefully, you’re not gonna fire lots of people if you’re like screening properly in the interview process. But it happens. And when that happens, I think there’s an expectation on the manager.

And so if the manager isn’t doing that, then that’s part of the system breaking down because you give all these tools and part of those tools is like, how do you use them? And so if the manager is like, I don’t believe in firing people, not that they would say that, but let’s just say, that would be an expectation that I think is an engineering leader I have to set. Because honestly, it’s not fun doing that stuff. And so it’s easy to say, I’m gonna focus more on building a great engineering system and focus less on having these hard conversations, right? And what I would do is as a CTO I would say, hey, we have to do that. It’s managing the people is part of managing the systems because the people maintain the systems. And so you have to hold just as high of a bar on the people management part as you would on the system management.

Henry Suryawirawan: Yeah. So I think there are a few key things that I, uh, listen just now when you mention, you know, the explanation, right? So first thing is definitely expectations must be clear, right? Second thing is that you probably need to put it down somewhere, right? So whenever, you know, people leave, you should not have this knowledge also gone along with the person, right? So maybe the writing culture is very important as well. Maybe you can codify that as, I dunno, like how the way things work, way of working, some people call it, right? Or, you know, like GitLab also has a very good example where they codify everything and open source it, in fact for people to learn. So I think, uh, leadership also play a bigger, uh, role in terms of, you know, codifying these standards.

[00:41:53] The Importance of Having Good Managers

Henry Suryawirawan: So in terms of hiring managers, I think this is also part and parcel of like executive role. Because once you hire so-called bad managers, I think it’s very, very difficult to actually maintain the standards, maintain the expectations, and things like that. So tell us, what’s the importance of manager role and what do you think should executive do in order to avoid, you know, like hiring bad managers?

Michi Kono: Let me start with, um, the second half of that question, I think, which is like how, basically how to build a management team, right? I think that answer first. So for me, I think that you should be, we should be very clear with what managers do. And one of the most difficult things I think a startup faces is does a manager write code or not, for example. Because when you were a team of 10 people and you were a CTO and you were managing five engineers, you were definitely writing code. At some point, that statement becomes false. And it becomes false because you’re actually causing more problems as a manager writing code than helping. And it becomes… that’s because there’s all these other things you have to do that require your attention. Again, we have to evolve ourselves.

And so one of the most important things to decide is when does that cutoff occur? When in the company’s history do you stop asking managers to write code and manage them accordingly? And so, for example, I set very clear standards now in the company. I don’t think there was a standard before I was a CTO. I think one of the first things I said is like, as a manager, you can write code. I mean, I don’t, I’m not gonna stop you if you write code. But I will only allow you to be measured as a, in your performance by how you manage. So how great of code you’ve written does not factor into your performance review. You can write it. And if people like you for it, fantastic! But if you lose your best engineer to that because they’re upset that you overruled them, I’m not gonna look at the cause, I’ll look at the outcome. The outcome is that you lost your best engineer.

And so setting that kind of requirement or expectation really crystallizes for managers what success looks like. Because I think the most important thing for engineering leaders, first and foremost, is that they can recruit good engineers, but also keep them, like empower them. So great engineers or great anything, any kinda employee, generally won’t work with you if you will micromanage them and you’re overruling them, right? Putting aside like the bad ones, the good ones for sure, they’re not gonna want you telling them what to do cause you hire them to do that job. And so if you can’t do that, you can’t be successful, at least in a startup. Because how do you scale yourself? You have to hire a hundred engineers over the next two years as an organization and you’re bleeding out only of the good ones. Like you’re done as a company, right? You’ll only keep the bad people who don’t care that they’re being micromanaged. But then you’re also being limited because your systems are only as good as your managers who are writing code 30% of the time.

So they should be technical so they can understand BS, right? But it has to be low ego, because like I said earlier, even if they were technical just two years ago, the thing that they were doing two years ago might be an antipattern now. I mean just think of like AI systems and like RAG and stuff. Like the patterns are changing so fast that what was state-of-the art two years ago is kind of like yesterday’s news now. And so, so you have to have that mentality that I’m here ultimately to go and hire this person that I used to work with who’s amazing and then get outta the way. And I always, I say like the it’s the player coach model. Like I want managers to coach, but I don’t want them over there scoring the goals. I mean, they’re there, they’re gonna help the team, but that’s someone else’s job. So I think if you could do that well then you can scale for a while. And I think it’s true universally, frankly, in any good engineering org.

[00:45:30] For Strong ICs: Writing Code or Being a Manager?

Henry Suryawirawan: Yeah, I think the art of letting go is always the difficult one, especially if you start as a good IC, right? As you grow into senior, you develop solutions, write code, and typically it’s like great solutions, great code, right? And then you move into the management role. That’s when actually the trade-off starts to become like a battle, right?

So do I write less code? Do I, you know, hand it off to the engineers? So maybe for the strong ICs out there who typically avoid, you know, being a manager simply because they still love to write some code, right? Do you think it’s a good thing that they should just focus on writing code? Or they should maybe try being a manager or some kind of a leader role? And how can they actually detach from, you know, the necessity of writing code?

Michi Kono: I usually, if someone has to ask me, I usually tell them, don’t go into management. It’s an entirely different skillset. You have way less control than you think you do, because ultimately you’re not the one steering the wheel, right? Imagine trying to tell your Uber driver where to go from the backseat. Like that’s what it’s like, but you do for that team of people. And so it can feel in some ways, like it looks like you have all the authority, but you have none of the actual, like direct control in some ways. And so it can be frustrating. It’s an entirely different skillset. The lows are very low. Like when you’re, you know, politics, in a big company, the politics can crush you. But you’re also, in a small company, expected to write code while manage, like it’s a very challenging place. You have to figure out the right balance to use your skillset.

So I always tell ICs, if you’re capable of writing code, you should stick with that for as long as you can until you feel like that’s not, you’re not capable anymore. Management is not, like a side hobby to try out. It’s cause if you think about it, if someone says, hey, Michi, I wanna try managing for a little bit, what do you think? I want you to imagine me saying, cool, Henry, this is your manager now. They just, they just wanna try it out, right? Like you’re not cool with that. So you need to hear from me, no, no, they’re all in. They’re here. They’re gonna be here for years. They’re gonna help you succeed, right? So if that’s not their mental model going into it, you’re not gonna, it’s probably not gonna create good outcomes for you as a report.

And so I’m always, I’m like really focused on the person having the right motives. You know, really, they’re not there for themselves. They want to succeed for the business. They wanna to help the team succeed. They want people to succeed that are working with them. And not because they want more authority over like what gets done, right? Because the reality is it’s not, it’s just not true. And some of the most difficult parts of running a company is frankly like letting go of people or changing projects. Like imagine you are working on this amazing new system for six months, and then I tell you we’re not gonna do that anymore. Like that’s a really hard conversation, because people might quit over that kind of stuff. Or I could say, you’re not the right person to maintain that anymore. Those conversations have to be done by the manager. And if that stuff, firing people and like doing HR stuff is not something that you think, I mean, not that anyone enjoys that, but if that’s not something that you think would be something you would want to get better at, it’s not the right career for you.

So I always tell people you need to have the right motivations and really be in it to win it to be a manager. Cause it’s just not a path that is necessarily that it’s not all fun and games. At the same time, it’s also a one way path. Like I think it’s very difficult to go back. So once you step into this thing, like I said, you have to be committed to it. It takes a couple of years just like with engineering to get good at it. You know, no one gets to go and say, oh, I’m gonna just hobby code for a little bit, try out the career. Like, no, it’s gonna take you years to get good at it. It’s the same with managing. It takes you years to get good at it. And so by the time you’re like, okay, I kinda understand what’s going on here, but maybe this isn’t for me. It’s a year or two has gone by, right? Because you have to go through at least one promotion cycle to see what it’s like to promote people. That takes some time. So a year’s a long time to not be in the code. And while you can go back, it could probably set you back.

And so I always say like just it’s not a step that I would take lightly. Something that you should really think about. If you really enjoy coordinating, helping people, empowering people, hiring, right? I think it’s something worth taking a look at. But just know that just like with any job it has its downsides.

You know, I would say like the worst part about being an IC is probably fixing bugs and doing on call, fires and incidents, right? Like that’s probably the worst part. And if someone said to you, yeah, but I don’t, I don’t wanna do that stuff. Like I just like writing code. You would think that they’re quite naive as an engineer, right? And so you shouldn’t love waking up at 2:00 AM to fix a fire on a system. No one does. But it’s something that you might get good at. You know, you get really good at like handling an incident. And you know it’s a skill set that you have to get really good at to become senior. And you have to know, you know, there’s gonna be some fire and you have to fix it very quickly under a lot of pressure. That is part of the job for being an IC. There’s an equivalent of that in managers and if that stuff is like terrifying to you, you’re like, I don’t wanna do that. Just I would think twice.

Henry Suryawirawan: Yeah, dealing with people is always the, maybe the art, right, when become a manager, right? So because like code can be very structured and maybe it’s more like binary, right? One or no, yes or no, right? But with people, sometimes it’s very ambiguous and like what you said, right? You cannot put a control on, you know, like you think you are the leader and you have the authority, right? But sometimes you actually cannot control what actually happened in reality. So I think, uh, yeah, being a manager definitely requires a different skill set and sometimes it can be really rewarding becoming a good manager that people love, right? And achieving a certain outcomes as a team, right? But definitely it requires a different skill set.

[00:50:55] The Difference Between a Manager Role and Executive Role

Henry Suryawirawan: So how about becoming a CTO? Because I understand that becoming a manager is one thing, becoming a, you know, like a people leader is one thing. But becoming an executive, I dunno, like maybe in your role, right, currently in the Garner Health as a CTO, I think it requires a different skillset as well. So what do you think are the difference between, you know, manager, people manager, and also the CTO role as a executive role?

Michi Kono: I dunno if you’re, I’m not sure if there’s two, but there’s at least one I can think of. Let me start with the first one I think of, and then I’ll get to the second. So the first one is maybe not necessarily exclusive to CTO, but certainly at the more senior levels, like you have to be proactive, not reactive. You have to be thinking about what’s happening in six to 12 months or 18 months, or the bigger the company, the further I had to be thinking. And if you’re reacting, then you’re, you’re screwed. And the reason you’re screwed is because, going back to the Uber driver thing, imagine that I’m managing an Uber driver and then imagine that there’s someone managing me on how to drive that Uber driver. Like there’s so many abstraction layers and hops.

And now imagine that’s not happening in real time. And so by the time I realize, oh, I need to react, the time it takes for the organization to shift course and adjust to that reaction is, at best case, weeks, right? And worst case it could never happen. They’re just like, nope, we’re not doing that. But it’s probably months or quarters and that could kill you as a company. So that statement of being proactive is true probably for any organizational size, just because the higher up you go the more, you have to account for the fact that the team will ship slowly, right?

But I think the second one is that’s unique mostly to CTOs is that you are the final line between the engineering and the business. Like there is no one above me to communicate to the business what engineering is doing. Whereas there’s always someone above you, in any other role, right? So if you’re dealing with a business stakeholder who doesn’t quite get it and you’re trying to say that stuff to them, maybe your manager’s got your back and they’ll figure out a way to say it, right? But it’s, that chain stops. And it finally at the CTO, it stops. And it’s just you and everybody else has specialization in their stuff and very likely none of it’s in engineering or very little.

And so be able to communicate that. It’s a bidirectional communication, by the way, right? Like you have to be able to communicate with the legal team. And there are things like the hiring contracts. And then there’s like, I dunno if you wanna do open source and there’s like some license, on those topics. And then with the sales team and then, you know, marketing and people team. So you’re the final arbiter on this stuff.

And I think, so the meta point to all that is that communication is probably the most important skill set because you have to communicate something that a lot of atomic engineering decisions far down the org and to translate that all the way up to the highest levels of the company to people that are probably not technical at all. And they expect you to be that translator for them. And then vice versa, right? ‘Cause they’re like, hey, there’s this compliance thing or whatever. Like if it doesn’t get translated back, it gets lost. And this gets into like management systems again. Like how do you route this work? And it’s a product management question as well. There’s other partners I might work with, but there is no one else that I can rely on. It falls on me. And if I’m lucky, my stakeholders are technical. But you can’t rely on that to be true.

Henry Suryawirawan: Yeah, and sometimes also you need to handle complaints from other departments as well. Like for example, if let’s say engineering are not delivering, engineering always having incidents and things like that. So I think, yeah, you’re kind of like the bridge between the business and the engineering. And I think the important thing is the communication, uh, also understanding systems, right, management systems, and that things are becoming more important.

Michi Kono: And also designing those systems, right? Like if you’re below CTO, they’re probably setting those management systems. But the accountability for creating those systems, it falls on me. I’ll also say that like the accountability to know which systems you need and be proactive about that is also on me. And so again, it goes back to like, you just have to, as a, this is true for any executive role, right? You just have to think about what level of scale you’re at. When is the right time to introduce something that’s annoying that, you know, might feel like busy work for people, but it’s actually really important to scale the org.

I think a good example debate we have is metrics. Metrics is actually a great one because some companies start with metrics when they’re very young. But realistically where you’re more interested in closing the sale than looking at a dashboard. And so you’re just writing the thing. At some point, some of the very low level metrics, these systems becomes important to look at it at an aggregate, but may not matter in the moment when you’re building it, when you’re just shipping it for money. But if you go to like really, really big companies, everything is measured out.

Everything is every, there’s a KPI of everything. Every, every… I mean there’s different levels of maturity on this, but generally the businesses that are much more data driven, which sort really, really big. So somewhere between when you’re a two person startup and when you’re at a 20,000 person company, you’ve brought in this concept and there’s different levels of that. At an extreme, you would be doing like, at scale experimentation, A/B testing. So the question is, when do you bring that in? So those kinds of things, I think are the things that, again, it doesn’t have to all come from me, but I’m accountable for it.

[00:56:01] A Unique Thing Learned from Doing Payment Systems

Henry Suryawirawan: Yeah, so thanks for mentioning that, how do you create systems, right? I think it’s very important as an executive to actually first look beyond, right? Uh, your job is to be proactive, not reactive, right? And how to design systems to, in order to be more proactive towards those kind of things. So you have worked in multiple companies, right? You know, Stripe, Meta, Capital One and all that. Do you think there are some non-intuitive thing that you learned from those organizations that you wanna share with us as well?

Michi Kono: I, those are very different companies with different philosophies. You wanna try to clarify a little bit more what you wanna learn?

Henry Suryawirawan: So something that is non-intuitive that you think, oh, this is very unique from this company that I learned that I think could be useful if you wanna share with others.

Michi Kono: So I spent a big chunk of my career doing payment stuff. And I think one thing that’s interesting about the financial industry is that they’re like excessively obsessive about fraud. I would say like if you’re, if it’s a fraud topic, you get infinity budget. That’s probably the biggest sort of delta between that industry and others. Even though it’s funny ‘cause fraud represents money loss, but not money gain. So it’s a very tricky balance because you’re trying to build features, but there’s new features all have some kind of fraud factor. So there’s like this internal war always between sort of like the compliance and control and risk side, security side of the business with the sort of the revenue and feature generation part of the business. And getting that right is really critical.

I got, I used to, I did consulting once for I don’t want to name the name, but at a financial institution, it’s not Capital One. And it was an innovation project. They were working on building this new thing. It was gonna be this amazing new product, consumer product. And this is like a global brand. And, internally it was a huge fight because every other department was like this is not worth innovating on. It’s gonna disrupt our business model. And what about all these different ways of. And basically they use fraud as like risk as a way to kill the project. And so, uh, I think they were talking about like phishing and, you know, the login screen can have phishing attempts and what. And so it’s like what? I would say that they were probably valid, I don’t know. But, you know, the innovation is very difficult in that space because you have this like huge department in the company who’s motivated to just kill any good idea, and for good reason perhaps. And the company’s gonna figure that out. Like Square and Stripe have figured out that balance perhaps, but it’s, um, interesting to see that war. So that was something I observed.

Henry Suryawirawan: Yeah, thanks for sharing that. And it’s always, uh, you know, challenging to prevent fraud and maybe if I can bring it up also, security, right? It’s always a balance, right? You wanna be secure, but at the same time, you want to innovate and create new things and disrupt the market and all that, right? But sometimes security also needs to take a, you know, priority as well to protect your users, protect your systems, and protect your company altogether.

[00:58:43] 3 Tech Lead Wisdom

Henry Suryawirawan: So, Michi, I think, uh, we learned a lot from the conversation. Before I let you go, right, as we wrap up our conversation, I would like to ask you one more question. Typically, I ask the question called the three technical leadership wisdom. If you can think of it just like three advice that you want to give to the listeners, what would your advice be?

Michi Kono: Yeah. Uh, the first one I’d say is be willing to be wrong as I said earlier. Like you have to, if you don’t do it, no one else will.

And be willing to make very hard decisions as a leader. Choice A versus B. Not making a decision is in itself making a decision. And so I’m sure you can all imagine those times where you had some proposals for an executive and then you’re all waiting around for them to make a decision. Like that’s a decision. You’ve just killed the team for a week.

Um, and finally I’d say, there’s a famous sort of adage from, uh, the CTO of Meta. But he used to say that communication is the job. And I’m a big believer in that as well. Like I think if you can’t communicate well in various ways, not just what I’m thinking, but in terms of what the priorities are, what people should be doing, what the expectations are. If you can’t do those things well, then you probably can’t be successful as a leader.

Henry Suryawirawan: Well, lovely wisdom. So thanks for sharing them, right. Especially the last part, right? Communication is definitely the job of leader, right? Uh, especially if you wanna communicate, over-communicate and make sure that the teams are aligned and get the priorities right.

So Michi, if people love this conversation, they wanna connect with you, they wanna find you online, is there place where they can reach out to you?

Michi Kono: I guess, uh, if you’re more interested in Garner, take a look at getgarner.com. Otherwise, you can find me on LinkedIn. It’s Michi Kono.

Henry Suryawirawan: Right? Thank you so much for your time today, Michi. I think we all learn a lot of things, you know, your insights, your wisdom, especially in becoming a better CTO and technical leader. So thank you for that.

Michi Kono: Thank you.

– End –