BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations The Principal Engineer’s Path: Skills, Strategies, and Lessons Learned

The Principal Engineer’s Path: Skills, Strategies, and Lessons Learned

47:57

Summary

Sophie Weston explains that technical careers are winding journeys, not straight ladders. Drawing on 30 years of experience, she shares how senior ICs can become "broken combs" by broadening skills in systems thinking and strategy. She discusses the vital role of organizational flexibility and explains how public speaking and community engagement create feedback loops for career success.

Bio

Sophie Weston works as Principal Engineer at ClearBank. Prior to that, she worked with Matthew Skelton (co-author of Team Topologies) helping organizations to adopt Team Topologies and fast flow ways of working.

About the conference

Software is changing the world. QCon London empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

Transcript

Sophie Weston: Have you ever looked at someone in a senior role and wondered, how did they get there? Maybe more importantly, how can I get there? We talk about career ladders, as if the path to success is a simple series of steps, each one leading neatly to the next. In reality, careers don't work like that. They're not straight. They're not ordered. They're long and winding journeys, often full of unexpected twists. If you told me 30 years ago, when I was a junior dev, that one day I'd be a principal engineer, and on the stage speaking at somewhere like QCon, I probably wouldn't have believed you. Because back then, I didn't really know what to expect from my career. I certainly didn't have a grand plan. I didn't have much of a plan at all. I just wanted to solve problems and write code.

In many organizations, principal engineer is considered the highest level of the individual contributor, the IC path. Getting there and growing into any leadership role is about so much more than just having deep technical expertise. It's about influence. It's about communication. It's about strategy. It's about understanding that your career isn't just about climbing, it's about navigating, adapting, and growing in ways that matter to you. Crucially, it's also about having the right support from the organizations and the managers that you work for along the way. I want to share what I've learned so far from 30 years in tech. We'll talk about the role that organizations play in shaping career development. We'll explore some of the skills and strategies that you can employ to develop yourself and your career, whether you're aiming for principal engineer or another leadership role. Because at the end of the day, it's not just about reaching a destination, it's about making the journey work for you.

Who am I? My name is Sophie Weston. I'm currently a principal engineer at ClearBank. A little background on ClearBank, just to give you some context. The business was founded in 2015. We've got offices in London and Amsterdam. We're about 700 people in total, with about 270 across product and engineering. We're very much a tech company, but we're also a fully licensed and regulated bank. It's an interesting space to be in. As for me, I've been working in tech for very nearly 30 years. August will be the 30th anniversary of when I started my first job after graduating. For most of that time, I was a software engineer. I've worked on all sorts of projects using all sorts of tech. The bulk of my time being a hands-on techie was doing Java on some flavor of Unix.

About seven years ago, I finally made the decision to step away from the IDE, and I moved sideways into more coaching and consultancy type roles. I work with delivery teams and the wider engineering organization to help them improve how they deliver software and to help build a good engineering culture. I'm also very involved in the wider tech community. I've been an ambassador for Women in Tech York since it started back in 2018. I'm a co-organizer of two conferences. There's DevOpsDays London, which has been running for many years. Unsurprisingly, given the name, that's focused on DevOps practices and culture. The second conference is Fast Flow Conf. That's focused on the approach and methodologies described in the book "Team Topologies" by Matthew Skelton and Manuel Pais. I was a track host here at QCon London last year. I curated a track on how a team's really working. I co-hosted one of two tracks at the Platform Engineering Day at KubeCon. As you can see, I'm even known to give the occasional talk myself.

I've also got three kids who are mostly grown up now. My youngest son turned 20 about a week ago, and he's now off traveling in Australia with his girlfriend. My middle child is 24 and is training as a driving instructor. My eldest is nearly 26. Following in his parents' footsteps, he's a platform engineer. My kids are not something I normally mention when I introduce myself when I'm speaking. My usual bio that I give is much shorter and far less detailed than how I've introduced myself to you here, because much as I love my kids, their existence isn't really that relevant when I speak at a meetup or a conference.

