#30 - The Engineering Career Dilemma & Growing Through Self-Reflection - Annie Vella

Episode Introduction [00:00:58]

Henry Suryawirawan: [00:00:58] Hello, everyone. Welcome to another new episode of the Tech Lead 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’re new to the podcast, know that Tech Lead Journal is available on major podcast apps, such as Spotify, Apple Podcasts, Google Podcasts, YouTube, and many more. Please subscribe to the podcast to get notified for any new episode that I release every week. Also check out and follow Tech Lead Journal social media channels on LinkedIn, Twitter, and Instagram. Every day, 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 techleadjournal.dev/patron. I highly appreciate any kind of support and your contribution would help me towards sustainably producing this show every week.

For today’s episode, I am happy to share my conversation with Annie Vella. Annie is a technologist with almost two decades of hands-on software engineering and technology leadership experience. She has worked in a range of business domains across four different countries, both remote and onsite. Recently, she left her role as Engineering Manager at MessageBird in Amsterdam to return to her home country, New Zealand, where she has joined Westpac as a Tech Area Lead in Auckland.

In this episode, Annie 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 in 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, a tech 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. Annie 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 Annie 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 next one-on-ones.

Towards the end, Annie shared her experience at MessageBird, a scale-up company based in Amsterdam, where she led the rapid growth of her team organically within a short period of time. Annie also highlighted the importance of promoting engineering leaders from within. And she shared a 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 you 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.

Introduction [00:05:44]

Henry Suryawirawan: [00:05:44] Welcome everyone to another new episode of the Tech Lead Journal. Today I have with me Annie Vella. Someone who I knew from friends on LinkedIn. So Annie is currently in New Zealand. So I got a reach someone from that area, which is very good for me. But recently she actually moved from Europe. So Annie will tell the story about her later. So Annie, welcome to the show. I’m so excited to have you here with me.

Annie Vella: [00:06:10] Thank you, Henry. I’m really happy to be here too.

Career Journey [00:06:13]

Henry Suryawirawan: [00:06:13] First of all, Annie. Maybe if you can introduce yourself, telling the story about you and maybe some highlights or major turning points in your career, that would be great.

Annie Vella: [00:06:21] I sure can. All right. Well, my story starts at a very young age. I got a Commodore 64 when I was about five or six 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 it 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 bounced 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 I reached maybe high school. In 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, we 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 remember speaking to 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. And I thought, well, that’s not fair. I can’t do that. So I sort of tried to learn a bit on the side at home. But this was in the late nineties, and there really weren’t too many options for self-learning at the time. At least I didn’t seem to find them. And I didn’t really know anyone who could help me in 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 cause 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 there for. You can come from any background and I think I prove that you didn’t have to come with a set of knowledge already and skills in that area. I felt like as I progressed through my degree, I learned 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 that 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 called 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 a 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 believed that by doing, you learn more than just by reading about it or listening. So, I try to work on big projects. I tried to work alongside other engineers, who 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 in the UK for a couple of years, and then ultimately Amsterdam, which is where I was recently.

I’ve worked at, I think, 10 different 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 learnt 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 a 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’ve finally recognized just how important it is 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.

Resisting Management Early [00:12:25]

Henry Suryawirawan: [00:12:25] 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 impactful in the corporate world, normally. So if you can share a little bit more about your thought process, why you resisted 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?

Annie Vella: [00:13:01] 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 accounting. 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 medior senior. And then what? Maybe you might move into architecture, or you move into people management. But what sort of milestones did 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 being 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. It’s 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 where does their passion live? What brings them energy? Or some tasks that you’ll do might take energy away from you, and you need to look for something that gives you energy. And 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 architecture role. 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, and you’re 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, deciding which technology stack to use. So for me personally, I really love 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 than 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 respects 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.

Tech Career Milestones [00:17:34]

Henry Suryawirawan: [00:17:34] So I pick up a key point when you were sharing your short story just now. You mentioned about milestones which probably in the Tech career is not so clear, not so evident. And especially just now you mentioned, like 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 are 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 volunteered and things like that. So not necessarily have something well assessed or good attributes that you can say, “Okay, I tick all these boxes. I’m ready for manager.” So maybe you can share a little bit on that.

