When you're really small, everyone understands what
they're supposed to do. 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.
Michi Kono, CTO of Garner Health with experience leading teams at
Meta and Stripe, reveals the art and science of scaling
hypergrowth engineering teams. Management systems are about how
you can run a group of people. It's a set of processes and
expectations that can scale. It's about scaling repeatable
outcomes. If you don't formalize it, it's
basically tribal. You wanna make sure that as you
scale, you codify these things. What's your tips and strategy to
nurture a good engineering culture?
I think a good engineering culture is one that focuses on
engineering. You want a world where your best
engineers are engineering the right systems.
The only counterbalance is really the business outcomes.
Shipping code in itself is zero outcome.
Unless the system is being used. You emphasize a lot on
accountability. How can you do that in such a
way that still, nurtures psychological safety and people
aren't afraid to actually admit things that they are doing.
Every time we mess up, we diagnose the situation to its
root cause. We do this for all processes.
We try to figure out the accountable individual.
Not to blame them and fire them, but really to learn to
understand. We don't let seniority titles or
org chart determine who's right. Right is like a factual
statement, not one based on like social hierarchy.
One of the most difficult things a startup faces is does a
manager write code or not? As a manager, you can write
code. I'm not gonna stop you if you
write code. But I will only allow you to be
measured in your performance by how you manage.
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. Great to be here.
Thank you. 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?
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. 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? 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.
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?
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. Yeah, i've heard about, that
huh? Sorry.
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. 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. 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?
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.
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? 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. 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?
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? 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.
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.
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.
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. 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? 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. 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. 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?
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. 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.
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. 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. 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. 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?
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.
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.
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? 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.
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?
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. 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? 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. 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?
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. 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. 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?
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.
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?
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.
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.
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?
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.
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.
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. 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? I, those are very different
companies with different philosophies.
You wanna try to clarify a little bit more what you wanna
learn? 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. 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.
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.
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?
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. 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? 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. 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.
Thank you.