As you'll see as this talk unfolds, this time it's different, because this is going to be a very personal talk. It's going to be my insights from my reflections on my career to date. My kids have played a part in that story. With the superpower that's hindsight, I'm going to look back on my 30 years in tech and highlight the things which I believe helped me most as I developed my career and which can also help you. The first important insight, though, is that my fondness for wearing green clearly hasn't diminished over the years.

Outline

This is an outline of what we're going to cover. To set the stage, I'll start by sharing how I define engineering leadership and what being a principal engineer means to me. From there, this talk has two main themes. First, how organizations can create environments that support career growth. Second, what you can do personally to drive your own development. If there's one key idea I'd love for you to take away from this talk, it's that the journey matters just as much as the destination. Since QCon brings together senior engineers, architects, and managers, I want to challenge you to listen to and view this talk through two lenses. I want you to wear two hats. First, think about your own career. What steps can you take to grow, develop, and shape your journey? Just as importantly, as engineering leaders, ask yourself, how are you paying it forward? What concrete steps can you take to support and create opportunities for those earlier in their careers?

What is Engineering Leadership?

What is engineering leadership anyway? If you're thinking about your own growth, leadership might seem like something for later, a role that you grow into. The reality is, leadership isn't just about titles, it's about how you behave. It's about influence. It's about guiding people, about creating an environment where people can thrive. What does that actually mean in practice? In my opinion, engineering leadership comes down to three things. The setting technical direction, this is about guiding teams and helping them to make smart architectural and technical choices. There's driving good engineering practices, that's helping teams build software efficiently that delivers real value, both to the business and to its customers. There's shaping culture, mentoring, coaching, making the organization a good place to be and to work.

As principal engineers, we tend to focus less on what teams build and more on how they build it. Our role is to spot patterns, connect dots across the organization, and guide teams towards better decisions without dictating from above. In fancy terms, I'd say it's socio-technical cross-cutting concerns. In reality, it's just helping teams do great work. An analogy that I like to use is that we're like the sweepers in the Winter Olympic sports of curling. Their job is to sweep the ice in front of the stone, reducing friction so it can travel smoothly and reach its target. They don't throw the stone or decide its direction.

Instead, they make small adjustments along the way, helping it to go further and more accurately. That's what we do as principal engineers, we reduce friction. We help the team and the wider organization move faster, avoid unnecessary obstacles, and stay on track. Personally, the area that I'm most focused on and passionate about is in creating a good engineering culture. By a good engineering culture, I mean one that's good both for the organization, it's able to deliver value effectively and efficiently. Also, crucially, it's one that's good for the people working in it. Yes, we want to have impressive DORA metrics, but not at the expense of burning people out. That's my take on engineering leadership in a nutshell. How do you grow into this role? Let's talk about that next.

Support from Organizations

I want to start by taking a step back and exploring some of the ways that organizations can support people's career growth. These practices aren't specific to engineering leadership roles, they're more foundational than that. They're policies and practices which enable everyone to pursue the career they choose. How many talented people have walked away from careers they loved simply because their jobs wouldn't bend even slightly to fit their lives? One of the most impactful things that organizations can do to help people in their careers is to offer flexible working. Allowing people to flex their work around the needs of their home life enables them to have the job and the career that they want to have.

For me, being able to work in a flexible way played an absolutely vital role in my own career journey. I mentioned my three kids in the introduction. I said that they were a part of the story. Because I had a young family and because I wanted to balance my family with having a career, I chose to work part-time for many years. In fact, I worked part-time for the same company for 20 years. Without part-time work when my kids are young, I wouldn't be in tech today. I would have had to walk away, as simple as that. Flexible working comes in many forms. For some it's part-time hours, working three or four days a week to balance work and life. Others compress their hours, working longer days so they can fit five days into four. I did something different. I spread my four days over five, finishing at 3:00 every day so that I could pick my kids up from school.

For some, flexibility means remote work, for others it's simply knowing that when life throws a spanner in the works and they need to take some time, work will understand. Flexible working and organizations being understanding of people's commitments at home shouldn't just extend to those with young families. Some people have elderly parents to care for. Some people want time to study, others just want a different work-life balance, it doesn't matter. The point is that these people still have a lot to offer, a lot to contribute. The benefit to an organization of offering flexibility is that they widen their pool of potential talent to include all of these amazing people, as well as those who are able and willing to work a conventional nine-to-five, Monday-to-Friday job. The role of managers is also really important.

