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.