Here's the truth. Hiring remote engineers doesn't have to be expensive and time consuming. Our friends at Revello can help you find and hire top engineers based in Latin America in a matter of days. Just tell them what skills and experience you're looking for. They'll come through their network of over 400,000 pre-vetted engineers and give you a short list of curated candidates that meet your specific hiring requirements. You interview
and hire on your terms and only pay for as long as you keep the engineer. To learn more, visit revello.com forward slash ELC today and save $2,500 off your first hire. That is just a ripe environment for the rapid degradation of trust within an organization and has immeasurable consequences when it comes to degrading the culture of a team. I think the temptation is there understandably and I think from good intentions of I want
to try to measure unobtrusively. I want to get this data about my team without them knowing about it or minimally knowing about it so that I'm not bothering them. That is a trap because we don't need to treat people the same way we treat distributed systems with dashboards and dashboards of telemetry data. People can talk, just ask them. Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the Engineering
Leadership Community. I'm Jerry Lee, founder of ELC. And I'm Patrick Gallagher and we're your host. Our show shares the most critical perspectives habits and examples of great software engineering leaders to help evolve leadership in the tech industry. One of the first concepts that our guests today shared with me that shifted my paradigm is that it's not about how you measure. It's about how you change behavior. In today's
episode we are joined by the inimitable Laura Taco CTO at DX. Laura reveals why changing what you measure doesn't always lead to improved productivity and many of the different things that you can actually do about it. And so in this conversation we talk about some of the best practices to identify and define what productivity looks like in your engineering organization. How you can harness behavioral psychology to help your team achieve their
goals. We also talk about anti patterns to avoid when you focus on developer productivity. Plus Laura shares her favorite approaches to identify your skill gaps and define what success looks like for yourself and your team. Let me introduce you to Laura. Laura Taco is CTO at DX, a developer experience company. She previously led teams at companies like Cloudbees, all the education and Nova Credit. She's an expert in building world class engineering
organizations that consistently deliver outstanding results. Beyond her own leadership experience, Laura has coached CTOs and other engineering leaders from startups all the way to the Fortune 500 and also facilitates a popular course on metrics and engineering team performance. Enjoy our conversation with Laura Taco. First off, just wanted to say welcome Laura. Thanks so much for joining us on the show. How are you doing? What's going on? I am doing really
well. You know, it's morning for you. It's like, you know, actually, it's not even dusk for me. It's straight out dark, dark, dark out. But I can look at my window and I see like Christmas lights. There's some snow on the ground. It's very peaceful. So it's winter magic right now for me. The winter magic. I love it. To kick off our conversation a little bit. I think the context I wanted to share with folks listening in ahead of time, over
300 companies have taken your course on measuring productivity. You've coached hundreds of executives around that topic. And now you're at DX and continuing a lot of that same work in that space. And so I share that to kind of share with folks that you spent a lot of time in this problem space thinking about these issues that plague engineering leaders all the time, these like existential crisis issues. And so that you've been reflecting on like the state
of measuring and productivity for a long time. And for me, I'm like, you are tapped into like the pulse and the trends and like the what's going on more than I ever could observe. And so this topic specifically like measuring productivity has been something that's like one of the most popular things like every time we do a peer group, every time we do an executive dinner, everyone's like, what are you using to measure? Like how do we talk
about productivity? And so I don't really want to talk about like that specifically. But I rather want to like zoom out and get some context like, why do people like so passionately care about measurement right now? What are you observing or like what are you noticing about this conversation around engineering and productivity? Right now those two words are just
key. We didn't care as much as about productivity when money was free, more or less. And I do think that there's some not all of it, but I do think there's some correlation with economic circumstances and economic pressure. And I think a lot of executives and engineering leaders right now specifically, they just want to make sure that every dollar, every euro they spend is being spent in the right way. And these metrics have been fairly easy for
people on the go to market side like sales marketing. There's a really concrete metrics to look at performance and measuring engineering performance because it's knowledge work. It's just been really tricky. And now there's just a little bit more pressure to try to figure it out. I also think aside from that economic pressure, there is just naturally, I don't
want to call it necessarily commoditization because we're not quite that far yet. But there's the adoption curve where things that were in early adoption stage by companies that had larger budgets and they did the sort of pioneer work are now ready and ripe to be taken and embraced by more people in the industry. And we see this curve happen all the time, right? DevOps was a fringe thing before it became mainstream. And I think
in the same way developer experience was a fringe thing. And now it's starting to see more into the mainstream where now executives are starting to care more about developer experience. And that's leading to this boom of how do I measure developer productivity? Do we have great developer experience? How do we rank against everyone else?
What do you find to be like some of the tension or the traps like when people are going down this journey to now focus more deeply on productivity, developer experience and things like that? What are people typically doing that is maybe, I don't say a mistake, but like maybe they're falling into like some type of trap. Yeah, anti patterns. There's lots of them. I think the bottom line for me and I'll sum it up really concisely here is that teams, engineering orgs want to be consulted about
that productivity, not informed about it. And so if you just think about what that means, it means I don't want as a developer, I don't want to block anywhere into a room. I don't want to open up a browser tab and see a dashboard with my commit history or how many times I'm releasing to production without me knowing about it beforehand, without me knowing
who's seeing it, without me knowing what's going to happen. That is just a ripe environment for the rapid degradation of trust within an organization and has immeasurable consequences when it comes to degrading the culture of a team. And so that is definitely an anti pattern. I think the temptation is there understandably and I think from good intentions of I want to try to measure unobtrusively. I want to get this data about my team without them knowing
about it or minimally knowing about it so that I'm not bothering them. I'm not taking it more of their time, but we want to just look at the data so that we can, let's see what the bottlenecks are. Let's look at the telemetry and look at the bottlenecks. That is a trap because we don't need to treat people the same way we treat distributed systems with dashboards and dashboards of telemetry data. People can talk, just ask them. It sounds really novel, right?
Yep. I think what's interesting is some of the anti patterns that you're highlighting here, they dive into the psychology or the behavioral parts of people and that oftentimes like for us trying to build a perfect system or a perfect process, the challenges that we run into very much so more live into the psychology and people's reaction to those systems. I know you have a lot more thoughts about the idea of behavior and psychology.
So I was wondering if you can maybe bring us into that perspective a little bit. One of the common pushbacks that you might hear if you're talking about having a team participate in the measurements that they pick are like they're going to game the system. And I think that's a totally valid concern to have. But what I always say is that if you are concerned or if you observe that your team is gaming the system, that is not a negative
thing about the team. It means the systems, it's working as designed, right? Human beings are designed to work in a way or make choices in a way that's going to bring us the most reward or incentive. And if you create a system of metrics that rewards the wrong behavior, you should only expect that people participating in that system are going to do the wrong behavior in order to get the reward. It's maybe not as straightforward as a mouse going
through a maze to get the cheese. But when you just take it on a very, very zoomed out level, expect the expected that's you're setting up a system where people have the wrong incentives. And there's a saying of the worst thing about bad metrics is that people will use them. And so that's part of this. I'm going to set up metrics and my team's going
to know about them and then they're just going to game the system. And so what I say to that is like, don't create a system that can be gameed or figure out where your incentives are. So that's one thing. I think the other part is like just the misguided feeling that we can measure on obtrusively and have it a not be damaging, but then also be actually
giving you the result that you want. Because I mean, if I came to your house and like made a dashboard of everything that you ate yesterday and I just presented it to you, you'd probably call the police. You know, you'd probably think that's a really creepy thing to do. And I feel like my privacy's been invaded. And I know that professional setting, right? We have slightly different rules, but people don't like being spied on or feeling like they're
being spied on. And that's a lot of times what metrics just feel like. You talked about this idea of teams want to be consulted, not informed about their productivity and that impacts trust. And so I was wondering if you could maybe color that in a little bit in terms of what does that relationship look like when it's not a dashboard, when it's more of that consulting relationship and not more of an informing other people about their productivity.
Like, do you have like a sense of what does that structure typically look like? You know, you can certainly get these measurements unobtrusively. The thing is that you're not going to be able to do anything with them unobtrusively. Because in order to actually move the needle, you need to involve the people who are doing the work. And that's the team that you're observing
in the first place. My method, it's the same like four steps. And when I consult with teams or bring people through my course, I'm always giving them the same kind of the rundown of these same four things. I always encourage them to start with a survey telemetry and you know, dashboards on dashboards on dashboards of data. Great when you're just trying to debug a distributed system.
But like people can talk. So let's just take advantage of that and see if we can get some quicker answers than leaving us to, you know, a terabyte of workflow data and trying to like distill it. So start with a survey because your developers are feeling the pain of inefficiencies every day. They know what needs to change. And when you can find that pain, what you've done is you've unlocked intrinsic motivation for them. You've unlocked this possibility of a new future and
you've unlocked motivation for them to participate in fixing the thing. Because you're saying, hey, I want your opinion about this. And then now I have your opinion, you've said that this is a problem. Let's work together and fix it. And when you're fixing it, that's when you can draw on certain quantitative metrics as well. And all other qualitative metrics to keep track of your progress.
But you got to do the hard work in order to move the needle on these things. So it's really just start with a survey, find the pain, figure out where you're going, set the goal, find measurements to check whether you're hitting the goal, do the hard work, and then evaluate, did you hit it? Do you need to change something? And that process just repeats over and over and over.
I love that survey as a pathway to intrinsic motivation. That's such a more empowering pathway to unlock your team's ability to contribute and impact the organization, but the system and both the results that you achieve. I think like if you put yourself in the position of what I rather have someone come to me and say, hey, we want to fix this or optimize this or I want your
opinion on how we can make things better. What do you think is the problem versus saying, hey, come into the boardroom, I have this slide deck and I'm going to tell you every place that you're messing up or every place that I think that you have a problem. I would just feel like, why didn't you just ask me, I'm sitting right here. I could have told you that. And I think it just doesn't set up whatever happens next for a great success because the trust was sort of violated already in
that first interaction. I love that idea of like, it's what happens next is what's most important. It's not necessarily even like the data that you get. You have to optimize for the what happens next. And I think that's really powerful. As a US company, hiring remote engineers can be time consuming, expensive and frustrating. You could hire freelancers, but you don't know how much they'll focus on your business outsourcing to dev shops, risks, control over who works on your projects and
expensive long term contracts. Or you could look overseas, but working across lots of time zones can really slow things down. Enter Revello. Your gateway to a talent network of over 400,000 pre-vetted engineers in Latin America who are proficient in English, work in your time zone and are dedicated exclusively to your business. Revello simplifies the hiring process, enables quick payroll in local currencies and provides expert staffing support. There are no big up front contracts,
you only pay for each month that you decide to keep your developers employed. With Revello, you're in complete control. You get to decide who to hire, what to offer, and you get to decide how long to keep them on your team. To learn more, visit Revello.com forward slash ELC today and save $2,500 off your first hire. A couple things that you've said, you figure out the incentives, do the hard work to move the needle, and then it's the what happens next is what's really important. And so
I want to make some jumps and assumptions here. So like, let's say somebody is measuring and their incentives are incentivizing the wrong thing. And so they want to change their measurements. Does the changing of the measurement impact then the result that people get? And if not, what is the thing that's going to change the result to help them become more productive or become more efficient or achieve that thing that they're looking for? Oh, I wish it was the case that if we
just changed measurements that behavior would fall in line. But I very, very rarely see that be the case. Unfortunately, because the memory and the footprints that those wrong incentives leave behind are very deep. And I think about organizations of having the momentum of like a cruise ship, and then you try to do something. It's like trying to steer it with a spoon. It just takes a really long time. And so there's a gap that always needs to be closed because you've trained people that,
hey, you're a mouse, and if you do this, you're going to get some cheese. And then all of a sudden, you put the cheese somewhere else, and they're still going to be looking in that old place for the cheese until you teach them, hey, it's over here. Here's how you can find the cheese. And if we think about that with people, it's not just about changing the measurement, but you have to fundamentally change the way that people work. And in order to do that, they have to be motivated to change the
way that they work. And that is the hard problem you need to figure out a way for them to believe or see that the version of the org or of themselves that you're trying to get them to is better than the one that they currently have. Right, because that's all I think at some level, we're all working in
sales, right? We're trying to persuade people to do things differently. And I think at some deep level sales is just selling someone a version of a different version, a better version of themselves. And so you really need to answer that question, what's in it for me in order to get them to change their behavior. And that's why that intrinsic motivation piece is so key and essential.
Because if they don't have motivation, it's just harder to get them to move the needle and harder to close those gaps to get the change to actually be enacted on the ground where it matters. This is profound. I mean, I think about a lot of times there's resistance to not want to be salesy. And so when I think about like, what is the case for an engineering leader to develop influencing skills like this to me seems like the supreme case for why it's so important to be
able to cultivate a vision for for somebody else? That to me is like, it's profound. Yeah, you know what I as an engineering person, I think this like, I'm very turned off by salesy marketing things. I think that's a very common attitude like in our pocket of the industry because it's like, it's so easy to define ourselves on what we're not. And I worked with a really great business coach
when I started my coaching business. And one of the things that you worked on was like, I really have an aversion to anything that's like salesy or marketing e. And she just said like, but don't you think that clients working with you has a positive impact not just on them, but on their whole org. And I said, of course, and she said, but they can't have that positive benefit unless they know about it and unless they know about you. And so what are you going to do?
And I just thought that really changed my whole perspective on this. And I think influencing doesn't have to feel salesy. And I think engineering we often get that push back to like salesy influencing stuff on things that we don't believe in. But as an engineering leader, absolutely, if you believe I want to make sure that my team has the best possible environment, the best
possible developer experience so that they can do their best work. You got to have to have you need to learn how to influence and have to learn how to present that in a way that gets people to participate in your system. Because if you truly believe that that is the right ethical moral thing, but also like the right thing for the business, you need people to participate in that only comes with influence. I'd be curious to dive in a little bit more specifically.
So when we're talking about in order to change behavior, we have to cultivate a belief that the version of the org or the self is better than the version that they have. What are oftentimes like the roadblocks to like a team adopting a new behavior? And what can the leader do to influence or change that conversation? I think one really key skill for any engineering leader is understanding the facets of motivation. And generally people are motivated either by
competence. So they want to be the expert. They're motivated by autonomy. They want to be the one making the call or they're motivated by relatedness. And these are like those community magnets, people who are drawing people together and seeing as like the connector of all things. So I can see you probably are motivated by relatedness quite a bit. You have this podcast that's bringing these
people together. And everyone, it's not like you're one or the other. Everyone sort of has a, you know, like a spider graph of what you know, I'm very motivated by autonomy, but also like relatedness in this aspect. For a lot of engineering teams, things like autonomy are a huge, I mean, that's a huge benefit, a huge driver of why you might want to change your behavior for
something. And so the key here is to unlock what it is that your teams are motivated by and then figure out a way to help them understand that doing x, y, or z is going to help them have more autonomy, have more expertise, have more relatedness because then you can tap into what makes them tick and what makes them feel motivated and intrinsically motivated to change their behavior, not just do it because I'm your boss. And you need to do this.
Can you maybe share like a story or an example related to these, these different facets of motivation? Because I think it's, it's so powerful. And for me, like the part where I oftentimes run into friction with implementing or applying something like this is like sometimes I just like, I lack the right words to say or that's my fear is like, I feel like I'm not going to say the right thing. I don't know how to quite freeze this. Yeah, this, this idea of finding the motivation.
I mean, it comes up in organization-wide applications. But I think I can give a better example on an individual basis. And I'll try to keep this short and small. But when you're doing a performance review of someone who's a stellar performer and you don't have more cash to give them, what are you going to offer them instead as a way to keep them motivated and incentivized? And that's
when you really need to understand what is this person motivated by? If they're motivated by relatedness, maybe it is, hey, speak at a conference, we're going to get you a coach to write your proposal. And when you get accepted, we're paying for everything for you. That's great. I mean, that's a great perk. That's better than beer and ping pong, right? Or it can be this person's
really motivated by autonomy or this team's really motivated by autonomy. If we can get to, you know, achieve X milestone, then why don't we give them, you know, certain amount of time or certain budget to pursue this new spike of work or experiment with X or whatever, then they get the expertise, they get autonomy, they can do some self-directed stuff. By no means am I saying it's a treat to be able to choose what you work on. I don't want to go down that road. That's
definitely not what I'm saying. But there's a way to sort of connect and to contextualize certain things to get people on board and to make sure that what you're offering is like the better version actually matches up to what that person values as the better version of themself as well. No one wants to go to work and feel like they're doing a crappy job. No one wants to go to work feeling like things are feeling really inefficient. I can't decide what I want to work on. We never have time
to do XYZ. Everyone wants to improve. I've never met a developer who didn't. Some of you listening maybe have come across a person that's just fine-coasting. They do exist, no doubt. But I think generally people are good inside. They want to do what's best for them. They want to do what's best for their team as well. Another sort of case study that's sort of popping up to me when we're talking about motivation is I'm thinking of like the quote unquote do more with less environment
that a lot of folks can operate in. So I'm thinking like the perspective of Engine and engineering leader. Maybe they're coming off of a re-org. They're working with a team. Moral is low. And a lot of the questions that come up is how do I boost morale or how do I keep the team
motivated after this or I'm being told to do more with less. But this person wants to work on this particular technology or they want to do this particular project type of work and it's moving away from maybe the core priorities of the organization and we're supposed to simplify and do these types of things. I'd love to just get your thoughts on this environment of do more with less and keeping people motivated, post re-org sort of state. Are there any nuances to apply
these things towards maybe cases like that? Building resiliency is a really important skill for anyone in their professional career. It's never fun to have to be in an environment to build resiliency because it generally means something's happening where you need to be more resilient. But I've had these tough conversations with my own team members at various points in my career. As a leader, it's your job to match up what a person is interested in with what the
company needs. And if you can do that 50% of the time, I think you're doing an outstanding job. I think generally, you know, in times that we've had really hot markets where engineers are able to like move around and do whatever they want and get sort of like unlimited cash for doing so. That's a much harder line to hold because you know that they can go do something else. And so you kind of have to be creative with other reasons that they might stay, for example, culture of
excellence or whatever. But I have very frank conversations with my team that, you know, I'm not going to be able to let you do whatever it is that you are interested in if it doesn't align with what the business needs. So get comfortable that this is a job and not a club. And there's going to be stuff that you don't love doing. But what it is going to do is build in resiliency. It's going to expose you to stuff that maybe you wouldn't have naturally exposed yourself to. You just want
all the stuff that's like immediately gratifying and really interesting to you. But you know, the rest of the 90% of the world that's not hyper palatable. There's so many skills there that are so core to being able to excel and to to transfer those skills to the next thing and do it in a great way. Offering resiliency is actually a skill that you are going to partner with them or partner with the team on building and strengthening the team and, you know, strengthening skills that they might
not have naturally had a tendency to strengthen before. I think that's an important phase of anyone's professional development. And one that I know I look back on times that I've had to learn more about resiliency or improve my own resiliency. And I'm it sucked while I was doing it. And I won't be on, you know, I won't lie about that. I'll be honest. But I'm glad that I had those experiences because now I'm able to see things in act in a way that I might not have had had I not had that insight
gained from those more difficult times. Absolutely. And the offer or invitation I would give folks is to reflect on the moments where resiliency had a huge impact. As part of your what's in it for me, how can you provide that value to your team? Because you sharing that story may have a profound impact on making the case for why resiliency would be an important value for them as being part of the team. That's something I don't think about enough is like in the moments where cultivating that
has actually had a huge impact on what I do. I love it. It's such an unexpected like source of like value or a skill set to give people within the company. Absolutely. Whenever I'm hiring, especially for higher level, you know, leadership positions, I'm always interested in like how many loops have you closed? How many times have you been able to see something from start to finish and everything in between? And leaders that are very resilient just tend to have more of those loops closed.
They've just seen more stuff. They've seen how things can go up down sideways, backwards, upside down. And that's something I really value because it's going to happen again. And so I don't want someone practicing with that the first time as like, you know, VP of a huge organization. I want to see that they have some resiliency built up. And so taking it down to level even like a tech lead, I want them
to have some resiliency when you are constrained by budget or resources or time or whatever it is. And you need to use your second choice for, you know, solving the problem. And how are you going to do that? How are you going to bring the team with you? How are you going to still create a technically excellent solution when things aren't 100% optimized? A couple really great skills to incorporate. I think for people's strategy, evaluating loops closed. And then the skills using constraints
that solve problems. I love that. Another question I want to ask like because I'm thinking about just the exposure and the point of view that you've had working with companies, different engineering leaders like from across the whole spectrum. What I imagine is that you've observed a ton of different behaviors that maybe are preventing engineering leaders or organizations from achieving
the sort of impact results that they're looking for. I was wondering if you maybe share a few other of those types of behaviors or skill sets maybe that you've noticed that are interesting to share with folks here. I find it so captivating at this point in my career that it is kind of all this, it's all like the same six six or seven things. Before we started recording Patrick and I were talking about professional organizers and how they kind of don't have this emotional connection to
your stuff. And so they can just like look at a mess and be like, oh, you need it's this and this and this and this and they do it just so quickly that it's sort of mind blowing. But I've developed that muscle as an external coach because I don't have the baggage of politics, reorg, you know, I just don't have that emotional investment. And so when I look at something, I'm like, well, you can't do that. You might be really great at doing x, y, or z, but like I still see that you are
not able to set a clear expectation with your team. And those are the skills that might be overlooked because you are so strong and something else. And I find that's generally what happens with leaders is they're very t-shaped or even sort of w shaped. If we can imagine that as an alternative to t with like more more things going deep, but they certain they have certain strengths, but there's areas where they're still very weak. And those weaknesses are often overlooked because the strengths
that they offer are so strong and so worth capitalizing. But to get concrete on some of these things that I witnessed all the time from organizations, Fortune 500 tiny baby startup, any leader super experienced, I mean, some of the most experienced CTOs that I've coached still struggle with prioritization, saying no to something is very difficult for anybody. Having expectations, not just on the people's side of things, but also for the outcome. What do you expect to happen as a result
of this interaction? Oftentimes, if you just walk into any meeting and say, stop everyone, what should happen as a result of this meeting? What's going to happen at the end? No one can give you an answer because it's just not, it's implied that everyone knows, but in fact, no one knows. Things like having difficult conversations, giving difficult feedback, coaching someone to a better outcome or coaching them out of your organization. These things are uncomfortable, so we
avoid doing them, which means that we just don't get very good at them. A couple other things would be like matching up the scope and size of the problem with the process or the resources in order to solve it. I see a lot of startups who want to over optimize things before there's really a need to. But really, I think making a plan and sticking to it is as human beings, we just struggle with it regardless of how many years of experience, regardless of your title and whatever fancy chair
that you're sitting in. There's so much I want to deconstruct here. When you're talking about outcomes and just simply checking in with people and saying, what do we expect to happen as a result of this meeting? For me, I'm thinking about where I can apply that in my life and I'm like, wow, if I had inserted that here, this would have transformed the conversation because everybody would have clarity in terms of what we're working towards. Is there anything that somebody can do to
identify if that's a problem for them? Signals that you probably can revisit this and this may be the thing that's a gap right now that you can develop. Is there anything that people can do to identify that challenge? Then what might be one or two things that they can do to help work towards developing that skill set? Totally. I can actually tell you a great story about a leader that I've coached. His name is Joel DiTropani. He is the co-founder and co-CEO of a company called
Vigo. They're in Edtech. He's Australian. Any interaction with Joel is just a delight because he has this particular humor that's still quite novel to me. I just really enjoy talking to him. He's an incredibly coachable individual. We have had numerous conversations in our coaching relationship about exactly what you've described here, whereas where can we find the problem? One of the things that he came to me with was, Laura, I just can't seem to get the results out of my
team. Why are they so bad? Why are they so bad? It was phrased a bit softer than that. Why? What's happening here that we're just not able to get traction on the goals that we're setting? The whole conversation, the problem that he brought to me was my team is not able to perform. And what I said was, Joel, your team is fine. They are behaving exactly as you would expect
them to pave, but you have set a crappy expectation or no expectation at all. And so what we were able to do during that coaching conversation was turn it around from being a problem with his team where he felt very out of control to being a problem with himself, which is 100% within his control. And then we were able to practice and do some role-playing and some mock conversations about, here's a situation, here's what you did, here are all the ways that someone could fulfill
that expectation, not doing the thing that you actually wanted them to. And so here's a better way and more concise way to set the expectation that gives them enough information to be successful without you needing to fall into the cycle of micromanagement where you don't give enough information at first. They don't deliver what you want. And then you got to go back and say, don't do it this way, do it this way, give me an update. And it's just this like micromanagement
spiral that we fall into. So I think that's the hard part when you're in leadership is that you're often not surrounded by people who are like calling you out on stuff. You don't get a lot of feedback. The higher you go, because there's just not people who have your same job at a company, whereas if you're an individual contributor, you're getting more feedback because there's just more people who are doing the same things as you. But being able to look at something and pick a part,
what are you responsible for? What is your locus of control? What action that you could change? Is it that I have to set a better expectation? It's so powerful and unlocks so much capability in your organization more than any metric on a dashboard ever could. I love it. A follow-up question like thinking about like the role of outcomes. Where have you maybe noticed that these are the places that are most ripe for setting the right expectations or defining the type of outcomes
that we're looking for? Like are there certain conversations where the this is particularly thorny or like where are the places that you're seeing that maybe are ripe for outcomes or ripe for these sort of expectations setting conversations? Oftentimes where I see poor expectations leading to poor outcomes, it's often in the planning stages of a project where whoever is responsible for the project has some level. Maybe it's still very low fidelity, but they have a vision of how
things should turn out. There's certain assumptions that they have of what the solution should be. In a common failure pattern I see is the leader doesn't share all of that information with the team in fear that doing so is going to make them a micromanager. So for example we're starting a brand new project, right? And we need to pick a cloud provider. Other parts of the business are like all in on Google. And I leave that information out because I want to make sure that the team
feels no restriction to evaluate whatever vendor. And they come back to me with a proposal of like, okay, I think this should run on AWS. These are the regions that we're going to use blah, blah, blah. And then I go, oh yeah, I'm just not comfortable with that because I know we're going to get pushed back with x, y and z because we're using Google over here. That would have been really great information to know at the start. And including that information in your expectation doesn't make
you a micromanager. It's just giving your team what's necessary because now they wasted all this time for a solution that's actually not feasible. What you could have said was we're using Google everywhere else. And if we want to pitch AWS, we need to have a really, really compelling reason. So if you're going to come back to me with a recommendation for AWS, I need to know like, that it needs to be like defendable. Otherwise, what I want to know is like, what's the best possible
thing that we could do with Google? What are the limitations? What does it mean we can't do? Is it mean we can't deliver anything? What's the situation here? What's your recommendation? That is such a clear expectation. It's setting your team up for success. They know exactly what the constraints are. You're not a micromanager. You're just telling them what they need to do to get the stuff done. The first scenario is often what I see leaders defaulting to because they don't want to,
they don't want to restrict. But actually the constraint is it's just a fact of life in the business. What I'm noticing here is for a leader to be able to effectively do that. There has to be a little bit of reflection on their side to like define that success or what that vision is. Do you have any thoughts or recommendations to help folks ahead of those types of conversations gain clarity on what success looks like or what type of vision is that they want to help support the team to achieve?
This sounds so dead simple, but just take 15 minutes and think about it and write it down. Because there are few leaders who have more time than they know what to do with, of course. But there's even fewer leaders that will make the time to be deliberate about what results that they're looking to see. I think a lot of, again, a failure mode, a failure mode of a lot of leaders
is the path will reveal itself as we start the work. And front loading or taking time to be deliberate about setting an expectation, thinking about the outcome, but also the non-outcome. And so I often frame this as like the floor and the ceiling of what you want to happen.
We often know the ceiling of what we want, but we don't really think about what the floor is, or we don't think about all the ways that someone might interpret our expectation and fulfill it based on their prior experience, but absolutely not based on what my expectations are. And just a moment of self-reflection and writing it down and sharing with the team can prevent probably 75% of things going down the wrong way. And there's still going to be 25%
that you got to solve in the moment, like make that audible call. It's way cheaper to do that at the beginning than it is when something's already been built and you're sitting in a demo meeting saying, this isn't really what I wanted. This isn't really what the company wanted, or this is going to be hard to defend to whatever VP who has some certain association with whatever is, that's all stuff that you want to surface at the beginning. It makes me think that often the
most profound truths are the simple ones. And what you highlighted where there are few people who actually are deliberate with defining the results that they're looking for, I think to me just highlights how simple it can be to differentiate and to really help guide your team in the right direction. That really seems like I wrote down that as a note in all caps. It's going to entirely change our approach for my next conversation coming up in a little bit.
I'm so glad to hear that. Tying this conversation back to productivity metrics and measuring development team performance. One of the biggest missing pieces of almost every org is that they don't take the time to think about what does productivity mean for our organization. Does productivity mean more work out the door? Does productivity mean higher quality work? Does
productivity mean more impact on revenue? Is it quantity? Is it quality of work? They just don't think about it and they're looking for a checklist of metrics or a checklist of something to say this is going to make our team productive. But having just that conversation is so essential because as it turns out and there've been studies on this, developers define productivity
generally quite differently than leadership defines productivity. Developers are in the day to day, they're looking at things like activity data they want to feel productive and closing PRs and like feeling like they're moving forward. Whereas leadership tends to care more about things like impact on business or other things. And when you have then a conversation about productivity with both of these parties, they're talking past each other because you haven't actually talked
about what you care about when it comes to productivity. And then we get into this like you're spying on me. Why are we keeping track of this thing or why are you tracking a metric with the I feel that I can't impact at all? That's often another failure mode. It's like we're going to start tracking user adoption because we care about the impact on the business and then an individual developer sitting there in front of their keyboard thinking, well, I'm not choosing what we're
building. Why am I being evaluated on user adoption? This feels so unfair. So, you know, I would say involving your team isn't like a get out of jail free card when it comes to building trust because there's still ways to lose trust when the conversation is framed incorrectly. Oh, Laura, are you ready for some rapid-fire questions? I am ready for some rapid-fire questions. All right, let's do it. What are you reading or listening to right now? If you open my Kindle, I am reading remarkably
bright creatures, which is about like an octopus. It's very, it's fiction. I really read fiction, but to balance that, I'm reading like a huge backlog of ACMQ papers on like all sorts of things related to development, productivity, computing, etc. I'm also listening to this podcast, Will Killie, which I highly recommend. It's about infectious diseases. And I finally finished watching Loki, which I realized like I'm pretty late to the game, but I have small children. So I'll use it as my
excuse. I love it. I just finished up Loki as well. Thumbs up. It's so good. Yeah. Okay, that's great. I did think it was like one of the best. I agree. I totally, I think the premise is just exceptional. I love being stuck in a giant bureaucratic environment, and dealing with big bureaucratic problems as like the conflict for saving, you know, the universe. I think that's just like such an unexplored
storyline. Rappifier question number two, what's a tool or methodology that's had a big impact on you? Containers 100%. I left my corporate development job to join like an incubating tiny startup within another corporate, but like working on open source tooling for this thing called Docker, when it was just like right after Docker was introduced at PyCon. Like it wasn't there wasn't any tooling around it. And so doing that work inside the container outside of the container really
changed my life. My husband met me at DockerCon. He sat next to me at a talk, and he remembers that interaction, but I don't. So I always said he met me at DockerCon, but I didn't meet him there. Some of my best friends have come from working with containers, and I'm just like I'm very grateful to that whole project. You know, who knew the Linux kernel could just provide so much, so much joy. I love it. What is the trend that you're seeing or following that's been interesting or hasn't
hit the mainstream yet? All right. I think in I think it's going to take a while like two years might even be too quick, five years, 10 years, but a much bigger emphasis on carbon emissions in computing, not just about like choosing your cloud provider, but also analyzing the memory footprint and just resource footprints of legacy applications, for example, and having environmental sustainability as an argument for refactoring because you're able to run it on X percent smaller
infrastructure, whatever. I think there's also going to be some like green clouds or cloud providers that are a little bit more fringe that are really focused on sustainable energy. I think that's coming. It's going to take a while. I think so. I love this trend because I think like underneath this are like a handful of like business ideas that engineer leaders are uniquely positioned to help cultivate. So we can cut that out. 100%. 100%. Something that you're logging in the back of your head
for like a future project, but oh, free startup idea, free startup idea. Last question, Laura. Is there a quote or a mantra that you live by or a quote that's been resonating with you right now? So one thing that's resonating and I'm actually writing a whole blog post, maybe a blog series comes from our conversation prepping for this, which is measure for change. And if you're not measuring for change, what are you measuring for surveillance? Something else, measure for change. So those three
words put them in a sky writing. But aside from that, you'll hear me repeat this all the time. Don't have us two things. Whole last one thing in the immortal words of Ron Swanson from Parks and Rack. A fantastic way to close both previewing a powerful blog post that you're sharing and ending
with a Ron Swanson quote. Thank you so much for joining us. And I think really like for me, providing so much clarity around the gap between the outcomes that people want and the way to help harness motivation in the right way in the tap into some of the human psychology to help drive that type of change. And I'm really excited to read that blog post about measuring for change. I think that's going to be so powerful. So I look forward to it. Again, just want to say thank you.
Yeah, thanks for having me. I really enjoyed this conversation. I hope someone is out there listening and thinking, wow, I've been thinking all of these things. And now I have this conversation, this podcast, a point to his validation for what I'm thinking is the right way to think about things and share it, use this as leverage to get your vision crystallized and to get your vision out there.
I think it's a great thing. Absolutely. And this is just like a final a final plug. Like if you are not following Laura on LinkedIn or other platforms like with the thoughts and insights, like I learned so much from the things that you share. So if people aren't following the things that you're doing, like this is a huge encouragement because every time that you post or distil or deconstruct in a dress, especially a lot of things around measuring productivity, but everything
beyond it, like I learned so much. So this is just if you're listening, you got to follow Laura. Wonderful. So nice to hear that. You very rarely hear the human one-to-one impact. So that made me a thank you. If you enjoyed the episode, make sure that you click subscribe if you're listening on Apple podcasts or follow if you're listening on Spotify. And if you love the show, we also have
a ton of other ways to stay involved with the engineering leadership community. To stay up to date and learn more about all of our upcoming events, our peer groups and other programs that are going on head to sfelc.com. That's sfelc.com. See you next time on the engineering leadership podcast.