A flexible working policy at an organizational level is worthless if managers block people from actually using it. If people fear that there'll be career consequences for working flexibly, then the policy is meaningless, it's just words on paper. Real flexibility needs real support from the top down and from bottom up. Flexible working isn't just a perk, it's a necessity of modern life. The companies that get this are the ones that are keeping their best talent.

One of the biggest career boosts you can get doesn't come from switching companies, it comes from within, internal promotions. In my experience, internal promotions are generally a really good thing. They're good for people who get promoted, assuming of course that they get all the support they need to transition into their new role. People feel valued. They work hard. It fosters a sense of loyalty. You shouldn't always have to move companies in order to progress. For companies, internal promotions aren't just a nice-to-have, they're a competitive advantage. Promoting from within keeps valuable organizational knowledge in-house, it strengthens team morale. People like to see their colleagues being recognized for good work. It proves that career growth isn't just a promise but a reality.

In my 20 years at the same company, I was promoted multiple times. I went from developer to senior developer to team lead to technical architect, before finally making a somewhat sideways move to the awesome sounding role of DevOps advocate. Internal promotions aren't without their challenges. Navigating friendships in the selection process, avoiding perceptions of favoritism, and stepping up from colleague to leader can be tough. Without the right support a promotion can sometimes feel a bit more like a battlefield rather than a stepping stone. Of course, bringing in someone new rather than promoting from within is sometimes absolutely the right thing to do.

There are times when you need a different skill set or experience of a particular technology or industry, or you might actively want someone without a history in the organization, someone who can bring a fresh perspective and inject some new ideas and ways of thinking. I've seen internal promotions work really well and be extremely beneficial both to the individuals and the organization. I've worked with many excellent engineers who started their career doing first-line support on the service desk and who were later given the opportunity to move into a new role and train as platform or security engineers. It was wonderful to watch how they grew and thrived in those new roles.

Internal promotions are an excellent way to retain talent but also to grow talent and develop people's careers. One final point before moving on. I've talked about the importance of flexible working and I've talked about the importance of internal promotions. For me the combination of these two things has been a huge enabler in my career over the years. Being able to work part-time and for that not only to not be seen as an issue day-to-day but also not to be regarded as a limiter to being promoted was crucial. Again, I simply wouldn't be here without that organizational culture of being flexible and being open to possibilities. No one should have to choose between family and career. A truly supportive workplace ensures that you can have both.

The last thing I want to talk about in relation to organizations is squiggly careers. A squiggly career isn't a predictably straight climb up the corporate ladder if there even is such a thing. It's a dynamic evolving journey where people take on diverse roles, sometimes even switching industry. Personally, I think that every career is squiggly to some degree or other. I don't think there is such a thing as a normal career path. As an industry, we should be supporting people who want to change roles over time. Whether that's moving from software development into security or quality engineering for example, or switching to become a product owner. I don't pick those examples at random. I know people who've made those very changes and with great success. Supporting people to move between roles is also beneficial for organizations. Companies that enable career mobility, retain talent, they keep people engaged and they encourage fresh perspectives.

One of the biggest squiggles that many engineers face is deciding whether to stay on the IC path or move into management. It's a crossroads that many of us reach, and unfortunately too often it's framed as a one-way street rather than as a flexible choice. For some people, that move into management works out just fine, but for others it can lead to frustration after a few years when they feel that their technical skills are beginning to atrophy. I know this first-hand. When I first became a team lead, I was thrilled to take on the role and lead a small team, but over time I found myself coding less and less and becoming increasingly frustrated and disconnected from tech. When an opportunity came up to return to an IC role, I jumped at it. I'm not alone.

