Talk transcript

Hello, everybody! I'm Barbara. I'm here to tell you a little bit about my career journey from engineer to leader to manager. Somewhere along that way, I encountered a little dilemma. I had achieved the career progression. I had the title. But now what? A bit of uncertainty hit me as to whether the path I had chosen for myself was, in fact, still the right one for me.

So today I will be sharing how I navigated that uncertainty, and I'll finish off with some practical tips that you can try out to see whether they help you figure out what the next logical step might be for your career.

Barbara's background

By now, you've probably heard — I'm originally from Germany. I moved to New Zealand and did a computer science degree at Canterbury University in Christchurch, before moving to Wellington and starting my tech career. I started off working for a big management consultancy called Accenture, and then worked for all kinds of fabulous places over a period of around 25 years.

I had all kinds of different roles. I started off as an engineer, went to senior engineer, became a technical lead in all kinds of different versions and flavours, before becoming an engineering manager and a manager of engineering leads.

So you could say I did the classical career ladder. But it wasn't quite like that for me. It wasn't as deliberate. In fact, I resisted for quite a long time moving up that ladder. I remember a manager, maybe after five years of being a senior developer, trying to get me to become a project manager. I resisted, because that wasn't really the right time or the right thing for me to do. But eventually I got curious, and I did become a manager in the end. That ladder, though, looked pretty one-way for a long period of time for me.

The individual contributor myth

First, I want to talk about engineer roles and what I call the individual contributor myth.

Individual contributor (IC) is a term commonly used to distinguish between a person in a manager role — who has people reporting to them and is responsible not just for their own work and goals, but also for other people's work — and a person like an engineer, tester, or business analyst who doesn't have any direct reports and therefore supposedly only contributes individually.

I've discovered for myself that that is a myth. In my opinion, the best engineers are those who have discovered early that software development is a team sport. You are seeking synergy with other people. You are collaborating deliberately with many people, putting all of your clever brains together to achieve an outcome much better and much bigger than what you could achieve as an individual.

I'm sure you've encountered examples like this. You might have had to coach a junior developer — making sure they can get productive as fast as possible, while showing empathy so you don't overwhelm them. Or you might have had to defend a design. You've been tasked to do a technical design for a new microservice, presented it to your team, and maybe had to defend it against an architect who thinks you should be doing an event stream, while you think a synchronous application programming interface (API) would suffice for the small scope. So you're constantly negotiating.

You may or may not have the luxury of a scrum master in your team, so you find yourself taking turns in that role — planning, becoming responsible for your team's delivery for a sprint, and facilitating. All of these are clear leadership skills. You are leading — you may lead without authority, but you are still leading. And you are directly influencing the performance of the people around you.

Life as an engineering manager

Eventually, I became an engineering manager. I want to tell you a little bit about what that felt like.

As an engineering manager, you face bigger challenges than before. One I clearly remember: I was an engineering manager at BNZ (Bank of New Zealand). At the time there were approximately 1,000 people working in technology, looking after approximately 1,000 systems — about one system per person. There were plenty of engineering practice standards around, but they were all scattered all over the place. They had about 10 domains or departments, each with their own standards, and engineering leads and engineering managers were responsible for conveying those standards to the software delivery teams.

The challenge was that my manager came in and said to me: "Look, Barbara — would you be able to write down four organisation-wide standards for engineering practices that apply to microservices? And can you do that with your team in the next quarter? Can you make sure those standards are agreed across the 1,000 people, that some of the teams your engineering leads are working with have already adopted those standards, and that each standard comes with a fully automated report that clearly shows which systems are adhering to it, which ones are not, and who owns them?"

That was a really big challenge. My engineering leads were already in full-time roles looking after teams — working with two teams at a time and helping with their day-to-day software development. They had just a few hours a week to help me with my lofty goals. It was a big challenge, but I had a great team, and we had to do some acrobatics to get it done.

Conflict resolution & stakeholder management

Conflict resolution is another thing engineering managers do a lot of. There are the typical interpersonal conflicts — an engineering lead says something that offends a developer, and you get brought in to mediate. But there's also conflict around technical direction.

