Hi everyone. My name is Patrick Akio and if
you're interested in tech leadership, this episode is for
you. We cover the managerial path
versus the individual contributor path and what that
path actually looks like from a technical perspective.
How to adopt new technologies in bigger organizations, get buy in
and get things done. Both the pros of the new
technologies as well as the downsides and what they could
be. Joining me today in sharing his
stories is Raresh Mirika, Senior Staff Engineer over at Molly.
And I love the perspective he brings and the stories he
shares. So enjoy.
This morning I saw a post on LinkedIn and it was funny
because it was about LinkedIn. Now there's a little small tab
that says videos and this person was thoroughly against it.
Based on research that has been done, platform like Instagram
and TikTok and short form video content or image content leads
to endless scrolling, which is not good for the human brain.
So then I'm wondering, is LinkedIn really incentivized to
keep people on their platform and that's why they added video
or do they plan to do some good with it?
I feel like for bigger companies that's always this discussion
point, right? What is the purpose and is it in
the end good for people or not? I doubt anyone ask themselves if
they're doing any good with it. It's really I've noticed also a
few, let's say social features on LinkedIn lately.
It's it has become a a new social platform, a new social
media platform. I've read recently an article by
Bruce Schneider from the security expert Bruce Schneider,
and his point there was that the biggest successful companies out
there on the Internet are all culture companies.
They are not providing a service or selling wares or right they
are. What they are selling is
culture. So you're talking about the
YouTube, Twitter, Facebook slash Meta, everything Meta does, and
now LinkedIn. And in fact, they're because
culture has a wide appeal. So you get a lot of attention in
eye bolts and you get a lot of engagement, which then of course
you you monetize through ads, which is the the de facto way of
monetizing anything on the Internet.
So everyone that is in a position to pivot into that that
direction. They will do so.
Probably will because it's going to, it's going to be profitable
for them. Interesting.
Interesting because what LinkedIn, what was LinkedIn
selling the other day? They were selling the
recruitment services, let's say, right?
They were selling tools for recruiters.
They were selling this notion that, OK, you can reach talent
and get talent into your organization, which is a
valuable thing, but that's like the size of that market.
It's finite. It's peanuts compared to the the
culture space. Yeah, that's fair.
I wonder what it's in part to be within such an organization like
you. You've been in way bigger
organizations than I have. I work in consultancy and I go
more in and out of organizations, but for example,
booking, I was listening to this podcast and there was a guy on
the X Friedman show, Peter Levels.
I think he's a Dutch guy. He does a lot of indie startups
and he was also talking about booking.
The booking was there to solve a problem and now it's grown to
this scale, right? In the end it's also a bit
slower as a total, but every part of it is like optimized and
AB tested for conversion, which I think in and of its own from
an outside perspective is insane.
What was it like kind of working on that platform from your
perspective? That's very interesting.
First off, it's the only very large company that I've ever
worked for and that I know from from the inside and I've worked
for it for 8 1/2 years and I could say I worked for three
companies in this time because the company has evolved a lot.
When I joined, it was about 300 people in tech or so, and when I
left it was 2 1/2 thousand people.
It's an insane growth and booking obviously very
successful, world renowned. If you look at the oral history
of booking, you read a little bit a little bit about it.
It's actually on the Internet and it's told by people who were
in leadership at those times. That's cool.
It's it's really cool. Then you you learn that it's
success is owned to a few key ingredients, a few decisions,
and that's of course snowballed into a massive thing.
So one of them was what you're talking about, this hyper
optimization thing. So at some point in the history
of booking, someone decided to lead the company from a
commercial product and tech perspective, not directly
through let's say experts, leadership or you know,
consensually, democratically or whatnot, but through a tool.
Yeah. And data.
Data, yes. So you use data 1st and prove
that your decision is in fact commercially successful.
And so the teams, most vast majority of teams and, and
engineers within within booking used this tool to show that the
changes that they are making are beneficial to the company.
That's that's one thing. So that's gave everyone a date,
a data, validated, a scientifically proven kind of
trajectory. And the second is take your
hands off the steering wheel, meaning that I as an engineer
could decide for a good portion of my tenure in the company
could decide to go out there and change something that you as a
customer would see on my own. Oh, OK.
Completely autonomously, of course.
I mean, I'm a back end developer.
I would need a designer. I would have to convince one of
my designer colleagues to support me, one copywriter
colleague to support me, etcetera.
So we would make a an autonomous team, yeah, if we if we wanted
to. For bottom up.
Bottom up, we had an idea. We said OK, we think that if we
add this button here it would convert better or.
No, no product person that makes the decision or.
No, that was not required. OK, It would have been smart of
me to enlist the product person to help me with the product
task, but I could take ownership of that and I could be my own
product person. And then I would actually
implement all of this, deploy it, test it for a couple of
weeks and show with data that my idea is legit.
OK. And we're talking about regular
ideas, not things that could be affected by, you know,
regulatory. Yeah.
Ohh. There were some huge changes
that were done this back in the day.
There were some huge changes that were done in the day, but
we're we're talking really bad back in the day.
Yeah. And those had immense impact.
Like now they would be in total over the years they would be
worth stupid amounts of of revenue.
Was it incentivized to do this or was it more the culture and.
Kind of it's a mix. OK.
So for the for a good part of of my tenure there, if you were
successful from so if you did things right and you, you
clearly benefited the company, you would definitely recognise
this in terms of pay for performance.
Good stuff. Yeah.
Now this has changed and this has changed throughout the
industry over the last let's say 7-8, seven years.
And there is, I would say less of a, of a, how to say this,
less emphasis on pay for performance and there is much
more pays pay in general in in general in industry.
OK. So less peaks basically.
Sorry, less peaks. Less peaks, yes, and less
discretion from a, from a manager.
Of course, when you're running a three 100% team and you need to
allocate individual bonuses and you know everybody, everyone by
name and reputation, it's one thing.
When you're running a 2000 person organization and you're
trying to do the same thing, it's much more difficult.
Yeah, that's why you mentioned I worked for three different types
of organisations. OK.
And I'm assuming then the second type was kind of somewhere in
between. Yeah, yeah, yeah.
It was very, very fast growing. And that meant that there was a
lot of a lot of change all the time and a lot of uncertainty
all the time and a lot of communication channels breaking
down and being recreated in different ways and so on.
So there's, so there was a lot of a transition period.
Interesting from your side, Why? Why did you always because I
know you never left, let's say hands on work or you're always
more so involved where things are being built rather than high
over managers would be. Why'd you choose that path
within this org and also still continuing?
Well, I generally believe that the managers, the managers have
a tough job. So the, the managers, they need
to make sure that the team is happy, that they are working
well together, that roadblocks are being eliminated, that the
paperwork is being done and so on.
And that's just not my not my expertise and not my thing
right. Ultimately, And then there's not
enough time to keep on doing the technical work.
You cannot be a good I, I, I cannot be maybe some people can
I cannot be a good technical contributor and at the same time
take care of the team and the the people where right.
So for there, there are teams in which the, the, the manager
there, there's ATL, for example, a team lead and they have very
limited people responsibilities and they basically approve
holidays and make sure to have one on ones and things like
that. But they also have a, a
technical responsibility in the team that works some of the
time. But it's again, a misalignment
of incentives because I, as a individual contributor, as an
engineer, I can work on my career all the time.
So I'm delivering products, I'm expanding my skills.
I'm making sure that they have a big network of a support network
around me. And that helps me promote, that
helps me in my career. Yeah.
Depth. Yeah.
If I take on the the TL role now, my mindspace, yeah, is
occupied also by that. But now I'm working on two
paths. So I could promote from, let's
say an engineer to a senior engineer if I kept on going on
the technical side. Or I could invest more on the
management side and then grow from a team lead to, I don't
know, manager of software development or a director or
what not. So someone responsible for
multiple teams. Yeah.
So this means that now I have to make a personal choice and to
invest more of my time and energy in one of these paths.
So it's kind of a A robbery. You, you give me this, this,
this responsibilities as manager, then it's in my best
interest to immediately drop all of my technical
responsibilities. Yeah, because that's how I could
accelerate my growth on the management track.
That's the new path. That's the new path.
And that that makes, I think it makes total sense for the
individual now from the from the company's perspective, of
course, that means that you lose 1 headcount effectively.
So you either compensate for that or you try to trick the
person into taking on this, this role that's kind of a from a
career growth perspective is at a disadvantage, but they feel 2
roles for you as an employer. That's great from an efficiency,
cost efficiency perspective. Cost efficiency, yeah.
Yeah, but it's, it's a short, it's a short term thing like no,
but people who are very talented in either of these tracks,
right, they, I think they will perceive it as a bad deal.
OK, interesting. Like I, I'm contrasting this
towards my own experience because right now like I'm in a
consultancy company and we're experimenting with this team
lead structure. So part of my time is allocated
towards one on ones, indeed more so personal happiness for
consultants. And I don't have any insights
into what type of client work they do.
So this is more so the people management role.
And then I have my client work and I said yes to this because
I'm kind of torn, right? I do see these as two separate
career tracks and I agree with you that there's going to be a
decision on. I don't think this in between
stage is good. It's healthy.
I do think it's good for me to gain this experience and then
see what I want to do from that aspect.
But yeah, I do realize that if you have this mindset of OK, I
already know what I want to do, then it's a bad deal to split
your time because split focus doesn't work.
Oh, if you if you want to try it out, then it's great, especially
in like if you're fortunate to be in a very fast growing
company, then you are in a place where you can try out the
management track. And if you like it and you get
hooked on it, then you have a an elevator ride because more teams
are being formed all the time. You have priority.
You have a place to be 1 the the leader of one team.
But then you know that three teams are going to be formed
next quarter and they're going to pick to lead those three
teams the person who has most experience, which is you now
having 4 the total of four months of experience, you're the
the best person we have. Yeah.
But of course, with those four months of leadership experience
also comes maybe four years of tenure in the company, of
course. So then that's a huge
opportunity for people wanting to jump into, into management.
So and people, I've seen people jump into not, not the teal, but
even the director level. Yeah.
Straight from engineering because based on lots of tenure
and a little bit of trial, of course here and there, yeah.
Interesting. And for you then this you
already knew that this kind of people management track was not
for you. No, it's why you decided not to
do that. It was not appealing.
And so the, the direct people management was not appealing at
all. And the paperwork, I'm just not
equipped to do that. I would fail at it horribly.
So, and I, I always had this, the autonomy that I needed to do
my work and work on my projects that I didn't really need that
lever that management gives you, which is, I mean, of course you
decide where resources are, are allocated and you can give teams
direction and so on. I never needed that because I
could already do that through influence.
So there, there was no, no appeal.
Nobody ever stopped me from doing what I, what I thought
was, was right. They, sometimes they had
difficulty being convinced and I needed to put in more effort.
But that's fine. That just validates the idea.
That's OK. But having this massive
resource, so you have a a whole structure of manage managers and
teams and so on that works. And then you come in and you
influence that structure to into a certain direction.
That's a huge boost of productivity for me because I
don't have to actually think too much about, you know, their,
their happiness and environment and so on.
There are it's handled. It's handled.
Yes, it's provided as a service. Yeah, perfect.
Interesting. What is this career path?
So are we talking about the management track?
And I know traditionally I have a good view of that
specifically, but I'm curious from your perspective, what is
this career track, let's say with depth and also more
technical leadership then look like because there are skills
that overlap I feel like. Yeah, it depends a lot on what
you on what you want to do and the context, right.
Because there are a lot of, let's say traditional individual
contributor careers. You see them more in specialized
domains like for example security and networking, I think
where you have very, very, very strong experts.
So they they learn, they apply, they apply things at a higher
and higher scale. But it's as you say more depth,
it's less new initiatives and trying things out.
It's more like, OK at this level, at this stage of our
company or our our organization, we need to have this level of
maturity of these solutions and so on.
Yeah. And those are usually the areas
right security. Those are usually, yeah,
exactly. These are traditional areas.
Things are quite well settled and they're very, very demanding
in terms of quality. Yeah, but the innovation space
is smaller, Yeah, unless you're at a very big Corp and you're,
you know, rolling your own software defined networks like
at Google. So then but.
It's trail blazing. Then it's very different, Yeah.
And but then if you're in product development or I was
more in infrastructure, but at the at the edge between
infrastructure and applications. OK, so close.
So close, closer to the application side, but I was also
database administrator. But as a database administrator,
of course you're interacting directly with the application.
Yeah, it's gonna have huge impact.
Especially from a reliability perspective, you can have huge
impact. Yeah.
So then you can take this path of becoming an expert, then you
become a database engineer or security architect, etcetera.
Or you can go for more breadth. Breadth could mean business
acumen. So you're an application
engineer, but you know very well the business, the industry.
And then of course you can contribute from a directly
commercial perspective. So you're now finding solutions
to business problems or you're finding that there's new
technology and then you you use your own creativity to apply it
to a certain business direction. So that's very, very lucrative.
For example, in in my previous job, this was the case for a
data science and machine learning or you can try to
introduce new technology. So, so this is basically opening
up new avenues for the company. So you can it could be based on
hype like now with AI, everybody's trying to find a, a
problem for the, the new AI tools that are available.
Oh yeah, sometimes successfully. And then the skills that you
need to grow are very much more people skills because you need
to influence people. You need to convince people to
help you. You need to convince people that
it's a good idea. You need to make a very good
compelling argument about about the the ideas that you have and
so on. And then yeah, it kind of blends
it a little bit with with people management because like 80% of
what we do is dealing with other people past if you're a small
start up of a few individuals, then most of the time you spend
coding and building products. Yeah, when you're in a large
company, most of the time you're trying to stay out of other
people's ways and try to influence or make make room for
the thing that you need to. Accomplish still make it happen.
Yeah, still make it happen. That's the most, most part of
the job, the coding. It's a small part of the job.
That's considered the easy part, right?
The hard part is to arrange all of the elements in such a way
that outcomes a product that's still usable for the for the
customer. And your team gets what they
need and the other teams get what they need because the
relationships between teams matter a lot.
So you cannot make sure that it happens for you at the expense
of someone else. Yeah, usually that's really bad
for. Usually, yes, yes, I think I
think of this from my own perspective.
And this year I made a decision to take up an assignment as
product manager, product owner, product manager, the roles are
kind of interchangeable at this org.
They say Product Owner is more technical, which I think is
pretty funny, but in any case. And it's mainly because of that
autonomy and decision making power that you mentioned, right?
If I had that more as an engineer, then maybe I wouldn't
have switched to this role to see what it would look like to
be fully responsible or more responsible than I was
previously. And now I notice indeed, skills
like communication, getting by and solving people problems,
those are things I excel more and more at just by virtue of
doing it more often, right? That's the experience I gain
here. And I definitely miss the
implementation side. So for me now with this
learning, I feel like the ideal role would be to be more of a
product engineer where you have that business acumen and you're
also there with a certain level of autonomy and business power
or decision making power to actually drive change and also
implement it. And then still the
implementation is like this, I don't know, this fulfilment,
which is more personal, where I actually feel like I contribute
and not just kind of overarchingly see and plan and
prioritise and other people contribute.
Like I feel like I'm not doing as much of the work as other
people. But then people appreciate that
you are in this position. That's, that's kind of your
role, right? You are the orchestrator.
So that's how I now see my path towards the future.
Have you ever been in a position where you drove change within
the organization just by virtue of you having that autonomy and
decision making power from your position?
Yeah. So I on a number of occasions
I've autonomously or bottom up introduced technology, usually
within a group of people. So we decided to try something
out. OK.
So based on based on what? Just based on what was new or
what? Based on what was new and what
was what was interesting to us and based on opportunities that
already existed in the company. So, for example, around 2016 to
2017 had booking there. There was a lot of data
available for data science purposes.
Yeah, but it was exploited in a quite naive way, let's say.
So traditional querying and reporting of it.
And there was no strong tool for doing data science.
Yeah, at the time. So a colleague of mine and
myself, we found this, it was back then a relatively new
project called Apache Spark. Oh yeah, it is, yeah.
And and we decided to just try it out.
So being engineers, it was trivial for me to just get the
library, install it and connect it to the cluster and run some,
some jobs on it and see what it spits out.
So for me it was trivial. Yeah.
For the 100 or so data scientists around, this was
earth shattering. Yeah, right.
Yeah. They, they had no, no skills, no
knowledge, no access, no, no way.
They couldn't make it happen. They couldn't make it happen.
So then we decided, OK, this is interesting.
Of course I'm an engineer, I can query data, but ultimately, how
useful am I going to be, right? I'm not going to be of of much
use because I'm not a data scientist.
Not compared to the hundreds of data.
Scientists. So we made the decision and a an
informal deal with two of our colleagues, data scientists that
we will support this project. So the installation upgrades,
making everything work fine, we will support it.
And they will have to train and get all of the scientists to use
it. Yeah.
And that happened. And then within about a year or
so, we formed, we, we collected other teams that also had
similar initiatives. So one of them had an an
initiative in deep learning with image, image tagging.
And another team had another initiative in data science
proper. And we created a a track, so a
collection of teams under one leadership to provide machine
learning services to the to the greater organization.
Yeah, to these balloons a lot over over the years, but it
basically started with with two people saying OK, it would be
really cool if we could use this new tool.
I mean we are data rich, we have we are compute capacity rich.
We can make something out of it. We can definitely experiment
with it on company money and time.
So why not? And then signing up more people
to actually use it. And because without signing up
the data scientists, you don't have a business case, right?
You just have a toy tool that you can you can use and, and
show off, but you don't have a business case.
You're not actually delivering value.
Yeah. But by enlisting these people
and organizing, organizing them a little bit and organizing
trainings and offering these resources, then basically you
are reshaping a large organization and how they how
they work every day. Interesting and.
I mean, my contribution to this was just the pushing the the
kick in the butt that it needed. And then of course, it's
snowballed and a lot more people were engaged.
I mean, you had the right skills to get it up and running and
then the that probably that people side of it, that business
acumen, that's what got people buy in.
Towards a vision I was able to convince.
So that's the thing, a lot of people have the skills.
If you, if you ask them, make this work on this computer, they
are much better suited than I am.
What I brought to the table or the the the the critical skill
that I have that helps me do this kind of job is convincing
other people to help me. It's it works very, very, very.
I can. See that smile?
It works very well. It was.
It works scary well, Yeah. And of course, I, I sell a story
in which you are, you are going to gain out of this, right?
So this is the story that if you do this, you train these people,
you are going to be at the forefront of this new
technology. So you will be well known in
this community, which is obviously beneficial to you.
There's a lot of credit here. There's I'm not doing this for
my own, my own credit or gain. So you're the front person for
this stuff. But obviously it's a win win
situation. And yeah, it's it works.
Convincing. People 80% of the time, it works
100% of the time. Yeah, yeah.
Convincing people is a powerful skill and I feel like it might
be underestimated. Like I I like the art of having
a discussion. I, I was very stubborn.
I think early in career I still think I am stubborn, but I've
learned to be flexible, right? I can be convinced.
Let's just have a good conversation and see what the
arguments are. And I feel like that flexibility
and still persuasion, power like story and a vision that still
all will contribute towards persuading someone.
Especially people with let's say that don't have the skills to
get something up and running from an engineering perspective
like data science or people that are completely non-technical but
do have business acumen. From a business side, I think
it's very powerful from an individual contributor
standpoint, especially when you have that let's say decision
making power or autonomy to make those decisions.
But before we go into more how you did it specifically, I'm
interested in the environment that cultivates that because you
said, OK, we had an idea more so up and coming technology with a
vision and with the environment that we have, we could see this,
right? And we can make the decision to
do this experiment. All of that just makes it seem
like you woke up, had this idea, did it.
But there needs to be time. There needs to be an an
environment to be able to do so, right?
Yeah, obviously, no, I mean, I did wake up and I just did it.
But what I, what I'm not factoring in is that like the
other 10 years of organization building that I, I was on the
shoulders of others when I did that, right.
So I, I kind of landed on the shoulders of others.
I also participated in building things.
But yes, it's true, there is a special kind of environment that
allows these things to happen. And it's an environment where
bottom up solutions and initiatives are appreciated.
At the very least they're not hindered.
It's an environment where all ideas and all perspectives are
at the very least welcome. But also quite a lot of
constructive criticism is like, yeah, the some, some vigorous
conversations happen all the time.
Yeah, but a productive 1. Most of them.
So even even though when even though the conversations can
become a little bit emotional, it's very important that there's
a lot of psychological safety. Yeah.
So even if the ideas are criticized ruthlessly, it's very
important that at the end of the day, we have trust in each other
that we want the best on a personal level, we want the best
for each other, right? And because in a very fast
growing organization, for example, that trust gets eroded.
You have teams that are very far away from one another and they
don't see each other's perspectives.
And you also have engineers with very little tenure and so no
track record between each other. And it's very difficult to
establish that those relationships.
So if you have a more of a hacker ethos with a small team
that have been together for a little while and they have a, a
very good goal in mind, right? They, they are all aligned
towards a, towards a larger goal, then it's possible to have
these vigorous conversations on topic, even though, I mean,
we're computer nerds, we fight over crazy stuff, right?
Like which editor is the best? So of course you, you do do
that, but that does not lead to judgement for the other person.
So that's, that's very important.
So having this this high degree of psychological safety is very
important. Then of course, having a
talented team helps a lot. And here The thing is that it's
usually a strategic kind of a strategic decision.
If you build your company with a strong focus on in sourcing
things, then you have more work to do for experts in different
fields. OK.
If you choose to externalize, for example, you choose to host
on cloud, then you have no reason why you would have a six
person networking team. Yeah.
Doesn't make sense. Yeah.
So you don't have those skills. You don't have those skills at
all anymore. So you you have no, no reason to
employ those people. You're robbing yourself of a, of
a talent pool that could be a multidisciplinary talent pool
that could help you in other areas of, of your company,
right? So many companies choose to
externalize a lot of of their, yeah, their skills in the end.
And so they, they invest more in industry expertise, but they rub
themselves over this multidisciplinary, right.
So they, they, they don't hire, you know, physicists,
mathematician, chemists. I worked in a team.
So I, I worked in a team with two surgeons, OK.
So I was the, I, I was the safest person in the office
because I literally had, yeah, two medical professionals that
were both software developers now, OK, on either side.
And of course, they bring a different perspective to things.
Interesting. That's phenomenal.
I mean, I from from my side, I love working in the cloud.
It's because me as an individual, I have less total
cost of ownership, right. I don't have to think about
things like storage, networking, scalability, elasticity.
It's all out-of-the-box there. And I think for I think the
majority of organisations that just makes sense indeed.
And when you get to a point scale wise and where you can do
more and can afford to because you just have I think the
capital to do so, bring that back and indeed kind of
internalize that knowledge, then possibilities open up.
But it's a, it's a bigger risk as well at the end of the day
because a lot of things have to come together in the right way
to actually execute or be able to execute on the benefit there,
which I think makes. Sense yeah, it's important to be
successful first, right. So once you are successful, but
then you still have to have the right ideas.
So even though you're making lots of revenue, you still have
to have the right ideas and recognize that OK, from here to
the next step, we need to change a bit.
It's not enough to find the the widgets to sell and be
successful in selling that one widget.
We now have to create this new organization that innovates and
invents and so on that goes beyond the pre made building
blocks, the Lego stats, the let's say that the SAS space and
the cloud space offers us. Yeah.
Do you think it's the right ideas or also just the ability
to experiment with many ideas in a fast-paced environment?
But just that, just the idea that you need to create that
freedom for yourself, that's in itself, that's difficult
learning to have right? Because The thing is, as an
organization, you learn how to be successful in your own
paradigm to change an organization, that's a a
different skill. And usually usually
organizations resist this. Yeah, it's very long process to
change an organization. Yeah, that's why I'm so
fascinated by this environment where things, ideas pop up
bottom up, right. It's not often that I hear that,
I hear preach and ideas that this is what we want.
But to be able to have that I think is a different ball game
from an from an individual contributor side.
Do you get time for that or how is this facilitated, let's say
by the, by the environment? Yeah, well, I prefer and in in
my case, it's also an internal perspective within my, within my
career generally it's yeah, I I could just take time and do it
right. So there's no, there's no risk.
But internally in my head, there is risk, right?
Because I am taking time. I, I am held accountable for
what I did with that time. Yeah, or I could be, I could be
wasting time and even worse, I could be wasting other people's
time. That's, that's another topic.
So if you create an environment where individuals are allowed to
do this, but they're not, let's say they're incentivized, but
it's not advertised that they should do this, Yeah, Then you
have self selection. So a few who are risk taking
believe in their idea and they think internally that they need
to work hard to make it happen. They will show up, right?
They they will see the door. They're like, OK, interesting,
yeah, let's see what's behind door #1 oh, wait, there is a
void here, I can build my own thing.
OK, fine. Do that.
Then from externally you monitor and you, you look at it, you
say, OK, they're onto something. OK, fuel the fire a little bit.
Yeah. Or give them a little bit of
coaching. If they're causing a mess, which
I've I've done in the past, of course they're causing causing a
mess. OK, let's clean the mess around
them a little bit and help them put a bit of structure.
Like for example, in the story about machine learning, there
was at some point a lot of structure was put together to
make things efficient and orderly.
And so that people are no longer confused about who's running
what and why, which it was the case before.
And there's only a, a small number of initiatives that are
actually going to going to happen like this at at the
larger scale. At the smaller scale, if we're
talking about experimentation, AB testing and having bottom up
product ideas, then that can happen within the team.
So within the regular conversations, products to
engineers and so on, you need to really listen to what everyone
is talking about. And you really need to ask
everyone, OK, what do you think about this and so on.
And then, then you're going to have seeds from that.
And of course not everyone is going to go out and pitch their
idea. But if you can extract the idea
as a product owner or product manager and, and always start
from the perspective of everyone has valuable ideas and we should
really analyse each one of them with equal merit, then you're
going to get. OK, well, actually that's a good
point. OK, let's put it in the next
print or the one after that. Yeah.
And that's how you get, you extract bottom up ideas and you
get to the implementation. And people are very, very happy
to discover that 2, two weeks later, they're working on
something that they just blurted out in the last brainstorming
session. They're really proud about that
and excited to work on it. And of course that is becomes a
flywheel of motivation and and performance of the teams.
Yeah, absolutely. I I love that perspective and
insight. I'm also wondering when it comes
to those bigger, let's say, structural changes, especially
when it comes to new tooling and technology adoption.
It's fine if the tooling at the end of the day has that
longevity that you aim for, right?
But with new technology, they pop up sometimes like mushroom
like. And if you choose to adopt it,
especially with an organization and at the end of the day,
something better pops up or something just actually doesn't
work out towards the vision that you had, it can have pretty
severe consequences as well. Is there any experience you've
had with, let's say, advocating for a new adoption of a
technology where things didn't end up the way you want it to?
Yeah, yeah. In fact, I have an example of
that. So also also a long time ago, a
few colleagues of mine and myself, we started playing with
containerized infrastructure. So we got a hold of something
called Mesos. I think it became later on
Apache Mesos. And it's a, it's an old
orchestrator, a bit more visual, a bit more like VM Ware, let's
say. Yeah, it, it was OK.
Obviously it, it was far less powerful than what Kubernetes is
now. But this was pre Kubernetes,
yeah. And we thought, OK, this is
interesting. This is a way for us to run,
well initially toy workloads on a, on a cluster.
So we set up a cluster. We started playing with it.
I started researching a little bit about, OK, what is contain
containerisation? What is it good for?
Why this new paradigm? I mean, obviously I understand
why this would be useful in a, let's say, virtualized
environment, like in a cloud environment or Lambda, OK, you
can run tons of things over so much metal.
So it's efficient. It's, it's an efficiency thing.
But beyond the efficiency thing, what I found was that it allows
the developer to self-serve to hardware resources just like in
a cloud environment. Obviously we were on an on Prem
environment managed servers managed by ourselves, but still
from the application developer to the servers, there was a long
chain of communication, approvals, budgeting, planning
set up and so on. So it was, it was very difficult
for for an application engineer to create a new flavour of
application. It was very, very easy for them
to scale up an application or down or what not.
That was relatively easy. But for them to create a new
flavour that is very difficult. And there was a, there was a, an
appetite within the organization for being able to spin up new
Java services, for example, so and the new toy services and so
on. Yeah.
So I thought, OK, this is this is quite interesting.
So this actually allows us to put effectively an API in front
of limited hardware capacity and then offer this as a service to
application engineers and then they self-serve and host their
applications within this. So this is a paradigm shift now
where I my mistake was not adopting this initiative as my
own and dedicating my my whole time to it because I was engaged
with something else at the time. But what I did in what I thought
was support to the the existing team was to explain this idea
and paradigm in a blog post. OK, yeah, medium sized blog post
internal to say, OK, this is a new way of thinking about this.
You can, we can offer you this and you will get this thing,
this API and this world where you can expand and install your
applications and offer them to our customers.
Ultimately, yeah, of course, on the backdrop of experimentation
and everything that will happen anyway.
So I, I posted this and well, left for holiday after a a
period of time. This caught people's attention
and it caught management's attention.
OK, Of course. I think the the back story is
that people in in the application space, they were
very thirsty for this and they pushed management into, well,
maybe this is a good idea. Could you just make it happen?
Yeah, this is what we need. They were very, very thirsty for
this, this degree of freedom from the infrastructure
perspective. Nobody really was aware or cared
about this much because of course, they were still doing
their thing that they they knew they needed to do for years.
And so this perfect storm happened where management
decided to, well, yeah, make a run for it.
And they put together a number of teams with very little
guidance in the end because we didn't know what we even wanted.
This is a yeah, blue ocean idea put together these these teams
gave them the mandate to. Yeah, just build it, whatever it
is. Yeah, and they, they really,
really struggled, right. So they, they got between a rock
and a hard place. They got between excited and
eager management and thirsty and yeah, eager also users, client
users, yeah, internal users. They were really between,
between a rock and a hard place. And it was not a pretty, pretty
picture. A lot of people ultimately did
not appreciate my efforts to popularize this idea.
OK. And yeah, I think ultimately,
yeah, it's a, it's a, it's a big mistake of, of mine to, to have
try to popularize an idea without giving the necessary
support or guidance or, or toning down the, the
expectations of people around me.
I can see that learning because I mean, you said one of your
strength is that persuasiveness, right?
So you probably saw the appetite for it, which is then absolutely
leverage that you're going to use to get an idea through and
you wholeheartedly believed in that vision, I'm assuming?
Yeah, no, of course I of course I believe it's useful, but I
mean, I didn't think they were going to take it this far.
I I thought that they. I didn't know.
I didn't think anything later on, I thought I Oh my God, like
I would have expected you to be more reasonable, reasonable
about things like you cannot expect everything to just show
up. This is brand new, Like
Kubernetes didn't exist. Yeah, so, right.
But that's that's hindsight. And in the end, it doesn't
matter because I'm responsible for what I think and what I say
and what I do. The reactions of other people, I
shouldn't have expected them to react in a particular way.
I I should have made sure that they understand.
OK, this is just experimentation.
We just try things out. This is a possibility.
This is why it's worthwhile our time.
But don't get too excited. But I didn't do that, of course,
and that was a huge mistake. Yeah, Yeah.
I appreciate you sharing that learning.
I I can definitely see how that can escalate quickly, right.
And eagerness from both side management and from a user base
and a team in the middle puts basically a high make pressure
environment. Yeah, really at play there.
Yeah. And I, I, I'm really, I'm really
sorry about it, really, because I it's the, it's the worst
thing. Like if I cause an outage that
many times, if I, if I cause a technical problem, yeah, that's,
that doesn't really hurt anyone. Well, in my current job it
might, but in my previous job, it didn't.
It just meant a bit of loss of revenue.
Yeah, and that's OK. That's part of the that's part
of the rules of the game. It's still a terrible feeling
from your perspective, yeah. It's a terrible somewhat
exciting yes, it it no, it, it is a bad it is a bad feeling.
It depends on it depends on what happened right.
But when you heard people, people that you have to show up
and look them in the eye the next day, but anyone really
strangers as well, then it really hurts.
Then you really, you really get put down a bit.
You, you get humbled. Yeah.
But things, I mean, from my perspective, I'm an outside
perspective, it feels like you have a big sense of ownership
because to attribute that to like you starting a flame and
then other people really fanning this flame, like as a collective
fault. I feel like also within that
organization, if the idea and also the execution turn out to
be right, then everyone will be celebrating, right?
But it's because it went this way that that's the learning
there. Yeah, of course, but that,
that's the case for, for everything like the, the all,
all accidents have good intentions.
Like unless you're, yeah, OK, we, we're not going to talk
about people who intentionally cause harm, right.
But every time that you do cause harm inadvertently, of course,
you have to take responsibility for that.
Even even if, for example, it's an, it's an incident, we do
postmortems for incidents and it's very, very important to
take responsibility for it. That doesn't mean that you need
to be punished for it. You're, you're punishing
yourself well enough by just saying, OK, I, I'm definitely
going to try not to do that again.
That's, that's enough. But it's really important to get
the learnings because otherwise anything is excusable.
Then any kind of risk taking activity becomes excusable
through this lens of saying, well, but if it turned out all
right, then everybody would have been happy.
Well, but then I can push it really far right with the risk
taking. And that's that's where you get
into breaking the law for the benefit of profits, for example,
because you go, oh, but I mean, obviously if we can skirt this
regulation and become successful, then everybody's
going to be happy. Well, yes, but that's not the
right thing to do. And you should have learned that
a few steps prior. Yeah, Yeah.
I really like that perspective. I've seen things when an
incident happens, happening twofold, like you describe it,
where people really take to heart those learnings.
And also we accept that mistakes happen and we move on, right?
Or where all of a sudden we say, OK, our risk appetite might have
been too broad and then processes come in place.
And then all of a sudden that autonomy and decision making
power gets taken away. And even then, like it can
happen with reason or it can happen completely the other way
where all of a sudden you're like, OK, we can't do anything
anymore. And I see organizations lean
more and more towards sometimes taking away or putting in
processes too much or too quickly.
And then when processes are just too much, you lose this kind of
experimentation or that freedom and autonomy.
And yeah, I think it has to be a trade off, right?
Not every company is bank. So the risk appetite can vary
and you need to make a conscious decision and what to adopt
process wise and how freedom or how autonomous people can be.
Indeed. But there is, I think there is a
modern tendency towards safety through internal rules, yeah,
rather than safety through, through inter, through
incentives and this taking responsibility and acting as an
individual in the best interest of the organization.
Yeah, this is I think also because or, or one of the one of
the contributing factors is that individuals feel more safe,
psychologically safe if it's rules based, The other way is
much more personal. And it's easy to perceive this
responsibility that falls on you in a, in a difficult, difficult
way. Right.
So it's a, it's a way of protecting engineers, protecting
people from fall fallout. Yeah.
And that allows you to have a larger, less experienced
organization with less friction with less people work inside
that organization because everything is laid out.
And you cannot cause an incident because there are all of these
rules in place that prevent you from causing that incident.
Right? Yeah.
So this means that you're excused from explaining
yourself. Why did you do from A to M that
caused the incident? Because you should stop at B.
Yeah, that's the process. Yeah.
There's a control there that that stops you.
Now, of course, this has a cost to agility and so on.
And within an organization, you need to find the balance between
putting these controls in place. I mean, I work now in a
regulated entity, so we have to have these controls.
Yeah. Yeah.
So there's. But The thing is that the
controls need to provide the safety, a real safety, not the
safety that the auditor sees and they check the box.
No. So the control has to provide
real safety. And at the same time, the
control has to have a very good story for how the agility of the
team is preserved and or what measures we took internally to
make sure that the agility of the team is preserved.
Because if you just slap on controls over a system that was
not meant to have them, for example, you commit code
straight to the straight to the repository and deploy straight
to production and there is no control.
That's what start-ups routinely do.
Then every engineer is empowered to build a feature and deploy it
and test it in production with some users and roll it back.
OK, Now you become regulated entity, for example, and you
need to slap on a control you need to have for ICE principle,
for example, and you need to have some change management for
production. You can no longer create
production database tables directly.
Yeah, OK. Now as an engineer, I can only
test on my local machine, so I have no way to test anymore.
Now the company is losing agility.
Yeah. It's.
Very obvious. So we need to invest in
mitigating that loss. I it's very important not to
skirt the regulation. So don't create the control just
for show, but mitigate the the impact and well creates pre
production environments or create a way for engineers to
test changes potentially in production but without full
deployment. So divorce deployment from
release with feature flags or experimentation.
So you need to do these investments in order to regain
the agility. And then at the end of the
story, if you're successful, then you're going to have the
cake and eat it too. Yeah, it's going to cost.
Yeah, that's the best part. I feel like with that mindset,
because controls are easy, right?
You slap a control on it, but that can have tremendous side
effect, not just in way of working and productivity and
agility, but also sense of fulfilment and honestly just
happiness, right? If you work in the sandbox
environment as an individual, doesn't feel as good as when you
can experiment more so with actual users, right?
They say that when this chain of you solving something and then
it actually landing to the end user is very long, then that
usually correlates with people kind of losing sense of what
they're doing. And then also, I thought it was
interesting that you mentioned this feeling of doing the best
for the organization. That's something that I felt
very strongly like I started out in operations and when I heard
from honesty, my product manager, whomever we needed to
do something and I thought it genuinely didn't make sense.
Like I could not just stop there and do it.
Basically it was it was always bothering me.
So I escalated or I would make sure that the right people would
be at the table to have that discussion regardless on if I
was right or wrong. But I need to be convinced that
this is indeed the right thing for the organization.
I've realized in practice that not everyone thinks like that
and therefore some controls are are better in place.
But I think it's very dangerous also when people of, let's say
higher decision making power or levels of autonomy, you don't
have the best of the company like at at their heart and you
see strange decisions being made, especially when you're
from that role of individual contributor.
Yeah, no, that's, yeah, that is absolutely true.
Yeah, yeah, yeah. You, you don't want to see that
no at all. And it's, it's, it's extremely
damaging. As so when we're talking about
the, the population of individual contributors that are
exposed to decisions by, by senior leadership that don't
make sense, the the feeling of demotivation is very, very
intense. Yeah, yeah.
It's it's a situation that you want to avoid as much as
possible. And here like two things to
avoid that would be A to B. It's very important to be able
to explain and to answer any question about a decision, high
level decision, especially strategic decision and be open
about it and be able to explain to everyone involved why you
chose that it could. I'm OK even with explanations
that are not maybe so objective. Yeah, right.
What you want to hear? Yeah, Yeah, that's, that's OK,
as long as you're open to explaining it and you're,
you're, you're clear about. It and then we can disagree and
commit. Yeah.
Then we disagree and commit. Yeah, yeah.
And because you can make an argument, especially in
technology, you can make an argument for either or.
Yeah, it's subjective. You choose between cloud
providers. It's very easy to choose either,
either or any one of them Is, is reasonable, right?
Obviously large successful companies use all, all of them,
right? So if you choose between one,
one or the other, then you, you should be able to say, well,
it's because of of this reason or this technical reason or this
business strategic reason or this financial reason or.
What or what? Because if not, then it's not a
credible, Yeah, what else decision, right.
Yeah. And the, the, the side, the,
the, the, the downfall of that is that a lot of a lot of people
that are witness to that, they're going to be extremely
demotivated. So yeah.
Avoid. Yeah, I, I agree.
I I was wondering how to prevent that.
And I agree that when it happens, the communication and
the clarity is like paramount. Without it, you're going to lose
a lot of trust and a lot of motivation there.
But I'm wondering from your perspective then also what
you've seen does, let's say a higher leadership people that
are not on this technical leadership path, but more on the
traditional managerial path. Do they need to have any
experience with software engineering Or what have you
seen with people that have had that experience versus the
people that don't have any experience?
Well, I've seen great managers in both sides of the camp,
right? So I've seen great managers that
come from very different backgrounds that cannot code to
save their life. Yeah, they are still, you know,
they're they're still productive with the computer, right?
We're not talking about people who are not fit in in that
space, right, But they, they are not software engineers, but
they're great managers. They are very much people
oriented or, or business savvy. They're smart people.
They're very, very successful as well.
And of course there are engineers who chose the, the
management path And well, by the time that you see them as
directors or VPS or whatnot, of course, many of them have not
touched code in a long time. So you might see them as rusty.
Some of them, if you look in their background have
contributed to interesting pieces of Internet
infrastructure. Yeah, So, so right.
So it's a mixed, it's a mixed pool.
But I, I don't think that it's necessary for a, a manager in,
in the IT industry to have a software development or IT
background necessarily at all. As long as they're passionate
about what they're doing. And yeah, they, they are, they
are a good fit for the organization.
That's that also matters a lot because a manager in to give an
example, Amazon infamous management culture example in
Amazon is not going to be fit in Spotify, neither the other way
around. But they are individually very
successful in their own organisations as long as they
are a good fit for their it's it's the same same thing for
developers, for software engineers, for any other
employee, if you're a good fit for the organization, even
though from the outside it might look like, OK, that
organization, I never want to work there, there's still
thousands of people working in that organization and many of
them being very successful. So there is no reason to throw
rocks at them. It's just, yeah, everybody likes
their their own game. Yeah, I mean they also help form
that, right? Even even if you are new and you
join the leadership team immediately, it helps form part
of now the new organization. So that's why if you do a
complete swap initially, then those organizations don't make
sense with those leadership teams.
But I think if you would do it gradually, then the organization
will change. Yeah.
But there's a strong yeah, there's a strong organ
rejection. Exactly.
If it's a brief match, yeah. If it's like DNA doesn't blend,
then yeah. Yeah, it doesn't work.
There is a strong organ rejection and yeah, it's very
difficult to to navigate this. Well, organisations do need to
evolve, but people within the organisations have their own
ideas about the direction that they would prefer to evolve.
And sometimes it doesn't match with with what happens in
reality. That's fair.
So if you're, if you're talking about should we hire a new
leadership from a particular background or from a particular
company because we want to be more like that, You can.
Yeah. That there's a responsibility on
both sides to make that transition smooth.
And there's also responsibility on your side to explain
internally in your organization why it's a beneficial shift
towards a more like that. If you try to do this in a
covert way or or without any planning at all, then I predict
sparks. Oh yeah, I from history and
experience, I, I felt some sparks indeed.
I really enjoyed this conversation.
And I must say, before we round off, is there anything you still
want to share? We talked about technical
perspective, leadership, I think driving ideas, getting by in on
the people side as well as the technical side.
Yeah, maybe if you, if you find yourself in a position of
influence or leadership in a company, I think the best thing
you can do to serve your your company is to promote systems
and rules and incentive structures that you can easily
explain to someone without them needing to be in the room when
the decision is being made. So if you, if you can make it so
that you can explain the rules of the game to someone outside
of the room and then they can work it out to OK, if this is
how decisions are being made, then I'm confident that they're
made that they are solid, even though I don't know the
arguments because of reasons. Yeah, I'm not Privy to those
arguments, but I know that the employees perspectives were
taking into account or right what whatever it matters to
them. Then you're going to have a much
easier time with convincing people to to row in in the in
the the right direction. Interesting.
That really hits home because I, I feel like when decisions were
made and I don't know what process or what led to that
decision, yeah, that's when I feel pain and when I see
friction around the extra critical.
But when I do trust the process, it's different.
Yeah. So it's very important that the
process is credible because people are, especially in in
medium large organizations, people are not Privy to a lot of
the details of the decisions. So a good example is promotion
processes. A promotion process that is
manager discretion is not really a credible system, no, because
there is all sorts of incentives, right?
The managers are incentivized to have their their reports happy.
And so there is an incentive to promote early to give an
example, right, all sorts of things.
So if you set up a system where the process is credible, then
you're going to have a much, much easier time to explain the
the outcome. Yeah, yeah, Love that.
All right, we're going to round it off here.
Thank you so much for listening. If you're still here, leave a
like, leave a comment, let us know what you thought and we'll
see you on the next one.