Good Mentors Make Good Managers; a journey from IC to Management

So it's really interesting following David's talk on stoicism and how I can really think about how I can't handle how you are responding to my talk.

I can only focus on the presentation preparation that I was able to do and, dwell on that.

And yeah, hearing from Stefano about what it means to manage managers, and now that I'm in that role I guess this talk is really a great segue into what that looks like.

And I hope that really is something that we can all look at.

So for me as a software engineer, it's a career about continual learning.

When I started, I was working as a Web developer for several small companies.

There wasn't much thought put into mentoring or training beyond what we needed to do to get the work done for that day.

And often that it wasn't even that I wasn't sure if I was gonna share this, but the first job that I had as a Web developer, I actually got fired from.

Because they didn't teach me how to properly send out a mail merge with this system that I hadn't used before.

The client wasn't happy, called me into the office and let me go after that.

So that was really my first experience about not learning things.

And yeah, so wasn't a great start to, learning education in the career.

As I was looking around the people who were learning with me it seemed like we were all responsible for our own education.

We needed to know what we needed to know, how to find out, what were the tools that were gonna be useful, and we had to learn all of those on our own time.

For me, software engineering has been a relatively unstructured career.

There was an interest I had in computers when I was little.

Dad brought home a little computer.

We learned how to tinker and program on that one.

I learned how to pull apart websites when I was at school, after school doing all of those things.

My parents actually said, don't bother doing the classes for computers at school.

You're not gonna learn anything.

You already know everything that they would teach you.

I went on and did some university courses, a computer engineering course at Wollongong University.

That was great.

I learned all about the fundamentals of code, all the fundamentals of programming, how to put software together, how to run a software project.

But one of the things that I found is that it didn't actually set me up for what a career in software development was gonna look like.

So several years on, I'd worked at several different companies.

I didn't have a development planning, so these learning opportunities that came to me are the ones that I just did.

So some of those opportunities were really exciting.

Like when the iPhone was released, I was working for a, cycling magazine and we built some iPhone apps, well I built some iPhone apps.

I had to learn how to do it.

All of the, things released them to the store.

Really exciting time and some of the opportunities are much less exciting.

Had to rebuild classified ad sites.

Had to install and manage inventory management system for the job ads we were running on the classified sites, running e-commerce stores.

So all of those things were there.

But one of the questions that I didn't know is what were the thing that I needed to learn next?

I didn't have a structured learning pathway.

And so without that I wasn't I, was learning, but I wasn't learning strategically and I wasn't learning deliberately.

I was just collecting this broad set of skills, which were useful, but I wasn't going deep and I didn't have a framework to know what that was.

About this time about the 2015, 2016, there was this 10 X engineer memes going around and what it looked like, and you you were really grumpy and you didn't talk to people and you sat down and you got all of this amazing work done, and no one else know who knew how it worked.

But when I was looking at those memes, I was thinking, what would it actually look like if I was to try and be a 10 X engineer?

And for me the opportunity would be to work with 10 other engineers to help them in their careers.

And so that is where I started thinking about the, what it would mean to be a engineering manager.

But I didn't know what it would take to get there and I didn't even have anyone to ask.

And so looking back at that period of time, this is that quote that really struck me, which is 10 years of experience versus one year of experience 10 times.

If you haven't got a the opportunity for growth, you're repeating the same type of learning.

Yeah.

So as I was saying wanted to understand what it would take to become an engineering manager.

So when I was looking at the work I was doing I was in a Web agency.

We were rebuilding sites, I was learning some great skills around front end Web development.

Building these great agency design sites new sites each time, but it was the same work repeated.

And I was looking for what's the next step that I can take in my career?

How can I really look to have a bigger impact in the work that I was doing?

And, so with that I spent a couple of years in, in, in a few different roles looking at what are those opportunities.

But when I was looking for work, I began looking with this in mind.

How could I take the skills that I'd built up, and take that to a place where I would have the opportunity to continue to grow and have a bigger impact?

So a few years later when I was looking, I was taking, interviews showing them what I could do, but also talking about what they would be able to offer me in terms of training as well.

One of the companies that I spoke to, there was an interviewer there.

He was talking to me about what I was looking to do in a couple of years time, what was my plans?

And I was able to talk to him about the opportunity I was looking forward to understand what engineering management would look like what would it take to get there.

And this particular person said, oh, we're really small at the moment, only a couple of engineers.

We don't have, we don't have that engineering manager position at the moment.

We're very flat, but we're gonna be growing and we will have an opportunity to get there.

So that was great news for me.

Somewhere I could come, join, use my skills, and as the company grows, I'd be able to work with the CTO and kind of have that pathway as we grew together.

So this is the company that I joined was Compono.

I was working with David for part of that time and the mentor, the CTO that I found there was Nikolai.

So I joined a couple of weeks later and we started working together.

We built several projects as I was learning about the company and the products and the software that we were using.

But for me, the real most the most valuable time was the feedback that we had together in our regular one-on-one sessions.

I remember the first feedback that I got from him.