An example: our engineering managers came up with some standards for source control. One rule said you cannot merge your code to master unless an automatic build has succeeded. A few people were upset, and one person in particular was really frustrated. He said: "This standard is not well thought through. It's causing my team so much rework. We've got all these repositories that only contain documentation and tests. It's completely unreasonable to ask us to have build pipelines attached to that."

From his point of view, that was completely correct. What a silly thing to ask — to put a pipeline on a documentation repository. But from the organisational point of view, we were working at a bank. A bank has several internal and external audits every single year. You cannot simply trust 1,000 people to always do the right thing and not sneak malicious code into their documentation repositories. We needed an automated, quick, and reliable way to provide proof to auditors that malicious code cannot enter the system.

It's a classic example of a situation where you don't need to have a fight. You can just explain the context, and people usually come along on the journey.

Stakeholder management is another thing engineering managers do a lot of. Effectively, stakeholders want to move in all kinds of directions, and you have to try to coordinate, find common ground, and bring everybody back together.

And lastly, my personal favourite: inspire and motivate your team to follow you on some journey to achieve some lofty goals, and try to turn all of the individual deliveries into one synchronised, coordinated performance.

The dilemma: manager or engineer?

So I did all that, and then the dilemma arrived.

I had an amazing manager — I found him inspiring, I trusted him, he believed in me. I had fabulous colleagues. We were having fun at times. I was hitting my goals and getting positive feedback. Everything was wonderful.

And I felt loyalty and connection to my team. I didn't want to disappoint.

On the other hand, I had that little voice in my head that kept asking me: wouldn't you be better off being an engineer? Do you remember how much time you had designing and building microservices? Is this really you? You're good at it, but remember — you can be good at something that isn't really you.

So the question became: are you a manager, or are you an engineer? A type of professional identity crisis emerged.

Pluralistic ignorance

The first thing I thought to do was speak to some of my peers who had also progressed from engineer to manager. And I was absolutely certain that I was the only one who felt like this. Everyone else seemed perfectly comfortable and happy in their managerial roles. Must just be me.

There's a term for that. Social psychologists call it pluralistic ignorance — you think everybody else thinks something different from you, when in fact they don't. Once I started speaking to my peers, it emerged that lots of them were feeling the same. That provided some comfort, because I didn't feel so alone anymore. But it still didn't help me figure out what to do next.

Finding a mentor & the Engineer/Manager pendulum

Next, I decided to join a mentorship programme I had seen advertised on LinkedIn. I was selected as a mentee, and in that programme I met two fabulously inspiring technical leaders.

One of them was Anna. She was assigned to me as a mentor and helped me make an action plan of how to proceed in the direction I chose. She stayed alongside me, supporting me through all the stages.

The other inspiring technical leader I met in that programme was a mentor for somebody else. She in the room on today — it's Rachel Collingridge. Thank you, Rachel!

What Rachel did was ask me: "Have you heard about the engineer-manager pendulum, Barbara?" I said no. She sent me the article — Charity Majors wrote it in 2017. I went and had a read, and I thought: oh my God, this is exactly what I had been experiencing.

The article describes an engineer who is successful in their career, gets a bit bored or curious, and becomes a manager. It's a whole new set of skills. It feels really hard — it's like a completely different job. But then some of these people pendulum back. They become engineers again. And they are so much better at it now, because they have been a manager before. They know what their manager needs from them. They're so much more effective in their role because they understand what their boss needs.

And some of those people then pendulum back again — they become managers again. Because they have recently refreshed their technical skills, they are much better at strategic planning. They're more in touch with what's going on. We all know how quickly tech moves these days, especially with AI.

So this struck me as a way to get better at both jobs. This wasn't about resigning, quitting, or stepping down the ladder. This was about getting better at both sides of the role.

From pendulum to continuum

That was enough encouragement for me. I applied for a role as a principal engineer, not really thinking I would get it. But I did. I got hired at a lovely company called Totara.

I expected to become somewhat of an engineer again — learning PHP and working practically with different teams. But the mission turned out to be different: use your technical skills to work closely with the 10 software delivery teams, find out what their key pain points are, structure them, organise them into a roadmap, market that to the technical leadership team, and help the organisation improve their practices. So it was a technical leadership role again.

I had a sense of déjà vu — but it wasn't quite the same. And I realised: it's not just a pendulum. You don't have to swing back all the way. Instead, it's a continuum. There are roles in between, across the entire scale. That was a huge revelation for me.