Some organizations hesitate to allow engineers to move in and out of management roles fearing that it somehow signals failure or that it's disruptive to teams. In reality, having flexible career paths and allowing people to move back and forth between IC and manager roles ensures that managers are there because they want to be not because they feel pressured into the role. It also means that you have managers with strong up-to-date technical skills able to lead teams in the right direction. When managers move back into an IC role, they bring a wealth of new leadership experience that makes them even stronger technical contributors. Charity Majors the founder and CTO of Honeycomb has written extensively and with her usual eloquence on this topic that she calls the engineer manager pendulum. I urge you to go and read her articles. I'll include some links in the slides which I share at the end. Because this isn't just about individual choices, this is about how organizations support those choices.

That's where you as engineering leaders come in. Before we shift from discussing what organizations can do to how you can drive your own growth, I just want you to take a moment to reflect. Does your organization enable career flexibility? Does it promote from within? Does it support role changes? Is this something that you can take advantage of for yourself? Just as importantly, what can you do to help make those things happen for others? Because as you move into senior roles, you're not just navigating your own career, you're shaping the career paths of those who come after you.

As we've seen, organizations play a huge role in shaping career growth. At the end of the day your career is yours to navigate. Policies and frameworks can support you but they won't define your path, you will. If your goal is engineering leadership, whether as a principal engineer or beyond, taking ownership of your own development is essential. How do you do that? How do you build the skills that will help you not only advance but also lead? The first step is broadening your skill set. Broadening your skill set is one of the most important things you need to do if you want to become an engineering leader. Technical knowledge no matter how deep no matter how impressive is not going to be enough. I'm sure you've all heard about being T-shaped or being pie-shaped. In case anyone hasn't, being T-shaped refers to having deep expertise in one area, that's the vertical stroke on a capital T, with the horizontal stroke indicating a broad understanding of other areas. That evolved into people needing to be pie-shaped, that's the mathematical symbol pie not the kind you eat, which is about having deep expertise in multiple domains again with that broad understanding of other fields.

Being pie-shaped is obviously valuable but leadership demands even more breadth. You need to become a broken comb. As a broken comb, you don't have deep expertise in a couple of areas, you have varying depths of knowledge across many areas allowing you to bridge gaps, connect ideas, and solve problems creatively. Some areas of expertise will be deeper than others, that's what gives the broken comb effect. What makes you effective as a leader is the ability to integrate and apply that knowledge in different contexts. You can never predict exactly what scenario might arise when having a particular skill or area of knowledge will prove useful, but you have it there anyway ready to use. Having this breadth of knowledge gives you more options. It gives you different ways of approaching and thinking about problems.

Recommended Reading List

What are the key areas where broadening your skills will have the biggest impact on your growth as an engineering leader? There's no universal syllabus for engineering leadership, there's no checklist that you can follow. There are common skills and knowledge that in my experience most successful engineering leaders develop, so let's explore some of those. This is my recommended reading list. I say reading list because reading books is my favorite way to learn. If books aren't your thing, that's fine, there are plenty of other ways to learn. Conference talks are also great, you can find loads of those on YouTube. These are some topics and resources that I've found most valuable, and I'll share links to all of these at the end of the slides which I think will get shared later. "Team Topologies", read the book by Matthew Skelton and Manuel Pais, or watch some of the many talks that are available online by both authors. Watch the talks from Fast Flow Conf which are all on YouTube.

Domain Driven Design, there's loads of resources available on this. Read the original book by Eric Evans or check out the ddd-crew GitHub account. There's loads of resources there, loads of practical guides on things like event storming. Wardley Mapping, Simon Wardley's work is all licensed under creative commons and his book is freely available, or there are training courses available. You can follow Simon Wardley on LinkedIn, he's always posting really cool stuff. Check out learnwardleymapping.com as well. "Accelerate", I'm sure you've all heard of the DORA metrics.

The State of DevOps Reports, and the book Accelerate is where they come from. Accelerate is published by IT Revolution. I would recommend pretty much any book published by IT Revolution to anyone aspiring to move into engineering leadership. Theory of Constraints, start with "The Phoenix Project" which is published by IT Revolution, which is a novel about DevOps. I know it sounds a bit weird but it works. This is actually a DevOps focused rewrite of Goldratt's original book, "The Goal", in which he introduced the idea and the theory of constraints. The Goal itself is a great read, I think there's even a graphic novel version available now.

