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-flourthslash-elc today and save 20
$500 off your first hire. Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the Engineering Leadership Community. I'm generally 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. After surveying hundreds of engineering leaders, we've pinpointed the top 10 challenges engineering leaders are facing right now.
This is part two in a four-part series sharing some of the best insights from hundreds of ELC events, podcasts and conference sessions. In this episode, we focus on your team and the friction points that may be holding your team back from their full potential. And we get into challenges like how to increase velocity without losing quality. We talk about measuring productivity and creating needing full metrics and we talk about working with your cross-functional partners.
So let's dive into our first segment, speed versus quality. How do you balance shipping new features versus fixing bugs and handling tech debt? This dilemma is as old as time and almost always requires a constant re-evaluation of the demands of your business and product. Richard Wong shared their journey at Coursera and how they approached the speed versus quality balance at different phases of the company.
I wouldn't say that like speed and quality, they are diametrically opposite to each other. In fact, for many companies, it's part of a job description as engine leaders to design an organization, a process or system that allows to move both speed and quality at the same time. But from time to time, as the business evolves, we may be falling behind on one side and we did shift the balance to the other side.
I often think about engineering or engineering processes is like designing a traffic system. So think about a typical traffic system that when you actually go to Al Camino, VL or on one-on-one, they designed the system to try to optimize for two things.
Number one is to maximize the amount of traffic flow on the street. So everybody can get to their final destinations with minimal disruptions. But you also want to make sure they are at a certain level of safety. So maybe the traffic can move very fast, but you don't want everybody dies at the intersection.
They collide with each other. This is pretty much what happens in the engine organization. On traffic system, you define the set of rules on like you drive on the right side of the road, you flesh your signals before you turn and you move when the light is green and stop when it's red.
And engineering, you do the same thing except the type of design is slightly different. So you have design with vehicle, view, unit testing, setting SLA for your services. That's what we call kind of processes here. But even in the real world, the traffic system is not static. Right. So think about this. Right. If there's a city, if you actually live in a town with only a couple hundred people, there's seldom there's any cars on the street, usually.
The amount of regulations or restrictions are pretty limited. Right. Many of the intersections, probably uncontrolled. There's no speed limit. Why because in deck out settings. I mean, the stick is really low in terms of the chance that you call an accident that has like big damage to anyone. That is the same thing I think for an early stage company that when I joined Corsair, Corsair was a serious B company. We were much smaller than what we are today.
At that point, what you basically do is just you want to run fast. You allow people to go into different directions and try to figure out as much as possible on what is needed by customers. In fact, the reality is like 90% of the startups. They run out of money before to get the right idea or even for successful startups, right 90% of the ideas don't work out on the first trial.
You better not to spend too much energy or time thinking about scaling or building a perfect product to start with because most of these ideas will get from away. But you know that when things change right over time when your town becomes more populated at some point it becomes San Francisco or New York City, then you have a much more limitations, right.
You have a stop sign, you have traffic lights every 100 yards. You put even emphasis to maximize the balance between speed and safety. So I think in a growth company like what Corsair has been going through is constantly about like redesigning our traffic system like in the city.
Maybe when the traffic doubles every few years when the number of people double every few years. Sometimes it's more effort, but sometimes it's because there's an accident. There's some issue. Back issue happened that pushed you for that change, right. So it's about like what is on the example. I mean, we definitely have that kind of challenge about three to four years ago.
When we started scaling. So when I say when we start scaling, it was a situation that we had build our enterprise business. We have built a degrees platform on our system. So at that point, unlike the early days, many users were using Corsair just as a hobby, right. They enjoy the learning. They just come here whenever they have free time.
Now, Corsair actually became the platform that our enterprise customers are relying on to up level their employees and organizations. And universities are putting degrees on our platform and final exams on our platform. It was a turning point for us. Now these customers, they have much higher expectation on our product functionalities and qualities.
And at one point, we were too reactive in thinking about quality. We just like follow the old way of like keep shipping, shipping very, very fast without thinking too much about the experience and the quality. And very quickly, you hear these customers, they shift the conversation from about the one more features to talk about their frustration on our platform. They said when I try to do this, it failed, it errors, it doesn't work.
They give me incorrect information to the point that it became a major business risk for the organization. Each quarter at a company, we actually talk about highlights and low lives, right. Three, four years ago, there was a couple quarters. The major business risk for our company was because of these kind of frustrations from a customer about the quality of our product.
It was definitely very stressful as a head of engineering and try to manage through the situation, but the fact that across leadership team, a strong alignment was going to shift the balance to more focus on quality side was a great outcome that I can't ask for more. So once you have that, it's much easier for you to actually drive the level of execution across organization to fix the problem.
What's great about the speed versus quality challenge is that so much of this dilemma is context and priorities dependent, but that's also what makes it so hard to resolve. So here's another great example to help you expand your perspective, Fatima, Ala Visita and Andrew Fong had a conversation at ELC annual 2022 that explored specific processes, operations and measures that help them focus on the end impact and balance and navigate this velocity versus quality conversation.
Fatima, can you just define velocity? How do you think about velocity? I think there is a very specific definition for velocity in agile development, which is mostly based on percentage of completed work from what you committed. Some people measure it with story points, some people measure it with percentage of completed tasks. I usually do it at a higher level and more lightweight.
But actually, it's not just a very important metric, like average velocity and trends in velocity and all of that, but actually stepping back, I think what matters is delivering value to your users with a good cadence and velocity while it's a very helpful metric in showing how your team is operating and all of that is not a complete picture.
And you need to step back, think about your OKR processes, shipping cadence, how frequently are you actually launching, and then velocity would be a very helpful input into that. So when you're doing this planning, you have all the sprint planning going, how do you keep teams out of the weeds thinking about just the story points and just thinking about that from a velocity perspective?
How do you get them to pull, how do you pull them up an altitude, right, to what you're getting at, which is ROI for the user? So we dropped to actually set goals for a sprint at a higher level than tasks. And we have very specific definition for what these goals needs to be. Usually they need to be very in result focused, ideally something that we launch. And ideally, these are team goals, not individual goals, and they're prioritized.
And then teams are responsible to go and work on those and we actually kind of look back and OK, what percentage of those goals we achieved and expecting teams to really commit to their highest priorities. So if you need to stop working on lower priorities, move people to deliver on those higher priorities, do that.
I was just going to ask that. So what's your technique? How do you get people to move from project aid or project B? How do you ask them to do that in the middle of a sprint without them getting sad, upset, you know, whatever, whatever emotion they may feel?
Yeah, so this is we try to do this at the smaller scale. So with the smaller parts and I mean moving people from one project to another is also something that you need to think about case by case. Sometimes it makes sense. Sometimes it doesn't sometimes sprint is too small to even develop in context in that the new area.
So definitely depends on the case, but the spirit of it is we want to as a team commit to a few things that are shipable and that are very resolved focused and really go and deliver on those.
Can you go one level deeper in the result focused? I've historically found it's very hard to think about something that's more than binary like a zero one. Did I did I do it or did I do it? I'm just curious show of hands. How do you feel that when they do their planning as well? OK, there's no amount of people.
Yeah, so that actually that's actually what we try to do something that is very binary. So when we look at it, we can say we did this or we didn't do this. So maybe if it's part of a bigger project, you can think about one flow within that project launching that to even if it's not like launching it to external customers launching it to the team or making it available for the rest of the company to play with.
OK, so if I tease apart where you're saying there's an aspect of the velocity is focused on the customer, not velocity just for the sake of moving code into the code base. Exactly, exactly. So that's the point I was trying to make that velocity is like looking at this kilometer, definitely tells you how fast you're going doesn't tell you whether you're going from point A to point B. So you need to make sure that you have ways to track that as well. What are the ways you use to track it?
OK, ours for the most part, but I mean, the same problem can exist at OKR level, right? So it's important to just like a step back and think about how frequently are you launching maybe even develop a list for yourself of like OK, how frequently are you launching is it monthly is it quarterly. And what's the quality of things that you're launching and all of those things and just track those things.
So given your experience, it's sort of the larger tech companies and these like high growth startups. How do you think about the shipping cadence? Like do you have in your mind or you think about it quarterly monthly? What's the what's the optimal? Like how do you arrive at that? I don't know if there is one perfect answer for this that applies to every industry or every stage of the company definitely depends on the stage and on the product.
You, for example, we're talking about that you're building toward this region. It might take some time and you're all heads down working on that. There are sort of that are actually going a little bit more about trying to fight market fit for them. Hopefully shipping cadence is every sprint for us somewhere in between. We try to have your bets that might take actually with longer, but also try to balance that with the smaller things that we can get out monthly cadence to customer.
So they can actually improve the product on an ongoing basis as well. 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 working 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.
Let's transition to a new challenge, measuring productivity and creating meaningful metrics. Everyone right now is seeking to understand what drives their team's productivity. This is a conversation that comes up all the time and it seems to be the unifying thing behind engineering leaders everywhere. So let's start with metrics. Randall Kutnik had a fantastically titled talk from ELC annual 2022 banish bad management with metrics that don't suck. I told you, it was a great title.
He examined some of the different real world examples of different metrics that can help you better achieve the different outcomes that you're looking for. We want to build healthy teams that are consistently delivering customer value. I hope so. Is anyone out here not just looking at this and going, I don't want a healthy team? No, okay. So we're all an agreement on this. This is difficult, but the real hot take of this talk is that leadership can be really easy just as long as you don't care.
If you don't care about building healthy teams, you can just run them ragged. If you don't care about delivering value, well, then you don't really need to do anything at all. And a lot of people out there. And first off, if you want it to be really easy, you don't show up to conferences. I'm not talking about you.
I'm not trying to give anyone here side eye or anything like that. You all care, right? That's why you're here. Of course, if you don't care and you just want to be a manager and you just want to go on autopilot the whole time. It's like, I, you know, just run things. I don't want to think this is less hard. I don't want to do it. And all of a sudden, those things that make leadership hard, taking a long time to sign out of the decision worked.
And even then you have, well, did it work? What's going on? Become great assets. You can just throw up the smoke screen. If you ever worked with someone who's just like, I'll shuffle this around. And then if you know, figure out who the mouthiest person on the team is and put them on a pip. And that'll buy me six months. And then we're, you know, under resource. And he's been another six months recruiting hiring all that.
And oops, I got a job off for any of us. Somewhere else. Bye. What do we do about this? Because this, this sort of auto the autopilot manager out there really harms our ability makes we care really harms our ability to get things done.
Because first off, our team has to make up for their team slack. And even though even when we get people, excellent team members, excellent engineers, they've been trained by auto that if they ever bring bad news to management, and they're going to be the next person on the pip. So again, makes it harder to get that context too. The question is what do we do about it? And the answer is already been spoiled by the title, right?
But not those metrics, because I know a lot of people think about managing my metrics and what they're thinking about is once again, we're going back to auto. Managers and autopilot, they love metrics metrics are great. Now I don't have to think anymore.
All we do is like, let's see, we'll make data driven decisions. Whoever fixes the most bugs, whoever closes the most jurid tickets, they're the best engineer in the team. The most productive will define productivity, close the most jurid tickets. Great. Top engineer gets promoted. Everyone in the middle, you're fine. You get a 3% cost to living raise. Bottom person will fire them for performance issues.
Management, hooray, we're done. And the thing about these sorts of metrics is like, okay, yeah, so a big hot take if ELC don't measure productivity by number of jurid tickets done.
The thing about that sort of metric is auto, you want to manage on autopilot, all of your metrics measure individual productivity, because you want to stack rank your team in order to not have to think, which isn't how software works. You just killed all collaboration on the team. I can help you out or I can get more tickets done for me.
I can spend more time taking my tickets, breaking them up into smaller tickets to make my number go up. So instead we need to remember software as a team sport. How do we measure a team? How do we measure a team's ability to collaborate and execute without ruining the entire team's ability to collaborate and be productive in the process.
So there's a couple ways to handle this. Has anyone here heard of Dora not the explorer? I have a three year old at home and very familiar, but Dora, Dora the DevOps and research assessment group. There came out. I was looking this up and I realized that that was almost a decade ago that this effort started and we've been doing this for a while.
But yeah, the Dora team went out and said, OK, we want to measure a team. We don't want to want to have auto metrics and they put out surveys. They got access to Google and tens of thousands of engineers and teams there.
And they said, what makes a good team? And they found four key metrics that made for a team that was executing well. The first being how long it takes to go from an idea to production. So known as that issue cycle time. Then how often are you shipping to production? Because if you don't change things very often, you're not executing very well. How often do those changes fail? And when they do fail, how long does it take to fix things?
So we have a really good image of a team that was working together, executing efficiently and just consistently delivering value. Now good. That's one of our three things is consistent execution. That's one third of what we want. And the good news is the team behind Dora kept at it and kept working and continued to do research and figure things out and came up with the space framework.
And the Dora metrics is our team executing well and then space attempts to answer is a do we have a healthy team because you can execute a lot by burning out in six months later, you're not executing well at all. And so we expand that and we start asking questions like are you satisfied? Do you like your job?
Are you happy with that? Do you feel productive? We continue to look at things that Dora Park cares about. Are you deploying well? Do things break often, but also look at collaboration things. How are people reviewing each other's PRs are, you know, you get a lot of pair programming and things like that. Now this is two of three.
So now we know do we have healthy teams are they consistently delivering with one question that remains is what they're delivering valuable because I'm sure this has never happened to you that you've been looking at your organization and realize there is a team that is consistently delivering in a healthy manner, something of absolutely no use whatsoever.
You realize it is no correlation with the goals of your organization and the authors of the door report and the space framework actually have something to say about this because they say there's a lot of things that are going on, a lot of things that developers do and they say it's almost impossible to comprehensively measure and quantify all of the things that a developer may do in a day or work on.
So they think it's impossible. Let's talk about how to do the impossible because what we're talking about is alignment. We want all of your teams together to be working and focused in the same direction. So we need metrics. We have metrics that measure execution. We've metrics that measure health of a team. Now let's talk about metrics that measure value through figuring out our teams aligned.
And there's two alignment metrics. They have one key metric we call a full time equivalent because what an alignment metric cares about is what are you spending your time doing because it's really easy to game to your, you know, issues.
I can create three of them and then file them and fix them in the manner of an hour and it's possible to game, you know, okay, number of deploy you want to know how often I deploy great. I can just deploy a lot and just deploy little small things and that's generally good. But what you can't game what you spend your time on if you're an engineer you have 40 40-ish hours a week. What are you doing with that time? Are you working on Kubernetes? Are you working on making customers happy?
And as soon as I say something like that, everyone's like, Oh God, I don't want to do time cards. I agree. You do not want to do time cards. Instead, the good news is, you know, nowadays in 2022, we have a lot of different things on the left that we have.
We have we have Jira, we have GitHub, we have Pedro do we have Google calendar with a lot of different things that tell us what developers are doing. You can take all that data and just it and say, okay, give me all of the changes to a dearer, your ticket of the linked pull requests, all of the calendar data, pull that in and I have a general idea of what people are doing with their time because it all comes time stamped. Okay, well, Randall opened this Jira ticket and then open to PR and has some commits associated with that.
So you generally know what I was doing last Tuesday and then you can take all of that data of all of these entries and throw some data science at it. You have data science. I'm not a data science person. I don't know the math. But if you crunch those numbers and say, okay, well, you did this many PRs and all that on these times, you can generally get an idea hour on hour of what people are doing.
One of the key things to know about metrics is we can only provide context. You know your organization much better than I do. If you have a heads up display to understand what's going on, then you can do your job better. But we can never if you start managing just saying, hey, the metrics is this. You've become auto. One of our case studies were a customer's job fight.
What I was a different doubled in size because they quadrupled in size in a year. He's not doubling size is bad. They're huge. They acquired three different companies. No idea what was going on. Bold on the data said, what are people spending their time on? Where are developers actually working and the answer was that dark support that we're talking about earlier.
I know that sounds evil, but it's just people trying to help sales and support coming in saying, hey, you know, engineer friend, can you help us out? There's this one one customer has this one issue and the engineers like sure I love to help half of the engineering hours were spent exclusively fixing little things for support and sales.
And none of us being written down now is leaders. They were like, we can't ban people helping other people. It's a terrible idea. Instead, they said, can you please write that down? And so the engineers, okay, good. You know, I can write that down. And they said, oh, well, all of these support requests actually evolves around this bug that we thought was low priority because no one mentioned it turns out everyone's working on it. Fix the underlying cost and all the support goes away. Sales loves it.
Sport loves it because hey, they're not getting complaints anymore engineering loves it because they can go heads down and actually focus on what they want to do. And of course, customers love it because they're not constantly inundated by random small bugs all the time. They ended up with 80% increase in throughput. Focus on road map, making people happy with new features instead of constantly manually fixing bugs.
So where should you actually focus to improve developer productivity? I'll be noted joined us on the podcast diving into exactly that he gave us a high impact place to start with the DevEx framework, which is a practical developer focused approach to give you clear actionable insights into what to measure and where to focus in order to help you improve developer productivity.
Yeah, in our paper, we're calling it the DevEx framework, but in actuality we provide two frameworks. So the first part of the paper focuses on providing a conceptual model or framework for understanding developer experience. And that's because developer experience, this isn't just something that's happening within this little pocket of research.
Developer experience is a trend happening across the industry. A lot of companies are trying to figure out developer experience. They're trying to define it, create charters around it. And so we wanted to provide based on our research, a working conceptual model that organizations can adopt in order to not try to reinvent what developer experience is, but start actually taking action to improve it.
So that's part one of the paper. Then part two of the papers of framework for how to approach measurement. This is informed again from our existing research and experience in trying to actually apply the concepts that we've learned through a research over the past three years.
We talk about how to measure. We, for example, recommend starting with surveys, but then also mixing qualitative and quantitative methods gathering data from systems as well. We talk about the importance of balancing objective and subjective metrics, balancing KPIs and individual factors and making sure that organizations are looking across the three dimensions of developer experience that we describe in the first part of the paper.
Taking a step back really, this is not just an encapsulation of our research, but really of what we're seeing in the industry, we include two case studies in the paper, but developer experience is something that is happening. This isn't just conceptual. Lots of teams are being formed around developer experience, see suites across the industry are focusing on debx at the sea level, focusing on it and optimizing it.
I think this paper is lending, you know, in a timely moment, when a lot of people are trying to figure this out and we're hoping that this helps people get started more ease. Do you have a favorite blind spot that these uncover that you might encourage people to look at for like a low hanging fruit area of focus here for some of these bottlenecks or levers?
It's obvious when you say it, but it's not something I see a lot of engineering organizations really raising the alarm bell on is requirements quality. It's just how clearly defined are the tasks that developers receive. And again, I'll share quick story when I was at GitHub, I talked with a director. He oversaw multiple teams and actually asked him, this was a little later when I got to figure out how to improve lead time.
Well, I better go ask all engineering executives across the company how we can do that. So I asked a director at GitHub, what would actually improve your lead time? He told me that he thought that the reason for their lead time was requirements term, meaning developers would begin a task and then halfway through the task they would realize up, we're not really building the right thing.
And then the PM comes in changes the direction of the thing that they're working on. They have to start all over and it happens all over again. So requirements quality is so important for not wasting developers time. You don't want to waste the developers cycles working on the wrong thing or pivot halfway through and have them throw away all their work. And so requirements quality is something that definitely was service in our research.
It's also something we're seeing with the organizations we work with be a consistent bottleneck and friction point. I love that. And I viscerally feel the tossing and turning of the mess the messy requirements there. And all across the different levels. I think that problem happens all the time and not only just engineering requests can be the requirement can be a personal task and same thing seems to change afterwards after start digging into it.
What are maybe a second assert to have more example like that? I think that's this kind of walks through of the bookings for example is what are the common points where productivity can be inquiry like we will optimize something that these two directing path on productivity. And so I think that's the direct answer to your question. But one of the themes from our research and our experience working with organizations is this tension around what to do about these problems.
I mean, if you talk to developers, these types of problems like the problems of developer experience are glaringly obvious to developers. They live it literally every day.
And so we have problems going solves and we see this with organizations that are talking about developer experience and claiming to make larger investments and developer experience and really what we found in our research and in our experience, the problem boils down to the fact that there's always this tension between feature delivery and all the other stuff feature delivery versus internal improvements or technical that or improving tools.
I think navigating that tension is a big challenge for frontline managers and middle managers who often see the problems on the ground that are inhibiting their teams, but don't necessarily have the authority or the capacity to shift resources to address them.
That's sort of this universal challenge. It's the same challenge that's existing around technical debt, but it really applies to all these aspects of development organizations. And that's one of the reasons why you see the pattern of organizations forming dedicated teams, dedicated groups specifically focus on developer productivity because they just completely separate the responsibility of feature work and enable network within their organizations.
Now let's talk about the cross functional relationship. We know most of us are operating in a world where resources are finite and we have to navigate the complex calculation and oftentimes competition for resources with other teams and we want to be able to better advocate for what we need, but we also want to better understand the context and the challenges of our partners so we can move faster and create better outcomes at ELC annual 2023 Barbara Nelson and Laura Faye shared a ton of great strategies for cross functional excellence between engineering and product.
Over the years, when I've seen engineering projects go badly and you know, admit it, you're all engineers. There are those projects that don't go so well when I dig into why it hasn't gone well. Nine times out of 10, the issue was there was some kind of fundamental communication gap between product and engineering, either engineering wasn't listening or product wasn't communicating well enough and the net effect was we delivered the wrong software or
in the wrong time or it missed the customer's requirements altogether. And so that's really what made me focus more on kind of what that relationship is now given example from real early on at one stage, I worked for a company called General Magic General Magic was a hugely innovative company, and I was commonly innovative the brightest set of engineers I have ever worked with, Barnum, we built technology that was so far ahead of itself that it was an ultimate business failure.
We couldn't sell it, nobody wanted it, we were miles ahead and so kind of from that, that really influenced my career from then on of being I don't just want to build cool technology cool technology is great. I don't want to build it if nobody wants to use it and so kind of lead to you Laura and kind of what do you feel makes a good product and let's start from there.
Yeah, that's a great place to set the foundation. So every product management team right there job in my view, their job is ultimately to create products that are valuable, feasible, usable and viable.
So valuable to the customer, this value proposition out there, there's a problem to be solved the customers are willing to pay for it is feasible and this is where largely where the relationship with engineering comes in like you can have a great idea and it could say, you know, oh, if we had product superstar that would solve the customer's problem, but it's just not really feasible or way too expensive to build or what have you usable stands to reason right it's got to be usable or it's not going to be successful.
And then ultimately viable viable for the business. So if it's a consumption subscription that it can continually delivered at a reasonable cost is going to generate a profit and that it can scale right. So that you can actually make a business out of it. So valuable feasible, usable and viable is sort of the pillars, if you will, that good product management team or product manager is going to be always thinking about in terms of putting definitions on the table.
So that's a great point. I think the partnership between the product manager and the engineering manager or two the two teams product management team and engineering team is what gives you the balance between all of those. So you know, they're the products that they kind of very engineering led their feasible, they're technically feasible, but it's not clear anyone wants them if you build it they will come.
There are things that are kind of you know, they're valuable to the customer, but it's not feasible. The thing costs a fortune. I've struggled myself on managing kind of cloud costs where you're like, OK, this is great. This is really cool, but I don't know how we make money out of it. And so getting that balance right is really critical and the product management organization have an enormous role to play.
And why don't we start from there, which is what what does product management do? What does it do? What does product management do every day? So the role, the role of product management is really, as I mentioned, to create products that are valuable, feasible, usable, and viable, right.
Their job day to day is working 360 right you've often heard, I know many of you may have heard, you know, the role of a product manager. If you Google mini CEO, the first thing that comes off as product manager, right. So really they're acting sort of as a proxy for the business in that regard.
They're working with customers, they're working with sales, they're working with support, customer success is a huge, I personally believe yet realized lever that product management has that as an industry, we're not leveraging as much as we could. And then of course with engineering, you know, tell you the story, my son is an engineer and staying in the family business.
He said, you know, I have this really good relationship with my product manager. And so we were sitting together the other day and we were working through some issues and I saw her desktop and her calendar was open. And he was like, oh my god, she's like double and triple booked almost every single hour of every day of the week. How can you possibly do that job and how can you possibly prioritize what you need to do to get the job done.
So that gives you one example, but there's so many pulls on a product manager in that sort of 360 scenario. And so making prioritizations and making decisions is critical to that role. They get to say know a lot.
Because as we all know, every release is an exercise in how to fit 20 pounds of stuff into a five pound bag. And so they are the voice very much the external voice to say, I know you want that feature, but sorry, not this release. Right. So they often end up not being everyone's best friend because of that sale support, engineering, depending on on what it is.
So I think the message there is they tend to be overloaded their spinning plates and really the good organizations, I don't say not come down to one product manager, but the organization as a whole, you know, if they have a really good way to do a value assessment, which is sort of their filter for does it make the road map or not or is this something that's going to propel the product ahead or not, you know, you've got to operate on on frameworks, but the role is it's a it's challenging at best.
But we all know good ones and we all know not so good ones, right? Yeah, it's really good to understand kind of what the product managers and product management organization are bringing to the table because it's important for the engineers to understand that too.
So the engineers bring a lot to the table to and there is a risk that you can have that the engineer kind of gets lost of being well, the product manager told me to build it so I built it. And so you really want to find a way that engineering see the value in their contribution, which is really important.
Which is kind of the how are we building what we're building and how do I ensure the thing is of high quality, how do I ensure it satisfies the customer needs, even though the engineer is kind of relying very heavily on the product organization to kind of in some ways give them the guideposts, give them the framework in which to deliver, but you really want to make sure engineering still feel a very strong sense of ownership.
So that's kind of where that partnership is so important so that you don't feel like they're just, oh, I'm building what I was told to build. Beats me, whether anybody wants the thing or not. And I think Barbara, you brought up a really good point recently, which was the skills match between product management and engineering, right? If you've got, you know, super experienced engineers versus maybe a relatively young team and how that plays out in the relationship.
Yeah, absolutely. And some ways I kind of view the analogy of kind of a relay race and passing the baton, you know, you have to come to meet the person who's taking the baton from you. And a lot of the kind of value in the relationship is really understanding where to come to meet them.
So if you've got a very senior team that are very familiar with the product with the customer base, often it'll be maybe a very technical product and they are the product user. Then you don't want the product organization spelling out all the minutia.
But on the other hand, if you've got a relatively junior team or a team that just don't have familiarity with the space, you may have to spell out a lot more of the details. One of the projects where I saw this issue, you know, in spades was I used to work for a company where we were delivering a Wi-Fi solution for business travelers.
And so our target audience was the business travelers, typically their patients for getting connected is pretty darn low. And so we were trying to develop a solution that connected to the world's Wi-Fi in a very smooth and seamless way.
And that is that is a really hard problem solved the developers that were building this solution weren't business travelers. So they didn't understand the environment in which this product was being built. So they'd make comments like, oh, yeah, if this is a problem, just reset the router.
Yeah, have you tried resetting the router in a four seasons hotel or on an airplane, you know, that is not an option. But this was where there was just so much lost in translation between the product manager kind of going, oh, they need to be able to connect to these networks and the engineers going, oh, okay, I know how to build a network connectivity solution.
And the thing completely missed the mark. Well, so in that case, we we'd really lost in the translation between the product team who knew what needed to be built and knew their target audience. The engineering team that knew the technology, but they just didn't come together.
And yeah, added to that. So as a product leader, I always emphasized the need to specify in context, what we call NFRs, the non functional requirements. It's easy for product teams just to look at feature function and maybe some of the external points. And often they don't always think about those things, but at least putting some guard rails around them. And we're talking about performance security reliability requirements, you know, usability requirements, things that are not okay.
And in this case, like the solution is not reboot the router and so on. So those become really, really critical. And many cases, depending again on the product, the relationship with engineering is critical because engineering can guide on what's possible to be done in many of those areas, but they can't lose face of the importance of NFRs.
I've worked with in the last five years with an advisory firm catering to, if you will, or meeting the needs of CPO's and that's one of the biggest messages in asking them, how are you doing specifying the non functional requirements for your engineering teams. And I will say, I don't know what the the experience is with this group, but generally speaking, they don't generally do a good job at that in my opinion.
Of the dysfunction between cross functional partners stems from communication and having a shared sense of priorities and context Jeremy Hendricks and joined us on the podcast and doven do several incredible tactics on how to align lead and scale a combined engineering and product organization. We got to do a ton of great tactics to help you create a shared sense of priorities and then address misaligned expectations between engineering and product.
I have a bit of a rule when I hire product people to start with and that is that a part of my process tests for the product person's ability to understand engineering ideally they've been an engineer at some point in their career history. But if not the kind of ability to understand the nature of the trade offs that people make, and I think if you don't start with that like raw capability, it's really difficult for product people to understand the nature of those engineering trade offs.
So I think that's the fact that this kind of thing accumulates technical debt and that kind of project, though not customer casing actually will help customers on the long run. The second thing is that I make sure that kind of both sides of that equation like engineering to product and product engineering that you get people to understand each other's list of priorities, which of course starts with having lists of priorities.
Not everyone has the discipline of saying yes, here is like force rank to the set of things that I think we need to do to make the products to see or force rank the set of things I think we need to do to scale engineering.
And taking both of those lists and pushing them together right saying no, no, there's actually a single set of priorities and having everyone sit in the room and really understand each other's points of view and it's not about making people agree with the other person it's about having that shared context.
And I'm sure that you have shared ability to reason about priorities under a world where there's really limited resources and I've found that exercise, whether you're doing it with individually contributing engineers all the way up to like CEO and like board members is a really effective way of getting people to kind of have that sort of empathy that's needed to make good decisions there.
Does that mean to the extent possible you would prefer make decision in the same room bring together both product and you're interested. They can have shared context absolutely so in the same room as much as possible and in fact, when I have like a number of teams in each of them has like a product leader and an engineering leader.
The expectation I set with them is like look, you guys are going to have different points of view and that's OK, but when you come to me, you either need to one have a really clear shared point of view on something because you've gotten this together.
A clear point of disagreement so that you know, we can tie break on OK, which one of these is actually more important right now and either one of those is totally fine, but a shared understanding of the facts, a shared understanding of the trade offs is sort of the floor that I draw on those conversations.
You mentioned, you know, sometimes the product opportunity like the bus comes and you can get on the bus and you have that opportunity. So one of the engineering leaders in one of our pure groups. Basically a PM left and he sort of had to subsume their responsibilities or assume their responsibilities. And the big question was like, I don't even know where to begin. I don't even really know what they've done.
What should you look out for or if somebody is starting from zero and they're an engineering leader and they are now taking over some of the responsibilities of the PM that was helping out. If they're starting from zero, what's your quick tips, where should they start?
The first quick tip is if you can get a hold of that PM and ask them what did they care about and why that context is gold like it might be wrong. Maybe the PM wasn't any good or whatever, but at least you like understand where they were coming from. And after that, I would say the most important things is go to talk with everyone individually and say, OK, you know, this person's now gone.
What are the challenges we really have? Like what do we need to focus on and what are we doing that we shouldn't be doing? Right. What do we most importantly, like what do we need to get rid of that word, just spending time on and go have it with everyone individually, not in a room because you do it in a room.
There's going to be group thinking and the rest you got to do it individually and then bring everyone together and say, OK, folks, this is what I've heard and I'm representing you correctly. And that both does the trust building piece, which is extremely important if you're going to kind of be thrust into that goal. And hopefully it gives you a good sense of at least the first cut like what's important and where does the time need to go.
What have been the most effective ways that you navigate speed versus quality? How do you approach productivity and creating meaningful metrics? How do you create effective cross functional partnerships? We want to know what you've learned and how you're tackling these critical issues. So send us an email or share a comment on LinkedIn and help us share the wisdom across the community. See you next time on the Engineering Leadership Podcast.