If you imagine a technical skills scale — typical developer skills on the left, technical manager skills on the right, and in the middle the skills you need to be good at both — it's actually multi-dimensional. You have an axis for each skill, and you could be scoring high, medium, or low on each one. The combination of all those axes is your individual skill set.

Tip 1: It's about you

So here's tip number one, if you're feeling a bit stuck or wondering where to go next in your career: it's all about you.

What do you want? And I really mean you. Not your family, not your manager, not the people who report to you, not what your neighbour wants you to do. What do you want to do?

It took a while for me to discover that. What really helped were three questions I kept asking myself.

The first: what makes you feel good at work? What makes you feel elated? I started writing a journal — every evening I sat down and wrote down what I had really enjoyed that day, if there was anything at all. This can be completely different for every person. It could be that you fixed the trickiest, most dangerous production problem that day. Or it could be that you gave a presentation and someone who's usually quiet came to you afterwards and said: "I really liked what you said. I could really relate to that." Or it could be that you wrote a submission for a company prize for one of your employees, and they actually won. If you start keeping a log or diary — I eventually moved to weekly, so the frequency doesn't matter — you see a pattern emerge. What satisfies you at work?

The second question: what are you good at? That's a completely different thing. My manager at the time encouraged me to do a strengths test. That changed my world. All of a sudden I understood why some things at work come so easily, and other things feel like the worst chore. It's got to do with your strengths. That's worth looking into.

The third question: what are you optimising for, at this particular point in your career?

Is it status — do you want to be in a position in your organisation where you can directly influence the direction the company is taking and the decisions being made? Or do you want to optimise for money? A common misconception is that managers always earn more than principal engineers. That may or may not be true, so be careful there. Or do you want to optimise for flexibility? You might have a young family and want to spend more time with your kids. Or you might have earned well and it's time for a bit more freedom to spend time on the things you enjoy outside of work.

Tip 2: Roles are more fluid than you think

When you work for one organisation for a while, your horizon starts to narrow. You think the particular organisational structure you see is all there is. These are all the roles there are, and you have to navigate yourself within that. That is not true.

There are roles out there you won't even have heard about. There's probably a different role for every centimetre on that skills continuum. You just have to go out and find it.

Tip 3: Experiment and learn

This one heads towards the growth mindset. What are you interested in learning right now? If you put all your energy and focus on that, you will achieve it. There is absolutely no doubt about that.

For some people, the career ladder really works, and that's great. But if it doesn't work for you, go broad. Try something else. Try something sideways or in a different direction. Treat your career like a proof of concept (POC) — you have a hypothesis about what might interest you, you give it a time frame, and then you experiment. If it doesn't work out, there's no such thing as failure. I strongly believe that. There's only learning. Okay, it wasn't that. That's fine. Let's try something else.

Tip 4: Know your own worth

And lastly, the unicorn tip. This is about knowing your own worth, and it's probably the hardest one.

In my experience, people who are good at both the managerial and leadership skill set and the technical skill set are a little bit rare. They are on the unicorn scale, and they are really highly in demand. If you can do a bit of both, that is the unicorn recipe.

Unfortunately, the same type of person — and probably most people in information technology (IT) — tends to have a bit of impostor syndrome. They can't really see their own magic.

How do you overcome that? Mentors really worked for me. They are a little hard to come by because they're usually successful and therefore quite busy. Another concept that works really well is the personal board of trustees.

What is that? It's a group of people you choose and gather around you — anyone from a close friend to a family member. Someone who trusts you and who you trust. Someone who hears all your stories. When you come home after a really good day, they hear those stories. When you come home and it was an absolute disaster, they hear those too. Use your board of trustees to navigate your career, experiment, and get their feedback.

Feedback from your manager is valuable, but take it with a grain of salt. Managers tend to have their own agendas — they probably need you in that role so they can achieve their own goals. They are usually honest, but they don't always step outside that to ask: is this actually right for this person? Your personal board of trustees will.

Summary

Here are my four tips. I hope they help some of you find the next career step that is right for you, and help you jump into action.

I'll finish on this quote by Martin Luther King: "You don't have to see the whole staircase. Just take the first step."

Thank you!

Talk references

The Engineer/Manager Pendulum by Charity Majors