Psychological Safety, this is a really important topic. In my opinion, not enough leaders really understand what psychological safety is and how incredibly important it is. Read Amy Edmondson's classic on this topic, "The Fearless Organization", or check out Tom Geraghty's website at psychsafety.com. He has a weekly newsletter and all the back issues are available on the website. He's got a Slack space, there's a downloadable action pack. His company offers training courses too. Organizational transformation, again there's loads in this space. Some books that I found useful are "Team of Teams" by General Stanley McChrystal, there's "Turn the Ship Around" by David Marquet, and "Sooner Safer Happier" by Jon Smart. Software architecture, again obviously a huge topic. Recently I've enjoyed learning about Barry O'Reilly's Residuality Theory. I've only watched some of his talks so far, but he's got two books that are both available on Leanpub which are on my list. Strategy, more books, "Good Strategy Bad Strategy" and "The Crux" both by Richard Rumelt.

Also, "The Art of Action" by Stephen Bungay is a fantastic read. Systems thinking. Systems thinking is one of those things that once you start to get into it, it will change how you see everything forever. You'll never look at your organization in the same way again. Start with a book called "Thinking in Systems: A Primer" by Donella Meadows. This is simply the best introduction to systems thinking. It's one of my favorite books ever. There's product thinking. I think it's really important that engineering leaders understand product thinking. Pretty much anything by Marty Cagan is worth reading. I also really enjoyed "Escaping the Build Trap" by Melissa Perri, and Jez Humble, one of the co-authors of the "Continuous Delivery" book has a free online course on Lean agile product management. Then there's Building Teams. Read "Dynamic Reteaming" by Heidi Helfand. There's "Teaming" by Amy Edmondson, or the classic, "The Five Dysfunctions of a Team" by Patrick Lencioni. These are just starting points. My advice is to pick one thing that inspires and excites you and you'll naturally find that one topic leads to another.

Individuals - Bring Your Whole Self to Work

Work isn't the only place where you can develop valuable leadership skills. Think about the things that you do outside of your job where you can learn and practice these skills. If you're part of a sports team, you'll be building skills in team working and resilience. If you do volunteering, say in a youth group, for example, you'll develop skills in coaching or problem solving. Maybe gaming is your thing, in which case you're likely to have strong skills in strategic thinking and adaptability. Getting involved in the tech community and helping to organize events is a fantastic way to learn and practice new skills. I'll talk about that in more detail in a little while. Don't undervalue those skills that you learn in other parts of your life and don't underestimate how they can help you in your career journey. We often talk about the importance of psychological safety and the need for people to be able to bring their whole selves to work and be themselves at work. I think this applies in a wider career context too.

For me personally, nothing prepared me for leadership quite like parenting. Some of the most valuable leadership skills I have, I learned through being a parent. Negotiation skills, time management, multitasking, stakeholder management, well-laid plans that explode when you least expect or want them to. Constantly practicing being adaptive and resilient, influencing rather than controlling. These are all leadership skills. When I was going for promotion from senior developer to team lead, I was interviewed by the head of development. I think today he'd probably have the job title of director of engineering. I didn't know him very well at that point. He asked me if I had good organizational skills, and I just laughed at him, I couldn't help it. I said, "I have three kids under the age of 7 and I'm here, what do you think?" I got the job.

These skills that you learn outside of work are equally valuable as the ones you learn through actually doing your job. In some ways, they're more valuable because they represent more teeth on your broken comb. It's not just the skills themselves that are valuable, but it's the additional perspective you have from having acquired them in a different setting. Don't leave those skills at the door. Bring your full skill set, your whole self to work.

Make Connections

One of the fastest ways to grow isn't just about what you learn, it's about who you meet. Engaging in the wider tech community can expose you to new ideas, open doors for opportunities, and connect you with people who inspire and challenge you. There are lots of different ways that you can get involved. If you're looking for an easy way to start, social media can be a great entry point. Follow interesting people, engage in discussions, share your own insights. Even small interactions such as commenting on a post or resharing an article can help you build connections and stay informed. Blogging is another option. It's not something I've ever really got in for. I find the writing process very difficult and I'm incredibly slow at it. Although I did publish a few articles about psychological safety for my last employer's blog.