Annie Vella: [00:18:27] 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 Dreyfus 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 move from novice up to an expert level. Actually, what the Dreyfus 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 a certain sort of framework or 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. You want to prove to yourself and to everyone around you that you’re able to solve that problem. You’re probably pretty keen to get onto 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 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 rules 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 scopes, that’s the growth. So instead of being more 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 and 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 that can tell you that you are now at middle or senior level. It’s more around how you behave and why you’re 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 teams 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’re 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, it 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 into 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, when 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 scientist out there, Annie. 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’ve 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 story in this domain.

Working with Underperforming Lead [00:22:37]

Henry Suryawirawan: [00:22:37] 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 thus when they become a 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 go into 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 IC, as you more and more progressed as more senior, have you had a manager who actually didn’t perform on that level? And what kind of impact that would bring to an experienced IC like you? Is there such a story from your experience?

Annie Vella: [00:23:21] I do, actually. And funnily enough, it’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. There, the team lead of that team, he had been the most senior IC 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 were 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 error happens every night at 2:00 AM. 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, 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’d feel pretty good about themselves because they’d solve the problem. They’ve gotten a fix out to production. And 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 lead 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 was 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 anyway.

Henry Suryawirawan: [00:26:08] Right, right, right. So it’s also an accidental kind of a story for you picking up this management skills, right?

Annie Vella: [00:26:15] That’s right. Yeah.

Women and Early Management Role [00:26:16]

Henry Suryawirawan: [00:26:16] So Annie, before our conversation today, we exchanged messages. You had 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.

Annie Vella: [00:26:35] Sure. So over the past few years, I unfortunately have not worked with that many women in IT. Perhaps if you think about what I said at the beginning of this conversation, it wasn’t encouraged at school. And then there just weren’t that many women doing computer science at university either. 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 in 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’re 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 in IT for the last little 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 looked 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 puzzle 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’ve 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 later 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 IC 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, cause 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 and more of your time learning how to do effective one-on-ones, how to do performance reviews, how to help build career progression frameworks. There’s a 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 reckon. 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.

Growing Through Self-Reflection and Storytelling [00:30:08]

Henry Suryawirawan: [00:30:08] 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 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 mentioned most of the times is 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 through self-reflection and storytelling?

Annie Vella: [00:30:40] Sure. Let’s see. When I first became a leader, a manager of an engineering team, and I started doing one-on-ones. I was told one-on-ones are 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’re thinking, “Gee, they’re not performing as well as I thought they might in this role.” But it may not be anything to do with a 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 was 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. So at the end of the day, there’s plenty of material out there. If you want to learn how to set up a Redis cache, you can find a tutorial on that. I don’t need to show you myself. You’ll probably figure it out yourself. And to be honest, it’s probably best if you figure it out yourself than 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 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 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 maybe 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’ve 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 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 that 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 and 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 that. 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 we are 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, we’ll 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 to do what we hired them to do in the first place. You know, be the best engineer that they can be.

Self-Reflection Questions [00:34:51]

Henry Suryawirawan: [00:34:51] 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?

Annie Vella: [00:35:11] Yeah. So, when I first joined a team, in that first one-on-one that I scheduled with 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 ended 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 that. Other questions that I asked in that first one-on-one that helped 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 do 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 inefficiencies 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 is 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, there’s so many sorts of things like this. Like 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 do you find really frustrating or 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 asked 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. 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 started 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 onto me saying, “All right. That’s a perfectly valid insight. So what are we going to do about it? 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 can improve 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. I can 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 is to “be the supply to the unmet demand.” There are generally a bunch of unmet demands within an organization, perhaps even within your own team. Things that you could 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.

Henry Suryawirawan: [00:38:56] 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 you’re mentioning, “You know, the pipeline is slow.” “Oh, okay. Maybe it is slow. There’s nothing that we can do about it. It’s just slow.” Or the tests are breaking “Yeah. It just breaks from time to time. There’s nothing we can do about it.” So I think, yeah, this is 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 gatherings, brainstorming how to improve on things that they don’t like as a team. So I really, really love that.

