Be the supply to the unmet, demand things that you can make
a huge difference on if bony, you just go and do it.
You don't need to seek permission.
If there's time, just go and do it, and you'll make someone's
life, so much easier, they'll be grateful for it.
And you'll have some impact and created a positive experience
with somebody, and that's how you end up growing and being
noticed. Hey everyone.
My name is Henry Surya be Robin. And you're listening to the
tekhelet Juno, the show will be bringing you the greatest
technical leaders practitioners and thought leaders in the
industry to discuss about their Journey ideas and practices that
we all can learn and apply to build a highly performing
technical team and to make an impact in your personal work.
So let's dive into our Journal. Hello everyone.
Welcome to another new episode of the tekhelet journal podcast,
very happy to be back here again to share with all of you, my
conversation with another great technical leader in the
industry. Thanks for tuning in and
spending your time with me today, listening to this
episode. If you are new to the podcast,
know that technology, you know, is available on major podcast
apps such as Spotify, Apple podcasts, Google podcast,
YouTube and many more. Please subscribe to the podcast
to get Defied for any new episode that I release every
week. Also check out and follow
technology, you know, social media channels on LinkedIn
Twitter and Instagram everyday. I post nuggets of wisdom from
each week's episode and I share them on those channels to give
us some inspiration and to motivate us to get better each
day. And if you'd like to make some
contribution to the show and support the creation of this
podcast, please consider joining as a patron by visiting
technology. No dot f / Patron.
I highly appreciate any kind of support and your contribution
would help me to add sustainably producing this show every week
for today's episode. I am happy to share my
conversation with any Vala. Any is a Technologies with
almost two decades of hands on software, engineering, and
Technology leadership experience CS work in a range of business
domains across four different countries, both remote and
on-site recently. She left her role as
engineering. Manager at message, but in
Amsterdam to return to her home country New Zealand where she
has joined respect as a tech area lead in Oakland.
In this episode, any shared her engineering career dilemma story
on why she resisted getting into management early in her career
for many of us in technology career.
This is a career decision. That is sometimes quite tricky
to navigate. Most of us started our
technology career due to our love.
Solving complex problems, playing around with Technologies
and the novelty of building things that seem to magically
work. Some of us even prefer talking
to the machines rather than humans.
However, at some point in time in our career, there will come a
time when these questions start to arise such as should we start
going into a management role such as being a manager attacked
lead project manager and so on. When should we take the
management role? Should we take it early in our
Career to show our rapid progression.
Any kind of Milestones that I should aim for?
Before I consider taking the management role.
Is there any difference doing a management role at Large Size?
Companies versus the small ones and the list goes on and on and
it becomes even trickier. Since at most of the companies,
the management role is highly associated with more money and
status symbol. Any also highlighted her
observation on the tendency for women to get singled out for
their people skills. And thus get offered the
management roles early in their career.
She shared her thought process on this and related.
It back to her own experience on how to approach it.
The other thing that any also shared with me is her unique
approach to helping others grow in their career and skills
through self-reflection and storytelling, including some of
her favorite self reflection questions, which I find
insightful. And you can also try those when
you have a conversation with your people in your The next one
on once towards the end, any shared her experience at
message. Bird a scale-up company based in
Amsterdam where she led the rapid growth of her team
organically, within a short period of time.
Any also highlighted, the importance of promoting
engineering leaders from within and she shared few stories on
how she did that. When she promoted a few people
in her team to become new managers.
I hope you will enjoy this episode.
And if Like it, please consider helping the show by leaving a
rating review or comment on your podcast app or social media
channels, those reviews and comments are one of the best
ways to get this podcast to reach more listeners.
And hopefully, they can also benefit from the contents in
this podcast. So, let's get this episode
started right after our sponsor message.
Are you looking for a new cool, swag tekhelet Journal.
Now, offers you some swags that you can purchase online.
These Swags are printed on demand based on your preference
and will be delivered safely to you all over the world where
shipping is available. Check out all the cool swags
available by visiting technology, know that deaf /
shop, and don't forget to break yourself.
Once you receive any of those tracks.
Welcome everyone, to another new episode of the technology.
You know, today I have with me, a novella someone who I knew
from France on LinkedIn. So any is currently in New
Zealand, so I got to reach someone from that area, which is
a very good for me, but recently, she actually moves
from Europe. So, any will tell the story
about her later. So any welcome to the show Im.
So excited to have you here with me.
Thank you, Henry. I'm really happy to be here too.
First of all, any maybe if you can introduce yourself telling
the a about you and maybe some highlights on major turning
points in your career. That will be great.
Sure can. All right.
Well, my story starts at a very young age.
I got a Commodore 64 when I was about 5 or 6 years old.
So that's pretty early on my parents bought it for me because
they thought it would be a fun platform for me to play games on
and do puzzles on, but actually, it came with a manual on basic
programming. So that's when I actually
discovered, what programming was at that young age and I found
that just so interesting because it enabled me to make more out
of a device that you could play games on.
I could make it sing songs for me.
I could make it draw a smiley face that bounce around the
screen. And really, at this point.
I was just copying the code. That was in the manual.
I didn't understand what it was really doing but it gave me some
insight and I think that opened up my eyes at that age that
there might be more to this and that I was really interested in
it. I didn't get much of an
opportunity to carry on learning about computers until So I
reached maybe high school, the high school that I was attending
at the time. I actually lived in Mexico for a
few years and the school that I was going to there.
They had a computer science course that I was able to take
for a few months and we started doing some Pascal programming at
that point. So at this stage, I was about 15
years old and I was being introduced to a different
programming language, and I could start learning a bit more
there. Again, my passion for this was
totally reignited. I was so excited about it, and
then my family moved back to New Zealand at that point, so, I
actually had to switch. Schools and the school that I
ended up in for my last two years of high school was here in
New Zealand and it was an all-girls high school.
So they offered something that they called computer studies and
because it had the word computer in it.
I thought, right? That's for me.
I'm going to take that course alongside mathematics and
physics. All the things that really
interested me. Unfortunately, computer studies
was not what I thought it was going to be.
It was actually a course on how to use Microsoft Word to make
things bold. I think the most complex thing
we did was learning how to do some mail merge.
So I Speaking to that, one of the computer studies teachers
and asking them if there was any opportunity for me to learn how
to program and unfortunately, they actually laughed and said
the only way that I'd be able to do that was if I went to one of
the boys schools, I thought, well that's not fair.
I can't do that. So I sort of tried to burn a bit
on the side at home. It was in the late 90s and they
really weren't too many options for self learning at the time.
At least. I didn't seem to find them.
I didn't really know anyone who could help me and that respect.
So, I stuck with the Computer studies throughout those last
two years of high school. And then when I graduated, I
remember one of these teachers asking me what I was going to do
next and I said, well, I'm going to go to university and I'm
going to do computer science. And again, they tried to
dissuade me. They said I would probably be
the only girl in the class and I wouldn't be anywhere near as
good as any of the other guys in the class.
I'd be behind because they'd had a head start.
And, you know, these sorts of comments, I think have stuck
with me as I've progressed from my career because they were kind
of a turning point for me. I think somebody telling me that
I couldn't do Something or that I shouldn't do something.
Just encouraged me to try even harder.
So it certainly didn't put me off.
It just made me want to try harder.
So, yeah, I went and did a Computer Science and Mathematics
degree. I absolutely loved it.
I think it probably was a little harder for me at the beginning
because I really didn't have the same background that a lot of
the other people in the class did.
But it didn't really matter because that's what university
and study is therefore you can come from any background and I
think I proved that you didn't have to come with a set of
knowledge already and skills in that area.
I felt As I progressed through my degree, I learnt more and
more lessons. Not necessarily about the theory
or the fundamentals, but about how to solve problems.
And that if you spend enough time and effort on things
eventually, a problem can be solved and the feeling of
finding that solution was just so satisfying.
So I was really, really glad that I pursued my passion.
So after I graduated from University, I started working as
a software engineer here in New Zealand.
I was lucky enough to end up working at I think at the time,
it was probably New Zealand's busiest website.
Old Trade, Me, New Zealand. Never really had eBay here.
So trade me was like eBay, but just for New Zealand and it was
such a busy website like so much traffic and so super well-known.
So I was lucky enough to work on something that so many people
knew about and when I released a change or a new feature or bug
fix, I knew that thousands, millions of people were using it
and that just continued to make me feel, like, I'd made the
right choice. I remember thinking that I just
wanted to stick with it. I wanted to make sure that I
kept refining my own skills that I put myself.
Into situations that made me learn more because I really
believe that by doing you learn more than just by reading about
it or listening. So I tried to work on big
projects. I tried to work alongside other
Engineers, so I had a lot of respect for eventually.
I decided that I needed to try doing the overseas experience
thing. As many new zealanders.
Do. I went overseas, I ended up in
Australia for just over a year and then the UK for a couple of
years and then ultimately Amsterdam, which is where I was
recently. I've worked it, I think ten.
Aunt companies I've been a contractor.
I've worked at a lot of startups.
It means that I've had a very varied experience as a software
engineer so far. Throughout that time.
I felt like I learned so much and I really wanted to stick
with the tools. So I stuck with being an
individual contributor for as long as I could just to keep
gaining those skills. It was actually fairly early on,
in my career. It was only a few years out of
University that I was already being offered roles in
management, because I guess there was a perception that I
had some good. People skills.
Some good soft skills, but at the time I thought this is way
too early, you know, I can't move into leading other people
yet because I don't know enough myself.
I need to keep learning and the best way to do that is to keep
being an individual contributor. So I really resisted moving into
management. I ended up resisting for about
10 years. So I finally ended up moving
into management role about seven or eight years ago.
Now, it's been quite a number of years that I've been leading
teams and other engineers. And I think, now I finally
recognize just how important it endures and how much there is to
be gained from helping other people learn as well.
So, I'm glad I made the shift but I'm also glad that I waited,
as long as I did. So I think this story, many
people could relate as well, especially as more and more
technology opportunities and roles for people around here,
especially with the booming, of these startups or
technology-driven companies. So many people are thinking
about, should I stay as an individual contributor?
Or should I go into management, which is perceived as more Full
in the corporate world normally, so if you can share a little bit
more about your thought process, why you resist it for like 10
years before you actually made that move to become a manager.
So why was it important for you to delay for such a long time?
Sure. So what's really interesting is
when I started off as a software engineer, I don't think there
was a very clear career path for software engineers and maybe
there still isn't but I do feel like it's getting better.
I used to look at other Industries like say maybe you
went into Counting. I think there's a very clear
career path for accountants. There's certain Milestones you
need to hit. Maybe there are some exams, you
need to sit. Then you get a certification and
then you can sort of be promoted to the next level as a software
engineer. It felt like there was sort of
Junior media senior and then what maybe you might move into
architecture or you move into people management, but what sort
of Milestones that you need to hit in order to reach those next
levels, so it wasn't very clear to me at all.
And I think there is a big difference between being an
individual contributor as an engineer and A leader or
manager, the sorts of things that you'll be doing day to day
are entirely different. I do think that as you said like
at least in the corporate world moving into management is
perceived as being more impactful.
But seen as a promotion it's seen as you get a pay rise out
of it, more responsibility and it is all of those things but
it's not the only Avenue to get more of that in your life.
What I urge other people to think about is what does their
Passion live? What brings them energy for some
tasks that you'll do might take Energy away from you, and you
need to look for something that gives you energy.
And if for the time being writing code, solving problems,
delivering solutions to customers.
If that's what gives you energy stick with that, for the time
being. It doesn't mean that.
That's what you're going to have to do for the rest of your life.
We have fairly long careers. These days, I reckon, most of us
will probably have a 45 to 50 year long career, unless you're
lucky enough to retire earlier. So, you know, that there's
plenty of time to change your mind later on about what you're
going to spend most of your day doing.
There are some people who might decide that they are definitely
cut out to being a people manager earlier, on in their
career, but they probably have that sense quite early on in
their career and they can make that choice.
But for the most part, I think, if you've chosen to go into
software engineering, it's because you have a passion for
solving problems. It's been described to me, and I
totally agree with this. It's like being paid to solve
puzzles every day. Who can argue with that being
fun for those of us who enjoy solving puzzles being paid to
solve. Puzzles, day-to-day is
fantastic. So, if that's what you enjoy
doing, Stick with it because there are other avenues to be
promoted in a more technical career path.
You can keep going on through, it doesn't have to be like an
architectural, it can be more of a principal or a staff engineer,
you know, you do grow and there's so many different ways
that you can grow continue down that path until you feel like
you might have more impact in your more interested in looking
for ways to solve problems that involve team structures or
project processes or identifying, what skills are
missing within a team and how To help other Engineers grow within
the areas that they're interested in or have more
impact. These are the sorts of things
that you'll be solving. It's still a puzzle that needs
solving, but it's entirely different to reading lines of
code looking for memory leaks, the siding which technology
stack to use. So, for me, personally, I really
loved solving those technical problems.
I'd wanted to do it since I was six years old and it just made
sense for me to stick with it. For as long as I did.
I believe that if I moved into management too early, I would go
Rusty on those things. I suffered from a Bit of
imposter syndrome, you know, I think a lot of us do and I
always thought I wasn't good enough.
And maybe everybody else around me was better at solving
problems. And I was, you know, practice
makes perfect. Right?
So, if I continue to practice and put myself into new and
different situations, I would keep learning but if I moved
into management, I would be practicing at different things.
And how could I possibly lead a team of really smart Engineers?
When I couldn't do those things myself?
I think it's important that you have enough skills that your
team. See you in the same way that you
respect them. I believe you need to be someone
who they can trust to help them get out of trouble when they
face a situation. They haven't faced before.
Maybe you can have some stories to tell that guide them in the
right direction. It's not about solving the
problems for them, but perhaps just being that safety net.
So I do think that I made the right choice for me to stick
with what I was doing as an individual contributor, as long
as I did. I think it was very baffling to
people around me because these sorts of conversations about
moving into management. Came with the additional
responsibilities and the pay Rises and the opportunities to
grow, but it was growing in a direction that I wasn't
interested in at the time. And to be honest.
I felt a little pressure to go in that direction, but I'm glad
that I didn't fall into that trap for myself.
I think I'm better off for it. I hope I'm a better leader for
it. So I pick up a key point when
you sharing your short story. Just now you mentioned about
Milestones which probably in the pack career is not so clear, not
so evident and especially just now you mentioned The
progression of someone as an individual contributor.
What kind of impact they can bring?
So, if you can probably summarize for people here, who
would like to be an individual contributor?
That is gradually growing being prepared for management role.
What do you think at the stages in between, you know, the kind
of Milestones that people should be looking at, at least, have a
rough idea, because it's so unclear for people in the tech.
I see that a lot of times people get chosen into a more senior
and management role just by chance by luck, or by being
Tiered and things like that. So not necessarily is have
something well as a store, good attributes that you can say.
Okay, I think all these boxes. I'm ready for manager.
So, maybe you can share a little bit on that.
Sure. So actually more recently.
I've come across something called the Dreyfus model, which
I think is probably a good place to start what The Dreyfuss model
talks about is it's a skills acquisition framework and what
it describes is the progression more to do with the behaviors
and attitude that you have when you From novice up to an expert
level actually what the drivers model says, and I feel like I'm
kind of evidence of this is that it takes about 10 years to
really become an expert in a given skill that skill can be,
you know, it doesn't have to be software engineering as a whole.
It could be a specific language or specific technology or it
could actually be something totally different, like learning
how to play an instrument or cook or something like that when
you're a novice. So this would be a junior
engineer, you know, when you start off as a junior engineer,
you probably work within certain.
Sort of framework. A set of rules and guidelines.
You're probably being given tasks and your focus should be
and generally is to pick a task off the board and do it as
quickly as you can. If you want to prove to yourself
and everyone around you that you're able to solve that
problem. You're probably pretty Keen to
get on to the next one. You might make some mistakes
because you may even be rushing a little bit just to get through
the work quite quickly, but you're working within a specific
set of guidelines that are set out from people around you.
I reckon that as you start to To grow and it really is like those
Milestones are very gradual as you begin to become more
experienced and grow those skills.
You rely on those roles less than this, you might start to
discover that. There are some rules that don't
apply in certain situations where they did apply somewhere
else. You start to question things
more. Perhaps you want a little bit
more context around why the work needs to be done, or why it's
being done in this way or why now, as opposed to later that
sort of scope starts to grow. So, instead of being more
focused. Focused on a narrow area, you
start to ask around, you know, maybe what other teams are
working on or what the business case for this is.
So your Viewpoint becomes a bit more holistic.
I think, as you develop those skills in the more experiences
you have you start to gain a sense of intuition around the
right things to apply to certain situations, you recognize that
the rules. Don't apply in every situation.
So everything's becoming more situational and you become more
context aware. It's not an exam that you're
going to sit. It can tell you that you are now
at Media or senior level. It's more around.
How you behave. And why are you behaving in
those ways? And it's very gradual.
I think this is why I encourage a lot of self-reflection.
When engineers in my team's talk to me about wanting to be
promoted. I try to discuss with them that
perhaps they shouldn't be aiming at having a promotion but
instead, they should be reflecting upon their own
behaviors and do, they feel like they are now acting more from a
sense of intuition? And do they want the bigger
picture? Are they able?
To take on that bigger picture because at a more novice level.
The bigger picture is probably too confusing and you don't need
it. You shouldn't have it.
It's too much information might overwhelm you.
So it is quite a natural progression.
I would say you do actually need to practice the hard tasks over
this period of time up to 10 years.
You also need to put yourself in two very different situations.
Because if you do the same thing over and over for 10 years,
you're probably not going to grow those skills and develop
these aptitudes either. Another thing is communication
skills, you know. I was in high school.
I wanted to do all the Sciences. I really wasn't very interested
in studying English or history or anything.
That required, those other sorts of skills.
But I remember my father, insisting that, I take English
as a subject because he said, you can be the smartest computer
scientists out there any. But if you cannot communicate
that to other people, it won't mean anything.
This was so many years ago and I still think about it all the
time because being able to communicate with people with the
right sort of words or the right level that they need to be
communicated with is so important.
And that's something that you gain skills.
What you might have as a more Junior engineer, you might have
thought these were irrelevant things that you didn't need to
know about these. You just need to develop you
need to be better at writing, SQL queries, or you need to know
the latest framework or how to debug this complex situation.
You do need to know those things, but then there's a whole
lot more beyond that as well. I guess that's my store in this
domain, right in my previous episodes, as well.
I learned that many technical leaders are kind of like being
thrown into the roles. They are not well prepared.
So that's when they Come the manager.
They didn't actually perform. Well, the team are suffering.
And also the other day, I was having a conversation as well.
That the technical leadership is actually is in a crisis mode now
because as more and more people going to the technical roles,
not necessarily everyone make a good cut as a good manager.
So have you ever seen in your 10 years experience as an icy as
you more and more progress as small senior?
Have you had a manager who actually didn't perform on that
level and what kind of impact that would bring?
NG to an experience. I see like you is there.
Such a story from your experience.
I do actually and funnily enough.
That's how I became a team lead. It's a story of me moving into a
team lead position. So it was one of the roles I had
in Amsterdam. The team that I joined was the
backend team for a relatively small company.
They're the team lead of that team.
He had been the most senior I see on the team and he was
promoted into this position because where else was he going
to move to? So, you know, it was one of
those. Situations where he probably
wasn't well, prepared for running a team.
He had excellent technical skills, but I think he needed to
work on his people skills a bit, his management skills.
I don't think he'd had any training in this area.
So what I found was he could solve technical problems, but
what he wasn't doing very much was sort of bringing the team
together, coordinating the sort of impactful work that each
engineer could be doing to help themselves to help the company
to help other teams. So, what I found was the team
was Generally not very busy. Surprisingly for a small team.
There wasn't that much for us to work on and there were periods
of time when I felt like everybody was just sitting
around not doing much work at all.
And I thought, hang on a second. I know that there's a lot of
work to be done because at this point, I was eight years into my
career. I was seeing the pain that the
support team were going through because they didn't have the
right tooling to help our customers.
We had error logs that filled up every day with recurring
problems that looked like they Probably fairly simple to fix if
only, somebody would care to look at them.
And so, that's where, while my manager was very busy with many
other meetings. He was barely ever around.
I started asking other Engineers.
Hey, are you working on anything at the moment?
If you're not busy, do you think maybe you could take a look at
this particular bug? It looks like this era happens
every night at 2 a.m. It's probably some sort of
process. Maybe you could take a look and
people reacted really well to that because it gave them some
Direction. People were getting a little
bored at work, which might sound surprising.
Rising but, you know, being bored at work shouldn't be a
thing, right? So when people got the sort of
direction from me, they would go.
Yeah, sure. I'll take a look and then they'd
solve the problem and then they feel pretty good about
themselves because they solve the problem.
They've got an effects out to production.
I just kept doing this. And in that sense.
I was kind of leading the team without having the title.
And I think it was because I had a manager who hadn't had that
sort of training. He probably didn't even have
that much of an interest in running a team yet to that end.
We almost swapped positions. I became the team leader of the
Team and he took on an architect role for a different team.
And I think he ended up being able to move back into something
that he really enjoyed doing, which is being Hands-On again,
as an individual contributor at a very high level.
Because he did have all those really excellent technical
skills and it created a space for me to move into the
leadership role that I had resisted for so long, but as it
turns out I was doing anyways, right?
Right, right. So he's also an accidental kind
of story for you. Picking up this management
skills, right, right. Yeah.
So any before our conversation today, we exchanged messages.
You have one particular probably observation about women being
offered management role earlier in their career.
Maybe you can share a little bit more your observation and what
you think your message for the women out there listening to
this episode as well. Sure.
So over the past few years. I unfortunately have not worked
with that many women and it, perhaps if you think about what
I said at the beginning of this conversation, it wasn't.
Charged at school and then they just weren't that many women
doing computer science at University either and it starts
very early on. There's not much of a supply of
women going into this industry. I have worked with a few women
and I've been in a few women groups and women and it groups
throughout my career. What I've learned is that a lot
of women, they have a desire to get into software engineering,
they do the degree, and then they start working and very
quickly, they seem to be singled out for their people skills.
I think there is a perception that women have really good soft
skills just naturally and that we are able to maybe rally the
troops. We're willing to take on tasks
that require sort of coordinating, the team talking
to team members. Maybe we show a bit more
empathy. That's not at all to say that
men are not capable of doing this or that, they're not good
at doing this. But there does seem to be a
perception that women are particularly good at this.
I have recently spoken to, I can think of three women, which is
probably the total sum of women that I've spoken to and I teeth
without the hospital. While who all had the same story
that very early on maybe a year or two out of University.
They were already being offered team lead positions in all three
cases. They saw it as an opportunity
for promotion and they took that role and now 10 15 years down
the line, when they look back on it.
They all said to me, that they kind of wished that they hadn't
because it meant that they didn't get to practice their
skills very much. They moved up through those
ranks very quickly. They did go into Computer
programming because they loved solving the puzzles so much, but
they never got much of an opportunity to actually do that
in a couple of instances. They even said, Gee.
I wish I'd had a manager, like you who might have talked me out
of that at the time and reminded me why I became a software
engineer in the first place. So, my advice to women, who are
listening to this podcast, who are in this situation, would be
not to rush into it, just because it is offered to you.
It doesn't mean you have to take it, that opportunity will be
there for you. They On.
If it's something that you absolutely know you want to do
by all means do it and hopefully your manager can support you
through that. But if you are loving solving
the problems right now, learning new skills, working on more
complex systems distributed systems.
Then stick with that for now because you know, what, moving
into management is not that hard but moving back into being as an
icy from management. I think that's a little harder.
I've had a little bit of experience in this, after two
years of being a manager, I actually, Went back into a role
where I was an individual contributor.
At least part of my role was writing code again, and I was
pretty Rusty, you know, because I hadn't really kept up those
skills because there's so much to learn about being a manager
that you end up spending more of your time, learning how to do
effective one-on-ones, how to do performance reviews, how to help
build career progression Frameworks this, our whole host
of things that you need to learn about technical leadership that
you don't have enough time in the day to also continue to code
as well, and immerse yourself in those really truly complex
problems. That will teach you more so it's
certainly doable but it's harder to come back into an individual
contributor role. I reckoned just do what you
think is best for you, but don't feel pressured that just because
you're being offered a role in management.
You don't have to take it right now and maybe take it at a later
stage when you're ready to take that next step which is a
fundamental change. I think so, I guess that's my
advice. I was kind of like interested
when you're sharing this story about manager, having to support
the upcoming manager and you yourself.
I mean, like, look, Looking at your history in your career,
right? Many people actually said that
you have a particularly unique way of growing people.
So the keywords that they're mentioned, most of the times
it's like you're growing them to do more self-reflection and by
telling your story, so maybe you can teach us your unique
approach here. Why do you have this kind of a
unique angle on how you grow, people, true self reflection and
storytelling? Sure.
Let's see. When I first became a leader, a
manager of an engineering team and I started doing one.
Ones I was told one-on-ones is something that I had to do.
So, all right, let's get onto that.
I noticed that most people didn't really want to talk about
work. They wanted to talk about what
was going on in their life and it made me realize that
everybody's different. Everybody has their own
background. They've got their own stuff
going on. They've got their lives to lead.
Some people have very complicated situations when
you're in that space, you know, you bring this with you to work.
So perhaps, you look at somebody and you thinking gee, they're
not performing as well as I thought they might in this role.
Ole but it's may not be anything to do with the lack of skill.
It might be more to do with how the rest of their life is
evolving at this particular point in time, so I thought it's
very important to take a step back and look at a person's
situation in a more holistic way through that.
I came to realize that there was so much more to Growing other
Engineers than just teaching them raw skills.
That the end of the day, there's plenty of material out there.
If you want to learn how to set up a redis case, you can find a
tutorial on that. I don't need to You myself,
you'll probably figure it out yourself.
And to be honest. It's probably best if you figure
it out yourself and to be shown by me.
I think it's important as Leaders to be humble and to be
bold to share your own failures and to share your struggles and
challenges. If other people can see that
you've gotten to where you are in your career, and still,
you've also faced a bunch of difficulties throughout your
career. I for one, I don't like public
speaking. You know, I think it's really
scary to get up in front of a bunch of people and talk about a
subject that. That I feel like maybe everybody
else in the room knows more about than I do.
However, I've done it and when I've done it, I've had a great
time. And when you actually stop and
think about it, then those people are in the room wanting
to listen to you because perhaps you'd know more about it than
you, give yourself credit for and it's about taking a deep
breath and just calmly speaking about this thing that you do
know a lot about if I tell stories like that to other
people who are sharing with me, their fears about something
something that's may be preventing them from growing.
Then they Might have another think about it and they might
find some courage to go and try that themselves in other
situations. I can give some insight into how
complex a particular type of project was.
For me. I found that almost every single
job I've had has required some kind of data migration data.
Migrations can be pretty complicated and often need to be
done in many steps. When you describe something like
that to a team. It might give them some more
ideas on how they can approach it or why it's important to put
something in place today. That might help.
Help them later on. So I try very hard not to solve
the problem myself anymore. Even as a leader in engineering,
for some time. I felt like I needed to be able
to solve all the problems. But I've gradually come to
understand. I don't need to know how to
solve all the problems, but I do need to act as a safety net.
I need to ask the right questions at the right time.
Tell some stories that might help Inspire someone else to
think about something slightly differently.
I do seem to have had some success with this.
And I absolutely love hearing from Engineers that I've Worked
closely with that. I've had a positive impact on
their life. I've made them think about
something in a way that they just hadn't yet.
And now they're sort of equipped with a tool that maybe they
didn't have before to just question things.
I think it's so important to question things ask, why I
really try to drive a curiosity mindset within engineering
teams. We can get bogged down with the
day-to-day. There's always a fire to put out
or a new project that needs to be launched when an issue arises
or you know, there's an incident or something, don't just Fix it
and move on because then you won't have learnt anything from
them if you stop and think. But why did that happen?
There will be a reason computers not magic.
We make them do what they do, right?
So, yeah, the people as Engineers who have that control.
We just need to remember that. We are in control of the machine
and we do need to just question. Why?
And when we go down that path will probably find something
really insightful that will help us on our next problem.
So yeah, these are the sorts of tools that I use to lead teams
and Inspire engineers. Do what we hired them to do in
the first place, you know, be the best engineer that they can
be. So on the self-reflection part.
Do you have some kind of common questions because you emphasize
a lot about asking why asking the good question.
So this is for people like software Engineers or any
technical roles out there as individual contributor.
Are there common self-reflection questions that you would
probably want to share with us for us to think about and Ponder
ourselves. Yeah.
So when I first joined a team in that first one-on-one that Ty
schedule was people. I actually have a set of
questions that I asked straight away.
The first one being, how did you become a software engineer?
Tell me your story. And I think that's a really
interesting question to start with, because it helps people
start to rewind back to when they decided that they wanted to
become a software engineer. The Myriad of ways that people
end up becoming a software engineer is just fascinating.
But it also tells me a wee bit about what motivated them to
become a software engineer, and the path that they've taken to
where they are today. And So I start with a other
questions that I asked, in that first one-on-one that help guide
questions later on in my journey with them are things like what
do you think is working really well, in our team today?
And what do you think could be improved and what are you love
the best about your job? And what do you not like so much
about your job? The purpose of these questions
is not to then allow this person to only ever work on the things
that they like doing and avoid all the things that they don't
like doing. But I'm looking for some common
threads about about in efficiencies or frustrations
within the team, you know, nobody likes to come to work and
be frustrated. I think if you start to sense
that there's a lot of frustration within the team,
then you need to investigate that a bit deeper and try and
solve those things as Engineers. I think we do have a lot of
frustrations when our pipelines are too slow or there are some
unit tests that just randomly fail.
Gosh, is so many sorts of things like this, that you don't have
the access to the right technologies that you want to
use and that makes your job a lot harder.
And so I tend to ask people. What are you Find really
frustrating. And what are you spending time
on that? You wish you didn't have to
spend time on? And what's really interesting is
when I ask that question, most people they don't have an answer
for me, straight away. And that's okay.
They don't need to have an answer straight away.
What I want to do is encourage them to think about it.
So I say, let's chat about it in our next one-on-one, and
whenever you get a little bit frustrated between now and then,
just make a note of it. So we can talk about it next
time and slowly, but surely I start getting these really
interesting comments around a lack of process around.
Something or that Engineers are not invited to participate in
the design phase of a project, early enough pipelines being too
slow or unreliable and that then leads on, to me saying, all
right, there's a perfectly valid in sight.
So what are you going to do about it?
So, how can we make a change here?
How can we reduce that frustration?
Because you're probably not the only one feeling this and then I
encourage that person to maybe go and speak to other people
about it and go and do some research about how they Prove
this or why is it that this thing in particular frustrates
you, I guess, in that way. I'm really trying to get people
to think deeper than just. The obvious thing is for people
to say, to me. What skills do I need to learn
to become a better software engineer, and I don't have a
perfect answer for you there you and I could maybe suggest some
particular technologies that are very popular in the market right
now that maybe we use, maybe we might use in the future, but
that's probably not as impactful as getting you to a phrase.
I use has to be the supplied to the unmet demand.
And there are generally a bunch of unmet Demands within an
organization. Perhaps even within your own
team, things that you can make a huge difference on if only, you
just go and do it. You don't need to seek
permission. If there's time, just go and do
it and you'll make someone's life so much easier, they'll be
grateful for it, and they'll thank you for it.
And you'll have had some impact and created a positive
experience with somebody. And that's how you end up
growing and being noticed eventually, hopefully getting
promoted for it. So there's a virtuous cycle to
be had from Just asking questions and making people
reflect on what makes them happy.
What drains them, what frustrates them, where they get
their energy. I think that sums it up, right.
I really, really love that. In particular the phrase be the
supply to the unmet demand and I think I can relate to this.
A lot of times as well, many people actually took
frustrations for granted. For example, like we mentioning,
you know, the pipeline is the okay.
Maybe it is slow. There's nothing that we can do
about it. It's just slow or the test of
breaking. It it just breaks from the Time
to time, there's nothing we can do about it.
So I think he actually sees good mindset to always think.
Okay. Why is this happening?
Is there anything that we can always improve and make it more
effective, more efficient and maybe also have a group guy
drinks brainstorming, how to improve on things that they
don't like as a team. So I really, really love that.
So any you also work in the message but before coming back
to New Zealand, so from there, I think it's also a great story
where you had a chance to lead a team that grows organically
within less than a year. You can tell a story about your
experience, your journey and message, but what did you learn
from there? So message, but unfortunately, I
only spent a year at message burden is just under a year
because I came back to New Zealand really to be closer to
my family and these days of Corona in that time.
It mrs. Bird though.
Wow message Bob moved really fast.
They are very very high Growth Company very fast-paced and in
more ways than one. So for example, they're growing
really quickly is and they're hiring many people and any given
month. If there were 10 Engineers
starting and sometimes I might not even have known that an
engineer was starting in my team until the day before.
So, we had to be very adaptable, very flexible, and ready to take
on whatever challenge, may present itself.
In the next day, on the other hand.
They were also growing incredibly rapidly in terms of
the number of customers and the usage of the services that we
were building. So, particularly in my team, I
started off as an engineering manager for One Tribe.
The conversations tribe, which when I joined was only about six
people. And over those 11 to 12 months
that team grew to about 12 people.
And then I took over another tribe as well, the dashboard
tribe. So overall I ended up being
responsible for about 25 people, which was a lot more than when I
started, right? So that in itself was a big
change for me. It was also something that
allowed me and my colleagues to help grow some other Engineers
into leaders, because there was no way that I could personally
support and Lead 25 individual. Computers.
That wouldn't be fair on them and I just wouldn't be able to
do it. I was very lucky to have three
different individual contributors who were not only
very senior in their own skills and their Technologies, they
were working with, but very interested in moving into a
management role. And I think that's really
important. We've spoken about being given
the opportunity to move into a management role.
It's not about throwing someone into a management role who
doesn't have an interest in it. And this case, I was lucky
enough that there were people within the teams who Shown an
interest in, they wanted to have more context about what kind of
work we were doing. They wanted to have more input
into the sort of work. We were taking on, or the order
in which things are being done. They wanted to help other
Engineers grow, which they were actually already doing.
And I saw a lot of how I had moved into Management in them.
And so it was just coincidental that we needed people in these
roles and I was able to help them move into these team lead
roles. The really interesting thing for
me was Was that they were very different individuals.
One of these guys was incredibly technical like a systems
thinker. Very process-driven and that
worked perfectly with the people that he ultimately was
responsible for leading. And the sorts of projects He was
working on another engineer who was incredibly empathetic,
always wanting to help people. Just the kind of Soul.
You'll have ever met with his technical background combined,
with that desire to help those around him.
He also made an incredible leader who Manage to steam in a
very different way to the other person.
This just goes to show that everybody has their own style
and we certainly don't want to go for a one-size-fits-all
solution when it comes to leadership.
Everybody. Does it in their own way?
Then this case it just worked incredibly well and I saw them
both gaining skills and leadership in such different
ways. The ways that work for them.
The sorts of lessons that that taught me was it made me reflect
back on how I had become a manager and the sorts of
Questions, I had, you know, I remember thinking so where's the
list of tasks that I must do? They had a day when I'm a leader
and my manager at the time saying, well, there's no this,
you know, it just gonna have to figure it out on your own.
I remember when speaking to these new leads.
They sensed that their performance would now be
determined in different ways. So, how can they still be seen
to be doing a great job? If it's not writing code all day
long, they're not being judged on how great their coders and
the mindset there is that's Because as a team lead at
message, but you're still writing code for 50% of the
time, but the other half is you're being judged more on how
your team is performing and how the engineers that you're
responsible for our growing and their satisfaction and how
they're performing. So it is a mind shift and if you
have a little bit of imposter syndrome, then that's doubled at
that moment in time because you're completely new to this
type of role. I remember talking to them about
how to do one-on-ones, how to conduct performance reviews, how
to give A feedback I think feedback is something that's
very difficult to get, right. It's so important.
But yet I remember reading something that said you need to
have had about five positive interactions with somebody
before. You can rightfully give them
feedback that they won't react in a defensive way too.
If you try and give someone feedback before, you've had
enough positive interactions with them, they'll probably just
put their fences up and not want to listen to it.
And they, my are you with it. It's not the purpose of giving
feedback, right? So, The sharing these sorts of
little insights that I've read, or I've sort of felt myself with
them to try and prepare them best for the sorts of
situations. They may now be faced with which
will probably be different to those that I've faced, but just
trying to build their little toolkit as much as I could.
I think the other thing that I would encourage other
engineering leads, when you're in that situation is talk to
your peers. It's not just about forming
relationships with your team. The people that you're now
leading. It's also about forming
relationships with other people that you're or level and the
people that you report to yourself.
It's all about relationship forming, because ultimately,
you're going to need to have some difficult conversations.
You need to be able to negotiate.
So the more relationships, you build with these people, find
reasons to speak to them about something and collaborate on
something else. These are the sorts of skills
that you need to start building out more and more.
But that's what makes a team lead role quite difficult
because you do need to still keep your hands on the keyboard,
and you need to be able to solve those technical problems as well
together with your Those are some of the lessons that I
definitely had the opportunity to learn at message bird.
I think I also learnt that it's really important to bake a
little bit of technical excellence and to all the work
you do. Because when you're a startup or
a scale up the tendency is to move really fast and deliver
software, incredibly fast, but inevitably you end up taking
some shortcuts which over a longer duration of time can end
up piling up and you know, technical debt exists
everywhere, but at some point I think you'll start That to feel
like the majority of the time that you spend is spent
reviewing old work that now needs to be upgraded or fixed or
migrated away from and then you're not able to deliver new
features as quickly as you might have been otherwise able to so
it's a balance. It's definitely a balance and
that's something else that I think I learned that message
bird is finding that right balance with the team.
Yeah. It was a really exciting place
to work with fabulous. People like so many intelligent
very kind people to work alongside.
It was a great experience. I like the story where you
actually promote leaders within your team.
And I think it's probably one of the responsibilities as well as
a leader as an engineering leader to actually probably find
talents within your team who can actually grow and assume this
role rather than pick the people and throw them into this new
role. So growing the people within
your team to become leaders. Right at the is also Worth to
share for other engineering leaders who are listening to
this episode. So how do you actually first
spot, the talents within the team?
Team who may make a good card to be a good technical leaders.
And then how long do you think should they take before?
They actually assume the role? Or is it more like opportunistic
basis where you see probably when the team grows unit more
technical leaders in the team that you promote them or is
there more like a progression? Well, I think this comes back to
having that close relationship with your team members learning
more about them as people and what drives them.
So in my interactions with all the engineers that I was
leading, they were Engineers that when I spoke to them, it
was clear that their passion, lay in solving the technical
problems. They would describe their role
as hey. I'm being paid to solve puzzles
everyday. I love my job.
That person probably wasn't super interested in spending
more of their time managing other people, but in those
interactions that I had with my team's, there were these
particular Engineers who would talk to me about wanting to
solve some of the other sorts of problems that we've discussed
more around, how to refine a process on how to How to create
an MVP, what's the process that we should be using to determine
and build out an MVP? I had one engineer, one of these
two leaders that are mentioned before he was very interested in
how to improve and develop a culture.
And these are not problems that a engineer who wants to remain
as an individual contributor thinks about right?
So it's through those sorts of conversations that I started
getting a real feel, before we even discuss the opportunity of
maybe moving into that sort of role.
I think this person might be interested in this.
Type of role and when as an organization, we saw the need to
have leads in these teams, but for me, it was a no-brainer.
I have people who I think would be great in these sorts of
roles, but they are actually interested in it.
And so then I had discussions with my manager, within the HR
department and then I went back and spoke to these particular
engineers and proposed the idea to them of.
How would they feel about such a change?
I also think it's important to pose this question, as kind of
an experiment. Maybe it doesn't work out, and
that has to be okay. A as well, maybe they give it a
go and they realized that it's not for them.
All they wanted to do was to see if it was something that they
could try out. So maybe before officially
changing their title, they can go through a period of time
where you give them some more responsibilities.
Maybe not yet managing people but maybe more mentoring other
Engineers, maybe helping them may be leading bigger projects
projects that require cross team collaboration.
And these are all going to start exercising, the sorts of skills
that they're going to need as a leader before they are.
Officially become somebody's manager and that gives them.
Maybe some insight into the sorts of day-to-day tasks that
they will be doing and whether it's really what they think they
should be doing at this point in their careers.
I agree with you. I think is so important to try
and promote within you hire. Excellent engineers.
And then if you don't give them opportunities to grow, they'll
go somewhere else. So you want to retain them.
And in order to do that, you have to carve out a path for
them to take and some cases that might be more towards people
leadership and other cases it might be more.
Odds, principal staff engineer levels, but I do think it's very
important to look forward and forecasts.
Where could this person be in 125 years if they stayed with
us? Will there be a position for
them to move towards and have more responsibility?
More impact. Thanks.
Anyway, for sharing your story. It's been a great conversation.
I learn a lot like when to actually, I took a management
role and some of the guiding principles you have around all
these including self-reflection, the importance of
self-reflection finding opportunity to improve.
In efficiencies and things like that.
So before we end the conversation, I normally would
ask this question to share about three technical leadership
wisdom for the listeners out there.
So any would you be able to share yours?
Yes, sure. I think the first one and
probably for me the most important one, very much along
the lines of what we've just spoken about.
It's so important to empower and enable your engineers.
And by this. I mean make sure that they're
involved early and projects. Ask them about how they believe
things could be done better. Ask them about how to improve in
efficiencies lead them by asking questions.
Don't tell them how to do things as a leader in technology,
whether you're a people leader or you're just a very senior
individual contributor, Your Role shouldn't be to solve the
problem for them. It should be the guide them to
solving it themselves because that's how you grow Future
Leaders. In this sense.
I think I would encourage technology leaders to act more
like coaches than managers. And it does require building a
lot of trust. So that would be Number one.
My second point is around ensuring that everybody on the
team has a sense of ownership over something that the team is
responsible for. So something that I've come up
with a over the last few years. I call it the component
ownership matrix. It's actually the result of a
bit of an exercise that I do with a team where we get
together as a team and we list out all of the components that
the team is responsible. For those components might be as
large as a service or as granular as a particular
component. That's may be very complex.
Within a service or an application, you list all of
those out and then you assign how level of criticality to that
particular component. If it's incredibly, highly
critical or maybe if it breaks nobody really notices and it
doesn't really matter that much your Sinai level there.
And then you assign an owner and a backup.
So the purpose of doing this is not at all to say, the owner is
the only person who can never work on this piece of software
there. The owner and nobody else must
touch it. It's more to ensure that
everybody in the team feels responsible for something.
They can treat it like their little baby.
They get to look out for it and make sure that if there's a new
project happening, will it impact their component?
Should they be considering how it will impact their component?
They should be keeping an eye on the error logs.
They should be, maybe keeping the libraries and dependencies
upgraded. I think that's really helpful
because it means that even when a new engineer starts on the
team, they feel like they're now a part of the team.
They're responsible for something.
It also helps prevent situations where there might be some very
senior Engineers. We've been in the team for a
long time being Responsible for most things, whereas the rest of
the team are just there to help and aren't particularly
responsible for anything. So it helps distribute that
around and of course, the backup is just somebody to be
nominated. In case the owner is away on
holiday or whatever, the case may be.
So assigning responsibility and ownership over certain elements
of what a team is responsible for.
I think that really helps a team and individuals grow.
And the last one is I think we discussed this as well as to try
and bake a little bit of extra quality into every piece of That
your team does. It's almost impossible to go
back and retrofit thousands of unit tests or integration tests
in an application that has none. Nobody wants to do that.
It's not practical. There's not enough time to do
something like that. It would almost be so difficult
to try and unwind. What a piece of code was
supposed to do. If it's going to take an extra
hour or two, just do it while you're there, you know, if you
just do a little refactoring or a little bit of extra testing
while you're there, it will just help its cumulative over time.
You'll end up with a much more stable solution that you don't
have to carve out a six-month project to go back and retrofit
some sort of quality into this particular application.
You just got it done as you went along.
I think that can really help stabilize and make systems more
resilient moving forward. I like to refer to this as not
borrowing from your future self. So yeah, I mean like a lot of
people tendency will be just rewrite it right?
I think I like the way you pray sit, like, bake it a little bit
one at a time gradually and cumulatively you will improve
the system. Anyway.
Again, any for spending your time, for people who want to
find you online? Is there a good place for them
to do? So mostly on LinkedIn at this
particular point in time? Okay.
I'll make sure to put that in the show notes.
So, thanks again. Any hope you have a good day
today. Thank you so much Henry.
It's been a pleasure. Thank you for listening to this
episode and for staying right till the end.
If you highly enjoyed, please share it with your friends and
colleagues who you think would also benefit from listening to
this episode. And if you're new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It really, really helps me a lot
in order to grow these podcasts better.
You can also find the full show notes of this conversation on
the episode page at technology, know that death website.
Putting the full transcript interesting quotes and links to
the resources and mentions from the conversation.
And lastly make sure to subscribe to the show's mailing
list on technology on all the deaf to get notified for any
future episodes. Stay tuned for the next
technique Journal episode. And until then.
Goodbye.