The best way to get involved in the wider tech community is through attending meetups. No matter where you live, there are ways to connect. If you live in a town or a city, chances are there are meetups covering everything from DevOps to frontend development. Virtual meetups and online communities can be just as valuable. There are spaces for everyone to learn and grow. I live in York, which isn't a very big place really, but there are meetups on .NET, frontend development, testing, software development, tech startups, and of course, there's Women in Tech, for which I'm an ambassador. There are many reasons to go to meetups.

Firstly, it's about learning opportunities. There are always great talks. Go and listen, hear new ideas, learn new things. Even if it's a subject that you're already familiar with, you'll hear a different perspective. You've got someone else's take on it. Meetups are also a great place to meet new people. The clue is in the name. When you meet someone new at a meetup, you can usually guarantee that you'll have at least some overlap in interests. Talk to people, swap stories, share your experience. Again, this is about learning opportunities, but it's also about networking. Networking is a really important tool in building your career. A broad and strong professional network can be a great source of career advice, job, and other career opportunities, and even emotional support.

One of the reasons I love Women in Tech York is because it's one of the few places and times where I'm not one of only two women in the room, if not the only one, which still happens all too frequently. For many of us, that's our daily experience. To go to Women in Tech events, and A, not be in the minority for once, and B, where most of the people there have that same shared experience, it's a very positive thing. Becoming more involved in a meetup or a conference as a volunteer or as an organizer can be even more rewarding. It's hard work and it's time-consuming, but there are many benefits. Becoming a co-organizer of DevOpsDays London and Fast Flow Conf is one of the best things I've done in my career, both personally and professionally.

Personally, I find it incredibly rewarding. Some of the best teams I've worked with are ones I've joined as a volunteer. You get to work with amazing people who you wouldn't normally collaborate with, and you get to learn new skills that you wouldn't necessarily get the chance to learn at work. Putting on an event is a very clear mission. There's no shifting priorities like there often are at work. Just a very focused goal. It's great. When you get there on that first morning, when attendees are arriving, the coffee's out, you've got a fantastic lineup of speakers ready to go, all that hard work suddenly feels incredibly worth it. Organizing events isn't just personally fulfilling, it's professionally rewarding too. It raises your visibility and it supercharges your network. You're working alongside other organizers and speakers, many of whom are at the very top of their profession. Volunteering in tech communities often means stepping outside your comfort zone and meeting new people, organizing events, taking on leadership roles.

Public Speaking (Step Out of Your Comfort Zone)

If you're ready for another challenge that will push you even further, public speaking might be the next step. I know that a lot of people think that public speaking is something they will just never have the ability or the confidence to do. To be quite blunt, I disagree. If you'd seen me the first time I stood up to speak in public, you would never have predicted or probably even believed that one day I would be here speaking at QCon. My first time didn't even really count properly as public speaking. I was only introducing some lightning talks that I'd organized at work, but I was so nervous about having to speak to a room full of people that my heart was pounding and I had a whooshing sound in my ears. I know very few people, even those who appear regularly at events like this, who don't get nervous about speaking in public.

For most of us, that's just natural. It's also worth noting that even for those people who are totally chill about the idea of just grabbing a microphone and getting up on stage to speak, that doesn't necessarily make them skilled public speakers. Being good at public speaking is about so much more than just being naturally outgoing. It's a skill that needs to be learned, and it's a skill that anyone can learn. Why go through that pain? What are the benefits of public speaking? It builds credibility, lets you show off your knowledge. Sharing your knowledge helps both you and your audience grow. You're now the one giving learning opportunities to others. It strengthens communication skills. Learning to articulate and present your ideas clearly makes you more persuasive in meetings, presentations, leadership roles. It boosts confidence and growth. Stepping out of your comfort zone is where real growth happens, I promise you.