Lessons Learned from MessageBird [00:39:34]

Henry Suryawirawan: [00:39:34] So Annie, you also work in the MessageBird 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. Maybe you can tell a story about your experience, your journey in MessageBird. What did you learn from there?

Annie Vella: [00:39:52] So MessageBird. Unfortunately, I only spent a year at MessageBird. It was just under a year because I came back to New Zealand, really to be closer to my family, in these days of Corona. In that time at MessageBird though, wow, MessageBird moved really fast. They are a very, very high growth company, very fast-paced, and in more ways than one. So, for example, they’re growing really quickly as in they’re hiring many people. And any given month, 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 the 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 contributors. 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 the 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. In this case, I was lucky enough that there were people within the teams who had 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 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. I had another engineer who was incredibly empathetic. Always wanting to help people, just the kindest 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 managed his team 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. In this case, it just worked incredibly well. And I saw them both gaining skills in 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 day to day when I’m a leader? And my manager at the time saying, “Well, there’s no list. You know, you’re just going to 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 code is. And the mindset there is that’s true. Because as a team leader at MessageBird, 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 are 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 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 to. 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 might argue with it. That’s not the purpose of giving feedback, right? So, just 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 are now leading, it’s also about forming relationships with other people at your 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 team. Those are some of the lessons that I definitely had the opportunity to learn at MessageBird.

I think I also learnt that it’s really important to bake a little bit of technical excellence into all of 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’ll 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 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’ve been otherwise able to. So, it’s a balance. It’s definitely a balance. And that’s something else that I think I learned at MessageBird 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.

Promoting Leaders from Within [00:46:46]

Henry Suryawirawan: [00:46:46] 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. I think it’s also worth to share for other engineering leaders who are listening to this episode. So how do you actually first spot the talents within your team who may make a good cut 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 a opportunistic basis where you see, probably when the team grows, you need more technical leaders in a team that you promote them or is there more like a progression?

Annie Vella: [00:47:33] 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, there were some 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 every day. 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 teams, 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 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 I mentioned before, he was very interested in how to improve a developer culture. And these are not problems that an 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 discussed 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, with 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 as well. Maybe they give it a go and they realize 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. Maybe 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 officially become somebody’s manager. And that gives them maybe some insight into the sorts of day-to-day tasks 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 it’s 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. In some cases, it might be more towards people leadership. In other cases, it might be more towards principal staff engineer levels. But I do think it’s very important to look forward and forecast where could this person be in one to five years. If they stayed with us, will there be a position for them to move towards and have more responsibility, more impact?

Henry Suryawirawan: [00:50:30] Thanks Annie for sharing your story. It’s been a great conversation. I learned a lot, like when to actually took a management role. And some of the guiding principles you have around all these, including self-reflection, importance of self-reflection. Finding opportunity to improve inefficiencies and things like that.

3 Tech Lead Wisdom [00:50:47]

Henry Suryawirawan: [00:50:47] 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 Annie, would you be able to share yours?

Annie Vella: [00:50:57] 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 in projects. Ask them about how they believe things could be done better. Ask them about how to improve inefficiencies. 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 to guide them to solving it themselves. Cause 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 my 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 over the last few years is 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 maybe very complex within a service or an application. You list all of those out and then you assign how a 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. You assign a 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 ever work on this piece of software. They’re the owner. 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 who’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, is to try and bake a little bit of extra quality into every piece of work 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. It’s cumulative. Over time, you’ll end up with a much more stable solution that you didn’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.

Henry Suryawirawan: [00:54:34] So yeah, I mean like lot of people, the tendency will be just rewrite it, right? I think I like the way you phrase it, like bake it a little bit, one at a time. Gradually and cumulatively, you will improve the system anyway. Thanks again, Annie, for spending your time. For people who want to find you online, is there a good place for them to do so?

Annie Vella: [00:54:51] Mostly on LinkedIn at this particular point in time.

Henry Suryawirawan: [00:54:54] Okay. I’ll make sure to put that in the show notes. So, thanks again, Annie. Hope you have a good day today.

Annie Vella: [00:54:59] Thank you so much, Henry. It’s been a pleasure.

– End –