In today's episode, I am joined by Jason McDonald, Director of Community Development at the OWASP Foundation. Author of "Dead Simple Python” and the brain behind today’s topic. Quantified Tasks.

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Jason C. McDonald

• https://www.linkedin.com/in/codemouse92/
• https://www.quantifiedtasks.org/

Book Recommendations:

• Dead Simple Python by Jason C. McDonald

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

15 - Jason McDonald

Aaron Rackley: [00:00:00] Hey everyone, and welcome to the Tech Leadership Decoded podcast, where through conversations, we unravel the intricacies of leadership in the tech industry. My name is Aaron, and I'm a tech geek here based in London, UK. And in today's episode, I'm joined by Jason McDonald, a Director of Community Development at the OWASP Foundation, author of Dead Simple Python, and the brain behind today's topic, Quantified Tasks.

I really hope you enjoy today's episode, and if you do, Please can you take a moment to like this episode and leave a review on the platform that you're currently listening to it on. It really helps us reach more people like you through that algorithm. And with that, let's get into today's episode. Enjoy.

Okay. And welcome Jason to the podcast. How are we doing? Hi,

Jason C. McDonald: um, I'm doing great.

Aaron Rackley: Um, I'm really excited to have you on. Um, I have been a. In my previous life, I've been a scrum master a lot. So story points, estimating, all that kind of stuff is something that's been ingrained into me at this point. [00:01:00] And when I saw the blog, your blog posts on quantified tasks, I was super excited.

And then I heard you on a podcast a couple of days later. So it was like, it's in the sphere now. So I needed to get you on to have a chat. So before we get straight into it, um, do you want to just give us a five minute overview on you and. Your, your background.

Jason C. McDonald: Absolutely. Yeah. So I have worn many hats over my career.

Um, I think you could say, well, my, my tagline for many years has been author, speaker, hacker, time Lord. Um, because I have, um, I have done a lot of things over my career. I think most significantly I'm a traumatic brain injury survivor, and that gave me a very unusual entrance into the industry. Um, I started out by founding my own open source.

Organization running what turned out to be one of the first [00:02:00] full remote internship programs in the industry gained my skills while teaching others My first full time job in the industry was as a senior engineer So it's an odd Odd way to get in to be sure. It's like getting on a plane from the top of the empire state building.

Um, but along the way I never was really acting just as a traditional software engineer. Um, I was doing a lot of, uh, especially training interns running those projects. Um, And then every other job after that, I wound up in various capacities of, of, um, what I understood later to be business analysis, uh, project management, uh, product strategy, um, of course, good old fashioned software engineering management, um, because I guess.

My primary fascination is not code itself. It has never been code itself. It's actually been psychology. Why do we do the things we do? [00:03:00] Why do we communicate the way we do? And in college I studied communication. So I'm fascinated about how ideas get from one person to another person. Um, and how they change in that process.

That is, that enigma is one of my favorite. Things to ponder and it influences everything. I everything I build everything. I write

Aaron Rackley: Interesting. No, um, I come from a design background in theater and costume and stuff like that So my even my journey into software is a bit odd as well but uh, I I know a friend who wants to do a podcast actually on just talking to developers and leaders and Knowing their beginnings and journeys.

And I find it fascinating. But the question of the hour is what inspired you to develop quantified tasks and what are they?

Jason C. McDonald: So this goes all the way back to when I was first starting out in software engineering, [00:04:00] I was looking for my local library, uh, for books on coding, cause I was brand new to it. And I came across this book called dreaming in code by Scott Rosenberg.

And he chronicles the, the, um. The start and almost up to, but not exactly up to, but almost up to the demise of a project started by Mitch Kapoor, who is famous for creating three to one Lotus, um, he wanted to create something called Chandler, which was a completely revolutionary for the time project information management system that, that.

Broke down the silos between the different objects in the PIM, and he wanted to build it in open source, um, which was still in its infancy at this time. Uh, and Scott Rosenberg was in the same office building, and so he kept going over to the Chandler Foundation, uh, watching what they were doing, asking questions, kind of became their Their scribe, as it were, um, so [00:05:00] it's a very poignant look into everything that works and everything that doesn't work in software engineering, especially the things that go wrong and.

He made some interesting remarks in there about planning, but one of the things that stuck with me was this one line where he says, it is possible in the first few minutes of working on a task for a developer to determine whether or not a task is a black hole by black hole. He meant a task that it doesn't matter how much effort you put into it.

It never gets done. It just sucks up in the ordinance amount of time. And this To a young software engineer fascinated me because this seemed to defy all logic. How could you have a task that never got done? And this started my drive to understand what causes these black holes to form. How can we identify them?

How can we mark them out in our task manager so we know they're there? and that pursuit led [00:06:00] me to start coming up with ways of measuring tasks. Mm-Hmm. quantifiably. Um, when I finally learned about story points a few years into my career, I discovered that I was not the first person to try and quantify things, but perhaps I was the first person to actually

Yeah. Pardon the hubris. I was perhaps one of the first people to do it. Okay. Because the fascinating thing about story points is that it is a little bit like the imperial measurement. Of the foot back in its infancy, the foot was the king's foot. It was the literal king's foot that everything was measured against.

You change kings, you change countries, you change measurement systems. So it was an attempt at standardization, but it was still incredibly relative. And it took actually coming up with a standard measurement. Um, and, uh, you know, around the time [00:07:00] of the French Revolution, the whole thing with, with the standardization of measurements and the scientific community in France and Europe beyond was instrumental in making, um, science and engineering possible.

In the first place. So it's a matter of moving to that.

Aaron Rackley: Okay. So obviously in story point, we'll, we'll come to the comparison of story points in this later. I think everyone has a story point as a frame of reference, but how do we measure quantified tasks? What is the, what are your measurements in it? So

Jason C. McDonald: the three, actually, the interesting thing about quantified test is there's actually eight different measurements, but in terms of estimation itself, there's three key numbers.

Okay. Um, so the first one is distance, and this is maybe the most obvious one. Okay. How [00:08:00] long would it take you to complete this task relative to a development cycle? Whatever's normal for your team. Usually it's your sprint. Um, how long would it take you relative to a development cycle if you knew everything?

That little clause is the key part. That's what makes it objective because It's going to take everyone a different length of time when you factor in differences in experience and skill level and familiarity with code. But when you take all that out of the way, and you just say, if you knew everything you had to learn absolutely nothing at all, how long would this take you?

Reality is people can come to a pretty solid consensus on that. And it's a measurement of raw work. How much of this is just fingers on keyboard? Yeah. The second one is friction, which is what resources exist, um, to help you solve the task. So again, it's something you can observe empirically. How much documentation in there?

How healthy is the code? [00:09:00] How, um, how well known is this, you know, process? What's the precedence on it? Um, Are there subject matter experts we can go pick the brains of easily? Um, the less of that you have, the higher the friction, because the more you're going to have to research things, the more you're going to have to experiment, so the longer it's going to take you and the, but more importantly, the more effort.

It's going to take you because that's the key thing here is we're talking about developer effort more than time because developer effort, if you think about is actually the limiting factor, you, you can have 80 hours available to you to code in a week, but that doesn't mean you're gonna be able to code for 80 hours, your brain's gonna get tired.

That's why we, that's why we don't want to ship on Fridays, not because there's something special about Friday, but because we're just burned out at that point. We're missing obvious things. Um, and then the third one is, kind of goes back to that black hole I mentioned, Relativity, which is, how much [00:10:00] of this do we know versus how much of this do we not know?

How many unknowns are there in this? Some things are very straightforward. Um, You know, we, we need to, we need to add a button to the homepage and it needs to be blue. Well, there's no surprises there. We know how to add a button and we know how to make it blue. Um, yeah, hopefully, hopefully, uh, there's, and that's why the lowest relativity score is a one because it's never, it's never a zero.

There's always a possibility. But, um, then on the other end of it, you have the things that are, um, we know nothing, we know absolutely nothing about them actually. Relativity 5 means you should stop and rethink what you're doing, because if you know nothing, you can't even code at that point. So it's somewhere in that continuum between there's no unknowns that we know of, and there's no knowns that we know of.

You're going to land somewhere in that, uh, 1 to 5 scale. Um. And where you ultimately get [00:11:00] a single number out of out of these three, because each of these is one to five is you add your scores for distance and friction, and then you multiply by relativity. You remember that old agile story point method of make your best guess and multiply by three in terms of time estimates, and that's the rule here.

That's that. That's the same thing, except you're not multiplying by a fixed arbitrary number three, you're multiplying by your level of uncertainty. Yeah, if it's really obvious and there's no no one knows that you know of your estimates probably spot, you know Bang on the dot or darn close But if you don't have any information at all, it's, it's, it's a total swag.

And at that point you might as well just say, eh, eh, ordinarily this looks like it should take about, uh, you know, two weeks worth of effort. Um, but we don't know anything. So three months, you know, and again, I, I know I keep going back to time, but that's, that's what we wind up thinking about often. [00:12:00]

Aaron Rackley: Yeah. I think it's interesting because what drew me to this, um, was.

When I was doing scrum a lot of the time it got so focused on how many story points you could deliver in a sprint and You can fake that to a degree and I think one thing that Interested me about your calculation was that friction aspect because there's a part in that which you mentioned Which is the how much you can actually focus on that work, right?

So whether you're burning out near the end of the week things like that story points doesn't really take that kind of aspect into account so You know, it's like you're just hitting, I don't know, some arbitrary number eight a day, eight a day, eight a day, but you're not thinking that what happens if the developer's getting tired during that day or, you know, things like that.

So that was, that was one aspect that really drew me into it. And, um, and obviously. The kind of unknowns is always a big one, right? [00:13:00] So, yeah, so I'm really interested by that. But, um And

Jason C. McDonald: it's interesting that you bring that up, too, because that is part of what I hope to address with this, because, yeah, you know, you Story points, not all story points are created equal.

If you get eight story points because you completed, uh, four two point tasks. Yeah. That's nowhere near the effort involved in completing one eight point story.

Aaron Rackley: Yeah, that's true. Yeah. How do you find it works for the difference in individual software developers? So, obviously, with story points, you're hoping generally to get to a consensus so that If, depend on who picks up the time is relatively the same in story points delivered, but how does, how does this factor into that?

Jason C. McDonald: Well, there, there's two, there's two, uh, aspects of that. One is I was mentioning earlier, standardization, one of the key parts of this is that this is [00:14:00] repeatable. So, um, Unlike story points, which vary from team to team and project to project, and you can't really compare across, this compares across. So if something scores as an 8 in energy points in quantified tasks in one project, is about the same amount of effort as an 8 in another project with a different team and a different language and a different context.

Um, because you are looking at those things of distance, friction, and relativity. Um, so this allows a developer to form a personal relationship to the numbers. Instead of it being about, well, um, all our developers should get, you know, eight story points a week done. You start to understand what you can deliver and what you can deliver under certain contexts.

For example, when I'm working in Python, which is a language I know very well, I average about 24 story points. Um, and so when it comes to planning, I can know that I'm [00:15:00] taking on a reasonable amount of work for me if I'm aiming for picking up 24 points of work. However, there's that other aspect that not every point is equal, even in this, not, not every point is equal, which is why we preserve those three numbers we get it from because it allows for self selection.

So, and there's two aspects of self selection, um, anyway, one is that a junior developer is not going to want to pick up high friction, high relativity tasks because they're going to need to bring a lot more of their own knowledge to that task. So you can distribute the lower friction tasks to the more junior members of the team.

Uh, open source projects benefit from this in that this automatically becomes what's your low hanging fruit. Yeah, you know, you want to find your low hanging fruit, look for low distance, low friction. There's your low hanging fruit right there, right for the picking. Um, and then the senior level engineers can pick the more challenging work.

Um, [00:16:00] Because you can see what's more challenging, but there's this other aspect where the amount of energy you have and what, what sort of energy you have varies from day to day. Um, you have, um, two hours to code before, uh, before you have to start getting ready for a meeting. Uh, are you gonna want to pick up?

Um, a task that is really simple and straightforward and you can get it done because it's low friction. Or are you gonna want to pick up a really hard task? Obviously you don't want the hard task right now. You gotta go to a meeting or it's friday afternoon and you're exhausted versus it's monday afternoon and you've got nothing on your calendar.

You got this beautiful five hour slot where there's just nothing going on. Now you're gonna go for that high friction task because you have the timing, you're in the right headspace for the additional challenge. So it allows people to select the right work for them within the sprint and within the workday.

Aaron Rackley: Yeah, I think that's really interesting because, like, actually in the [00:17:00] past, obviously, when I was doing a lot more development, yeah, if you wanted to pick up a quick, quick win, you do the one to two story points, right? You try and find the smallest ones. But I think what you're saying there is a lot more interesting, which is like, what do I have the mental capacity to really think about?

Like, can I take on these less ones or am I, do I have the ability to take on a complex one that's short or do I need a less complex one that's short? And I like, I like that. That gives you a lot more kind of flexibility in work you should be doing at that time, rather than just taking the next one and droning for it.

Jason C. McDonald: Right. And it might not even be short. It might just be busy work, you know, you, you could have something that's like, it's, it's low friction, low relativity. It's just, it's just, it's really straightforward, but it's high distance. You're going to need the whole sprint to do this because you're having to, uh, rename all of your tests to use underscores instead of camel case.

Yeah. And that's just, that's a lot of busy work. Well, you know, you can't finish that in one [00:18:00] session, but you can certainly spend 30 minutes on it before a meeting and you can see that.

Aaron Rackley: How do you recommend teams transition to start using quantified tasks? Especially if they're like really already grained into story points, like, where did we start?

Jason C. McDonald: Well, first of all, the nice thing is that energy points from quantified tasks and story points have a lot of similarities from the outside. They cover roughly the same range of numbers. They have roughly the same curve as the modified Fibonacci. Um, you will get numbers that aren't true modified Fibonacci, so Uh, when you adopt this, you will have to tell your team.

We don't care what the number is. We care that the number came from this. That's the important part. So don't, don't twitch. If you get a seven, a seven is valuable information still don't freak out. Um, but beyond that, you use basically the same process as you already do. [00:19:00] The only thing that changes really.

is that your conversation about estimation follows a particular structure. These are things that we already should be talking about if we're using story pointing, but the reality is we don't. The three questions that I brought up one, one for each of the measures. How long would this take? If, uh, how long does it take me if I knew everything?

Relative to the sprint. Again, it's not, it's not, it's not an hour commitment. It's just relative to the sprint. Um, what resources are available to help us complete this task and how much do we know versus how much do we not know? Those are the three big questions. And by going through that list. With your team, um, you can very quickly, and by the way, in practice, this is faster than story point estimation because you're streamlining your conversation.

You can really rapidly narrow in on where [00:20:00] developers may be disagreeing about the estimate. Oh yeah, this is obviously a week of grunt work, but, um. I think it's more. I think I think it's higher friction. Why do you think it's higher friction? Have you seen their documentation lately? It's got major gaps.

Oh, I hadn't looked at the documentation to realize that. Yeah, I agree with you. Okay, conversation goes a lot faster and it's a lot more productive. Once you have come up with those three scores of the one to fives. Um, once you come up with those three scores on your team has consensus on them. Um, Yeah.

You write them down so you can update your task tracker. Many task trackers have custom fields or tags or whatever. You can use that for capture this. And even if you don't have that, stick it up at the top of the description. This is a three friction to relativity one, whatever. And then you apply the formula to it.

So distance plus friction and multiply that sum by relativity. That goes in your story point score box. Okay. And that's it. That is literally the whole thing. [00:21:00] Um, if God help you. You have one of those story point boxes that is a Fibonacci number drop down, then write your actual score in the description and then pick the closest Fibonacci number.

It's still, it still works well enough to get you started. As you use it, you will, in a, in a very agile way, like Agile's supposed to iteratively, you will find. Your team refining how you approach this, uh, you will find some habits of story pointing that you no longer need. You may discover, every time I've used this on has discovered they did not need poker.

Beyond the first day, they're just like, yeah, the poker was a waste of time. It was no longer needed. Um, that may not be the case for everyone. Um, you may make adjustments to your issue tracker. You may adopt other parts of quantified tasks, but you can do that iteratively.

Aaron Rackley: Yeah. I think what's also interesting about that is that if I, [00:22:00] if in whatever software I'm using, Jira, whatever, right.

I had these custom fields for the three values as well as the final one as a tech lead or something like that. I can look through the backlog and see. at a glance, which ones are looking like they're going to have a high friction or So for me to then go and have a look and see why are they, why is that high friction there?

Maybe there's something I can do to reduce that friction later on. And I think that's a really good metric to have. Yes. Which you don't get in story points, right? You just see how it's a seven and then you're like, well, I don't know why it's a seven. You know, there's no context around that

Jason C. McDonald: precisely. And I've seen that a couple of times.

One of the projects I was leading, we had a story that was 12 points. We were looking at that and going, that's a lot of work. Why is it a 12 again? We scored that last month. Why is that a 12? When we looked at what? Oh, because we don't know how this works. Oh, well, we just need a spike. Yeah. And then we'll understand that and that'll lower that.

The other nice thing though, about these custom fields is [00:23:00] that, and I really hope, I really hope this achieves adoption such that the tool makers start actually built baking this into their tools because there's additional things that we could do. With it. One of my favorites is the averages. If you take an average of, say, and all of the averages of all the different metrics are actually useful.

But if you take an average of, say, friction, if you've got a high average friction and you're struggling with your team's velocity. You know, you need to add more senior members. Yeah, right there. Like you, you immediately know that. Okay, we, we are in the weeds. We don't have enough tools for a junior to get their head around this easily.

We need more senior members on the team versus, um, if you're, if you're struggling with velocity and you've got a high distance. It, uh, it just means there's a lot of busy working. You just need more, you just need more, more energy available to you. Literally just need more coding time. That might [00:24:00] mean reducing meetings, um, or, or, or eliminating other distractions.

So your development team can actually just. Have more time hands on keyboard. So you can guide that conversation with the managers. And that's kind of the clever bit about this, where story points lends itself to being misunderstood by managers who really want that, that inherently unit list, meaningless number.

We even say it's meaningless. That's the point. I've heard someone say that. Of course, story points are, are, are meaningless. That's the point of story points. Like, but managers don't understand pointlessness. They want to have a metric. This gives your managers metrics. So when they involve themselves in the conversation, as they inevitably will, instead of them trying to assign an arbitrary meaning that is going to be wrong to your story points and use that to make decisions, there's already meanings there and they're coming in and they're able to see, Oh, you have really high relativity.

Why is your relativity so [00:25:00] high? Well, because our product definition is not very good. Oh, we should have more conversations about what we're building.

Aaron Rackley: Yeah, I think that that's important, right? Is that it gives more context and more information to, to those individuals that are also going to be a factor in your planning, right?

And your project manager is definitely one of them. And Anything that you can do as a team to make sure that you and your product manager on the same language, always help.

And I think this is really exciting for me personally, because I've just done a load of blog posts, but, um, sorry, podcast episodes around like developer mesh, uh, measuring developer productivity and should you shouldn't you and stuff like that. And I think this kind of does it the should and shouldn't at the same time, because it's like, it's, it's.

Story points is like, you shouldn't because it's artificial and it doesn't really give you a good [00:26:00] representation. Whereas this gives you a perfect representation, I think, of areas of improvement, which is what I want to measure for my developers. I want to figure out how I, as a tech leader, can make their lives easier.

And this, this will give me a consistent. set of metrics across all projects across all teams that I can look at and have a good visual aspect and what's going

Jason C. McDonald: on. Yeah. That was one of my goals with this back before, back when I was first coming up with it, you know, something else that, um, dreaming and code mentioned was that it was difficult to measure developer productivity.

Yeah. You know, do we measure in hours? That's a bad idea because then you reward the slowest coder. I do a measure of lines of code. Well, then we never refactor, you know? So it's like a closed issues. Uh, you know, then, then I'm at the joke from Dilbert all those years ago when Wally says, I'm going to go write myself a new minivan.

It's like you, we didn't have a good way of [00:27:00] measuring developer productivity. This becomes a good way. If asterisk, it is the beginning of the conversation and not the end of the conversation because. The important thing is you cannot, and any managers who listen to this need to understand this, you cannot raise a developer's velocity beyond a certain inherent threshold.

Yeah. The human brain actually has, neuroscience has told us that the human brain actually has a maximum capacity of how much it can do. It is based on our metabolism. Each individual is different, but there's only so much you can get out of a brain. Once you reach that threshold, you're done. The brain can do nothing else.

It's tired. It can no longer do that, that, that, that work. And we use so much of that and, and managers have often [00:28:00] thought in terms of, well, you know, we just need to get developers who are willing to work 80 hours a week. You don't want your developers working 80 hours a week, because as soon as your developers are working 80 hours a week, they are, they are spending so much of that time, at least half of that time.

I would argue more than half of that time, um, in a state of mental exhaustion that you are creating low quality code, not because they're bad coders, but because they simply do not have medically cannot write good code at that point. They're tired. So when you're looking at velocity, you're looking at developer energy.

You cannot artificially inflate that. What you want to do is look at the average over time and you want to recognize when that average dips. Recognizing that, you know, it will go up and down. Everybody has good weeks, bad weeks. We'll look at the average over time. And when that average dips, when it's trending down, then your question should be, Why?

What is consuming their energy? And let [00:29:00] that be the start of the conversation on figuring out how to improve their productivity by making more energy. more of their energy available for their use in engineering. Yeah. Um, but you cannot, you, no matter how much money or time or, and, or perks or pizza or whatever you throw at them, they're never going to be able to work past their maximum and that maximum will shift a little bit.

But it'll average out to something. Get to know that average and respect it. Because if you don't respect it, they can and should leave.

Aaron Rackley: No, I think, yeah. It's very rare that you find people that are able to code non stop for that period of time. It happens, but very, very rare. Very,

Jason C. McDonald: very rare. And, and, and even the ones who can do it cannot do it long term.

Aaron Rackley: And When you've [00:30:00] for the places that you've implemented this, what kind of are the first kind of challenges you've come across?

Jason C. McDonald: Usually it's the, the, the number one challenge I run into is, is what I refer to as the religion of Agile. So it's not the methodology of Agile, because Agile is great. Agile is wonderful. I love Agile, but the religion of Agile. Is the idea that it is this, that is the set of, of, of philosophic principles that as long as you adhere to these and, um, and, you know, gold plate a copy of the, of, of your scrum certification, put it on the wall and pray to it three times a day, you will somehow achieve project management nirvana.

Yeah. Does not work that way. And the places that follow the religion of agile are very resistant to this because it runs counter. To this sort of [00:31:00] institutionalized agile mindset, because you're moving away from the magical numbers of the Fibonacci, which are somehow supposed to, you know, align our chakras or whatever, whatever is allegedly special about about the Fibonacci sequence, um, it, it, it.

Changes so much of it from being just meaningless, empty ceremony into actual conversation and as one person put it to me, he said, I don't like this because you know that these numbers shouldn't have any meaning. I don't want them to have any meaning because look at our lovely burndown chart. I publish these.

I am serious. Actually, I actually had to technically tell me I publish our burndown chart. Oh God, online. This is how I market. And I'm just thinking, heaven, help your developers.

Aaron Rackley: God, that's like a race to the bottom. That is don't,

Jason C. McDonald: yeah, don't do that. If you know, if you're, if you're one of [00:32:00] those shops that is inviting your clients to your retros, you're publishing your burndown charts.

You are setting story point objectives for your staff. You're going to get resistance. Because this really runs counter to that nonsense. And I do mean nonsense, but at the same time, that's because this is truly agile. This is putting information back in the hands of the developers so that they can iteratively improve.

But

Aaron Rackley: then on the other side of that, what successes have you had implementing this so

Jason C. McDonald: far? Every time I've, every time I've been able to put this onto a team, what I've heard over and over is where has this been all my life? And the reason for that is because it takes all of the subjectivity out of how do we score?[00:33:00]

Because that's really where a lot of the friction around estimation comes from. Everybody's got their own idea on how to do estimation. And really most of those ideas don't disagree that much. They disagree just enough to be like the, to go back to measurements again, to be, uh, to be like the, um, like, like the, like the U S survey foot and the, and the standard foot it's off by just, just, just enough to be a real pain.

Um, and that creates a lot of. confusion. Um, and so this, this removes this whole question of what do we assign more weight to? And it allows the conversation to focus on what's actually important. And that has been a breath of fresh air for a lot of people. Because it makes scoring actually productive and fun again, when you actually get [00:34:00] information, it's very satisfying.

Aaron Rackley: So I think one more question for this is

in the terms of like small time, sprint stuff like that, it seems to be perfect, but I know that time's relative, but when it, when it comes to planning long term projects, how do you think, how does that work?

Jason C. McDonald: There's actually a separate. Triad of measurements and quantified tasks that relate to that long term planning that I'd like to bring up.

So, the three planning metrics, impact, gravity, and priority, form a sort of funnel. And it allows you to take your backlog and identify priorities. Um, and those, um, those priorities ensure that what makes it into the sprint to be scored is what you need to be working on. [00:35:00] Um, You start at the very top of impact.

So impact is the importance of the item, the work item, whether it's a task or a bug to your overall project goals and more specifically to your users. And I actually go into on, on the website, quantify task. org, actually go into this whole. impact planning process. You can follow, identify your users, prioritize which users do we care about more, you know, because you have certain users that matter more in your product than, than, than others.

It doesn't mean you don't care about the others, but you have priorities. So identifying that at the get go helps. Because then you can say, you know what, this is a blocker for this smaller group of users and it's a major inconvenience for this larger group of users. So this is fairly high priority. You can identify priorities as things come in.

You can identify those in collaboration with your client or your other stakeholders. [00:36:00] Um, once you have those priorities, then the things that matter the most bubble to the surface. Your, your, your priority, your, your, your impact four, impact five things bubble to the surface. From there, you kind of grab the stuff from the top.

Of the impact and you start planning your release around that gravity relates to planning releases. So this is the importance of the work item to the, to the release and the goal of a release, um, all the way from 1, which is it doesn't matter at all. Leave it out. To and actually kind of maps to the to Moscow must have How does it go must have should have could have won't have?

So one is like won't two is would if we had extra time We probably gonna leave it off all the way up to must this is a blocker We don't have a release without this you identify that that gives you a that frames your [00:37:00] release and then from there You can, again, start pulling things into your sprint during your sprint planning and priority is your now next later.

Um, priority five is emergency. Our hair's on fire. Fix this right now. The server room has just been hit by a meteor. Priority four is I'm currently working. Someone's currently working on it. Three is someone needs to pick this up as soon as their work item is done. Two is probably a subsequent sprint.

One is probably a much later sprint. And so you continually rework these numbers sprint after sprint after sprint because they continue to bubble up your priorities and you're not losing this information as you move from sprint to sprint. Um, then you, as you pull things in, this is where the estimation comes in, because as you're doing that sprint planning, you're scoring as you go.

And so, you know, when you're sprint full, because everyone's got a full plate, they know what their capacity is. And so once everyone's [00:38:00] plate is sufficiently full, not too full, not too empty. You have a sprint and

Aaron Rackley: you run with it. So when we're doing the planning for a sprint, do we take each individual's?

Energy points and then obviously the site like look at work that they will pick up based on that and then or is it like you do like a the same kind of thing with story points where you take are usually our sprints are 200 energy points. So we take 200 energy points. Or is it,

Jason C. McDonald: um, you can do either way.

You can do whatever, whichever way works better for your team. But I tend to recommend more towards, um, getting your team's capacity. In terms of potential velocity from the individuals because it does vary, you know, your, your average is, your average is going to fluctuate, you know, Bob's on vacation this week, uh, Laura, uh, Laura is just getting over COVID.

She's still not a hundred percent, but hey, she showed up to the meeting and, uh, you and, uh, Michael [00:39:00] is, uh, losing his mind. He's been in meetings for the last two weeks and he wants to code a lot. And so your capacity looks different than normal. And you want to be able to take that into account. Um, so considering the energy that each of your developers has is going to be beneficial.

And besides that, if you want your manager to do it, you should be doing it yourself. You know, if you want your managers to be thinking about developer energy, then that should be right at the front of your planning.

Aaron Rackley: Yeah. Cause that's interesting. I was just thinking as you were talking there about like, if you were to, if you're focusing on individuals in your team and their energy and you notice that.

Oh, in last two sprints or cycle, John A has dipped a little bit in his energy, maybe I'll go and have a look why, and then you might just realize that he's been picking up very complex friction tasks, right, and then it's not because his [00:40:00] energy's dropped, but it's more to do with the kind of Work he's doing could be the reason and I think that's another interesting thing that story points once again, just wouldn't give you that information Yeah,

Jason C. McDonald: now I do have to do one other warning about planning though.

And that is that we tend to leave some important things off Okay we include Tasks for coding. We don't tend to include tasks for reviewing We don't tend to include tasks for testing. Those need to be separate tickets scored separately because, um, I had one, I had a couple of sprints where the front end lead was averaging what looked like about five energy points, a sprint.

But that's because she was doing all of the code reviews and more than 75 percent of her time was going into those code reviews, but she wasn't getting any velocity credit for it at [00:41:00] all. So you do need to factor that in. And it's helpful when you're, when you're figuring out, um, energy. Um, and it also helps your, it also helps your testing and review because the fact we leave it off the board also means it becomes an afterthought and it becomes an inconvenience like, Oh, but I have all these story points or these energy points to get through and I have to go read your code now, waste of time.

And they're more likely to rubber stamp it. Whereas if it's actually a ticket. It's like, okay, that's a, that's an eight story point job that he's doing and we need a code review. Oh, I can do the code review on that. Okay, that's going to be another six story points. It's on your board. You actually have planned for that.

That will also help improve the accuracy of your estimates because you're factoring, not just in building, but you're factoring in everything else that, that, that has to go along with that, which again, is something else that managers tend to overlook. Why do they overlook it? It's because we don't. put it on the board.

Aaron Rackley: [00:42:00] Actually, yeah, that's that's actually very interesting because in teams that I worked in in the past when you're doing story point estimates of the planning poker is as we say the QA are obviously involved in that and generally you'll come into a consensus around that table what that story point representation of the ticket is including.

Potentially testing KIPA reviews in this, whereas this actually allows you to, if you're separating it and then you do the individual estimating on each, it gives you a clear, clear view on where you're

Jason C. McDonald: going and it ensures the right people are working on it because, because if you factor in testing and review into your estimate and you assign it to, to, to Alice.

But Alice is not the one writing the tests for, for some reason, maybe she's not the one doing the testing or she's not the one doing, well, of course, she's not doing her own code review. Yeah. Um, you know, and you actually have, you know, Jane's doing the code review. Um, well, Jane should have that on her own velocity chart, but it's, it is amazing to me.

I've seen this for years, how [00:43:00] the code reviews will accidentally drop off people's radar because it's not, they don't have a card. They don't realize it's a thing. They forget to check their to do list on GitLab. Of course, we all forget to check the to do list on GitLab, you know, because where do we go to find work?

That's a to do list, look. Yeah, we go to JIRA. That's where we go to find, to find the next step. We go to our task tracker. So if the task is on the task tracker, it gets overlooked and then, Oh, shoot, I'm sorry. Yeah, it's Friday afternoon and I got a meeting with the boss in 10 minutes. But okay, I'll give your, I'll give your code a quick glance.

Oh, shoot. It's 957 lines. Looks good to me. Stamp ship. Whoops.

Aaron Rackley: Awesome. No, I, I'm definitely. Energized by this, by this whole concept. And I, I really want to try and use it. I'm gonna have to try and figure out a way to a team using it. Before I ask you to give us a little look on where you are online and the website and stuff, I'd like to [00:44:00] ask our guests to recommend a book for our audience to put on their shelf and have a read.

And it doesn't have to be a technical book. It can be anything you like. So do you have a book that you would recommend for our.

Jason C. McDonald: I do. I might be biased. It's my own. Um, so, um, I am the author of a dead simple Python. It's published by no starch press. This is if you have cross paths with the Python language.

Um, but maybe you're struggling to get the most out of it, especially if you're coming from another language. Most books out there for Python are written for people who don't have prior coding experience. And that's great, because Python's a great entry level language. But if you know how to code, you don't want to suffer through another 200 page explanation on functions and variables.

You already know how to work. Yeah. So This gives you a really deep, exhaustive tour of the entire language from the perspective of you already know how to code, you're coming from [00:45:00] another language. Um, but most importantly, it doesn't just teach you how to do things in the language. It's not just like, okay, well, you know, you know how to use if statements.

So here's the if statements in python. It's what's the pythonic way to do it? How do you do it? Getting the most out of the language. Why do we do things a certain way in Python versus another language? That's really the focus. And it covers the entire core language. Um, so I definitely recommend, uh, checking it out.

It's, uh, it's about 800 pages, which people laugh when they hear dead, simple 800 pages, but that's because looking backwards, it's, it's not simple looking in, nothing simple looking in, but when you get to the other side of a concept, you look back and go, Oh, it's so simple. That's what I mean by that. So you can find that anywhere.

That's simple.

Aaron Rackley: I'll have to pick that up. Um, because. I, I been, I want more books that are aimed at, I already know how to code. I just want to know why the language does it that [00:46:00] way or what is the pitfalls I'm going to get in that language. Right. So I'll definitely take a look at that. And then where can everyone find your wonderful self online?

Jason C. McDonald: Right. So if you want to learn more about Quantified Tasks, there is a website. You can also subscribe to the newsletter, which I periodically put stuff out on there, uh, that is quantifiedtasks. org. Um, quantified tasks, plural at the specified, uh, dot org. Um, and then if you want to find me, I am ubiquitously known online as Codemouse92, uh, so you can find out more about me.

Um. Find my other books, because I also write fiction books, um, various podcast appearances, conference talks I've given, all that good stuff, at codemouse92. com.

Aaron Rackley: Awesome, I'll make sure they're both in the show notes. But again, thank you for coming on, I'm, as I said, I just Want to try and use this now because [00:47:00] it's it's answered all of the problems that i've ever had with story points Even though i'm a fan of scrum and story points.

It's a it's a weird edge. Um, so yeah, I appreciate you coming on

Jason C. McDonald: Excellent. Thank you so much. And hey, um what you or anyone listening to this if you Use this on your team. Whether you find that, Hey, this works great. Or we came up with this or we changed it this way, or this isn't working. Please, please, please do reach out.

There is contact information at quantifiedtask. org. Um, I want to gather as much information about this, um, being used in the field, um, as I possibly can, because, um, this is agile. This is, we, we improve things through collaboration, through iteration. So please share anything you learn. Um, be very appreciative of it.

Uh,

Aaron Rackley: we'll do. Thank you very much. Thank you.

In today's episode, I'm joined by Michael Tempest, a Senior engineering team lead at Spendesk and creator of thinkasync.xyz/ and together we will be answering that very polarising question. Does remote work… Work?

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Michael Tempest

• https://www.linkedin.com/in/michael-t-60295576/
• https://thinkasync.xyz

Book Recommendations:

• Effective Remote Work: For Yourself, Your Team, and Your Company by Dr James Stanier
• Building a Second Brain: A Proven Method to Organise Your Digital Life and Unlock Your Creative Potential

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hey everyone, and welcome to the Tech Leadership Decoded podcast, where through conversations, we unravel the intricacies of leadership in the tech industry. My name is Aaron, and I'm a tech lead here based in London, UK. And in today's episode, I'm joined by Michael Tempest, senior engineering team lead at SpenDesk and creator of thinkasync.

xyz. And together, we're going to be answering that very polarizing question, does remote work work? I really hope you enjoyed today's episode, and if you do, please can you take a moment to like this episode and review it on the platform you're listening to it on. It really helps us reach more people like you through that algorithm juice.

And with that, let's get into today's episode.

Okay, um, thank you for joining me today, Michael. How are you doing?

Michael Tempest: Yeah, doing really well. Thank you. Um, how about you?

Aaron Rackley: Yeah, not too bad. Um, we've just said before, before we start recording, I've got a few days off work, so it's going to be a nice little relaxing one for me today, hopefully. That's good.

[00:01:00] Fresh day. Um, so before we get into the topic. of remote work, which is actually a topic that I'm really excited to talk about. And I say that a lot on this podcast. I always say I'm really excited to talk about it, but generally remote work is a conversation that is very hot topic for me personally at the moment, because we just had a change at work as well, um, which means more people going back into the office.

Um, so there's been a little bit of debate about that at work before we get into that conversation. Do you want to just take five minutes, let everyone know about you, your background and why you want to talk about today?

Michael Tempest: Yeah, of course. Um, so, so Michael Tempest, um, I'm currently a senior engineering team leader at a company called Spendesk.

Um, I've been in tech for a while. I don't know how many years, like you lose track eventually. Um, going from engineer [00:02:00] to, to like a tech lead and then engineer manager and again, more into the leadership aspect of things. Um, and as the same with everybody else, the pandemic hit. Um, and we all got forced remote.

Uh, as part of that, I started looking into. Because I recognize that remote working was different to being in the office. You can't just take the practices of the office and put them remote and it just work. So I did start doing some light touch, uh, looking in there. And then what actually really spurred it on was once the pandemic lifted, um, I was at home looking after my wife who, um, unfortunately got long COVID, which meant that I was doing a lot of the school runs, looking after the kids.

Like I needed quite a bit of flexibility. And then there were rumors that, you know, people starting to return to the office and they were starting to get these conversations up. So I really want it to prove that remote working could work. And the only way to do that was to really drive it forwards with.

[00:03:00] Um, the team that I was working with, with the people I was working with and really experiment with it and show that this thing can work as long as you've got the right, uh, attitude and, and the ability to experiment a little bit more and get feedback and trust of people. Um, so that's, that's kind of where I started and how I've ended up where I am today, talking from a remote working, but also asynchronous working perspective.

Aaron Rackley: Okay, so. We joked about this on, um, in the channel beforehand when we, uh, introduced it. But yay or nay to remote work?

Michael Tempest: Do you know what? It's a, it's a very easy answer of it depends because it has to be for the individual, for them to decide. Now I like, I prefer the option of hybrid. So you have an option of an office existing.[00:04:00]

But you've also got the option to work remotely because there are some scenarios and some personality types that prefer to be around people, right? People are energized by other people. I'm not one of those people, right? So working remote works quite well for me. Um, but I still go into the office to meet with people, but it's not forced, right?

And I think that's the main thing is it's not that remote is better or worse. It's that it should be an option. To work wherever works best for you as an individual. So that you can give the most to the company.

Aaron Rackley: No, it doesn't make sense. Um, I think you can ask that online and get the most crazy responses in your Twitter feed or your LinkedIn feeds and the arguments that are happening on there are extremely um, polarizing.

So Got that bit out of the way. [00:05:00] Let's talk about how it can work, right? And then how it can't work and then what we can do to evaluate. So what do you see are the key benefits of working remotely compared to working in the office?

Michael Tempest: Uh, the number one key benefit is the flexibility, right? Is it's allowing people to Work in a way that puts and I know a lot of people are going to go, well, that's not the way you should think about things, but puts work second, like to me, life should always come before work, right?

Like, yes, you should be passionate about what you do. You should love what you do. Um, but it's not everything. Right? Life is there to be lived. Therefore, remote work really helps support that. Um, if I take you to, so, you mentioned about some of the comments that you get when like, you see some of these threads.

One thing that I really [00:06:00] hate to see is um, when they have that remote workers and then they show a picture of somebody that's incredibly unhealthy and they're in bed and they're just like lazy in their pyjamas and it's, it's not the reality. It's the reality if you want it to be. Um, but what I find is that remote work actually gives you more ability to do some of those things.

As an example, I've been able to, um, now I work in a fully remote company. I've been able to go to the gym pretty much every single day for the past year. Right. And that is something that remote gives you that ability to do. Anytime I go into the office. It's not quite the same. Yes, you could squeeze it in at lunch, but the travel alone means that you're exhausted.

People love to talk in the office as well. So it's like you, you are also stuck on other people's times. Um, so that's the big one, right? Is the flexibility. Uh, the second [00:07:00] one is, is focus. Yeah. So it gives you that time back to really focus on activities. Now there's a lot of research out there about focus time being such a huge beneficial to actively getting work done rather than spending meeting after meeting, talking about stuff, you act, you have that time to go, this is the time where I actually get the results of that meeting actively done.

You can't do that in the office because there is a constant disruption. There's, there's either meetings, there's conversations, you get pulled into stuff. As an example, when I go into the office, I, I basically say those days are a write off, right? That's for me to socialize with the team, but also talk to people in different teams and build those connections because building connections in remote is a little bit hard.

We'll probably go into that a little bit later. Um, but again, the, the [00:08:00] focus time improvement. Remote working is, is massive, but in order to do that, you have to put in the right practices to make that happen because what happened quite early in the pandemic was everybody went to remote work and they took all of the practices they had in the office with them, which meant that everybody was in meetings all day, every day.

So it's a real, um, effort to pull people out of that and go, you have to increase the focus time and decrease. The amount of time otherwise, you're not getting that benefit from remote working. Yeah,

Aaron Rackley: you know, i'm i'm seeing the same thing um In general as well, with me, my friends, colleagues and stuff that I work with in other places, they're saying the exact same thing, it's like any day you do go in at the moment, it is kind of just like a write off of meetings or just that's the day when everyone can actually see you so they're going to bombard you with the questions, right, because they know you can't run away.[00:09:00]

The, so. When you first transitioned to start having remote work, um, and you started looking at this from a leadership point of view, what kind of things did you see at first wasn't working and you started to try and address first?

Michael Tempest: Um, yeah, so the, the biggest things I saw first was That that mean thing, right?

And people not having focus time. So speaking with engineers, all I would get back was I'm in meetings all day or I'm never get any time to actually doing engineering or, um, it was. A very similar theme, right? So once you realize that that's the feedback, it's then a chance to look at how do we change this?

Right? What is it that is causing all of these meetings to happen? And a lot of it comes down to, um, [00:10:00] some of it is people reactionary and being used to what they The way they used to work, right? If you want something doing, you go and ask, like, Bill at a desk, right? Yeah. Or you just send a message to somebody and expect somebody to respond straight away, or you do it in a, in a meeting.

Whereas we really need to do is focus on how do we give enough information that we can continue doing other things while we wait for that thing to happen, right? Nothing we do should really be an emergency. And if it is, that's where you have stuff like incident process, right? It should be a rarity that you need somebody right then at that moment.

So once I realized that the meeting thing was a real problem with the team, it was then a case of let's put processes in place to reduce that. So the first thing was have a huge review of all of our meetings that we were having as part of like standard agile processes. [00:11:00] What value do they bring us? Okay, that doesn't bring any value.

We took it out. Okay. These two are very similar. We just merge them. Um, and once we got that into a semi decent place, it was then pushing it even further by going, okay, now we have this meeting as an example with, uh, something like refinement, where you would bring some, uh, user stories, refine them.

Everybody would go, yeah, this is great. Let's move on. What we're finding was that we could probably do a fair bit of that asynchronous. So we brought in practices to go put up the ticket or whatever you want to do for refinement. Two, three days before the refinement session. And what you found is that the majority of people then actually refined it before it even got to the session.

So some of those sessions went down from traditionally two hours to 15 minutes, 20 minutes, because so much had already been done up front. Um, [00:12:00] so what you're doing in that scenario is you're reducing the meetings by looking at the value aspect first, and then actually looking at the meeting and going, right, how can I asynchronize this?

So that I spend less time in that zone, um, I can increase my focus time.

Aaron Rackley: So you mentioned there that one of the solutions you were looking at is what you can do to reduce the meetings and looking outside of those work factors. But what, uh, what things do you think you can do during meetings to make them a bit more easier in the remote settings?

Michael Tempest: Hmm. Yeah. So the biggest one is an agenda. Like there's the amount of times I've seen a meeting come through and there's no agenda, there's no outcome. It's just a random title. There's no help to anyone because nobody can prepare for it. The most important thing to get a meeting to be successful [00:13:00] is, is the upfront.

Effort that you put into it. So an agenda and outcome really think about who you need there, but also give people enough information that they can delegate if they need to. So one of the practices that, um, I've started bringing in more is if a meeting doesn't have an agenda, you can pretty much decline it.

Because it means that it's almost saying I've not really put much effort into this. So you just need to show up. And I know that's not the case, right? Like everybody's busy. Everybody's got stuff to do. But if you put that extra effort and that, uh, upfront planning in place. Yeah. It shows a level of respect to other people of I've thought about this.

This is what we're aiming for. On top of that, you should always, um, let's look at two things. So one is you should try and async as much as the meeting [00:14:00] as possible. But the second thing is having a central space to collaborate. So let's go over the async one. First is have a document ready to go, right?

Like if you're going to present slides in a meeting, post them out as part of the message. You know that you're going to use them, let somebody look through them already. Give any documentation that they need beforehand. If you want people to contribute, comment, or give thoughts, give them all the information beforehand, so the meeting could actually be reviewing what everybody's put.

On the other side of that, when we look at the central collaboration, there's so many whiteboarding tools out there now, like the pandemic that shots that stuff in, yeah, like you've got like Miro, Whimsical, um, you've also got like whiteboard on zoom and Slack. So use that in order to give people all the information that they need central.[00:15:00]

Right. You're not excluding anybody. There's nothing worse than if you're remote. And some people are in the office, them using a whiteboard in the office because you can't see it. It doesn't matter how good the camera is. You are excluded because everybody is surrounded by that board. So it's making sure that whatever it is that you're contributing to is centrally available to everybody.

It also helps with audit trail, right? Is you can do it before, during and after. It also makes the meeting a little bit more enjoyable because everybody's involved. Yeah. Um, one of the big learnings that I found from asynchronous working and remote working is you can actively give a chance to those people that struggle to voice themselves in meetings.

Yeah. So as a leader, one of the things I always used to get told was, Oh, the people that are quiet in meetings, you've got to get them to talk more, get them to talk more. And [00:16:00] at the time I thought, Oh yeah, of course, of course you do. Um, but over the years, I've realized that that's not always the right personality type, but you can't force people into that bucket.

So what this does is it gives those people that do struggle to speak out in meetings, um, over like a synchronous meetings, a chance to verbalize their thoughts. Um, so those are like the biggest things I find make a meeting more impactful. Like with the summary being just put the effort in upfront and you will.

Not only have the people attending appreciate it more, but you'll end up with much better outputs. Yeah,

Aaron Rackley: no, 100 percent great. One thing that, um, I have been hearing, um, in the Slack channels and stuff that I'm part of is this idea that they're finding that a lot of people are having, like you say, a lot more meetings since coming remote, [00:17:00] and we were having a chat about this in one of the Channels and what you think about your input on this is like, do you think that's because they haven't thought of they haven't got the other side of the collaboration or work remotely?

Correct. Yeah. So it means that they're not constantly having that kind of like feedback and communication, like maybe teams is not set up well, or they're not using slack or whatever, and which is meaning that they're trying to overcompensate by the amount of meetings they're

Michael Tempest: having. Potentially, um, there could be multiple.

Reasons for it, right? Like the, the big one I've noticed is, is that people don't feel like they can stop and review. Right. They, they believe that the stuff they've put in has always worked and therefore will always work. Um, so that's a big one that I always encourage people to do is. really review the ways that you work, because that will change forever, right?

You will [00:18:00] never get to a point where what you got will always work because team dynamic changes that you get new people in, people leave, you also have different things that you might end up delivering. So just because you're looking after product X like six months ago, doesn't mean you're looking after it now.

So the way you deliver might change. Therefore you should always review that stuff. Um, and it can be that you're so efficient now that you don't need that meeting that was there before. So it's always a case of reviewing those. When you see a lot of people having meeting after meeting after meeting, it's because they haven't either reviewed or they're falling back on the synchronous style of working because that's what they know.

Right. They don't, they've not experimented. They don't give themselves the time to prepare and, and actually have these things thought out in a way that means, [00:19:00] um, okay, today I'm going to spend an hour preparing this. Um, document and this meeting and stuff and then send it out versus I'm just going to book a meeting and we'll talk about it then, right?

You can see why a lot of people prefer the other one because that's the way they've always done it, right? It's easy to book in a meeting and say, we will talk about that thing at this point on that day. Um, so it's, it's about encouraging those practices of don't think that way. First, think about how can you avoid needing to book that meeting in the first place.

Aaron Rackley: Yeah, that makes, makes a lot of sense. Like you say, the key word, I guess, is asynchronous, right? Doing things when you need, like, filling up that time. Um, what kind of tools are you guys using for your full remote daily?

Michael Tempest: So, um, zoom for video [00:20:00] calls, um, slack for communication. Then we have notion as our knowledge base.

Um. And then, and then bits and pieces in between, um, I've used multiple different versions of these things like teams or, um, or Google. And what I've found is it's not the tool specifically. It's how you utilize it because it doesn't matter what tool you do. You can use it incorrectly or use it for the thing that it wasn't really intended, but you've kind of just forced it to work that way.

So as another example is always review the tools you're using and how you're using them. And I don't mean from a company level every single time, but just as a team, right? Like you look at something like Slack, is that the right channel for us to be talking about this? Do we have enough channels? Do we have too, uh, too few?

Um. [00:21:00] Are we using these channels correctly? Like the, the big thing when it comes to communication is for remote work to work. It has to be transparent. Now you can't be transparent with everything, but we know that there's a level of politics. There's also a level of stuff that you just cannot talk about openly all the time.

But you should always default to transparency when it comes to tools like Slack and Teams, where there's open communication, because the more information you give to people. The easier it is for them to align, understand, and deliver on that thing.

Aaron Rackley: Yeah, no, our company just moved from Slack to Teams, uh, literally beginning of this year and it's, it's been, it's been tough just because I just don't think we all know how to use Teams yet effectively.

So there's a lot of miscommunications, a lot of like missed, missed chats and channels and stuff. So yeah, we're in that, that phase at the [00:22:00] moment where we're trying to adjust. Um, to doing that. So like you say, reflecting definitely needs to happen there.

Michael Tempest: Yes. It's, um, I think you also have a similar problem with Slack anyway, right?

Is the larger the company, the more communication you've got, the more likely you are to miss it. And as a leader, it's your responsibility to help people manage that communication load, right? You can, you can manage it to a certain degree within your team of. Okay. We've got too much going on or we're not talking enough, but you won't be able to manage everybody's.

So that's where you work with your team to go, okay, you've missed this message. Why do you think that happened? Right. And then work with them on their method of keeping that stuff up because. Everybody's different how they manage communication. Some people prefer to keep everything until like the end of the day and then go through it.

Some people like to keep on top of it. Like me, I cannot [00:23:00] stand seeing an unread message. Um, but I've got a method which means that I don't have to deal with it straight away. I just have to put it into my notion database to deal with it later, but it at least keeps things clear. Like I say, most of it is people have different ways of dealing with this as a leader.

It's your task to help them improve that on the other side. If you, um, are really passionate about this stuff. Then look at it from a company level, right? And really put in places, um, practices that really help people use these tools effectively. So for example, with teams, it could, it could be that everybody's trying to use it their own way, but there are ways that you can have a trap channel structure, a naming convention, um, best practices that.

I mean, the, the communication isn't one thing after another, right? There's, there's some of those [00:24:00] communications where people will put one word. Hello is the worst in the world, right? Like somebody puts hello and you just thought, what am I supposed to do with this? Um, but there's also like those examples where people go, they, they give you a question and you know that there's more there, but you have to really pull it out of the, if you put standards in place, it doesn't matter what tool you use them.

The communication standards will help those tools actually adopt across the company in a much better way.

Aaron Rackley: Yeah, I think, I think what you're saying is important because when you've, what I've noticed is as you move to remote is that now you're using more tools, if anything, and I think having some structure and rules around, this is my personal opinion, like when to send an email, when it should be a message on Slack or Teams, or when it should be a meeting.

Like, I think even though those levels of. Discussion need to happen because if you've got four [00:25:00] to five, I don't know how many everyone has been, if you have four or five different messaging avenues, you're not going to be keeping on top of them all day, are you? So they, I, in my opinion, I think they have to have some

Michael Tempest: rules around it.

Yes, I completely agree. Um, you, you almost. This is what I was saying about it doesn't matter at all, right? It's how you use it. So there's, there's key things that you have to have when it comes to any type of business is a knowledge base somewhere to actually plan and do the work communication. Um, and that could be video, audio, whatever, but you have to assign like the king.

Of those things so for communication as a company you should go Okay We default to email or we default to slack because otherwise you end up with a message in teams a message in slack a message in email and then somebody will send you a Text message right and before you know it you you're watching all these different channels if you know that you only have Slack to monitor [00:26:00] that makes things so much easier to deal with, because then you could even get to a point where, okay, I'm going to automate all my emails to actually show up in Slack or the opposite way around.

Right. Yeah. Um, but by choosing as a company, your default agreement that this is our knowledge base, this is our communication. You set that standard and it means that even though you've got 15 tools, there's only three that you really care about. Yeah.

Aaron Rackley: As a leader, um, what are some of the common challenges you think you face now that you're managing remote teams and what would you do to overcome

some

Michael Tempest: of them?

I think I've been quite lucky. Um, in, in the people that I've ever worked with, I've always been incredibly remote positive, right? So they've been able to adapt. They've been able to, to move forward with this stuff, really take it by like the horns and just keep charging forwards. [00:27:00] Um, the, the biggest problems that you have.

are more around how do you support them in gaining connections? And how do you also support yourself, right? Like, because you've got to do a bit of self reflection of, wait, how do I build connections remotely? Like that's the biggest challenge. Yeah.

Aaron Rackley: I think that was going to be, that was going to be the next question.

Uh, which is like, um, how do you keep team cohesion, right? How do you build that sense of belonging in a company that. People don't see each other face

Michael Tempest: to face. Yeah, um, it's, it's getting involved, right? There's two ways of getting involved. Um, one is purely social, right? So if there is an office, occasionally show up, start introducing yourself to people.

You know you've got somebody who is the social person in your group. Get them to like, help you, um, connect with other people, go to [00:28:00] the, the Christmas parties or whatever. But as a leader, the real important part is. Organizing those social interactions as a squad, right? Not that that that's a little bit separate to, um, building connections within a company, but building connections as a squad is also really important.

So actually organizing those times to meet face to face. Still focusing on flexibility so that you're not like completely chaos in somebody's calendar, but, and also making those sessions really, really empowered. So I'm not talking about, Oh, we'll meet up and we'll work in an office, right? You meet up to socialize, to understand each other and work with each other.

So those memories that you build last for the next three to six months. On top of that, within a team, you encourage pairing, knowledge sharing, like, you give more delegation to the team to organize themselves. [00:29:00] If you give them that, then they will build their connections internally as a team. Far better than if you were in the office.

Because they'll build their own reports with each other.

Aaron Rackley: Yeah, I think that's important because I think one thing you miss with remote working and conversations is you miss the nuance in how people communicate face to face, right? Your texts, when you're writing text messages, it can be very. Sound very blunt and very rude and and then but you can realize having conversations people They're normally a jokey person.

They always say something in a very jesty way, right and you build that communication that Understanding with each other, but you definitely can lose that

Michael Tempest: With text. Yes, you can That's why Synchronous is still important. I am I want people to understand that the message I try and share is to think async, which is default to asynchronous and then move [00:30:00] across to synchronous.

It doesn't mean that asynchronous is always the way to work. Um, because some of these, I mean, it can end up like you end like a 20, 30 thread message, which would have been solved if somebody had just jumped on a call. Right. And you've got to help people understand those. to almost stop, reflect and go, actually, should we just jump on a call and handle this?

And then you end up with a much more, um, uh, fuller engagement. And that also helps build those connections. So if we go back to the topic of building connections outside of your own team or your squad, um, the other part of doing it, especially in a leader's position is. Get your engineers, uh, your designers, whoever you're leading to work with different teams, work with different people, because what they'll see is not only meet other people, um, and build those connections, but they'll [00:31:00] also see how those other people are working and maybe even adopt that back into your own team or adopt changes into theirs.

But if you build those connections through work, it means that. Eventually you get to a point where those connections have just naturally built themselves. One of the things Spendest does really well, um, uh, twice, cause I've only been there for just about a year, but they've held a hackathon. Um, and the hackathon is incredibly well organized and has a remote aspect as well.

So you don't all have to be. In a physical location, they really support the remote, but that builds huge connections as well because there are people you will work with in those that you can build a connection and continue talking to afterwards. Um, and it's great. And I think more companies need to adopt that level of hackathon for connection building rather than product delivery.

The

Aaron Rackley: other [00:32:00] thing that I think is interesting to have a quick conversation on is like. This work life balance, um, because you mentioned it at the beginning, obviously, the difference back on remote is now that you're working from home more, which means you can do different things, but I think it can also go on the negative side as well, where people can end up working too much, or, you know, or not knowing when to stop, because like for a lot of people, they might not have a spare office in their house, or they can't separate it.

Right. where they're working from the rest of their day. So how, how do you deal with that as a leader?

Michael Tempest: It's, uh, a lot of it is down to routine, right? Is helping people build the routine that works for them and also making sure that you don't celebrate that behavior of overworking, right? Constantly check in with them to make sure. Hold on a minute. You ain't doing too many [00:33:00] hours, are you? Like, we should be focusing on what you deliver, not how many hours you work, right?

Like, you have to be really careful that, um, you keep an eye on people's mental health when they're remote. Because it is harder to see than being in the office. Like, you get all the benefits of, um, work life balance. As long as you keep a very close check on them. There's been multiple times where I've caught myself being sat here until seven, eight o'clock at night.

But then I just take that time somewhere else. And as long as you've got a supportive network and a supportive manager, that's exactly how it should be, right? You, when I talk about flexible working, it should be do what you need to do to deliver whatever it is that you're trying to deliver. Um, but don't push yourself to a point where you're like.

Doing 50, 60, 70 hour weeks. [00:34:00] Yeah. Unless you really want to, right? Like, some people absolutely love it. But, it's definitely not something, um, that a leader should encourage. So, one to ones are key. I've always said that one to ones are the most important thing that a leader can do. And if, as a leader, you are not having them either regularly, they are not the most important thing on your, um, list.

Or they're not that, um, fruitful, then like give up because you're not serving your, your direct reports properly because they've got no avenue to feedback. They've got no, you can't build trust out of that. So like one to ones are the number one most important thing that any leader should have. Um, because you keep people, you can keep an eye on people's mental health, you can understand their feedback and their frustrations.

Um. [00:35:00] And you can, you can make sure that remote work is working for them. Like you said, with the, let's look at some examples of how you can separate your home life to your work life. One is if you, if you are in a position where you're working from your living room or from your kitchen. Make sure that it's in a way that means that you can still separate by either Making a fake commute.

So starting the day by walking out the house and going for a walk or maybe even doing some yoga Something that means that this is my body preparing for my day to start and then the same at the end of the day something to close off the day, right? That could be reading a book, going on a walk. It could be, uh, anything, right?

As long as there's something that you do in the morning and you do in the evening that says, this is my day complete. If you've got a laptop or something like that. [00:36:00] Um, I think most people do now when they're remote working, you close that thing up and you chuck it away, right? That, that should be your representation of.

This is my work and I put it away and I tidied that up and then it's completely gone, right? That's really important that if, if work is in your space, you have to have a way to visibly try and shut it down. Yeah,

Aaron Rackley: no, interesting. Definitely, definitely get a habit of breaking up your beginning and end of your work day.

Definitely. So I want to touch on one more thing before, um, before we end really, because I'm already seeing the time it's getting on nice and long. Um, Why do you think companies are starting to ask everyone to come back

Michael Tempest: now? That is a controversial question

Aaron Rackley: I know there's not

Michael Tempest: a one answer. [00:37:00] Yeah, it's

Aaron Rackley: Interesting thing to ask people. I think at

Michael Tempest: the moment. I don't know I think if I if I get my political brain out of the way a little bit I think that it's similar to what I mentioned earlier around the synchronous working Right. People default to that because that's what they know.

I think people are returning to the office or forcing a mandate to return to office because that's what they know. And the unknown scares them. What I really struggle with is the, the remote versus office, like, debate shouldn't really be the debate. The debate should be, are we able to deliver work no matter where we work from?

And you see so much data one side. Not the other. Yeah. And that makes me feel like it's, well, actually, I, it's [00:38:00] based on feeling that people are t are asking people to return to the office and it's not data driven. Yeah. I think it's based on feeling, it means that it's like, well, I'm scared of that remote thing because I can't keep an eye on people and if I can't see people, then how do I know they're not just watching Netflix all day?

Aaron Rackley: Yeah. No, I think So this, this is where. Um, my visual understanding of it comes from at the moment is the same thing, similar to that is that a lot of companies that I know of that are asking to come back and not really giving a reason and like you say that, that makes you think that maybe there's a fear to it because if they can't tell you that there's a reason for is there productivity drop, you know, is there anything like that?

They can't give you feedback on that. It's probably because they're not measuring it and they don't really know. Um, yeah. So that's, that's really interesting. Um, I think we'll never know, but there's lots of books, right? There's a lot of books, a lot of research on showing it does work [00:39:00] for not every company, but it does work for a vast majority of companies.

So, um, like, like your company and a lot of others that are completely remote first. So we shall see where that goes in a few more years, I think.

Michael Tempest: Yeah, we we've gone past the point now where. Return to office will go for everybody. Um, and I, I have a really strong belief in the community that is around flexible working, right?

That they've changed the way that they've communicated to remove away from remote working and talk about flexible working, because that's the real message is if you can offer somebody to work from. Anywhere that works for them, why wouldn't you? Yeah, right. As long as they're still producing what you expect to be produced, then I don't see the problem.

Um, and I think that's where, that's where a lot of people [00:40:00] need a lot more guidance in how to make the flexible working work. Yeah. Um, and that it isn't, like we mentioned right at the start, it isn't. Taking all the things you've always done. It's about experimentation, feedback, trust, alignment. Um, the biggest thing that can help with, and then it's one of the things that spend desk, um, well, I say one of the things, another thing spend desk does quite well is, is sharing that message.

All the way from the top all the way down right and it keeps that alignment and that's why Remote working can work because everybody's on the same page Everybody knows what they're focused on and everyone knows what they need to deliver Yeah,

Aaron Rackley: and maybe don't put random videos on tiktok show pretending that you're not doing anything all day.

That's yeah

Michael Tempest: Yeah, it's uh But but even then it you've got to um, you've got to [00:41:00] As a CEO, you've gotta balance that stuff out with reality. Yeah. Right. You know, those people are probably doing that too. Like rubbish . Yeah. Like to, to kind of, uh, get a reaction . Um, but you've got to then look at your workforce and go, look, do I actually believe that these people are being like this?

Mm-Hmm. Um, yeah, it's, uh, I just

Aaron Rackley: don't think you can lie with facts. Right. If you know the, the output is there, then you can't argue with it. Can you really? So,

Michael Tempest: no. No. I think, uh, a lot of it comes down to trust. Yeah, you have to trust by default.

Aaron Rackley: Cool. Um, I'm gonna have to wrap it up just because I don't want to waste too much time.

But um, before we go, I like to ask everyone who comes on the podcast to recommend a book and That book doesn't have to be tech related leadership related. It can be anything you like so, you know, desert island kind of This kind of style. Um, [00:42:00] so do you have a recommendation that I can put on my

Michael Tempest: bookshelf?

I do i've got one right on my desk. Um, I mean i've got absolutely tons, right? Um, but Uh, I should really say one of my remote ones, right? But I

Aaron Rackley: I think why don't we do a remote one for the topic of today and then you can have Another one. Yeah.

Michael Tempest: So effective remote work by James Sania. Um, incredible book, incredible guy, right?

Um, but his book is incredibly easy to work with. It gives you so much scope for how to apply those learnings. To your, your team, your company as an individual, right? It's not built specifically for leaders. It's built for everyone to understand how you can effectively work in a remote world. Yeah. Um, that was an absolute life changer for me.

Uh, it really helped me on the start of this journey. And then the other one, um, which is a little bit different is, uh, is building [00:43:00] a second brain by, uh, to go to go for say, um, it's, it's

Aaron Rackley: incredible. She started reading it actually. Um, it was one of my 20, 24. Um, resolutions just to finally sit down and read it and really think about it as a concept.

So yeah, please do

Michael Tempest: explain. Yes, it's um, it's a fantastic way for those people that want to learn the world. But not try and keep it all in your head. I think, uh, over time people have realized that our brain is not there to be a database of all things. And we've got enough technology now that we can build our own database of those things.

But not everything that goes in your head is going to be useful right now, but it could be in the future. Um, so this is part of, uh, I don't, I don't know if it's happening to every leader, but productivity is definitely. Uh, a big key factor for me now of how [00:44:00] to, how to be more productive myself, as well as help others.

And this book really helps you figure that stuff out in a way that you can treat it as a project and, and, and understand productivity, but it also gives you the ability to go to your direct reports and go, how are you note taking, how are you still sorting that stuff? Are you, are you spending too much time on keeping your notes organized?

Versus actively being useful with them. Yeah. Um, so yeah, that one's, uh, that one's a really good, uh, recommendation. Brilliant. No,

Aaron Rackley: I, as I said, I, I've just started reading that one. Let's build a second brain one. So I need to finish that. But, um, where can everyone find you online, my friend?

Michael Tempest: Uh, so you can find me at, um, thinkasync.

xyz. Um, Recently just had a refresh of the website. Uh, thanks to a close friend of mine who, um, [00:45:00] absolute wizard. Um, and then from there, everything else, spiders, um, for, to all the different places, uh, is still early journey, but. Over time, I want to really, uh, give people the tools they need to adopt a better working practice to really make flexible working work for wherever they are.

Aaron Rackley: No, a hundred percent. We'll definitely link all of that in the show notes. But again, it's been a great conversation. Um, this is something I've been wanting to talk about for quite a while, so I've been happy for you to come on and really delve into the topic, and I think it's going to be a polarizing topic for a very long time.

Um, so I'll probably revisit this again in a year's time, and maybe you should come back on and we'll have another chat and see how it's been going, but um

Michael Tempest: Yeah, I'd love to, I'd love to.

Aaron Rackley: But yeah, thank you for coming on, and I appreciate

Michael Tempest: it. Alright, cheers, thank you very much.

In today’s episode, I'm joined by Tobias Mende, a leader, mentor and Tech advisor and together we will be answering the question. Why do we need to stop measuring developer productivity?

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Tobias Mende

• https://www.linkedin.com/in/tobiasmende/
• https://unblocked.engineering/

Book Recommendations:

• Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage in Human Consciousness
• Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations
• Leadership Is Language: The Hidden Power of What You Say and What You Don't

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hey everyone, and welcome to the Tech Leadership Decoded podcast, where through conversations, we unravel the intricacies of leadership in the tech industry. My name is Aaron, and I'm a tech lead here based in London, UK. And in today's episode, I'm joined by Tobias Mender, a leader, mentor, and tech advisor.

And together we'll be answering that question, why do we need to stop measuring developer productivity? I really hope you enjoyed today's episode. And if you do, please, can you take a moment to like this episode and leave a review on the platform you're currently listening to it on. It really helps us reach more people like you interested in tech leadership.

And with that, let's get into today's episode. Enjoy. Okay. Good morning, Tobias, and welcome to the podcast. Hope you're having a great week so far for the audience. I read a, um, sorry, I read a LinkedIn blog post and it was all around. developer productivity and how we measure it or we shouldn't measure it and things like that.

And so I immediately reached out and thankfully [00:01:00] you said you'll come on the podcast and talk about it. But before we get into that, because I'm super excited to talk about it, actually, um, would you just give us a little brief intro about you and how. You know, your career and how this blog post came to be.

Tobias Mende: Yeah, sure. Thank you for inviting me to your podcast, Aaron. I'm very excited to be here. My name is Tobi and I've been working in software engineering for about 20 years now. And I spent over five years as a tech employee in various companies, in remote and hybrid teams. And lately in one developer experience team, which I built up from scratch.

Uh, then that brought me to the topic of developer experience and developer productivity and thinking about how we can, uh, increase the engineering excellence and happiness. And today I'm working as a coaching consultant for software companies and as their partner for those topics. [00:02:00]

Aaron Rackley: Awesome. Cool. Um, so I know that the, the blog post is split into two parts.

So what I thought we'd do is we'd start with part one and you've got some good headlines. So I thought the headlines could just basically be the questions. What do you think is? First of all, high level, what do you think is wrong with measuring developer productivity?

Tobias Mende: So, um, actually that goes back already, um, 20 years, I think.

Um, um, when, um, Martin Fowler wrote that, uh, you cannot measure developer productivity because. You, um, cannot measure output and that's kind of the issue because what is engineering output, um, you might think, okay, but it's code, uh, maybe because engineers produce code, but then on the other hand, is that really valuable?

And, uh, [00:03:00] today we know code isn't an asset, right? Code is a liability. So producing a lot of code is not, uh, not a quality of a great engineer. And, um, that, that means we cannot measure output just by the amount of code, but we need to measure it by business value. So how do you measure business value then?

And that's something we can also not measure in the moment we are creating a feature, for example, because when we are creating a feature, we are not knowing yet how long will this feature be in production? How many customers will it attract? What will customers pay for it? And also the other side, how much bugs do we have because of that?

How much incidents, how much maintenance effort does this feature cost us? So the output is something we can maybe estimate or probably more likely guess. And because we cannot measure the output, everything else to measure developer productivity is in my opinion, based the time, uh, [00:04:00] because we are only measuring some, some, uh, meta or some, um, proxy metrics that, um, can.

Help us to understand, okay, how often do we deploy to production and these kind of things, which are valuable, but in the end, it's not about developer productivity. It's about, um, our flow and developer flow. And this is something that's more interesting to measure, but it doesn't give us any idea about productivity in the end.

Aaron Rackley: And you mentioned in your blog post, uh, the, the title of the section was the lie about sales productivity, which I thought was interesting. So do you want to explain that concept?

Tobias Mende: Yes. Uh, so the, the reason why people are looking for to measure developer productivity, I think is because they assume they can measure productivity in other areas, for example, sales.

And it sounds logical, right? Um, a deal closed, that's, that's productivity because then we have a [00:05:00] client and that's, that's the output of a sales team. But when we think about it more closely, then that isn't the end of the story. It's just the beginning. Once we have the client, the question is how long will this client stay?

How happy are they with our product? Will they recommend the product? Or will they demand a lot of other features that we still need to build in order to keep this client happy? and so also um, just having a lot of sales and attracting a lot of clients can be Negatively affecting productivity and the the business value when those clients are not the right clients when those clients just close deals because they have a promise some feature that isn't in existence yet that That engineering hasn't built yet, then that creates pressure on the engineering department to build that feature.

And thus, this means that they need to prioritize that. This means that they take shortcuts that they don't finish what they actually think should be built based on a product, um, uh, management. [00:06:00] And then a client can actually be something that you don't want to have. So. Uh, just having, just closing clients and just closing deals with, uh, annual, annual recurring revenue of X doesn't mean that this is also, uh, the value for the company.

There are other things involved in this makes measuring sales productivity in the big picture, in my opinion, a lot more complicated than just by these numbers.

Aaron Rackley: Awesome. And I think you, you give some other examples of other departments, like a HR, um, just hiring the wrong people because they're just trying to fill quotas as another example.

And then I think the best quote out that whole section was the one you've got, God heart law. So when a measure becomes a target, it ceases to be a good measure. I think that's very, very good one. And I liked that a lot. So you said we shouldn't measure it, but I guess, um. Well, I, I'm assuming that we have to measure something, right?

So, [00:07:00] um, cause again, naivety, I've come from, it's a lot of places of sprint scrum agile, and that's how they're measuring it, right? Do you have this traditional kind of, um, you're measuring your story points or you're measuring your releases and things like that. So what. What do you think we should be doing instead or yeah,

Tobias Mende: yes, uh, of course.

So one thing that I believe is, uh, the, um, measures such as 30 points or deployments made or so, uh, and also the Dora metrics. Uh, lagging indicators in, in, in a sense. So, uh, when, when those go down, then you can look into it and see, okay, why does this happen? Do we have a problem here? They, they are indicators for that, but they don't tell you much about the productivity because maybe the team just changed how they work.

Uh, on the other hand, what I find quite valuable is to think about developer experience and how we can manage developer experience. So how [00:08:00] can we measure how enjoyable it is for engineers to work in the system? How much flow do they have? How much feedback do they get? And these kinds of things we can measure.

First of all, we can measure those using surveys, not like this hard data that we get from our systems. Like, okay, you have 10 commits per day and you have, uh, every engineer creates an average of thousand lines of codes per week or something. But more like, um, we can ask engineers in the end, how do they feel about their productivity?

How do they feel about their excellence? What is blocking them, where do they feel that they are wasting most of the time and that gives us a picture of where do people think there is an improvement opportunity and when we improve those bottlenecks and we remove those bottlenecks. Then that eventually also increases the productivity.

So without even measuring productivity, we can still improve the productivity by listening to [00:09:00] engineers.

Aaron Rackley: Yeah, it makes sense. I think, um, one of the things I learned when I transitioned from an individual contributor into a leadership role was that you do start looking at. Um, measuring differently. So as an individual contributor, I'm just looking at have I got my task over?

Have I done it in the time that I said I'd do it? That kind of stuff. Whereas like what you alluded to there is as a team leader, you start looking at it more holistically, globally, and kind of what are the areas of. Productivity and where are we slowing down, speeding up what areas, because like you say, every developer is individual and they can, they all have their own quirks and individualism that makes them either faster in one area or slower in the other area.

But the one thing that we all have in common is generally like the tool chain that we're doing, the product that we're working on, that's all very similar. So I think what you said there about [00:10:00] looking into listening, sorry, to what developers are saying is, you know, their, their pain points is definitely an interesting thing.

And I've always found that generally, and this is from me personally, I've generally found that it normally is like a tooling issue that normally is the, the slowing down for a lot of things for me. It's like, um. I'm not able to test properly because of this, I'm not able to deploy fast enough because of this.

And, um, I generally find it rare that a coder goes, I couldn't code fast enough because my hand didn't type quick enough. So, or like you say, it becomes a lack of documentation. So I think, yeah, um, definitely looking into these, um, kind of stuff. So,

Tobias Mende: yeah, go on. You mentioned, you mentioned another important thing there, um, also, I think.

That it's not about individual performance in this case, this is, we are so used to think about individual performance historically from, from management, but this is actually [00:11:00] not what software engineering is of engineering is steam effort. And in the end, the team performance matters. So we cannot, like when we measure by code output, for example, it might be that an engineer doesn't output any code because they are more in a navigator position in a pair programming or team programming session because they are more experienced and distribute their knowledge to other team members.

Then their productivity in that metric, uh, is low and measuring the productivity by such a metric would then lead these engineers to not do that anymore, but to code more themselves in isolation. And this is. It's actually the opposite from what you want. So this is a good example of contrast law in an effect that it, uh, turns people into the wrong direction.

Aaron Rackley: So in your, um, first blog post as well, you mentioned something called a Dora metrics or space framework. Do you want to. Explain a little bit about

Tobias Mende: that. Yeah, I think the, um, the Dora [00:12:00] metrics, uh, pretty well known, um, uh, probably because they are there since the, I think accelerate, since the book accelerate came out, they gained a lot of popularity.

They are deployment frequency. Lead time for changes, change failure rate, and time to restore. And, um, they are, um, they are DevOps metrics. So DORA stands for DevOps Research and Assessment. So, uh, they are metrics how well a team is doing in terms of, uh, continuous deployment or deployments in general. Uh, how much defects do they introduce, how quickly they can restore their services, and these kind of things.

Uh, these are, well, they are labeled, I think, developer productivity metrics. And I think that's also as close as we, as we get to a developer productivity there. But I think it's in the end, it's not developer productivity. It's just a proxy metric that can make sense for a team to measure, but I don't think it makes sense for others to measure them [00:13:00] globally for all the teams and then compare teams by those.

So they can give a team insights in their own productivity. So as a team, we can decide we would like to measure those metrics and then reflect on, do we like what we see, or do we think we can do better there? Um, so that's, that's Dora. The space framework, um, is a framework that spans five dimensions, uh, and every letter stands for, stands for one.

So, um, the S is for example, satisfaction and well being and the space framework. Is, um, is, uh, was introduced by Nicole Fosgreen and others, uh, a while ago to, um, show people what kind of dimensions to think about when they think about developer productivity. Uh, and it's also relevant for developer experience because what they said, and a lot of research is backing this, that satisfaction and well being.

It's one of the most important factors when we want to achieve developer productivity. And coincidentally, it's [00:14:00] also one of the most important factors when we want to achieve high developer experience. It's not a surprise that people who feel, um, well in their job and, um, are satisfied with their work and have a purpose in their work and understand why they are doing what they are doing and are not blocked by too many bureaucracy and policies and, uh, other teams.

Are just more productive and also more happy in their work. So the space framework, um, I'm not sure if you want to go into detail there, but, uh, it, yeah, it spans these five dimensions and, um, that can be used. Uh, and I like to use it, for example, when thinking about developer experience, uh, surveys, when I create them for clients, the space framework gives me like guidance, not just to go into one.

Uh, into one of the dimensions too much because, for example, the A is activity in space and, uh, many people tend to go a lot into activity [00:15:00] or in, in some performance metrics, but they don't go into a satisfaction of well being or collaboration communication, which would be the seat in space. So, uh, having the space framework, uh, can help leaders to, um, ask better questions when they think about service.

Aaron Rackley: Okay. So there's a lot, a lot to, um, digest there. So we've got the Dora, which I've got them up because I ain't going to remember him, like you said, but you've got developer frequency, lead time, change failure rate, time to restore that kind of stuff. And then we have the space, which tell me if I'm getting this wrong.

Cause I, I'm not looking it up correctly, but satisfaction, performance activity, communication, efficiency. So that's a lot of metrics. Can too many metrics be a burden?

Tobias Mende: Yeah. So the space framework, um, those are not metrics, but dimensions and [00:16:00] you can measure every dimension. Um, with multiple metrics or none at all, uh, defense, for example, satisfaction of well being, we can measure by, by asking questions in the survey, right?

Activity, there are a lot of things you could measure there. And there are metrics that might fall in there that, um, that don't actually make sense. For example, I could measure how many commits are made, but maybe that's not an irrelevant metric for activity. Um, that's good to measure. So it's really the space framework.

I would see as something to us to support a discussion around what's important for us to measure. And so that we cover all of those five, um, dimensions and get a good insight into the developer productivity and experience in our teams and. Uh, then, for example, the answer can also be, we have a, we have a, um, a survey, uh, that backs most of those dimensions in, in that survey.

So we don't need a [00:17:00] lot of metrics to measure because, um, of course, when we have a lot of metrics to measure. Then, um, we also need to make sure, okay, how do we make sense of all of that? How do we put that all together, uh, when this metric goes up, but another metric goes down? Is that good? Is that bad? Or does it depend on something else?

So, uh, I, and like also in the past, I don't really have seen that metrics. It's created a lot of value and clarity for most engineering teams, because teams very much know where they lose time, what frustrates them, what, what their bottleneck is. For example, do they have a lot of incidents or do they have flaky tests that always interrupt them?

Or do they have too many meetings? The teams know, so the question is if they already know, and we can figure that out with the teams together, then do we really need a metric to prove that once we remove those bottlenecks, it gets back better? Or can we [00:18:00] just ask the team again how they now feel about their work?

And most of the time. I find that this gives us much more, uh, insights and much, uh, clearer picture than looking at all those metrics because they go up and down and there's, there's some noise in there. People go on vacation and the deployments go down. People come back and the deployments go up. All these kinds of things.

It's a lot of data and a lot of noise. And in the end we are thinking, okay. What does this metric tell us? Probably it's going fine. Oh no, maybe it's going up down a bit too much. So maybe we have a problem here. Not sure yet. And then what are you doing then? Of course, you're asking the team, uh, how it feels.

You look into the retrospective and see what, what are the topics that are coming up, this kind of. These kind of things. So I personally won't spend too much time on finding the right metrics to measure. I would straight ask the teams. Okay.

Aaron Rackley: Yeah, no, that's super, super [00:19:00] interesting because yeah, I, I'm a big believer in retros and having conversations with team to figure out what's going on.

But obviously you don't have to wait for a predefined, um, time slot to do that. Um, what kind of. Do you, have you found, um, developers are giving you feedback on and which ones of them do you think are harder to solve than others?

Tobias Mende: So, um, of course a lot, uh, some of those that are easier to fix are usually like, oh, this build takes too long.

Or this, these tests are too flaky, um, like the technical things are usually the ones that you can fix more easily, because then you go dive into the build and find out where the issue is, why it is slow, what you can do about this, then you, then you fix it. And that can have a huge boost in productivity.

Uh, and also of course, satisfaction, some things that are more difficult to change is [00:20:00] of course, when we come to organizational structures, for example, when you have Uh, different departments and you have the engineering teams in one, and then you have an operations team because you are still not understanding how to do DevOps.

Uh, and then, uh, the, uh, engineering teams hand over their deployments to the operations teams in, in a meeting, uh, once a week or twice a week or every two weeks. Uh, just for the operations team to run those deployments and operate the system. And of course, that's frustrating for engineers because they cannot move to faster deployments.

They always have blocked by another team before they get feedback from production. And, uh, they need another meeting to hand over this deployment, this artifact to another team. And this is of course, something that's super frustrating, that's slowing teams down a lot. And has a huge impact, uh, and changing that of course involves at least two teams, sometimes even different managers, and, uh, sometimes [00:21:00] even two areas of an organization in the worst case.

And you need to get everybody on board to understand why this is a problem and what we could do instead, for example, developing the operations team more into a platform team that provides safe service capabilities for doing deployments and doing the monitoring and so on. So that they provide the infrastructure and the support, um, to, to learn about those, but that they don't do the actual deployments.

And then we can remove the bottleneck, right? Then we increase the flow of the engineering team. So. Uh, in the end, the goal is, um, also their team to politics come into play. The goal is that, um, an engineering team, our product team can, can own a value stream or a slice of a value stream from the customer idea to, uh, delivering the artifact to the customer without any dependencies.

Uh, on other teams where we need to wait for other teams, because this is, this is frustrating, but, uh, fixing that and [00:22:00] changing the team structures and how they interact with each other, that's a lot more difficult because that there, we are not only dealing with code and CI pipelines, but we are dealing with humans, human relationships, team structures, sometimes also responsibilities and, uh, like how many teams belong to a manager.

So there's also personal interest involved. Okay. Uh, that makes it,

Aaron Rackley: yeah, no, it makes total sense. Um, so we've identified that we have problems. We just identified those metrics that we should or shouldn't be using. Um, and we know that ultimately it comes down to shaping the environment where the engineers, uh, I think the phrase you might have used was something like, um, outstanding experience, um, and outstanding work.

So they have the perfect place for them to work and produce what they need to work. Um, So you are a agile coach. Is that a technical agile coach? [00:23:00] Is that correct? Um,

Tobias Mende: I'm a little bit of everything. I'm, I'm, I'm a technical coach, uh, for address of the teams. Um, I'm also a consultant, um, around technical and engineering leadership and, uh,

Aaron Rackley: So if I was to hire in a technical agile coach to help with this, what would be?

The kind of things they would be looking at doing, because I know that on your blog post, you link to a developer experience assessment, I think that you do. So maybe you could talk about what that is.

Tobias Mende: Yes. So what I realized when talking to companies is that of course, everybody's now measuring Dora metrics.

Unfortunately, our tools made this really, really easy, but what it's far more difficult for people is to. Uh, develop surveys to understand the developer experience of their teams and, um, to make sense of the data they get. So, um, [00:24:00] when, when you develop and run a survey, of course you have different challenges first, understand what kind of questions should I ask?

Because I can just not ask everything. Otherwise nobody will answer the survey because it takes two hours to answer all the questions. And then once you have the survey, you need to get it out. to everybody, um, to the target audience, like all the engineers and maybe other people in the product area to get feedback.

And then you have the question, is there a lot of engagement with the survey? Otherwise the data would not be relevant. And the developer experience assessment is, uh, my service that helps companies to do exactly this. So first of all, it starts with the briefing with one of the leaders of the company who wants to have that for their area and we understand, okay, what.

What kind of, um, uh, topics could be interesting, but, um, I'm not only, um, listening to the leader, but I also talk to four people in the organization to understand what they, what they see, like different perspectives on, [00:25:00] on the engineering organization of certain people. And then finally, with all that knowledge and my own expertise, of course, I will create a survey that is tailored to the organization.

And then, uh, executed with them inside of the organization and create a report of the results and my suggestions. So this also should help with, uh, selling developer experience improvement initiatives to non technical folks, because also something that I noticed is that, uh, engineers and sometimes also tech leads are very good at understanding the technical issues and solving them.

But they are sometimes struggling with, uh, communicating them to non technical people that in the end make the decision. So sometimes you have a non technical manager who then thinks, yeah, but why should we do this? We have business priorities, we have this feature and we assume this feature gives us revenue X.

So, um, then the question is how does this developer experience initiative fits in? And quite often that's then why those initiatives, uh, do not happen or are [00:26:00] deprived forever. Uh, because. Uh, engineers cannot make a valid business case out of those. And that's kind of where my assessment also helps to, to show how does that impact the productivity?

How much time do we waste? How much does it affect the frustration of engineers? And maybe what are the most important things that we can first address? And of course, then if there is desire by the client, I'm moving in with them into a long term partnership to have that teams to remove those bottlenecks.

Um, To train the people on what we found out that is missing. So that's then the next step. But the first step is knowing what, what the issues are and then I move in. Um, you also ask about the technical coach and what, what they should do. Is that right? Yeah. I would say it depends a bit on what kind of technical coach you are looking for.

So what I, what I do with clients when [00:27:00] I work as a technical coach with teams is that I'm collaborating with them a lot and pairing with them on their day to day work challenges to also see where do they struggle to, is it about unsure that they are unsure how to test a certain thing, or is it that they again have some issues with CICD, for example, that I observed that builds take very long or that They have a very complicated branching model or that there is some power dynamics within the team that influences their collaboration so that there's, um, that are people not speaking up or just sitting there quiet and collaboration and also meeting.

So it's a mixture of technical coaching on, on, on the coding on architecture, design, testing, automation, all these kinds of things. Uh, and on top of that is also of course the HRI software perspective and. To me, it means I'm asking a lot of questions, sometimes unpleasant questions, like, why do you estimate story points, or, [00:28:00] um, why do you do dailies, uh, which doesn't mean that I say nobody should ever do dailies, but it means have you thought about why you are doing them and what the value for you is.

And, um, so, yeah, I'm observing them kind of, um, and work with them. Uh, as an external kind of technical lead, uh, looking into the factors that, uh, improve their technical excellence, but also of course, without looking into the factors that improve satisfaction, happiness. And with that, then also again, retention of engineers.

So these are kind of the topics that I would cover there. So, um, and general, uh, for a technical coach, I would, um, check with them. If they have the experience that, that we need in the organization. So if, if they know the tech stack or at least, um, have seen a lot of tech stacks that they can, that they can, um, support valuable insights and outside perspective.

And, uh, ask, uh, [00:29:00] interesting and thought provoking questions for the engineering team. And then of course, um, yeah, it's more also, uh, do I like this person? Uh, and, uh, do I think I can trust this person? Does this person fit in from how they work, how, how, um, the attitude. So this is very helpful. And of course also have they worked on similar projects, for example, if I have.

technically agile coach who always only worked on iOS apps in the past with teams. They might not be the right technical coach for a team that's working on a backend infrastructure or software as a service product, because challenges there are a lot different, of course.

Aaron Rackley: Yeah, no, I think, um, as a technical leader myself, it's definitely giving me a lot of forethought because again, like everything is.

Companies, like you say, are obsessed with metric driven reporting. And, um, I think you as a technical [00:30:00] leader can kind of slip into that behavior. And what you're saying to me today really makes total sense of like how we, as leadership for the technical, forget the business as a whole for a moment, but as a technical leadership, we should definitely be looking at how we can make our teams better.

Um, and I don't mean better in a negative sense, right? I mean, just everyone's happier. Everyone's more productive. Everyone's just working towards the same goal, right? So what I will 100 percent do is I will share the link to your. Unblock. engineering website, because the blog posts on there, there's just so many of them and they're all great for getting deep diving into all this information and we wouldn't have enough time in a blog, in a podcast to go through all of this stuff that you've got, but, um, on your website, I noticed that you are looking like you, you obviously offer services you offered.

Potentially workshops and talks and things like that. So I'm definitely going to try and sign [00:31:00] up to one of these workshops, come and come and learn something. Um, do you want to just, uh, tell everyone about the unblocked engineering website a little bit more and what that is?

Tobias Mende: Yes, sure. Um, so unblocked engineering is the business that I started, uh, basically beginning of this year, um, before that I was working as a software engineer and tech lead as a freelancer, but the unblocked engineering came from.

Uh, my realization that there is a need for, um, for coaching, mentoring, consulting, and training around, uh, technical excellence, uh, and that, uh, involves the developer experience and developing productivity topic, which is very close to my heart, of course, but it involves everything else from day to day work of engineering teams, uh, up to software architecture, team structure, technical leadership.

And, um, I finally bundled all of this together in. Uh, a package that's called the excellence and happiness partnership. Uh, and this [00:32:00] package kind of is my offer for any engineering team, uh, in software companies between 15 to 70 people in product and engineering that, uh, want a partner at their site to improve their technical excellence, their engineering excellence, and the happiness of the engineering team.

And that's kind of a long term engagement with me as a partner for all those topics and everything we talked about and of course, much more. Um, yeah, if that's interesting, you can look it up too.

Aaron Rackley: Yeah, no, I'm pretty sure there will definitely be people here listening going, I need to go and find that out.

Um, now, um, Obviously we could go on about this for ages, and, um, I highly recommend everyone to go and read the blog post that obviously brought me to you, which is why we need to stop measuring developer productivity, and it's split into two parts, but I think you have a longer form version of it on your sub stack as well.

Um, [00:33:00] so I'll, I'll link to both of those and then if they've got any questions, come and speak to them. So one thing I ask all my guests that come on to the channel, uh, is to recommend a book and the book doesn't have to be technical, doesn't have to be, it can be your childhood favorite story. It could be anything, but some people give a couple, so feel free to do that as well.

But basically on my podcast website, I have a bookshelf and all the books go on there. So.

Tobias Mende: Okay. So, um, then the first book, uh, that I would like to recommend is, uh, reinventing organizations from Frederick Lallou. Uh, it's about organizational design and, um, uh, like stages of organizational development. And for everybody who only knows classical hierarchical companies, that can be very eyeopening to see what other companies are there, how [00:34:00] they can work.

For example, hierarchical management and leadership. And for me, it was just, um, very eyeopening to see, uh, how that can be possible. I worked in a company that partially. Um, used some of those ideas as well, for example, um, decision making process that was very, very great because it involved everybody and allowed everybody to bring in their attentions and propose a change to the organization.

And so that's a really cool book and it's really very written. I can highly recommend that. And of course, then, um, because you already mentioned that the accelerate book is still, still really a great book to read, um, on, um, uh, DevOps basically, but also, uh, it's interesting for everybody who was in software engineering and things, how can we develop a better software faster?

So, um, it's cool. And it's backed on with a lot of research. So. That's another good book I can recommend. [00:35:00] Awesome. And I can, can go on if you like.

Aaron Rackley: I'll tell you what, give us one more, one more. Let's do it.

Tobias Mende: One more. Okay. Then I need to choose which one I chose. Um, okay. Maybe, um, let's, uh, Oh yeah. Let's, uh, uh, take this one because it's also a leadership podcast.

So leadership as language by, um, David Marquette is about how, how we can lead and how, what we say and what we don't say influences. Uh, our way of leading teams. So it's really cool and I really love his story. He is, um, he is, or he was the captain of a US submarine. And, um, quite a hierarchical, um, organization, you would say, and he also wrote another book, an earlier one, Turn the Ship Around, which is quite popular, where he moved from this classical command and [00:36:00] control kind of leadership to a more intent based leadership approach.

So both of those two books, I can definitely recommend.

Aaron Rackley: Okay, perfect. I've written them down. They'll go on the bookshelf. Awesome. Now, um, before you go, um, could you give everyone a little rundown of where to find you online? Um, you know, social website, et cetera.

Tobias Mende: Sure. Um, uh, obviously, uh, unblocked dot engineering is, uh, the, my website.

So there you can find me. Uh, and of course also on LinkedIn, it's Tobias Mender. Um, maybe we can also link it. Um, those are the most popular channels where you can get in touch with me. Kind of immediately. Awesome.

Aaron Rackley: Perfect. Well, I really appreciate you coming online to talk about this subject matter. It's something I'm really now obsessed with and I need to go away and read a lot more.

And I'm definitely going to add all those books to my, uh, to my Amazon [00:37:00] and get them ordered. Um, yeah, so really appreciate it. And, um, hope to speak to you again soon. Yeah.

Tobias Mende: Thank you for having me. It was, was a lot of fun and really enjoyed being on this podcast.

​

In today’s episode, I am joined by Lena Reinhard, a Leadership & Executive Coach, Mentor, Organizational Development Consultant, Advisor, Speaker & we are answering the question What engineering metrics should I use as a leader?

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Lena Reinhard

• LenaReinhart.com
• https://www.linkedin.com/in/lenareinhard/

Book Recommendations:

• Into the Planet: My Life as a Cave Diver by Jill Heinerth

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hey everyone, and welcome to the Tech Leadership Decoded podcast, where through conversations, we unravel the intricacies of leadership in the tech industry. My name is Aaron, a tech lead here in London, UK. And in today's episode, I'm joined by Lina Reinhardt, a leader and executive coach, mentor, organization development consultant, advisor, and speaker.

And we are answering that question, what engineering metrics should I use as a leader? I really hope you enjoy today's episode. And if you do. Please, can you take a moment to like this episode and leave a review on the platform you're listening on? It will really help us reach more people like you. And with that, let's get into today's episode.

Okay, and welcome to our podcast, Lina. How are you today?

Lena Reinhard: I'm good, and thank you for having me. Brilliant.

Aaron Rackley: And with the start of 2024, I've got a couple of podcasts coming up, including your one, which is all about kind of like looking at the year moving forward, how to think about yourself as an individual leader, like goal [00:01:00] planning, you know, thinking about your team on what metrics and all this kind of stuff as like a, a fresh new year, new beginning.

And I was reading a blog post that you obviously wrote called what engineering metrics should I use a guide for engineering managers, directors And I wanted to get you on to obviously Have a quick chat about as a new leader, who's in the role, what kind of engineering metrics I should be looking at, or what kind of things can I do to keep an eye on my team, essentially.

But before that, why don't you just spend a few minutes just introducing yourself, let us know about your wonderful self, and for anyone that's listening, Lena's sitting outside at the moment, so if you get any, uh, any sound, that's why.

Lena Reinhard: I hope we don't get too much of that. So yeah, I'm Lena Reinhardt. I'm an engineering leader.

I've been in the. Workplace for almost 20 years. My background initially was in finance, but I've [00:02:00] been in tech for 14 years now. And my work is in any role I've had is basically about helping people and organizations manage complexity and be successful with it. And practically that's meant I've been a startup software as a service, um, co founder and CEO.

I've been VP engineering at Travis CI and Circle CI. And, um, I've also been an engineering manager in a couple of places, and now I do the same work. Um, so helping leaders in the technology space succeed in complexity. And I do that work now as a leadership coach and trainer, mentor, and organizational developer.

And so for me, it's all about these systems of humans, tech and business and making success with those. Yeah, no,

Aaron Rackley: that's awesome. That's a very variety driven experience there, which

Lena Reinhard: Yeah, I'm just a curious person and that's what happens. There's a career path if you'd like to say

Aaron Rackley: yes to things Yeah, mine's exactly the same.

I jump around [00:03:00] just because I I need to just be doing something new all the time Yeah, love a good challenge. Yeah, 100 percent So thinking about um metrics for engineering leaders, I think the first question i'm going to ask is like what What is the most common pain point you think of someone coming into leadership of choosing what is the right metrics to do?

And then we'll come to implement them later. Yeah. How do you, what do you choose? What is there?

Lena Reinhard: So. I will admit that I'm always torn about that question and how to answer it best. Um, because my, in my experience, especially working with new leaders and also also being a new leader at some point, um, the challenge is that, um, it always really helps to basically have a very concrete starting point.

And so I do think, um, basically talking about what exact metrics can be helpful for which purpose, I think that's helpful. And I'm looking forward to talking about this. And at the same time, I've also [00:04:00] found that like with any framework or any, um, example, basically of how to run a team, there's technically the answer always has to be it depends.

So it depends on what metrics you should choose, depends on your organizational context, your role, where your team is at, et cetera, et cetera. And, um. So I find that basically even to answer the question properly, there, there are these two aspects to it for me, basically, as a new leader, you need a starting point, absolutely.

And at the same time, I have also found that especially as you're growing over time, it really helps to have a bit of a framework that you can use to understand why certain metrics are important or when to pick which ones for which team at what point in time. How do you feel

Aaron Rackley: about that? Yeah, no, that's good.

So there's a couple of things, right? So you're saying that there's like some core kind of metrics that you could use across everything and then there's like frameworks that you can use. So maybe we start off with like some of the [00:05:00] metrics that you find are quite common across different scenarios, right?

So what kind of metrics are there that we can look at?

Lena Reinhard: So if you're an engineering manager and, um, meaning you have a team of engineering managers reporting to you, um, and there aren't already metrics in place, honestly, that could be a really good point to start from basically look at the metrics that other teams are using, ask your peers, ask your boss what they're familiar with.

Um, that said, um, I would say at the engineering manager level, um, I, the reason why you're using metrics is usually twofold. Um, the one part is essentially to help your team learn about themselves in the sense of how are we working, how is, um, how are our processes. What are the impediments in the work that we're doing together?

Um, so essentially it's about helping a team understand themselves and, um, get better. And so it's in that case, [00:06:00] metrics are really a pillar or core aspect of, um, DevOps culture of learning agile culture. Um, and a really important part of that. Um, the second part, um, in addition to helping your team, there's also metrics that are.

I always call them metrics about your team, so metrics that you use to convey to other people how the team is performing and honestly also just to have those for yourself because metrics are an important part of having visibility and situational awareness of how a team is doing. And those metrics about the team are a bit more for people like your boss, maybe a product manager.

If your team has one, if you have a platform team without a PM, maybe there's there are other platform teams or upper leadership that you have to provide some sort of visibility to. And so keeping these audiences in mind, I find this really helpful. Um, and so in terms of concrete metrics, metrics for a team, um, Of course, there are the classics, there are Stora metrics, um, which are [00:07:00] quite sort of engineering centric in the sense that they're about ultimately being efficient as a team, being effective as a team.

And, um, so those can be really helpful. Um, I would also always recommend talking to your team, because especially if your intention is to help your team learn and improve over time, they will. Maybe have some ideas for what they would find helpful. Some teams, for example, are struggling with observability where either not much is in place or they're getting overwhelmed with alerts that are meaningless.

And so, um, understanding basically what the problems are that your teammates are seeing and then how to measure those is honestly always a really good conversation because it also helps engineers then wrap their head around the metrics, helps with avoiding resistance to adopting metrics. If that's not a practice people on your team are used to yet.

Um, So yeah, basically what the engineers want, DORA metrics are a good starting point. Um, I would also suggest, um, for the whole topic of helping a team learn [00:08:00] metrics that are more about the agile process can be super helpful. So things like, um, cycle time can be a really good one or the PR review time.

Um, if it's more about helping a team basically work in smaller increments, some teams also like to use story points. Um, that's always with a bit of a caveat that They're only meaningful within the team. But if, if you want to help the team work in smaller increments, make faster progress, um, basically helping the team understand how well, how good they are doing at breaking down work.

That's where story points can be super helpful. Um, yeah, that's sort of as a starting point.

Aaron Rackley: What do you think? No, that's really good. I think, um. We've had a few people that mentioned DORA, um, and across a lot of different managing areas. So, um, I think they're very useful, especially like, like you said, Dave, you've got like cycle time, deployment frequency, that kind of stuff.

Once you've got this data, um, you started to notice, [00:09:00] I don't know, the deployment frequency started to slip or sometimes getting longer, you know, what, what kind of things can that data tell you? And, um, What can you do to try and adjust that, I guess?

Lena Reinhard: Mm hmm. Um, that's, I honestly find, I love that question because it's usually one of the sticking points with Metrix, because it's one thing to basically see, hey, we are not doing well or we're having struggles in a certain area, but then what do you do with this information?

And so I mean, specifically, if your deployment frequency is going down, you'll basically start debugging. In the same way as you would do with a core code base, you start looking at the system. So, I mean, honestly, I always recommend grouping your team in as much as possible. And so probably say that quite a lot today, just because, um, the engineers on your team are subject matter experts.

And of course your responsibility is kind of to. to surface that expertise. Um, but so they probably have ideas. Maybe they were [00:10:00] just, you know, very simple things like requirements weren't, um, ready on time or there had there had to be some rework or you had someone new on the team or just people were working with an unfamiliar code base and so understanding essentially the people perspective is always a really important component of honestly making any metric meaningful and useful.

Um, so I'd always say start there. You can probably also I mean, honestly, um, you can probably also see some things just based off of the, um, the work that's happening. So for example, you know, did PR size increase? Um, what made that happen? What were the factors that got you there? And so, um, That's where, like, basically having metrics in place is great, but you're going to get only the most use out of them if you actually look at them on a regular basis, for example, once a week, and then talk with people about it and try to understand what is actually happening there.

Aaron Rackley: Yeah, I think, um, that's a good point. As you become an engineer, a lot of people that become [00:11:00] engineering leaders do come from engineering first, right? So you're used to breaking down the code base, the systems, to figure out where the bugs are, and you're doing exactly the same thing, right? But you're just moving it to people and processes.

Yeah, exactly. And you're finding the right problems, right? So yeah, um, I think as a technical leader, I think one of the things I think I've struggled with in the past is striking the balance between starting to use all these metrics for accountability, but also still using them to make sure that you can foster that culture of learning and.

You know, experimentation where people want to try and do stuff instead of just trying to hit metrics, because I found in the past, like, especially with a scrum, for example, just randomly, if you've got 20 story points, people start to live for 20 story points, instead of pushing forward, trying to find more, you know, they get into a happy, happy medium.

So how can we strike that balance, do you think?

Lena Reinhard: I think [00:12:00] that's something, honestly, that a lot of people struggle with. And that's probably going to be a continuous topic for you throughout your leadership career. And by you, I mean, basically all of us. Um, and so I think a couple of things, one part, I found is essentially the systems you set up around metrics.

So I mentioned the point already around involving your teams, um, having regular conversations like that can be an important part of it. Um, the other is just in what metrics you even select. My recommendation is always start with three or four metrics at maximum. Honestly, I feel like even, you know, Dora is technically four metrics.

That's already a lot. Um, you may actually be better off if you just pick one or two Dora metrics and then something else that's really meaningful to the team. Um, and including a way to balance out your metrics in this. So, for example, if you only measured story points, of course, your team's going to optimize for that.

Like, [00:13:00] because how would they not? And that's, that's one of these really gnarly pieces about metrics that. I find really hard to like, honestly, that's really hard for people to wrap their heads around, which is that metrics are going to create incentives, and these, these incentives are going to lead to behaviors and those behaviors are going to create your culture.

And that's where I don't think you need to overthink the metrics, but I do think you should. basically iterate with them in the same way as you do with anything else in the sense of basically reviewing regularly. Are those metrics actually working? Are they helpful? Are they leading us to where we want to go or do we need to make adjustments there?

So in the story point example, it might be helpful to additionally add a metric around Something that's not about shipping a specific amount of story points and trying to, obviously now I'm struggling to come up with a good example. Um, but, um, let's see. Um, [00:14:00] I mean, honestly, another could just be, are you actually achieving your goals as a team?

Um, So the basically I do find looking at metrics that are more efficiency based and that's where I would slot story points in the sense of it's about how we work. It's about our processes, having something that's about effectiveness. So in the sense of are we achieving our goals? Are we getting things done that can be really helpful?

So basically have some balance embedded in the in the metrics that you're selecting. Um, and I think the. Last part for avoiding these misguided incentives, basically, or these, um, accidentally wrong incentives, is, um, continuously improving how you're using these metrics. And as a part of that, also not just making it your work, um, So I, you know, you mentioned the word accountability and I do think metrics can help with that, but at the same time, there is so much where I realize I've already talked about this a couple of [00:15:00] times now, where it's about building systems that work.

So in the sense that it's not just dependent on you looking at metrics, but your team understands why you're doing this and the point of this and that story points, for example, measuring those is only a crutch in order to help you achieve a goal and the goal could, for example, be that knowledge is distributed more evenly across the team.

So that's actually the much better metrics metric now I'm thinking of it. Um, so, you know, do people actually feel like they understand code bases better? Um, and so keeping in mind that basically the metrics, metric is a tool to solve the problem and it's not, it shouldn't become the solution in

Aaron Rackley: and of itself.

Yeah. Yeah. That's interesting because a lot of that, as we just said, is, is focusing on the metrics of you looking internally as the team. And. I think there's a big conversation happening at the moment in general about like returning back to the office, working from home, all this kind of stuff. And I think I'm in a lot of conversations in lots of forums on Discord and Slack [00:16:00] where everyone's getting upset about being asked to return in general.

But I think, I think a lot of this comes down to, again, people not understanding the metrics that they're, they're giving back up the chain, right? So we've just talked about going internal, but going. The same has to be said for understanding what What information you're giving back, right? Because like you said, a lot of people are potentially ready to turn the office because your company doesn't think you're some visual metric or something somewhere that is saying you're not doing as much as you was before.

Potentially that's potential one reason, right? I'm sure there's financial reasons and lots of other reasons, but one of them is. Obviously, uh, kind of this kind of look at productivity and accountability and stuff like that. So, um, do you have, do you have any thoughts around the area? I know it's putting you on the spot, but I was just thinking, because it's a hot topic at the moment.

So it would be interesting to think about what kind of metrics we could use to let our, our bosses and our [00:17:00] company. know that we are still doing well. We're still, or even better than we was before.

Lena Reinhard: Yeah. Oh, I, I love this whole topic so much. And I, I also have to just say, I have a lot of, um, spicy hot takes on this and I will try to contain them.

Well, you won't, but other people might. So, um, basically the. Um, I do think this is important to talk about and to think about in terms of essentially how do you convey to your boss and your bosses that your team is doing work, that they're doing well, that they're, for example, getting better. It's something that most of us actually aspire to.

Um, and that all of that is possible in the context of, for example, remote work. I think that's really important before I talk about how to do that, though. I just want to preface it with essentially, um, I think, [00:18:00] I mean, ultimately statistics are very clear. People, like productivity is higher in remote teams, and I do, I mean, I have been working with distributed teams across the globe for 12, 13 years now.

Some of them were hybrid, but most of them were almost exclusively remote. The data is there. The whole reason why a lot of companies are really forcing return to office now, which is basically what's happened to me yesterday, I think, was when Google announced that people either have to make a choice to move to a certain area or they're going to lose their jobs.

Um, my understanding, honestly, is that a lot of this is essentially used by companies as an excuse and as a tool to make layoffs happen in a way that's easier for them to execute. Um, and, um, A lot of the reasoning that is given, especially by executive teams is essentially the CEO believes that [00:19:00] it's better if people are in an office, which is the CEO's personal belief system.

And that's played out, um, in, in those kinds of policies and whatnot. And so I do think there's a lot of smoke and mirrors around this whole topic. There's a lot of BS going on there in terms of how workers are treated and how, like. Policies are being shifted and whatnot. And a lot of this is essentially not based on data.

So I also basically want to say that yes, it's important to convey this picture of how your teams are doing. It's like managing up as a critical part of your job as a new leader or any leader, really, at the same time, there is a piece to this where you might be fighting windmills, um, and that doesn't mean that it's not worth it.

Um, but. It makes it a really tricky situation to navigate. I mean, that's as you, as you also said earlier on. Um, so yeah, and, uh, I'm going to stop there before I actually get into a rage.[00:20:00]

So in terms of how do you actually do this? Um, and I think. Conveying to your boss how your team is doing. It's important in specific contexts like the remote work stuff, but at the same time, it's also something you should be doing on a weekly basis, at least. Um, so I have actually, I have a template for how I've done this in the past on my site, and we can probably include that in the notes.

The whole angle. that you can think about there is basically pushing information. So in the sense that avoiding, you're avoiding that your boss has to ask you, for example, you know, how's the team doing? How are we progressing and whatnot? You shouldn't be getting those questions. You should. Always convey that information.

What's the word? Proactively. Um, so that's the starting point. Um, in order to actually talk about this, um, essentially the two things that any boss cares about and that I care about learning from my managers is, [00:21:00] are we achieving our goals? Yeah. And how are we Are we basically, are we spending the money that we're spending in a way that helps us get to where we want to go?

And so, in very practical terms, that should always mean, are we on track to achieve the goals that we have as a team? Um, you have, maybe you have OKRs or you have SMART goals, whatever it is, doesn't matter. Um, but, Are you on track to hitting those goals? Um, what are the risks? What are the unknowns? Um, and how, how confident do you feel about achieving those goals?

So for example, um, if you said, Hey, we're 90 percent there, but actually the last percent, the last 10 percent that are missing are about something that we haven't dealt with really that we haven't been able to plan because there's been too much going on or whatever the reasons are. These last 10 percent might actually be really gnarly.

And even though we still have a lot of time in the quarter, we might not actually get there. Dick. And so that means you have, like in this example, you have the metric, you know, how are we on goal achievement, like the [00:22:00] 90 percent and the context around it, which is, hey, I'm not super confident. Um, we are.

And then what are you doing about it? So, for example, you're working with the tech lead to de risk that project. You are working with stakeholders, whatever it is. Um, so there's, that's the. Are we achieving our goals piece, the effectiveness piece, and then there's the efficiency piece. Um, it might be that your company has given a mandate for teams to, you know, become more efficient.

It's been a big word that's been thrown around quite a lot. Or, um, you want to talk about the remote work piece. Um, and that's where you can look at how is your team performing currently? Has your, you know, how is your deployment frequency? For example, I would say, um, The slightly tricky bit with Dora metrics, for example, is that they are very engineering centric.

So if you're reporting to, for example, a CTO, um, who, you know, understands those metrics, understands their value, um, and understands what they mean, um, [00:23:00] those metrics can be really helpful. So you could incorporate your Dora metrics there, or you could, for example, say, Hey, we have, um, increased the number of story points that we're shipping because the team has gained more knowledge.

Um, we are on, on a. Positive track there. Um, and so essentially, ultimately there is a piece of understanding. What does productivity even mean to your boss and other business leaders in your organization? Um, and if you're not sure about that, or you can't really get that information, start with what you know.

Um, and if your boss then tells you, Hey, that's actually not meaningful at all. Well, then you can try something else, but really focus on pushing that information out and then dealing with the feedback. Um, and really, you know, you can iterate in your communication there in the same way as you can iterate in which metrics to use and how you use them with your team.

Aaron Rackley: No, 100%. Based on your, your, your experience over the long time that you said you've been doing it. The um, have you made any mistakes with [00:24:00] engineering?

Lena Reinhard: No, never. What? That's like, rude.

Aaron Rackley: I'm making more time. Oh,

Lena Reinhard: I have made so many mistakes. So the question is much more, you know, which, which area and, um, What do

Aaron Rackley: you think is the most common pitfall that probably new, new leaders would make with Metrix, I

Lena Reinhard: guess?

Um, so I kind of see two, honestly. Um, the one is basically just struggling to get started. Um, and I get that it's a very, it's not just a complex topic. It's also a topic that has quite a lot of hot debate around it, um, in sort of engineering circles. And so that can make it really hard. Um, so like we mentioned earlier, basically pick just something and start with it and involve your team.

If you're struggling with that part. Um, I would say the second [00:25:00] part that. It's really tricky. Um, but manageable is basically, um, starting to wrap your head around using metrics to achieve the results that you want, because one portion that's a bit more. The angle of, hey, you pick something, start there and then iterate from there, that's essentially what I would describe more as the observability aspect where you use metrics to understand how our team's doing, how does that relate to our goals and to what our bosses want from us, etc.

The other part is more where you can use metrics really effectively to drive change, like the whole piece. That I mentioned earlier in terms of metrics will create incentives, will create behaviors, will create culture. That is a really important bit. And so if you are essentially looking to, you know, help a team really get better at something specific, or you want to shift the culture on your team to be a bit more learning focused or a bit more experimentational or whatnot, um, that's when [00:26:00] it's just a different way of thinking about metrics.

And I found, um, That piece honestly was something that was really difficult for me for a while because I was used to metrics as much more, you know, Hey, the business wants this while we're going to do it, um, which is fine. There's nothing, nothing bad about that, but, um, using metrics in a way that's really motivating for a team and that helps them understand, you know, bigger context and all that, um, that I found can just take a while because so much of it then has all these.

Asterisk and it depends attached to it. Um, yeah. But yeah, I think those are the, the two ones.

Aaron Rackley: Yeah. I think, um, I definitely need a t-shirt with, it depends written on it because every set. Yeah. Every question for every fin in tech is, it depends.

Lena Reinhard: Mm-Hmm. . And that's so hard because I really like, I empathize so much with people wanting concrete answers and whatnot, but I think that also goes to.

Like, honestly, the crux of these leadership roles, like the ultimately [00:27:00] the thing that differs you is probably not the skill set or so that what differs you from the work that your engineers are doing, at least folks who aren't at staff plus level is essentially that your job is to deal with ambiguity.

And your job is to handle complexity and to handle things like, yeah, it depends. There aren't straightforward answers. Um, it's hard. Um, you need to look at all these different factors from your people to your boss, to your company, to your goals and whatnot. And that's a lot. And I found that basically I would also say in the, in any case, but also in the case of metric metrics, like give yourself time and.

just initially honestly start by just acknowledging that that is a thing, that that's part of your job now. And that also means the whole thing of like, nothing's ever done. Everything just takes forever. Um, or like a lot of, a lot of the work is also just about building good structures and systems. Um, like, you know, regular one on ones and retrospectives with the team and whatnot.

We do all of those things to basically it's leadership [00:28:00] hygiene. Um, and, um, that's work. It's more or less rewarding on any given day. Um,

Aaron Rackley: yeah. I remember when I first started out in software, I remember always I was joking with my colleagues, like what, why is our managers always in meetings and then you get to this level of role and then you go, and that's why, okay, I

Lena Reinhard: understand now.

Yeah, yeah. And, and, uh, I think, I mean, even for people who are more on the sort of technical leadership path in the sense that they don't have people reports, um, but they're owning larger contexts for technical projects and whatnot. Um, it's the same issue where some, at some point your basic, your job is to.

Either find problems that the business already has or like surface them and then solve them or just your handed problems and your job is to solve them. Um, and that's just that's just gnarly work.

Aaron Rackley: Yeah, but I find it very fun. Me

Lena Reinhard: too. I love it. But it's it's also initially you can basically think [00:29:00] about it in this.

Yeah, exactly. You can think about it like with an engineer where like a junior needs very well scoped tickets. Um, with very clear acceptance criteria and all that and like nothing against acceptance criteria. But at some point, if someone wants to become a tech lead, staff engineer, so you would expect that you can basically tell them, Hey, there's something wrong over there.

Please figure out what it is and fix it. And so it's the same thing with leadership. So give yourself time, but also. Don't let that block you or keep you from that work because it's really good work. I'm glad you mentioned that Shouldn't just talk about the hard part

Aaron Rackley: Yeah, I want to do an episode at some point which is like, um engineering management 101 like the first thing here's like a Blueprint of the 30 days things you need to learn from tech going from just being a tech software developer into that role, like what is the scary bits that you're going to encounter?

And it's like, cause you've spent all that time learning how to do the latest software, the latest repository, everything. But now it's like, Oh, there's this whole other books you need to learn. [00:30:00] Yeah.

Lena Reinhard: Yeah. And, and a lot of it basically is, there's just nothing has clear answers anymore. Right. Your job as an engineer is to basically Breakdown ambiguous, complex issues until they are not ambiguous anymore and you can code through them and Boom, it's done.

And I know that it's a hard job and it's a complex job, but in our line of work, that just barely exists.

Aaron Rackley: Yeah, yeah. Yeah. So we've mentioned Dora as a, as one of the kind of resources you can use. Do you have any other tools or resources that you could recommend for like gathering and analyzing this kind of data?

Mm

Lena Reinhard: hmm. Um, you mean more. for, essentially, you have the Dora metrics and you want to figure out what to do with the results,

Aaron Rackley: or? Yeah, let's go with that one first, because it's obviously, we've talked about it a lot, so it keeps it in the frame

Lena Reinhard: of where we're at. Mm hmm, yeah. Um, I mean, honestly,

I don't know. It's [00:31:00] like in, you know, beyond, beyond the whole, um, look at the metrics. Mm hmm. I'm a big fan of calendar events and reminders because my brain just, uh, otherwise doesn't function. So, you know, if that's you or even if it's not you, maybe it's worth a try, but have a weekly reminder in your calendar to look at your team's metrics.

Um, make it part of your team meeting, um, or team planning template. Um, so you talk about them every week and then, or also talk about them during your retrospectives. What are the things that you've learned from them? How do you want to deal with these lessons learned? Um, involve your stakeholders. Um, so if you have a product manager or then again boss, um, you may have to talk about, you know, hey, we, for example, realized our deployment frequency has gone down.

Here is what we think is an issue there. Um, here are the things that we would like to do. How can we prioritize that work? Um, because metrics are going to get very demotivating very quickly if you're just seeing that everything's on fire and [00:32:00] no one has the capacity to do anything about it. Um, and so involve your stakeholders, um, and.

And honestly, that's, that's pretty much it. Um, I don't know if you were thinking of anything specific in terms of No, no, no, that's fine. That's fine. I

Aaron Rackley: just wanted to, to gauge what you think. Yeah. Um, I think one last question then is, we've just spent all this time telling you why we think you should use metrics, but what is the last bit of nugget you would give to someone who is just Listen to all this, but they're still hesitant to want to do any metrics.

Like what, what would your one motivational sentence be?

Lena Reinhard: I'm afraid I can't boil it down to a sentence yet. Okay, thank you. So my first question, and I honestly I hear that a lot from, especially managers who are just moving into the [00:33:00] role. So my first question at someone in this position, basically, what are your concerns and where do you think those concerns are coming from?

Because in my experience, honestly, a lot of managers are. Um, scared of what introducing metrics is going to do to their team and to their relationship with their team. Um, a lot of engineers have made bad experiences with managers in the past and have dealt with, you know, feeling micromanaged, being micromanaged, um, or feeling like metrics were used against individuals, um, instead of actually as a tool to learn, um, things like that.

Many engineers have made experiences like that, unfortunately, um, but that also means. Maybe that's part of why you're concerned or you're concerned of becoming a quote unquote bad boss or, you know, someone who's annoying their engineers. Or it's you're in a company where that's not really part of the culture.

And so it feels weird to be the person who kind of [00:34:00] introduces that. So digging into basically what's your hesitation, where is it coming from? Um, and, um, validating that. So especially if your concerns are about, you know, how will your engineers react? What's it going to be like for them? Speak with them, say, Hey, you know, and, and as part of that dig into.

Why do you want to use metrics in the first place? Because, of course, it gets thrown around a lot. We all say it's kind of important as part of visibility and situational leadership for a team. Sure, that's all true, but that's also very abstract. So, like, what makes you think that metrics would be helpful with your team at this point in time?

And then go into a conversation with your engineers about that. So, for example, say, hey, you know. Hey, teammates, I would like to get a better sense of how we're doing just for us, um, and I would get a better sense of what I can tell the business about how we're doing it. For example, to help convey that our productivity is improving, even though we're all distributed.

Um, [00:35:00] dear teammates, what do you think about this? What does it bring up for you? Um, what concerns do you have around it? Um, so basically. Don't just keep it in your head, but especially if you're concerned about wanting to protect your teammates, um, which is very, um, very good intention, um, validate those things and speak with people and at the same time, you know, you can still say, Hey, I do believe metrics would help us get better if there's hesitation on the team, you can speak with them about, you know, what What would those metrics look like?

What would, what kind of practices around those help the engineers feel at ease or would actually help your teammates get use out of those metrics as well? Because of course, like no one likes to measure a bunch of stuff that in the end, no one will care about. Um, or that again, like no one will be able to do anything about.

Um, so I would start there. Um, because honestly, a lot of, I mean, all of us have made experiences in our workplaces. Not all of those were unequivocally good, unequivocally good at all times. And, um, That also means that we all [00:36:00] have some baggage and we bring those, that baggage and our own ideas about how people react and what not into the workplaces that we're in and into the teams that we're running and that's okay.

That also helps us because it also means that it's part of our instincts. Um, but the thing is that our instincts just aren't always right. And so, um, I think reflecting on the idea of why are you doing those things? Um, why do you find them important and how can you use them and do them in a way that is in alignment with what?

Matters to your teammates. Um, and how can you do this? Well, together, I think is a really good starting point.

Aaron Rackley: No, that's that is absolutely great questions. Yeah, I I am obsessed at the moment of just trying to understand all of All Dora, all metrics, all this kind of stuff. I like to analyze problems. I like to try and figure out where the bottlenecks are and I think it's a great tool to get there.

Um, so I appreciate you coming on to talk about it. [00:37:00] One question I'd like to ask all our guests and I don't know if you saw this, but I'd like to ask our guests to recommend a book which I'll Buy and put on our bookshelf and it doesn't have to be tech it can be your favorite childhood book It could be anything but if you could offer one book for someone to read What would you recommend?

Lena Reinhard: um, so my recommendation is not tech at all. The book is called Into the Planet by Jill Heiner. Jill is a Canadian cave diver and writer, photographer, filmmaker, and one of the first things that I think she says in, this is her memoir, and one of the first things she says there is that she's She's specialized in cave diving, and if she has an accident during her work or during this cave diving, there are three people in the world who can Come to her help.

And one of those is her ex husband, which I, which I just think is a really good preface. [00:38:00] So she's, she's incredibly good at what she does. I'm not a diver at all. I snorkel or dabble in snorkeling rather. But I don't think that's ever for me and I'm incredibly fascinated by the work that she's done and by her career because she's One, I mean, exploration is just a really fun topic.

And, um, the work that she does is incredibly complex and difficult. And there's so much about understanding risks and still doing what you're doing, just carrying those risks and also like working with other people to build a setup where those risks. are at least managed. But at the same time, there's no 100 percent certainty in it at all.

And so the book is called Into the Planet, My Life as a Cave Diver. It also includes a bunch of beautiful photography from her. So if you're not into digital books, I can recommend getting the paper copy because they're just Bye. Phenomenal. Um, so yeah, that's, that's my book.

Aaron Rackley: Awesome. I'll add it. And yeah, as you say, cave [00:39:00] diving, definitely scary.

I've watched some videos and the preparation, preparation, preparation.

Lena Reinhard: Yes. Yeah. Yeah. I'm not, I, yeah, no. I'm curious to try a lot of things, but that's, there's a hard line.

Aaron Rackley: Awesome. So before you go, um, Where, if anyone wants to find you online to talk more about this, where can they find you?

Lena Reinhard: Yeah, I have a website.

It's LenaReinhart. com. You can also find me on LinkedIn. I have on my website, um, bunch of articles, including about metrics and how to make them work for you and your team. Um, and the whole topic about, um, pushing information to your boss. Um, I try and, um, release a lot of sort of actionable things that you can walk yourself through and then.

Tailored to your situation and figure out paths for yourself, um, forward. And I think, yeah, website and LinkedIn is currently the biggest ones. I'm post X, but still haven't found a place to go.

Aaron Rackley: Well, I'll make [00:40:00] sure they're in the, um, show notes anyway. Thank you. Thank you

Lena Reinhard: for coming on. I loved your questions.

Thank you so much for having me.

​

Today we are in conversation with Ida Rolek-Kononiuk (VP of Technology) and we start 2024 and season 2 of this podcast answering the question. How do I set goals and objectives as a leader?

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Ida Rolek-Kononiuk

• www.linkedin.com/in/ida-r-kononiuk/

Book Recommendations:

• Turn The Ship Around!: A True Story of Turning Followers Into Leaders

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hey everyone. My name is Aaron and welcome to the tech leadership decoded podcast, where through conversations, we unravel the intricacies of leadership in the tech industry and welcome to 2024. It's a brand new year and as such, a new season of this podcast, which I'm kind of splitting up each season into each year.

So we're in the second year, season two, and we're going to start off the year like many do, and we're going to think about goals and objectives. So, for instance, on this podcast last year, we managed to get out nine episodes. And I have already set the goal of hitting two episodes a month. And I'm going to need your help as a listener.

So, if you have any ideas for subject matters you want us to cover on the podcast, do let us know on X, formerly Twitter, at Tech Lead Decoded. Again, that's at Tech Lead Decoded. Or, even if you just want to be a guest, reach out onto the platform and we'll have a chat. And with that out of the way Let's get [00:01:00] into today's conversation where I'm joined by the awesome Ida, the VP of technology at.

fxcintelligent. And we asked the question, how do I set goals and objectives as a leader? Okay, thank you for joining me today. How are you doing?

Ida Rolek-Kononiuk: I'm very good. Thank you. How are you today? Yeah,

Aaron Rackley: not too bad. Not too bad. I'm really excited to get started because this is going to be the first audio of the year for the podcast.

I've done some other recordings, but I thought I'd wait for this video recording to get it out first because of the topic that we're doing, which I think Suits the beginning of 2024. So we're here today to talk about goal settings and team goal settings and personal goal settings. But before we get into that, why don't you tell us a little bit about yourselves and what you do?

Ida Rolek-Kononiuk: Oh, yeah, certainly. Um, I'm a VP of technology at FXC Intelligence. Um, we are an [00:02:00] industry leader in a cross border payments data and intelligence, uh, and I'm leading a technology team full of very talented individuals from software engineers, data engineers, to, to DevOps. Before I joined this company, I acted as.

I was director of engineering and a big organizations as a service owner in the BBC as software engineer. So I was on all sides of setting goals and objectives and receiving them and having them set for me from junior level up to now, now that the PPP level. Awesome.

Aaron Rackley: Okay. So let's just say it's the beginning of 2024.

I've got the mandate to set some goals for me, myself, the team. Where, where, where would you start in all of that?

Ida Rolek-Kononiuk: context and a direction. So your, your goals or goals of your team don't exist in vacuum in a separation to your company, [00:03:00] your work, your life, the stage of your career, or where do you want to go with it.

So whoever gave you the mandate, ideally should also be the person that could tell you in which direction was their purpose for you and for those goals. And that's a very comfortable situation if you have such a person. Working with you. So the boss, a company CEO or a company board that actually comes to you and says, those are our goals as a company for this year.

Could you please set goals and use them to start to set goals and objectives for yourself and your

Aaron Rackley: team? Let's think about me as an individual first, and then we'll come back to some team stuff later. So as an individual, I in the organization might have a career framework, for example, and the company I'm trying to work towards.

Thanks.

Moving up the ladder, moving up the thing, um, How would I go about internalizing where I think I need to grow? [00:04:00] in the upcoming year? What kind of techniques could I do? Sure.

Ida Rolek-Kononiuk: So first, and I find that very, very useful, um, is to gather some feedback. And it can be feedback from people around you or having an honest retrospective with yourself.

Yeah, um, some people are lucky and also have a support of a personal coach or have friends who may be in a similar discipline, and who can take a look at you from the outside. Like what went well the last year? What do you want to achieve? Where realistically in that career framework? What are your strengths and what are your the areas to to improve on this this year?

Um, and then once you know where you are, and what went well, I think the next step is to think what do you want to grow? And my and I know it's a controversial take, but I usually start from building on your strengths rather than [00:05:00] trying to patch up weaknesses, unless there is something critical really slowing you down a real blocker as an There is absolutely no way that you can progress in your career without writing down things.

Let's say you really want to be an architect, but you don't write documentation and you don't prepare any, any diagrams whatsoever. So without that skill, It is very difficult to progress. It is a necessity, usually, to be an architect, to be able to explain your designs or plans or wishes. Therefore, you may have to invest in training or invest yourself in this area and start building, but then find your strength.

If you aren't strong with writing, Maybe you're better with talking, maybe you should do a podcast about architecture. Maybe you should talk to people, maybe you should talks or internal brown bag launches, things like that. Maybe you should mentor a person and record the [00:06:00] videos and meetings. So rather than forcing yourself to work on something that you aren't very good with, I would focus in a career framework, I was focused on what your strengths are, where do you think you have the biggest chances to make the biggest progress, and focus your objectives there to push that next level through your strengths and through the best sides of your, your work and your personality.

Aaron Rackley: Yeah, no, very interesting. And obviously, like you mentioned, make sure you reach out to your, your peers and colleagues to try and get feedback on how you're working, because I think one of the hardest things for me, and for, I guess, a lot of people is. Trying to internally, um, uh, visualize your own feedback, right?

Like you, I'm perfect. I'm amazing. I'm not, but I mean, it's very hard to self reflect, I think, a lot of time. And I think that's a skill that takes a lot of time to build over, over [00:07:00] years. I imagine it will never stop.

Ida Rolek-Kononiuk: Funnily enough, when you said you're great, most of the people I work with. actually are under appreciating their own abilities.

And very often they believe when you have like a end of year performance review or an informal chat, see, this is a career framework, where do you thank you for people very often don't appreciate how good they are and how well they do. And that opening conversation as to where you are and having that input from your boss, but also from peers, from people who are already on a level that you aspire to be on.

having their inputs will give you a slightly more objective take on where you are rather than you low balling yourself and think oh I'm actually pretty bad, oh I can't do this, it'll take me years to get there.

Aaron Rackley: It's usually not true. Like you just said there about it might take me years to get there, that kind of stuff.

Is there a concept of like, I'm unrealistic goals. [00:08:00] Can you set yourself up for failure with your Yes,

Ida Rolek-Kononiuk: 100%. And I think you have to, and that's a difficulty as a manager. So my technique usually is to ask people to set their own goals, and then we discuss them, I give a general guidance as to what the goal is, and what are the areas in the career framework, but in terms of what objectives Um, people set for themselves, especially on the more senior level, managers, seniors, I would expect them to be able to phrase objectives and tell me where do they think they can focus, they can focus on.

And I expect those goals, right, I hope for them, the objectives to be measurable. Very often, people will phrase objectives that will never be achievable by any objective metrics, they will never be able to prove they did a good job, or they did. they, they plan a thing that is so unrelated to their existing work, that it's very, there is very little chance they'll find time for it.

[00:09:00] People say, my job is what I do eight hours a day. And then somehow on top of it, I'll give myself the objective of learning two new languages, even though my work right now does not really require those two new languages. And I will, um, What else that people often often hope for, I'll start writing blog posts and record podcast, I'll be more productive, I'll publish on LinkedIn.

If it's not part of your work, if it's not tied to what your team does, what what what your role requires of you, you are setting yourself for failure. And it's not because it's too ambitious. It's because you are unrealistic about the time and commitment it requires. And it's easier to achieve goals if your whole context leads you towards it and it gets easier for you.

So you are rigging the game to make it easy. Ideally, you should be tying your objectives to things that will benefit your daily work and that the objectives shouldn't be on top [00:10:00] of the work, they should drive your focus in your daily work. So you can say that um, you will collaborate with other teams on at least two or three big projects this quarter.

Um, and that is a realistic thing that you, as, as you look at your tasks or epics or things that are coming your way, you can actively think, is that a opportunity to collaborate? Should I be reaching out to other teams and checking with them? Are they facing similar challenges? Have they faced them in the past?

Are there lessons? Is there something we can share? And then you collaborate with them. Is there a dependency? Because collaboration can be so many different things. So you can then make it part of your work rather than make it on top of your work, so to say. Does that make

Aaron Rackley: sense? Yeah, I think so. Because one of the next questions I was going to have was around tailoring your goals.

Towards like the strategies of where the company is [00:11:00] trying to go. Right. And I think sort of, uh, slightly what you mentioned in there is kind of similar to that aspect of like, obviously, like you mentioned before you, the company's going to have OKRs and it's going to have its own goals that it wants you to achieve, they want to achieve over the year.

So aligning. Your goals to where they're trying to go so that you can show your, your goals have pushed towards that are definitely a great thing, especially if you're trying to move up your career, right?

Ida Rolek-Kononiuk: 100 percent Is that correct? Yeah. Yeah, a touch should work this way and if any person from a junior level to a manager is working against company goals, they are most likely either wasting time or they are pushing for something that is very unrealistic in a given environment and maybe they should be considering a different environment.

So instead, what is much better is yeah, let's say in my company right now, our goal for this year on a company level as [00:12:00] to continue to grow and develop our people and continue to be the great place to work, which sounds lovely. And we indeed are a great place to work. But then what does it mean for technology just saying, right, it's not really measurable.

So I can tie it inside technology, I can say the goal is to set goals and objectives for all of the people and empower our people. to hit at least 80 percent of their goals. Here, I'm making a big leap of faith, because I'm assuming people will not read it just to make the goals extra easy. I have trust in all of the managers and teammates, they will be asking people to do ambitious things to put themselves outside of the comfort zone, but in the same time provide support and create environment that will allow people to reach those those goals, setting them so people fail wouldn't make sense.

So that will be the um, that goal. we are trying to hit as technology. And then each manager for each team will be able to say what that goal means for them. It may be that particular [00:13:00] team has to focus more on certain areas. In one team, it may be performance in another team, they may be looking at better documentation, better onboarding processes.

So what it actually means can be interpreted. But I'm asking people to create an environment in which people will have clear expectations. And we'll be able to hit their goals and set those goals and hit them, which then entails doing regular reviews of those goals, reviews of the progress, asking people what help they need, maybe changing team processes to focus on certain goals areas.

So you're gearing the whole team processes and you're evolving the whole team work so that people's goals are the very content of their work almost every day. And then the same time you make those goals tied to what you want to achieve as a company. And I think it works as a wonderful mechanism for a leader to, to harness ambitions of people and their drive to be better, which most [00:14:00] engineers have.

in abundance and harness it and, and direct it's not just to create better solutions for the sake of better solutions. Let's create the drive to be better in a particular direction that you're interested in today, be it security, customer focus, better performance, more documentation, more dynamic infrastructure.

I know a cost optimized infrastructure. You might have 15 different things you want to improve, but you pick one or two and then you harness everything towards it.

Aaron Rackley: Yeah. Interesting. I think. Um, just to pick up on something you said there, which, uh, was about, um, you can easily fall into the pit, pitfall of making them too easy, right?

Making your, your, your goal and objective, especially team members or anyone who's just trying to fulfill an obligation that the company is trying to, um, give you instead of it being an internal reflection on yourself as well. And, um. What do you think, um, people that are [00:15:00] brand new to this, so say you're a brand new leader, you've only just, this is the first time you're actually working with your direct reports to help set objectives.

What kind of things should I be looking for in, because as you said there, you normally ask them to do their first set of goals, right? Imagine they've never had goals before. We, I've never worked with them to do goals. Like what kind of things should I be looking for to start out? Doing this

Ida Rolek-Kononiuk: depends. Have you got career framework you can use or not?

Because if you have career framework, you can ask them what they're like, like you are right now, you should see what level they are on right now. So you're saying I'm assuming you're working toward the next step. So pushing yourself out of your comfort zone will be this. But you may not have a career framework to use.

It happens often. Um, it's not an easy thing to just have. And in that case, um, it's I would ask person, what type of work they found the most challenging the last [00:16:00] year and what type of work they found the most satisfying, and then dig a bit deeper, because there is there is a lot of satisfaction in overcoming your own limits.

When you do very, people usually don't get massive satisfaction from just repetitively completing tasks that are very simple. People usually strive for a bit of a challenge, they want to achieve something new, hence climbing the tall mountains and things like that, or sports achievements, and whole progress.

I would think that if a person tells me what was the challenge that satisfied them the most, I would think pulling that thread, we will find where to challenge them and setting each goal, you're asking, is that what you've done last year? So how did you do? How would you measure it last year? What is the progress?

What is that growth from the last year? If last year, you've completed Five mid level projects, would you like to do bigger projects this [00:17:00] year? Would you like to take more ownership, more responsibility? Would you like to think wider about them? So if you were considering software engineering, did you also think about security or testing?

So in some direction, there has to be growth, either in quantity or quality or speed, like what is that improvement and the difference we are expecting from a last year, I don't believe that goals Or objectives can be successful if we just say do exactly the same thing as the last year. Yeah, I think that would be quite a flat thing to do.

Aaron Rackley: Yeah, you got to strive to towards something, right? Um, I think one of the things we were talking about there was like, um, setting goals, but In terms of short versus long term goals. Yeah, uh,

Ida Rolek-Kononiuk: so I would set goals. So there is a difference that we didn't really actually elaborate on. There was a difference between goal and objective.

And people sometimes just use it as, as the same thing. And in my understanding and how I [00:18:00] approach it, goal is that sort of long term, more ambitious, aspirational thing. And objectives are a more particular. time, time specific element and actions that you can perform towards this goal. So goals, I would usually set for a year or like for a long time, because it's something more ambitional, but on objectives, I would set I would calibrate objectives to a level of a job.

So managers or directors are supposed to think long term. So their objectives also can be more long term because they may be planning now for something that will happen three months from now. So I can have an objective for a manager to plan and execute on their recruitment plan for their team. And I won't, I won't just cap it as a one quarter because the recruitment plan for a year, my staff will start to die and in six months, we'll have three new front end engineers.

But for a junior team member or a mid level team member, I would say their objectives probably are tied to a quarter because we only plan [00:19:00] for a quarter ahead and you have a good clarity of your work for a quarter ahead. And I would tie it to a quarter and assume that The company requirements context is so dynamic that a quarter from now, which can be something else.

And I would build it quarter by quarter and review it each quarter.

Aaron Rackley: And like you said there, you'd reviews each quarter. So, you know, if the business is adapting or your team's adapting or any kind of external factors, then it's good. A good point to start, have a look, make sure you're and re evaluate them.

Thinking as a leader again, and I, I use this word very Um, likely, but accountability, how do you keep your team motivated and accountable towards the goals that they've. So, and then again, how you do that for yourself, right?

Ida Rolek-Kononiuk: I believe in rewards and recognition. So, what's the point of the whole objectives and goals all together?

It's not just to tick something, it's to be able to recognize if people are doing a [00:20:00] good job. Good job. Yeah. And so from product perspective, you can measure like have we shipped enough features and have enough users using them? But as a technology leader, I'm not just counting, you know, how many lines of code we wrote and how many tickets we moved.

I care about people growth and how they work and what they do and the way to measure are they working the way you're achieving What I would like technology to achieve, like bigger technical maturity, the more collaborative environment for me. see people hitting those goals and objectives. Therefore, accountability and motivation should not only be regular review of a person, it should be a celebration and acknowledgement.

So I believe in fanfares, I believe in quarterly all hands, where you elaborate on those goals, you say this team, this person did this, this happened, that happened. Look what the progress we've made. Look how our goals us hitting those goals, how it impacts the whole business, all of us as a company, like what what [00:21:00] we were able to achieve.

And I believe that focus that that verbal public acknowledgement of achievement and importance of it, how it wasn't a paper based exercise. It's changed the things at impacted other teams or other members or users, I think that that's one of the big things. And I then expect engineering managers or team leaders to also celebrate with their teams and with the people that they manage.

In the same time, if goals are not hit, that requires a conversation, a proper conversation as to what support is needed, what is happening, what has changed, and not just like, well, okay, nevermind, you're not hitting it. Oh, well, lean in, dive in, pay attention, care about it. And that, that really brings results, I think.

Yeah,

Aaron Rackley: that makes sense. Um, how can we, as obviously, as an individual contributor, the goals are pretty, [00:22:00] um, oriented towards yourself as a leader, you, you got to strike the balance. So how do we strike that balance between. The goals that you're individually trying to, uh, achieve and the ones that are related to the team that you're, you're, you're working with, or do you see them synonymous together?

Ida Rolek-Kononiuk: So I see them quite synonymous, but it may be because I, I'm used to, I used to work in the big teams in the bigger environments. It's been a long time since I worked in a company where we just have like two engineering people, we work in a context, you've got inside technology, multiple teams and departments.

And then you also have sales, you've got commercial, you've got people team finance team. And I believe software engineering is a team sport, we hit those goals together. It makes no sense for one person to just better themselves if it doesn't benefit others. like each thing to go to production and be there for users.

It requires hands of [00:23:00] three, four or five people sometimes for a person writing the specification requirements, the code testing, the code review, the release of it. It requires quite a few people. So I think that objectives should be tied to the whole team. And one person is developing something. And usually if there is a goal to, to learn something, to get better in something, I would mirror or shadow it with a goal of sharing that with others.

In our career framework, alongside the knowledge and ownership, you always have teamwork and collaboration. And it goes hand in hand at It would be very hard to progress your career just by getting a stronger knowledge, but not improving in any way on a teamwork or collaboration, not sharing that knowledge with others, not influencing, not implementing it in something that other people can use and see.

Aaron Rackley: Yeah, because I think that's interesting because something I've read I was doing a lot of [00:24:00] reading in preparation for this podcast, but one thing I kept seeing was this very 50, 50 side of whether, you know, how to avoid, I'm trying to think of the right phrase, but it's like how to avoid being your goals being impacted by the outside of the world, that kind of aspect.

And then, and then, and then the other side is like, what you're saying there, which is, you know, some of it needs to be, because like you say, you're all part of a team, you're all part of the same company working towards the same goals and. I think a lot of times when people sit down to work out their goals for the year, they get too personal and they do get too much of it.

It's about me. It's about being about me. But what you've got to remember is when you've gone from a individual contributor to a leadership role, it's no longer about you. And most of what you do is about the team that you're working with. And Tell me if you agree or not, but I think one other aspect to that is the team is [00:25:00] not just your immediate people that you're working with.

It's the, the whole group of individuals that are part of. that end goal that you're trying to achieve within the business level,

Ida Rolek-Kononiuk: right? 100. Yes, yes, you're, you're very, very much right. So the team that reports to me, I'm basically just supporting them and I'm conveying the business goals and interpreting those business goals and translating them for the team.

But my personal goals will very much be tied to. Correctly translating the company goals into what those teams are supposed to do, and then engineering managers or team leads will then translate and interpret the goals I'm setting for technology to their own teams. But once again, their success, I cannot imagine a team leader hitting all of their goals whilst every person reporting to them fails to achieve theirs.

It is an extension. There is that buildup and it's whole a pyramid where a person who seems to be a team leader actually is supported by the people who Report to them. [00:26:00] And I can only succeed if people reporting to me succeed in their goals as well. Mm-Hmm. . So that's how, how I, how I see this structure.

But then we also have, quite rightly so me as a leader of a team or of a department, I don't, don't only have people who report to me. I have my peers. So I have to manage sideways. And then I have people above me. So, so my boss and, and then people on his level. And there is that question of how my goals tie to their goals?

And can I represent my successes, my goals being hit correctly? Can I shape my goals in a way that if all of the people reporting to me had their goals, and they did very hard job, and they did very well, how can I then represent that and channel it upwards and showcase all of that success as a success for the whole department and the goal hit by like whole technology?

that this, you know, zero failure for a year. Perfect. That's what we had. No, not a single bug on the production for a year. Perfect. Tech work. You hit that goal. And [00:27:00] that's the moment when you want to sing about it to your bosses, because it's a measurable thing that you achieved with all of the people reporting for you.

Sideways, it's a bit different. Like how do we sing the roles between Technology and finance and technology and people are slightly more complex, but still if we work in one company towards one goal, we don't work in separation. There is that sort of thing. There is finance, supporting recruitment, finance, supporting growth of infrastructure, making sure we have money for the growth that is necessary, making sure it's all planned well and spent well and wisely.

So it all aligns

Aaron Rackley: as well. Interestingly, like we said there, one of the things that. It's always apparent is that the company has its goals. It has its KPIs and they're normally very known, um, in, in a corporation or a business, you normally know what those are. Um, I was also reading another thing that was like a 50, 50 split in the blog posts I found was around how.

How much of your [00:28:00] goals you should share amongst everyone. So some places were like, everyone should be open, everyone should be talking about goals so that everyone can help achieve each other's goals. And some places were like, Oh, no, hush. So where do you sit on that? Oh, that's

Ida Rolek-Kononiuk: a big, that's a big thing.

Um, so in the past, I was one of the people I share my goals openly, and I try to phrase them and think about them in a way that I'm an no point of time I should be in any way ashamed or embarrassed about my goals. If I'm If I have to make some tough decisions, I'm making tough decisions because it will ultimately drive certain success and will allow company to be more successful and all of us to be more successful.

And most of my goals always are joyful. I see them as a productive, optimistic, optimization things, which I'm very happy to share with people and share my progress. I can imagine in some departments, it's maybe more tricky. I'm trying to think what I could imagine some people having goals [00:29:00] that may be sensitive, or they may show point out things that aren't perfect.

And maybe it's not, it wouldn't be wise to mention it out loud in any way that, you know, we want to improve from this to that. Maybe it's better not to say what are we improving from. So let's, let's powder after that. But no, I'm a firm believer that if we publish our goals, and we share them, we can then find groups of people who have very similar goals.

Even once the goals and objectives were trickled down, interpreted, calibrated, and you set your own objectives, you will then find other people in a company who have exactly the same objectives and you can help each other. If so, you wish, if you'd like to work

Aaron Rackley: together. Yeah, no, it's interesting. I find that a lot of stuff that I bring people on the podcast to talk about, there's always the competing sides, right?

So I think one thing I'll be looking at in the future, the podcast is getting multiple people on for the same topic, but from different sides so that we can, [00:30:00] because the whole idea of this podcast is to aim at people just starting in a role, right? And I am a firm believer in that to fully understand the subject matter, you need to know all sides of that conversation and understand why people have the thought process they have.

So it's interesting to hear your side. I'm excited. I'm excited to go away and start thinking about. My, um, goals for the year because I've got the message like past week that I need to start sitting down and filling in my form on my, um, on my app at work and I have to start thinking about getting the goals from my team as well.

So it's been really helpful for this insight in. your thought process. Is there any more areas you think you'd want to cover? I think

Ida Rolek-Kononiuk: we went through most of it. I think probably the last part would be to not worry about the goals, just not working over time. And I think both managers and individual [00:31:00] contributors should easily entertain an opportunity to just edit the goals during the year.

Once you set them, they aren't set in stone, I believe they are flexible. And if if the things change, if you change, if your plans change, if your hopes change, and the expectations around you change, you can always come back to it and you can change it a bit and you can edit your goals and that's okay as well.

Aaron Rackley: I think that's the important takeaway I think of all of this right is that yes we have to set goals for a lot of these companies they require them and they are there but just remember to just take it easy don't get too stressed out and you can always adapt them right.

Ida Rolek-Kononiuk: 100 percent it's not, it's not a plan that you have to execute on and someone will hold you accountable to every single word.

There is spice, there is spice for flexibility. And I hope you'll have a great time setting your own goals.

Aaron Rackley: Well, I appreciate you talking about that. But before Um, we end the conversation. I [00:32:00] like to ask all of my guests one question, which is, I have a bookshelf behind me with a load of books on it that I buy from.

I get a recommendation from every guest, and then I go out and buy that book and read it. And it can be any book, it doesn't have to be tech related, it can be your childhood favourite story. But um, what book would you recommend to someone to read?

Ida Rolek-Kononiuk: I will go with Turn the Ship Around. Turn the ship around.

Is it already on your, on your bookshelf or

Aaron Rackley: not? It's not on the list, no, but I have heard a bit of it before. For our listeners, would you like to tell us about the book?

Ida Rolek-Kononiuk: Softenley, it outlines and follows a particular person in American, in the Navy, um, as he takes the leadership of a, of a ship. and approach as to how to empower people and how to empower the whole ship to function when you can't really see and micromanage every single bit.

So how to let go. It's that important [00:33:00] moment in your career, where you just start to trust people and you are okay with the fact you don't know everything, and you will never know everything and people will do things and you just have to trust them to do it. Well, and how do you build that relationship with people where you know about the important things, but they also feel they can do a lot themselves independently.

And it's okay, it's about intent, it's about communication, it's about taking responsibility. And it really allowed me to grow as a leader. And to move from having a full control of everything I do, like writing code, and you know what the results are, to working with a living, breathing organism and multiple human beings, who will do a lot of things I will not know about, or who will have knowledge and experience I I will not own and it'll be theirs and they'll do things and I will be fine with it and being responsible for such a thing, especially when you are in the military and like seeing it from a perspective of life and death as well as like for me, it [00:34:00] really changed

Aaron Rackley: a lot.

Yeah, I think the military is very good at producing. stories and books around leadership and management because they they've got it, they've

Ida Rolek-Kononiuk: got it right in many places. Yeah, like a lot, a lot of depends on it doesn't it? So I think that yeah, they did it quite well. They do it quite well, quite often. And I think American military spends a lot of time thinking about leadership and particular growing leaders.

And yeah, and it's, it's a great book. I recommend it. There is even I think a Warwick book with exercises if you a person would like to do it.

Aaron Rackley: I would definitely, definitely purchase it. Um, I have heard of that book a couple of times from other people, not on the podcast, but I have heard of it. So definitely add it to list now.

And, um, so before I let you run off, um, where can people find you online if they want to chat

Ida Rolek-Kononiuk: about LinkedIn? LinkedIn is the best place.

Aaron Rackley: Yep. Okay. I'll put that into the show notes. So again, thank you for coming on, talking about this. It's. [00:35:00] I'm excited to, to see where my goals go this year.

Ida Rolek-Kononiuk: Thank you so much.

It's been a pleasure. It's been a pleasure to have this chat. Thank you. Thank you.

​

Today we are in conversation with Steve Dwire, an Entrepreneur and Technology Leader Professional Coach and we explore the topic of personal growth and how you as a leader can take the time to step away from managing others and take the much-needed time to reflect on yourself.

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Steve Dwire

• www.stevedwire.com
• https://www.linkedin.com/in/stevedwire/
• https://twitter.com/SteveDwire

Book Recommendations:

• Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones by James Clear
• Atlas of the Heart: Mapping Meaningful Connection and the Language of Human Experience

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

10-steve-dwire-

Aaron Rackley: [00:00:00] Hi, everyone, and welcome to this episode of the Tech Leadership Decoded podcast, the podcast where through conversations, we unravel the intricacies of leadership in the tech industry, provide insights on how to become a top performing leader. Today, we are in conversation with Steve Dwyer, an entrepreneur and technology leader, professional coach, and we explore the topic of personal growth and how you as a leader can take the time to step away from managing others and take that much needed time to reflect on yourself.

But before we can start the conversation, can I ask a quick favor? If you like this conversation and the podcast as a whole, please do remember to subscribe on your favorite player and share a link to this episode on your social media sites so we can reach even more amazing technology leaders like yourself.

Thank you. And with that, let's just jump straight into today's episode. Okay, and thank you for joining me today, Steve. Hope you're having a great morning for you, evening for me. Thanks so much, appreciate

Steve Dwire: being invited.

Aaron Rackley: Yeah, thank you for coming on [00:01:00] and today I've got you on to talk about Um, how can I work on my personal growth as a technical leader, um, but leader, technical leader in brackets, um, but before we get into that conversation, do you just want to give everyone your five minute, this is your life intro?

Sure.

Steve Dwire: Um, so I, I spent probably a little over 20 years leading software engineering and it teams in the corporate world. Uh, everything from a tiny little startup to a fortune 100 company. And what I discovered during that time is that most engineers weren't prepared for that internal change that they needed to be successful as they moved up in leadership, myself included.

You know, I wasn't prepared for that. And many of the people who promoted me were focused on [00:02:00] their own deliverables. They didn't really know how to coach the leaders who reported to them. Or maybe they had too many direct reports to truly be able to invest in us. Or they just assumed that we already knew how to lead or we figured out on our own.

You had, um, Kevin Ball on, um, back in episode three, I think it was. And he talked about growth focused management, but the unfortunate reality is that very few of us as growing leaders actually had or have that kind of a growth focused manager to help us figure things out. And, um, and that's the way I was, but in about 20, well, 2013, I started realizing that I wanted to do something more than just being in the corporate world.

So I started my own software as a service [00:03:00] startup and. Come 2022, I realized I can't keep doing both at the same time. So I left the corporate world focused on the startup, had a bunch of growing there as I realized that the market I was going after was underserved. Specifically because they didn't want the kind of service I was trying to offer.

Right. So it was through that, that I hired a professional coach to help me figure out what do I do with this? And through that process, I learned I didn't really miss writing code. I didn't really miss managing infrastructure, but what I really missed was having one on one conversations with. The people who reported to me and seeing them grow and change and get promoted.

And I realized I just hired a guy to [00:04:00] spend the next year having one on one conversations with me. This is a profession. This is how I want to spend the next chapter of my life. And so that's where my passion for this personal internal growth has come from. And that's when I, when I saw your message on Slack channels that, that, that looks like a good opportunity to help people with that internal personal growth.

So

Aaron Rackley: in For personal growth, where do you think that differs from just generic professional development? In that essence, why do you think leaders need to prioritize that personal

Steve Dwire: growth? Yeah, I, I like that you distinguished professional from personal. They are different things, though there is a huge interaction between the two of them.

So when we talk about professional development, yes, that's learning and practicing of [00:05:00] specific job related skills. When we talk about personal development, I'm talking about more of the internal issues, such as a fixed mindset versus a growth mindset or things like imposter syndrome or the ability to choose one's habits more than the specific habits themselves.

So it's, it's been said that we are human beings, not human doings. And yes, there's certainly a relationship between the two because. To some degree, we do what we are doing because of who we have been being. And it's just as true that to some degree, we Are who we are being because of what we have been doing.

James Clear talks about this in Atomic Habits. He describes that circular influence between our habits and our identity. [00:06:00] And as I read his explanation, I understand that the habits are the doing. That identity is the being. And practically, all of that leadership development that I experienced in my career.

It was focused on the doing side of things. People weren't equipped to talk about the being side. A lot of companies have mentorship programs and those focus on that doing side. Uh, I think it was your very first episode. You had Aaron Fox talk about how to go about getting a mentor if you, if you want that.

And they're, they're great opportunities to learn from somebody who's succeeded. In that path that you're traveling, because that mentor's area of expertise is in that skill that you're being mentored on. Um, and, and if that's the kind of professional development you're looking for, then yeah, mentor is a great choice.

And often [00:07:00] larger companies, they will have an entire department that they refer to as learning and development. Oftentimes that's part of HR or people operations, but historically learning and development really translated into training and that was about it. And again, much of that training was focused on safety, security, legal compliance, things that a company has to do in order to manage the risk of having so many employees and even when a learning and development.

Um, topic does start to get more internal, such as, you know, let's, let's explore emotional intelligence or employee engagement or having crucial conversations, things like that. Even the internal personal development programs tend to take the form of things like computer based training, or at most a two to three day live workshop.

Some of them [00:08:00] will include periods of hands on practice or role play and that, that does help to kind of ingrain that training more than just a lecture, but it's still often focused on practicing a certain habit or a practice of doing. As we're growing as leaders, we often find ourselves stuck trying to adopt that new way of doing.

Because of. That more internal way of being, and that's where I see that internal personal development having the biggest impact because even a group workshop over a period of a few days, it's just not structured to help a person with lasting growth in that being. So once one trend we are starting to see, and this is a positive, in my opinion, is that more and more companies are starting to bring in professionally trained coaches.

Or maybe even just [00:09:00] getting professional coach training for their learning and development team members And even some department managers are getting training and professional coaching so that they're equipped to help team members with those internal changes that will help them succeed. And so that helps fill in the gap that we've seen so often where executives get this kind of coaching that comes from the outside to help them with that.

internal issue. And those leaders closer to the front lines tend to miss out. Well, that that's starting to change. And so that's, uh, that that's a positive trend in my opinion.

Aaron Rackley: As, as a leader, that's looking to start a personal growth. What, where do I start? What's the first thing in your journal that I should be doing that.

Sets me on the path

Steve Dwire: to the, if we look at first thing, it's really about identifying [00:10:00] what is the goal you want, you want personal growth, but for what reason I was just having breakfast this morning with the gentleman and he shared this metaphor that he's going to be presenting. Uh, coming up to a leadership group, I thought it was, it was really effective.

Try to try to envision, uh, he had a really thick rubber band. It was the kind of used for exercise or physical therapy, the big stretchy band. Yeah. Let me put my thumbs in it and stretch it out. And he said, anchor your right hand to the edge of the desk. Imagine that is your current state, and then you stretch it out as far as you can, and that's, you know, that's the vision that you have for the future, and you feel that tension.

If your right hand is anchored in where you are, what's going to happen is your vision for the future is going to retract and get pulled [00:11:00] back, and it's going to keep moving and becoming less and less. But if you can anchor your other thumb on the vision where you want to be, And you lift up the anchor from your right hand, then your current state will naturally tend to move towards that vision.

So really, the where to start is first identify what is that gap you want to close? What's that compelling vision that's going to draw you into a change?

Aaron Rackley: Okay, so discover your high level goals or find out where your goals are. And then I guess we look at finding the gaps in our Um, areas of expertise or areas of interest or whatever, and then try and find places to fill that knowledge?

Is that, am I reading that right?

Steve Dwire: Right, that, that, yeah, that's a, that's a good high level. Often, you know, when I'm, when I work with somebody, I will start [00:12:00] with an assessment that really helps people get a clearer picture of the inside of them. Um, okay. There's a, there's a saying we kind of live inside a bottle and when you live in the bottle, it's really hard to read the label.

Uh, so it's clever. It's helpful to get somebody outside and that's where a professional coach or somebody with that kind of training is very helpful. And so different kinds of assessments are helpful for that, to be able to explore, what are your strengths, what are your interests, uh, what are the, the things that you've, that you personally find fulfilling, what's your satisfaction level with all these different areas, because sometimes, especially in the, In the corporate environment, when we're thinking about personal growth in a professional environment, we tend to wear these blinders and focus only on professional development in [00:13:00] the corporate environment and not think about the impact that physical health Relationships, family, financial freedom, spiritual health, mental health, all of those different things have an effect.

And so spending the time to actually investigate all those different areas and say, how, how satisfied am I with these areas and identify not just the skills gaps, but The fulfillment gaps and then look for the patterns about where, where are some things in common and then identify of those areas, where are the areas that I feel compelled now, having seen this, where do I feel compelled invest.

Where it's not, it's not going to be [00:14:00] my boss or some, um, some website that says here is the effective way or the best way to do something. It's not going to be some standard driving me toward that improvement. It's going to be a personal attachment to that goal that draws me to it. So identifying those areas would be that next step.

Aaron Rackley: One thing, what I'm hearing is like personal growth obviously involves kind of like stepping out of your comfort zone, um, and into something that you're not either not used to, or you're afraid to, to attack really. Do you have any kind of like advice that you could give for people for like trying new approaches, taking risks?

Um, that kind of aspect,

Steve Dwire: I'm trying to remember the exact phrasing, but it, it, it is something like the treasure just to remember the treasure that you're after is in the place that you're [00:15:00] afraid to go. Okay.

Aaron Rackley: That's very interesting. I'll definitely look that up to see, no, it

Steve Dwire: was something like something like that.

But I mean, you, you picture a cave, um, that, that you're, you're afraid to enter into that area. But, uh, the most compelling visions are, tend to be on the other side of it and it's when we are only half heartedly interested in the goal that it's so easy for us to let go of it and stay in our comfort zone.

So back to that metaphor that a gentleman presented to me just this morning at breakfast. If your anchor is current state. You're constantly looking at, well, this is the way things are. This is who I am re looking at with a, what we call the fixed mindset. So many of the assessments that I've seen, like to put [00:16:00] labels on people, you know, the, the disc, you know, oh, I'm a, I'm a high C on the DISC assessment, or I'm an INTJ, or I am a, I'm a number four on the Enneagram, or whatever, whatever it is.

I personally don't like the assessments that put labels on people. It, a lot of people, it works for them, but for me, that label tends to emphasize and reinforce that identity that's associated with current state rather than keeping that focus on, well, this is, this is the area I want to be at. This is the goal, constantly reminding yourself of that goal gives that draw to take those steps into those comfort zones.

Out of the comfort zone. Excuse

Aaron Rackley: me. Yeah. Earlier, you mentioned a couple of phrases that I think would be interesting to just mention because we haven't heard of them so far on the podcast, which is, [00:17:00] um, fixed and growth mindset and imposter syndrome. And could you just quickly explain like in a couple of sentences, what each of those mean so that we can.

Uh, see how that affects your personal growth.

Steve Dwire: Sure. Um, fixed versus growth mindset. And the, the science on this is, um, I don't wanna say the science is changing, but they're discovering, um, discovering new things around this arena. But generally speaking, a fixed mindset is one that says, this is who I am.

My identity is fixed. And you're just gonna have to learn to deal with it, because this is who I am. Um, and I can never Accomplish whatever, because, for example, back in 2013, my identity was, I am a software guy. So, if I'm going to start something new, it's going to be by developing software and building that, because that's who I am.[00:18:00]

But a growth mindset is one that recognizes, I can look ahead, and I can set a goal and have a dream that's bigger than who I am today. And I am capable of becoming that person, even if that's not who I am today. Yeah. Imposter syndrome is somewhat related. Uh, the way I like to describe it is many times when somebody becomes a manager or especially when they become a manager of managers and they're, or they're, there's, they're the director and they go to that first staff meeting.

With the other directors and that feeling is I finally have a seat at the table But I feel like I don't belong here. Mm hmm and The result is that that person they show up at the meeting and they stay silent [00:19:00] they're not ready to voice their perspective and What happens is the company misses out on the value of a perspective that comes from the peoples and the teams and the, or the product line or whatever their area of responsibility doesn't get represented.

Because they feel like everybody else has this figured out. And I'm the only one who feels like I have no idea what's going on. And especially moving into people management skills, when you thought you just got promoted, and you discover that you actually completely changed careers. That entering into that, especially when you Didn't get the kind of training and coaching and reinforcing that is starting to become a trend.

Now you enter in, you think, well, everybody else knows how you're [00:20:00] supposed to have one on ones. Everybody else knows how feedback is supposed to work. All of my peers have this figured out and I'm the only one who doesn't know. And I'm afraid to ask any questions because I don't want people to realize that I'm a fraud.

And that. belief, that fear of being found out as a fraud is one of those things that keeps people from progressing in both personal growth and in professional

Aaron Rackley: growth. Yeah, I think this is something I've, I've noticed over the very short years that I've been alive and working. But um, is that a lot of companies, a lot of people are in the positions they're in because they've grown with the company or they've just naturally progress through their career, but like you say, a lot of companies are not set up to help you when you progress to the next stage.

Um, and I think if there's something to tell anyone that's listening, it's that. You know, [00:21:00] we've all been there. We all get, we all get pushed to a new role and we take on new responsibilities. And unfortunately, I'm the kind of person that thrives in not knowing what I'm, like, not understanding or not knowing things, because I like to learn.

So when I start a new role, I'm very much like, okay, I want to know everything. I'll absorb. So like this podcast, right, I go out there and I read books and I read everything I try and absorb. But I know there's a lot of people out there that are not that. Mindset and like you say have this kind of imposter syndrome that they're not ready for it But we're all in that boat and I think um, I think companies in general need to get better Even I think smaller ones.

I know that a lot of big companies have these kind of processes in place But I think a lot of smaller ones definitely need um help in just setting up these kind of like Onboarding kind of coaching, um, aspects when they move roles, if, and hopefully that means that they'll approach people like you and others who have these facilities in place.

So they don't have to hire [00:22:00] someone full time in their own organization. Right.

Steve Dwire: Especially in the smaller ones when almost every role is fractional.

Aaron Rackley: Yeah, yeah, yeah. The smaller you get, the more fractional you're all right. But, um, so I've had a quick look at your website. Um, And I'll put the links in the show notes to everything so they can go see your coaching services.

But I thought what I found interesting was that your coaching has, um, two pillars, which is alignment and advancement. And I thought that was interesting. Is there a way, can you tell us what the difference between the two is?

Steve Dwire: It's, it's really about two different goals. Um, oftentimes, especially those who are coming to me.

Individually and paying for their own coaching. Yeah. Sometimes they're looking at their role at their job. And they're saying, I don't know if I even want to be here. I don't know if this is the right [00:23:00] place for me. And they are exploring possibly even changing careers, changing jobs. And so that's very much more of a personal development side of things.

And so that, that's what we would explore during that coaching engagement. Or for those who say, I know this, or I believe this is where I want to be. And I want to get promoted. I want to be able to advance. Um, but either. Um, I haven't had the opportunity or I don't believe I'm ready or I think I'm ready, but nobody else seems to be noticing that.

And I keep getting passed over for promotion. So that would be that other, that other pillar, the, the approach and the tools and the techniques are really the same. It's just recognizing two different kinds of future state that people are to achieve.

Aaron Rackley: Okay. Interesting. Um, so. [00:24:00] I imagine that on my journey of personal growth, um, I'm on my own one.

Part of this podcast is part of that journey. Um, but you're gonna inevitably be hit with setbacks, you're gonna face challenges. You're gonna, there are gonna be some tough points. Do you have any, uh, like techniques on how we can turn those negative or Into like a positive experience or how can we get the best from it?

Steve Dwire: Well, first of all congratulations for stepping into that discomfort zone and starting the journey I think that's one of the biggest things that people fail at is even taking that first step. You've taken more than that first step because you've, you've reached out. I am not your first podcast guest.

You know, you've, you've, you've been exploring that. The second thing is something that you have already recognized. You [00:25:00] said it yourself. We all experience these things. These setbacks are common. Everybody faces the setback. I love a quote from Zig Ziglar. He says, and I'm saying this from memory, so it's going to be something like this.

But it's, failure is an event. Not a person. Okay. So the failure is something that happened. It is not who you are. You're not a failure. The experiment didn't get the results that you hoped it had. Um, yeah. And so remembering that, and I even hesitate to use the word failure because several different people who come at this different way, Oh, embrace failure because, because unless you fail over and over again, you're never going to get to success.

And other people say, Oh, it's not failure. It's just [00:26:00] learning. And when they, they choose not to use the word failure, just because for many people, it has an emotional component to it, whichever way you choose to use the word failure, when you do experience that, you use the word setback that experiment that.

activity that didn't have the results that you were hoping for.

Just ask yourself, what do I learn from this? And what will I do differently as a result of what I just learned? Um, I just posted, uh, this morning, uh, article about feedback and how when we look at feedback, As a past focused exercise, then it can drive that negative spiral. But when we are disciplined to look at [00:27:00] feedback as always forward looking, always in terms of what future behavior are we going to encourage as a result of this, it helps re anchor that attention on that goal that we're trying to achieve.

And as long as we keep that goal anchored back to that image of the, that stretchy band from, from this morning, then that will draw our current state closer towards that, that goal that we've envisioned for ourselves.

Aaron Rackley: Yeah. I think, um, I think on, it must be Instagram, Twitter, one of those social medias, I still like an image.

that had someone said, um, how did you get so good? And they said, experience. They said, how, how did you get the experience? And they said, I fouled a lot. I think that was, I thought that was very interesting because it. Yeah, whenever I, I listen to a lot of podcasts around, um, [00:28:00] like people that have started up businesses or have eventually got successful business.

And they always say the same thing. A lot of them have in common is that they tried multiple things, they tried a lot of different avenues, and it was eventually the one that stuck, right? Or, you know, because they learned a lot from mistakes they made on other ones. And I think that's, I think that's true in every.

Every walk of life, to

Steve Dwire: be honest, there's a podcast that I listened to the way where I cut my teeth on the doing side of management is called manager tools. Okay. And one of the things that they, um, one of the hosts, his name is Mark Horstman. And he would say this frequently. He said, um, good judgment comes from experience.

And experience comes from bad judgment.

Aaron Rackley: That's really good. See, I like it. I like that a lot. I'm definitely going to add that one to my Twitter. Um, so I think, um, obviously it's an ongoing journey. Um, and it's, [00:29:00] it's not going to be something that's going to happen overnight. And I imagine it's going to be, I imagine it never stops, right?

I hope not. Yeah. Um, how Can someone track their personal growth and ensure, like, and kind of see that they are improving, because I think sometimes you as an individual find it very hard to notice the change. Um, like for me, I only notice a change in mine is when I'm actually having conversations with colleagues at work and I'm starting to.

impart knowledge that I've learned through the podcast or through other stuff. And that's where I'm starting to pass that knowledge on. And that's the only time that I reflect and notice that I've changed. Um, and for example, I'm a, I have a few neural challenges. I am ADHD and I'm slightly bipolar, so I am quick to judgment and I'm a quick to kind of Come to a conclusion on something which is not [00:30:00] necessarily the positive and um, I think in the short time I've been doing the journey for last year is My fiance even said to me the other day that for one of the first times in a long time, we'd had a conversation about sign and it was the first time where I hadn't, I'd, I'd been too calm.

She was, she was confused by how calm I was on the outcome of the conversation. And I said, I think generally that's because of what I've been learning and trying to self reflect over the year, but how is there some tools that other people can use, um, to reflect?

Steve Dwire: There are a lot of different ways. I think I mentioned Often when I start an engagement from coaching, we will start with a, an assessment.

Yeah. So there, there are formal assessments that you can go through and then repeating that assessment. So if, if we'll have a six or nine month coaching engagement, start with an assessment at the beginning, [00:31:00] you figure out what goals you want to work on and then at the end, take the assessment again. So that's a very formal way to be able to see it.

Um, but it doesn't have to be that formal for many people. Simply the exercise of journaling, uh, and establishing a habit of journaling. And I go back and forth on this. Sometimes I am extremely, extremely faithful. I am going to journal absolutely every single day. And then I'll go for periods and not journal at all.

And, you know, I don't want it to become the, um, the dictator. Yeah. It's a tool to serve me. I'm not serving it. Yeah. But that's, that is another way that you have a written record of this is something that I was struggling with, and you can go back to that journal. I actually have multiple journals, one that's more for taking notes in meetings and conversations, [00:32:00] and another one that is strictly self reflection.

For whatever reason, I've chosen a red. journal, a red Moleskine journal. Well, we could

Aaron Rackley: look into that another day. What's that? We could look into that another day for the meaning.

Steve Dwire: I have no idea what it means. It may have just been, it was the one that was on sale at the time, and so that one will be, I'll reserve that one for a personal introspection journal.

But, but that's a, that's another way just to. To have an opportunity to look back at what you've documented about how you were feeling over the past, but another way that I'm experimenting with and it's, it's

almost taking a software development strategy and applying it to personal development and that it's, it's almost like the, a [00:33:00] sprint A scrum like sprint, but for me, I'm still experimenting with this. I have a, a form that I've put together. I've only been doing this for two weeks. So, still early experiment, but it's, it's writing down very specifically.

These are the goals that I want to accomplish in these two weeks. These are the daily habits that I expect are going to contribute. to accomplishing those goals and then tracking on a day by day basis how well did I do according to those to those habits. And after the two weeks I'm actually re evaluating it because I'm recognizing that there are Even in the goals, we have both output goals and outcome goals.

Yeah. And habits can contribute more directly to output goals, and outcome goals are going to be over a longer period of time. And so my current approach [00:34:00] didn't reflect that distinction. And then I have some daily habits that I just want to be a part of who I am. And so those are always there. And then there are other daily habits that are more specific to this two weeks.

I didn't have that kind of a distinction yet, but something, I mean, if you're really, really looking for, um, a repeatable way to look and see what kind of progress have I made. Having a tracking sheet, uh, I actually made it in Excel and printed it out so that I could have that physical experience of marking the yes or the check.

Yeah. And then scribbling notes in different places, things that I've learned of how I want to do things differently for the next two week period. But that, that's a way if you're really looking to be, what's the word I'm looking for? Not mechanical, but very probably pragmatic, very, [00:35:00] yeah, very, very pragmatic, very logistical.

Yeah,

Aaron Rackley: I think, yeah, no, I've, I keep hearing about journaling and this habit tracking. Um, I've heard it multiple times now over the last few months. So, um, it's definitely something I need to try. I, um, I've not been, I've tried to have a journal in the past, but I've never been successful. But now. With the growth that's going on, maybe it's time to give it a go, another go, see how it goes.

Um, awesome. Now, it, I, and

Steve Dwire: I, I would challenge the statement, I've never been successful. If I can. Yeah, go for it, yeah. You said you've tried a journal. Have you written a journal entry? Yes, yes. So you've been successful?

Aaron Rackley: I've been successful in that sense, yes.

Steve Dwire: Now whether it's, whether it has accomplished what you've wanted to accomplish, or even if you knew what you hoped to [00:36:00] accomplish by it.

Yeah. That might be a different question to explore for a future iteration.

Aaron Rackley: Yeah, yeah. Self reflection. I think, I think it never had a purpose. So it was never something that became a habit. So it never became, in my eyes, useful. So, yeah.

Steve Dwire: An illustration of that difference between being driven to do something, because you read somewhere that it was a good thing to do, versus being drawn to do it because it's bringing you closer to a goal you want to achieve.

Aaron Rackley: Yeah, awesome. Now, I think that's the perfect place to, uh, to wrap up, uh, the personal growth, uh, conversation, but there is, there is a lot to unpick in this, this area. So maybe, hopefully, you could come back on another time and we could delve into a bit more. But, um, obviously, you've listened to my podcast.

So, [00:37:00] you know what's coming. Um, I ask everyone that comes on to recommend a book. Um, it doesn't have to be around this area, it could just be your favourite nursery rhyme book from when you were a kid. Um, so yeah, do you have any favourites you could recommend?

Steve Dwire: Um, okay, I heard the word favourites, so more than one is okay?

Aaron Rackley: Yeah, more than one's fine. I had someone I think do five, so I've got, yeah.

Steve Dwire: Um, so in the area of doing, I would say James Clear's Atomic Habits. Um, because he does explore that interrelationship between the doing and the being and that has been, you know, it's, it's, it's not going to be some hidden gem. I mean, a lot of people probably already heard of that one, but atomic habits is a really good one.

Great book. Yeah. And then on the area of being, this is not [00:38:00] a. Mind blowing. Oh my goodness. There's so much insight in here book, but it was, it was fascinating to me just to expand if we can expand our vocabulary around internal understanding. I think it gives us a lot more flexibility, a lot more fluency.

In being able to understand internal growth. So, uh, Brené Brown recently published a book called Atlas of the Heart, and it explores the various shades of color of emotion. That we experience under different circumstances and then being able to recognize the distinction between different things that we often lump under the same thing.

And so Atlas of the Heart is, I just found to be a really fascinating read.

Aaron Rackley: Awesome. I will, I've already got atomic habits, [00:39:00] but I'll definitely be adding the Alice of the Heart to the book bookshelf. Um, and before you go, um, where can everyone find you online? Company

Steve Dwire: website would be northwayinsights. com Also Northway Insights on Facebook, Instagram, LinkedIn, or Steve Dwyer.

D-W-I-R-E. It's a weird way of spelling it, but, um, steve dwyer.com or Steve Dwyer on Facebook, Instagram, and LinkedIn. Okay. And all the social media. Yeah. I basically share the same thing, so . Fair enough. Awesome. You, you go to one and you'll

Aaron Rackley: see it all. . Yeah. Awesome. Now, obviously, thank you. for coming on and I hope that you can come on again in the future.

Um, to talk more about this, but yeah, thank you for taking the time.

Steve Dwire: Alright, and thanks for the invitation, and thank you for your boldness in stepping out in this growth area that's helping a whole bunch of other people. Thank you.[00:40:00]

Aaron Rackley: Hey, thank you for making it all the way to the end of today's episode. It really means the world to me that you've made it this far. I really do love making these episodes, and I'd love to make even more. So please, if you have two minutes to spare, can you share this podcast on your social media sites?

Or even point it to a guest you think would be great to come onto the show? And if you are one of those guests and want to come on, please reach out at contact at tech leadership decoded podcast. com. And until next time, have a great day and I'll see you soon.

Bye.

Today we are in conversation with Andy Skipper, Founder and Chief Coach of CTO Craft and we talk about what is a CTO Coach and what does it take to be a good CTO.

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Andy Skipper

• www.ctocraft.com
• https://www.linkedin.com/in/andyskipper/

Book Recommendations:

• The Five Dysfunctions of a Team: A Leadership Fable (Patrick Linceoni)
• The Advantage: Why Organizational Health Trumps Everything Else In Business (Patrick Linceoni)
• Punished By Rewards (Alfie Cohn)

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hi, everyone, and welcome to this episode of the Tech Leadership Decoded podcast. The podcast where through conversations, we unraveled intricacies of leadership in the tech industry and provide insights on how to become a top performing leader. Today, we're in conversation with Andy Skipper, founder and chief coach of CTO Craft.

And we talk about What is CTO craft and what does it take to be a great CTO? But before we start, can I just ask a quick favor? If you like this conversation and this podcast in general, please do remember to subscribe on your favorite player. And then if you have two minutes, can you just share the link of this episode to your social media sites so we can reach more amazing technical leaders like you?

And that's it. Thank you. And with that, let's get into today's episode with Andy. Okay, and welcome Andy and thank you for joining me today on the podcast. You're having a great day Um, so yeah, we are here today to talk about What a C T O coach is [00:01:00] and what C t O craft is. Um, but before we get into all of that super fun stuff, do you just wanna spend five minutes just explaining who you are, your experience and how you came to be part of C T O Craft and a C T O coach?

Andy Skipper: Yeah, of course. So I'm a, I'm a technologist by background, so I was mm-hmm. . A developer for many, many years, mostly in the startup world, various digital agencies, um, and then became a, a CTO kind of by accident in one of the startups I was working with, um, in that they didn't have any kind of leadership within the technology side of the business.

Uh, so I, I kind of filled a bit of a void there. Um, and since then I've been CTO, uh, gosh, um, too many companies to, to remember. Um, at some point I, uh, I decided to, uh, to go the fractional route. So it was a fractional CTO, [00:02:00] um, for a while and, um, and actually had a consultancy, a group of. Fractional CTOs that I was helping find work.

Um, and I found that more and more of the, the fractional work that I was doing personally was actually either coming in to replace a, a CTO who had burnt out or hadn't been able to scale with the business or just hasn't worked out or coming in alongside someone like that and kind of supporting them in.

Growing into it and, um, and finding their way a little bit. And so I, I decided that was the part of the role that I was enjoying the most. So I'd kind of doubled down and, um, and that was all I did for, um, for a few years, um, as CTO craft kind of came about as a platform for the people that I was coaching one to one.

Um, and this was back in 2017, um, and it's grown from there basically. So it started off with. Know a hundred people or so [00:03:00] in London. Um, and it's now just over 12,000 people all around the world. Mm-hmm. . Um, and, uh, yeah, it's great fun.

Aaron Rackley: Oh, awesome. Cool. So I think we should start at the beginning of like, what do you consider to be a C T O in, in your, in your definition of it?

Andy Skipper: Yeah. It's, it's a really interesting question because I think that, um, If you were to ask that question of an investor, they would probably have a pretty static answer to it. There'd be one specific profile that they think of, but in truth, it's very different depending on the stage of the company, the kind of industry they're in, um, the kind of person, you know, so there are some CTO archetypes.

Like you get CTOs who are very, very technical and they stay hands on. Um, well, there are CTOs who are more strategic, more visionary. There are CTOs who [00:04:00] are more operational and you get CTOs who are more people focused. And the truth is that companies kind of need different profiles of CTO at different times in their lifetime.

But the, the one thing that kind of glues them all together is that they're all theoretically, they're all the apex technologists within their company. They're all top of the food chain. As far as the technology is concerned, so they, that they're where the buck stops essentially for technology stuff.

Aaron Rackley: Okay. And you mentioned there in your little introduction about being a fractional CTO. Now, can you, what does that mean?

Andy Skipper: So fractional CTOs or fractional C anything Os, they're basically, um, they, they work on a portfolio of clients and typically they'll work more on an advisory and a guidance basis rather than operational.

But [00:05:00] where, um, where companies see the most benefit from having someone like a fractional CTO is where they want someone with a lot of experience, um, but don't have the budget to pay for somebody full time at that kind of level. Um, or they have someone slightly more junior or a first time leader within the company who needs some kind of support to avoid the pitfalls and, um, and make the best choices.

Um, so yeah, as a, as a fractional CTO, you could be working for a company. Two days a month or you can be with them four days a week, you know, it's very variable But the the point is that you're working with many at the same time. So it's having a Portfolio cto career.

Aaron Rackley: Okay. Um, what do you think? um, the biggest challenges are for Uh people becoming a cto like taking their first role into that c [00:06:00] cto suite Uh, seat, sorry, not suite, seat.

Andy Skipper: So, um, I would say typically it's because when you first hit that kind of role, especially if it's in a, a smallish startup, usually come up through being a very, very good developer. You know, you might come up through being a good developer, then an engineering manager, then et cetera, et cetera, until you get CTO, but typically.

You're not too far removed from actually developing code. And the problem is that the skill set you need to be a very good developer is very different from what you need to be a very good leader of developers. And I think most people and most companies don't recognize that when they're putting people like that into a C level position.

And so there's, there's not a lot of support. You kind of have a whole new load of skills to, um, to build. You know, you're, you're on the critical path for the success [00:07:00] of the company at a C level. And so, um, that, that's where problems start to happen. You see a lot of burnout in first time CTOs. Um, and yeah, obviously they have reasonable budgets.

They have reasonable ownership of, um, of, you know, large parts of the, the company's outgoings in terms of development teams that they might not have experience with. Et cetera, et cetera, but it's getting past that hurdle and recognizing that it is a new set of skills and it's not an evolution of being a very good developer.

Aaron Rackley: And I guess that leads us to kind of like what CTO craft is and what you do as a role, right? So like that's where a CTO coach would come in to help. I

Andy Skipper: imagine. Yeah, absolutely. And so, um, both coaching and, uh, peer validation or community validation, I'd say that's, that's the biggest. Benefit that I had when I was coming out through being a developer and a [00:08:00] CTO, or rather I should say it's what I didn't have because there wasn't a community like this at the time, but it's, it's being around other people who are going through the same kind of struggles as the same kind of learning journey.

Um, and then also having access to much more experienced CTOs. Um, who, uh, who can kind of guide you down certain paths or help you set goals, et cetera, et cetera. Yeah, that's it.

Aaron Rackley: So I, so for me, for example, I'm a technical leader at the moment for the company that I work for. So if we use me as an example and I career trajectory, I want to become a CTO.

Like what, what kind of things should I be focusing on? Cause obviously up until this point, the focus has been mainly, like you say. Being a very good individual contributor to the code based, you know, designing systems and stuff. So what, what's the What's the pathway now, like what kind of things should I be focusing on in that, in that field?

Andy Skipper: So the two biggest things I would [00:09:00] say you should be focusing on to kind of get to that C suite level, executive suite level, are commercial understanding, getting much more involved in the strategy and the objectives of the business, understanding what the different parts of the business are doing, how they will feed into the success of the business.

Because as a CTO, You kind of need to understand what shape cog you are to fit into that machine to help it keep turning and keep succeeding. Um, and that, again, that's, that's one of these skills or understandings that you don't get when you're taking a backlog and developing and putting, putting features out, essentially, you don't get as much exposure to that.

Um, and the other thing is communication skills and people's skills. So absolutely at that C level, even if you are still hands on, there's going to be quite a lot of, um, people management stuff. There's going to be negotiation. There's going to be [00:10:00] HR related stuff. There's going to be. stakeholder management, there's going to be presentation of technical stuff or communication of technical stuff into a form that non technical people can understand.

Um, but it's those two being more commercial and being more, more aware and proficient with your communication skills.

Aaron Rackley: So as. As a CTO coach, what kind of things, uh, do you see in people that make them successful in a CTO role over the ones that potentially go down that route and kind of, I don't want to say fail, but move out, move away from it because they didn't like it or whatever reason.

Yeah.

Andy Skipper: Yeah. There are a few things. I mean, one of the things definitely is, um, energy management. You know, one, one thing that is very prevalent in the tech industry, especially among the male side of the tech industry. Which is still by far the biggest side, [00:11:00] obviously, um, is this propensity to take on more work and, um, and not pay attention enough to the resources you have on a personal basis to get all that stuff done.

So then, as I said before, there's a lot of burnout, um, not just in CTAs, but also the levels directly underneath them where you feel that you should be capable of. Figuring out every problem or making every decision correctly. The first time should be capable of being everything to everyone. Essentially

Aaron Rackley: is the different level of how removed a CTO has become from like the technology ecosystem.

I find it, it's been so varied. So I, I think it'd be interesting to ask, like, do you think as a CTO being really on the pulse of everything is still important or. Is it the other side that's more important? Like you said, the commercials, [00:12:00] like where, what do you think? Is there a balance?

Andy Skipper: Yeah, there's a balance, but as I said before, it's very different depending on what kind of company or what size company or what stage company you're in.

You know, I think it's fine to be very, um, hands on or at least being completely aware of all the different parts of the infrastructure or the architecture. Knowing who to talk to, to find out about the stuff that you don't know is, is very important in those situations, but yeah, at, at later stages or as the team grows, um, you, you just can't be on top of all the, the implementation stuff.

It's just impossible. Um, you know, I, I don't think there's a specific kind of concrete inflection point that you hit, I think it's different for every company. Um, but certainly a CTO should expect eventually to be quite abstracted away from the day to day coding stuff. At [00:13:00] some point,

Aaron Rackley: okay, just a minute ago, we were talking about what makes, um, a CTO successful, but what on the flip side of that, what do you think a biggest mistake someone as their first CEO makes?

Andy Skipper: So CTO, sorry. Yeah. Yeah. So, so, um, a big mistake that I've seen many times. is staying too embedded within the engineering team or the people underneath the CTO. You know, it's there, the whole concept of the first team that from the, um, the Patrick Mencione book. Um, that talks about your first level of responsibility is actually being to the leaders in different functions who are alongside you rather than to the people underneath you.

And, you know, especially if you've been promoted up from being a developer, being part of that team, that can be quite difficult and you can stay very protective of those [00:14:00] people. You can be biased towards decisions that favor those people. Et cetera, et cetera, et cetera. Um, so that that's a mistake I see quite commonly that they don't pay enough attention to what the other parts of the business actually need from technology and focus on the needs of the technologists.

Aaron Rackley: Okay. Yeah. Interesting. So let's talk about CTO craft. So can you give us an overview of what that is and how it breaks down and why even just someone as me, who's. Technical, technical leadership wise, it's important, but definitely for a CDO.

Andy Skipper: Yeah, sure. But it's, it's an ever expanding suite of stuff for technology leaders.

Um, the, the core of it is a Slack group, um, which is buzzing, you know, people use it for peer validation. They use it for getting feedback on approaches. They use it [00:15:00] for getting recommendations for penetration, testing companies, you know, all sorts of stuff. Um, and then alongside that we have a newsletter tech manager weekly.

We have weekly events and then we have a conference every year or two, two conferences this year for better or for worse. Um, then the, so the coaching, we do two, two types of coaching. So we've got a pool of one to one coaches who are all, have all been CTOs at some point, um, and it's kind of a, uh, a halfway house between proper coaching and the executive coaching sense.

Where it's non directional and it's more about helping people define their path and then helping them hit their own goals and mentorship where the people actually have some context awareness of leading technology teams and building products and that sort of stuff. So it's, we, we basically do a matchmaking service between [00:16:00] people who are looking for a one to one coach and.

And the CTOs who are coaching, um, and that's, that's one part. And then we do, um, something called circles, which are peer groups of 10 to 12 people who meet once a month for a guided discussion on topics that they suggest. Um, and again, that's, that's more about. Peer to peer validation, having a, you know, a fixed tribe of people that you form quite close relationships with and, um, and it's all very confidential.

So they, they rant about their situations and they offer each other solutions and so on and so forth. And then apart from, apart from all that, we also have now launched Campus, which is our learning platform. So this is more education focused. Um, and that's a, it's a, a learning community. So it's got lots of social aspects, but, [00:17:00] um, it's also got a large directory of.

Videos and content, and we're slowly, but surely adding courses. Um, so self paced things, Udemy style, uh, again with a social element. So you can discuss the topics with other people who are going through the course and that kind of thing. Um, and that's, that's been out for. Eight days and then it seems to be going well so far, but it's very, very new.

Yeah, that's it.

Aaron Rackley: Awesome. And you mentioned that you've got a couple of events coming this year. Uh, that there's not much time left in this year. Um, so. What kind of, um, event is that? Is that a conference?

Andy Skipper: Yeah, so we've got a conference coming up on November the 7th, um, and 8th, which is focused on culture, engineering culture.

It's [00:18:00] got lots of people talking about, um, Making sure the culture within their teams supports the development of the, the company, but also the development of the people. Um, we've got, uh, Michael Lopp doing a keynote. He runs the RANDS leadership Slack, um, and a bunch of other people, people from Facebook, et cetera, et cetera.

But yeah, I'd say. Two day conference in London, tickets available now.

Aaron Rackley: Well, I saw this morning. I don't think there's much left. Is there? Not many, not many. 10%, I think I saw this morning. So yeah, that's, that's good to hear. Um, cool. So I will make sure that in obviously the, the notes that we put a link to CTO craft and.

The campus and everything like that, because I've, I've had a quick look at the campus and it looks from what I've seen on it so far looks awesome. Um, I'm going to try and convince my job that part of my budget this year should be allowed to go towards it. We'll see what they [00:19:00] say. Um, so as someone who deals with a lot of CTOs, um, in your coaching aspect, what do you, what's your thoughts on the future of CTO leadership and Because I think the reason I'm asking that is because, like you say, with like startups, larger style companies and everything, I've, I've seen in some of the startups that I've looked at and talked to, it's kind of blurred almost, like not there as a thing.

So I don't know if that's just because of the size difference and whatnot, but where do you think this CTO leadership in general is? Going in the future.

Andy Skipper: So, I'd say one pattern that I've definitely seen, uh, over the last 12 months is that... Um, companies are dealing with much less resource, you know, and they have much tighter purse strings than they did 12, 24 months ago, even [00:20:00] over the pandemic, which means, you know, there are redundancies.

There are, you know, uh, paused hiring processes, et cetera, et cetera. So people are having to do a bit more with a bit less. Um, but that doesn't stop the amount of innovation doesn't stop the amount of. Um, opportunity there is, so I think it's, I think that's the biggest thing that I've seen people preparing themselves to do more with less.

Um, I think in terms of actual innovation, in terms of technologies, we'll be looking at, obviously there's the whole gen AI wave that's washing over everyone. I see a lot of, um, a lot of people. Jumping into that and finding ways of improving their business or improving their productivity, um, using Gen AI.

Uh, I don't see a point where a CTO will never have a team of developers to, to, to lead. I think that's, that's [00:21:00] probably a long way off if ever coming, but, you know, fun, fundamentally, I don't see that change to the implementation of Gen AI as being very different from. The implementation of developing for mobile devices or, you know, developing for the blockchain, et cetera, et cetera.

These are waves that come over us and leave us changed, but don't completely append things.

Aaron Rackley: Yeah. They're just coming a lot quicker and faster. Used to be decades now, then a few years now months. Yeah. Um, I'm interested in. You as a coach. So like what with CTOs, um, and what kind of, what are you looking for from someone that you want to coach?

Um, cause I'm, I'm, I imagine coaches don't just go, I'll pick it. I'll pick everyone. I imagine you can be quite, quite selective. So what are you looking

Andy Skipper: for when [00:22:00] you're... So I, I specialize. Okay. Not, not all of the coaches in the AT C T O craft do, but I, I specialize, I tend to focus on people who are struggling with stress and energy levels.

Mm-hmm. , um, you know, so I've, I've been through a burnout as a C T O a couple of times. Um, and come out the other end. So it is, it is a topic that I tend to gravitate towards, um, in terms of the people that I, I look to coach, I think it's people who are open to making changes fundamentally, I think that would be true of most coaches.

Um, we do get inbound leads for coaching from founders or even investors in some cases where they're kind of imposing it on their, on their CTOs. Yeah. Rather than it being an active process for the CTO to go out and try and find support for themselves. Um, and you know, we'll, we, we do work in that way [00:23:00] successfully, but it is harder because that CTO doesn't have a, a natural desire to go out looking for change.

Um, but yeah, uh, there, there are some in the, the, the coaching pool. Um, who will take people who are not even in, in some kind of challenging situation, you know, and they, they use them more like a conciliary feedback loop kind of person rather than actively coaching and changing their behaviors and all that sort of stuff.

Yeah,

Aaron Rackley: no, very interesting. So I don't want you to give away all your secrets but um, you mentioned there that you specialize in, you know, burnout and stress and stuff. So is there one little bit of nugget we could give to everyone that's like a tech a technique or something for how to deal with burnout?

Because I see it all the time. It's... Everywhere I work there's burnout every year, especially at this [00:24:00] time of year where you're getting close to the end of Christmas and financial years and stuff

Andy Skipper: like that. Yeah. I mean, the biggest thing for me was learning that it is so widespread. You know, cause I think a lot of people, when they start to experience that kind of disengagement from work and dealing with kind of health problems or, you know, fatigue that comes with being burnt out, they, they kind of assume it's specific to them and it's because they're not good enough where it's, that's not at all the case.

It is very, very widespread and it's. Very, very common, especially among first time CTOs, as I said before, um, so understanding that, um, and then being a bit more brutal about setting time aside for recovery, you know, um, and talking to people, talking, talking to your manager, talking to. People who are in [00:25:00] your, your first team, Lencioni's first team, or speaking to people in your family and just being open about it, being transparent about the fact that it is affecting you both at work and at home, because it likely is.

Um, getting support, going and talk to professionals if you need to, um, but not brushing it under the corner of a rug and, and assuming it's just something that's wrong with you, essentially, that never ends up well, if you do that. Yeah,

Aaron Rackley: no, a hundred percent agree with you there. So in, in that, in that kind of world of, like we say, time, what balance.

And just stepping aside, obviously with lockdown over and everyone now having years of this hybrid working full, full working, do you have like a kind of, [00:26:00] sorry, I'm just calling you out. Do you, do you have like a stance on that kind of aspect? Cause I'm, I'm reading a lot of articles at the moment where there's a lot of companies reverting back to pulling everyone back into the office.

So do you think that's a. I mean, a wise move or do you think that would change again in a few

Andy Skipper: years or I don't think there's a one size fits all, um, solution to that. I think what the pandemic did show us is that it is possible to, to operate a team successfully remotely. Um, I think a lot of the problems that I've seen or heard of from people who complained about it is, um.

Trying to make the hybrid style work where you have some people who are in the office all the time, and then some people come in a couple of days a week or whatever, I think that is very difficult to get right. Um, because people, employees have kind of come to expect a level of flexibility and a level of comfort [00:27:00] and not having to commute and all that sort of stuff.

And giving some of that up to come in part of the time means that sacrificing something without gaining something. I think this is, this is my armchair psychologist coming in. I think that's the case, but I've, you know, I've seen companies do the hybrid thing very well. I've seen the whole RTO returns to the office thing happened seamlessly.

You know, a lot of it depends on the people, depends on the company, depends on the culture. Um, yeah.

Aaron Rackley: Yeah. So what do you, what do you think, um, CTOs can do, or is it even in their remit, right? To help structure that culture to, for whatever it means ends up being, whether it's remote, hybrid, whatever, but what part do you think, how much of a part do you think a CTO should have in?

Andy Skipper: And that certainly they should be capable of fighting, uh, fighting for that [00:28:00] cause. If a team does want to stay completely remote, then they should be capable of articulating to the other people in the company. Why that's not a problem or vice versa, if it is a problem and they can justifiably see it as a problem, having the, uh, having the, the guts to tell the team that and say that it's just not possible.

Um, yeah, other than that, I think there are certain skills around asynchronous working and meeting management and, um. You know, working, working with people who are predominantly remote is not quite as tricky as working with people who are half remote, half not, or sometimes remote. Mm-hmm. , you know, so there, there are some specific skills to learn there.

Aaron Rackley: And I, and, and I, if, if anyone wants to learn all these skills, they can go to your campus.

Andy Skipper: They can, they can go to the campus. . [00:29:00] I'd also definitely recommend the, um, the, the GitLab. Book on remote working and that's a great resource for, for how they do it. And obviously they, they are a hundred percent remote, I believe.

I think they've

Aaron Rackley: always been remote.

Andy Skipper: Haven't they? I think so. I think so.

Aaron Rackley: Yeah. So probably nailed it right down.

Andy Skipper: You would hope so. You would

Aaron Rackley: hope so. Yeah. Um, cool. Now, obviously I could delve into all of the pillars that you guys mentioned on the website for what you learn. So I'll just say the four that I think you've got on there, which is like leadership, strategy, culture, technology, operations, and then like, like you said, stress and wellbeing.

And what I'm going to do is I'm going to go away, make that list and find people to come on and talk about each of those different aspects. Um, but I'll point everyone towards it. Um, So before, one thing I'd like to ask everyone that comes on to the podcast is I've got on the website, I've [00:30:00] got a bookshelf and I ask everyone to just recommend one book and caveat, it doesn't have to be related to the subject of tech or anything at all.

It can be your favorite childhood book, but the idea is to just put something new on there for people to read and hopefully learn something new. Um, do you have a rap, uh, a book recommendation? Outside of the GitLab one, because I'll put that one on anyway.

Andy Skipper: Honestly, the hard part here is only recommending one.

Aaron Rackley: You can, you can recommend a couple. I think someone listed off like five the other week and I was like, okay, finding them all.

Andy Skipper: So I definitely recommend Patrick Linceoni, who I mentioned before, two books of his. Um, the five dysfunctions of a team and the advantage, um, they're both about interpersonal relationships within leadership teams and culture and the, um, you know, the business benefits of having a good, a good culture within your team, et cetera, [00:31:00] et cetera.

Um, punished by rewards is very good by Alfie Cohn. Um, and that talks about motivation and how to actually get stuff out of people without. It being, uh, a carrot being dangled or a stick being brandished, you know?

Aaron Rackley: Hmm, I'll definitely have to pick that one up. I've read the Five Dysfunctions of a Successful Teammate.

That's a very good, that's the one that's written in a novel style, isn't it? That's right, yeah. Yeah, it's very good. I really enjoyed that one. Um, so I'll definitely... Pick up the other one. Well, I'd say, I say it to everyone every week, but since starting this, I now have, my bookshelf's getting too big because I have to buy every book just to, and then, yeah.

Um. So before you go, I think if you can just share everyone where they can find everything online, where they can find you, CTO Craft, and we'll make sure those links also go into the, um, to

Andy Skipper: the show notes. Yeah. Um, so almost everything [00:32:00] is on ctocraft. com. That's the first place to go. You can sign up for the community there.

You can find out more about the conference and buy tickets. Uh, you can find out about campus, et cetera, et cetera. They're all linked to from there. Um, so that that's the place to go and you can find us on LinkedIn as well and on YouTube, a bunch of stuff on YouTube. Um, yeah, those are the main ones not Twitter.

I'm not doing Twitter anymore.

Aaron Rackley: Oh, no controversial

Cool well, no, I I appreciate you coming and taking the time. Um, obviously We met through the Slack channel, um, on CTO craft. So I am there for anyone that decides to join on there is also, you can say hi. Um, so appreciate you coming on to talk about it and. Yeah, hopefully I will be able to come to one of these events very soon.

I just need to find the time. Indeed. Indeed. Yeah. Well, thank you very much, [00:33:00] Andy. I appreciate it. No

Andy Skipper: worries. Good to talk to you. Thanks for having me on. Thank you, mate.

Aaron Rackley: Hey, thank you for making it all the way to the end of today's episode. It means the world to me that you have made it this far. I really love making these episodes. I would like to make even more. So please, if you have two minutes to spare, can you just quickly share this podcast on your social media sites?

Or even point it to a guest you think would be great for the show. I'd really appreciate that. Thank you. And until next time, have a great day, and I'll see you soon. Bye.

Today we are in conversation with Julie Nee, a passionate trainer, speaker and author. We deep dive and talk about the book/course The Power Of Positive Leadership

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Julie Nee

• www.julienee.com
• https://www.instagram.com/julienee108/
• www.powerofpositiveleadership.com
• www.jongordon.com
• https://www.instagram.com/jongordon11/

Book Recommendations:

• The Power of Positive Leadership: How and Why Positive Leaders Transform Teams and Organizations and Change the World (Jon Gordon)
• All It Takes Is a Goal: The 3-Step Plan to Ditch Regret and Tap Into Your Massive Potential
• Mirror Mirror: 5 Reflections to Clear the Fog and Help You Shine

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hey everyone and welcome to this episode of the Tech Leadership Decoded podcast. The podcast where through conversations We unravel the interests of leadership in the tech industry and provide insights on how to become a top performing leader. Today we're in conversation with Julie Nee answering the question.

What is the power of positive leadership? But before we jump into today's conversation I just want to take a moment to let you know that our new website is now live So head over to techleadershipdecoded. com to see all our past episodes and an interactive bookshelf that displays all our past GEDs recommended reads.

And with that, let's get straight into today's conversation. Hi Julie, and thank you for joining me this week on our podcast. How are you doing?

Julie Nee: I'm doing great. Thank you so much for having me. I love that we get to connect. Across the pond,

Aaron Rackley: to be fair, quite a few of my guests have been across the pond at the moment.

It seems that there's a lot more people on that side of the world that are willing to come onto my podcast in the UK at the moment. So I need to get down to [00:01:00] some, um, local meetups, I think, and drum up some more people. Um, so yeah, uh, welcome to the podcast and for everyone listening, obviously they've had a little intro, but we are here today to talk about what is the power of positive leadership.

But before we get into any of that, to introduce yourself and how you've got into the point of being involved in the power of positive leadership.

Julie Nee: Yes, I'd love to. So my background is in sales and sales leadership. I worked for the Hershey company, uh, for 19 years and I sold chocolate and lead teams all over the U S um, during my couple of decades with Hershey and.

During that time, I had joined a new team and I was leading people all over the country and one of my guys out in the West. Was reading John Gordon's book, the energy bus, and he gave a copy of it to his whole team and I was his new boss. So he gave me a copy of the book as well. And [00:02:00] he said, I really want you to read this book on your flight home.

So it was really important to him and he was a new guy on my team. So I read the book on my way home and I immediately said, this is it. This is. Powerful, powerful work. And this is how I want to lead my team. And this is how everyone should be leading their team. And I started bringing the principles from John Gordon's book, the energy bus into life with my team at Hershey.

And by the way, for there, there probably are many people who haven't heard of it. So the book is called the energy bus. And the subtitle is the 10 rules to fuel your work life and team with positive energy. So it's all about positive energy and mindset and all those things. So I just, it really clicked with me and resonated with me.

So I started putting the principles into practice and here's what I found. My team was able to thrive not only when the business was good and everything was going along easy peasy, you know, just when, you know, it's easy to thrive when, when the business is good. Right. But [00:03:00] what happened was my team really learned how to thrive when the chips were down and when the business got hard.

We weren't finger pointing at each other and we weren't shaming and blaming and doing all the things we were just working together to figure it out and find a way forward. And we were able to keep our minds positive, even during the hard time. So, because of what I saw in that work, I felt the need to reach out to John Gordon, the author.

So I wrote him an email and I said, thank you so much for the energy bus. This is what happened with my team. So powerful, et cetera. And he responded. So I was like, well, wow, this guy's really cool. I'm going to read another one of his books. So then I read his book, the carpenter, and I wrote another email.

And then I read the seed and I wrote another email. And then I said, man, I gotta bring this guy into speak. Like he he's a big time speaker. So I'm like, I'm going to bring him in to speak. So I live in Charlotte, North Carolina, and I brought him into this executive women's leadership group that I'm part of.

And. And he, and I had the opportunity before he got on stage to [00:04:00] introduce him. So of course I volunteered myself for that because I was totally fangirling over John at the time. And I introduced John and he got on the stage and he said, I think Julie's more passionate about my work than I am. And I was like, yes, yes I am.

Yes I am. And so that was the beginning of kind of building a relationship with John Gordon. We built this relationship over the course of a couple of years, while I was still working with Hershey, while I was still traveling, while I was still leading a big team, all these things were happening. But after a couple of years, I was kind of ready.

I was ready for a change. I was getting a little bit burned out in my corporate environment, and I really wanted to share this work in a bigger way. I just had found that. The seed that had been planted inside me was really growing and I wanted to share it. So I finally, at the end of 2015, uh, wrote John one more email.

And I said, top five reasons why we should work together in 2015. And he [00:05:00] called a couple of days later and he said, what do you want to do with this? How much money do you make all the things? And we had a big conversation. And by the end of the conversation, he said, okay, you can go out and start speaking about the energy bus for free.

Don't quit your day job. Yeah, you know, and so I did not quit my day job yet. Uh, I went out and started speaking for free. I spoke to junior leagues and rotary clubs and women's groups and really anyone who would listen to me speak about the energy bus. Um, and I did that for about 6 months and then it was time, there was some organizational changes going on inside Hershey.

So I had the opportunity to make a change and I left and I started working with John Gordon about 6 or excuse me, 7 and a half years ago. And it started out as just speaking about the energy bus and then clients would say. Hey, can you do a workshop about the carpenter? Hey, can you talk about when in the locker room first?

Hey, can you do this? Hey, can you do a talk about this? And so I started creating all this content just for, um, either [00:06:00] keynotes or for workshops and then clients as the years. kind of went on, then clients started saying, we need training, we need training, we need training, we need more. And so John and I created the power of positive leadership training together.

And we launched that kind of soft launched it at the end of 2018 and then formally launched it at the beginning of 2019. Um, and we started doing public events together, John and I training people publicly on the principles inside. The power of positive leadership. And then since then, we've been doing this both publicly and privately with leaders and teams all over the U.

S. We also built another training called the power of a positive team. So that's taking those same principles and filtering them through the lens of the team and building stronger, um, commitments and connections inside teams. Um, and then recently we just kind of rebuilt a whole new. Training experience that we call [00:07:00] a day of development, and it's taking the best of the energy of us, the power of positive leadership and the power of positive teams and wrapping it in all into one awesome day of development.

So, um, something that started out as just speaking about the energy bus has really turned into something so much more between workshops and training and a lot and lot, a lot of content creation around all of this work. So that's a summary of how I got here. Yeah,

Aaron Rackley: well that, that is a great, great story of um, taking what you found out, loved, and then turn it into something you could do every day, which I think is what we all aim for at some point.

Um, so. Obviously you mentioned quite a few different, um, kind of courses and stuff that you, um, do on behalf of John. Um, obviously we're gonna talk about the power of positive leadership today. Maybe I'll get you back for the other ones, at some point. But, um, so you mentioned that [00:08:00] the power of positive leadership is built on principles.

Do you wanna just give us a quick overview of what those principles are and then maybe during this episode we'll just delve into a couple of them?

Julie Nee: Yes, absolutely. And before I do, I want to share something that we kind of foundationally set up at the beginning of any of our trainings and really in our conversations with clients.

And that is that. Positivity is the competitive advantage that makes teams and organizations and individuals, frankly, stand out from the rest because there are so many negative people, negative organizations, negative cultures, and people can't thrive in that environment. Not only will the business not thrive financially when you have a toxic environment, but people can't thrive individually.

And there's so many people today struggling with. Mental health and all these things and so. That positivity piece is a key element of having a competitive advantage and what we have and what we share often is a [00:09:00] body of research, which, by the way, I'm happy to share a resource with you if you want to post it in the show notes for your listeners, um, with some of the research points around this and really this is not what we're talking about.

It's not just fluffy stuff. It's not just an idea like, Hey, be positive. We're talking about real. Bye. Scientific proof and research about why positivity and positive leadership matters. So if you want that resource, I'm happy to share it, but with that, I'll share the principles. So it, we kind of go around a little bit of a wheel.

So it starts with culture. So positive leaders drive positive cultures. And when we talk about culture, we say culture is not one thing. It's everything. It's literally every little behavior. It's every good morning. It's every, can I help you with a project? It's every, uh, can I get you some coffee? It's, it's every, it's every smile.

It's every turning on your camera, engaging with people when you're doing it virtually. It's literally everything. Culture is everything. And by the way, it's being created, [00:10:00] whether we intentionally created or not. It's being created by the way everyone is behaving toward each other because not one person creates the culture.

Everyone creates the culture and so we make it great really by our actions and it's our most important job as leaders to create the culture intentionally. Right? So that's the 1st 1. The 2nd 1 is positive leaders, create and share a positive vision and really that's about where do we want to go? Where are we going as an organization?

Because if you don't know where you're going, how in the world can you get there? And also you have to invite people to be part of that. Hey people, this is where we're going. And I want you to be part of it. It's exciting. I want you to be part of it. Let's do this together. This is how we're going to get there.

And as a leader, and especially a positive leader. We have to be saying it over and over and over again, like to the point where everyone around us is so sick of it, that they're spitting it back to us all the time of like, where we're going. Okay. We got it. [00:11:00] We know where we're going, but like, no mistaking.

This is our vision. And this is how we're going to get there. So positive leaders create and share a positive vision. The next one is positive leaders lead with optimism, positivity, and belief. And this is so big and needy. This, this particular one, because. There's a lot in there, but it's really, if you think about optimism, really at its simplest form, it's believing that tomorrow is going to be better than today.

So, even if today is hard, I believe that tomorrow can be a better day and positivity having that positivity inside ourselves as leaders. And by the way. You don't have to have a team of direct reports to be a leader if you influence other people, which we all do. We influence our work people. We influence our families.

We influence our sports teams. We influence our churches, you know, whatever it is. If you influence other people, you're a leader. So [00:12:00] if you want to be a positive leader, you have to be able to fill yourself up, fill and fuel yourself, right? If you are tired and down and depleted and depressed, you can't possibly pour into others.

So when we lead and teach people around this particular principle, we do a lot of exercises around how to fill yourself up so you can pour into others. And then the last word inside that lesson was belief. And it's about believing in yourself. It's about believing in where you're going, and it's also about pouring that belief into others.

So I believe in you, right? I'm going to tell you, I believe in you. And even if you don't believe in yourself yet, I'm going to have enough belief for both of us until I can pull you along. So positive leaders lead with optimism, positivity, and belief. And then of course, we can't talk about positivity without also talking about negativity.

So the next principle is positive leaders transform and remove negativity. And that's [00:13:00] really about a consistent weeding and feeding inside our minds, right? So we feed the positive, we weed the negative, we feed the positive, we weed the negative, right? And. A lot of times inside cultures, people just let people be negative, like, Oh, well, that's just how he is.

That's just how she is. And we're just going to let them sit over there and be the way they are. Well, it doesn't work. It doesn't work because that one negative person can suck the life out of the greatest, highest performing, smartest, most capable team with their negativity. So truly, truly, truly the biggest mistake leaders make is they don't.

Address the negativity inside their teams, and it's about making a decision back to that very first principle about culture. We have to make a decision inside our culture not to allow negativity to sabotage our teams. So when you have someone that's negative, you point back to the standard. Remember, we said as a culture.

We don't do negativity, so we got to stop that behavior right now. And so inside that [00:14:00] lesson, we talk about complaining. We talk about something that John likes to call energy vampires, which are basically people who suck the life out of the room. So yeah, must transform and remove negativity. And then the next one is.

Positive leaders create great relationships and teams and inside that principle, we really share about the importance of knowing your people and having those connected and committed relationships. Because if you don't know what motivates someone, how can you motivate them? Right? And kind of the key, the key themes inside this lesson are what we call the four C's.

So communication, connection. Commitment and care, and they kind of build on each other, but it starts with communication and, um, we always say where there's a void in communication, negativity is going to fill it. So if we're not intentionally communicating as leaders, people are going to make up their own stories about what's happening inside our [00:15:00] organizations.

Right? So we have to fill the void with our own positive communication. And then next is positive leaders. Build excellence through love and accountability. And this is really important because again, some people are like, oh, that's just fluffy stuff. Oh, that's just your silly, you know, fake positive stuff, whatever.

No, we're talking about building excellence, driving excellence inside our organizations. And the two hallmarks of the great, the greatest positive leaders are love. And accountability together. So I'm going to love you up. So I'm going to love you up. I've built a relationship with you. I've used the four C's communication, connection, commitment, care, and I'm going to love on you.

And we have trust and we have a great relationship, but because we already are in relationship, I'm going to hold you to a high standard of excellence. Because I care about you and I want you to be great and I want you to get promoted and I want you to make more money and I want us to hit [00:16:00] our numbers and I want us to do all the things that we want to do, but I have to hold you to that high standard.

But the reason it works love and accountability together is because of the relationship. If I have, there's this awesome quote that John has in the book and it's by Andy Stanley and it says. Rules without relationship equals rebellion. And that's the truth. So if I'm grinding you hard, charging you, trying to push you all the time, but we're not in relationship, then you're going to shut down.

Right. So, but if we are, we do have a good relationship and we have the trust and the love already. Then, you know, I'm pushing you because I care. And really, the goal is to build a bridge between those two. Because what we see, if you think about love and accountability as a continuum, and on one side of the continuum is all love and no accountability.

And when I talk about people who are all the way on the love side of the continuum, I think about, you know, and believe me, Erin, I've been there myself early in my career [00:17:00] when I first moved from an individual contributor into a leader of people. Um, I just wanted everybody to like me like these are my friends and we used to work together and now I'm their boss.

So like, I didn't want to tell them how to get better on their performance because I wanted them to like me, but I was way too far over on the love side. So everybody liked me, but I didn't really have excellence and my people weren't really getting better because I wasn't telling them the truth. So I call that kind of like successful in people to death.

I'm not sure how you do, uh, kind of performance rankings in the UK compared to the US, but for us, it's usually. Like a five level scale or a four level scale and successful is kind of, or meets expectations is kind of right there in the middle that doesn't do anyone any favors. If you, everyone gets, everyone gets a successful, but nobody's making the number.

Like, it doesn't make sense. Right? By contrast, if you go all the way over to the accountability side of the continuum, and it's all accountability and no love. Then you're just grinding people and they're tired, stressed, and burned out. So [00:18:00] that's why kind of building that bridge in the middle is so powerful.

So anyway, uh, positive leaders drive excellence through love and accountability. And then lastly, positive leaders lead with purpose. And that kind of brings it all together when you're doing all these other things. And sometimes as leaders, we get tired, right? Some days we've got so much going on. We don't feel like connecting and committing to our people and we don't feel like communicating all that.

Like I don't have time to communicate all the things and energy vampires are sucking the life out of us and all the things, right? Sometimes it's hard, but here's the thing. We don't get burned out because of what we do. We get burned out because we forget why we do it. And that's when we have to come back to our purpose.

So asking ourselves, why do I do what I do? And what kind of legacy do I want to leave with my people? Um, and that's where we give our, give power back to ourselves through that kind of last principle of why, why do I do what I [00:19:00] do? So those are the principles inside the Power Plaza.

Aaron Rackley: A lot of great principles.

And I, I literally don't think we'd have time to go through all of them in detail. So obviously I will definitely be linking. to the books in our show notes. Um, I've ordered the box set. I'm waiting for that to, to arrive. But I want to just pick out a few that I think would be interesting to talk about.

Um, I think one that's very relevant at the moment is obviously positive culture. And I think the question I have around that is obviously now that there's Obviously since COVID, since now everyone's working from home, like how do you think that has changed and how we can approach that differently now that we're not in person and having those micro conversations and interactions that you had mentioned there about building up?

Julie Nee: Yeah, I'm so glad you asked. And here's the thing about, because you're right. And, and, and there are a lot of different work environments [00:20:00] now. Some people are fully remote. Some people are partially remote, some people are all in person. It really kind of depends on what business and industry you're in. Um, but here's the thing about culture.

It has to be on purpose and it has to be intentional. So you just said everybody's virtual. I have been on more. Virtual meetings where 0 percent of the people turn on their camera. This is just one example. And by the way, this is my opinion, not necessarily John's opinion, but inside the work. This is what I've observed.

I would work with so many different industries and clients. And if, if we're looking at a bunch of black boxes. How are we connecting with each other? Like it's hard to build relationship with a black box right now. You and I, even though we're not sharing the video, we're looking at each other in the eye and that's how you build connection with people.

So. When you think about culture, one of the first things that you need to do is say, what do we stand for and what do we want to be known for? And that's really core [00:21:00] values, right? So you decide as a culture, what are your core values? And then your behaviors need to be in align with that in alignment with that.

So if I say my core values are kindness, connection and excellence. Right. Okay. Well, so when we jump on a virtual meeting, if my first two core values are kindness and connection, then I'm going to have my camera on, cause I want to look at you and connect with you. And then I'm probably going to say something nice in the chat or send you a DM or a smile at you or whatever it is.

But we have to live into what we say we stand for because a lot of, and John says this and I love it. He says. We don't want mission statements on the wall. We want people on a mission. I literally was at some clients just this week and somebody was talking about how they have their core values on the wall, right?

And it says integrity, excellence, love, or whatever their core values are. And they're like, people point at it and laugh because no one does the behaviors. [00:22:00] So it's about being congruent. What do we stand for? And then I got to show that in my actions. And sometimes we say, know it and show it. I know what we stand for and I'm going to show it.

And that's an easy way to remember it. Know it and show it. I

Aaron Rackley: think one thing that I noticed a lot in all, pretty much as a common theme across a lot of companies that I've worked for over here in the UK is this idea of, like you say, positive optimism, right? Is how we don't have a lot of that, um, from what I've seen.

And, um, I think. What would be interesting is, um, how do you develop that as a, as a leader? Like, how do you build up being able to, as you say, give back to your team members? And if you are feeling drained in that area, like, how do we, how do we

Julie Nee: build that up? Of course, that's a great question. And It's funny, by the way, just before I answer that, I have to tell you, I had a Scottish gentleman in one of my sessions this week and he's, he said, [00:23:00] culturally Europeans, we don't really have it like it doesn't, but, but really, when, when I was talking about that lesson earlier, I'll say it again, if you don't have it, you can't share it.

And so if you, Aaron, have an intention to pour optimism and positivity into your team, you have to have it first. So what are some ways that you can kind of feed and fuel yourself? And I'll give you a couple of those ideas just so you can kind of think about pouring into yourself. Um, I'll probably share my two favorites.

Okay. One of them is gratitude. And you've probably heard about this 5, 000 times. Like if you're plugged into this, any kind of mindset or positivity work, you've probably heard about gratitude or read about gratitude. Anyone listening, Google the benefits of gratitude and you will find probably a hundred thousand studies about this.

Like this is how. Real. It is. Gratitude is a power and it really does [00:24:00] help us change our minds. And so I would encourage people to find a way to be grateful and bring a gratitude practice into your life and work. And it's, it's, it's kind of easy to do it. It really is like, Hey, tell me something good. This is a great way to start a team, start a day.

When you jump on a virtual meeting with your team. Hey, everybody blow it up in the chat. Tell me something good. Just tell me something good. Anything. Work, personal, I just had a baby, the sun is shining, whatever, it doesn't matter, anything. Tell me something good. It's like a mental warm up to start thinking about.

What good is going on in your life, capture gratitude in a journal or, or, or sit in stillness, you know, prayer or meditation or whatever you do and think about the things that you're grateful for, but really finding ways to kind of start and end your day with gratitude and even do it during the course of the day.

I had a client who. Um, at the end of each business day, and he was a leader of a [00:25:00] large company and, you know, fires coming at him all the time and just a really hard role. And he said, at the end of every day, I look at my hardest meeting my most difficult conversation, like, really just the most challenging thing of the day.

And I find something to be grateful for in that. And it's a great practice to find gratitude in the hard things. You don't have to be grateful for the hard thing, but to find gratitude in the hard thing is to me, something special. And I know that every single person, you, me and everyone listening, we all have hard things, but I bet if you really, really looked inside any hard thing that you've experienced, and I know this is true for myself.

I can always find things to be grateful for inside that thing. I'm not grateful for it, but I'm grateful for inside it. So gratitude is huge. And I strongly suggest incorporating some type of a gratitude practice. And the other [00:26:00] thing that is incredibly powerful is for us to fill ourselves up. It's the way we speak to ourselves and John uses this example inside his work all the time of this gentleman named Dr.

James Gills and he's a man who ran six double Ironman triathlons. And you read about this when you read the book. And by the way, the last one, he was 59 years old. So an Ironman, if you don't know what, I'm not a triathlete. Are you?

Aaron Rackley: No, I'm just training for my first half marathon in two weeks and So I'm building up

Julie Nee: practice in, uh, into place when you do your half marathon.

So this is great. So what an Ironman is, is you do a full marathon, a 2. 4 mile swim and 112 mile bike ride. And then you do that whole thing again, 24 hours later. And again, the last time he did it, he was 59 years old and people would say to him all the time, Dr. Gills, Dr. Gills, how do you do it? [00:27:00] Like when your, your feet are bleeding and your knees are hurting and like every bone in your body is telling you why you can't finish the race.

And he said, I talk to myself instead of listening to myself. I talk to myself instead of listening to myself. So instead of listening to all the reasons why I'm too slow, too old, too much pain, all the things can't do it, not enough, blah, blah, blah. Instead of listening to all that, I'm going to talk to myself and I'm going to feed myself with the positive words I need to finish the race.

And let me tell you, this is game changing because we have people do this all the time in our sessions and we have them write down. And you can do this too. And you can do this with your team, right down in the left column, three things that are in your, in your mind that when you listen to your brain, you know, they're pretty negative that they're popping up pretty often.

What are those three things? It's usually some kind of not enoughness, right? Write those down. And then [00:28:00] in the right column, what new positive truth can I speak to that lie, that untruth that I just wrote in the left column and then you overwrite it. So it's, you know, sometimes it's as simple as like, I don't have enough time.

Okay. And the rewrite is, I make time for what's important. Sometimes I have parents in my groups who are like, you know, because they're balancing careers and kids and whatever, you know, I'm not a good mom or dad, I'm not a good parent. And then they say something like, um, I'm fully present. And I make my moments count when I'm with my kids, you know, whatever it is, like some people talk about just, I'm, I'm, I'm not, I'm too old.

I'm too slow. I'm too fat. I'm too thin. I'm too this. I'm too whatever. Right. But speaking truth to the lies, and I tell you what, I've, I said this to a couple of groups this week. If you, if I asked you walking out of this room to read the things that you put in the left column, the lies. To either your spouse, your best friend, or your child, [00:29:00] you would never say those words to them.

Never. So don't say them to yourself. Right? So speak truth to the lies. When those negative thoughts pop in, stop your brain and replace them with something positive. So those are two really, really powerful ways to Feed and fuel yourself.

Aaron Rackley: Yeah, no, that is amazing. Um, the second one, like um, talking to yourself, is the listening self, is definitely something that I've actually found myself doing in the last run I done last weekend because I use like um, I do the training but then on a On a Saturday I do like a fun 5k run at the park, park run I think it's called.

And um, that is the only time where I try and do it against the time. Any other training I don't worry about time, I just worry about finishing. And during that race it was exactly the same thing where it was like... there was a point where my, I get, I'm, I have an element of ADHD, so I get very bored very [00:30:00] quickly.

So obviously on long distance running, my brain starts getting bored. I say my brain, me, I get bored and I start, you know, looking away over the place and start, stop focusing on what I'm doing. And then I had to do just that kind of exercise to myself where I start talking to myself and being like, no, you're doing this, focus on this.

Like you've got to run this distance. Just think about that for the next two minutes. Like that's, that's how I was. Doing it. So I could see definitely how that that definitely would work.

Julie Nee: So I love that. I love that. You're already using it Encourage yourself too, and I hope you will use it during your half marathon, you know Use poor encouraging words into yourself and like I know for sure.

I'm I believe me. I'm not a huge athlete, but When I run or jog or whatever, sometimes I'm literally counting mailboxes. Like, okay, three more mailboxes, you know, and then you can walk for a minute or whatever.

Aaron Rackley: Perfect. [00:31:00] Um, I want to talk about the whole kind of energy vampire transforming negativity. Um, again, it's like, um, I've worked in many places in the past where. Negativity just spreads like wildfire. Someone has it, hits the next person. They have it, then they sit together and they, it swells up. And so how do you have any.

Tips or tricks for leaders to kind of like help transform that into something else, how we can identify it. Right. Or whatever. Yeah. So I

Julie Nee: do. So first thing I know this is going to sound way overly simple, but don't do nothing because you're right. It spreads like a cancer. So don't do nothing. A lot of times when you have some negative people around you and on your team, people are just sitting around waiting for someone to do something.

Why isn't he talking to these people? Why isn't he doing something or she, why isn't he or she doing something about this behavior that is killing our team, right? [00:32:00] So don't do nothing. But here's the next piece. When we're confronting our energy vampires, which again, we're committing that we are going to confront it, right?

And this doesn't matter if it's your boss, if it's a peer, if it's a direct report, if it's, you know, anyone who is. Um, contributing to any toxicity inside your culture, it has to be confronted. So I think the, the best way to start is to get curious with your energy vampires. And so it's like, Hey, Erin, um, I noticed last week in the meeting when we started talking about XYZ, um, and you slammed your pencil down or your book or whatever it was, you seemed really frustrated about this topic.

Tell me what was going on there, you know, and just like pointing back to a real situation. What I would suggest is never saying you're always this and you're never that, and you're always like always and never don't help anyone specific situations, help people. So [00:33:00] talk about a specific situation. Ask what's happening, bring curiosity to the situation because sometimes it's something really simple like, um, maybe they're frustrated with a process or maybe they're upset about a change going on inside their organization or whatever.

It could be something so simple that as soon as you ask, they tell you and you're like, Oh, well, we can fix that. You know, let's go. Let's work on fixing that right now. Right. Um, but sometimes it's something else. Uh, we are all whole human beings, right? We're not just our job titles. So it could be they have a sick child or a sick parent, or they're worried about a scary result they got from a test themselves, something health wise, or what could be anything, any number of things.

But if we don't ask and we just let them behave that way and continue to behave that way. We'll never know and the other, so, so do something, get curious. Um, the other thing is it's on us as leaders [00:34:00] to coach, train and develop our people. Sometimes people behave in a certain way because maybe they weren't properly trained.

Maybe they don't have the right tools to do their job. Maybe they're, we're not doing a good job coaching. Maybe we're just grinding and hard charging and it's just not a leadership style that works for them. So it's on us to coach, train, and develop our people. Um, we also have to encourage our energy vampires.

A lot of times people behave that way because of fear. And so it, you know, it's just, we have to put, literally the word encourage means to put courage into. So we have to encourage our energy vampires a lot of times. When there are people who are so negative around us all the time, um, we just, we literally just think of them or see their face and we're like, you know, we have a mindset about them, but we have to be the only way to change our own mindset about our energy vampires is to find something positive about them, [00:35:00] anything and tell them, you know what I mean?

Like it changes our brain and then we can change our relationship by putting courage into someone and encouraging them and making them feel better. About what they're doing. Um, but it's a lot of work on the leader. This is if you have an energy vampire on your team, I do want your listeners to know it's not one conversation and then it's solved.

Yay. All the energy vampires are gone because we had one conversation. It doesn't work like that. It takes time and energy and coaching and revisiting and checking in and all the things. So it's really on us to keep checking and sometimes and again, I'm not sure how your. Uh, how it works from a documentation standpoint in the UK, but in the U S a lot of times we have to document, document, document, document, because if we are coaching and training and developing and encouraging and getting curious and having the conversations and doing all the things and the person is still not willing to change, [00:36:00] sometimes they have to go, they have to go because they are ruining The performance and the productivity of the entire team.

And like I said, one person can't make a team, but one person can break a team. And I've had a lot of people ask me on this topic. Well, what if my energy vampire is my top performer? Well, here's what I'll tell you about that. When, even though you have to get to the point where you let go your top performer, and you're really worried about it from a financial perspective.

As soon as you do that, everyone else is going to elevate because they've been so stressed out and so drained by this person that they haven't been bringing their best work. So once you get rid of that behavior, now everyone else can bring their best work. So it's worth it to do this. It's not easy, but it's worth it.

Aaron Rackley: Interesting. So to expand on that a little bit, what if you find that you are starting to become? The negative [00:37:00] person.

Julie Nee: It's so funny that you ask that because one of the things we do in our trainings is we say, okay, either stand up or raise your hand if you've ever been a complainer and 100 percent of the people stand up, right?

Stand up if you've ever been the one who is about to suck the life out of your team, you know, has sucked the life out of your team, you know, stand up if negativity has ever threatened to sabotage your team. Uh, frankly, most people stand up on all the things, right? Sometimes it is us. So I, I think one of the things about that is bringing some self awareness.

Um, to ourselves, I read this study recently and it said that 90 percent of people think that they're self aware, but only 10 to 15 percent actually are. So we have a huge gap in terms of what we think we're bringing to others. So as leaders, as teammates, as humans, that willingness to look in the mirror and say, wait a second, I'm not bringing my best to my team.

So if I, [00:38:00] it goes back to know it and show it right. So if I say that I stand for this personally, or we say organizationally, we stand for this, but I'm yelling at my people all the time, or I'm taking out my frustration on everyone around me, then I'm not modeling the behavior that I expect from everyone else.

I mean, and if you, if you're not modeling it, your team is not going to do it either. So, um, the ways to come back. To yourself, come back to center are things like what we just talked about earlier around gratitude and talking to yourself versus listening to yourself and. Finding ways to feed the positive inside of you.

Aaron Rackley: Awesome. Now I could definitely go into this for hours and hours and I feel, and I guess this is why you have whole courses and dedicated to it because it's, there's a lot to unpack in, in this, uh, in all of those different principles before. Um, we wrap it up and end. I'd like to just ask [00:39:00] everyone that comes on to recommend a book.

Now, don't use, don't do the powers of positive team, because I'm going to link that one anyway. But, try and think of a book that you would recommend to someone. It can be fiction, non fiction, anything. Um, just one book. It could be Harry Potter, that's the one I always say. It can be really

Julie Nee: whatever. My son loved Harry Potter growing up, I'll tell you that.

Well, here's the thing, and I don't want this to be selfish, so I'm gonna give you two books. So, one is, I launched my own book earlier this year, so I'm gonna be a little selfish, I'm pointing to it. Yeah, go for that, yeah. Um, but my own book is called Mirror, Mirror. And the subtitle is Five Reflections to Clear the Fog and Help You Shine.

Okay.

Aaron Rackley: So. Adding

Julie Nee: that straight to the Amazon box. I am selfishly saying mirror, mirror. And another one that I actually just started reading this week, it's, it's called All It, excuse me, it's called All It Takes is a Goal. And it's by John Acuff. J O N [00:40:00] And then his last name is A C U F F. And it's all about simplifying goal setting.

And I, I'm just like really loving it right now. So I'm about halfway through and I'm loving it. So I'll give you those two.

Aaron Rackley: Okay, brilliant. Now I'll add them to the website. And to my Amazon basket, my book, since I've done this podcast, my book list is getting very long. Um, yeah. So where can everyone find you, the courses, everything online?

Julie Nee: Yes. I'll give you some websites that you can link, but I'll, I'll say them out loud, but I'll give you some websites as well. So, yeah. Um, the power of positive leadership. com is where you'll find content about this, um, and of course, john Gordon. com about all of John's works, work, J O N G O R D O N. com. And then me personally, uh, you can find me at julie knee.

com or on [00:41:00] Instagram at. at julieny108. Um, so those are probably the best links to start with. And again, I know you'll post those in the show notes.

Aaron Rackley: Well, no, honestly, thank you for taking the time to come on board to the podcast. It's very been eye opening and there's a lot that I need to go read and dive deeper into.

Um, so thank you for

Julie Nee: joining me. You're most welcome. And I sure hope it serves your audience. So thank you so much, Aaron.

Aaron Rackley: I hope you enjoyed today's conversation with Julie and thank you. For making it all the way to the end of this episode. If you like this conversation, please can you share this podcast across all your social media.

It really does help us reach a wider audience. And finally, if you're our tech leader and would love to come and have a conversation with me on this podcast about a subject you're passionate about, please email me via contact@techleadershipdakota.com and I'll see you in the next episode. Bye for now.[00:42:00]

Today we are in conversation with Alfie Whattam as we talk about his company Alfa and how they help companies grow tech teams.

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Alfie Whattam

• http://alfiewhattam.com
• https://welovealfa.com/podcast

Book Recommendations:

• Shoe Dog: A Memoir by the Creator of NIKE
• Steve Jobs: The Exclusive Biography by Isaacson, Walter
• Trust in Alfa: 7 Simple Rules for Success
• Think And Grow Rich
• The 7 Habits Of Highly Effective People: Revised and Updated: 30th Anniversary Edition
• Ready player one

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hi everyone and welcome to this episode of the Tech Leadership Decoded podcast. The podcast where through conversations we unravel the interests of leadership in the tech industry and provide insights on how to become a top performing leader. Today we're in conversation with Alfie Whatom answering the question, how do you build a tech team?

I hope you enjoyed the conversation and if you do please remember to subscribe to this podcast on your favorite player to be notified when we go live with upcoming episodes and if you're a tech leader and would like to come and have a conversation with me about a you're passionate about, please reach out via email.

At contact at set leadership decoded. com. And with that, let's get straight into today's conversation. Thank you for joining me today, Alfie. Um, how are you doing?

Alfie Whattam: My pleasure, Aaron. Yeah. Thank you for having me. I'm all good. How are you? Yeah, great. Um,

Aaron Rackley: on this, as we just said, just saying before we started this lovely Monday afternoon, um, so today I've got you on board cause we're going to be talking about how to build a tech team and [00:01:00] potentially a tech company.

We'll see how far we get into the rabbit hole. But, um, before. we get into the, into the topic. Why don't you just introduce yourself to the audience? Let us know a bit about your past and obviously why you care about building tech teams and we'll go from

Alfie Whattam: there. Sure. Yeah. So my name is Alfie Wattam. I'm a London based, uh, entrepreneur and podcast host and author and speaker, husband, dads.

I wear many, many different hats. Um, And I, my company, my main company is around building tech teams and recruiting kind of 10 X software engineers and building out top high performing, uh, groups of people for all types of companies, from large businesses like Google and Gymshark to small startups working in AI and the metaverse and everything in between really.

Um, and I've done that for basically my entire adult. So, um, it's got a little [00:02:00] bit of a different journey and background to, to most people that, that have, um, kind of wound up in my, in my position. Um, but yeah, happy to share that story with you today and, and any advice or tips, which might help the listeners as well.

Yeah, no,

Aaron Rackley: no problem. You talking about your, uh, background there. I. Tell me if I'm wrong, did I say that you used to be a magician, or still am a magician, or...

Alfie Whattam: Yeah, I, when I was a kid, and a teenager, uh, Aaron, I, um, got into it, like, like most people do, really. You get a deck of cards as a Christmas gift or something, and you can do a few tricks.

For whatever reason, I never seemed to grow out of it, I still really loved the idea of being a kid and being able to, you know, completely, um, blow the socks off adults and, and, you know, do something which they had no idea how I was able to achieve it. And that sense of wonder and excitement and happiness that you can bring to people really led me to keep doing it and keep doing it.

And then before long I was doing [00:03:00] shows and parties and weddings and... Performing all around the world on television shows, like Britain's Got Talent and my own platform. Um, and it was a lot of fun, did it for, for a while, built a business around it, around hiring magicians for, for other, um, events and that sort of thing.

And that's kind of how I got into recruitment in a, in a weird way. Um, but yeah, a lot, a lot of fun. And, and as you mentioned, definitely not the, uh, origin story, which most people have, I suppose.

Aaron Rackley: I think, um. That's super, super interesting. I think that's a great way to get into anything, really, and I think if one thing that I assume that it's done is made you a great presenter.

Alfie Whattam: I like to think so. Yeah, I don't think I'm the best speaker, you know, when I see, like, Like world class speakers, like, I don't know, someone like Obama or something and how he's eloquent and succinct. And I think I've got a long way to go till I can speak like he can. But, um, the magic side definitely taught me a lot about [00:04:00] communication around presenting around, I guess, sales and marketing and entrepreneurship as well, and relationships and all of those, uh, very, very important life skills I was able to apply to.

Um, you know, my, my other. Uh, businesses in Korea to help me where other people perhaps struggled. Maybe they didn't have those skills and that type of thing. So magic really, really did help for it through teaching me those types of, um, attributes, if that makes sense.

Aaron Rackley: Yeah. Um, amazing. How did you end up?

Building tech teams. How did you end up that as that as a business from from magic to building tech teams? Like what was that

Alfie Whattam: journey? Uh, I got really busy doing the uh, the magic gigs Um, and it was getting to the point where I was basically being asked to be in a couple of places at the same time So i'd be doing a show in london.

I'd get requested one in australia or germany or Singapore or whatever. And I couldn't literally, despite being magic, I couldn't be in many places at the same time. And obviously I wasn't that good. [00:05:00] Uh, and I would essentially hire other magician friends to do the shows for me and take a cut, take a margin.

It's recruitment 101. I built up a magic recruitment agency business, which sounds, uh, really cool. Um, it's not as Profitable as you would imagine. It's only people working a couple of hours a week for you, you know, on a Friday night, Saturday night sort of thing. So, um, a lot of fun, a lot of, um, a great experience doing that and a great journey, but, um, I realized pretty quickly that I was going to be in a much better position if I was able to pick a sector to, um, to recruit for, which was a little bit more in demand than, than Mike.

A magician for a corporate events, if that makes sense. So, uh, tech was always the thing, Aaron, that I, that I loved. And ever since I was a kid, you know, obsessed about everything from, um, you know, building websites as I did when I was 13 years old to, [00:06:00] you know, trying to sell. Ecom products or whatever the, whatever the application was, the obsession was always there.

And I used, um, tech, I use social media to build up my, my magic business. So that was the other thing that I really knew about. Um, so that's kind of where I made that shift and, and, you know, thankfully it was the right decision.

Aaron Rackley: So I'm, I've got a startup and I'm looking to start out a tech team. Um, I know that I've just identified, I've got this part of it.

I've got a SaaS product. I've got one guy just working on it and it's starting to take off. I want to go out and build a team. Where do I start? What does that

Alfie Whattam: mean? Well, it depends on what you need really, right? Um, I have a business which recruits software engineers for the companies across the UK, so perhaps I could speak to, to that angle.

Um, I think, you know, a lot of the time, the advice that I'll give here will be applicable to many other areas as well, but it's really. Important in my opinion [00:07:00] to hire specialists, not generalists when it comes to, to tech, especially if you're an early stage team and that sort of thing, because if you can get a developer that can do Java, C sharp, Python, Ruby, React, Angular, iOS, Android, then I guarantee they can't do any of that stuff very well.

Like the best developers that I know are people that stick to a particular area and they master it and they become really, really good at it. And then they can add value from that. Perspective and then, you know, they could look at doing other things, but first they master, you know, something as their core foundations to begin with.

Right. So I think quality is something that people tend to get wrong. Aaron, they tend to try to hire too much in one individual, which makes sense. If they're a startup, they're trying to say. Um, but it's much better to get people that, um, you know, uh, inch wide, mile deep rather than mile wide inch deep, if that makes sense.

Um, so I think, I think quality obviously is, is paramount. I think speed is just as important [00:08:00] though, Aaron, because oftentimes people, when they want to hire, they seem to get this, like. power ego trip where they think, okay, I'm going to make all the candidates do five interviews where they've got to do two hour take home technical tests.

They've got to do, you know, this weird Google cultural interview where if you get like a brain puzzle question wrong, then you're rejected instantly. So I think speed is just as important. Treat candidates like they are in demand because they are a good developer. When we, when we find somebody, you know, after a week, after a couple of weeks, they'll, they'll have multiple offers from, from companies.

So, you know, why should that person work for you? You know, not why should, um, sorry, why, why should you be their employer? Why, You know, it's, it's not

just a one way street anymore. It's about. You know, making it work for both ways. So I'd say quality, I'd say speed. And then once again, um, just to do the logical side of it, I'd do price, you know, ultimately, [00:09:00] if you're going to hire, you do need to pay people what they're worth or pay people more than what they're currently on.

Um, I work with some clients who want to have, you know, an A star unicorn, but they're paying like peanuts, right. And you're going to, you're not going to have to get a senior if you're looking for a junior salary. So I think it's about getting those three components, right. And if you can do that. You can hire some amazing people and they can add a lot of value to your company, to your team, to your vision.

If you get any one of those components wrong, if you don't, if you are too generic, if you're too slow, if you're not paying market rate, then everything starts to crumble. So it's really about getting all three in, in order if that works.

Aaron Rackley: Yeah. So just to confirm that, was that quality, speed and

Alfie Whattam: price? Is that what you?

Yeah, it's, it's, it's nothing that I've invented, by the way, that the USP is like one of the most fundamental parts of, of business, but I often find, especially from a technical perspective, if somebody is like head of engineering or something, they haven't got that background and that understanding. So, um, oftentimes it's, uh, it's about [00:10:00] repeating common sense because it's not always common practice.

Aaron Rackley: Yeah. So I think that's going to be, um. Very apt for our audience base because this podcast is aimed at obviously new technical leaders or people that have transitioned from, uh, like a tech role into a tech leader or, you know, come from a PM and stuff. So, like you say, not everyone has experience, especially in those three things, right?

For example, if I am recruiting for my company, I don't necessarily know the prices of things. I'm never going to know that speed. Yeah, a hundred percent probably could be quicker, but you normally stop behind some recruitment process. Um, and quality now, I think that's something that everyone struggles with when they're hiring.

So I think if we start a quality, how do you, uh, for your business help adjust that pool to find the right

Alfie Whattam: [00:11:00] people? Yeah. Well, when it comes to hiring developers in my specific example, quality. It kind of comes down to two very separate things. You have quality of technical skills, and then you have, I guess, just quality of the individual in terms of, um, more of like the soft skills, communication, attitude, et cetera, et cetera, right?

I think both are perhaps equally as important. Maybe the attitude is more important because it's better to get somebody who might not have the skills, but is willing to learn. Is willing to put in the time and their free time the weekend to upskill as opposed to having somebody that, you know, might be might have all the right technical skills, but they're not willing to, you know, learn more and have the right attitude and be adaptive and all of that stuff.

So I think quality. Really comes down to those two areas. And then I guess what you're looking for is very, very subjective. You know, one version, one person's version of quality is very different to another person's. And that, that just [00:12:00] depends on what they're looking for. So if a client came to me, let's say Google came to us and they said, Hey, you know, we really need to hire, you know, um, You know, five Java developers, um, need to have this, this, and this, um, finding people just with the right keywords on a resume as in, you know, Java, spring boot, AWS, et cetera, et cetera, that that's only going to get you so far.

Like you need to then actually vet them, not just. Based on keywords on a resume, but actually call them do a zoom with them, you know, speak to them about perhaps any short gaps on on of tenure. So if they've been somewhere for three months, six months, six months, you know, why try and work out the reasons why are they going to join this new company and then leave again after three months or.

Is it a genuine reason why they've moved on, or is it something like, um, perhaps there's, I don't know, spelling mistakes all over their CV, or maybe it just doesn't sell itself as [00:13:00] appealing to the reader. Because ultimately a CV, It's just a sales pitch to get an interview. I mean, the point of a CV is to get an interview.

The point of an interview is to get the job right. If you break it down to first principles. So, you know, when I'm speaking with them, when I'm interviewing them, are they selling me on why they're a good fit? For that position. Are they selling me on why they can solve the problem, which the hiring manager is having.

And that really comes through in the interview. You can't get that from a CV. So I guess the vetting the, um, the quality piece, you know, there's a many, many, many different metrics to it from, from references to their LinkedIn page, to their CV, to the interview, to referrals, to the, to the tech stack, to the communication, you know, it's a multi.

Faceted problem to, to, to solve. Right. But I guess that's, that's the reason why companies like mine existed to solve those problems.

Aaron Rackley: Okay. Perfect. And I guess that just helps with speed, right? Because you have taken the time to [00:14:00] do that first initial, um, probably horrible way, but culling of, of the pool, right?

So try and find. The best, um, that you have, and then that helps us make decisions quicker when we're

Alfie Whattam: hiring. Yeah, um, and the speeds, just to add something there, Aaron, the speed is, um, is often misunderstood by, um, People that are looking to hire when using a recruiter, because they will, they will go to a recruiter.

They'll ask for some CVs from a very, very hard to find, you know, skillset. And, you know, 48 hours later, they've got, you know, five amazing options. And, and they'll, they'll think, Oh my God, it took them 48 hours to find these five options when, when in reality, it took them five years to find the five options because it's their network, it's, it's the relationships.

Bill over the past couple of years, maybe they were recruiting for a different company, looking for a similar skillset, and they had an add up and that person applied. And they'd been sitting on that recruiters database for [00:15:00] a couple of years, and they've been building that relationship. Maybe they met them at a networking event.

Maybe it was on LinkedIn. Maybe it was on Twitter or X as it's now called. Right. So. When you're paying somebody for time, you want it to be done as quickly as possible. But what you want is somebody with experience who has already done all the work. So what would take you five years to do, they are able to do in 48 hours, if that makes sense.

Oh

Aaron Rackley: yeah, 100 percent agree. Something that I've been trying effectively over the last year as well is now that I'm starting, you know, I'm into leadership roles now, I'm starting to hire, I'm starting to interview people for roles is. Is I have been going to a lot more kind of meetups really starting to get to know people trying to get As I as you say that network growing so that if when I do work somewhere that requires someone I can send out an email Yeah, um, or I can just put a linkedin post and then I might have a selection of people that i've already talked to who are ready to go and i've got a variety of like [00:16:00] Um, discord channels where it's the same thing, but like you say, it does take time.

Um, and I think like you alluded to a moment ago, the other side of the speed is you as the person employing your reactiveness to those people, right? Like you mentioned, making sure they don't take weeks and weeks to get back to someone because as we all know, it's very competitive and you'll lose very good talent quickly.

Um, the last thing you mentioned now, I wanted to ask you, obviously. There's a big difference between a startup and some company that's been going on for a very long time that has a decent budget going with them. So... With that resource constraint that a startup has, what advice would you have for founders or leaders that are trying to build out a tech team that do have a limited budget?

Like what kind of things can we do in that scenario?

Alfie Whattam: Well, you know, budget and salaries. Uh, [00:17:00] different because a salary is one component of that budget, right? A large company oftentimes can't give up equity, for example, whereas a startup can. They can give shares to that early team. They can calculate, you know, estimate what the value of that equity would be.

And then that, that it gets included in the package. A startup can have a lot more flexibility. A lot of the times with job titles that they give to somebody, you know, instead of calling them a. Senior engineer, when there's only one engineer in the company, you know, why, why not call them the head of engineering or the CTO or something like that, which to a lot of people is worth 10, 20 K, which you don't have to, all it is, is, you know, a word on a, on a, on a document.

Whereas a big company can't do that. So a lot of, you know, big companies are an advantage if they have. Great benefits package. You know, if they have a structure and specific ranges that they can work to and, and offer pretty competitive salaries, let's sell it that startups perhaps don't have that, that capital to, to, uh, you know, to, to [00:18:00] give the high paying salaries and the benefits and et cetera, but, you know, they can give all the other things that I mentioned there as well.

And I think another thing to keep in mind is that, you know, a lot of people that are. Working for big companies, they want to work for a big company. And a lot of people that work for startups, they want to work for a startup. It's a very different type of beast. I mean, I spent five years working for a big company before launching my own startup and, and, you know, I've been doing that for the past year or so now.

So it's, it's a completely different type of. Environment and culture and, and way of doing it. And, um, if you have somebody that perhaps is willing to just do anything, you know, I don't know, startup, big company, I don't care. Maybe that's not the person that you want because you want somebody that knows what they want because they're very, very different worlds, if you know what I mean.

Aaron Rackley: Okay, interesting. So we've talked about obviously what we're looking for, how we, how we get out there, find it. But I think, um, one aspect that [00:19:00] I see online that people talk about a lot is culture fit. How do you use culture fit when you're trying to build a team for, um, a startup? Like, are you looking at a bigger picture of all the, say you've got the remit of hiring six people for a new, a new team that are coming in for Google?

I don't know. Are you looking at how those six people are going to work a job together during your And if an initial stage

Alfie Whattam: startup, or I wouldn't, I wouldn't, I don't like the word culture fit. I prefer like culture art because a culture fit just gets you in that situation, six straight white guys, probably, you know, like if you want diversity, if you want.

Equality and, and, and inclusion. And if you want these things, then trying to find people that are like a replica of you is not the way to, to, to do it. Right. Um, so I think, I think [00:20:00] culture art is better, you know, how can they add to the culture, you know, rather than how can they fit the existing culture? I think from a recruitment perspective, there's only so much that you can do.

Cause you obviously don't actually work for Google in this. Hypothetical. So I think, you know, a lot of the time, what we would do is when we're speaking to the people making the decisions, the hiring managers and the leaders and the recruiters trying to get an understanding subjectively of their personality and, and, and how they are.

And then when trying to find candidates, trying to obviously find people that will gel with that and, you know, make a connection, it's probably a bit more of an art than a science, to be honest, when it comes to that sort of thing, and you don't always get it right. Um, but yeah, I, I, I've never been a fan of the word culture fit.

I like culture art. I think that's a better way of looking at it.

Aaron Rackley: No, that's, that's great. I've actually, um, just did some, um, interview training at work and that was literally the part they added was like, don't look for culture fit. Look for culture. So it's interesting that you also threw that out at the beginning.

[00:21:00] You mentioned what your company does and how it works, but there was a phrase that you threw out that I think is. Very interesting that we've not talked about before on the podcast. And I think it'd be interesting if you'd want to spend two minutes on it. And you mentioned the phrase 10X engineer. Did you want to just maybe tell everyone what that means and elaborate on

Alfie Whattam: that a little bit?

Well, I mean, it's the concept is it's an engineer who can do. You know, 10 times the amount of work in the same amount of time than like a regular, um, software engineer would do. I mean, if we're honest, it probably applies to basically anything in life. There'll be 10 X recruiters. There'll be 10 X gardeners.

There'll be 10 X shopkeepers, et cetera, et cetera. Um, and I think it just comes down to the fact that, um, You've got the Pareto principle, right? You've heard that 20 percent of your actions lead to 80 percent of your results, but you can find that across anything, even in nature, like 20 percent of the, the pea pods will start 80 percent of the peas, you know, everything in life.

It's like a, uh, [00:22:00] Fibonacci, you know, mathematical, you know, law of the universe, 10X engineers are no different. It's just people at the end of the day, if you, if you strip away all. This is a good way of looking at it, right? Take all the money out of all the hands of the people in the world and then give it five years.

The rich people today will probably be rich again in five years because it's what they do, what they know and the actions that they take, which allow them to get to that. That destination and that point 10X engineers, it's their personality. It's their nature. They, they're the hardest working, you know, they, they, they get in first.

They stay the latest, they, they do what's required. And, and as a result of that, they, they achieve the most, um, 10X engineers seems to be like a term, which is used quite a lot in the, in the deaf community. But that term could be applied to basically anything, I think.

Aaron Rackley: No, thank you, um, yeah, I've definitely heard it all over, all over the place, and I've heard it argued.[00:23:00]

For good and bad on both sides. Um,

Alfie Whattam: of course, and that's often what we look for though, because if you are looking to recruit a software developer and you go out there and do it yourself, maybe you pop an ad up on, on LinkedIn, or you ask some of your friends or whatever, and you get, you know, a decent engineer, then that's amazing.

But if you, you know, work with. A partner, which is all, that's all they do, you know, day in, day out, interviewing hundreds and hundreds of people in order to try and find that needle in the haystack and they can give you that person, that 10 X engineer. Then it's like hiring 10 people instead of, but you hire one.

Um, and one person is a lot easier to manage than 10 people as well. Let me tell you that. I mean, real 10 Xs don't even need to be managed. They kind of manage themselves to be honest, but, um. Yeah,

Aaron Rackley: no, it's interesting. I need to, I feel like, um, it's like one of those subjects that you, again, you could spin off into a whole episode on, so I won't delve much more into it.

But, um, what role do you think leadership plays in building a successful

Alfie Whattam: team? [00:24:00] Well, oftentimes, if somebody in the team is not doing as is required. The question is, is it down to that individual or is it down to the leader? And I think that in the vast majority of situations, it's down to the leader, really, you know, the, the leader has to set the vision, you know, has to inspire the team in terms of this is the outcome.

This is where we need to get to, whether that's a financial target that they're working towards and like a sales environment, whether that's a product, you know, something being built in like a. Dev team, you know, or whatever, right? They set the vision. Then they need to inspire the troops to go along on that, on that, on that journey with them and, you know, allocate, okay, you got to do this part.

You got to do this path. But if we all do our part together, then we get to our final result into our finished goal. I think oftentimes. In the, in the dev world, where the mistake is made is they just put the best programmer in charge of the team. Right. And [00:25:00] that's great. But people skills and tech skills are two very, very different things.

And you can be the best coder in the world, but you can also be the worst manager. So the best, you know, development manager is not oftentimes the best dev. It's, it's a different skillset. And I think being a leader comes down to those points I mentioned. It's about vision. It's about strategy. It's about collaboration.

It's about inspiring people. And I think fundamentally it's about holding people accountable. This is the part where people tend to forget in leadership. When somebody is doing a great job, everybody can praise. good performance. Everybody can walk around and go amazing. You've done that. You've hit that on time.

Well done. The part that people struggle to do is the slapping people on the wrist when they need to be told off. And if somebody isn't doing well, you know, gathering, uh, them quietly and telling them what, what, you know, what could be done to be improved and upskilling them and mentoring them. That's the difficult part.

That's the part that people get wrong. And [00:26:00] then. Obviously, unfortunately, X, you know, um, dealing with underperformers and exiting them out of a, out of a company if, if it's needed, where most people, if they are told them to fire somebody that they'd freak out, they wouldn't even know where to start. Right?

So I think being a leader is very different to being a developer. Um, it's very hard for most developers just due to their personality to do that. Um, but. The ones that can, can, you know, go off and, and do that if they want to, it's, it's part of their careers.

Aaron Rackley: Yeah, no, I 100 percent agree. A good thing you there is you threw out a few good, um, words and we could definitely spend time going into each of them, like vision, strategy, inspiration, inspire, um, accountable.

But I think one, um, I'd like to just try and jump into a little bit is, do you have any kind of, um, experience or, Some tips on how leaders can inspire that team. Cause I think that's the one a lot of people really forget. [00:27:00] I've worked in a lot of places where you don't ever feel like your management are there for you or helping you encourage you to get over the finish line or, you know, it becomes a monotonous kind of day job of coding, coding, coding.

Yeah. So. Do you have

Alfie Whattam: anything on that? Yeah, I think, you know, inspiring is largely down to winning hearts and minds. And I think what people tend to go wrong is they just focus on the mind's part. And the mind's part is a little bit easier, really. You know, we talk about the goal, talk about what we're trying to achieve, talk about your part in that puzzle.

Um, and logically it makes sense and they can do it. And it's, you know, in your mind, you know what you're doing, you know what you're going after. I think the part where leaders tend to. So to forget is about the hearts and, and they don't win the heart. And the way to do that is to, you know, I, I, I guess, get them to become a friend just as much as they are as an employee.

So I often would take a team for a, for a walk outside. And first question is you look, how are you [00:28:00] immediately? Everybody's gonna start telling you about the project. They're like, oh yeah, yeah, it's going well, we're doing this. And just, just, just, just stop, stop a second, right? How are you? How's, how's life?

How's the missus? How's the kids? What'd you do last weekend? If you can get somebody to open up and trust you as a friend, then you've got the heart part is, is there. And by the way, this isn't like some, like, manipulation To try and, you know, coerce them, you know, ultimately if they're, they're working in that job, they've got a job to do and you've got a job as a manager.

Right. So unlocking the heart as well as the mind will get somebody to work towards what you want them to work towards, but actually they'll want to do it. That they'll, they'll, they'll enjoy the work. If, if, if they feel like you've got their back and they've got yours, if they feel like. You know, you as a manager trusts them and, and gives them the ownership and the accountability to make it happen.

That's, what's going to decrease retention and make people want to stick around, you know, when people enjoy. People don't leave [00:29:00] their family, right? You never hear about, I'm going to leave this family to go to this family. Well, sometimes, but that's more of an unfortunate thing, Aaron, rather than like a rule, right?

But people leave companies all the time. People will happily leave a company and go to another company because people aren't. They don't feel like it's their family. Family might be the wrong word to use in that circumstance. I'm not trying to say build a cult or something like that, right? But, um, a place where you really, really enjoy to work is a place that puts hearts over minds, if that works.

Aaron Rackley: Yeah, no, yeah, definitely. I definitely feel like, um, There used to be a time where a job was a career and people would go there and feel like they were part of something and it was, they would want to be there for 10, 20, 30 years. And it definitely, what I've seen in the last 10, 15 years that I've been working is just people like jump around all the time.

And it, and like you say, some places it's because of a manager. Some places because of the product or a [00:30:00] lot of time, it's just boredom. Like if you're doing the same thing over and over again, that can be a thing as well. So I think, like you say, trying to find the heart and the mind of each individual is definitely a great.

Um, for, for your team members and then trying to figure out how they can all work together. Um, do you have a, it can be a success story or it can be a failure story of like, um, when you've found it difficult to get a team together for a client or even in an individual. Aspects of your life.

Alfie Whattam: Yeah, sure. Um, so what in what in what context the team that I've built of developers or recruiters or

Aaron Rackley: Any of them right?

Like if you've if you've you've you set out with the challenge of just building a new team Whether that was of your magicians, um, uh recruiters and everything But then you found that the approach you take you're taken Might have been slightly off or you got the wrong people or Like, um, once you're in that situation, if you have [00:31:00] been, how do you think you can get around bringing that back on track?

Or

Alfie Whattam: I'll give you an example. Before I had my own company, I spent five years working for a huge corporate, um, recruitment agency and started there as a trainee. Worked my way up when I finished, I was, uh, in charge of the UK and Ireland's, uh, software development business, you know, over 50 people offices all across the UK and Ireland, India.

Um, and I think one of the main challenges that I had in that role was a lot of the teams that we had were very, very, um, I guess, how do I put this? Um, The people didn't have any motivation or drive or willingness to want to really, really go after it. And I think the problem that had been followed prior to this...

Change, which I'll talk about is that basically [00:32:00] everybody was unfairly labeled as being motivated by money, which I think for a lot of people is the case and I think for myself, I think that's, that, that, that's definitely one of the motivations, but I think for everybody. It would be a bit of a blanket statement.

Not everybody is motivated by money, but I think at the time that was the way that they were managed. So the carrot was you do this, you get this commission check. For example, this is in the context of recruitment, obviously, um, rather than developers. But, um, you know, in trying to build these teams of recruiters, if you're waggling a carrot in front of them, but they don't.

don't really that interested in carrots, maybe they like broccoli or something instead, right? Then you, then you've got the wrong motivation. You've got the wrong lure. You know, you've got the wrong thing that they're, they're, they're working towards. So oftentimes it's not even about replacing the people.

Oftentimes it's not even about replacing the [00:33:00] systems. You know, oftentimes it's not even about replacing the business, the business is about replacing the incentive. And if instead of it being about money, if instead, every time that you have, you know, secured a position for somebody, you can talk about the fact that that can literally change somebody's life.

Like if you get somebody the drop, the job of their dreams, you can change their entire life. And that can change. Their family's life. If they've got kids, it allows them to, you know, go out there and live a better life and be happier. It also can, can transform the organization. You know, we, we did some great work with like, uh, health tech companies for example.

And if you can get a great developer on that project that can build something which can save lives, then that is an incredible feeling at, at the end of the day. So instead of talking to this person in, in the one-to-one meetings about, Hey, you're gonna make this much money, you're gonna do this, and just seeing them.

Not really that interested instead talking to them about, look, you could, you can change this person's life. You can transform this organization. [00:34:00] This, this company creates medicine, which can cure cancer patients. You know, you could be a big part of that process. Suddenly their eyes get bigger. Suddenly they get hungry.

Suddenly they get smart. So, like I say, if you want to build a team and you're having trouble with your own challenges, just look at the incentives are the people. That are within the team motivated by the message that you're repeating. And if they're not, then change the message. Because, uh, you know, oftentimes it's something literally as simple as that.

Aaron Rackley: No, that's perfect. I think that's a great way to circle and finish off that, that aspect of it. So, yeah, amazing. Thank you for, um, Really going into deep, deep detail there about like building up that team. I think personally, I think it's just one of those things that will take a very long time to really master.

And I think, I don't even know if you ever can master it. I think that's the [00:35:00] important part. I wanted to take a moment. I do want to talk about your business and. A few things that you do. So first of all, you have your own company. Um, is it alpha technology? Is that, is

Alfie Whattam: that the name of it? Yeah. I'll, I'll, uh, I guess would be my, uh, holding thing.

And then within that, I've got alpha technology, which, which makes almost all the money. That's the recruitment part. And then I do other things from, from, uh, books to podcasts to newsletter, speaking, some coaching, but, uh, the recruitment is, is kind of what I've spent the past, you know, almost decade doing now.

Aaron Rackley: Yeah, so I thought we'd just take two quick moments just to, um, Just talk about your book and your podcast. So, I'd like to, I'd like to share as much as I can for the people that come on to the, on to the podcast as well. So, if you want to just tell us what was your book about? Obviously, I know, but the audience

Alfie Whattam: doesn't.

Yeah, yeah. So I, um, I've, you know, been very, very [00:36:00] lucky in recruitment that 90... 5 percent of what you're doing as a recruiter is speaking to people and networking and building relationships. And, um, I've had, you know, the, the look really to meet some of the most talented people in the world from, from, you know, the top AI specialists to people that are running massive, massive companies, you know, with billions and billions and billions of pounds.

If you're American, um, to bestselling authors and everything in between. So I've met, I've met, you know, uh, an incredibly collection of people that are way smarter and talented than I am. And I, I'd always ask them, you know, I don't know why more people don't, but like, Hey, what, how do you do it? Like, what, what's the secret?

Like what's, what, what are the top things that you would, that you would do if you were in my position? And I just spent years and years collecting a notebook of ideas from, from the, the greatest. Minds in the world and then I put them together into a simple collection of habits [00:37:00] routines I think the weird not almost not weird But the the thing is if you ask a hundred, you know millionaires how to become a millionaire Almost like 80 of them will give you the same answer and that's what I found when doing the book.

So I was able to Take the, the answers, uh, to how, how did you become successful or some variation of that, of that phrase. Uh, and I put it down to basically seven, you know, key lessons, rules, which if you apply, if you follow, you will achieve more success in your business, in your life, in basically any area.

And I've taken these ideas and applied them to my own life. And, um, you know, being able to, um. To make it work. So it's a very simple set of routines, habits, hacks, life tools, which if you apply, hopefully will help you in whatever you're trying to do as well. And I don't take any credit for them. They're they're, they [00:38:00] were borrowed and stolen by people greater than me, but I've, uh, I've done all the hard work of.

Of collecting them and putting them into a structured system blueprint, which if you follow can, can help you out as well.

Aaron Rackley: Cool. And that's trust in alpha seven simple rules for success. Yeah.

Alfie Whattam: Get it from anywhere. I'll make sure

Aaron Rackley: I link it. Yeah. Yeah. And then obviously. You just mentioned there because because of your your your job and your exposure to all these people you also have a podcast as well Yeah, and I watched a few episodes since I've I haven't caught up on all of them I'm getting there.

But um since I met you online, so do you want to just tell everyone again? Just kind of plug that So they know what that is. And obviously I'll link it in the show notes as well.

Alfie Whattam: We've done like 120, 30 episodes or something now. We've done it for a couple of years now, maybe four, three and a half years or something.

Um, where I've interviewed everybody from, um, I mean, it's a tech [00:39:00] podcast. So, you know, DHH, the creator of Ruby on Rails. I did one the other week with Harry Stebbings, uh, 20 VC guys. You know, a super popular podcast and a tech fund, um, to people like Peter Wang on the Python side. Um, and just hundreds of, of very talented CTOs, founders, heads of engineering and so on.

And basically we talked to leaders in tech about everything from what's happening with digital trends from. AI to the metaverse to blockchain and, and, and beyond. And we also talk about how those people have built their companies, how they've built their teams, ideas, and lessons that you can take away from that as well.

So, um, I would say the podcast is probably aimed at, uh, tech and business type people. Um, and yeah, we've been doing it now for a couple of years and, and been very lucky to have some, some really, really great conversations with, um, people you know, [00:40:00] bestselling offers to world class investors and everything in between.

Awesome. I'll

Aaron Rackley: make sure I share that in the link as well. Um, now before I, we wrap up and, um, get you to just share your socials and links about, there's one question I ask everyone when they come on, I ask everyone, if you could recommend one book and it doesn't have to be a tech book, it can be. You know, I always say it could even be Harry Potter, right?

It can be any book you want, but if you could recommend one book to give to someone to read, what would you pick?

Alfie Whattam: Well, I'd probably be biased and give them my own book to be honest. But if I didn't pick my own book, um, you know, I'm, I'm a massive reader. I always have been. And I'm pretty sure I always will be.

Um, I do like it. One audible audio book like every week to two weeks and then I'll always read like a physical book every week to two weeks as well. So, um, I, I try and get through like, I would say like 40 books a year. I try. [00:41:00] Now, a lot of them are, uh, re, um, Reading books. I've already read. If there's something that I really like, I will read it many, many times to, to, to try and get the points down.

Um, and I've, you know, I've read a couple of hundred books now around business and tech. I think my favorites of all time would, um, Do you want me to recommend one or, or I'll give you a couple?

Aaron Rackley: If you want to do a couple, you're more than welcome. I just have to make my bookshelf

Alfie Whattam: longer. If people haven't, um, read Shoe Dog by Phil Knight.

That is, um, exceptional. That's the story of, of Nike, uh, Nike and, and how it was built from nothing to, to what it is today. Um, I think Steve Jobs autobiography by, by Walt Isaacson is, is a classic. Um, and then obviously my, my own book as well. There's so many depending on the area that you're talking about.

If you want to talk about business, you know, some of the classics, like think and grow rich or how to [00:42:00] win friends and influence people. Um, seven habits of highly effective people, Stephen Covey, it's great. I mean, there's so many on the tech side, fiction, like ready player one. It's a great book on, uh, the future and what VR could become.

I mean, I've got, I've really have got an endless list, but those are just some that come to mind, mate. Well,

Aaron Rackley: that's perfect. We've got a nice, nice couple there and I'll put onto the bookshelf. I'm actually currently in the process of building the new website for the podcast, and there will be an actual bookshelf where I'll link to all the books that everyone's mentioned in each episode.

Um, yeah. So I just want to say thank you for coming on. I know how busy you are and. It's been great getting to know you and meet you. So. Before we go, do you just want to let everyone know where they can find you online,

Alfie Whattam: and... Yeah, yeah, I think just, if you just go to my website, so alfiewhattom. com I've got a difficult spelling on the surname, so it'll be in the description or something.

Um, and if you click there, it will link [00:43:00] you to all of my other socials, so rather than trying to list all of them, just go to that one website and it will have X and YouTube and... The Gram and all of the ones that people know and love will be on there as well. I did have Threads on there as well for a little while, but it doesn't seem to have, uh, have taken off as much as Zuck would have hoped, perhaps with people sticking around.

Had an amazing, uh, first week and then it kind of crumbled afterwards. So, um, don't follow me on Threads. Follow me on the other ones that are going to survive.

Aaron Rackley: Perfect. No, thank you for joining me. Thank you.

Alfie Whattam: Cool. Thank you, Aaron.[00:44:00]

Today we are in conversation with Sade Turner-Moise answering the question What is Diversity & Inclusion? D&I for short.

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Sade Turner-Moise

• https://www.linkedin.com/in/sade-turner-moise-392066178/
• Women Talk Tech Podcast

Book Recommendations:

• Lean In: Women, Work, and the Will to Lead by Sheryl Sandberg
• Never Split the Difference: Negotiating as if Your Life Depended on It by Chris Voss and Tahl Raz

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hi everyone. My name is Aaron and I'm a tech lead here from the uk. And welcome to this episode of the Tech Leadership Decoded podcast. The podcast where through conversations we unraveled the intricacies of leadership in the tech industry and provide insights on how it's become a top performing leader.

Today we have a great conversation with Sade Turner Moy answering a, the question, what is diversity and inclusion? D and i for sure. I hope you enjoy this conversation, and if you like it, please remember to subscribe to this podcast on your favorite player and stay tuned for more upcoming episodes. And if you're a tech leader and would like to come and have a conversation with me about a subject you're passionate about, please email me via contact@techleadershipdecoded.com.

And with that, let's get straight into today's conversation. Welcome to today's episode. How you doing today?

Sade Turner-Moise: Yeah, all good. All good? Yeah, really good day. Working at home today. Um, so yeah, a little more productive, I would say. But yeah, just getting, getting through some admin.

Aaron Rackley: [00:01:00] Brilliant. Now, today we're gonna be talking about diversity and inclusion, and I'm intrigued by this.

Um, and it's a topic that has been coming up a lot. I think, especially for the companies I've been working for the last few years. It's definitely like, There's training that's starting to come around this area now, which never happened before. So I thought I'd reach out to you to see if you could come on and really talk about what that means and what that means for people in a leadership role and what we can do to obviously help in this area.

But before we dive into the questions, do you just wanna introduce yourself and talk about your experience and how diversity and inclusion is important to you? Yeah,

Sade Turner-Moise: a hundred percent. Um, so yeah, my name's Sade and I am a tech recruiter based in London. Uh, we mainly work actually with German based companies, but of course, uh, also in London as well.

It pretty depends on, on what the MO market is. Um, and yes, I've been in tech recruitment for the last four years. Um, I would probably argue like many graduates, uh, came out [00:02:00] university, um, had no clue what I wanted to do. Uh, my studies philosophy actually, which is very, very different to tech recruitment.

Um, but yeah. Studied that. Um, my nan honestly thought I was gonna become a priest and I had to put polite. You tell her, Nan, that's not what philosophy is, but yeah. Um, but yeah, kind of fell into recruitment and I think tech recruitment was something, or tech in general was always something that I was always quite interested in.

I think tech's ever changing. There's so much going on. It's just a really exciting space to be in. So yeah, I was really grateful for the opportunity to, to be at Impala, which is a startup. Um, and yeah, I've been in this space for nearly four years and they really, really exciting, gone through the pandemic, which like many people was a struggle in itself.

But yeah, I think it's been really good to work throughout different periods and yeah, I think very recently got really, really, uh, I mean, I've always been. Interested in the kind of DNI aspect. I went to an all girls school, um, all girls high school. Mm-hmm. So was actually quite an interesting experience because up until maybe 1617, [00:03:00] I'd not known any different.

It was, so there was girls everywhere. Our teachers were all female, the head teacher was female, there was no men anywhere. Um, and then, uh, stepped into the working world and it was almost the opposite. Especially in tech and recruitment. There are a lot more men than what they are females. And to do really well in this space, you have to.

You have to have a voice and you can't get lost in everything. So yeah, it was, I think d and I became a lot more apparent when I kind of stepped into working world, especially in tech. I'm sure we'll get into it, but the numbers for women are very low. So yeah, I've always been quite interested in, in how I can use my voice and an industry to get more women in the tech space, especially at leadership level.

Cause I think that's where we're going wrong, for sure.

Aaron Rackley: Yeah, definitely. I guess let's start right at the beginning. Yeah. What is diversity and inclusion? Like what is, how do we define that? Yeah. What does that mean?

Sade Turner-Moise: Yeah. Yeah. So I think really good question actually. And, and from my podcast and from my doing my research, it's very different for everyone.

Um, and I think often I find that we do look at d and i very narrowly, but for [00:04:00] me, I think. You know, d n I, uh, environment is having one or having people from all backgrounds or perspectives. Uh, like I said, I think we look at d Nni as men and women and I think for me it's, that's okay. And I think in tech that is what it is, right?

I think in the tech space, I think women make up 20% of, of the tech world, uh, in the uk and I think 0.7% of, of. Women of those women are black. So it's even, you know, when you actually get into the nitty gritty of everything, the numbers get lower and lower as you go, get more into detail. Um, but yeah, I think it's more than just having, you know, more, more women in the space.

It's about different perspectives, different educational backgrounds, different cultures. Um, and I think bringing all those people together to really build the best product, build the best tech team, um, that's, that's what I think it really is. It's not just about male and females. Whilst it is a very much, that, it's a lot more than that, I

Aaron Rackley: would say.

Yeah, no, I totally, totally get what you're saying. I think it sounds like a silly question, a silly question to ask. Um, [00:05:00] but why is it crucial, do you think, for organizations to prioritize, you know, D N I in their recruitment process?

Sade Turner-Moise: Yeah, yeah. So I think there are various reasons as to why I think it's important, but I think it goes back to that di diverse perspective.

I think. It allows different viewpoints to come into, to come into play and everything. Mm-hmm. It allows you to attract top talent, build products that can cater to a different audience. You know, just by having different people you can do so many different things. Uh, and I actually read an article, I think diverse teams do a lot better in, in terms of success than teams are not diverse.

Mm-hmm. Um, for various reasons, but I think it's really crucial when it comes to just. Doing a lot more and having different perspectives involved. Um, you know, when you go out to dinner with a group of friends and you're, you're all put the same restaurant cause you're all from the same group of friends and the, the same sort of people, uh, whereby having different people with different backgrounds enable you to kind of build, build better products, I would say for sure.

Yeah.

Aaron Rackley: Okay. Uh, just thinking on that, cuz it, [00:06:00] what I'm trying to be careful of is that obviously I. In diversity inclusion. From my understanding from the training I had literally in this year, I am very much on the privileged end of the spectrum cuz I am, you know, typical white man, middle aged, grew up in London, in the uk so I basically have almost as much as.

You can get in terms of privilege. So I have, I, when I think of these questions, I generally try and think, am I asking the right question or am I biased in myself on it? So, so bear with me as I think through some of these. No, no. There's

Sade Turner-Moise: all wrong way, I would say, and that's what I've learned from from this.

Aaron Rackley: Yeah. What is the challenges that people and individuals have and groups of people have when pursuing roles? Um, Not, obviously we're gonna focus on tech industry in general, but obviously this applies across the board, but what is the general, the barriers that you think they come against? Yeah. When [00:07:00] we're

Sade Turner-Moise: hiring?

Yeah. Yeah, so I think. I think a lot of it come from a lack of representation, I think. Mm-hmm. You know, for, for me as well, you know, let's be honest, I'm a, I'm a black woman of color. Um, so I, I guess you were saying that you were, you know, in terms of privilege, you are up there. I think, you know, you could maybe argue the opposite for myself.

Um, not in that way, but you know, I am in that minority group. Um, and I think often underrepresented groups such as women, such as ethnic minorities, um, they don't see enough people like them in the workplace. Um, and I think especially in the tech world, especially in leadership roles. Um, and I think that's really hard cuz it can lead them to feel quite, I isolated and make it hard for them to kind of find role models or mentors who share similar experiences.

Um, it might not be seen as a bad thing. I think for me, I always looked for mentors who were different from me, who were in a life that I wanted to be in, um, who were in places that I wanted to get. So I think it's not a bad thing, but it can be quite hard to see yourself in those roles. So I think that's one thing.

Um, I think [00:08:00] access is important as well. I think. A lot of underrepresented groups do not have access to the same opportunities, whether that's education, um, networking events, you know, career development programs. I mean, I remember looking to get into all the graduate programs, you know, that were, you know, all from the big names.

And of course then, you know, they don't look at. Not people like me, but you know, you know that you get what I'm saying. So I think, you know, there's limited access for those groups to get to where they need to get to or to get there where they want to be. Um, and I think as well, you could maybe argue certain stereotypes, certain prejudice, make it really hard for hiring managers to see these people in those roles, which make it harder for us to get there.

Um, mm-hmm. And then I think as well, you know, it is really hard to not talk about challenges without talking about bias. Um, I think, like I said, right, discrimination does come into play when you think about underrepresented groups. Um, stereotype perception, um, like I said, it makes it really hard for hiring managers to see those people in those roles.

Um, then when you get there, it then makes it [00:09:00] harder for those people to see you in promotion roles or, you know, leadership roles. So I think the bias is, is, is kind of everywhere in that. Um, but I think it's often quite hard for. I guess for barriers to be broken down if hiring managers do not see. People that are different in those sort of roles.

So I think there are various challenges, but I think those are a few which I've seen. Um, and even, you know, in my role helping engineers, you know, move to different companies, I see it all the time. Um, so I've seen it firsthand, I guess from my own experience, but also, um, where I am. Uh, but it's not in every company, right?

I think I really lucky where I work, but I'm. I'm the most senior person in the team. And I think that for me speaks volumes. Cause I think as a woman of color, you know, you don't see that often. So I think it's not in every company that you see this, but in, in, in a few companies and speaking with friends, it is, it is a common experience for ethnic minorities or minorities in general

Aaron Rackley: at the moment we're, we are hiring our company, for example.

And you are, as you said, helping recruit individuals for other [00:10:00] companies. What can we do when looking for. New hires to reach a more diverse pool of people. Um, because obviously if I go onto my LinkedIn and I just search, I'm probably gonna only get a, a very narrow view of, of the world and if I do the same on Twitter or Facebook when I'm looking for jobs.

And so what can we do to help find more diversity in our hiring processes, do you think?

Sade Turner-Moise: Yeah. Yeah. So I think this is a, it's, it's a really interesting question there. Cause I think me, in my job as well, I've done the same, so I was actually working with a company and they said to me, we have a, we have an engineering team full of males.

How can, how can you help me find more females? Mm-hmm. So I've been there and I've seen how you can do it. So I think. I think firstly you have to really set out some clear goals. I think set the clear d n I goals. Mm-hmm. Which you want to achieve. Um, because otherwise what you're doing, you could be working against what you actually do want to get to in the end.

So I think having those goals in place, Um, it may include setting targets [00:11:00] for hiring diverse candidates, promoting diverse talent. Um, so it may be the case, your goal is to hire more females, so set that as your goal and look at ways you can achieve that. Um, and I think you then have to be intentional about that.

As well. Um, you can't do it halfheartedly. You have to kind of go at it full force and really be intentional about making these goals a priority. Um, I think that's one place to start, for sure. Set the goals and see what you want to actually do. Mm-hmm. And how, what diversity do you want to include in your team?

You know, maybe more females, more cultures, whatever the case. Um, I don't think ways you can actually do that is diversifying your hiring practice. So it could be ensuring your job descriptions are a lot more inclusive. So using gender neutral language, um, or using language doesn't, I guess cater to one group.

Um, I mean, we've seen it quite a lot, right? We want ambitious, hungry, career driven. Um, you know, those things all apply to, to both genders, but often that ambitious, eager. Confident it does tend [00:12:00] to, to kind of suit males more, let's say. So having, I guess, language Okay. Which, which is a lot more inclusive, um, I think really helps, I think ensuring that your interview panel is diverse as well or is a lot more inclusive, um, and involves different people mm-hmm.

From different walks of life. That really helps cuz like I said, um, when hiring, it's not just about what, what you are doing, it's about do people want to join your company as well. Um, so I think. Having people from different walks of life on that interview panel allows people from diverse backgrounds to kind of see themself in that role as well.

Um, I think you mentioned a bit about at the beginning, right, training. Um, and I think training is something which is a lot more popular now, like you said. Um, and I think we have to keep going of that. I think bias trainings is really important because you could do all that work to attract that new diverse talent and you can get them involved in your interview process, but if the bias within your internal hiring team isn't.

Addressed you will [00:13:00] get, you will kind of go back to square one because the changes that you've made say to kind of bring more women to the hiring manager. Um, if his biases are still in his head, he will just reject them. So there has to be a lot more training to raise awareness of bias and I guess equip the team to really mitigate bias in the decision process and in the decision making.

Um, because otherwise, like I said, you'll be back to square one. I think as well, right? Those are a few things which I think are a lot more practical. Um, and I think hiring is one thing which is really important, but retaining that talent is equally as important. So when those people join your team, You have to make sure they're welcome.

The environment is inclusive, so having e r g groups or, you know, mentorship and sponsorship programs whereby people can connect with others like them and really kind of stay in that company. So I think hiring is important, but making sure that the team is, is, is kind of set and, and, and quick to have that diverse team is, is very important as well.

Yeah,

Aaron Rackley: no, what, that was gonna be my next question as well, which is like, now that we've. [00:14:00] Managed to successfully hire. Yeah. A range of individuals, you know, how, how do we make our environments more inclusive? Um, and I know you've mentioned a couple of there, but do you wanna go into a bit more detail of like what, what that group is that you mentioned before and how, what, those kind of things, how they work or how you'd even go about setting these kind of things up?

Yeah, if you have any ideas around that. Yeah.

Sade Turner-Moise: Definitely, definitely. So I think, like you mentioned, right, D n I and you know, the, the kind of inclusive environment is so much more than hiring. You know, once you've got them there, how can you keep them there? Um, so I think ERG groups is, is one way of just, it's really beneficial, right?

Cuz I think it provides impact outside of that hiring process. Um, I think it provides a space for networking support, community building it, I guess it. Creates like a space whereby people can come together in the same group that can share their same challenges because some people may find it hard to express their challenges to someone who is very different or won't see that.

Um, so yeah, having a space whereby [00:15:00] individuals who are very similar and share the same challenges can come together is really important. So those groups are, are really beneficial. Um, I think as well, having benefits for different individuals. And different kind of employee benefits are really important.

Um, you know, not all benefits are gonna catered to the same group. Um, so I think having, I guess not individual benefits, cuz every individual is very different, but having more inclusive benefits, um, so employees can kind of feel supported and valued. Um, such as, you know, flexible parental leave or flexible working arrangements, those things.

And I think one thing which I'm really, really passionate about, and I think one, one reason why I think it's really important is d and I isn't just a one day thing. It's not just in the hiring process. Mm-hmm. I think d and I has to be celebrated all year round. So it's not just International Women's Day.

You know, organize events that, you know, promote cultural awareness such as, you know, lunch and learn or you know, breakfast, you know. Breakfast invite, whatever the case may be. Mm-hmm. Um, [00:16:00] guest speaker series. I think there's so much things we can do all year round and equally right. I hate to say it, but it's not just the diverse group's job to do this.

It's not just the women that have to kind of speak up other women. It should be everyone getting involved and creating that environment whereby everyone can feel really welcome.

Aaron Rackley: Yeah. We used to, uh, a company I worked in in the past, which was a relatively big company, they. The company paid for, I think it was once a month, every Friday.

It's just one of the things they did, they had like a, a bot or something that would randomly pick six people in the company at any level, anywhere across the business and you'd have to go and have lunch together. And it was a way to like just bridge everyone together. So it was like cross departments, you know, and diversity as well.

So I thought, I think that's a very, I think that's a nice way to. To do it. I'm not saying it's the only way. I'm just saying it's just one, one experience I've had that I thought was very nice. Yeah. Uh, because one thing that's interesting is obviously [00:17:00] this podcast is more focused on tech leadership, so how we can, what we can do in leadership to make this better.

Um, but definitely going from my mind at the moment is I just had a podcast a couple of episodes about, about. Focusing on the growth of your individuals in your team makes strong teams. Yeah, so now immediately my brain is thinking, okay, I've now got a team of diverse people that have, have experiences and backgrounds I am not familiar with or might not have the same experience.

How as a leader do I break down or become familiar with the. Those challenges so that I'm able to help them in, if they do come to me with a kind of life issue or a another area that's coaching that they need, that is not necessarily tech related, which is a big part of being a manager, role leader. Like, I'm just trying to think what we can do there.

Yeah. We might not have the outset

Sade Turner-Moise: that No, no. I mean, of course. I, I must admit right. I'm not, um, a DNI [00:18:00] expert, nor am I, you know, um, yeah. Any expert in general, I think I can just share from my own experience and, and kind of what I've seen other companies do really well at.

Aaron Rackley: Yeah. I think that's all, all we can ask.

Sade Turner-Moise: Yeah, I think, yeah, I, I think one thing, I think my. I, I have to kind of commend my, my company now, my, my bosses. I think they've created such a, a safe environment whereby anyone from any walk of life felt really was really comfortable coming to them. And I think that's what leaders can really do. I think having that safe environment whereby even if that person doesn't actually come and speak to you, but they feel they can, that's what's really important.

So I think creating that safe environment, um, whereby we, you know, you can feel comfortable speaking up, sharing ideas. Um, best in concerns without any kind of fear of judgment. I think that's really important. Um, equally right, it could be the case. You are not equipped to deal with that or you do not feel equipped.

Um, it could be the case, you know, someone that shares a similar experience, you know, even just connecting those people together. Mm-hmm. Um, for example, my, my boss. Did it really well. They, [00:19:00] um, they connected me with other women in the recruitment industry because of course, they're not women, so they, there may be challenges, right.

The most bosses, um, do not understand or have not been through. But having a really good network of other individuals that share, that could share similar experiences and being open to connecting them, you know? Right. Cause like I said, you might not be equipped to deal with everything and you shouldn't be, you know, you're not, this is not, you know, um, not everyone knows everything.

Um, but being open. Yeah. You know, Knowing other people is really important as well. I think

Aaron Rackley: definitely what you say there is definitely a, a great avenue to go down of just making sure that as a leader you are, you have a diverse pool of people that you have access to that you can also give them access to, whether that's in the company or as you say, as your wider network.

I have noticed in teams that I've worked in the past that, and I think this is a skill that I think is important, and this is less of a question and more of like a, a topic, is that I generally believe that. A diverse team from, you know, [00:20:00] male, female, race, age, whatever, I think brings so much different experiences to problem solving.

Mm. That I generally love having conversations where there's multiple people in the room because you just 100% are gonna come up with so many different ideas and different approaches to problems. Um, that it kind of almost saddens me that people don't realize that they're not allowing that to happen through their own bias of not hiring in this way.

Based on your area of knowledge at the moment, do you know any companies that have like made radical changes? Because I've seen a lot on LinkedIn and online the news and stuff like that of like companies that are really pushing towards diversity inclusion and then. There's always studies from different locations of like, did it work, did it not work?

Things like that. I've only seen [00:21:00] positive. Have you seen anything that's trying to be negative around that area and, and do you think it is something that will creep into the thought process of people in leadership that are trying to make these choices? Um, For example, I'll give you an example that might not be relevant, but the three day week thing that's happening Yeah.

Is a conversation around people going three day week and we're having a low conversations around whether we should do that or not. And then we've had PE companies to go out there and do it, and now. We've got companies that are trying to pull people back and are trying to make up excuses for why it doesn't work or it does work.

And I'm worried, from what I've seen online, that we've got the same kind of arguments happening with diversity inclusion and trying to be sensitive to that, to that side of the argument that's happening of, cuz I don't believe it for one bit, but. [00:22:00] I'm just trying to think of the right question to ask, so bear with me.

Sade Turner-Moise: No, I mean, I guess to be fair, it, I, I've not seen any negative come from having mm-hmm. A more diverse team. To be completely honest. I've not seen any team that have, have changed their team or made it more diverse and thought we shouldn't have done, never done that. You know, I think, like you said, it. It brings the difference of perspectives, um, it gives the difference of viewpoints.

And I think, like you said, it allows problems to be solved a lot quicker. Um, you could have a group of people that have, now you've got a group of people, right, that have someone in that team that has actually been through this already. Um, so now you are well equipped to deal of whatever that may be. So I think they can offer help.

Um, they can offer, you know, different, um, scenarios, uh, solutions. So, yeah, I, I, I think, you know, when it comes to making change, I don't think you'd make the change if you thought it was gonna do any bad, you know? So I think the changes I've seen on the diversity side, I, I've only seen nothing but good come from this.

So, yeah, I don't think [00:23:00] so from my experience anyway, may,

Aaron Rackley: may, maybe that's, um, a bit of diversity inclusion, literally right there is the. Obviously some social algorithm somewhere are showing me a certain viewpoint of the world and it's not diverging enough for me to get a bigger picture. So I definitely need to get on LinkedIn and add some more people, I assume, or like in different, yeah.

Sade Turner-Moise: Yeah. I think everyone. Experience and everyone's, I mean, if you, if you were to scroll on my social media and, and I was scrolling yours, we'd be like, what the hell? Right. So everyone's viewpoint is very different. So yeah, I think it's just about being open and learning about other things and, and, and actually being, like I said, open to seeing the world in a different way.

I think that's what, where we're going mm-hmm. Where I think we can go be better. Okay.

Aaron Rackley: Let me, let me bring it back to positivity. Um, I am an individual. I am, I can be either a leader or a personal contributor. Um, I am. Of a [00:24:00] demographic that is not, you know, as privileged as another, and I'm now looking for a job.

What can I do to help in that scenario? Because I know I always like to fit, there's two sides to every, every story and every situation. So if I'm out there actively look looking for hiring, what can you do as an individual that can help get your, get you in front of me as well? I guess is the, do you other side of that

Sade Turner-Moise: coin.

Yeah. Yeah. So I think, I think it, for me personally, I think it definitely comes back to networking. I think, you know, whether you're from a diverse group or not, you have to be open to meeting new people. Um, mm-hmm. I think, I'll be honest, I think LinkedIn and job boards and, you know, the normal way we'd normally do things is.

It's very saturated right now. You know, we've seen so many layoffs happen at the large companies like Facebook, me, you know, um, zoom, you know, Microsoft, all those large companies that are having layoffs. Where are those people? They're, they're searching on LinkedIn. You know, they're, they're everywhere. [00:25:00] Um, so I think you have to be open to find something in a different way.

It could be the case. You have a friend who knows, a friend who knows a friend. You know, my, my parents always said, you know, it's, it's, it's, what is it saying again? It's who you know, what you know. So yeah, I think it's, mm-hmm. It's all about being open to networking in circles that are different to yours, I would say.

Um, So, yeah, I think networking, if you are struggling, you know, whether diverse or not is, is definitely the key to, to finding something or finding someone.

Aaron Rackley: Yeah. No, I'm a big advocate for, um, like tech meetup meetups and things like that. Um, I always tell all my developers, um, just go, go to network even if you are not necessarily going to.

Stay for the whole thing, just go and have a chat, go and see what's going on. And one of the big things of like, um, these conferences that happen, and again, this is. It can be a pivot finish cuz they cost a lot of money. So hopefully your [00:26:00] company will Yeah. Help you go there. But, but they're a hundred percent worth going to just for the networking that happens at these events.

I've, you know, I've met so many people that I'd never have met online if I'd literally stayed in that bubble. And if you stay in work, that's even the smaller bubble, right? There's only like so many of you. I guess a question I have. I've decided that my company is not doing enough and that's what it's not.

That's not really what I'm saying in my company. I'm just saying in generalized the question, I've decided that it's, we're not doing enough and I want to start, you know, helping the company explore. D n I. Do you have any resources or do you know any, any organizations or courses or do you know, globe anything that is a good place to point people towards in this area?

Yeah. Yeah,

Sade Turner-Moise: so I think. Well, me personally, I'm part of a few Slack channels that are exactly this. So, um, there are a few, uh, places where I think I was speaking to someone on LinkedIn and she was part of it, so she invited me and, [00:27:00] and yeah, there's so many different Slack channels I think you can join. Um, have conversations, meet new people, like I said.

Um, I think that's, that's of course a good place to, to start Foot, foot. If I'm honest, because I think that's where you're gonna learn about different aspects, meet new people and see exactly what, what we could do more. Mm-hmm.

Aaron Rackley: Okay. Yeah. Um, if you happen to know, if you wanna share any links to those, I'll definitely put them, um, on the channel.

Yeah. Um, as well. Cause that'd be really

Sade Turner-Moise: awesome. Yeah. Um, as well. Another one I just remembered, there's a, an article that McKinsey wrote, I think it's called Women in the Workplace. Um, and that's really interesting for, it doesn't just talk about, well, of course the focus is women in the workplace, but it talks about diversity from different angles.

Um, there is, uh, actually I think, uh, there's an author that I read a book, she, I can't remember the name and I'm not doing her any justice here. Um, I'll find it. The book's called Lean In. And it's by Cheryl Sandberg. She actually has a few talks on, uh, Ted Talks, uh, about it as well. And she's created [00:28:00] like some, it's like a community, um, where people can lean in and speak about different aspects.

I can share a link as well afterwards, but mm-hmm. Yeah, she's done some really, really great talks, you know, about why women are held back, um, and how we could kind of lean into to kind of. Get more out it. So yeah, I can share some more links afterwards and you could put it in the podcast notes. But yeah, those are a few off the top of my head, which I've benefited from and I've seen other people benefit from as

Aaron Rackley: well.

No. Awesome. Yeah, I'll definitely, definitely be reading that book. I've just added it to my list. Yeah. Yeah. Really good. Um, a little while ago we were just talking about, um, what can you do as an individual to put yourself in front of other people, but what if you are someone that's finding. They're struggling to get into like a leadership level within organizations.

Like what can we, what can you do and what can we do to help in those scenarios? Right.

Sade Turner-Moise: Yeah. Yeah. I think definitely, you know, putting yourself forward for a lot more, um, in this, and, and I don't mean doing more and, and kind of. Not, you know, [00:29:00] you know, I don't mean like just doing more than your job title, so to speak.

Um, yeah, I mean, you know, it could be the case where putting yourself forward for, you know, different activities. Um, cuz it could be the case, I think a lot of the time, you know, a promotion might not come from your own manager, right? It could come from another team or another hiring manager who's also looking for a lead.

So I think putting yourself out there in different situations to meet new people and, and within your organization, right? It could be a company sports day or a company, you know. Go, you know, grabbing a coffee at different coffee station in the office. I think putting yourself in different situations whereby you can meet other people who are the decision makers.

Mm-hmm. Cause it could be the case your manager right now is just not gonna throw out you. Right. Um, not the case. Right. I'm sure. But they just might not need a lead. Um, so you might need to kind of put yourself out of your comfort zone and, and maybe go and speak with other people. Um mm-hmm. I think as well, another good thing as well is a lot of people are, I guess maybe scared to move on.

Um, I see a lot of. [00:30:00] People just, I guess, sticking within a, a role or waiting for that promotion to come. Like I said, it might not come work from your own company, from your own team, um, but putting yourself in a situation outside of that whereby that could happen. Um mm-hmm. I think as well also speaking up saying, you know, not, I deserve a promotion, right?

Mm-hmm. But it could be the case whereby you have a one-on-one with your manager and you say, Hey, I'm doing this. Um, I feel like I should be in touch to this, you know, is that possible here? You're not giving them an ultimatum. Right. But I think often I do find that, you know, under reps in groups are, are fairly scared to have a conversation or they don't wanna come across in a certain way or whatever the case may be.

Right? Um, but how else are we gonna get there? Um, so I think putting myself in that conversation and saying, I would like this. I'm not being, I don't feel satisfied where I am now. Is this possible? I think having those conversations and being open to them is really important as well.

Aaron Rackley: Yeah. I think, um, as you point out there, [00:31:00] um, just one aspect in your one-to-ones is definitely a great way to approach it, right?

Because it's say usually at companies are one-to-one. Um, situation is very helpful in pushing you towards your career path through that bus, through that company or business, right? So, Giving them a clear, I want to progress. Yeah. What do I need to get? There is always a good conversation to have and it forces the, the individual on the other end to actually think about it.

Yeah, yeah. Um, as well. So I think, I think if anything, I'd always say as a, as a tech leader, I'd always say, definitely bring it up in your one-to-one straightaway. Just set your expectations with your leadership of what, what your career plans are and where you want to go, and just get them to help you.

List out the steps to get there. I think it's a great, great thing to

Sade Turner-Moise: do. Yeah, because like everything, right, people may not know you want that, that. That promotion. Right. So you have to set it a hundred percent. Yeah. Yeah. They might feel, they might think, oh, [00:32:00] well she's comfortable in that role, or, you know, he does he even want to progress.

So I think actually saying, this is what I wanna do, how am I gonna get there? What do I need to do? Um, is really important.

Aaron Rackley: I think, yeah, cuz I think there's, there was a few years back where, I can't remember who was arguing or where, but it was, it was always, it was about the, the page, the pay gap between men and women.

Yeah. And then there was statistics out there that, you know how much of these statistics you believe, but you know, there was one that like, men tend to ask for promotions more so they get more promotions or they tend to ask for raises more so they get more raises. So, I think the one thing I took away from that when that was happening was if that's true, then everyone else needs to just start asking.

Yeah. But again, like there's that history of being afraid to ask, I guess, because of the pushback that's happened. So I think we just. I think personally that we just need to all get better at just asking for what we want and you know, go from there. [00:33:00]

Sade Turner-Moise: That's like everything in life, right? Like I said, if you don't ask, my mom was said.

If you don't ask, you won't get. Um, so I think all is ask and the worst they can say is no. Uh, and yeah, it sounds really bad, but you are already in the position for them to say no. Right. Because you're not in that leadership role. Yeah. So even if they say no, that's where you are already. So it's not that you're gonna be pushed back further.

You're just not gonna be where you might want to be. Um, so yeah. Yeah. I think having no is, is, is a bad thing. And looking at ways you can make sure you get that Yes. Is, is, is important

Aaron Rackley: I think personally as well. I think there's a safety and a no because yeah. What I think a no gives you is the power to know that they're not, they're not interested for whatever that question is, right?

They've decided they don't wanna deal with it, so that gives you the freedom and the power to go. I will go somewhere else that's willing. To do that. But until you ask that question, you're never gonna know whether that's the case. Right. And then you could just be sitting around for a very long time.

[00:34:00] Yeah. Yeah. Hoping

Sade Turner-Moise: for the best. Yeah. I mean, in my role, right? I speak with so many engineers at all different levels. Um, and I think from, so I've been speaking with a lot of CTOs and VPs of engineering, uh, lot recently, of course for my podcast, encouraging more women to get into tech. Um, and I think what I've seen from, from these women is they just ask, um, and a lot of.

What I've been saying, you know, how did you get to where you are? Well, they had to move on from company that, that didn't see them progressing. So that's one thing. But they had to ask for those pro promotions, right? They have to say, they have to kind of mm-hmm. Have a voice. You can't unfortunately sit there and be quiet because that's where you kind of get lost in the company.

Um mm-hmm. And I think from what I've seen, and, and a lot of progression does happen, just from speaking up. Um, so yeah, for sure. Actually, I'm speaking of the lady right now. Amazing, amazing engineer. She's actually moving from her current company, um, for an even better package and even better, um, opportunity elsewhere.

And I think having that courage to be okay, uh, to move on and be okay to ask is really [00:35:00] important.

Aaron Rackley: Yeah. And then I think like, um, there's the opposite of that as well is that as a leader, it's, you should be encouraging that kind of. Environment of people being able to just come and ask questions and they should.

If it isn't, no, I think you should have a no of a reason and you should go back with a reason and that will help. But you should never just be. Creating environment where you just shut people down and say, no, move on. Let's carry on.

Sade Turner-Moise: Yeah. And it may not be a no. Right? It could be a not right now. Um, but here's not right now.

That's important. Yes. But, but it, it could be, uh, you know, here's reasons or here's how you can make it sooner than what you might think. So, yeah. It's, it's a no's not a bad thing. Like you said, it's a safe place for, for you to

Aaron Rackley: work on a lot more. Mm-hmm. We, we briefly touched a minute ago on. Uh, things that I could do to bring, uh, into the organization, um, d and i and how I could start that kind of, you know, [00:36:00] implementation into the business.

But do you think that there are kind of like any, uh, potential challenges that. As an individual who's trying to bring that to the table could come across when, when

Sade Turner-Moise: that happens. Yeah. I mean, there are always challenges, right? And I think often, um, as a, as a leader, right, you know, a tech lead you of often have a someone above you as well, right?

Um, so it could be the case. Mm-hmm. As, as a leader, you go to your manager and say, I think this is important. Um, here's what I want to do. Um, to help with this issue. Um, they might say no. Right? And that's absolutely okay. Um, but it, I think it's, like I said, it's all about having that environment whereby you can still have those conversations and people can still come to you.

Um, I think as a leader you should look at your team as like, Somewhat a mini company in that, in, in that sense, um, whereby everyone in there feels comfortable to come to you and they may not be comfortable to come to anyone else above them. Uh, but I [00:37:00] think that challenge is, is having that conversation itself.

There might be a no, um, And it could be the case, someone says, no, we're not having that. We're not pushing that forward. Um, but often it is a yes. So I think you need to be that voice for the people in your team that do see the benefit in that. So yeah, I think the challenge could be that it would be shut down by, by someone else.

Right. But I think you need to be that person to kind of push those things forward. Otherwise it

Aaron Rackley: won't change. Yeah. Yeah. A hundred percent agree with you that, I know that you said you ha, you've mentioned a few times that you have a blog, um, Sorry, a podcast. Can you just quickly let us know what that podcast is about?

Because I want I 100 after I've listened to a few episodes after meeting you. And I definitely want you to come back onto this podcast again in the future, um, maybe with one of your guests. Um, because I would, I'd like you guys to bring a woman's approach to this conversation that I'm trying to achieve.

Um, so I definitely want you guys to come on [00:38:00] at some point and talk about. Women in tech. So do you wanna just quickly give five minutes on what your, your podcast is about?

Yeah,

Sade Turner-Moise: yeah, of course. So my podcast is, is called Women Talk Tech. Uh, and I guess the, the main aim of it is to encourage more women in the tech space to talk a lot more about it.

Um, whether we talk about our challenges, we talk about what we love about the tech space, we talk about how we've achieved what we have done. I think having that conversation, you know, I think a lot of women. Tend not to speak about it. You know, you mentioned that men also pay rises more, um, than, than women.

Mm-hmm. Or whatever the case may be. So I think the podcast really is, is aimed to share the successes of women in the tech space of all areas. Whether you are an engineer or someone like myself who's helping more to get into this space, that's what it's aimed at. Um, and I think. The, I guess my main goal really is to not just share the challenges.

I don't want the podcast to be quite doom and gloom. I don't wanna just talk about the low numbers about women in tech. Mm-hmm. Cause if, if you hear such [00:39:00] bad things, how would any other person wanna get involved? So, yeah. I think the main aim really is to, to kind of really shed a light on why more women should be in a tech space and why more women should actually stay in the tech space.

Um, so whether that's working towards a leadership role, like you mentioned, right? Um, or working with that CTO or even founding your own tech company, um, I think tech is a really exciting place to be in. So I, I hope my podcast is showing that and showing that women can be there and yes, it, yes, you may be the only female engineer there, but there will be others coming.

Aaron Rackley: Yeah. Brilliant. Yes. A hundred percent need to have you come back and we should do a whole episode on just women in tech in general. Um, So, yeah, hopefully we can arrange that. Yeah. So in a second I'm gonna ask you to plug everywhere people can find you online. But before that I, one thing I like to do with all the guests is I like to ask you to recommend a book.

Just one book that if you're on a desert island [00:40:00] and you have one book to recommend to people to read, it doesn't have to be tech related, it could be life, it can be just your favorite novel. But I think what I'm trying to do is on the website, eventually I'm gonna build like a bookcase of just all the books.

Yeah. That everyone's recommended. So, You can take a moment to think about it.

Sade Turner-Moise: Yeah. I about say, I'm thinking now cause I, I'm such a reader, but I literally from like self-help to absolute thrillers.

Aaron Rackley: Uh, well you could, you could always pick one from each section. So I think last week someone said like, here is my fiction of choice, but here is my non-fiction of choice.

So, yeah.

Sade Turner-Moise: Um, yeah. I, I, like I said, I read from thrillers to self-help books, I think. One book that I've really, really loved is, um, atomic Habits, um, by, yeah. Great book. Yeah. Has anyone recommended it already? No, but

Aaron Rackley: I, I've got that sitting up on the shelf somewhere, but I can't see it. How, which is being

Sade Turner-Moise: annoying.

Amazing. Yeah, so my boss actually recommended me to read [00:41:00] it. Um, and I, I, like I said, I've read thrillers before and I've never, I, I was in, I was kind of stepping into that kind of, Realm of books, but never really kind of got stuck into it. Mm-hmm. But I think yeah, if you've not read it before, definitely, definitely, definitely grab it.

I think it just looks at ways you can build habits for all aspects of your life. Um, and I think for me, um, that was really good because I was able to apply it to so many different aspects, whether that was work, relationships, family, um, you know, going to the gym. It was just ways we can make small differences in, in my life that will have a massive impact.

Yeah. Um, and I think that's that for me. I think if I'm gonna read a self-help book, it needs to be very practical. And I think for me it was really practical. Good, clear takeaways. And I think yeah, definitely, definitely would give it a read, for sure. Yeah. No,

Aaron Rackley: I've, I've read Atomic Habits, uh, fitness by James, clearer it Clear.

Yeah. Uh, and he's done a co Yeah, he's done a few other follow-ups as well, I think, uh, if I remember correctly, but yeah. Yeah, I definitely. Definitely a great book.

Sade Turner-Moise: Yeah. And I think [00:42:00] for me, whenever you look at making a small change, you, well, making any change, you focus on the, on the massive thing. Like, oh, I want to, yeah.

To kind of buy a house in five years time and the house is the main focus. And for me, that's a massive goal for me. But I think I was not looking at the small things I could be doing day to day to help me get that. I was like, how I was on the right move every day, you know? Yeah.

Aaron Rackley: I think, I think we all just naturally have that, that problem in general is we, we always are not, I guess we don't necessarily take the time to appreciate the little steps that it takes to get to where you are going.

Yeah. And so, you know, you're just willing to just jump straight there. So, yeah. No, definitely a great book. Uh, I'll definitely add that to the list. Yeah, a hundred percent. And did you say you had one called Split the Difference? Yeah.

Sade Turner-Moise: Never split the difference as well. Um, that is by Chris Boss and never Split Difference.

Yeah, never split the difference. Um, it also is called negotiating as if your life depended on it. Um, I love Oh, okay. [00:43:00] Really, really good. It's actually by a former F B I, uh, hostage negotiator. Uh, and he just gives, I would say, Again, probably really, really practical habits. I think there were nine, uh, nine principles, um, to help you succeed, um, and negotiate.

Mm-hmm. And I think for me, negotiating is part of my job. Right. Um, but equally, um, I negotiate when negotiate the supermarket or I, you know, everywhere you get a chance. I think it's really good. You know, when you go to the market and they're like, oh yeah, 10 pound. I'm like, no, you know, do it for seven.

Okay, I'll do it for eight. Do it for, you know, come on. So I think, you know, having that skillset to just know when to do it and how to do it, I think that was really good. I think, yeah, like the Chris boss, uh, and Raz, um, yeah, really, really good. Cool.

Aaron Rackley: I will add that one on as well then. Yeah. So thank you honestly for coming onto the podcast.

Diversity inclusion is something that I need to spend a lot more time delving into. Um, I've only done a few [00:44:00] simple courses that the companies have provided over the years, but I feel like it's a deeper topic that I need to actually go out and spend more time exploring. Um, so I appreciate the time coming on to talk about that.

For anyone listening, where can everyone find you online?

Sade Turner-Moise: Yeah, yeah. So of course, uh, my full name is Charade Tomo. Uh, check me out on LinkedIn. Um, I often do kind of write different posts about, you know, women in tech about, you know, how to, you know, navigate interviews. So yeah, all different aspects of posts, but yeah.

Um, also my podcast is on Spotify. It's called Women Taught Tech. Um, you can find ourselves on Spotify, uh, or on YouTube on our company page. So in par of search. Um, so yeah, check it out. Um, really, really interesting. And we also have some, some exciting guests. Planned. Um, so yeah, I think if there are any women listening who are struggling to break into leadership in the tech world or even just, you know, looking to become an engineer, um, definitely check out the podcast cause I hope it has some practical tips for women to get into the tech space.[00:45:00]

Aaron Rackley: Perfect. And once again, thank you for coming on.

Sade Turner-Moise: No, thank you Aaron for having me. Super was a great, complicated conversation.

Aaron Rackley: Hey, I hope you enjoyed today's conversation with Sade. Thank you for making it all the way to the end of this podcast. If you like this conversation, can you do me a big favor and can you share the podcast and like it on the platform, your choice, and even leave a review?

It really does help us reach a wider audience. And finally, once again, if you're a tech leader and would love to come and have a conversation with me about a subject you're passionate about, please email me via contact@techleadershipcode.com. And I'll see you in the next episode. Thanks again. Bye.

In today's episode, we are in conversation with Spencer Norman and we talk about Delegation; what it is and what tips and tricks there are to master it.

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Spencer Norman

• https://spencernorman.com
• http://linkedin.com/in/thespencernorman/
• https://twitter.com/spencernorman

Frameworks

• The RACI model
• Comfort, Stretch Panic Model
• Eisenhower Matrix

Book Recommendations:

• Nonviolent Communication -- A Language of Life: Life-Changing Tools for Healthy Relationships (Nonviolent Communication Guides) by Marshall B. Rosenberg

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hi everyone. My name's Aaron and welcome to this episode of the Tech Leadership Decoded podcast. The podcast where through conversations we unraveled intricacies of leadership in the tech industry and provide insights on how to become a top performing leader. Today we're in a great conversation with Spencer Norman answering the question, what is delegation and how do I master it?

I hope you enjoyed this conversation as much as we did recording it. And if you'd like this conversation, please do remember to subscribe to this podcast on your favorite player and stay tuned for upcoming episodes. And if you're a tech leader and would like to come and have a conversation with me about a subject you're passionate about, please email me via contact@techleadershipdecoded.com.

And with that, let's get straight into today's conversation.

Okay, Spencer, and thank you for joining me today. Um, and we're going to have hopefully a very super fun topic of discussion, which is delegation. So the question I will be [00:01:00] asking today, and hopefully you'll be answering, is what is delegation and how do I master it Now before we get. Into that conversation.

Why don't you just quickly introduce yourself and just let us know your career and basically why you're interested in delegation in general. Wonderful.

Spencer Norman: Well, so nice to chat with you today, Aaron. Uh, my name is Spencer. Uh, I'm a engineering leader at Privy, uh, privy. We build software for, uh, e-commerce retailers and businesses to, to market effectively to their, their audiences.

We focus mostly on, uh, small to medium sized businesses, and we build tools that. Allow them to, to grow their lists, to, uh, market via email and sms. And I've been in e-commerce in some fashion for the, the better part of my career. Uh, prior to being here, I was with, uh, a company called MailChimp. [00:02:00] Uh, which was acquired by Intuit.

Uh, I got to MailChimp, uh, via an acquisition of an open source e-commerce platform software. So we built e-commerce software, uh, with node js. Uh, we built a, a fairly large open source project that, that MailChimp ultimately bought and turned into a, a product that is now called MailChimp Open Commerce.

Okay. Uh, we had contributors and, and users all over the world of that software. Um, And prior to that I worked in a, a startup that rented outdoor gear and, and shipped it all over the, the country. Uh, I'm based in the, the US and Colorado. Um, and we would rent mostly ski and, and snowboard gear and we would deliver it directly to customers rooms.

And one of the challenges we had there was around the rental model where anything that we sent out had to come back. Mm-hmm. And we had to wash it and we had to get it ready. And there was a decent amount of. Kinda logistics and [00:03:00] planning, uh, software that we had to build to make sure that the inventory we were projecting for the late ski season was actually, you know, going to be available, uh, after it had been used a few times.

So, been in e-commerce for a while. I've been in software leadership for, for a while. Um, and I think delegation is an important topic to me because it's, uh, as one of my former managers would, would tell me. Uh, it's really how you scale yourself, um, going from what can I do individually to, to help the company or to, you know, solve a problem to, you know, how can I solve a problem that's bigger than something that I can handle all by myself?

And I think mm-hmm. The, one of the answers to that INV involves learning how to in, you know, incorporate other people into that solution. And I think delegation is a really key part of that.

Aaron Rackley: Yeah. So let's start off with, um, a basic definition of how you are defining delegation in the context of [00:04:00] leadership.

Spencer Norman: Yeah, so I think I, I, I see delegation as. Uh, something that is multifaceted, but there's kind of two different A approaches that I'm gonna look at when delegating. Mm-hmm. So one is, as a leader, you're gonna hire people who are better than you at something, and I think that's just a really important part of leadership.

Uh, you should not be the best at everything on your team. There may be certain tasks or skills that you have that you have not hired somebody else to take over, but you know, by the time you get to a certain size or a certain size team, Uh, you've hopefully hired people who are specialists in certain areas, and so you may delegate certain types of decisions or certain types of tasks where you have somebody on your team that you've specifically hired to be really great at that particular, uh, type of work.

So, you know, I would call this, uh, type one delegation is, is what I've referred as, and it's because you're, you're [00:05:00] delegating it because you are not the best person on your team to do it. I think there's another. Layer of delegation that is more about growing your team. I've called this type two delegation, uh, and I think it's when you have something that, that you need to have done, but the, the criticality of that task is not so high.

That it must be done perfectly or it must be done right the first time. And you can use these types of tasks, uh, to help people who are either newer to leadership or newer to a certain skillset, start to develop that skill. Um, so you know, this is, you're delegating because it's an opportunity to learn for somebody else.

Aaron Rackley: What do you think? The most common kind of misconceptions do you think that people have around delegation?

Spencer Norman: Yeah, it's a great question. So, uh, I guess the first place that my mind goes is toward, uh, just kind of like what [00:06:00] is the context that somebody needs? And I, I think let's, let's both focus very specifically on.

Delegating decisions mm-hmm. Rather than maybe tasks. So yeah, we're, we're not talking about can you send somebody to go get the coffee? We're talking about can you delegate the decision making authority for something that ultimately may matter. Mm-hmm. Um, and I think that, you know, what con I think about what context does somebody need to have in order to make that decision?

And I think there's, there's two ways. One of my old bosses, Sarah Hicks, who was, uh, the CEO at Reaction Commerce and the leader at at MailChimp for a while. She taught me that we can either push information to the people who have decision making authority, so you can try to aggregate everything that everybody in the company knows, and you can try to push that information up to whoever the boss is who ultimately, you know, has the the authority to decide something.

Or you can try to do the inverse of that and you can try to take that decision making authority and push that to the people who have the [00:07:00] information. And, you know, I think about both of those is you're gonna have information flowing both ways. You can't ever take all of the information, you know, and it's not always going to be exclusively in the domain of a single person or a single department.

But if, if we try to push the decision making authority to the people with information, which I really do think is a, is a core part of delegation. One of the other things that I think we have a responsibility as leaders to do. Is to push the context that we believe is important for that decision. Now, maybe it's, you know, company priorities.

Maybe it is, uh, you know, kind of the, the ultimate timeline that we want for that particular task. Maybe it's, uh, a list of other people, other stakeholders that need to be involved in that decision. But I think one of the things that goes wrong about delegation fairly frequently is that we ask somebody to, to decide something.

Mm-hmm. We don't necessarily give them the context that they need, that we have to make that decision [00:08:00] effectively. So we say, Hey, can you, can you make a decision about, I don't know what cloud provider we should use? Mm-hmm. And then when they decide on, I don't know, GCP or, or some specific technology, They come up with that decision and they come to us and we're like, oh, maybe not that decision.

We, we actually wanted you to make a different decision. And as soon as we start second guessing the decision that they've made, I think it, it usually means two things. One, they're not gonna feel as confident or as comfortable to make decisions. Mm-hmm. In the future. We've already kind of taken that power or that, that authority from them.

And two, it probably means we didn't actually do a good job of communicating the context or, you know, what was important if they made a different decision than than we thought they, we, we should have made. Uh, did you actually delegate that decision and did you, you know, share the, the information that, that you felt was important?

Aaron Rackley: You know, I agree. Um, I see this quite often because I do a lot of, um, kind of like solution designs for clients and stuff, and [00:09:00] sometimes, like you say, I can forget to give that, um, context to software engineers. If I say, can you go and find me a CMS system for this client? But I might not have given them the necessarily information of like the budget for example, for that project.

Cuz there's a lot of CMSs out there and they variety, um, price. Okay. And licenses as well. Like some places don't, they like to host their own, they don't want to be hosted as well. Right. And I think that's definitely an interesting, um, Have interesting thought there. Um, so thinking about that then, what do you think are some good strategies or best practices for basically effectively delegating these tasks?

Spencer Norman: Yeah, so I, I think one of the things that is maybe most critical here, uh, and I've actually talked a little bit about this at. Uh, a conference called Lead Dev where I, I dug in specifically on this. I think it's really important to be clear [00:10:00] about what you're delegating. Mm-hmm. Uh, and in, in some cases. And then, and really how much autonomy, I guess is the other piece.

How much autonomy do you want to give? Um, I think another, I guess going back to your misconceptions question, but another misconception that people can have is when you delegate. Maybe they think they're just supposed to go off in a hole and they're gonna come back. Mm-hmm. You know, in a week or in two weeks or in a month with a fully thought out decision.

And, you know, you're delegating it because you don't wanna be bothered with the decision. Yeah. And that may be true in some cases, but I think frequently you're trying to say is, Hey, can you go do some research on this? Or can you, can you collaborate with me on a decision? And if, if what you want is for somebody to check in with you, if you want to ultimately, Uh, I think about the kind of consulted, informed, uh, kinda responsible, consulted, informed model, right?

So if, if you still want to maintain, uh, some ability to, in [00:11:00] influence this decision, make that very clear. You know, if you want somebody to inform you after they've made a decision, that's a, that's a different. Approach here as well. So I, I do think being really clear about what decisions or what information gathering or what, uh, tasks you're intending to delegate, uh, and what you would really still do want to be consulted about is pretty important.

Uh, and then I guess another thing that stands out to me here, and this is just kind of stream of consciousness thinking, but delegation really doesn't absolve responsibility. So as the leader, you're still responsible for making the right decision. Yeah. And when you ask somebody on your team or somebody in a different department to take on a certain part of that, that does not absolve you.

If that goes poorly, that does not absolve you of the responsibility of making that decision. You still have to own that, and you have to own that. You know, in, in, in some ways your decisions to delegate parts of that will impact the outcome. And I think [00:12:00] in the ideal case, and for a great leader, it's gonna impact the outcome well because you've built a team that is capable of, you know, filling your gaps and taking on things that you are not necessarily great at.

But there's certainly a, a negative flip side to that, where if you delegate things to people who aren't ready for them, or if you give away too much of the project, you can end up with. Uh, you know, a, a poor decision on your hands that, that you have to be, uh, still responsible for.

Aaron Rackley: Yeah, no. Um, just, uh, you quickly threw in there the, um, I think it's like the racing method, didn't you, that, uh, do for people that obviously might not know.

Do you, could you quickly explain what that is just for two

Spencer Norman: seconds? Yeah, so I guess the, there's a ton of different versions of this framework, uh, but there's, you know, a number of, of frameworks for, I guess the, the RCI is kind of the, the typical term. But it's stands for responsible, accountable, consulted, and informed.

And it's, uh, typically [00:13:00] displayed as a matrix of, of people and their role in either a decision or a project or, or something else. And I think of, you know, the, let's say the accountable party as, as the one who will ultimately answer upwards to somebody for either, you know, the decision or the project. You then have a responsible party.

And sometimes these roles will overlap. You know, I think especially at smaller companies, you may have the accountable person who is also responsible, uh, for the, the decision making. You have a, you know, somebody who is in a responsibility seat, who is tasked with getting this work done. And then the other two I think are really interesting in the context of delegation, and that is someone who's informed.

Uh, so the I of the RACY stands for informed. And typically what that is, is, uh, Somebody who needs to be told about the decision, but doesn't need to be involved in the, uh, process of choosing the decision. And one, once that decision has been made, you need to make [00:14:00] sure they're aware of any changes that, that, uh, it implies consulted is, is a little bit different.

It's not necessarily the person who's responsible, but they will have a stake in this. And if you make a decision without consulting them, without, uh, considering their needs or, or their. Uh, requirements in the, in the process, you're gonna end up in a spot where, you know, maybe you made a, a decision that doesn't actually meet the needs of everybody at the company or mm-hmm.

You know, you're, you're building something that doesn't capture all of the, uh, you know, different elements. Uh, so that's how I think about the raci mm-hmm. Chart. There's again, I mean there's, if you google this, some of these different versions, there's a hundred different versions of this and people who use different words, but I think in terms of delegation, As the, as the leader, one of the most important things that you can clarify for your team is, do you wanna be consulted on this decision?

Do you want them to come up with some ideas and, and kind of pitch them to you and, and convince you where you're maybe still actually making the decision or at least [00:15:00] still in involved in that? Yeah. Or do you wanna be formed? Do you want them to go off, make a decision and just let you know when it's changed?

And those are gonna be very different. Approaches to that delegation. And it's not that one of them is good and one of them is bad. It's more that there are reasons to choose, uh, each and in any given context.

Aaron Rackley: Yeah. No. Awesome. Thank you for explaining that. I thought it just ties in nicely to what you were saying.

Um, So you mentioned some good strategies, some kind of nice practices, but you also kind of alluded to kind of like some risks. So what kind of potential risks or pitfalls do you think that leaders can have when delegate into their teams? Like, what can we, where can we avoid? Well, what should we try and avoid?

Yeah,

Spencer Norman: yeah. So, I mean, we talked a little bit, I think about the, you know, avoiding, uh, lack of clarity around what it is that you're actually. Yeah, delegating. Um, I think another pitfall and, and I talked a little bit about this, [00:16:00] but is trying to delegate something without delegating any of the decision making.

So if you want somebody to, to do something, but you want them to do it your way, yeah. Are you actually delegating that? You know, I think it's important to ask yourself, like, why do you want this other person to take on that responsibility if you already have a decision in mind. Now I think there are reasons to, you know, maybe coach somebody through how to think.

About a particular problem. But if you're trying to get somebody to do all of the work, but you just want them to do it the way that you would've done that, I, to me, that's micromanagement. You know, that's really not delegation. So I think that's a, a piece, you kind of have to find this happy medium between micromanaging the, the work and totally abdicating responsibility.

Because again, you can't, you can't just. Assign something and walk away and, you know, not care about the result. Um, so I think that's a, that's a [00:17:00] piece. Um, so, and I think that comes through really providing that context, making sure that it's clear what is important about this decision, and then providing the person as much autonomy as you can.

And that's gonna be different for a more senior person in a, in a leadership role who has maybe the specialized skills to do this well than it is for somebody that you're coaching and trying to grow.

Aaron Rackley: I think that's interesting because the other thing that I think can come from delegate, uh, delegation is helping to build trust in teams and individualism is do you have any thoughts around that area?

Spencer Norman: Yeah, so I do think there's, there's, there's a lot that goes into this, right? Mm-hmm. And there's a, there's actually a, a framework that I like. Um, which is panic, stretch, comfort model. Okay. Is kind of how I've thought about this before, but when you are, when you're delegating work, I think one [00:18:00] of the, the key factors of whether that work will be successful or unsuccessful mm-hmm.

Is how comfortable is somebody at taking, taking on that work. So let's call that one. And then the other piece is how psychologically safe do they feel to fail? And when you are delegating something to somebody who does not feel safe to fail mm-hmm. They're going to take the easy path. Most of the time, they're gonna take whatever it is that, that makes them most confident to succeed, even if maybe that's not the best solution or the best outcome.

So there's a, a model that I've liked, which is, again, it's the comfort, stretch and panic zone. Mm-hmm. And the comfort zone is a, a place where, Somebody has operated before, they're very familiar with that domain or with that technology. Um, they, you know, feel highly confident they can do it. It's not something that's necessarily gonna push their boundaries or [00:19:00] stretch them at all.

The stretch zone is, is that area where somebody is, you know, Maybe capable, but maybe they don't know that they're capable of this yet. It's, it's something, you know, I think if you think about the more junior engineer or somebody stepping into system design for the first time mm-hmm. And you know, they can do it, but maybe they don't yet feel confident that they can, they can lead that.

Yeah. Um, and so that stretch zone, I think the size of that stretch zone is going to be very dependent on what happens to people if they make the wrong decision. And in a, in a very psychologically safe organization where, uh, failure is not met with animosity or punishment, yeah, you're gonna have people who can really grow into these exceedingly leadership oriented roles.

You know, maybe they fail the first time, but I think often it's just that safety to fail that allows somebody to take a chance and to prove that they are very [00:20:00] capable of doing whatever that that work is. Beyond that stretch zone is the panic zone. And I, again, I think in a psychologically safe organization, the panic zone shrinks pretty significantly.

Mm-hmm. And a place where it's not safe to fail, though often you'll have your comfort zone and then immediately outside of that comfort zone is the panic zone. Okay. And anytime you're asked to do something that you don't feel confident about, you're gonna panic because you know that the responsibility or the, the say, the consequence of failure.

Is significant. And so I think as leaders, the more we can do, uh, you know, not to make failure on the, you know, organizationally impactful side of things. Easy. We, we do want to be responsible about how we fail. Mm-hmm. But to make, you know, that possible for people to fail in a way where they're growing and learning and it's not catastrophic, we'll actually make it much easier for people to grow into new roles and to take on new responsibilities.

[00:21:00] Um, So that I, I think of that as, as a way to build trust. And when you are delegating to people, one of the things to think about is, is this something where I'm delegating it because it's in their comfort zone and I know that they can do it really well? Yeah. From the beginning? Or is this more that type two delegation where this is intended to help them grow?

It's intended to help them stretch. And in that latter case, are you gonna put somebody into their panic zone where they're probably un incapable of? Operating effectively, or is this something where you're putting them into the stretch zone and maybe you need to pair them with a mentor. Maybe you need to pair them with somebody who can help them do that well, but you still want them in the, in the driver's seat.

In

Aaron Rackley: your experience, do you think there's any indicators, uh, that leaders maybe need to delegate more or how can you tell if you're not doing it? Correctly, as we just said before, the balance, right, of getting people that are gonna do it well, people that are [00:22:00] gonna push themselves. Like how do we get that?

Mm, how do we know if we're doing it wrong? Or how do we know if we need to do more of it?

Spencer Norman: Yeah, that's, that's a great question. Uh, I think this is probably more art than science if Yeah. If I'm on it. Uh, so I don't have a, you know, I don't have a specific gradient I can give you that will, you know, allow you to put yourself in a, in a spot, at least the whole

Aaron Rackley: point of the podcast, right.

Get many people's artistic opinions.

Spencer Norman: But I do think, I guess a few heuristics I would look at. One is, are you totally stressed out and overwhelmed? Mm-hmm. Right? And, and as a leader, You know, I think there's, there's only so much you can do as an individual and the bigger your team is or the bigger the types of, you know, projects or tasks that are being delegated to you.

So unless you're, you know, the founder or ceo, Chances are that you're not the top of the chain and somebody else is delegating something to you. And that's why you have a job is because somebody has asked you to take responsibility [00:23:00] for something, you know, and the, uh, more senior you are in a, in a company or an organization, the bigger those chunks of of work or those, those projects are going to be.

So, you know, are you trying to take on too much of that? And I think the, the main heuristic I would look at is, Are you incredibly stressed out about how much work is on your plate? Mm-hmm. Uh, so if that is the case, what is it that you can take off your plate by asking somebody else to do? And in some cases, this may be something where you don't feel like you have a team member who is gonna be great at this.

And I think that's where, you know, kind of the management, uh, I'll call it a responsibility, but the, the management opportunity, let's say, to grow people on your team, just because you don't have somebody who's good at something now doesn't mean that you don't have somebody who can take this on and learn it.

You know? And if you've hired a team of, of great people, one of the things that I look for in hiring is, you know, kind of a [00:24:00] growth mindset and somebody who's coachable. And so can I teach somebody who maybe is not an expert at this, how to do this well? And in the first time you do it, it maybe doesn't remove a lot from your plate because instead of doing, now you're coaching, in some cases, I think coaching is actually, you know, more effort or, or at least different effort, but the same amount of time.

But what you do is you take that particular topic or that particular domain and you build expertise on your team about it. Um, and so I think that's, that's one of the pieces. I think the other thing, and this gets a little bit at hiring and, and team building, But how do you build a team that can fill the gaps?

Mm-hmm. You know, I think one of the things for me that will lead to stress is if I feel like there is a task that needs to get done that I personally don't have expertise to do, and I also don't trust anybody else on my team to do it. And that's scary because I know this has to get done and, [00:25:00] you know, I don't, I don't know necessarily that I can do it well.

And so that I think is, is part of that team building conversation where you, you do wanna make sure that you're aware of your own, uh, skill gaps. You're aware of the things that you're good at and the things that you're not good at. And those things that you know you're not good at, you can hire for those.

You know, there's no expectation that a leader has to be the best at everything. And I think. The best leaders are very quick to acknowledge mm-hmm. Where they're not experts. Yeah. And to make sure that they are filling their team with people who can, uh, help them with those things.

Aaron Rackley: Yeah. I think I've found the best leadership that I've worked with in the past, there's always been people that know where their shortcomings are and their, their weaknesses are, and that allow the team to.

Pick up and take that information. Right. Um, so I think that's really interesting. I think, um, one question I actually just thought of is, let's think about this from a non [00:26:00] non-leadership mindset for two seconds. So I'm part of a team and I can see that my leadership is probably doing too much and I think I can offer some help.

Do you have any. Advice on like how you'd approach that,

Spencer Norman: right? Yeah. So I will caveat this by saying that I think approaching people in leaderships or in leadership positions can be one of those things that operates differently. Yeah. For people in a privileged position. And I think for me, uh, I certainly am.

So I would say, you know, first, first is to, to make sure that the groundwork is there Yeah. To approach somebody in, in a position of power. Mm-hmm. Um, so do you have a relationship where you know, you feel comfortable? Either broaching the subject that you don't think that they are doing something well, you know, providing that feedback.

I think this project is not going as well as it could [00:27:00] go. Or, you know, something like, you know, giving them feedback that you think you might be better suited for a particular type of worker project. So I think before broaching that is, is to make sure that you feel like you have a, a relationship with them where that will Yeah.

You know, Be appreciated and, and not punished. And, and I think that is gonna be different for every person. And I can't give specific advice on Yeah. You know, any, any individual's position, but assuming that you do have that, that relationship and that groundwork. Um, I think the, the thing that I appreciate is when somebody identifies something that is, Either not going to plan or, you know, where there is a gap either in the organization or in the tech stack and brings it to me and says, Hey, I think this is a problem and I would like to personally help fix that.

Yeah. And I think the, the next layer of that is to, you know, bring a, a solution or, or some, some approach where I can actually see the [00:28:00] thought work that they've already done on that. So, you know, I think it's one thing to identify a problem. There's. People I've worked with who you know, will say, don't bring me problems, bring me solutions.

I think that can be naive. I think it's, you know, it's valuable to know where your organizational blind spots are. Yeah. I tend to not try to dissuade or I tend to encourage people to bring problems even if they don't have a solution. But I think for the more senior folks, and I think when, for me, when, when you get to be, let's say a staff engineer, one of the things that I'm looking for from my staff engineers, Is for somebody who can not only solve a problem, but they can also identify the problem.

Yeah. You know, I think of a, a great senior engineer, I think of as, as somebody who I can delegate just about anything to. Mm-hmm. You know, I see a problem or I see a business need, or I, we have a particular product that needs to get done. Senior engineer can do all of the coding, they can do all of that work.

A staff engineer needs to be able to proactively identify problems that we're gonna encounter in the future. [00:29:00] Make a business case for why that needs to be done. And you know, then in some cases they also need to be the one to execute and, and ultimately solve that. So, you know, I think kind of proactively stepping in and, and volunteering to take something on is, is a great place to start if you're wanting somebody to, you know, delegate something to you.

Um, I think having, having that conversation, um, And one-on-ones is a great place to do it if your organization has a, a good habit around one-on-ones. I know a lot of organizations that don't do a good job delegating, probably also don't have, you know, great one-on-one meeting cadences. So, you know, there's other ways to do that.

I think if you don't have those one-on-one topics, put together a proposal, you know, maybe it's an rfc, maybe it's a tech spec, but something that identifies the problem, the context, why you think this is important. And then, you know, there's always gonna be various degrees of this, but to some point, how you would think about solving the [00:30:00] problem.

Yeah. How much resources you think it's gonna take. Why it's, why it's gonna be important to the customer, to the business. Yeah.

Aaron Rackley: And then I think on the other side of that is, um, you know, how we respond as leaders when that that comes forward. Right. Um, so I think what, like what you're saying there is just be open-minded, don't.

You know, I think the nicest way is don't be a dick. Right. Don't be nice about it. Right. Um, cuz like you say, for some people it can take a lot of courage and a lot of, um, well courage is probably the best word. A lot of courage to come forward and even put themselves into that position. Right. Absolutely.

So,

Spencer Norman: cool. I think that's a, that's a great point just to riff on that for a second. Yeah, go for it. But even, even if somebody brings something to you that seems. Idiotic, right? Yeah, it, I think it can be valuable still to recognize the effort that went into putting something together and being willing to approach somebody in a leadership position about [00:31:00] it.

Even if you think, Hey, you know what, this is really dumb. I think acknowledging that effort and trying not to dissuade them in the future because maybe this idea. Ultimately wasn't the right idea. But if you squash that type of approach, or you squash that idea, or you squash that effort that somebody's making to proactively solve problems, mm-hmm.

Guess what? They are probably not gonna bring you something in the future. Yeah. They're gonna keep that to themselves. So I think even in cases where it's not this, you know, solution or perfect problem that you actually care about. Continuing to encourage that. Maybe you don't prioritize that particular one, but encouraging that type of behavior is really critical.

Yeah,

Aaron Rackley: no, a hundred percent agree with you there. What advice do you think we can give to leaders who might struggle with delegation or, you know, hesitant to let go of control?

Spencer Norman: Yeah, so there's a, I guess it's like a matrix. I think it is a riff on the Eisenhower Matrix that I've, I've used to [00:32:00] encourage people to.

Figure out what types of things they can delegate. But it's, it's a two by two matrix. And on one axis we have, let's call it the kind of the consequence gradient. Yeah. So we wanna map things from low consequence to high consequence. And I think that that in terms of, let's say the impact of, of something not going to plan.

Mm-hmm. And then on the other axis, we have the reversibility. Of that action. So you know something that's very reversible, you make the wrong decision, you can make a different decision tomorrow and, you know, just change, change your mind and it's not a big deal. Or, you know, at the other, a end of that axis you have something that's totally irreversible.

You know, maybe it is, uh, firing somebody might be an example. Like you can't undo that. If you make the wrong decision about firing somebody, they're not coming back. Uh, and so you can, you can map this out and so you have kind of four quadrants of [00:33:00] this matrix. You have inconsequential and irreversible, so something that really doesn't matter, but if you make the wrong decision, you can't undo it.

Mm-hmm. You have below that, let's say inconsequential and reversible. You have consequential and reversible, so something that really matters a lot, but if you make the wrong decision, it's not terribly difficult to change it. I think of many code changes that don't involve the database as being in this consequential and reversible yeah, segment where maybe it's a big deal, maybe the app goes down, you know, it's not great.

We don't want that, but. You can push a revert in seven minutes if you have a, you know, a good yeah. Ci cd stack, and it's always over. You're back online. Now, learning, again, you don't want to be taking down your whole production app a lot, but as long as it's reversible, there's some opportunity there to, to allow people to, to flex.

And then in the the final corner, kind of this top right, you have consequential and [00:34:00] irreversible. And these are decisions that are both, you know, of magnitude either to your team or to the business. And also, you know, a lot more difficult to undo if you make the wrong decision. And I think as leaders, the more of our time we can be spending in that consequential and irreversible segment mm-hmm.

The better. And if you kind of flip on the other axis, Uh, I think inconsequential and reversible decisions, you should almost never do those. One, they don't really matter. You know, in the grand scheme of things, which decision you make, probably not gonna matter long term. And if you do make the wrong decision, you can reverse it.

Those should be delegated almost a hundred percent of the time. So identify the things that you're doing that just, you know, aren't gonna move the needle. And can you have somebody else take those on? Not necessarily because you think they're the best at it, or because you're. Happy to give it up, but because there's just an easy way for you to, to undo it and, you know, [00:35:00] the, the net impact is gonna be low, I think of inconsequential and irreversible decisions as a great training ground for other leaders.

Yeah, these are the types of decisions where we're gonna have to live with them for a long time, but maybe they aren't quite so impactful as to to really matter. And so it can be a, a place for you to coach. Help somebody make the right decision, because again, you're not gonna be able to make a new decision on this later.

Uh, so identify those things that, you know, may be unchangeable, but just are, are lower impact. Yeah. And I think that's a coaching opportunity. You wanna delegate it, you wanna be consulted on these, not informed is kind of the mm-hmm. The, you know, the framework I would look at. And then kind of on the flip side, I think is another great place for future leaders, but that consequential and reversible.

Where this is a place to get experience doing high impact decision making or, you know, yeah. You know, thinking about something that really does impact the [00:36:00] business. But if they end up being wrong, well, we can make a new decision tomorrow. We can make a new decision next week. We can make a new decision in the next quarter.

And so think about, you know, how long are we gonna have to live with this decision? Uh, you know, and that reversibility is always gonna be a, a gradient. You know, there's never, never just, it's reversible or it's totally. Irreversible, uh, you know, usually there's a, a spectrum there, but how long are you gonna have to live with something?

And I think if you're able to walk through an exercise of taking, you know, let's say the, the more important things that you do on a week to week basis, and you kind of plot them on, on this chart. Make sure that where you're spending most of your time is in that, uh, that that quadrant where it's consequential and irreversible things, and then figure out for anything that's inconsequential, how do you have somebody else on your team do that?

Mm-hmm. And again, I think the, the more senior you are in, in an organization, the, the, the more consequential these things are gonna be. Yes. You know, if you're a ceo, the inconsequential [00:37:00] things to you are gonna be highly consequential. To whoever your team is. Yeah. Uh, if you are a line manager, you know, working with a, you know, QA engineering team, the inconsequential things to you may be, you know, fairly inconsequential to the business.

Uh, and may just extend the timeline a little bit. You know, maybe something takes an extra day to release, not necessarily something you wanna optimize for, but again, if you're resulting in having more leaders on your team or you know, people who are capable of taking on. Uh, additional tasks that they weren't comfortable taking on before.

That's probably a trade off that is worth evaluating.

Aaron Rackley: Yeah. So obviously we've just, you've just gone through a, a great matrix now, I just wanna say, I think this is the first actual podcast where I've had about four or five different. Uh, matrixes, um, racy, you know, you've got yeah. All of these different frameworks, um, for essentially talking about one subject.

And [00:38:00] for me, that just str about, that just shows you how in depth you can get into basically any, um, subject matter, right? There are tools and tricks for everything. And, um, one aspect of why I'm doing this podcast and. One reason, I just wanna get loads of people to come on and talk about different subject matters.

And the same subject matter is for that reason, right? It's that we can read blogs over and over again and, but I think having real conversations with people that are actually doing this work, um, is a hundred percent doable. Um, so I, one more I can, I'm being conscious of the time and so I think if we do one more question, um, and then we'll go on to.

A little thing I like to ask everyone, which I'll get to in a minute. But let's have one final question about, um, the racy stuff. So we're talking about, um, consent informed and your matrixes, and do you think you could go into a little bit more about, um,[00:39:00]

knowing when to knowing. When I should be using one over the other. Uh, does that make sense? I'm trying to, yeah.

Spencer Norman: Yeah. I think, let me try to rephrase what I'm hearing you ask, but we talked a little bit about, let's say, an inconsequential decision. Yeah. That is irreversible. You may still wanna take a consulting role in that and use it as a, as a coaching tool, whereas a inconsequential decision that is reversible, maybe you just want somebody to go do it and let you know when it's done.

And I think of kind of this, this gradient or this spectrum between do you wanna be consulted on a particular decision or particular thing that you're delegating, or do you just wanna be informed as having a few different elements to it? Uh, and you know, being consulted is not a free thing that you can just do.

You know, you don't wanna be consulted on everything because. Asking somebody to consult with you before they make a decision, before they make a choice is [00:40:00] gonna slow it down. Right? Yeah. It's a blocking mechanism, uh mm-hmm. And, and I think it, it puts you in more of a mentoring role. You know, you are teaching somebody, you are, you know, maybe taking more of a, a lecturing or or teaching style approach.

Um, and it's also happening before the decision is happening. So, you know, I think of this as the slow approach. Now, there's nothing wrong with that, and if it's a really irreversible decision or something that's higher consequence, you may still want to take that, uh, approach. Being, you know, or, or allowing somebody just to inform you once the decision has been made.

On the other hand, is, is very fast. You know, it's something where you're not informed until after the decision. And I think of this as unblocking, right? So you are expre expressly letting somebody else take the reins there and you don't need to know until it's done. Uh, this I think, puts you more in a coaching posture and I think of that kinda coaching versus mentoring.

Mentoring, your're, kind of telling somebody, here's how [00:41:00] I would do it. Coaching you are observing it, you're watching how it happens, and then. You're helping somebody process the result. How did that go? What would you do differently next time? You know, what skills do you need to build? Where can we work together so that you feel more prepared for that?

But it's happening kind of outside of the context of that particular decision. It's more helping them prepare and and grow their skills. So that's how I think about kind of, you know, do you wanna be informed or do you wanna be consulted? It's how fast does this need to happen? Can you unblock somebody?

Can you take more of that, you know, co coaching approach here? Uh, and I think there's benefits to that, even if it doesn't necessarily result in the choice that you would've made. Whereas, you know, taking a consultant role, you're really kind of injecting yourself in into that process and gonna slow it down, but it may result in a decision that you are personally more comfortable with.

Aaron Rackley: Yeah, I think what's, um, very interesting from that [00:42:00] is something I've never really thought of. Um, In my experience in delegation is, like you said, there is the difference in time and cost of whether that decision becomes you being a mentor or a, a coach or consultant. Right. I think that's, that's very interesting.

There's something that I'm definitely gonna have to think about, um, moving forward cuz uh, like you say, they both, they all come with their own times, caveats and extra work or, you know, and on them as well, right. Um, yeah. Awesome. Now, I know we've, you could probably talk about delegation forever, and I'm, and I hopefully will probably get you back another time to continue the conversation.

Um, but I'm just being conscious of the time. So before I ask you to, um, Spread the word of where you live online. Um, I have one question I like to ask everyone, and that is if you could recommend to the [00:43:00] audience one book to read. Now, it doesn't have to be tech-based, it can just be, you know, if you just love Harry Potter, right?

Um, just name one book that you think everyone should read. And essentially I'm gonna create a. A bit on the website of just like books that I think every everyone should read. So yeah. What do you, what have you got?

Spencer Norman: The one that stands out to me immediately, and this has helped me both personally and and professionally, is a book called Nonviolent Communication.

Okay, interesting. Uh, I think it's by Rosenberg. I think it's Marshall Rosenberg. Uh, but the book really outlines how to have. Conversations about important topics in a way that kind of avoids putting people on the defensive and, you know, it, it gets into feelings. It gets into talking about, uh, you know, how something makes you feel and you know how you feel about a particular thing.

Um, and the, the title, you know, for me, I looked at the title and I was like, [00:44:00] oh, do I wanna read a book about nonviolent communication? But it was an incredibly, incredibly useful tool. Uh, my old manager, Sarah Hicks, uh, put me onto it. She told me that it was her favorite business book she'd ever read. And I was like, well, all right, I'm gonna read that.

And it's been probably the book that I recommended the most to people who want to be in management roles, but, you know, really any kind of leadership role. Uh, but again, it's also helped me in, in personal relationships as well. So highly recommend nonviolent communication.

Aaron Rackley: Brilliant. I'll add that to the shopping basket right now, cuz that definitely sounds like a book I need to read.

And I've just checked. That's Marshall b Rosenberg. Yeah. Cool. Okay, so next question. Where can everyone find you online? Go for

Spencer Norman: it. Yeah, so I am still on the Bird app. Uh, I think Spencer Norman is my handle on the Bird app. I'm also on LinkedIn, so feel free to, to reach [00:45:00] out to me there. Um, I'm also@spencernorman.com, so I have ambitions to write more than I actually write, but you can find, I think we all have, that you can find links to, to talks I've given, uh, on spencer norman.com along with, uh, some of the other, uh, connections to, to places like the Twitters or the, the LinkedIn.

Aaron Rackley: Brilliant. I will make sure I add them all to the show notes as well. So honestly, Spencer, thank you for coming on and talking about. Obviously delegation. Um, it's been very informative. Um, there's a lot that I've took away from this and I hope that obviously the listeners have too. So hopefully we'll have you on again at some point for either more delegation or a different topic.

But, uh, thank you for joining

Spencer Norman: me. Well, thank you so much, Aaron. It's been an absolute pleasure talking with you and I appreciate the, the conversation. Thank you.

Aaron Rackley: Hey, thank you for making [00:46:00] it all the way to to end of today's podcast. I really do hope you enjoyed today's conversation with Spencer. If you like this conversation, please can you do me a favor and just share the podcast on your social platforms and then like it on the platform.

You're listening to it right now on It really does help us get the podcast to a wider audience. And finally, if you're a tech leader, I would like to come and have a conversation with me about the subject you are passionate about. Please email me my contact@teleadershipdecoded.com and then again, thank you and I'll see you in the next episode.

Bye for now.

Today we are in conversation with Kevin Ball asking what does growth-focused management look like.

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Kevin Ball (KBall)

• https://www.kball.llc/
• https://twitter.com/kbal11
• https://www.linkedin.com/in/kbal11
• http://humanskills.co/
• https://www.youtube.com/@humanSkillsCo
• https://changelog.com/jsparty

Book Recommendations:

• Engineering Management for the Rest of Us by Sarah Dresner
• Full Catastrophe Living, Revised Edition: How to cope with stress, pain and illness using mindfulness meditation by Jon Kabat-Zinn

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hi everyone, and welcome to this episode of Tech Leadership Podcast. The podcast where through conversations we unraveled intricate season leadership in a tech industry and provide insights on how to become a top performing leader. In today episode, we are in conversation with Kevin Ball asking What does growth focus management look like now?

I went into this conversation with a set of questions all planned out. And that immediately got thrown out the window as my understanding of what it meant to be growth focus management shifted. And because of this, you'll see that for me, the conversation soon became a coaching session of Kevin teaching me the ways of growth, focus management.

I hope you enjoyed this conversation as much as I did recording it. And if you like this conversation, please do remember to subscribe to this podcast on your favorite player and stay tuned for upcoming episodes. And if you'd like to come and have a conversation with me about a subject you're passionate about, please email me at contact at.

Tech leadership decoded.com. And with that, let's get straight into this conversation, Kevin, and thank you for [00:01:00] joining me today. And I'd like to just start off this podcast by just getting you to basically introduce yourself and your career and, um, and then we'll get into the exciting topic that I have no clue about.

So I'm really excited, which is growth focus Management. So over to you. Yeah,

Kevin Ball (KBall): sure. Awesome. Well, hello, I'm Kevin or K Ball. I go equally by either of these days. Um, and I have been around the tech industry for closing in on 20 years at this point. Meandering around a wide variety of startups, and I can go into various levels of fidelity as useful, but I think I'll do the, the brief overview right now.

So I, um, I've, I think like conversation at this point. I co-founded two startups. I've worked at four other people's startups. I also ran a consulting firm for a while and now I'm running a small business that is, uh, focused on coaching mostly and some consulting. That and kind of meandered [00:02:00] around different parts of the industry.

I started in super computing, then I got into web. I've been in various parts of web, uh, most of the rest of my. Career. Um, and yeah, the last 10 years or so, I've been doing a lot of what I've seen described as the manager, staff engineer pendulum, where I kind of meander back and forth between kind of technical tech lead roles and people management roles and going up and down through that as the need.

Arises. I, I like to say that I migrate towards pain in an organization. So wherever there is a gap or something that it feels like we need more of that, that's where I end up going. And sometimes that's, we need more technical expertise and sometimes that's, oh my gosh, we need somebody to deal with all these people.

Aaron Rackley: Yeah. No, yeah, there's definitely, uh, similarities in my career. Uh, definitely in that aspect as well. I always find myself creating a role rather than having a role, um, a lot of the time. So,

Kevin Ball (KBall): Well, and that's, that's actually an area that, it's a slight tangent already, but an area I've been thinking a [00:03:00] lot about, a lot, because it comes up with a lot of my coaching clients, is the fact that the roles that we end up in mm-hmm.

It's a co-creative process. Right. It's not, We're in knowledge work, there's very rarely a pure bucket that you say, okay, I need you to do just this. Um, and but sometimes we expect that, cuz that's kind of what the societal expectation is. You're gonna get a job, they're gonna have things for you to do when you're supposed to go do those.

Um, and really in our world, in the tech world, like you have a lot more agency than that and it becomes a co-creative process between you and your manager and your coworkers around what exactly is the niche. Where you are going to derive the greatest combination of joy for yourself learning and growth and value for the company?

Aaron Rackley: Hmm. Yeah. No, a hundred percent. So what is the term growth first ma focus management, and what should I know about

Kevin Ball (KBall): it? Yeah, so that's a good question. Um, I don't know if there's a, if that's a common term or just a me term. Mm-hmm. But, [00:04:00] um, high level, when I think about. Particularly like engineering management, there's a few different pieces of it, right?

Mm-hmm. So there's, there's sort of production management, like what does our core engineering production loop look like? What is it that we should be building? You know, how are we breaking things down into tasks and getting the right people to do it? Kind of that sort of thing. And in some companies, that's done by a tech lead.

In some companies that's done by a. Product manager. Mm-hmm. Some companies that's even done by a project manager. Like there's a lot of this, like just making sure stuff is getting done. And in some companies that's done by an engineering manager. So that's like one piece of engineering management. Um, another sort of focus that one might have in management is around systems and processes, right?

Mm-hmm. How do we set up our organization? How do we set up the right processes so that things happen at the right time? And I kind of. As I think about these, like that's probably my second favorite. Like I really like thinking about those systems problems. And I think this is a lot of, of what goes into management.

Mm-hmm. But [00:05:00] the third big area in management and where growth focus management starts to come in is around a person focus, a human focus. Who are these people that I am responsible for and how am I helping them? And within a person focus. My mindset is always about growth. Mm-hmm. How does this person want to be growing?

What are they working towards? What excites them? Uh, and often they don't even know themselves like that. I, I've had conversations where I, I open up and I say, okay, so what do you want to accomplish in your role here? Mm-hmm. And they look at me and they're like, I don't know. I've never thought about that.

Right. Like, what do you wanna accomplish in your career? What are you working towards? Yeah, I don't know. I'm just kind of stumbling from place to place.

Aaron Rackley: Yeah, that's, I've, I can wholeheartedly agree with that. Cause I, for, for the longest time, I've jumped from job to job and I've never, it's always been in some kind [00:06:00] of creative aspect.

So it's either been, you know, a team lead or a scrum master or a developer or, you know, I jumped over the place for the same reason. And it wasn't until someone said the same thing to me that. This, uh, I think the beginning of this year or the end of last year, where they said to me, take a moment. What do you actually want to do?

Like, take a moment. Yeah. Like, where, where do you wanna head? What, what is it you wanna do? And for me, um, a big part of what I do on this podcast is, and why I started the podcast is because I want to help develop people and teams and process like, and the process around that. So, As with this, I'm reaching out to as many people as I can get on to absorb as much information as I can, and hopefully by doing the podcast, people will listen and gain that knowledge at the same time.

So if as a technical, I'm a technical lead at the moment, so as a technical lead, what, what were the first things I would be looking at if I was to start [00:07:00] looking into growth focus management for potentially team members?

Kevin Ball (KBall): So I would start with a conversation. Mm-hmm. I mean, I, I kind of drift everything towards conversations.

I'm very human and interaction focused. Start with a conversation about, you know, what are your goals? Um, you know, what do you want out of this job, out of this career? Um, and depending on the relationship, sometimes you can just say like, what are you trying to accomplish in life? What's going on for you?

Mm-hmm. Um, and I'm gonna, I'm gonna, Pin that, and put a side side tangent here, which is, I had an experience early on in my time as a manager that led me to open the door to people bringing non-work things. Mm-hmm. And you have to be careful with that. Yeah. Because you don't wanna push for that. You don't want to infringe someone's boundaries.

Some people very definitely want to keep very clear boundaries between work and home. Mm-hmm. But I worked with a young man who was, Early in his career [00:08:00] and when he was on, he was brilliant, but he was inconsistent and he often was showing up late or or other things. And I started working with him and discovered that this young man had.

Like the most difficult home situation I've ever heard of. Right. So he, he was a refugee. Mm-hmm. He was the only English speaker in his family. Um, he was taking care of his mother, his sister. He had a brother who had turned to criminal stuff and would steal things from the household. Um, and like he was the only income.

He was doing all of these different things. And the most effective thing I could do to help him get better at work was to help him think through how to manage his home life in that situation. Okay. And, you know, we talked through things and we tried strategies and experiments and did different things and, and we're able to make substantial progress.

And, you know, he's gone on, he's got a great engineering career at this point. Um, but that opened my eyes to the fact that, [00:09:00] you know, we are not segmented human beings. Mm-hmm. Mm-hmm. I don't have a home K ball and a work K ball, and those things don't connect to each other. Like if I'm having a rough time at home, that's gonna show up at work and vice versa.

And sometimes the best thing I can do is to se try to segment those and just to do a clean jump and only talk about work when I'm at work. And sometimes I need some support on one side that will bleed into the other. And so as a manager, Once again, I'm not pushing it, but I, when I have a conversation about goals and, and I actually, I have a structured process I can go into that I took, would take my reports through.

Mm-hmm. We had worksheets to get you thinking about it and all that stuff. Um, but I would say like, you can keep this focused on just your job if you want. Mm-hmm. You can expand this to look at your entire career or if you want, we can talk about life and other things. And honestly, like some of the most.

Gratifying places that I've been able to help people is when it's with something that reaches [00:10:00] through their home and their work and is something that is just, you know, they're struggling with throughout their life. And if we're able to make progress on that, I have not just helped them do better work in this job where I'm trying to, you know, deliver on something.

I have helped them become a healthier and happier human being. And that is like the best thing in management for me.

Aaron Rackley: Um, So, yeah, you've just, uh, as you were just saying, just then you mentioned, uh, like the process that you've walked through with, um, The team members or, or your coaching clients, um mm-hmm.

Could you give us a little taster into that? Um,

Kevin Ball (KBall): well, and I'll take it from the perspective of working through it as a manager. Yeah. So it is an option that I offer to my coaching clients as well. Um, so as a manager, I had kind of what I called a structured growth process. And we would go through, I had four different sessions that we would go through.

Um, we would start working on goals. So identifying what are your goals, what are you trying to accomplish? Um, you know, what are you already doing? Working towards those, what are some. Low hanging fruit opportunities to work towards this. Mm-hmm. [00:11:00] Uh, next we'd move into strengths. Strengths is an interesting one.

I think a lot of us obsess about our weaknesses, but we don't always think about our strengths and how we can take better advantage of them. Mm-hmm. So I've had folks where I've done this and they're like, wow, this was totally eye-opening. I've never thought about the things that I'm good at before because I spend all my time thinking about the things I'm not good at.

So we talk about strengths and we look at ways to take those strengths and amplify them, take those strengths and use them in more, more places. Um, then we do talk about weaknesses. And another fascinating thing that starts to come up is you start to discover for many people, your strengths in your weaknesses are connected.

They are two sides of some underlying trait that you have. And so what this means, And what is often revelationary is you can't get rid of your weaknesses because by doing so, you'd have to address this trait that is also the source of your strengths. Mm-hmm. Instead, we learn or have to focus on learning how to, you know, work around our weaknesses, find [00:12:00] tools or people or other things that help us, uh, not have to focus on those weaknesses and, and be able to deliver on the things that they've been blocking us for.

Uh, Occasionally you'll find a weakness that is what's called a blocking weakness, that is actually keeping you from your goal. But more often, you know, by spending so much time on our weaknesses, rather than trying to figure out how do we work around them and focus on our strengths, we're holding ourselves back.

Um, so that's the next session. Um, sometimes at this point I would insert a 360 review feedback thing. Depends on your team. Depends on, on how folks, um, are. If that's a culture that's, that's kind of accepted, that can be really. Interesting and eye opening cuz it can show where the places that you have, where you think your strengths are, are those aligned with how others are perceiving you, where you think your weaknesses are, are those where others are perceiving you?

Mm-hmm. Um, so we'll insert that somewhere. Um, and then I do a session focused on roles. And this is where it all starts to really come [00:13:00] together and we look at, okay, for your current role, how is that aligned with your goals? How are you taking advantage of your strengths? Where are your weaknesses holding you back?

How can you look around them? But even more so, what role do you want to grow into? You know, if you are right now working as a senior engineer, do you want to become more of a tech lead? Mm-hmm. Do you want to move towards management? Do you want to become a specialist on a particular system? What is that?

You know, we going, calling back to our, our kind of co-creation process of, we create our own roles. Like what is that role that you want to be moving towards? And what this does is it sets up a phenomenal opportunity then for learning and feedback loops, right? So now not only do they have a clearer picture of what they're trying to do and how they're trying to get there, I as a manager know what they want.

I know where they're moving. And through this process, we've built essentially permission for me to give them very clear directive feedback on things related to [00:14:00] that. Goal, those goals enroll, right? We we know, okay, you're moving towards that. So we're gonna give you an opportunity to tech lead this project.

And since we know it's tied to your growth, we're gonna do some very quick review cycles. Every one-on-one, we're gonna do a quick retro, and I'm gonna give you feedback on, this wasn't working well, this was working well. And then when we finish that, we're gonna get feedback from your peers. And all of this feels aligned because we've been talking about growth this whole way.

It doesn't feel like, oh my gosh, why is my manager telling me this stuff again? Like it's connected to this story of growth.

Aaron Rackley: Yeah. Okay. No. Yeah, like super interesting. All of this, I'm, I'm literally, as I'm sitting here, I feel like every time you say a sentence, my brain is spinning on a will cuz I'm like, okay, I feel like I am being coached right this second in terms of like all this

Kevin Ball (KBall): stuff.

You sick, I'm happy, all this stuff, you're happy. A little session here.

Aaron Rackley: All this stuff you're saying to me is just like very, very much on the nail of where my mind has been for the last like, Basically year, um, in terms of my career, um, [00:15:00] as I said, like floating around. So having now finally decided that like the career of like engineering manager, that that kind of, uh, is where I'm heading.

All of this stuff is just internal reflection to be able to help others in the same aspect. Right? Like I don't think personally I would be able to do this as a manager until I've gone through it personally as well. Mm-hmm. And I think. I think for me that's when, when you first said growth focus management, to me in Discord, I wasn't imagining as if, as something of like how you grow as a manager to be able to feed back into your management style.

And so it's interesting that it's like the other way round where it's like you're helping them. So I'm 100% behind this idea. I, I think it's a great idea and. I've worked at many companies where you never feel like you are a per, you never feel like you're a person. You just feel like you're [00:16:00] part of the, the process of getting stuff out the door,

Kevin Ball (KBall): right?

Yeah. There's a, there's a great, I'm gonna plant a seed on that, right? Yeah. So many companies. We'll refer to people as resources Yes. Say, oh, we need some more engineering resources on this project. And I heard a line that now I'm trying to sp spread everywhere, which is, if you call me resources, I'm gonna call you overhead.

Aaron Rackley: Ah, okay. That's, that's a very good line.

Kevin Ball (KBall): Yeah. People are not fungible. Everyone has different skills, strengths and goals in their life. And actually, I think one of the, Interesting things as we shift our mind to this growth focused management approach is, What our job then as a manager is, right? So part of our job is helping foster this growth directly in individuals.

But part of it is, you know, when I'm working as a manager, I'm constantly looking for opportunities to align work with growth. Oh, that project, I wanna pull that project [00:17:00] in because that is aligned with what this person is working on, and that's gonna be their opportunity. Oh, this project, this isn't actually working well with any of our folks.

Do you have somebody on your team where this is a good growth opportunity for them? And looking for those. And there's, there's pros and cons to this, right? So sometimes you're under pressure. You need something that is super high quality on super tight deadlines or something like that. And, uh, you need to have somebody who's already mastered all the skills required.

Mm-hmm. Just knock it out. That's, that's okay, right? That's, that's coming back to a production focus. And sometimes that's what you need. But I find that over time, If you want to amplify the abilities of your team, if you want your team to just accomplish incredible things, aligning with their growth is a far better way to do it.

Because when people are learning and growing and excited, not only are they expanding their capabilities for the future, but they're putting so much more of themselves [00:18:00] into that project than when they're just executing on something they already understand.

Aaron Rackley: Just, yeah, it, it makes you think every, everything makes you think, and that's, my brain is like that every time a sentence, my brain is shooting around and I'm immediately applying it to the day job and what I'm doing or past companies I work for.

And just trying to think if I, trying to think if I've had managers. Un unfortunately, I've not had many managers in the past that have had that kind of approach with employees, so I have, but yeah, I, I normally push back against that because I, I'm, I'm very much in that ballpark of like, people are people.

We've all got good days, we've all got bad days. We all looking for our, I guess, For me, I, I'm always looking for something that's gonna strive me towards the next thing. I'm always looking for the next challenge, the next problem to solve. And I don't think that was ever identified [00:19:00] by my peers for, for a long time.

And it's only recently with work with a few people that have definitely highlighted to me what my skillsets are and in what areas they sit well. So I think in one way, I've definitely had. Some managers recently or some peers that have definitely used this kind of growth focus management without realizing it, I guess is, is the right ways.

So, and some of them are friends and they're also doing the same thing. And I guess the principals are the same regardless to whether you are a manager or a friend or a loved one. Oh,

Kevin Ball (KBall): absolutely. Anything. Absolutely. Well, and I think. This is, it's a, it's a shift in focus, right? Mm-hmm. And I, I sometimes describe, you know, a manager's job is to find the people who are good at and excited about different types of work, and then systematically route more and more of that type of work to them.

Yeah. And I found that true outside of the people I was directly managing as well. Uh, at my last job, there [00:20:00] was a content manager who, her, her core job was dealing with content, but fundamentally she was, Incredible at setting up operational systems. Okay? Mm-hmm. We've got a bunch of stuff happening. We need to set up a system to make it happen and get things going.

And once I had identified that every time a problem that looked like that came up, I would reach out and be like, Hey, does this look interesting to you? And cuz a lot of times, and this is another interesting thing, right, we. And, and it comes to this, this focus on strengths as well. Mm-hmm. The things that we enjoy are often also the things that we are good at and still the things we are learning more and more about learning is fractal.

You can go deeper and deeper and deeper on whatever subject you want. Mm-hmm. And so I think all of our jobs, in many ways can be viewed as finding the people who love and are good at particular types of work. And figuring out how to align the work in the [00:21:00] organization so that they get

Aaron Rackley: that piece. That's super interesting because one of the questions I was gonna have next, which I'll ask now instead is, um, do you find any kind of like specific challenges or obstacles that you could find while doing this?

And immediately the one thing that was coming to my head, and this is probably just a lack of experience, is working in places where you'd not necessarily have the control at a time. To be able to, one, support people to this level or totally two, have the ability to give them the work that would suit them.

So how would, as an obstacle, what, what would you try and do there, do you think? Yeah,

Kevin Ball (KBall): absolutely. Well, and everything has trade-offs. Mm-hmm. Right? And I, I mentioned before, like sometimes you really just need to focus entirely on production and you gotta set growth to the side for a minute. There, there are elements of this that are about choice, right?

There are organizations that are not set up for this at all. Mm-hmm. Very hierarchical, top down, I'm gonna tell you what to do, you're gonna do it. Types of things. A determined manager could still [00:22:00] potentially set up a growth focused team. Mm-hmm. Where, you know, they essentially provide that sort of shield level or, you know, filter or what have you, and are still able to provide that within their team.

Mm-hmm. But honestly, I think it's likely to be. Painful on an uphill battle. And so at this point in my career, I proactively seek out organizations where the type of working that I want to do mm-hmm. Is something that is at least accepted, if not broadly welcomed. Makes sense. Um, I think that, you know, there are challenges and, and I think as an engineer or as a, as a manager, I.

Work better with people who are engaged. Mm-hmm. Driven, you know, high performing. And I struggle more with people who are underperforming, and that's not [00:23:00] unusual. Many of us fall into that bucket, but that also shows up in this growth focus, right? Sometimes the best thing you can do for somebody's growth is to find them a position outside of your organization.

Aaron Rackley: Okay. Interesting, interesting chain of thought because obviously, um, you mentioned there that sometimes just underperforming, but I guess if you are approaching your management, looking at growth focused in your words, um, it could just be that they're having a bad time outside of the work, the office.

Right. And that could be an indication of what's going on, so you It absolutely

Kevin Ball (KBall): could.

Aaron Rackley: So building up that trust is probably a great way to. Uh, get them to open up about the issue rather than it becoming a problem. Right. That,

Kevin Ball (KBall): yeah. Yeah. The other thing I do wanna highlight here is that, and I think one reason people sometimes struggle when they are very human-centric mm-hmm.

In their managers, is that it, it does, like you have always conflicting incentives. The [00:24:00] optimal delivery for production of this product may not be the optimal thing for my people to be growing. Mm-hmm. And, Constantly when you're working with someone, you're having to do trade-offs of, okay, I know you're working on this and we're gonna reserve some time for you to work on this, but most of the time right now I need you focused on delivering this thing right here, even though I know it's not the most exciting thing.

Like that type of stuff comes up all the time. And honestly, that's one of the reasons right now, I'm so happy to be outside of. The organization working as a coach. Mm-hmm. Mm-hmm. Because my incentives are completely aligned. All I care about is am I helping you get, understand what you want and get where you need to go.

Mm-hmm. And similarly, you as a, you know, in a coaching client have, don't have the concerns that you do as a report for talking to a manager. Right. A coach doesn't control your performance, review, salaries, whatever. You can be much more open. So I do wonder if. And, and this is, this is diverting a [00:25:00] little bit, but like we don't see much use of coaches in engineering.

Mm-hmm. Right now. Mm-hmm. It becomes, it's very common for executives, executive leaderships. It's very common for business owners, business founders. It's not very common in engineering. But I wonder if that's another thing that we might explore in our industry is, you know, does it make sense to separate the role of a manager who's responsible for your delivery and what you're doing?

Mm-hmm. And a coach who's responsible for helping you learn and grow.

Aaron Rackley: Definitely an interesting, um, question because I, I personally think that organiz all organizations, especially engineering, could definitely do with someone in there that is, you know, dedicated to helping you. Grow and achieve. And I know that some companies have some sort of HR arm as you would, that's like, yeah, we'll help you with training and budgets and books and we'll get you these course and that course, but that's not really helping you understand what you want to do.

Right? That's just helping you once [00:26:00] you've tried to figure that out. But that initial point of what do I want? What do I want to achieve? And. Having that personal department that's there to help you have that, I think is a great idea. Like I worked for a gang company. One of my first ever jobs was a gang company, and they had like therapists come in, they had maus, you know, they had all these type of things that I just took when I was very young.

It was like all these exciting things that you, perks and stuff. But I, as I got older, you start to realize that there's probably a good benefit to having these things there because happy people. Stay longer. Right. And a lot of They do better work. Yeah. And they do better work. And as we're learning more and more over the years is that mental health is a big part of that.

And I think coaching and therapy and all of this stuff is all aspects, I think that companies, especially large companies, need to definitely have in their repertoire, whether that's they have people or they hide them in so, That would lead me to the, the same thing of like having this [00:27:00] mindset. Do you think that having this management approach will help with employee engagement and retainment and stuff like that?

Cause we're seeing a lot, like I've, oh definitely. I and a few others have definitely seen a high turnover of people in various companies. Um, it

Kevin Ball (KBall): definitely does because I think, well, I mean, you've heard the phrase people don't leave companies. They leave managers. Yeah. And I think there's a lot of truth to that.

And one of the. The biggest things that people want from a manager is feedback and help with their growth. They want to know this person is helping them advance in their career and has their best interests in mind. And I think there are many practices you can do to improve that. But the first thing in line there is a perspective shift of I as a manager, at least part of my job is.

Understanding how this person wants to grow. Mm-hmm. And helping them achieve that. Mm-hmm.

Aaron Rackley: Let me throw Saint a bit, side words in that [00:28:00] sense. Then. So obviously if you go back, I know, 20, 30 years, right? We'd just go, you'd have people that have a career, lifers, right? They'd go 30 years in the same company until they get the gold what, or whatever they, they get in different countries.

But these days people tend to jump around a lot more. And I've seen many articles online trying to understand why this is right. And I don't think anyone really has the answer. Um, there's people saying it's because, you know, people are not happy, but what is happiness? Right? That's the important part. But I think a lot of companies are afraid to help people grow cuz they'll leave.

I'm wondering if there's an aspect of this that's like, we shouldn't be afraid of that. If people grow and get better and leave, hopefully we'll attract someone else that's on a different place. Or we need to adapt our company to be able to. Have what they need or you know, I dunno, I dunno what a question is,

Kevin Ball (KBall): but I think there are a couple of aspects of this.

Yeah. So one is I think we do need to think about how we can continually create [00:29:00] opportunities for growth mo uh, within our company, right? Mm-hmm. Somebody wants to learn and improve. How do we create opportunities? And sometimes that. Doesn't necessarily have to mean a brand new official title or role.

Mm-hmm. Someone who wants to work on their leadership skills. You can have them leave lead, for example, a cross team initiative. Mm-hmm. I had someone who wanted to eventually become a manager, and the thing we were working with is he was working with someone on a counterpart team to help I figure out how to improve relationships across our teams.

Mm-hmm. It's leadership activity, it's understanding a lot of relationships and people and all these things that go into becoming a manager. Without, we didn't have a management role available for him, but this was still helping him grow on that path. Now, I do think there is something, uh, broader here, which is to think about, and, and this isn't growth focused, but like relationship focused work.

Mm-hmm. Our relationships, our careers last a lot longer than any individual job does [00:30:00] today. Mm-hmm. And. If we have someone's best intentions in mind, that helps maintain that relationship over time. And at some point in the future, you may need what they have now to offer. So I think we as individuals, and to some extent as companies as well, need to think about these longer term relationships.

The last place that I worked, we had people who left and came back, who were laid off and then came back at a later time. Mm-hmm. People flowed in and out at different times, and I think that that is, Probably a healthier perspective. Certainly from a personal perspective, I think if you can focus on human connection and building relationships, those are relationships that'll happen.

That'll last a career. You know, I have people that I worked with over a decade ago, 2000, I guess 15 years ago now, 2007, 2008. Mm-hmm. That, I mean, there's one of them. He lives in Austin. Every time I go to Austin, I send him an email and I'm like, Hey, are you free? Let's grab dinner or coffee. Right. We still get together every time I'm in town near him, [00:31:00] 15 years later, 12 years since we last worked together.

Something. Wow. I. Those numbers aren't exactly right, but on that order. Yeah. Um, yeah, because brains and time, like that's a long time. Right. Um, and I think there's a real possibility. There's, there's other people that I worked with at that same time that, you know, I'm still in communication with. There's a real possibility that the next time there's an opening that they have that is a good fit for me, I'll go and work with them.

Mm-hmm. Right. Like, so I think if we think about it, A lot of this is moving from a transactional mindset, right. What are you doing for me now? Mm-hmm. To a relational mindset where you're, we are building a long-term relationship mm-hmm. That happens to be focused around work. Yeah. And how we work well together and how we help each other to grow.

Aaron Rackley: Yeah. No, I think that's, that's totally interesting because I definitely have the same. Thing with people that I still talk to on a regular basis from past jobs. And it is, if I [00:32:00] look back and think about it, it will be the people that have had the most like impact with, rather than just a ha you know, we went out for drinks after work or anything like, it would've been, we'd have done some kind of growth together in, in, in the role.

So that was like through a project and in the weeds together or you know, something, there's definitely. Definitely some aspect to that and a lot of those people, yeah, I'd, I'd, I'd get them to come and work for me in a heartbeat. Um, when you

Kevin Ball (KBall): see this show up sometimes where there will be a manager that will go from company to company on that, I don't know, three year or four year timeframe, and you'll see that soon after they show up at that company, a whole bunch of people that they used to work with.

Come along and start working at that company. And so these working relationships can outlast any particular job. I think the, the other thing to think about as you're doing this, and you've sort of alluded to this a little bit, is your own growth and the fact that all of this is messy. Yeah. We're dealing with humans.

Humans are not [00:33:00] predictable. Sometimes things mess up. So the, the, the last thing to remember here, and this. I think is more about human focus than growth focus particular, but it's to like give yourself and others some grace and if something doesn't work well, like, apologize and move on. All these very simple things.

But they, they're simple, but they're not easy. Mm-hmm. And, um, you know, I think we're, we're gonna have good days, we're gonna have bad days. Uh, there're gonna be people who don't want. This approach. Right? Like, and that's, that's actually another, that is a good thing to go on. Like some people do not want to worry about or think about growth at work.

They've got too much going on in their life. Mm-hmm. That's part of, that's theirs. They don't want to share it with you. They want to come in, get their job done and clock out. Yeah. And that is a very reasonable way to approach work. I don't think it would mesh well with me and my management style. Fair enough.

Right. And I will be open with people about that and be like, you know what? [00:34:00] I don't mind that. And in fact, there will be time periods where that's like if you, if you're in a time period where that's true for a short period, great. I've, I've gone through those a ton, right? Like I had a period I was caregiving for aging parents and kids.

I mean, early in the pandemic, right? Like everything was going crazy. I just wanted to clock in, get the minimum possible done to move everything forward and the clock out so that I could deal with the chaos that was in my life. That's okay, but if somebody's in that space for the long term mm-hmm. They may not be the best fit for a growth photos kiss manager.

Aaron Rackley: Yeah, no, that's interesting because I, I've had therapy over the years, um, and one of the aspects of therapy that I learned about myself is that I am. Without ever realizing it. I would always try to help. That was, that was my downfall and my strength. They're the same thing. Right. Um, my fault is that I will do it to the detriment of [00:35:00] myself, but, and the good thing is that it means I'm gonna help everyone as much as I possibly can.

And like you say, I guess one of the hardest parts of, for my personality type in that sense is that I would find it hard, as you say, to have someone to work with someone that. It has, it looks like they have a problem model, feels like they've got something going on that you are not able to help them with.

So I, yep. Yeah, I, yeah. That's something I'm trying to learn as a manager, like how I personally deal with that situation.

Kevin Ball (KBall): Well, and this is something that, you know, I would tell my reports. Usually as part of like a, a starting conversation. Yeah. You know, I, I have a starting conversation, a bunch of things we talk about, you know, how do you, how do you like to receive feedback?

Um, you know, what is your default expectation for how private things you say in a one-on-one are, like, for example, if you raise an issue, should I, you know mm-hmm. That I, my instinct would be, okay, I want to go and follow up on this, but should I check with you first? Or like, how are you, you know, what are [00:36:00] your kind of defaults?

Those sorts of things. But one of the things I'll say to folks is, Hey, look. Right. Like we are human beings. I try my best to be a good manager, but I acknowledge that my management style will not work for everyone. Mm-hmm. If you find it is not working for you, I will not be insulted if you tell me that and say, I would like a different manager.

Yeah. Right. And I think that's a hard thing for us as managers to, to be like, oh, I am not the right manager for this person. Like, am I failing? But I think, you know, Like many things, right? It's more like dating than stack ranking, right? Yes, there are skills that you can go all the way up and be better at, but there's also just a match, right?

Your personality will not be a match for everyone. And if the two of you can recognize that and talk about that openly and say, you know what? Like this is nothing against you. This is nothing against me. We are not a good fit for each other. Let us find you another manager. [00:37:00] That is a far healthier way to approach that mismatch than a sense of like failure on one side or the other.

Aaron Rackley: Um, as I said before, I could literally probably spend hours and hours, so I'm definitely gonna have to put you back on the books at some point to come back on and we'll delve into more of this or other aspects I'm sure. Just by talking to you, I can tell you're a fountain of knowledge of stuff that I just wanna pick out your brain.

Um, but I'm being conscious of the time and so I think what we'll do is we'll wrap it up with the one final thing that I ask all my guests is if you could give, recommend just one book to anyone. And it doesn't have to be technical, it doesn't have to be management. It's just one book, like Desert Island, one book.

What book would you recommend? Because I will be adding it to the Amazon list to read, so,

Kevin Ball (KBall): oh my goodness. No pressure. Well, so here's the thing. I'm a bit [00:38:00] of a book nerd. I read a lot of books, so I'm gonna ask you, okay. What types of things are you interested in? Because I have, if I were to recommend one book to you as a manager Yeah.

Um, that would be different than I were to recommend you to one book as somebody who's looking for something fun to read and likes fiction. Yeah. Or science fiction. Mm-hmm. Would be different than, you know, one book to read based on like if you're someone who's commonly stressed out or something like that.

Yeah. Okay. Like, I've had books change My Life so many times.

Aaron Rackley: I'm a book too, hence the question. Um, so Okay. We'll do two books then. Okay. The first book is, I've just listened to his podcast and I. Kind of wanna know more about growth, focus management. I, I'm not sick. I know that you said it's a, a term that you've probably came up with yourself.

So where would I go reading it? What would I read next? Okay.

Kevin Ball (KBall): The most human-centric book on management that I have ever read mm-hmm. Is a recent book. Um, and it's engineering Management for the Rest of Us by Sarah Dresner. It's [00:39:00] phenomenal. Ah, good old Sarah. Yeah, she's, I mean, she's great. Um, but, uh, and I, I have an interview with her coming up on my YouTube channel soon.

Small plug. Um, she's phenomenal. But, um, the, this book, it was the first book that I've read mm-hmm. That is explicitly about management and managing engineers, but the human aspect kind of was a through line through the entire book. Yeah. Um, so that is, that is definitely my top. Recommendation right now from a management perspective and from this perspective of how do I, how do I focus on humans and helping them learn and grow and become better humans?

Mm-hmm.

Aaron Rackley: Okay. No, I'm putting it down. I've. Heard that w that book way too many times recently for it not to be on the list. Um, because I, I, I think Sarah's been on a few podcasts talking about it, uh, recently, so I've definitely heard that. [00:40:00] Heard of the book. Okay. Second book. Um, I'm gonna pick one genre. Um, Let's go for, cause we still talk about human growth.

How about a, a self-reflection book?

Kevin Ball (KBall): So, one of the most, I think, revelationary books for me, that, that changed my approach to a number of things, um, is a book called Full Catastrophe, living by John Kabat Zen. Part of why it was revolutionary. So this is a book, uh, that looks at. Uh, something called mindfulness-based stress reduction.

Mm-hmm. Um, and it was the first book that to me took a, as a, you know, technically minded, studied science, very skeptical type of person. Mm-hmm. Took a very rigorous science-based look at what mindfulness meditation, which feels very like fuzzy and eastern [00:41:00] actually. Can do for your health and wellness.

Interesting. Um, mindfulness is an incredibly valuable technique. Um, it shows up in all sorts of different things now. There's people, like, I was just looking at this thing called positive intelligence, where this guy tried to wrap up a bunch of stuff and he's basically pulling from a few traditions. But one of the big ones is mindfulness.

Mm-hmm. Um, it's a very powerful way to essentially practice directing your mind. And kind of doing deliberate practice on how do I control this thing inside of my head. Um, but this book looked at. You know, both lays out what you can do, like what a practice looks like, but also lays out the science and studies that they did, you know, in hospitals showing dramatic health impacts.

Mm-hmm. Um, and so that was, that was revolutionary for

Aaron Rackley: me. Yeah. Well that, there you go. Two, two books that have to be on the list. And I will be reading them and I'll definitely probably message you on Discord and be like, yep. That, that one [00:42:00] was great. Yep. Let's, let's talk more. Um, okay, so now the fun stuff.

Where can everyone find you and what do you do online? Because I, some people have blogs, some people have YouTube, some people podcast. So Yeah, so nuts

Kevin Ball (KBall): share everything, all all the different things. Yeah. So what am I publishing these days? So, I guess the hub to go to is K Ball dot llc. Um, I self branded my, my new company.

Nice. And I published some blog stuff there. Um, I. Am a podcaster myself, so I regularly podcast on the technical podcast js party. Um, so you can go to change log.com/js party. Um, and I talk about all things JavaScript and the web. Uh, it's a fun time. Yep. Great podcast. I am also working towards a new podcast focused on human skills, uh, okay.

Sort of all the non-technical things that go into success in the tech industry. Um, that podcast itself is not being published yet. However, I'm taking the interviews [00:43:00] that are intend to make that up and publishing them on YouTube and a summary version on, uh, ck. So there you can go to human skills.co to find the, the ck um, the YouTube is youtube.com/human Skills or at Human Skills.

Um, and I should look at which one That is youtube.com/. At Human Skills Co. Um, is what it is. Okay. Um, and I think those are the big ones. I, I. Do a little bit on Twitter these days, but not too much. I feel like Twitter has become a dumpster fire. Um, I do publish regularly on LinkedIn, so LinkedIn is another one.

Yeah. Uh, but you should be able to find all that from K Ball dot llc. Brilliant.

Aaron Rackley: Well, as I said, I kept saying throughout this whole thing, I definitely will need to have you back. I've enjoyed this conversation immensely and I am, without even knowing it, a big fan of growth focus management. So I'll definitely [00:44:00] be.

And I feel like I need to blog about it. That's, that's how, that's how it's, yeah. Yeah. So yeah, I will definitely have that. And thank you for coming

Kevin Ball (KBall): on. Yeah, yeah. No, thank you for having me. And, and take it and run. Right. The best thing to me about all of this stuff, about software development, about, uh, podcasting, about all of these things is when we inspire new possibilities and new realizations of like, what, what can we actually do?

In this world, and so like if that has sparked something for you, take it and run,

Aaron Rackley: Billy. Well, thanks again.

Today we are having a discussion with Marisa Hoenig from Thoughtworks about their Technology Radar, An opinionated guide to technology frontiers.

Host: Aaron Rackley

• https://aaronsserver.co.uk
• twitter.com/aaron_rackley

Guest: Marisa Hoenig

• https://twitter.com/marisahoenig
• https://www.linkedin.com/in/marisahoenig/

Tech Radar:

• https://www.thoughtworks.com/radar
• Tech Radar BYOR
• Tech Radar BYOR Github Repo

Book Recommendations:

• Educated: A Memoir by Tara Westover
• Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones by James Clear

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hi everyone, and welcome to this episode of Tech Leadership Podcast, the podcast where through conversations we unraveled the intricacies of leadership in the tech industry and provide insights on how to become a top performing leader. Today we're having a discussion with Marissa Hoig from Fort Works, about their technology radar, and opinionated guide to technology frontiers.

If you would like to come on this podcast and have a conversation with me about subject you're passionate about, please email me@contactleadershipdecoded.com. And with that, let's get straight into the conversation. Okay. Marissa, thank you for joining me and again, thank you cuz we just started recording this a 10 minutes ago and realized it wasn't recording.

Let's start off right at the beginning again. Could you give us an overview of your career, how you got to where you are at Fort Works, how you got to be part of the tech radar? And we'll see how that goes and let's hope it record system.

Marisa Hoenig: Yes, I see the recording and all good. You know, this is what happens on podcasts.

We just, we just go with the flow. So [00:01:00] yes. Hi everyone. Uh, my name is Marissa Honig. I am currently the technical assistant to the C T O at ThoughtWorks, which is a global software consultancy. So we work with tons of different companies around the world and. One thing that we produce, it's our number one asset, and it's read by over a hundred thousand, oh my gosh, over a hundred thousand people.

It's called the, such a large number. I know. It's called the Technology Radar. And I, I'm lucky enough in my role to be the product owner for the tech radar and get to, you know, see the whole process, manage that whole process, and I'm excited to tell you about that today. A little more on my background. I started as a software developer after, you know, going to school for computer science.

So I've been at ThoughtWorks for four years now. And, uh, I also host my own podcast in my free time, although we won't get into that cause I haven't posted anything recently. So I don't look it up. And I'm based [00:02:00] outta Denver, Colorado, so I think that's nice to maybe know where, where I live. Um, but yeah, that's who I am.

Aaron Rackley: Thank you, and I think we should then definitely address the first question, which is the most important question, which is, what is the technology radar?

Marisa Hoenig: What is it the most important question? What is it? What is this?

Aaron Rackley: What is

Marisa Hoenig: this myth? What is this asset?

Aaron Rackley: I think it's worth to say that I came across the technology radar through the Fort Works podcast.

Um, I can't remember wh how long that episode was. I think maybe last month. I can't remember. Um, and I immediately went away from the podcast, looked out, downloaded it, and I was just in awe on how much information is in this one P D F. So I immediately had to get someone and I'm so happy that you replied on LinkedIn to come on and explain it.

So what is the technology radar for the listeners?

Marisa Hoenig: [00:03:00] Yes. I mean, I'm so glad you found that through the podcast because I was one of the people who was like, yes, we should really do a podcast episode about what it means to build the radar. So if people are listening and you wanna learn more about how we actually build it, definitely go check that out on the ThoughtWorks Technology podcast.

But yeah, it's a journey. Uh, so. The tech radar is about a seven week process, and as the product owner, I kind of get to manage that whole thing so, What happens is we have over 11,500 employees at ThoughtWorks around the globe, and we do this like call for blips, which blips our individual technologies that people are proposing for the radar.

So basically everyone submits these technologies that they're using on their projects, and we have these debates about what should make it on, and I'm gonna kind of skip the process right now to get to the overall asset. Yeah. But the overall thing is, you know, it looks like. You know, like a radar, like [00:04:00] it, it's meant to be almost a pun of like a shipped, like if you're, um, what's it like a, like a sailor or something?

Not a sailor, but, um, yeah, like a sonar

Aaron Rackley: radar type

Marisa Hoenig: thing. Yeah, a sonar radar. Thank you. If you have a sonar radar, you see like little blips on the screen and that's what the technologies are and they, they land in four different rings, so there's adopt, trial, assess, and hold. And these are, these are our opinions on the different technologies and what you should do on your projects, whether you should, you know, adopt that technology or that technique, or maybe you should really proceed with caution and hold on that one.

And so, It's a, it's an opinionated guide to what you should do on your technology projects. And so we usually publish about a hundred blips on a radar and we publish the overall asset twice a year. Uh, so you can look forward to it in the spring and in the fall every year. And I know you mentioned that you read the pdf, it's [00:05:00] also an interactive.

Radar online so you can like click through and see different things and you can also search for stuff. Uh, but we published both the PDF and the interactive guide and the PDF itself. I know you said it's a lot of info. It is 47 pages, at least the English version and. Uh, as the product owner, I, I was thinking about this.

I get to read through every blip about five times or so. Mm-hmm. So by the time we publish the radar, I like to say that I have memorized about 70% of the blips, at least the names. I don't know about the write-ups, but you could probably like quiz me on some of the blips. I'm like, oh yeah, that's definitely, that's in this tr uh, this ring or wherever.

Um, And so it's a huge asset and it's really this global collaboration of all our consultants to make it and to make it useful for folks like you. No, that,

Aaron Rackley: that's awesome. Yeah. Um, I, I won't quiz you. Just Thank you. Put you on the spot. Um, do you know at [00:06:00] what point you decided that this would be something that would be greater for outside people to see?

Because I know there's a lot of companies out there that are very. I, I dunno the right word, like cagey about what they're using or how they're using technology. So I'm very surprised that you guys go into this much detail and let this much detail out there. So how, do you know where that, where, when that decision kind of happened or?

Yeah,

Marisa Hoenig: so the tech radar has been around since 2010, and so that's about 13 years. I have not been around since then, but. From what I understand, what originally happened is the board that creates the radar, the technology advisory board, they were meant as an advisory group to our C T O, Rebecca Parsons, who I get to work closely with in my role.

And they would meet regularly to like advise on different topics, talk about what's going on around the world, and interesting technologies would pop up and so they'd be like, oh yeah, are you using. I don't know, react, are you [00:07:00] using data mesh, whatever. Obviously not those exact things, cuz 2010, I don't even know if what was around back then.

Um, but they started talking about these things and they realized, hey, like. Maybe we should, you know, make, make some sort of thing to visualize this. Mm-hmm. And I don't know whose idea the radar itself was, but the radar became the thing where they put the interesting technologies. And it was originally meant as you thought, um, as.

As an internal knowledge sharing tool. Mm-hmm. So originally we were like, oh yeah, like we'll just use this within ThoughtWorks. People can contribute to it. We can kind of share across the globe. So, you know, people can learn from other projects and as far as I'm aware, during the first radar we. Made it external.

We, we never had it. Only internal. Yeah. So we saw so much value in the radar that we said, Hey, actually, I think someone in marketing was like, Hey, this is really good. We should, we should [00:08:00] publish this. And so we did. We published it. And I actually recently looked back at the first radar. Um, you can, okay, if you go to our website, you can go to the archive and you can see the first radar.

You know, it only had 25 blips. It had the same overall structure, but the design is really old and you know, it has things on there like, iPhone and Android and Oh wow, okay. Something like Java, end of life. Like we thought Java was done in 2010, so there's like all these different things. Some people would still argue.

Yeah. Yep. Maybe it is. I don't know. Um, but yeah, you can go back and see, you know, all these snapshots and time to really track, you know. What happened with the tech industry since 2010. And so it's really cool to just look at it from that perspective. Um, if you're ever like, huh, I wonder, you know, in 2014 what was going on in tech, you can look at the radar and be like, oh, like that's what people were using on projects.

That's how we felt. Um, people should, you know, choose their tech stack, stuff [00:09:00] like that.

Aaron Rackley: Uh, have you, just thinking about that for a moment, have you ever took a moment to look back to see if something you were thinking about panned out correctly or not based on the observations? Yeah,

Marisa Hoenig: the, the tech advisory board definitely has, I think when we had our.

What's it called? Let's see, we're on 28, I think when we had our 25th radar, or like 10 year anniversary. It was one of those, they did a whole like series of, you know, these were our biggest misses and these were the best, uh, predictions that we made, and like all of that stuff. So someone did take a look and gather that information, which I think they found really insightful to see.

Aaron Rackley: Okay, so talking about. The radar in general. Obviously there are quite a few reports that happen every year about the state of technology, you know, that what technology developers are using. You know, [00:10:00] I think GitHub does one. I know that Stack Overflow does one. What do you think makes Fort work stand out?

Cause obviously over a hundred thousand people is a big, big achievement, especially fort. Essentially a list of OB objects. I don't wanna say it's horribly, but it's a list of technology that you guys have thought personally is great for you, for you. So why do you think everyone else is so in depth?

What's the right word in love with it? Because I, I'm in love with it and I've seen so many people on Twitter talking about it, who love it. So what do, what, where do you think that comes from?

Marisa Hoenig: Yeah, I mean, first of all, it's just so wonderful when I see people excited about the tech radar. Like that's one of my favorite parts of making it when I, you know, go on Twitter or go on LinkedIn afterwards and I'll like, I'll scour the web a bit to see what people are saying.

And it's always wonderful to see people saying good things [00:11:00] about it. Um, What distinguishes it? That's a really good question. I think part of it is because we've been doing it for so long, I'm not super familiar with a lot of the other reports, but you know, we're in our 28th volume right now, so 28 times we've gotten together and created such an incredible asset that, you know, Tells our story at least of what's going on in the industry.

And then the other thing is, you know, I mentioned how ThoughtWorks is a global consultancy. So we have people in 18 different countries, we have over 11,000 employees and. This radar is based on everyone's experiences. So we're working with, you know, hundreds of clients in various industries, whether it's, you know, automotive or retail or entertainment or the government.

Like we have so many different projects that when we come together to create the radar, we're getting technologies from. You [00:12:00] know, all these different industries, all these different companies, and creating an opinion on them and talking about our experiences using those technologies, and so, We're like, it's an opinionated guide because we truly talk about how we have experienced it, and there's very little opportunity for people outside of ThoughtWorks to really influence the radar.

If we put your tool, you know, in assess or hold or adopt, that comes because we truly think that's where it belongs. And we can't really be swayed to, you know, change that, or, you know, you can't pay to put something on the radar. Like we don't allow that. And so it's truly based on practitioner's experiences and we're kind of, you know, not afraid to say what we think and, you know, The goal is to really help people on their projects and to rev revolutionize the IT industry.

That's what we truly believe the radar is meant for to, you [00:13:00] know, impact all these projects, all this software being produced. And so if we say, you know, you should. I don't know, adopt Java. Funny cuz we talked about Java end of life before, but you should adopt Java, let's say. Um, then, you know, maybe there's people who read the radar and go, oh, you know, like ThoughtWorks recommended Java.

Like, let's do that on our projects and we would love that. You know, we'd love to make an influence in that way. And I, I wanna think that people respect that and respect that we truly say what we're thinking and comes from our experiences using these technologies.

Aaron Rackley: I think having that. Back catalog of just proven kind of experience is perfect for this kind of radar in general.

Um, because I've, I've worked in many companies that over the years have tried to make their own internal kind of like approaches at seeing what's out there and how it's working and stuff like that. But obviously I think one aspect that means it's never worked [00:14:00] for. Companies I've done in the past is because it's been too small and narrow in the amount of people that have input into it and the experience in those areas.

Whereas having a look at your radar, you can clearly see the amount of effort that has gone into that. And the, as you said, there's like four different phases that these blips have to go through in order to be, you know, deemed recommendable or, I forget the phrase that you used there, but, So how does a technology progress through the radar and, and.

Through the

Marisa Hoenig: system? Do you mean like when we're producing a single radar volume? Like how does it go from being proposed to them being published? Yeah. Yeah.

Aaron Rackley: I think like how does a blip become a blip, I guess is the Yeah,

Marisa Hoenig: yeah. The storyline, the, the birth of a blip. Um, I said I read them about four times, but they actually go through about eight different reviews, so, Okay, so the first step, and we'll, I'll try to keep this as short as possible, but the first [00:15:00] step is, you know, I put out a call for BLIP nominations, basically, and so everyone in ThoughtWorks gets that email and it says, Hey, submit your blip.

Like, tell us your experience about using a technology. What ring do you think it should go to? Go in? Which quadrant should it be in? Because we do have some categories like tools, techniques, languages, and frameworks and platforms. And they submit that to their basically regional, uh, what's it called? Like, uh, da da da, sorry.

Uh, regional. Like regional liaison between, you know, the entire region that they live in. So you know, like North America or different countries in Europe, or you know, China, India, et cetera. And the technology advisory board that creates the radar. So each of those people on the board collect all these blips and.

They [00:16:00] actually do an initial, you know, going through the blips and deciding which ones they should bring to the meeting. Because after, you know, a few radars of experience, a lot of the people on the board can understand looking at a proposal, whether it's gonna make it or not, or they'll remember previous conversations we had where we were like, no, like, This should never be on the radar, for example, and they just won't bring that to the meeting.

So it goes through this whole process. We usually get around 300 nominations for technologies. Uh, it really depends on, you know, how many people submit things and then I. The people from the board bring it to a face-to-face meeting, which I say face-to-face, but that's very loose now with Covid. Um, because during the Covid time we did remote meetings and then we did one face-to-face recently, another remote one.

So it, it really depends. But we get together for a whole week of discussions and so, It's usually about, well, it's usually five days, [00:17:00] but sometimes the last day we'll do a few less hours, but the other four days will be about eight hours of discussing technology, which I think for a lot of technologists, that sounds like the best thing ever to just get to sit down and debate different technologies and how you should use them.

And it is such a, It, I'm like humbled to be in that room, even though, you know, I'm taking notes. That's my main job during that session. But every now and then I'm like, Hey, I've used that technology, like I'm gonna participate. So I'll, I'll discuss, uh, for that technology. And we go through and our C T O, Rebecca Parsons, she will facilitate the whole thing, which is just, it's, it's a magical experience.

Like I don't think I'll ever experience someone facilitating so well, and. We go through and everyone discusses different technologies and then ultimately we vote on whether it's gonna make it on the radar or not. And you know, there's a lot of other things that go on with, you know, intricacies of bringing some [00:18:00] blips back or.

You know, getting rid of some other ones. But by the end of that week, we end up with around a hundred blips. And then what I like to say is after that, it's the real fun begins because that's when I become really busy for six weeks and I manage that writing process. So once we have those final a hundred or so blips, they go into a Trello board and basically anyone in that.

Tech advisory board, they can go in and they pull in a blip and they'll write it and they'll do the initial writeup. So that's coming from the BLIP proposal and then from their experience, from the notes from the meeting. All of that good stuff. And then, you know, I review it and then we also send it out to ThoughtWorks again to review and provide feedback.

So it's like not only are we allowing our, you know, 11,000 plus employees to propose blips, but they also review them and comment on them and make [00:19:00] suggestions. And every now and then, we'll even get someone who's like, I completely disagree. This should not be on the radar. Here's why. Um, And sometimes we'll get rid of it at that point, like, we'll, we'll get rid of another blip or two.

I think this time around we had about four that we got rid of during the process. And so it's like this constant feedback loop happening between the tech advisory board, me and all of ThoughtWorks. And so it goes through, That review and then the person reviews again, and then it goes through copy editing, and then like I review, they review, and then eventually we're like, okay, cool.

It's ready to be published. And then we also translate the radar into Spanish, Portuguese, and Chinese. And so I also make sure that whole process gets managed and we get volunteers across the company to be a part of that and to translate it into their language. So, Yeah, it's this whole thing going on.

And then at the end, you know, we have a designer who makes [00:20:00] the PDF and then I also work with our website team to get the website version published, and then we have like a big kickoff call and we say it's out there and everyone gets to read it.

Aaron Rackley: I hope you also have a big party at the end because that sounds like so much work and a lot of work.

Um, yeah, I think I, yeah, for me it's like, it, it's really great because obviously one of the hardest things I find generally is trying to keep up with technology. Especially it's changing every year and it's, and I think it's getting rapidly more. Worse as years go on in terms of amount of frameworks that appear, the amount of, you know, other products that are ching up, like AI, as you said, is a thing that's appearing, but then there's like 40 new products a week that are to do with ai.

So having things like this in place is, I think very important. And this is why I wanted to talk about in general for [00:21:00] the podcast, is because I think as a tech technology leadership, It's hard to keep track of this data. So having this tour available to you is, I think vital. So I guess the question that that leads to is like, you've got this radar now and you, you've gone through this very immense seven week period of getting it prepared and out to the people.

So how do Fort Works, and I guess by extension everyone else, how do you think that the best way to use this information that you are. You're providing?

Marisa Hoenig: Yeah. I think, you know, the challenge you mentioned with staying up to date on technology, the radar is the perfect solution for that. I know I'm biased because I work on it, but it truly is the perfect solution for that.

Just because, you know, we will literally, you know, wrap it up for you like a present twice a year and you can read it and see what's going on in the industry. Um, so like, [00:22:00] That's one of the ways, just keeping up to date with it. Reading it. We do have, you know, a newsletter that we'll send out when it's published and you can subscribe to that if you wanna know when it's published.

But I think, you know, I've had experience as a tech lead before and when the radar comes out, that's a really good way to. Uh, take an analysis of what your tech stack looks like. So you know, you're on a project, maybe you're using 10 different technologies. If you read the radar and you're like, oh, actually, like they said you should put this thing on hold, or they really recommend this alternative, maybe we should consider that, you know, if we're having issues with that technology on our project.

So it's a good way to just like, Learn about that. And the other thing is with techniques, ho honestly, techniques is my favorite quadrant because I feel like it's something that almost anyone can learn something from, like, you know, tools, platforms, languages, and frameworks. Often those are very specific [00:23:00] to, you know, a data project or a front end project, et cetera.

They're great. But I love techniques because I think. There are so many things to learn just from that quadrant about how you are building software and how, you know, you're talking to stakeholders or, um, I don't know, you're managing your people on your team and so like if you take nothing else away from the radar, it's say, look at the techniques quadrant.

The other thing is looking at blips in adopt and hold. Those are usually, you know, our strongest opinions about something, whether we're like, Hey, like. You probably shouldn't use this, or actually you really should use this. You should really consider this if you have the use case for it. And the other thing, like if you're doing a quick skim, is to look at the themes on the radar.

So, uh, I believe that's in the beginning part of the pdf, and then it's further down the page on the main homepage. And these are. Uh, from the [00:24:00] conversation that week. Long conversation, if things keep popping up, like for example, one of our themes this time is called accessible accessibility because we had so many blips submitted about accessibility, so everyone in our board was like, Huh.

There must be, you know, something new going on in accessibility land. Like there's all these new tools happening. It's really, you know, it's more accessible or it's easier to implement accessibility these days. And so we put out a theme based on getting, you know, five to 10 blips of a similar topic. And so that's what you'll see across all the themes.

And so that's often a really good thing to pay attention to, just to influence like, You know, how, how you're building that software or running your project. Um, and then I also think, you know, using the radar to determine your tech stack. When I was a tech lead, I did a greenfield project, and when we were considering our tech stack, we'd go, oh, you [00:25:00] know, what did the radar say about it?

Like, Did we have good experience with this, did we not? And that was really helpful when you're starting from scratch, especially because you might not know, you know, what technology should be we be using, but the tech radar kind of lays it out really well for you.

Aaron Rackley: Yeah. So like as, I think as you said there, like you, there was some key trends that pop up, um, different times, um, in different areas.

So is there like a key trend that you could, I, obviously I've read 28, but is there a key trend that you could, you could see in that, in this, in this one, after reading all 300 proposals?

Marisa Hoenig: Oh, that's, that's a good question. I think. The main thing I noticed, and this might just be because you know, there's a lot of hype around it recently, is around, you know, generative ai.

We did get a lot of proposals around generative ai. You know, whether it's just chatty b t or GitHub co-pilot, but there's all these [00:26:00] other open source tools that we often get proposed for the radar, and most of these. You know, no one has production experience or they're working on it on a project or a side project or whatever.

Mm-hmm. But we see these things pop up because of all the hype around it. And you know, we try not to give into the hype at ThoughtWorks, but we do, you know, wanna speak on it if we have things to share. So there was actually a really good article that came out of the. Um, the like face-to-face discussion for the radar about l l m prompting.

So large language models, how do you, you know, prompt them to create good code and like, what's that process you should go about? Um, this was published on Martin fowler.com. Martin Fowler is our chief scientist and he's on the tech radar. He was also part of the Agile manifesto, which like, by the way, um, I don't know, Martin might listen to this, but.

It's so bizarre to, you know, learn about the Agile manifesto in [00:27:00] college, you know, only like five years ago and then to sit at dinner with Martin Fowler on my right and like to realize that in the moment. But anyway, uh, there's a really good article, uh, maybe you can link it in the show notes. I can send you the link, but yeah, hundred percent.

It's. Really helpful. Cool. It's really helpful for just understanding how to do that when we're so early in this generative AI age of technology. So it's like things like that, um, have come out of the radar based on a lot of people submitting

Aaron Rackley: blips on that. Yeah, no, that, that's super interesting. And yeah, I think I'd be in awe too if I was sitting at that dinner table after learning it too.

Um, now obviously I, I listened to the podcast that you guys. Um, released, which goes into a lot more in depth on the process and all that kind of stuff. So I definitely recommend everyone to go and read it. And I know that on the website it's. But it's very intuitive of all the information that's available.

And as you said, it's very [00:28:00] interactive. But also the thing that I liked on it is that you give the framework of how to build your own radar. Would you wanna talk about that for a moment?

Marisa Hoenig: Yeah, absolutely. So I. The Build Your Own Radar tool is actually an open source tool that we have. And so you can find it on GitHub, and we also have a hosted site where you can basically upload your own CSV file or Google Sheets file, whatever, and you can generate your own radar.

And so it's built in the same way that our radar is built, you know, with the same quadrants, the same rings, and. I think this tool is really impactful because if you're on a project and you're like, Hey, like I really enjoy the radar, but um, you know, how do I really relate it to my own project? And so I actually highly recommend, you know, tech leads or anyone really leading some sort of team.

Maybe engineering managers consider using this tool because it's helpful just to get an idea of. [00:29:00] How does the team feel about the different technologies that you're using? What are the techniques that we're doing that maybe we don't realize we're doing, but like writing it down will make us go, oh, okay.

Like that's how we're approaching this software. That's how we do C I C D, or whatever it is. And I think that's a really helpful source of truth, almost like an adr, you know, an architecture decision record to be like. This is what people who are onboarding can look at. And this is what we can revisit from time to do, from time to time to really be, um, Intentional about what technology we use and whether we change in, how, you know, how our tech debt is looking, all things like that.

And so if you use our tool, you can kind of integrate it into your own system, whether you're using like, you know, backstage as, um, a portal or Confluence or something. And you can just use that on your team to [00:30:00] keep everyone informed. So I highly recommend checking it out. It's at radar.thoughtworks.com and you can just use it for your own project.

Aaron Rackley: Yeah, no, I will definitely 100% be getting this set up at my company, even just internally through like front end first of all, and then try and expand it out. Cuz I think it's, as you say, a great way for us to all just get on the same path of understanding. But before, um, I say goodbye, um, because I feel like I I will go on for hours.

Um, is, I'm gonna be asking everyone, um, the same question at the end of the podcast, which is if you could recommend one book to anyone, and the book doesn't have to be tech basic, you know, it's like a desert island kind of book. Which one book would you recommend? Oh

Marisa Hoenig: man, I, oh, it's a good question. I'm pulling up my like, good reads right now to be like, okay, [00:31:00] what do I, um, what are some of my favorite books?

Um,

okay. I mean, so. I'm gonna, I'm gonna mention two, but one, I'm only just gonna mention briefly, of course, atomic Habits is one of the, like, probably one of my favorite books ever and I highly recommend that, but I feel like that's a very typical response. So I'm gonna give you a different book. Um, I highly recommend.

Uh, educated by Tara Westover, it's, um, a autobiography and goes through her life with, um, kind of an unconventional childhood, like a very sheltered childhood and basically learning. Mm-hmm. Um, as she got educated through schooling, uh, learning kind of like what the world is like and learning about her past and her family and stuff.

It's a really good book. I think I wanna read it again, but. That, that would be a book I think everyone should read.

Aaron Rackley: Definitely. Okay. I would definitely add that one to my list because I'm basically adding [00:32:00] every book that, um, people recommend onto my Amazon list to, to read through. Um, and I recommend everyone else do the same thing.

Amazing. Expand your horizons as they say. I always end up finding that I'll read a book that I'd never have thought of reading before, or a genre that I've never delved into, so before. I say goodbye, and obviously it's been amazing having you here and I know I kind of abruptly end ending it and it, it feels horrible to stop because I'm just so enjoying this conversation around the tech radar and I'm definitely gonna have to carry this conversation on via email or something.

Um, but, um, if anyone else out there is interested in the radar and or, you know, wants to look at the radar where. Where can they find you and the radar

Marisa Hoenig: online? Yeah, I mean, this has been wonderful and if you ever wanna do a part two, I'm very happy to come back on the podcast or you know, we can chat via email and everything.

But yeah, if people wanna reach out to me, you can find me, you [00:33:00] know, on LinkedIn, on Twitter, um, I think I have, I don't know, GitHub, you can't really message on GitHub, but you can find me all of my social medias at Marissa Honig, that's M A R i S A H O E N I G. And if you're interested in more about the radar, I recommend going to thoughtworks.com/radar.

That's where you'll find, you know, the PDF and the interactive website that we talked about. And we also have, you know, thought work socials at. ThoughtWorks. Um, and yeah, you can also, you know, follow the company on LinkedIn or anywhere else. You can probably just Google us and you'll find us. But yeah, definitely follow up.

If you have any questions about the radar or you know, wanna talk to me, I'm very happy to chat with people.

Aaron Rackley: Awesome. Yeah, we'll definitely get you for a part two at some point, I imagine. I hope you enjoyed this conversation, and please do remember to subscribe to this podcast on your favorite player and stay tuned for upcoming episodes.

If you'd like [00:34:00] to come on and have a conversation with me about subjects you are passionate about, please send an email to me at contact tech leadership coded.com and I'll see you in the next episode. Bye for now.[00:35:00] [00:36:00] [00:37:00] [00:38:00] [00:39:00]

Host: Aaron Rackley https://aaronsserver.co.uk twitter.com/aaron_rackley
Guest: Erin Fox https://twitter.com/erinfoox
Book Recommendations:
Quiet: The Power of Introverts in a World That Can't Stop Talking by Susan Cain
Breath: The New Science of a Lost Art by James Nester

Show Transcript

These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.

Aaron Rackley: [00:00:00] Hi everyone, and welcome to the first episode of Tech Leadership Podcast, the podcast where through conversations we unraveled the intricacies of leadership in the tech industry and provide insights on how to become a top performing leader. Today we are having a discussion with Erin Fox about her talk, how to get a mentor without telling them.

If you like this conversation, please do remember to subscribe to this podcast on your favorite player and stay tuned for upcoming episodes and if you would like to come and have a conversation with me back. A subject you are passionate about, please email me at contact tech leadership decoded.com. And with that, let's go straight into the conversation.

Okay. Thank you Erin for joining me today. How are you doing first of all?

Erin Fox: I'm doing great. Happy to be here. Talk about a fun topic. Um, really excited.

Aaron Rackley: Yeah. Yeah. So obviously we are here to talk about, be getting a mentor without them knowing about it. What was the official title you had on the [00:01:00] talk that I saw you?

Cause I've seen you twice. I first saw you live in person at React Advance London. Mm-hmm. In 2022, and then I saw you on the online Tech Leader conference at 23 doing the same talk. So what did you officially call your title in the talk?

Erin Fox: Yeah, so officially it was how to get a Mentor without telling them, but then I kind of added and secretly get a mentee, so, It kind of goes on both ends of the spectrum.

If, if you're looking for a mentor or if you're, um, a more senior engineer and you're looking for a mentee. But, um, thanks for coming to all my talks. You must be really, really into the subject. I love that.

Aaron Rackley: Yeah, I think the first one was in that tiny side room off the main event. So that was, that was very mess.

Oh, it wasn't that

Erin Fox: tiny. I was still on the

Aaron Rackley: stage. Right. It wasn't that tall. What was that? Yeah, well it was, it just scared me being on that stage and that's for sure. Um, [00:02:00] so yeah, I like to start off the podcast just by basically introducing yourself. Just letting everyone know who you are and kind of why the subject matter we're gonna be talking about is important to you and why you've done talks on it essentially.

Yes. Go from there. Yeah,

Erin Fox: absolutely. So, um, to make, I guess, my career a. Journey quick. Um, I have a master's in communications in gender studies, and I had a terrible job and I hated doing it. I was doing paid social media, decided to quit. I did a bootcamp for three months in New York City. It was the hardest thing I ever did.

Cried at the bathroom, had no idea what I was doing. Uh, but I ended up being the absolute best thing for my life and career wise, I ended up working at, um, major League Soccer, um, working on React Native, and now I'm a. Full stack software engineer at Convert Kit, where I, um, help creators earn a living online.

And I like work now and Web React, um, in Rails. Not my favorite, but, [00:03:00] um, but throughout my journey and everything, I've always been very good at finding mentors and finding people to help me. I think it's because when I joined MLS as a junior engineer, I just had. A great environment and a great mentor there to teach me and guide me and, um, really show me what a good mentor was.

And so I've always wanted to reflect that back on who I work with, how I can mentor others, how I can help mentors be good mentees, be good. Um, I've always been like passion of mine recently. I didn't know I was doing it this full time until my manager brought it up. But, um, yeah, I'm really, I'm really into helping people and, and feeling good about your career and, yeah.

Aaron Rackley: Okay. Yeah, no, it's really interesting. In your experience, I know lots of different places have different approaches to mentored, mentor mentees, like some companies I've worked for in the past. They just basically give you like a buddy, but that's not necessarily a mentor. So how would you describe what a mentor is?

Yeah. I

Erin Fox: think [00:04:00] for me specifically, like an engineer, mentorship is, mm-hmm. You really teach what you know like to a mentee and you teach them how to teach themselves. And in, in most mentorship relationships, there's usually a mentor and a mentee. And, um, I think throughout these relationships it can flip back and forth and like a constant learning from each other.

Um, and there's like good characteristics of a good mentee and, uh, a good mentor and I think. Overall, um, mentorship is just connecting with someone of a different skill level that can help you and teach you and guide you, um, to what you wanna know.

Aaron Rackley: And if I am someone who's looking for a mentor, what kind of fears do you think people generally have of approaching asking for mentorship?

Erin Fox: Oh, totally. Yeah. That it, it is very scary. I think I like to give [00:05:00] this kind of metaphor of. When you're meeting someone for the first time, mm-hmm. You. If someone comes up to you straight up, like really in your face, hard eye contact, it's very intimidating. So if someone comes up or DMZ says, I want you to be my mentor, it's kind of like a lot to deal with.

You're like, oh my gosh, I don't know this person. I don't know what they need. I don't know if I'm smart enough to help them. So I think the traditional tactic of going up to someone or DM someone will be, my mentor is kind of old school now, and I think the way to find. A mentor, if you're looking for one, is find someone that has similar, that has achieved goals that you have and ask them a question that can, that you need and need help with.

So say, I really wanna get back into React native. I haven't used it in a while and I just, I don't know much about it. I've done some research but. I want some help. [00:06:00] Um, have a following on Twitter. Maybe I'll mention someone. Um, hey, like thinking of getting back into React native, haven't really done mobile development in a while, but do you have 10 minutes to give me the scoop on like the five things that I should really focus on?

And if they say yes, great. If they're too busy, move on. Um, but if they give you those five things, I'll go back, study 'em, maybe apply for a few jobs. Maybe I got a job and then you could go back to them and say, Hey, thank you so much for helping me. I was able to use your five things. I got the job. And so I think being able to form a mentorship more organically other than going straight up to them in their face and being like, Hey, leaving my mentor.

Um, yeah, I think there's like tactics that you can use that can really help you learn, even like knowing specifically what you need to learn from others. Can really help you kind of sneakily

Aaron Rackley: get a mentor. I noticed that you mentioned, you know, calling out on Twitter or potentially other social [00:07:00] media aspect, looking for a mentor doesn't necessarily mean finding someone within your own organization or.

Really does it. You can look anywhere, I assume.

Erin Fox: Yeah. And you also don't have to have one mentor. Um, I have many mentors in different kind of corners and pockets of what I wanna learn, but I think it depends on what you wanna learn. If you want to get better at, say you just joined the company and you know nothing about Rails, Ruby, and um, they're senior engineers and you just put out maybe a slack of, hey, I'm new here, like learning, trying to learn all this magic that Rails has apparently, like everything just happens.

Um, and I don't know why we're calling these controllers, controllers and all this stuff. So yeah, you can um, just ask a question of like, Hey, does anyone have 10 minutes? Love to get some advice. Um, that could be a form of mentorship too. I have someone that I asked for career advice specifically, so I don't wanna go to that same person and say, Hey, You know, is this like, do you think my career is going in a good path?

[00:08:00] Or, or you know, so like, depending on what your goals are and what you wanna learn, you can have multiple mentors. Um, but yeah, you really gotta find out where they hang out. You know, like if, where, like, if someone like you see is really great on Twitter of like talking about, I don't know. Salary negotiation and you're like getting a new job and you wanna get some pointers on that.

Um, definitely try and reach out to them. But, um, I think the, the main thing is like you really need to focus as a mentee. You really need to focus on yourself in what you wanna learn and then go find those people that are really good at it.

Aaron Rackley: Yeah. Okay. And as you as highlighting there, some of these relationships don't have to be long lasting.

They can be very short period of time for what you are. Aiming for in that moment compared to long-term visions like your career, if you've managed to find a mentor who is willing to help you in your endeavors, do you have any kind of skills or approaches that you take to nurture that long-term relationship?

And do you kind of like meet regularly? [00:09:00] Do you check ins? Like what, how does that kind of relationship seem to

Erin Fox: work? Yeah, I think depends. I think it, if it's someone that's like in your company mm-hmm. That you're working with, maybe you can meet. Once a week for an hour because you're working on a project to help you learn more about like, I don't know, react state or something.

Um, if it's you just wanna do a check-in and like a pulse check of your career, I think you could just kind of. Maybe message them on LinkedIn or like whenever you have a question or, um, things like that. But I think one of the main things is if you don't have like a constant weekly mentorship one, if you do have like once every couple months, it's important to follow up with them to let them know how their advice and how their teachings really affected you and how it helped you.

Because I think it makes it so much worth it for the mentor. To say, oh, this feels great. Like, I'm actually giving someone advice. They're listening to it or practicing it and it's working. Um, [00:10:00] so I think there's like a full little like life cycle circle of, of how those meetings should go. Um, but it really just, I don't know, depends on your workload on how much help you actually need, how much time the other person has.

It could be completely over like dms or on LinkedIn or anything like that. So I think if it works for you and it works for them, Um, it could be situational, but

Aaron Rackley: how can you tell if you, the mentee, the mentor you've chosen is good or bad? Like, how do you know if it's going wrong or it's going well? Yeah,

Erin Fox: I think that's, yeah.

I think, uh, you said mentor, right? We'll talk about Yeah. Yeah. A good mentor first. Yeah. Yeah. So I think a good mentor is someone who, Is really willing to like share their knowledge and help others. Mm-hmm. So if they're constantly putting out content or if you notice that they do great blog posts or, I don't know, they're just like, Willing to listen to you, and they could explain hard concepts [00:11:00] maybe in a handful of different ways and different perspectives.

Mm-hmm. I think engineers that you keep asking like, why, or like, I don't get it. And they keep, they keep being able to explain it. Like so many different perspectives are probably the smartest people that I've worked with or know. Um, but yeah, they just, I think a good mentor really provides. Guidance, um, in the right direction and not really doing everything for them so they don't take over the screen, they don't take over the keyboard really, like I mentioned earlier, kind of teach them to teach themselves.

Um, so yeah, I think a good mentor really just shows you. How to teach yourself by like, how they've, they've guided you. Um, yeah, but also with like plenty of mentors, there's, you could also have a bad seed or a bad mentor, um, which, which happens.

Aaron Rackley: Okay. So to [00:12:00] flip that round, uh, um, to you as a mentee, how do you be, be a good mentee towards your mentor?

Yeah,

Erin Fox: I think. It was, this was hard for me because when I first started out, I was so excited. I just wanted to learn everything and I had this really great mentor and I was like, I don't wanna disappoint them. What are the rules? I'm a big rule follower and I couldn't find much out there. Um, so I started like writing and keeping notes and now I have a blog post called How to Be a Good.

How to be a good pair partner in pair programming. Okay. Um, but overall, I could just give a scoop on that is so being a good mentee I think is also open and willing to learn. You show up prepared, um, you've googled the topic, you've watched videos, read blog posts, searched the company slack, which is awesome.

It's just a great, great tip. Um, you found the, like maybe you found the file but you don't know the right syntax. Um, you have a list of questions. You just come very prepared cuz you don't. Waste anyone's [00:13:00] time. Um, I think, um, one of the biggest things that you really, um, can do for a good mentee is, or how to be a good mentee is ask questions.

Um, I think sometimes, If you have a more senior engineer, they just don't realize some things or like realize what you know or what you don't know. So if you keep asking questions, I think that will really help you become, um, a great mentee and eventually a mentor. Mm-hmm.

Aaron Rackley: Yeah, and I think I. If I'm remembering this correctly, I think in your talk you mentioned a little bit about knowledge swapping as well as a mentee, a mentor.

Do you wanna talk about that a little bit as well?

Erin Fox: Yeah, absolutely. Um, so personal experience of mine, I have been, um, in a mentorship relationship with someone on my team. Uh, well, technically he's on another squad, we call it. We have squads. We have about five squads, but we have an engineering team.

Mm-hmm. And, [00:14:00] um, He has primarily been working on the backend is really wise with Rails and Ruby and all that. And I mostly, my heart's always been on the front end, even though I'm full stack. But I've been, when I joined about three years ago, I was having difficulty just understanding the backend and rails and Ruby syntax and all that.

And so being able to, this was actually like a planned mentorship where we, if you wanted to join, you can sign up and get paired up and, um, I think. The way that it really helped is like sometimes. I'm the mentor when I'm helping with react and front end things, and he's learning a lot in that way. And then other days we totally flip it and I'm the mentee and he's the mentor and he's teaching me about a lot about rails things.

And so I think with some specific mentorships, it could be a flip flop back and forth of constantly like learning from each other. Um, you could also, if it's just someone you're getting [00:15:00] career advice for, they could. Give you some advice, you do it. You come back to them, you say, Hey, it worked. Then I think that mentor is also learning like what advice is good to give and then they can mentor other people or maybe it didn't work and they're like, oh, okay, let's try something else.

And so, um, I think. With, with mentorships, it's felt, it usually feels very concrete of like, I am the mentor. Yeah, you are the mentee. Um, and I kind of like to break that up a little bit and flip it around because you could constantly be learning from, from either of

Aaron Rackley: you. Okay. Um, now when I was watching you at the React London, there was a slide.

That I remember very fondly. Um, and it was when you were talking about the seagull effect and I, I remember taking a screenshot and having to, well, with my phone, I was on my computer, so, but I took a photo and I immediately tweeted it cuz I remember the phrase. And I've got it up just to [00:16:00] remind myself, but it was like when someone is trying to help but craps all you over your code and then flies away.

Now I'm just pulling that out because I think you need to tell everyone what the Seago effect is because I loved this part of your talk. Sure, yeah,

Erin Fox: absolutely. Um, so yeah, we've basically talked about great experiences with mentors and mentees so far, but sometimes they don't go well. Sometimes you have a bad mentor out there and, um, Thes effect really has been a counter example of that.

And it's from a personal experience. I was working, um, on a team in pair programming with a more senior engineer. And each week I kept feeling lost after the pair sessions and more confused. Um, my code was a mess. None of my tests were passing. I was really just like the code was spiraling out of control.

Um, and so, yeah. Um, and that's where I kinda like, Come up with or bound, uh, the si effect. And yeah, as you [00:17:00] mentioned, it's when like someone comes in or flies in crops. All of your code makes all these changes. And then goes away. Um, and it doesn't really just apply to para programming or, or engineering mentorships.

You could really have many seagulls in many life situations. So they attempt to help you make a bunch of changes and then they leave you hanging because maybe they ran outta time, they got overwhelmed. Um, they didn't know how to solve it, and they didn't wanna admit that they didn't know how to solve it.

Um, but overall, you're just like left with no solution, no confidence, maybe questioning your career life choices, um, when really you should just be like flying and working together in the same direction. Not having someone crap all over your stuff and then fly away. Um, and if this is happening or if you are single yourself, that's okay.

The first step is to, to. Realize that you are. Um, but yeah, take a pulse check, uh, be more direct with what you need, what's not working. If you're just too overloaded with work, [00:18:00] you just have pressure to finish a project and you don't have time that week mm-hmm. To help a mentee. Just be honest with that.

Um, and if it's not working out, maybe just have very different learning styles. Yeah. Just take a pause. Um, say, hey, like, um, It's not working for me. Maybe right now there's a lot going on and I wanna try this on my own and maybe ask some other people on the team for some help. Um, I think that's one of my secrets of if I do get too overloaded and I don't wanna hurt anyone's feelings, or if the mentorship isn't really working out and, and.

Either of our favors, I'll say like, Hey, things have been a little crazy lately. Do you mind if we take a pause on this mm-hmm. For a few months or a month? And then be able to pick it up if our schedules allow it. Um, but yeah, overall the seagull effect is, it's very fun.

Aaron Rackley: Um, that's a great slide to have in your, in your, yeah.

So you mentioned there, um, like you mentioned a couple of techniques in there for, um, [00:19:00] The conversations you're having. And I, I know you mentioned peer programming just then as well, so mm-hmm. Is peer programming a technique you use during your mentorships, or is, is there other techniques that you can recommend for people trying to be effective?

Erin Fox: Yeah, I think it, um, for, at least for me right now, like where I'm at in my career, I. Want to get better. Like, I feel like I'm very good with my, like my soft skills, my communication skills. Mm-hmm. My negotiation skills and my, where I would need to improve is like my, my backend code, my more complex projects and just kind of leveling myself up as a full stack engineer.

And I've found the best way that I can learn and level myself up is through pair programming because that my goal reflects around code. Um, but. I, I love parents. Okay. Mean so [00:20:00] much short, especially working remote because I get a little lonely with the whole, you know, remote and I'm like just here in my house, just by myself.

So, um, being able to meet up with someone, then pair program and it's just, um, one that fills that loneliness hole for me. And two, I'm like, I just learned so well from others. Just mm-hmm. Like screen to screen, face to face. Yeah. Um, But it's also, especially pairing remote is so much better than pairing in person because like two people huddled around one screen, one keyboard.

It's not fun for me at least. But then when you're able to screen share and like. Do notes and like if they wanted to just take over real quick and write a left code. Um, I think para programming is a great way to force people to explain code and like use their words. Mm-hmm. Um, which helps them comprehend it more if they can explain it.[00:21:00]

Um, yeah. Overall just, yeah, big fan of pair programming. Oh, also one of my favorite things about pair programming is you learn the other person's tricks.

Aaron Rackley: You're like, oh, how did you do that? I didn't, yeah.

Erin Fox: It's like, I didn't know you could do that in BS code. Or like, someone had, uh, GitHub co co-pilot turned on when I was pairing with them, and I was like, what is this magic?

Like, what is GitHub co-pilot? And now I have GitHub co-pilot, and it's just, it's also fun to just see their tricks and tips on how. They are more efficient with their mm-hmm. Coding.

Aaron Rackley: Normally, whenever I'm doing pair programming, people just like to complain that I'm using the mouse too much. Ah, I have not learned all the shortcut tricks in my life yet.

I, so they go, why are you moving your mouse to get the file open? I'm like, I don't know. It's just muscle memory at this point. I'm too old. Yeah. But, um, yeah, well basically, um, This is one of the reasons I started the podcast in general is like, as you were saying, just in your, your goal right now is [00:22:00] to improve your backend skills in, and you're looking for mentors for that.

Whereas my aspect right now is I'm trying to get better at public speaking and communication and I thought, Having the podcast be a great way to kind of do that without too much of the pressure of having to stand on a stage. And so I applaud you for having done that many times. But, um, my goal obviously, um, is by.

Probably the end of the year or beginning of next year, is to sign up to try and get a talk onto a platform somewhere. So this is a way to kind of build up that confidence, that build up some skills list, learn from everyone else, uh, the people that have done it. So yeah, I am, I agree with you, finding the right platform for what you're trying to learn.

If you're learning to co-program. Pair program is definitely, I am a big fan of it as well. Especially I do a lot with junior developers and especially with VS. Code now where like click of a button and you're internet ID and you're coding alongside them. It's [00:23:00] amazing how quick that works. Absolutely.

Yeah. We've specifically got, in your title you said how to get a mentor without asking them, and I think that's, that's an interesting key. Part of that is like, do you have examples of how you've managed to do that? Because obviously we talked right in the beginning, like, how do you approach people and how do you.

You know, have that conversation without being too blunt, but how do you do this trick where you don't, they don't realize they're being a mentor? Yeah.

Erin Fox: Yeah. Actually

Aaron Rackley: I have a, that's not too cheeky to say it that way. Like, no, you know. No, you're like deciphering your information.

Erin Fox: No, that's totally acceptable.

It's like, this is your talk title and you haven't even talked about the talk title, so that's completely fair. Um, but yeah, I have a, a handful of examples. Um, so. Personal examples for me anyways. Um, when I joined Convert Kit, uh, they were just starting a mentorship program. It wasn't very that formal. It was fill out a Google spreadsheet, what are your goals, and then [00:24:00] whoever wanted to join could join.

Um, and then we got matched up and you're allowed to be matched mentorship relationship for about three months. And then if you wanted to continue, you could. You didn't want, you could get sign up again and get a different mentor. Um, and so that was very easy for me to just, oh, great, yeah, I'm new here. I wanna learn more, more rails back and things.

So I'll sign up and, um, ended up working out. Great. Um, initially the program I mentioned was quarterly, so you would switch mentors, but I am still with the same person I got matched up with and now I've been at the company for three years. And, and I think the cool thing is, is that they use like little match.

Um, mentorship programs can really be started by anyone on an engineering team. Mm-hmm. I don't think anyone would say, or I hope no one would say we're not doing this, um, because it takes up too much time or [00:25:00] something. Uh, that would be sad and you shouldn't work there. But, um, overall it's, I think, Being able to just set up like a mini thing and gauging people's interests and pairing people up is just kind of lifts the pressure of trying to find someone for help or trying to find someone for it.

And all you need is like a signup sheet on Google and then like a Google form and to be able to, to sign up. So that's a sneak away. I got a three year mentor now without really formally asking them. Um, another one, and we just talked about it, is, um, para programming, I think. Uh, peer programming has like little forms of mentorship.

I, um, I probably peer program a few times a week with people on our engineering team. I think it's a, it's like, it has proven to be like a great way to learn from each other, like raise a level, like of the entire team. Um, maybe isn't really everyone's first thought because. It could be like a vulnerable thing to be [00:26:00] like, Hey, does anyone wanna payer program?

Like, I'm not quite understanding this. Mm-hmm. Um, but I think making yourself vulnerable and putting yourself out there like allows other people to see like, oh. Like Erin's really smart, she's asking for help, like I could ask for help too. So I think kind of that working in public and being able to ask to help pair program, um, can really help.

And if they're just like, yeah, like tiny little things like, Hey, anyone have time to pair today on like, react news effects? Like, I'm creating one, then I'm missing something, then I don't really understand everything. Um, like I think saying you don't know something isn't a sign of weakness, it's an opportunity Oh, absolutely.

To. Get, yeah. To get yourself to grow and learn and to have others learn and grow with you. So I think overall pair programming you mentioned we're huge fans. Uh, but I do think it's like mini mentorship, um, lessons. And if that pair programming really sticks and you learn a lot from that person, it could blossom into a mentorship.

[00:27:00] Mm-hmm. Um,

Aaron Rackley: thing, mentorship thing. Yeah. I think as, um, your, your career progresses as a. A developer, you know, you eventually, hopefully you get to like the level of a senior developer and you become a mentor without realizing it anyway. So you immediately have juniors and mid-level people that you're constantly having to work with and l help them progress through their stages of their career as well.

And what you said then, just then about not being afraid to ask to, you know, ask a question is something that I. Try to say to every junior or every junior I ever meet, um, I say, I'm constantly asking questions. I, I do. I'm, I've been doing this 15 years and I'm still asking questions cuz internet moves so quick.

The web moves so quick, there's a million frameworks going on. It's impossible for you to keep up with anything. So, you know, I'm always saying ask questions, ask in the group if generally, sometimes as well, when [00:28:00] people, like, we have a slack at our company and if someone asks a question, Personally, I would just be like, if you ask, can you just ask that in the main group?

Because then more people are gonna have the option to look at it. They might have a different feedback, more people getting into the conversation, and you're sharing knowledge and mentoring everyone at the same time, and you're all helping each other, which goes back to that kind of like swapping knowledge aspect

Erin Fox: of things.

Yeah, absolutely. And I also think being, um, having being a mentee and, and having a mentor really. As you're leveling yourself up, you're like leveling up the, the mentor. Mm-hmm. Um, example I have of that is another teammate I started working with once a week, sharpen up my friend and skills. Um, also just trying to get to learn more people in the company, um mm-hmm.

And pair programming is a great way to do that. But as I was leveling up, I didn't really realize that they were also leveling up. Um, I was learning like, Great debugging stuff in front end UI solutions. [00:29:00] Um, but they were learning how to be a mentor since I was setting a good example of what a good mentee could be.

Mm-hmm. And so they discovered that they wanted to become a manager based off of, um, some of our mentorship sessions. And eventually a engineering manager role opened up for them and they've gained experience and had examples, um, to give. And so mentoring can really open doors for career opportunities as well.

Aaron Rackley: Yeah. And I think, um, it's important to probably say that mentoring is not just as we were just highlighting a little bit there, it's, it's not a one-to-one relationship because you can be a mentor in a group scenario. Like for everyone that's essentially going to a talk to be is a mentee of that talk and the person giving it as a mentor of that talk, right?

So I think if you want to be an effective mentor, you have to. Practice all aspects of being a mentor, whether that's individual, public [00:30:00] speaking. I even find personally, I think even writing blogs, that kind of stuff. I find this all the same skill set that you need to be affected by it. Would you think along the same lines or,

Erin Fox: yeah, actually I'd never thought of, thought of mentorship at that wide of a lens, but I think that's, that totally clicked in my mind of.

I'm writing a blog post on this. I'm sharing my knowledge, others are learning from it, and they can be a mentee and learn from it. So yeah, absolutely. I think there's many forms of like media out there that you can place yourself as being a mentor. Um, no matter what level that you are. It's contribute, open source, giving a talk, um, writing a blog post.

The podcast doing podcasts. I think there's definitely ways to, um, put yourself out there as a mentor and kind of like that also is like a secret way of getting some mentees if that's something that you're interested in.

Aaron Rackley: Yeah, absolutely. One more question I had [00:31:00] I've written down is about. Mentorship programs.

And I know you mentioned your, the company kind of had a little one, but have you had any experience or know anyone that's had any experience of like official ones? You know, like you have some companies out there that are willing to try and ma match people up and sometimes you pay fees and all this kind of stuff, but how do you feel that that dynamic compares to ones you, um, kind of like organically grow?

Erin Fox: Yeah. I think those are fantastic. I personally have not, um, done any of the programs, but I've heard great success from, from people being involved with them. Mostly because people that are involved with them already are committed already want to be there. Um, so you know that, you know for sure that something's gonna happen, which is probably reassuring if maybe you want that assurance that it's gonna happen.

I think those types of programs are, will be. Fantastic. Um, for you and if they [00:32:00] have the type of mentors and that have the goals that you wanna reach, then Yeah, absolutely. Um, I've just had more experience organically reaching out to people. Um, mostly cause I'm not scared to ask questions and slid into some dms.

So yeah, I think, I think anywhere you could find a mentor, um, that you feel the most comfortable is, is great.

Aaron Rackley: Yeah. Uh, I think I. Have. Um, so the other day I actually got an email randomly in my inbox from someone who like, had obviously found me from somewhere, found my email address and was reaching out for some advice on just changing their career from, uh, they at university study and theater design, which is kind of what I did back in the day.

So that transition, so, you know, being, not being afraid to ask is definitely the first jump. And, um, my fiance who's not in this tech world or anything, was very much like, Is that weird? Like someone's just jumping. I said, and, and it maybe did think about it, it did make me think, is it weird? [00:33:00] And, and I thought about it more and I thought, no, cause I've done it many times.

It, for me, there's no difference in doing it in an email via a Twitter post. Like it's all the same kind of communication, right? It's, but just making sure you're not just jumping, like you said, into someone's face. You're just going. Can you help me? Right. There has to be some kind of pretext to it. Um, I think that was just, yeah, that, that's that an experience I hadd recently, which I found quite funny.

But, uh,

Erin Fox: yeah, so yeah, absolutely. I think it's only weird the first time you ask after a while. It's kind of just like applying for jobs, you know? You just like,

Aaron Rackley: keep, keeps going. Just just handing your CV to anyone on the road. Can you just say this? Yeah. Okay. Yeah, so that's, honestly, it's been a great, great conversation.

Um, since I watched the talk, I really wanted to sit down and have a chat with you. Um, I just didn't have time to stop by afterwards and do any q and as, which is a, which was a shame. But I'm glad [00:34:00] we've managed to sit down and have this conversation, and I hope that we definitely see each other on a one of these random events sometime, somewhere.

But, um, I'd like to just open it up and say, where could people reach you? Um, if they have any other questions or they wanna see, because I know on your blog you have the slides for all your talks, so mm-hmm. Where, where can people find you?

Erin Fox: Yeah. I've tried all the. New Twitters that have been coming out, but I haven't been really keeping up with those as much.

Uh, so sadly, should I say, sadly I'm on Twitter. Um, but I'm on Twitter. It's the main place to find me. Uh, my handles Aaron, so it's Aaron Fox with two os. Um, I check that regularly. I love getting dms of people asking for career change advice or anything like that. So mostly hang out on Twitter still.

Aaron Rackley: Cool.

Um, and I'm gonna throw [00:35:00] one random question at you and I, I, I apologize cuz I haven't prepared you on any of it. No. Yeah. So, um, I'm, I'm gonna ask everyone that's on the podcast the same question, which is, if you could get someone in your, your profession to read one book, what book would you give? Send them.

And it doesn't have to be technology based, it can be anything that you like.

Erin Fox: Wow. One book. An engineer would read it. Oh, this is hard. Um,

Aaron Rackley: one

Erin Fox: book, this one is a weird one and I don't know why I'm thinking of it, but it, I forget the author, but, um, I'm gonna look at that real quick. Um, I read it about a year ago and it's called Breath the.

The New Science of Lost Heart by James Nester. Okay. Um, it's a big [00:36:00] yellow book and it, it, I don't know, I've been really into like meditation lately and mm-hmm. Breath work and just trying to be, you know, more calm, less anxiety and it was just a fantastic study on how we breathe and how if you breathe through your, I dunno, it was just very, Reassuring and just like fascinating on how, um, humans breathe, which is probably so random.

Such a random

Aaron Rackley: book. No, but this, to bring up, this is why I wanted to ask, this is why I'm asking a question very kind of openly, cuz it's, I'm always interested what people are reading outside of their usual bubble of stuff. Yeah. So like, like if you ask me, I'm reading Oh, go, go, go for it. Yeah. Can I change my answer?

Erin Fox: Of course, yeah. Okay. So there's that one, that's number two. But. The absolute best book that I would recommend that completely has changed my life mm-hmm. Is called Quiet by Susan Kane [00:37:00] and I gotta get the right, uh, title for you.

Aaron Rackley: Yeah. So it's, we put the correct heart of the links. Yeah. Show notes as well.

Erin Fox: So, yeah, it's called Quiet The Power of Introverts In a World That Can't Stop Talking by Susan Kane, and I'm a huge introvert and. This book just taught me that I shouldn't be saying I'm an introvert, you know? Oh yeah. It's cause it's just because I'm an introvert. Like it's a bad thing. And it helped me really embrace, especially like a lot of engineers are introverts, a lot of people that were promote are introverts.

Um, it taught me so much about how I like to work. And how I can work more effectively with others and like how to tell them what I need. Um, so yeah, absolutely Quiet. Um, by Susan Kane completely would write, if you're an introvert, if you're, even if you're not an introvert, just to learn like maybe your, your spouses, your partner is, or one of your immediate reports is you just, it just really is so [00:38:00] eye-opening to learn about how they recharge, how they think, what they need to be an effective leader or like individual contributor.

It's just, it's

Aaron Rackley: fantastic. Brilliant. No, that's two, two new books I need to put onto my wish list. Um, and give a read. Yeah. No, no. Thank, thank you again for coming on and I hope to have you on and again in the future. Maybe we'll elaborate on some more. Mentor, ET. Mentor. Mentor. I can never say that right Word.

Mentor mentee, yes. I keep thinking man, mentoring for some reason in my head. But yeah. And

Erin Fox: thank you so No problem. Thanks so much for having me. I always love talking about mentorship, so anytime.

Aaron Rackley: If you'd like this conversation, please do remember to subscribe to this podcast on your favorite player and stay tuned for upcoming episodes and if you would like to come and have a conversation with Be Back.

A subject you are passionate about, please email me at contact tech leadership decoded.com and [00:39:00] I'll see you in the next episode by for now.