The best way to start along the path of public speaking is by giving internal talks in your organization. If you don't already have weekly tech talks, you could be the one to introduce them. They provide a place where people can learn and practice the skills of public speaking in a safe, friendly, and supportive environment. They're also one of the very best ways of creating a learning culture, by sharing knowledge, breaking down silos, and building connections across your engineering organization. I've been championing and organizing internal tech talks at the places I've worked for nearly 10 years.

Bringing It All Together

I've talked about the need to broaden your skill set beyond merely technical expertise. I've talked about the benefits of getting involved in the wider tech community and about the benefits of public speaking. The real benefit comes when you bring all of these together because they don't just add up, they have a multiplier effect. You begin to create positive feedback loops. Learning new things leads to meetups, going to meetups leads to speaking, speaking leads to organizing, and before you know it, you're at the very center of the communities that once inspired you. You're contributing. You're helping to shape and lead them. For me, a desire to learn led me to engage with subject matter experts on social media and to find local meetups to go to. Through doing that, I met new people, was exposed to new ideas and perspectives, which resulted in me adding yet more things to my stuff I want to learn about list. This is what I mean about creating feedback loops.

After that, I volunteered to help run some events and I also took my first tentative steps along the path of public speaking. Slowly but surely, I began to increase my knowledge, increase my confidence, develop new skills. Doing all these things doesn't just expand your knowledge and your confidence. Importantly, it also raises your visibility, and that can lead to opportunities because what people get to see when you're doing all these things is someone who is knowledgeable, eager to learn, eager to share, committed, dependable.

Personally, I can say without any doubt that my career has been shaped by the skills, connections, and visibility that came from engaging in the tech community. Of course, some of it is still down to luck, call it serendipity, but to a certain extent, you create your own possibilities. My own journey is proof of this. The very first time I spoke in public properly was at a Women in Tech York event, which was lightning talks. I gave a lightning introduction to DevOps. I didn't realize at the time just how significant that choice of topic would be, because it just so happened that one of the co-organizers of DevOpsDays London was there that night to donate a couple of free tickets to the conference to the Women in Tech community. That chance encounter, I didn't even talk to him, but he heard me speak, and that was the first step which eventually led to my being asked to join the team as an organizer. You create the conditions where these opportunities can happen.

But, and this is a really big but, when it comes to self-development, stepping outside your comfort zone, learning new skills, intrinsic motivation and a growth mindset are absolutely key. You do these things because you love them and you find them rewarding because they challenge you, because they make you grow. Through that growth, you may find that some doors open for you that otherwise wouldn't have. Don't do these things because you expect doors to open for you as a result. When you focus on what you love, you'll often find that opportunities come your way. It's like the '80s movie, the Field of Dreams, starring Kevin Costner. Anyone know that one, the baseball one? Build it and they will come.

Step outside your comfort zone, try something new, share your knowledge, engage with the community, not because you expect something in return, but because growth happens in the doing. If you do that, you may just find that the best opportunities are the ones that you never expected. Let's revisit those two hats one last time. Does your organization encourage people to attend and speak at meetups and conferences? Are you given the time and the budget that enables you to do that? Do you encourage and support others to do that? If your office space is suitable, do you make it available to host meetups in the evening? Do you have weekly tech talks? If not, I encourage you to be the one to propose and organize them for yourself as much as for anyone else.

Takeaways

Let's just take a moment to reflect on what we've covered. We've talked about the need for organizations to create environments that support career growth and also what you can do personally to drive your own development. These are the key points that I would like you to take away. Careers aren't ladders with neat, ordered steps, they're winding squiggly journeys full of unexpected turns. The route to engineering leadership isn't predictable or a fixed path, it's a journey of learning, adapting, and growing. If that's your goal, here's what can help you along the way. Organizations need to support flexible working, promote from within and enable people to switch roles.

In particular, allowing people to move back and forth on the engineer manager pendulum. Ways you can drive your own development and growth include broadening your skill set beyond deep technical expertise to become a broken cone. Engage in the wider tech community to learn new skills, raise your visibility, and supercharge your network. Push yourself out of your comfort zone to try public speaking to improve your communication skills and grow your confidence. As leaders, you need to pay it forward, advocating for and supporting those coming along the path behind you, even as you're looking ahead and planning the next steps on your own journey. Finally, the support that organizations provide through policies and company culture is foundational. That builds the path along which you're able to travel. How far you travel along that path and how fulfilling that journey is, is entirely down to you.