This is the notes that I made from our feedback session.

And that was really important to me because it wasn't just what I needed to change, but why I needed to make some changes in how I was working and the opportunity and benefit that would bring to the rest of the team.

And looking back at this, the one that stood out for me the most was working out loud.

So thinking about how people were working I always had this impression that getting your work done quickly and quietly was something that we should strive for, something to be respected.

But Nikolai was challenging this thought that I had.

He said to, to work with the team to work out loud, to ask your questions, to ask for help when you need the help.

That's a sign of maturity, and that's the opportunity that we have as a whole team to bring everyone's knowledge and everyone's experience together.

And so that was something that I began working through, because I, could see that the opportunity to bring everyone in the team together, share the knowledge and, the work that we were doing, and to be able to quickly help one another if there was some help that we needed.

And over the following months, Nikola and I spoke about a variety of topics from project management principles, from team leadership from motivation and alignment.

And we were talking about all of the things around project and people management that weren't in the day-to-day functions of a software engineer.

Some of those things we ran through together, and then we covered a bit of a skills gap analysis.

What were the things that I had already done?

What were the skills that I could demonstrate now and what were the things that I would need if I was to move into a role like this tech lead role that Nikolai I was thinking about, we might need soon for, for the company.

And that was the areas that I started to think about.

And so these new, areas that we were thinking about were systems thinking stakeholders, strategy reporting, technical advisory.

So all of these kind of, we had discussions over several months about what these looked like and, and how I would be able to be prepared for some of these.

And all of these he also recommended me books.

There were lots and lots of books he gave me.

So there were books on general people management, on remote people management more specifically we had some books about engineering process and how to apply a lean methodology to startups and projects, and we also had books about thinking and systems which were great for me in the time as well as things that I've been able to continue to put to use.

These are a couple of the books that I really enjoyed at this time.

The other thing with books is that was a really great way to spend all of that time on the train back when we used to commute to the office.

So that next thing that happened was, I did get this opportunity at the beginning of 2020.

The engineering department had grown from five engineers when I joined to now 30.

And so we were forming some cross-functional streamlined teams and I was given the opportunity to take the lead on one of these teams.

We were going to build a new product for the company that was gonna extend the functionality that we had.

There was a good, strong vision the company had of what this was gonna do, but it was up to the team to build out a roadmap of how it was gonna work and, to really deliver on this.

And of course we all know 2020 became quite an interesting time in terms of everyone moving to a remote working situation.

So that really challenged the way that the leadership of this team happened as well.

As I said, we were there building a new product and my responsibility is moving from an individual contributor to leading a team within as, the tech lead changed as well.

So I began working with a product owner in the team.

He was new to the company, but he was also new to working in a product team.

And so we had to work together to understand what that looked like and how it worked.

And we were also bringing the whole team from a, project based work approach to, in, to bring in bringing in agile engineering processes as well so that we could, we were having a real big shift in, in how we were working.

I was spending a lot more, a lot of my.

time mentoring and pairing with these engineers in the team.

So just working through their understanding of the work that we were doing, making sure that they had all of the, tools and all of the knowledge and all of those questions answered.

Making sure I had the time to work with them, to run through any problems that they were facing to help them with their work but also to make sure we all had a common understanding and alignment on what it is that the team was working on.

But for me it was really important to continue meeting with my mentor with, Nikolai to make sure that I had the opportunity to ask those questions and to continue working on those new ideas that we had.

This was an interesting piece of advice I got from Nikolai.

You'll probably fail a few times.

You're still learning.

It's really played into some of my insecurities, my anxiety and my perfectionism and my fear of failure.

We spent a bit of time working through psychological safety and what that meant.

So Nikolai was talking to me about he, he worked with the team to bring everyone's ideas together.

He, when he had a discussion, he would ask everyone for their input before he shared his ideas.

And this gave everyone the, opportunity to share what they were thinking before they heard what the boss said, because that way they weren't holding back thinking that they might be contradicting what the boss was wanting to do.

And I, found that had I, where as I was working with a team under him that was a great tool that to be able to make sure that everyone had the opportunity to contribute to the team.

So with the new tech lead role came, other new responsibilities.

So working with this product owner I was responsible for making sure that the plans and roadmaps we build were technically feasible with the tools that we had, and we could deliver on those with the teams and resources.

We had to work together to communicate with this company's stakeholders.

A lot of, bit of report writing and planning documentation.

A lot of that was me preparing the product owner as he was the one who had to attend all of these meetings, making sure that we had the supporting evidence and material that we needed to answer those questions.

I was just glad I didn't have to be in most of the meetings.

We were also responsible maintaining the quality of the code base and the delivery metrics, so making sure that we had enough tests on our software that we could make changes confidently and reliably and a good enough environment for our continuous integration that we could release to production whenever we needed it.

Now that I was working with and mentoring these engineers, I found that those same lessons that Nikolai was sharing with me at the beginning were the same ones that I was repeating to the engineers, encouraging them to work out loud, share the things that they were working on, and asking for the help when they needed it.

