The framework is called input, output, Outcome, and impact.
So it's an escalating way of where to spend my time as an
engineering leader and more importantly, where my
engineering team is spending their time on.
I would say most teams and most engineering leaders are well,
worst in the input and output. Where some teams struggle is the
outcome and impact aspects of it.
My belief is that as an engineering leader and the
engineering team should be very closely involved in what happens
with our product when it goes out to the market.
Dura metrics are great, but they're very internal facing.
When you start to become an exec and interact with leaders from
other functional areas, think about what metrics they care
about. So if you have a good mission,
especially a good mission and and a clear mission, working
backwards from that and connecting how the work we're
doing to that mission is half the battle, in almost every case
it works, but it's not enough in my opinion.
Hey guys, welcome back to another new episode of the
Technical Podcast. Today I have with me Balki
Koderapu, he's an experienced engineering leader and very
experienced in a start up as well.
So today we're going to talk about engineering leadership and
few tips from him, how he can make a good culture and those
kind of stuff so bulky. Welcome to the show.
Looking forward for our conversation.
Thank you, Andrew. Honored to be on this podcast.
We connected on LinkedIn a few years ago.
I've been an avid follower of Tech Lead Journal all this time
and it's a great honour to be here talking to you.
Bulky. I always love to ask my guests
first to maybe tell us a story about yourself, maybe any
turning points from your career you think we all can learn from
you. Yes.
So several turning points in my life, but I'll share a couple
that are relevant to this audience.
So the first one is I stayed in large companies for the 1st 10
years of my career. Towards the end of that 10
years, I was really gung ho on growing up the ladder, climbing
the ladder in the large corporate setting.
So I convinced my leadership team to pay for my MBA,
executive MBA degree, which they did.
So I went to a very good university, University of
Washington in Seattle, to do my MBA.
All was great until the last semester where we had this
capstone project in entrepreneurship.
It was a competition. I was like, Oh yeah, this is
this is something like a course that I enrolled into that and
the startup and entrepreneurial bug bit me.
So in that competition, I was so involved.
I loved every second of writing the business plan, building a
company, building a product. Coming out of that MBA program.
I completely changed my direction.
I'm like, I'm not working for the large companies anymore.
I'm only going to build my own startup so the advice there or
turning point for me or anyone listening is don't make up your
mind going into something major in your life.
Just be open to changes in in your mindset and what the
universe gives you. Another turning point is so Long
story short I did quit my large company and build a start up
with a friend. We ran it for a year and a half,
learned a lot, but life happened.
We had kids and things like that.
So we both decided to exit that startup and go back to the
corporate world. And I joined a very fast-paced
medium sized company as a manager.
So that was the first time I was a manager outside of my domain
expertise. So in my 10 years in the large
company, I knew everything about our product and people and
technologies. So I got carried away.
I thought like I could be successful anywhere in the
world, have so much experience. But I was very, very humbled
when I joined this company. First of all, this was a very
developer oriented product. Developers took great pride in
what they did. So when I joined, I was being a
manager. I was like, yeah, setting up
their work, you know, rubbing shoulders with other marketing
people and salespeople and forgot all about, I'm here to
serve my team, right? So I forgot that I have to build
my trust and respect. So I was very humbled in that
experience. So again, another turning point
for me is that when I join a company, a new team, how bonding
with my team is first and foremost the most important
thing. So I I did not last very long in
that company, Long story short, but it taught me a great lesson
in with joining a new team, how to be a humble and do it with
curiosity when when I joined a new company be learning, be
building relationships and things like that.
Thank you so much for sharing your story.
I think it's pretty interesting, right?
So I think I was in the same shoe like you, right?
Working in a corporate ladder, trying to climb up as fast as I
can. But obviously, you know, the
startup kind of like NT's me. And you know, these days I have
more interest in joining startups rather than corporates.
So Balki, I know that you have been in the tech world and also
engineering world for quite some time.
Today we're going to talk discuss topics about, you know,
engineering leadership and all that.
Maybe let's start with the first thing.
It's about leading and inspiring engineering teams.
You have something that I find really interesting, right?
How to actually come up with the framework so that engineering
can create more impact rather than in some engineering teams
where they focus a lot on just input and output?
So tell us maybe a little bit of background, how do you come up
with this framework? Yes, this is not my framework
but unfortunately I don't know where I got it from.
I heard about it on a podcast and then dug up.
The framework is called input, output, outcome and impact.
So it's an escalating way of where to spend my time as an
engineering leader and more importantly, where my
engineering team is spending their time on, right.
So 5 seven years ago, input and output themselves were hard for
many teams. So people would struggle on how
to schedule their work and doing their releases on a cadence and
predictable way. I believe that more more and
more teams now because they either they follow scrum teams
or they have a good leader. Many teams are able to handle
input and output in my opinion. Right there are still teams that
don't do well with input and output.
I probably judge them, but I would say most teams and most
engineer leaders are well worst in the input and output.
Where some teams struggle is the outcome and impact aspects of
it. So for example, we build
features as fast as we can, but many teams are unable to connect
that with an outcome. Are the users actually using
those features? Is someone paying for those
features right? So if you take a step back, we
tend to make that somebody else's responsibilities.
I'm building, I'm doing my best I can.
The most beautiful product, it scales infinitely.
So why are you not selling salesperson or product person?
Why are you not telling me what are the right features to build?
To be fair, it's their responsibility.
However, my belief is that as an engineering leader and the
engineering team should be very closely involved in what happens
with our product when it goes out to the market.
So that's the outcome. And one example of outcome and
how to measure and embrace and make it our own is at the last
company. What we did was at the start of
the demo, we did spring demos like most companies at the start
of the demo, actually, we looked at software like Pendo, which
does user analytics, usage analytics and evaluated how our
features were being utilized in the field.
So if he built something in the last print or the Sprint before,
you would actually look at the corresponding metrics in Pendo
and say, oh, we built this, but nobody's using this part.
Is there a gap here? Or if he didn't market it
properly, so on and so forth. So that to me was very
empowering to be able to for the engineering team to be part of
that journey. So that's an example of outcome
impact is next level. So the current company I'm
helping is a truly mission driven.
Many companies say they're mission driven, but this one
truly is for the first time in my life.
So what we do is we help pregnant and postpartum moms
live a healthy and joyful experience through those 18 plus
months during their pregnancy and postpartum.
And we do that through technology, obviously.
So we help them connect to various fitness devices like a
heart rate monitor, a blood pressure monitor and a fetal
baby heart rate monitor. And based on the data that's
coming in, we provide them guidance on, you know, maybe you
could walk a little bit more or your weight is a little bit
abnormal, etcetera. So we literally kind of save
lives. So there's at least 2 examples
where our software and our counselors, we're able to detect
some early signs of trauma and we were able to save the baby's
life. So it, it's very mission driven.
But again, like it is very easy for an engineering team to be
disconnected for that mission. Like be obsessed about the
technology because we have so much data.
I could drool over that data all day and night long, but
reminding them why we are here is an important aspect for me,
right? So how are we helping them lead
a healthy lifestyle and how can we do that with data to connect
that mission, if not on a daily basis, on a weekly, on a
sprintly basis, Being able to do that, that impact is the most
powerful thing and what I can do in my engineering leadership
role. Thank you for outlining this
framework, right? So input output, outcome and
impact, right? I think I would tend to agree
with you based on my experience as well looking at the different
engineering teams in the industry, right?
I think somehow especially as you get bigger, right, and maybe
in the small startup, everything is kind of like well connected.
You understand the mission, you understand the features you
build and the kind of outcome and impact.
But as a company organization grows larger, typically, right,
you'll start seeing silo information not spreading
through end to end, right? And engineering mostly given
like, OK, here's what the things you need to build, right?
So instead of, you know, understanding what are the
outcomes that potentially could happen, they are just given, you
know, like a list of features and to produce output.
So I think partly one responsibility for leaders is
actually making sure that this doesn't happen that often and
somehow engineers are able to understand the outcome.
Maybe in your experience, what are some of the practices or
habits outside of maybe like Pendo that you have seen that
you have done before, right? What are some of the things that
engineering leaders are able to kind of like help so that
engineers don't forget about this aspect?
Yeah, there's several things. So for the last three companies,
I always made sure that engineering team spends a good
amount of time with our support team, right?
So most often support team is the frontline for the pain and
the joys of our customers. And again, because of the layers
in between engineers tend to be, we tend to keep them separate.
Like you don't, you can focus on your work rather than being
involved in the day-to-day grind.
But I think differently. I feel strongly that engineers
should work side by side, at least a few hours a day or a few
days a month besides support team and be involved in their
journey. So there's one we do.
And at the current company, we actually have counselors and
coaches on staff. So they are the ones that are
actually talking to the moms day in and day out.
They have a very tough job. They use an internal software we
built in order to communicate with these moms, right?
So they have to handle dozens of moms every day.
Moms go through ups and downs throughout the day.
So being able to stand by them and support them is a tough job.
So I've not done this yet, but my goal is for every engineer
that joins spends about a week with these navigators to learn
from their journey. All right, so they are so far
away from the technology, but we also build our software for
them. So first and foremost, we build
it for the moms. So we're going through this
journey and close behind that, we build it for the navigators
who are helping these moms. Those are two examples I can
think of. Oh, another favorite of mine is
we introduced this two companies ago.
We do these demos, you know, almost every team does print
demos, mostly internal facing maybe to the product partner.
But me and my boss introduced, we do demos for the entire
company. I was literally sweating when I
heard that. Oh my God, in front of the whole
company it was it was a small company, but not too small.
We were about 80 people when we introduced that, 35 or so in
engineering. The rest were outside of
engineering. Yeah, I mean, Long story short,
we take the highlights of the last month and we would do a
demo to the entire company once a month.
And I've always followed that practice.
I'll introduce that pretty soon in this company as well.
But it it's one of the best one hours of my month, every month,
right. So being able to prepare, doing
it with grace and humility to the rest of the company, believe
it or not, this was the most popular meeting for the entire.
This would be more popular than the CEO talking to the company,
right? As a technology company,
everyone in the company cares about our product.
Being able to showcase it in a humble manner is a very
delightful experience. So I've refined it over the
years, but partner with the product managers to see what
makes sense, what to share, what not to share, etcetera.
But the big take away for me is that be open to surprise.
So many times we build something, we share it and get
punched in the face. This is not what we want, you
know. So being prepared for that
feedback is the key for me if you're doing it in your own
company. So these are some of the things
bring the engineering team closer and closer to the front
lines. Be humble, be transparent with
what we're building and how we are building.
Yeah. So I think one of the key
takeaways for me is always try to get closer to the front line,
like what you said, be it the users or be it the support team
and also being closer with the cross functional team, right?
For example, the product team or maybe the marketing team getting
the pulse from the externals, right?
Like how our product is being used, what kind of impact or
stories that other people got impacted by using our product.
I think that's always helpful. And I think I took interest in
one particular word that you mentioned.
Engineers like to get focused time, you know, doing their
craft, doing their work. So they don't want to bother
with all these. Maybe some tips from you how for
engineers not to just prioritize their focus time, deep work
focus time. Always we say that to other
counterparties, but always to have something in the back of
our mind to actually understand the outcome and the impact of
what we do. Yeah.
I mean, it's a fine balance, right?
So it's well known that when craftspeople like Engineer do
their best when they're focused. So no way I'm going to take away
that focus from them, but schedule this very important
outcome and impact focus time as well, right?
So one thing that has helped in the past, this was from almost
seven years ago when I was New Relic, we had a role called
Support Hero. Instead of just escalating
everything to everyone and distracting people, we would
have one person focused on bugs and helping external teams, and
we call them Support Hero. So they would be the person
fully dedicated to helping others outside of engineering
for the whole spread. It's a little bit exhausting,
but I feel it worked out well. So what they're doing is a
little bit of a sacrifice. So let me hold the Fort down
with these bugs and escalations while I'm letting you, the
remaining six or seven engineers, enjoy your focus
time. So that's the balance we found
that person would also be at times beyond the support
rotation, the on call rotation as well.
So we treat them with thick glass and respect for what
they're doing, but also know that you know you have to do
this once every four to six prints, depending on the size of
the team. Yep.
So I think for engineers, you're typically in a life product,
right. So you'll have support things,
the tickets right from users, be it from internal or external,
right? And yeah, on call or support
hero that you mentioned here is a typical practice that we adopt
in order for the engineers to actually understand what kind of
issues that typically crop up and what kind of maybe impact.
Because when you listen to users problems, right, typically you
can empathize with their journey and the kind of impact that it
created for them. Thanks for highlighting that.
If engineers or engineering leaders know about the outcome
and the impact. Now, one question still exists
in typical startup company or tech company is that how do you
actually measure, you know the engineering productivity or the
outcome or output itself, right. So I think these days developer
experience, developer productivity are kind of like a
trendy topics. Maybe in your point of view as
well or your experience, maybe you can share what are some of
the engineering metrics that you typically use in order to gauge
the effectiveness of your engineering team?
Yeah, Dora metrics. I highly respect Dora metrics.
You won't go wrong with Dora metrics.
Within Dora metrics, A-Team metric is our ability to deliver
ship with confidence and joy, right?
So one of my mentors used the phrase drama free releases.
So when we prepare for a release and during the release and after
the release, it's a qualitative measure.
But there shouldn't be any drama.
Like you shouldn't have to stay awake making sure the release
goes on a specific date and time.
And it shouldn't take hours and hours to do a release and it
shouldn't cause issues afterwards, right?
So the specific metric there for me is.
How long does it take to prepare a release and how long does it
take to do the release itself? At my last company, just as an
example, when I joined, it would take the entire week to prepare
a release and then almost 36 hours to do the release.
And the context there is there is some context there.
It's not like we did it for without reason.
We were not a multi tenant application, we were a single
tenant application. So every one of our customer has
their own infrastructure. So which means we had to
release, deploy our software into every single environment
which would explored like whenever we had new larger
customers that we dreaded because it would be so much more
infrastructure and new servers and containers where we had to
deploy. And that was not going to change
anytime soon, right. So we did it for a reason the
customers wanted. We promised them dedicated
environments as part of their security agreement.
So going multi tenant was not an overnight solution.
We had plans to do that, but it was not an overnight solution.
So anyway, so just the sheer number of servers and containers
took hours and hours plus we didn't have any automated
testing. Again, Long story short, we
deployed a known solution Circle CI which I've used in the past,
which is robust and can scale and then slowly but steadily
introduced various layers of testing, unit testing,
functional testing, end to end testing, so on and so forth,
Canary bills and etcetera, all the best practices.
Obviously we could not do it overnight, but over a six to
nine month time frame, we methodically introduced all
these best practices and very proud to share that like
overtime, we we got down to about four hours.
You know, it's still cringeworthy. 4 hours to
release, it's still cringeworthy.
But in that setting where we had over 100 customers and thousands
of servers and containers, it, it was a joy to be able to do
that. So, yeah, Long story short, I
would say being able to release the joy and confidence is a key
metric for internally looking right.
So even that after a while it becomes routine for even
outsiders. Our CEO was first impressed.
Oh, yeah, that's great. You improved a lot.
But then what's next? Right.
So I'll pause there and see if you have any questions or
thoughts before I go to my next part of the answer.
Yeah. I like what you mentioned,
right, release with joy and confidence and drama free.
I think in still in many teams this might not be possible,
right? So because either like they
don't have automation or they have separate teams that do the
deployment and things like that, or they just don't invest time
in building all these, you know, internal tooling and
capabilities, but they focus more on just churning out code
and building features, right? So I think I hear what you said
about Dura metrics and I know that you also have other kind of
metrics and maybe internal dashboard that you use to
actually project different kind of progress or ability that
engineering does to other cross functional teams.
Maybe if you can share a little bit on what are those you know
and to what counterparties, I think that will be great.
Yes, Yeah. So, you know, when I first got
introduced to Dora, I still probably remember.
Like I was so excited. Yes, I've conquered the world.
Now I have metrics, so I started sharing that with our in our
executive team meeting. So first meeting they were like,
Oh yeah, curious. The second meeting they asked a
few questions. By third meeting, when I was
showing the same metrics, they were bored.
They were like, let's move on. You know, the, the point I'm
trying to make is, you know, they are fun for an engineering
leader in the engineering team to do.
And I could pretty much guarantee they would become
table stakes or like a little bit boring even for people
outside the team, right. So we, we should still make sure
we are delivering with high quality and confidence for
internal reasons. But I see this from the outside
in. And what I've come up with over
time is different metrics and values for different teams that
I interact with. So obviously one of the things
that most of the company, including the executive team
cares about is the product road map.
So I partner with the product team and make sure we refine and
update the product road map before it becomes a big deal,
right? So many times it would be like
the customer start yelling and screaming and then it's it's in
reverse. Then we have to go back and
scramble and create a road map. So product road map is top of
mind for me. And then going one level deeper,
again, this is somewhat more internal.
So start with the customer facing product road map and then
work backwards to what it means for our technology road map.
So I've learned this several years ago.
Many teams do it the opposite, right?
So they're like we want to scale to 1,000,000 users and start
from there. I would work backwards and then
build the tech road map that powers this product road map and
go even one step further. All of us know no product road
map stands the test of reality, right?
So, So what we did about seven years ago, I worked with our CTO
at the payment gateway company. We came up with four different
outcomes for the company, like when the company's ready for
exit, what would be the turning point?
I'll give you a specific example.
So to make my point, so we could be acquired by a larger company
or we would sign up a very huge deal.
Those are a couple of outcomes, right?
And we work backwards. So if you had to sign up a very
large customer that man, we should have very robust disaster
recovery. If you were to sign, if you were
signing up medium sized clients, they don't care about Dr. but
very large customers care about disaster recovery.
So again, working backwards. So what are the features we have
to do in AWS? We were in AWS that meant we
were a monolith. So being a monolith and building
a disaster recovery plan is not not easy.
So we have to split that into modules and maybe even micro
services. So it's just an example of how
working backwards and also working towards multiple
outcomes and see what is common. So in that example, in all of
the outcomes, we had to be able to scale on AWS.
By the way, we were on a private cloud back then.
We were not in the public cloud. So based on that, we made the
decision to like one of our first fundamental steps is to go
into a public cloud environment and that will sell all four
different outcomes. By the way, I got excited and I,
I started sharing an example. We have product road map back to
the product road map. Having a a robust but flexible
product road map is one of the things the entire company cares
about. Even when I'm talking to the
support team. As you know, engineering and
support are joined at the hip, right?
So as we scale, that means support gets the brunt of it
all, the bugs and issues. So the metric they care most
about, for obvious reasons, is the number of bugs we have
active or the time it takes to resolve a bug.
And going one level deeper, how long does it take to resolve
severity 5 bug versus said one bug, right?
So those kinds of metrics are important to support team.
So when I met with them once a week, that's where I started,
how many bugs, what's the trend line for how long it takes,
etcetera. So that's another metric
customer, our external facing metric.
Lastly, I talk about the people team, right?
People, the HR team, they care about how we're doing with our
hiring. These days, hiring is not the
most important thing, but it's still kind of important.
Like what is our acceptance rate?
So one of the metrics I'm really proud of is when we make offers
as an engineering leader, how many people are accepting those
offers? Even during the peak of the tech
market, I was getting close to 100% acceptance rates, and that
made me proud. So that's one example.
And then how long does it take a typical engineer to fully on
board and become part of the team, right?
So that's another metric. Pulse surveys is another
example. So we at one company we did
quarterly pulse surveys with all the engineers and getting a good
qualitative and quantitative feedback from internal team
members. That's a metric that my HR team
cared about. So Long story short, again,
durametrics are great, but they're very internal facing.
When you start to become an exec and interact with leaders from
other functional areas, think about what metrics they care
about. Whether they're a HR leader,
marketing leader, support leader.
They all care about different metrics, so think about which
ones you want to expose to them. Wow.
I think that's a very good overview, right?
So how it actually connects, right.
So I like the one that you mentioned.
Engineers love their own kind of like geeky stuff, right?
So Dora Metrics I believe is kind of like one of our geek
stuffs, right? They always try to talk about
it, but not all the time, you know, the counterparties
actually are interested in, you know, getting into the inner
details, right, because they can't connect with what they do,
right? So I think product road map,
product delivery is still one big aspect, right?
So also coming back to what you mentioned in the beginning about
the outcome and the impact, right?
If you can't deliver anything about your product, right?
I think you can't deliver the outcome and the impact.
And I like the working backwards from your product road map
rather than engineering LED kind of improvements, right?
We all talk about rewriting micro service and things like
that. So those typically are like
engineering driven. But if you can connect it to
your product road map or product delivery, I think that will be
an impactful project to do, right?
So I think in all these definitely people and
recruitment is also important, right?
Especially retention as well and onboarding and also the
engineering happiness or developer experience these days.
Anything that you want to add here on how to make sure that
the retention and also the developer pulse survey that you
mentioned actually gives you like a high engagement?
So maybe this is also connected to your culture, Maybe a little
bit about here, culture values, you know how to make engineers
more motivated. Yeah, You know, in the beginning
I translated the company's values to the rest of the team
and it works well, I think. Right.
So if you have a good mission, especially a good mission and
and a clear mission, working backwards from that and
connecting how the work we're doing to that mission is half
the battle in almost every case it works, but it's not enough,
in my opinion. I've learned it the hard way.
It's hard to sustain. Just keep on saying we save
lives or we improve the quality of our customers.
It gets tiring if you keep on saying the same thing.
So at my last company, I actually took the courage to
build my own culture engineering values.
So I came up with five values, and we'll dig into them
throughout this call. But that's one way, right?
So it's a little bit harder for an engineer.
It takes a leap of faith to connect to a company mission,
especially if it's broad, right? So, for example, many companies
say we work in the open, we communicate in the open.
It's somewhat obvious when you say that, yeah, who doesn't want
to work in the open, right? And it's also being a typical
analytical engineer. What does that mean?
So obviously it's the job of the leaders to go one level deeper.
But I did that in the form of engineering values.
So to demonstrate, I'll use one example.
So one of the values I created for this company is we always
communicate in the open. We celebrate our wins in public,
but at the same time, we document our failures and
lessons in the open as well. And then I went one level deeper
and almost every startup uses Slack.
And I feel like most places they don't use Slack in an open
setting. Like for example, in every
company I join. When I join, I love to look at
the stacks that Slack sends to the admins.
How many conversations are happening in DMS?
How many conversations are happening in a private chat,
private group, and public group? If you have to guess, almost 85%
of the conversations are happening in DMS.
I don't know about the global setting but when I joined a
company that's what I see 1st and I cringe.
Like why are so many conversations happening in DMS?
It can be that everything is secret.
So anyway, So what I came up with is a simple hierarchical
framework. By default everybody should be
talking in the broadest public channel.
If you can't do that, if you feel like it's a large group,
being shy should not be a reason.
Everybody should have the courage to talk in a public
group. But if you feel like it's too
large of a group and it's it could waste their cycles, then
discuss in a private channel that's purpose like for a
project or initiative only. If you feel like that's not
appropriate or if it's confidential then do a multi
party DM. And the last resort should be
Adm that's one of the values like really breaking it down to
what communication in public name and I'll share another one.
So as soon as I join, I create a template for AAR is after action
review, which is another name for postmortems, right?
Postmortems are negative. After action reviews are more
neutral or positive. So anytime there's a sizable
failure, we immediately start by writing our after action report
and sharing that with the entire engineering team and sometimes
even with the company. In fact, at this company, I
shared that with the entire company.
This is what happened and how are we going to make it better?
What what did we do to fix it and how are we going to prevent
it. So that's the share our failures
and lessons in public. So those are some things in
terms of like how to introduce and reinforce the culture.
Maybe we'll go back to your original question, how to
increase the engagement, right? So maybe I'll pause there and
see if you want to reframe or if you want to dissect that
further. So definitely, I think I could
actually relate to what you're saying just now, right?
So in the typical set up, any companies have a values and
mission definitely, right. But sometimes those are kind of
like too broad, too general, especially for engineering team
to actually also kind of like remember all the time, right?
I think, yeah, I agree that we have, we need to have like a one
maybe layer breakdown from the company values to ensuring
values. So I think that's where the
first key take away that I take. And I think you mentioned about
Slack DM, right? I think this is coming back to
the culture, you know, the culture of the country's
nationalities. Sometimes some people are more
reserved, right? They don't dare to share
publicly, but I think if engineering leaders advocate
sharing in public first by default, right, Do it in open
rather than the DMI think that's kind of like a good nudge so
that we share what we have and not create like too many silos
internally within the team. So I think those are like the
values, right? So maybe one question related to
that, when you set the values as engineering leaders, do you
invite, you know, other executives probably or is it
just internal between engineering leaders?
Or do you actually come up with your own values?
So how do you typically set these values?
Because I think some teams may want to create this kind of
values, but maybe some of them will just think, OK, here are
the best practices from outside. I'll just take all these values
and yeah, well, this is our values now.
So maybe you have a good tips here how to set the values.
Yeah, I'm smiling because, you know, that's the exact thing I
went through at this company. The direct answer is it depends
on the context, right? So for example, when I said this
last time, we had pretty good engineering leaders that had a
lot of what I call the context carriers.
They had been at the company for a while.
They know the good and the bad and the existing culture and
what should change. So pretty much relied on those
engineering managers. So I just set the framework and
said we need to come up with five to seven values.
This is what I'm broadly thinking, not even give any
hints and let them speak up and do it very collaboratively.
So almost 7080% of the values came from those existing context
carriers, I call them at this company.
The setting was almost the opposite, a very ambitious but
young engineering team that we're just like churning and
doing a lot of good work, but not like with a great amount of
purpose and connection to the mission.
Plus also they're shy and not as much experience doing things
like this. So I did invite them to
contribute. They came up with some simple
ideas, but they were a bit shy and afraid to like speak in the
open. So I did come up with some based
on my best practices and my short tenure at the company, I
knew where some of the gaps were.
For example, this communication, I saw everybody reaching out to
me in DM, like four people asking me the same question in
the DMI knew within a couple of weeks that the culture was more
like private and behind the curtain sort of deal.
And that became a core value. Another counterintuitive value I
brought to this company is, you know, many companies these days
are like, we need to move fast, we need to move fast, right?
So the velocity is important, move fast and break things.
That's the kind of a fashion statement.
And luckily we were already, the team was already moving pretty
fast, but we were ignoring some best practices like testing and
smooth deployments and things like that.
So what A1 Valuer came up with is we take pride in our
craftsmanship, which is how we build things, but we also care
about everything else in engineering, writing high
quality code, being able to deliver with grace and
confidence, things like that. So what the best practices of
engineering were lacking? The speed was already there, so
I didn't say anything about the speed.
When I shared with my peers, they were like stunned.
They're like, why are you not talking about speed?
Bulky, That's important. I'm like, it's table stakes
already, so I want them to think about the next level or even
like the reverse direction, slow down a little.
So we actually do this, right? Yep.
So I think definitely it's contextual, right, depending on
the maturity of the team like what you mentioned or maybe how
long the team or the organization has been formed,
right. So this is also one cue for you
to actually set the culture or the value.
So I think taking just best practice to me sometimes we.
Lose the connection somehow, like we just feel that it's too
far beyond us. So I think one key take away for
me as well is that you set the values.
That is still kind of like ambitious, but achievable,
right? It's not like something that is
too far ahead that the team is struggling to actually even
relate and connect with the mission itself.
So one aspect that I typically got frustrated last time, we set
the values, maybe the principles, you know, what kind
of engineering teams we want to be, right?
People don't kind of like practice that in reality.
So how do you actually motivate or make them remember, remind
them all the time that the values are important and we make
sure that they get kind of like a practice rather than just
formalities. You know, you put in the docs,
you put in the emails sharing that with everybody, but it's
just like a slogan, right? So maybe any tips from you how
you actually remind engineers to always put values behind them
all the time? Yeah, yeah.
So I would give props to Amazon, Right.
So Amazon's leadership principles are so well respected
because they start them at the interview stage itself.
So I'm impressed how they do it. I did an Amazon interview a very
long time ago, like 10 years ago, and the recruiter actually
sent me. They still do this, I believe
all their leadership principles and said you should practice
them and and bring examples. So that's my goal standard.
So what I've been doing is towards the end of the
interview, I just share my screen and show these values and
see their reaction. I'm like, let's talk through
these and tell me what do you feel about this?
You know, most people naturally will agree, but I'm like, which
one do you not agree with? Let's discuss.
So that's one way to even get a feel for, you know, some of the
cultural aspects of the values. Another thing I try to do is
then giving kudos to the team members I incorporate like this
is the value you displayed or engineering value you displayed.
So not only say, oh, you know, you worked over the weekend, but
because of that you displayed the specific value.
So that reinforces a third thing that I want to do which I
haven't done is actually share the values in the company demos.
So what I plan to do, you have to wish me luck on this.
At the beginning of my company level demos, I'm going to share
one or more values and give an example of how we'll demonstrate
that value in that demo itself. Or in other words, right.
So it's like varying our values on our shoulder and share with
the rest of the company. So these are some ways to
reinforce the third one. Again like Full disclosure, I
haven't tried it yet. I'll see how that works.
I. Wish you good luck when you
share that. Finally, definitely the first
aspect about Amazon, I wasn't aware about that, so thanks for
sharing that. Right.
So they even asked the candidates during interview
about the principles that they have and asking the candidates
to actually, I don't know, like explain maybe from past
experience how they actually like display those leadership
attributes. I think that's probably a good
thing for any teams to actually practice, right?
So starting from the interview itself, you can kind of like
gauge the so-called the cultural fit aspect, right, with the
candidates. And the other thing, of course,
I think in all these kind of values driven, principles
driven, there should be a like a reward mechanism, right?
So for people to get incentivized, I know it's more
like sometimes it's kind of like a carrot thing, right?
So we don't want people to just get motivated because of the
rewards. But I think for things to work
really well, people needs to have some kind of motivation.
It could be as simple as like what you mentioned, right?
Giving kudos or sharing it publicly in the company forum.
I think that always gives a moral boost for anyone to
actually remember the values and kind of like display that all
the time. So thank you for sharing that.
The last topic that I think you mentioned during our pre call is
about practising gratitude and curiosity for engineers.
Probably this is something that is touchy feely, you know, kind
of thing, right? So maybe a little bit on this.
What do you mean by practicing gratitude and curiosity?
Maybe? How did you come up with this
importance? Yeah.
So when I first became a lead almost 10 years ago, 12 years
ago, it wasn't a large old fashioned company, it was a tech
company. But the time, both the timing
and the setting was not like human friendly, right?
So all of my peers and bosses managed by almost by authority
and title and hierarchy. You have to do what I tell you
and that's your job sort of deal.
When I first became a lead, I couldn't do that to my peers.
I was managing all my peers and luckily one of my good
colleagues, he was my role model.
He recommended Baki. You know, you should listen to
this podcast called Manager tools.
Don't even know if this still exists, but it was my first
introduction to podcast and leadership.
It's called manager Hyphen tools and they were two hosts.
Really funny, but also deep, meaningful advice on how to be a
good leader. And the whole team was about
gratitude and curiosity leading from behind.
So I observed that whether it was right or wrong back then,
but that was the style I I was attracted to.
Over the years I refined it, but that's where it all started for
me in terms of putting that in practice.
For example, when I join a company, I tried to get closer
to the team members, even if there's multiple layers,
directors, managers, etcetera. I like to connect with each one
of the members one-on-one and on a very personal level.
So their family, their hobbies, you know, again, it's not
everyone is open to it, but I kind of tired them out and, and
extract the details from overtime.
They'll confide in me and share things.
Some people are more open, some people it takes 3 or 4 sessions
to know that I'm not encroaching their privacy.
It's just genuine curiosity, right?
So knowing those and being able to reconnect on those, you know,
people are interested in home automation, robotics, Legos,
video games. I'm not into all of them, but I
also use this as an opportunity to learn.
At my last company, several people were into home
automation, so I wasn't as much into it.
But after talking to several of them and went going to there,
they even had their own group meetings.
So join those group meetings. I got into it, right?
So that's the curiosity part, showing that genuine interest in
what other people are interested in video games.
I never got into video games, but I ask the engineers about
what's the latest and greatest video game and who are they
playing with? So it must be similar to you.
But most engineers like, that's their bonding experience with
their colleagues, right? So they play video games with
each other. Honestly, I couldn't get in, but
I I still, I'm curious about it in terms of gratitude, I already
shared about whenever I join a company, the first channel I
create is either kudos or shout outs.
And then once or twice a week, I have a reminder on my calendar
to see what's the highlight, who went above and beyond, who
practice that engineering value well, and then tag them and
their boss, whether it's on our team or external, and give a
very thoughtful shout out to the folks.
And believe it or not, within like a few weeks, that becomes
the most active channel with all the reactions, right?
So everybody likes to be recognized and appreciated.
In fact, like one of the managers, he actually used that
as a like he would go to that Channel when he was writing the
performance review because that's the best way to see what
all accomplishments people have. And if somebody comes to me and
praises somebody else, I'm like, don't tell me I'm closing my
ears, go to the shout out channel and share that with
their with that person and their manager directly.
So those are some ways to really recognize and in a genuine and
caring manner. And it helps in the long term.
In the short term it feels like work, but in the long term I can
guarantee it helps. Yeah.
So I think it's really beautiful the message that you just
conveyed, right? At the end of the day, it's all
human kind of thing, right? So we are not robots.
Engineers are not robots, definitely, right.
So we also have kind of like a feeling and we want to have some
kind of recognition from others, right.
So I think for any leaders, don't create some kind of toxic
culture where it's all about work and, you know, delivery and
all that. Practice gratitude and
curiosity. I think sometimes, yeah, as
leaders to practice curiosity outside of work is something
that we need to remind ourselves all the time, right?
Not everything is about delivery, right?
And also issues whenever there's an issue, right, when things get
done, right. So I think that's a primary
focus for many of the leaders, but actually to also be curious
about the individuals, you know, maybe do one on ones a lot more
often and also skip level from time to time, right?
And also the kudos channel, I think for those of you who
haven't got this kudos channel, please create it straight away
and start giving people kudos. So Balki, thank you so much for
your time. I think I really enjoyed this
conversation. There are so many aspects that
we can learn from your leadership and practices.
So I have one last question that I would like to ask you to end
the conversation. I call this the three technical
leadership wisdom. You can think of them just like
an advice that you want to give to us.
Maybe if you can share your version I think that will be
great. Yeah, top three.
I would say the biggest one. This is a little more
professional, but one of my biggest failures in my
professional setting was that first job when I was a manager
at a new company. The primary reason I failed in
that was I didn't think in terms of slices of work and phases of
work, right? Like the team had this big
vision to work in the background and deliver a brand new product
in a Big Bang fashion. I got carried away.
I'm like, Oh yeah, that's awesome.
And sure enough, like every obstacle that could come our way
either like a conference or a angry customer, it would keep
delaying that. And Long story short, again like
that was AI had a miserable failure.
It took like 10 times longer to deliver that product.
So the lesson there is 99% of the projects or features you can
deliver value within a few weeks.
Anything that takes more than two to four weeks you can chop
it down into a smaller phase of work.
So deliver value in phases or slices is my first idea.
The second one is be open to failures.
In fact embrace and look for failure.
So again, it goes with the first principle, but for most of my
life, I grew up in a setting where failure was not OK, right.
So what it meant is many times I wouldn't even venture into doing
something which college I wanted to, which career I want to
pursue. It's it's too hard.
It's too difficult. So I won't even try it.
And I just like winning all the time because I was choosing easy
targets. So, you know, I love and I
especially with my young kids, I teach them to push themselves to
try harder things, not to succeed, but to see what happens
and learn from that failure. The mistake.
Third one, it's a little bit about career progression.
I would say it's OK to be immersed in work and really
enjoy and just be focused on what you're doing for a living.
I would strongly recommend though that raise your head once
in a while to go back into the community and network and build
your personal brand. Don't overdo it, but I would say
for most engineers they do. Even engineering leaders. 100%
or 120% is about delivery and getting joy from the craft.
I would say allocate 10 to 20% depending on where you are in
your career. So I'll be honest on this
podcast, I target between 15 and 20% these days because of the
executive level I am in my personal brand and networking is
quite important. So the remaining 80% I'm
delivering and having fun in work, but 15 to 20% I
intentionally do those things, building personal brand and
networking. So I would recommend that to
folks at any level, especially for engineering leaders, it's
quite important. Yeah.
So I think the last one I could agree with you, right.
So because especially the situation in the job market
these days, right, it's quite tough and especially any kind of
situations could happen, be it layoff or change of culture
suddenly in one go, right? Then if you don't have this kind
of network with community or maybe kind of like network with
outsider people. And thirdly, about the personal
brand, right, where you are recognized for some kind of
things, right? I think those would tend to open
up new doors for you and new opportunities whenever you need
it one day, right? So I think thanks for sharing
that. So Balki, if people would like
to connect with you or they want to get in touch and do a lot
more conversation with you, is there a place where they can
find you online? Yeah, I love LinkedIn these
days. I feel like I learn a lot and be
able to share my wisdom there, so I'm open to connections on
LinkedIn. The only tip I give is don't
send me a blank connection. Say something either about this
podcast or anything, but write a personal note and I'll accept
your invitation and even have a virtual coffee with you.
Thank you for that invitation. So hopefully people can take
your invite to get a virtual coffee.
So thanks again for your time today.
I think we all learn about engineering, leadership and good
practices from you. So I think thank you so much for
this time. Henry, thank you so much.
I do want to thank you personally and then congratulate
you. Since we connected, I saw two
milestones. So you are you reached the 10K
downloads milestone on Spotify, is that correct recently?
10,000 Subscribers Subscribers. On Spotify, which is amazing.
And then you were featured alongside some cool startups.
So that, that one made me smile, you know, as a podcast featured
alongside starters. Only Henry can do that.
So thank you so much. Thank you so much for the
appreciation, it means a lot to me.