Questions and Answers

Participant 1: You've been in tech for a really long time. It's very impressive. How do you manage to stay on top of the new technologies? Because sometimes it feels that if you sleep on something for a month, it's like you are already late.

Sophie Weston: I'm very old and I've been in tech forever. How do you manage to stay on top of things?

It's easier for me now because I am not hands-on tech. I don't have to be as deep in it. There's always this expectation that you just have to do it in your own time. What I don't like in tech, there's just like, what are your side projects? I think this is part of what organizations need to do is they need to give people time, because that's part of our job. We can't do our job unless we stay on top of things. You just have to do it. I think part of that is organizations making sure that you have the time to be able to stay focused and train and learn, and not just have it be what you do in your home life. I don't know if that's a particularly helpful answer, but yes.

Participant 2: I have a question about moving back and forth between management role and individual contributor. Some companies may offer a hybrid role where they say, you spend some time managing, but you also spend some time being an individual contributor. Do you think organizations should do that? Also, should individuals look for this kind of role?

Sophie Weston: It depends slightly on the size of the organization, because if you're in a very small company, then maybe that's going to work because you might have small teams and things. I think it's quite a different skill set. I'm not advocating for people moving backwards and forwards, but I think you should be able to focus on one or the other. I think if you're an engineering manager, you should be focused on people and the people in your team and helping them develop their careers. If you're being an IC, then you should be focused on the tech and doing good work for your team. Potentially, yes. I think they are different skill sets.

Participant 3: One question goes to the detail that you mentioned on what the organization can do. You mentioned as a team or the question of what to do when the switch between the colleague to a leader happens. Then it can be sometimes more of a battle than a smooth move. Can you say a couple of words more about that? What can the organization do to help?

Sophie Weston: Because you suddenly go from being one of the crowd in the team to being outside that and sometimes having to tell people what to do or say no. That's what can make it hard. I think organizations just need to be aware of that and potentially give new managers or the role I'm moving into a mentor, someone else that they can talk to who is in the same boat, who can just answer questions and just be that point of contact. We talk about people having onboarding buddies when you first join a new company. Just someone that you can go and say, this is a really stupid question, but how do I do this? I think it's the same kind of idea, just being supportive, not just expecting people to be able to make that jump and succeed instantly.

Participant 4: What mentoring models or approaches did you find really useful on fostering the growth in terms of technical and leadership in the organization?

Sophie Weston: Personally, what I've seen work best is just that kind of one-to-one mentoring. It's about finding someone who has got the skills and experience that you want to learn from, but you also need to be able to have a good relationship with. Companies I've seen when it worked well is you just say who wants to be a mentor, who wants to be a mentee effectively, and just pairing people up. It doesn't always have to be a really long-term relationship. It might be that you want to learn a particular thing, and someone in your organization has skills about that particular thing. It can be short term. I don't think there's anything wrong with that as long as you both go into it knowing that that's what you're doing. Then, obviously sometimes it can be longer term and a more ongoing relationship. For me, mentoring, that's the way it's worked best.

Participant 5: How do you persuade? Since you're a principal engineer, you said all these things, but no one is following them or not going with the direction you said.

Sophie Weston: You just have to talk to people. A lot of being a principal engineer is about talking to people, both in meetings at group level, but also doing that kind of influencing and talking to stakeholders and getting them on board. A lot of talking.

Participant 5: Accomplishments, like a brag list, when it comes to promo time. Since it is a very different style of things that you do as a senior engineer, how do you measure them? You're not writing code, like not putting up products. What is the effective way that you found?

Sophie Weston: That is tricky because I don't like the brag list thing. As I said, about being a sweeper of the ice, you're quite visible in some ways. It can be a hard one. It's not one that I've solved particularly well, because I don't like going, look at me, I've done all these things.

 

See more presentations with transcripts

 

Recorded at:

Apr 01, 2026

BT