So as a team, we worked together to try and build a, degree of trust among us.

Safe for everyone to share their ideas.

And I was really aware of trying to be inclusive and bringing everyone in to all of the situations, all of the discussions and conversations that we were having around planning reporting and retros and things like this.

One of the best improvements I think that came out of all of this was one of the Q was the QA engineer on the team had been to a conference and came back with this idea of shift left.

And as a team, we were able to embrace this idea that, of shift left with within testing.

And that was something we as a team decided we were gonna experiment with.

What that looked like for us is in our delivery process we very much had a bit of a handoff between engineering and, test within the team.

We added an extra step where the engineer would pair with QA to run through their changes to make sure that everyone had a good understanding of what the change was and making sure it had covered all of the aspects required in this piece of work.

And we found that this had a significant impact, decreasing the number of defects that we had, and it increased our speed to shipping things into production.

We saw a great a great improvement from this process just because we had this opportunity to, have the QA come and, provide their suggestions.

This then became a process that rolled out across the rest of the organization.

Again, the QA was able to present these findings and show the, improvement we'd had as a team from this suggestion.

And so that was one of those great, feedbacks that came.

A new chapter.

So the engineering team was continuing to grow, so we'd now got 10 teams just in the start of 2021.

We were continuing to grow.

And there was a new role for an engineering manager several new engineering managers to support this growth.

We were using the Spotify model as we were looking at how we were gonna maintain the, engineering processes we had.

And so product and engineering was divided into three different tribes with three or four teams or squads in each of those tribes.

So for me, I was promoted to one of these engineering manager roles and I was given the responsibility for managing and the delivery for the team that I was leading, but also two more teams.

So a step up from tech lead to engineering manager was so much of a difference between, was as much of a difference as my move from software engineer into tech lead.

The domain, the scope of work I was needed to be across had tripled.

I had two whole new teams to look after.

What that meant is I needed to step even further, or I needed to step almost completely away from the day-to-day code that I'd spent the last 18 years really learning and, being my craft and trust that to the teammates that I was leaving in that team.

And I was now responsible for 15 software and QA engineers across these three teams and making sure I understood the work that they were doing and what was important for them.

Make sure that the teams are delivering well and helping each of these individuals define their own development paths.

So that was the journey that I've had into engineering manager, but it doesn't stop there.

The, first thing that I needed to do as an engineering manager was take responsibility for hiring in these teams.

And of course, me moving from tech lead into engineer meant the first role to hire was my replacment.

But before I could even get onto that one, one of the tech leads from these other teams had also resigned.

And now I had to hire two tech leads which this other role was a lot more urgent as I could backfill myself for a short period.

But there was a whole new team with a different domain that I wasn't fully across that I needed someone to come in with.

So in between running business case documents, ... reviewing position descriptions, CVs, and several hours a week of interviews it was very much a significant portion of my time now that I was in this role.

Thankfully with the support of a great HR team and other engineering managers, I was able to quickly fill these two positions and work with them to, onboard these new tech leads into their teams.

And get them to, yeah, really able to quickly come in and be effective in those, working in those products.

The second challenge that I faced moving into engineering management again with this team where the second tech lead was moving away there was some trouble brewing.

One of the engineers who'd been with us for several years she was taking a few days off for mental health reasons a couple of times.

And I a bit of a check in and she said she wasn't feeling great working with the team.

That made me go in and have a, chat to everyone in the team around the tech lead who was on his way out.

The engineer who, the established engineer who'd been with us for several years, and one of the new engineers who didn't, who was, who had just joined the team.

After speaking with everyone and trying to understand what the situation was, this established engineer was saying the new engineer wasn't respecting her code review suggestions in code reviews, wasn't paying attention to what she was saying in, meetings and, in planning sessions, and was having a difficult time not feeling respected and feeling like a bit of an imposter.

The solution that I approached the team with was to talk to the tech lead who was only with us for another three weeks, and I asked him could he defer to this established engineer within the team when asked technical questions, could he give her the opportunity to facilitate their planning sessions?

Could he really put her in the driver's seat for the leadership in this team?

My hope was that by giving her an opportunity to demonstrate the knowledge and the skills and the quality she had in these ways, that would really reset this relationship that the new engineer had come in and, really not necessarily set a great foundation.

I was checking in with, this established engineer a few weeks later, just after the tech lead had left.

And she was telling me that she felt great each morning waking up to come to the team and wasn't, worried about that anymore.

So that was a great outcome.

In conclusion what does this all mean?

So for me, as someone who wasn't sure what it meant to take, what it would take to go from an individual contributor into engineering management it hasn't been a very smooth transition.

There were a number of hurdles that I had along the way, but I can see that the opportunity to work with a skilled and knowledgeable mentor through that period meant at each step I could see what the gaps were in the way that I was working and how I could change to, better help the team that I was in.

I could learn about what was coming up in my career and start preparing the skills and knowledge so that when I did face those situations, they weren't as scary as they would've been earlier on.

When I had a mentor to meet with, I could ask that question, which is, what do I need to learn next?

Thank you.