Everything around us is constantly changing and developing - it’s tough to keep up with, let alone get ahead of. So how do we navigate our own careers and those of our teams with everything in flux? In this talk, Meri will introduce the concept of career vectors, which they have used in coaching hundreds of technical leaders over the years. You’ll learn tools for guiding your own career, those of your team, and even for communicating what types of opportunity is available at your organisation.
← All talks 
Lead Turing Fest 2024
Career Vectors: Navigating Modern Careers with Meri Williams
Auto-generated transcript - may contain errors. Tap a timestamp to jump the video.
Good morning, everybody. So hi. I'm Mary. Yeah. And my eclectic career has already been described by Brian. The thing he didn't mention is I'm I'm I'm not from here. I'm South African originally. And my weird achievement early on was that I, built part of South Africa's first satellite as a teenager.
So if you have children, I have great advice, which is don't let them do anything cool when they're young. Because I soldered something that went into space when I was sixteen. And it's all been fucking downhill since then. So, so yeah. As, as mentioned, I'm CTO at Pleo these days.
But I also run the Lead Dev Conference, which is a a leadership conference disguised as a technology conference, down in London, which is what that big picture's there from. And I've had a bit of a weird career, but it's had a few different kind of horizons.
I started out as an as an engineer. Everything was about code. And then got to the point where I realized that maybe it was all about the systems. And then, actually, how things fit together and the architecture and, you know, the bigger picture started to to make a bit more sense to me.
And And then I got into into process, as some engineers do. And then I had my, like, oh, shit moment that maybe the people mattered as well. And I'm not one of the people who ended up as a as a leader because I was good at it.
I'm one of the people who ended up as a leader because I just couldn't let other people do it badly, and insisted, that I would learn how to be good at the people things, honest gov, and and eventually moved over into that. And then realized that, okay, maybe it only really matters if there's people doing well in healthy teams delivering tech that actually meet some business needs, which is probably an embarrassingly late realization to have.
And then because I'm autistic, my brain then just made it all systems of systems, and that made it make more sense to me. And I suppose what I learned from that along the way was that there's no single flavor of leader. And I'm just gonna speak a lot about technical leaders today.
But I think oh, actually, I know I've gotten feedback on, on this framework before that it's genuinely quite useful for other disciplines as well. You'll hear me talk about coding and tech and architecture, and just substitute that for whatever's most relevant for your own specialism.
But there's no single flavor of technical leader. And on the one hand, that's quite freeing. It means you can chart your own course. But on the other hand, I think it's a bit scary. I think the fact that we don't have clarity on what leadership looks like in a lot of our disciplines, particularly the ones that are, very modern and digital, is a little unsettling for people.
My wife's an architect, a real one. She builds hospitals. Everybody always assumes she's an info architect. And they've got much more structure and rigor and, you know, they you have to be qualified to call yourself an architect and all these kind of things.
And it's very interesting comparing our industries and how immature engineering seems, in a lot of ways, software engineering, anyway. And so in this kind of miasma of leadership expectations and responsibilities without a lot of clarity, it's interesting to to try and make sense of things.
And so what I do is I tend to look for examples and try to spot the patterns. There's lots of different flavors of technical leader. I think what most people assume a CTO to be is a hands on deep technical expert. But what many CTOs at very early stage companies are is tech leads.
They're focused on delivering projects and products of increasing complexity over time. And they're not just trying to articulate what the best code approach is. They're also trying to figure out how to best meet the the user need or business need. You then end up with folks who are more architectural.
So they're working at a different, more strategic level of abstraction on the systems, the tech, the processes, and everything else. And then I think what you find at larger companies or even midsize companies is a combo manager leader roles, where they're developing and enabling individuals, but also teams.
And then you do get some roles, and particularly very much larger organizations, where even the technical leadership roles are just organizational leadership roles. You're managing managers. You're managing managers of managers of managers. It's just turtles all the way down eventually. Right? And I think having coached, at this point, kind of hundreds of technical leaders over the years, that brought me to what I call career vectors, which is basically just the different directions that you can go deep or broad in as you develop in your career.
And so this, aims to be a kind of not a replacement for career ladders or career development frameworks or anything like that, but almost the meta level of them. So rather than thinking, about the very specific skills that you need or or that kind of stuff, it's about going what helps you figure out what to go deep on, what to go broad on, and where to invest your time as you develop.
And so let's jump into it. The first vector is hands on, in-depth. And so for for me as an engineer, this means coding. For you as a marketer, it might mean something different. For a product manager, it's all about writing stories and speaking to customers and understanding what's needed.
For designers, it's designing in all different, forms. I'm enjoying the latest discourse on Figma not being good for prototyping because it looks too good, and that kind of stuff. But it's generally the work that you do as an individual contributor that gets you noticed, that gets you the opportunity to lead in the first place.
But as they say, what brought you here doesn't get you there, and so it's often not enough. The second vector, and I think the one that people understand the easiest, is strategy. Or they understand the need for it, if not how to do it.
And so figuring out what does the longer term look like, what does the right short, medium, and long term investment look like, and how to think about the way that your technology strategy, your product strategy, and your business strategy all interact with each other.
The third is delivery, getting shit done, which, whether we like it or not, is a skill, and is something that we have to aim to get better at, over time. I think there's formal roles about this, like project management, or scrum master, or delivery manager.
But it's also just a need that everybody has to get better at delivering things. Organizational leadership and management, like we talked about earlier, managing managers, managing other people, helping people achieve their potential, I think, is the greatest kind of calling a manager can have.
I think if you can be the person who makes ten to twelve other people the best they can be, you can be immensely impactful. And I think if we can just think of management roles more along those lines rather than the bad boss, Dilbert, pointy haired boss stereotype.
Because everybody hates the pointy haired boss in Dilbert. Right? It's funny because it's so recognizable. We've all had empty suit managers or a boss who practices the seagull style of management to fly in, shout at everybody, shit on everything, fly away again. See, I judge how damaged the room is by how big a laugh that gets.
You're clearly a lot healthier than a lot of the audiences I get to talk to. These first four are pretty obvious. I think the next two are more interesting. Commercial understanding. There's a point in everybody's career where a budget spreadsheet enters your life and never leaves again.
And, embracing that rather than rejecting it is, essential to success in the long term. But I think it also means understanding your business, understanding your products, your users, understanding what your unit economics are, understanding how you're gonna make money, and whether you're gonna be able to make money in a sustainable way.
And then finally, domain depth. Now I spent a lot of my career in domains that were so easy to understand that domain depth didn't really matter. Ecommerce is something that you don't need to get very deep in to understand that you're selling some stuff from a shop that just happens to be online rather than in person.
I worked the first ten years of my career at Procter and Gamble, which is fast moving consumer goods. Pretty much everything in the supermarket is made by either them or Unilever or Record Bacon, sir. And so a lot of my early career, I didn't really think about domain and didn't think that it mattered.
And then I got a job as a CTO of a AI driven drug discovery company and realized that domain really fucking matters sometimes, particularly if it's complex. And so these, six vectors, I plot out, like this to say that, you know, you can be and don't think too hard about the scale here.
This is a gut feeling, how strong do you feel on a zero to ten or a zero to five on hands on strategy, delivery, org management, commercial, and domain depth. And what you end up with is a little sort of shape or diagram, that tells you, what your current skill set looks like.
And then you can use it in a number of different ways. So in a slightly vulnerable way, I'll show you mine from, when I started that role as the at the AI driven drug discovery company, which is called Helix. And what Helix does is uses AI, largely knowledge graphs and natural language processing to figure out which drugs already exist that could be reused for rare diseases.
I have a rare disease. I've got something called Ehlers Danlos. And when there's a certain level of rarity, it's commercially unviable to invest in drug in new drugs because new drugs cost billions. And so instead, what what Helix does is tries to find drugs that already exist that can be repurposed for for diseases that are out there, but are just not, experienced by enough people to warrant billions in investment.
And when I took this job I'm from an AI background originally, and so I had about I had some proportion. So my skills I have is the blue, the the one behind if you're color blind. And so I had about I had some proportion of the hands on skills that I needed.
And it was back in a much smaller organization, so some hands on skills were still needed from the CTO. I had led much larger teams, much larger organizations, and hugely larger budgets. And so on tech strategy and delivery and org management and commercial, I probably had more than was needed for this particular role.
But then in domain depth, I had very little. And so the role I took needed me to, accelerate my understanding of the domain very significantly and very fast, and needed me to brush up on my hands on AI experience and then add the last ten years of, advancements in order to be useful.
And so one way to use this kind of framework is what I did at the time, which was I drew this for my CEO and said, the mistake you might be making by hiring me, I drew it during the interview process, was that I didn't really understand as much about drug discovery as some other people did.
And it was possible that they could have found somebody who had less of the scale and much more of the domain. But what ended up happening was we agreed that this was an acceptable trade off, that the rest of my skills meant enough.
The fact that I was a rare disease patient myself meant I was gonna care a lot about the domain, and so I was willing to invest a lot of time understanding it. And so my, my onboarding plan kinda wrote itself, if you if you can imagine.
It was all about what what do I need to learn about drug discovery, and a little bit about what do I need to catch up on AI AI wise. And what I ended up doing was making a a pact with the chief science officer who knew everything about drug discovery, but nothing about AI, because it's turns out quite hard to find people who've got both of those things.
And we did what was essentially a skill swap. I taught him a load about AI and technology and how technology was built, and he taught me everything he knew about, well, everything I could absorb that he knew, about drug discovery. When you use this kind of, framework, you can also articulate what roles look like.
So, an engineering role is much more hands on and delivery focused than an architectural role is, for instance. Whereas architects need to understand the domain and the strategy and increasingly the commercial side of things as well. It's very difficult to have buy versus build conversations if you don't understand the money side of that.
If you don't have a feeling for what it costs to have a product team to maintain something, it's very, challenging to make the correct decisions for the for the business. And I've also had some experiences where just different flavors of the same role can be better explained by this kind of shaping or mapping.
Amazon has a concept they called they call software development manager, which looks on the on the surface a lot like an engineering manager role. It looks pretty similar until you realize that SDM is rewarded only for delivery. And so I once hired someone who'd been an SDM at Amazon as an engineering manager, and they failed utterly in the role because they were no good at all at the personal development side of things.
They didn't view their role as helping eight to twelve people achieve their potential. They viewed their role as making sure the team delivers shit on time. And so they were in a much more project management, program management, delivery management kind of, mindset rather than an, what I would call an org management mindset.
And so the way you can use this is you can map your current skill and knowledge and experience, and then assess it against the the roles you have or that you want in future. Kind of a spot the gaps kind of exercise. But one thing that's really important is to remember that it's not Pokemon.
The point is not to catch them all. You don't need to become equally good at each of these vectors. You need to become the right level of good at the vectors that matter for your particular role or for the role that you want next.
And so only focus on a gap or a weakness if it's what I would call a controlling weakness, which is this kind of I think it's an HR term I probably learned at Procter and Gamble back in the stone age. But a a controlling weakness is something that you aren't good at that is essential to perform well in your role.
And one of the examples that often comes up is lots of engineers suck at at public speaking. And for the vast majority of them, that's okay. They don't need to speak in order to do well at their day job. If they wanna become a developer relations person or, they want to start presenting at company all hands or there's some need for them to get good at public speaking.
It's possible that they need to improve at it, but it's not essential. Whereas I'd say, an engineer who can't do testing, that's a pretty controlling weakness. That's gonna make them suck at their job. And so think about for your I'm and I know it's early, but I'm still gonna give you homework.
Think about your current role. How much does it matter that you have the hands on skills, that you have the strategic outlook, that you can deliver, that you can get shit done? How much of your current role is about leading people or managing people?
How much requires commercial understanding? And then how much domain depth do you need to have? And I'm gonna do that awkward thing of stopping for a second and letting you all get your phones out and just take thirty seconds to write that down while I stare awkwardly at you.
And then take another thirty seconds and just write down what do you think the score on the door should be for each of those vectors for the job that you have right now? And then the immediate question that begs is, are you willing to invest in the things that you need to get better at for the job that you have right now?
The one advantage when we still had notebooks was I could see that if people were scribbling or whether they were on Twitter. Now that it's just phones, it's very difficult to figure out. Although I appreciate nobody is on Twitter anymore. Fucking Elon. I mean, at least you don't have to be the same, you know, nationality as the bastard.
Right? Like, as if South Africans didn't have a bad enough reputation in the wider world, now we're responsible for this fucking guy as well. Anyway, hopefully, that's a useful quick insight into whether you're in a role right now where you're willing to invest the energy to get better at the things you need to get better at.
It can also be really helpful to use this to articulate what the role is that you want next. So if you're a senior engineer and you want to become a staff engineer, it's a very different shape than if you want to become an engineering manager or you want to become an architect.
And I'm reliably informed, though I don't have the example on the tip of my tongue, that you can use the the framework for, for other disciplines as well. But if we zoom out for a moment, you can also think about whether this kind of shapes concept can be useful to articulate to people, which vectors matter for which roles.
What kind of shapes do you require? What kind of growth do you enable with the the roles that you have at your organization? If somebody's really, really interested in a organizational management focused role, but you don't have any manager roles coming up anytime soon, then maybe the best thing you can do for them is to guide them to find that role in a different organization.
If there's somebody who desperately wants to do more strategy, that doesn't necessarily have to be a role. That can be a project that that you get them involved in. And so there's different ways to meet these needs and to help somebody to develop depending on, exactly what they're, where they're at and what the opportunities are at your organization.
But there's some common tensions that are maybe worth spending a couple of minutes on. One is, you know, how much a manager is expected to focus on developing and enabling individuals and teams versus ensuring delivery. Making sure that you know and that your managers know which should be the primary focus of their role is really important.
As you've probably picked up from listening to me today, and if you've ever listened to me before, I'm a very strong believer that developing individuals is the primary role of of the manager. And they can help teams run well, and they can help teams be efficient and be productive, but they primarily help people achieve their potential.
If you've got tech leads or, project leads or similar, is that more about depth in the specialism, or is it about leading the team to deliver a solution? How much business understanding is needed? How much user contact is needed? At what point and for which roles does it become essential to understand budgets and understand the commercial side of things?
One of the real benefits you get in being growing up in some other disciplines than engineering is you get lots of commercial understanding really early on. I think engineering is one of the areas where we can we can get really far in our careers without understanding anything about the business in a quite problematic way, actually.
But it does lead me to tell my tell my engineering teams that they don't wanna get promoted because it's just spreadsheets all the way down. Which elements of tech strategy require you to be in-depth still and hands on still? And which elements of any strategy require you to still be, connected.
In tech, we talk a lot about, ivory tower architects. I refer to them as PowerPoint soldiers. If you if your view of architecture is just that you do slides, then, you're probably not a great architect because you need to be connected to what it's really like to build still.
And then is it clear to everybody what the difference is between some of these broader roles? Like, in engineering, that's architecture, staff engineer, principal engineer. There's the equivalent in other, disciplines for, individual contributor roles versus manager roles versus leader roles. But one quite important message today is don't try to make everybody equally generalist.
If you try to make everybody level up at everything, we end up leveling people out towards mediocrity. Takes a lot of energy to go from good to amazing. Takes just as much energy to go from terrible to okay. And so if you have somebody spending a lot of their time and energy and their willpower when they're doing personal development, getting better at something that is optional, that is not a controlling weakness, is not a requirement for the role, then you can end up spending a lot
of energy getting to mediocrity, getting to okay. And I don't think that's worth it. There's a a brilliant book called First Break All the Rules, which I appreciate makes me nerdy that I have a favorite management book, but it is my favorite management book.
And it has twelve questions that predict high performance in teams. And one of them is, I do what I'm best at every day. And I think if you have teams where you get everybody to do the thing they're best at, and that adds up to amazing performance across the team, then that is so much, so much more powerful than trying to get everybody to be okay at everything.
And I think underlying that is one of my most, I suppose, hippie beliefs, which is that every person's capable of virtuosity. I think everybody wakes up in the morning and wants to be good at their job. I think that some assholes exist, but most people don't wake up in the morning going, today, I am aiming for just south of mediocre.
And if I can mess up everybody else's day along the way, my day will be perfect. I think most people wake up in the morning going, I wish I was great at what I did. I would love to be great at what I did.
Why why can't I just do the things that I'm good at? And so let's use this kind of approach to help people understand what they're good at, what they're not, whether it matters for their current role, whether it matters for their future role.
And hopefully, it can be a useful tool for you as you, navigate your own career, but also help some of the people in your team to navigate theirs. Thank you very much. That's all for me this morning.