The Misalignment Tax.

0:08 Welcome, and what this talk is for

Mannan So welcome, everyone. Korey is a Fractional CTO/CIO and Strategic Advisor who specializes in something most companies don't even realize is costing them: leadership misalignment. I'm personally very interested in this because I feel all of the large elephants, the IBMs, the BlackBerries of the world, fell from where they were because of emotional disengagement of the leadership. So I'll stop there, and with that, all yours.

I appreciate that. That's exactly right. So as Mannan said, I am Korey Mercier and I specialize in Herding Wolves. I really appreciate you all coming to my talk, and what I'm really hoping is that this will allow us to have a longer conversation afterwards where I can hear all of your war stories and learn some things from you as well. So I'm not here really to talk about misalignment per se.

You all know it's a problem. What I'm hoping you get out of this talk is a reframing of how to approach misalignment within particularly the product and engineering relationship, but there are always other aspects to that conversation, and some ideas on how to resolve that.

1:25 A launch nobody could put a date on

So just to give you a little bit of an understanding, here's an example from many years ago. I was working with a small engineering team, relatively new, very senior engineer leading the team, wasn't as business focused, very much focused on making sure that his engineers had what they needed. Had a product manager who had been brought in to help drive the team forward, and they were working on a product launch.

So the product was essentially for the energy sector, working with industrial control systems. It was an inventory management system, and it had a lot of moving parts. Had a technology partner that was involved in actually doing the inventory identification process, and the engineering team was doing its thing. It was building the product. They thought that they were meeting their deadlines, but senior leadership was not happy, because the product manager could never get an actual deadline out of these people, and the engineering team didn't understand that the deadlines mattered.

So the product manager was trying to get a launch together. They actually had a conference that was coming up, and the product was nowhere near ready, and the engineers were focused on things like elastic scaling and some of these issues, and they were running into scaling problems. And every time you asked the engineers what the issue was, their response was always the same: this is a discovery process, we don't know how long things are going to take.

Meanwhile, we had a salesperson that was going and talking to prospective clients and coming up with product features and deadlines and timelines that were not based on reality, had not been vetted. And so we had a distinct misalignment between all of these different parties, and so the CTO brought me in to help mediate between all the parties and try and get things moving together. And of course where I spent most of my time was in understanding the context from each of these parties' perspectives.

So what does product think is going on? What does the engineering manager think is going on? I actually spent time attending meetings with prospective clients with the sales lead to understand what he thought the product was and when it would be ready and all those kinds of things. So it was a lot of effort, and I learned a lot from that engagement that I'd like to go through here, some of my learnings from that.

4:01 Why it’s a tax: invisible, recurring, compounding

So most people think of mediation as, you go in there and you just tell people where they're wrong and make sure that they understand each other's sides of the view. Well, that's true to an extent, but that's treating symptoms. The actual problem is structural, and that means that you end up paying for the structural misalignment in terms of what I like to look at as a tax.

It's invisible. You don't understand the costs while you're in it. It's recurring. Every single sprint you're falling further behind, you're having to deal with misunderstandings of what those priorities were, and those priorities would shift from sprint to sprint. And it would compound, because as this went on, sprint after sprint, leadership was getting more irritated, product was getting more frustrated, engineering just didn't like being told that everything they were working on was the priority, because they had a distinct vision for how things were moving forward.

And so this compounds over time and it drives a lack of trust between the individual parties involved. So one of the things you have to understand when you're going through this process, when you encounter a situation like this, especially as fractionals, when you walk in, it's almost never that there are bad people. Occasionally you'll have people that are lacking in certain experience, but the issue is usually that we're talking about different groups of individuals with different experiences, different understanding of how a product should be launched.

They're speaking different languages to each other, and they're measuring progress in different ways. They're on different clocks. So the product manager is looking for launch dates and release timelines; the engineering team is looking for the health of the system, because they're going to have to maintain this for multiple years. And so often there is no translation layer, and that's where I would say you all are being brought in as fractional CTOs and CPOs, to help resolve that translation layer.

6:13 Where the tax lands, and why the job is translation

So one of the things that you'll realize is that this tax shows up in multiple ways. You've got throughput issues. You have technical debt. You have changes in priorities that are going to have the engineering team working on things that the product manager doesn't really want them working on, which leads to consistent misunderstanding. So you go into a sprint retrospective and you realize that everything that we committed to is not quite what we were getting done, because we encountered some problems along the way.

And so, in the age of AI you can write code fast as anything, but that may not be the right code. And so we're getting into this trend where we can just throw away code and rewrite it and it's okay. Now, many years ago that wasn't quite the situation. You wrote code, and it was a real problem, because that was time – serious time. And so at least that part is getting a little bit better, but what you end up with is all of these branches that make it into the production code that don't really belong there.

And all of this frustration builds into a lack of engagement. And so what you end up with is a feeling of psychological safety lost. And that is the most expensive part of this process, because when you lose trust between these individuals, between product and engineering and sales and senior leadership, that trust is really hard to get back, and every sprint that compounds until your best people will consider leaving, because they give up.

They're going, I know that this is an important part of this project and I'm not being heard, and so they'll leave the team or they'll disengage, and that may be a critical person on the team that the rest of the team is relying on. The product manager is struggling because, in this case, she felt like she had no ability to change the minds of the engineering people, because the engineering manager was representing the engineering interests and was talking about constraints.

And so that lack of trust was very, very difficult to get back. That's why they ultimately brought me in, to try and help solve this situation. But what you have to really understand here is that your job is not mediating. It's not just stepping in between people who are squabbling. Your job is to actually translate why the engineering team feels the way that they do, why the product manager has such a commitment to these timelines, why those timelines matter.

And the relationships that are breaking down inside the company extend out sometimes. You have potential clients. You have partners that you're working with that are starting to feel this concern, this pressure, because they are not having their promises kept. So the thing to understand here is that the solution is to develop a shared context between all these parties. There's a lot of get people in the room and let's discuss what the actual constraints are, why these timelines are important, why sales can't make promises that engineering hasn't vetted, why elastic scaling was important in this particular case.

And to also acknowledge that the CTO's job is to drive product and sales. They don't just serve the technology side of the business, they actually serve the business by driving those. You cannot solve all of these problems. What you can do is make them smaller, and you can make them visible. You can make people talk about it so that you improve the communications across all of these parties.

10:11 Signs it’s getting better

So where you see that this is getting better, these are some of the symptoms that you'll see that things are actually improving. So priorities stop arriving in the middle of a sprint. Roadmap reviews feel less like a battle zone, like you're in heated negotiations. When the engineering team says no, we can't do that, there's an actual conversation involved. There's a trade-off. We can't do it this way because of that, or we can do it this way, but this is what you're losing, this is what the trade-off will be for that.

But the biggest one in my opinion on this list is that disagreements start happening in the room and not in DMs, because what happens in relationships like this between parties very often is that everyone starts agreeing in the room – oh yeah, we can do that, no problem. And then the DMs start, right? The engineers get on Slack, or the product manager calls the CTO and makes promises that the engineers just agreed to, that now the engineers are going, you know, that really isn't going to work.

So all of those hidden conversations will start to reduce when people are starting to speak openly in the room. So, trying to hit my ten minutes here, what I have here is a list of questions to start our conversation.

11:34 Questions for the room

Where do you first spot the tax in a new client? So again, I'm coming from a perspective of, you're walking into a team that's already underway, they've already got relationships established, and you're the new person that's walking in going, all right, how do I understand where those gaps are, where those taxes are. And so I want to hear from you all: what are the alignment issues that you have seen, and the most expensive taxes you've seen a company pay?

Where is that line between mediation and translation? Because there is a point where you have to stop treating the symptoms of that conversation and start moving toward, let's develop some shared context, let's improve our structural process, which might mean having a different way of viewing the metrics that everyone is measuring things by, so that we're all on the same page. And then, how do you make sure that alignment will outlast you if you are in there temporarily?

So I've got a couple of QR codes on this slide, one to my LinkedIn and one to my homepage, and I would love to hear from all of you what you have seen in your businesses and your engagements.

12:44 Q&A: it starts at the very beginning

Mannan Thank you so much, Korey. I think this is – you could stop sharing your screen for a picture.

I could do that.

Mannan I think this is a very important discussion that we need to perhaps have repeatedly. Sort of like every couple has its issues, every team has its issues. So we would love to open this out to Q&A. Who wants to go first?

Lingan Korey, I have one – I can go first. Korey, what I have seen is that this is such a real problem. I've – not only as a fractional, but even in my prior roles leading teams – like you said, it's a tax, it's a hidden tax, and it holds a lot of folks back. I think where I've seen this surface, though, where people don't really recognize this initially, is the very beginning of the project, of having clarity as to what needs to happen.

We generally start off and people make commitments or have expectations and then they haven't really thought through things, right? So the product team's kind of having some idea and they're like, oh yeah, we'll – this honestly happens at the very beginning, but where you feel it is when the rubber hits the road, because all those assumptions that were not tested tend to get that tension going when you get a deadline, or you have a customer, and then now you're looking at stuff and he said, well, I thought I was building a box, but I really wanted a circle, and all of those things kind of come into play.

And then it's that lack of clarity, and then also the lack of understanding of the challenges that different disciplines have in that collective mission or goal, right? Engineers many times don't want to go redo work. Product folks think that it's super easy to build something. And so you have this very interesting gap. And that's what I've seen, and so I see that it starts at the very beginning, but not many people really think about it or even notice that.

Yes, I think that's exactly right. The product manager absolutely has a huge role in this, in making sure that the vision she has, the vision that the leadership team has, the vision of what the sales team thinks they're selling, is crystal clear. I completely agree. The conversation does require both sides to explain their sides. Both product and engineering in this case have an absolute need to communicate their sides of the issue.

And the engineers often aren't able to communicate the constraints that they're under in a way that product understands it. And that's where part of the problem is. Their incentives are different. Their communication styles are different. The words they use are different. The way they measure themselves is different.

Lingan Yeah, and I also think that it kind of gets exponential depending on the leader. You see, at the very top you can have a leader who is either inclined more on the product side, inclined more on the tech, or who has the right balance. Usually, when you have a leader who has the right balance, they tend to drive all the different divisions or groups toward that common goal better than if you have a person who has come from the product side, or come from the tech side, or come from the operations side.

And then that thinking – there's always a bias toward a certain aspect, and this tax tends to grow.

Completely agree.

16:58 Emotions, disengagement, and trust

Mannan I would – I wonder if it's really about just the leader being product or sales, or being biased toward something else, and – I think this is a universal problem. And as I said, every couple has it, every set of parents and kids have it. And I think the fact that we don't – we need to understand this is sort of like cleaning the kitchen. Dishes need to get done every day, and if you do not have a cadence around that – and, Korey, thank you, I'm realizing I need to do this more with my team too.

And I think this is such a big problem. This is why the large companies lose out. I was at a course last year at Stanford with a bunch of executives and we had these organizational behavior groups, and I asked them, like, all of these large companies that died out – it's not like they didn't have enough money to hire McKinsey, they didn't have enough money to hire the top university professors, PhDs.

Sure.

Mannan And it's not like they weren't super smart to begin with themselves. I'm curious – I feel like there's a huge emotional angle to this, despite all of us having different ways of communicating and different incentives, where once that emotional disengagement starts, Korey, what you said about compounding starts –

Mm-hmm.

Mannan I feel like when people start getting disengaged, whether that's in a couple, in a family, or in a team, that's when leadership doesn't have a full idea, because they're just like, yeah, who cares, I don't care, let him do or let her do what he wants. Can you speak a little bit more about that? Also, is it really just incentives? I've seen emotions weigh in so much.

And I feel like that's a discussion we again bring to the room and say, oh yeah, emotions are part of the environment – and that's really not optional.

No, emotions are everything. I think you're spot on. The reason I gave psychological safety and lack of trust its own slide was for exactly that reason. It is what it's all about. Because – I was reading a little bit of Michael's comment over there – the why things happen is because they have different incentives, different timelines, different language, different ways of communicating what's important to them. But the end result is a communication that lacks clarity, that lacks transparency.

You end up with people who get so frustrated by either not being understood, or by feeling like they're repeating themselves over and over again, that it reduces the trust they have in the people that they're working with to hear them, to recognize their value, their worth. They want to feel that they're on a team that recognizes their worth. And so when they run into that, that frustration causes them to disengage.

That disengagement causes them to not go above and beyond. To not push for something that they know is important. You know, maybe the engineers really were on to something, saying hey, if we don't nail this scaling problem, the entire application's going to fall apart, and this is our product, this is our reputation on the line. They don't want that. And the product manager may go, my customer doesn't care about elastic scaling, right?

They care about a product that will come in and do a good job of inventorying their hardware and letting them know when there are patches available and all of those. They care about the product features. So they're talking past each other, and that leads to a lack of trust and engagement. And once that starts, that compounds, and that makes it very, very difficult for any of the parties involved to get what they want out of that relationship.

21:10 Front of the house, back of the house

Mannan I'm going to hand the mic to Ying, and maybe we need a part two where you share some of your magic sauce or stardust on what you do to get people more interested. Yes, Ying, over to you.

Ying Sure. So I was just going to say, I really love the analogy of speaking different languages and not understanding each other, because as a bilingual speaker myself, language isn't just language, right? Language comes with culture and expectations of how you actually say certain things, because it means different things, right? So I feel like this problem that we're talking about, it's being magnified now that AI can allow product people who are typically not in the build process to make things.

But this is where I feel like I'm understanding this misalignment more and more, and appreciating the fact that we all just need to take the time to understand how we actually need to communicate with each other, and then what is the impact of what we do front of the house – you know, if we're thinking about a restaurant, front of the house versus back of the house, both of which need to serve

Right.

Ying the customer, right, just from a different vantage point. And the challenge that I have is most of the product teams are focused on the business. They haven't taken the time – and I'm not saying this is everyone, but my experience has been some of the good product leaders haven't spent a lot of time getting to understand how things get done. Now that you've done some vibe coding – I'm sure most of us have done some vibe coding – you understand the tax that comes when you make a change on your requirements, right?

So when you try to go to the perfect and you build the full application, oh God, you forgot a module, now you have to make a change. Okay, what happens on the back end of the code? Are you refactoring the code, or are you actually rewriting the code altogether? So I feel like if you don't have that kind of appreciation and investment up front to understand how decisions get executed – and I'm being a little bit mean on the product side, because I'm primarily on the product side.

I'm being a little bit mean to the product people. The advice I give to the product team is, you have got to have an understanding of how the technology works, how your decisions actually impact the engineering team. It's not like they're trying to be a pain in the butt with you. They're just trying to minimize the rework that comes when you have to keep up with the business needs as they change.

So I would say, totally agree, I love the description of it being a tax, because – again, being a dork, I'm talking like vectors – when you have misalignment it's like wasted energy, right? And wasted energy from a business standpoint is tax, right? You're paying extra effort that you could have spent on executing. So I know that was like a ton – thank you, I totally resonate with what you're talking about.

And the advice that I typically give to my customer is, you guys have got to understand how your actions impact each other. Spend a day, understand, follow the lead, like how does this thing get translated, understand the underlying technology. I'm actually on the opposite side when you said, oh, you shouldn't have to worry about elastic scaling. In my business I do regulated SaaS. Single sign-on – it's a big deal, right?

Because you need to understand as a business leader how you should best approach single sign-on, right? And again, a lot of the business leaders would be like, oh, that's a technical decision, you know. Like, we have CISOs and so on. I'm like, not if you're selling B2B SaaS. Do you understand how they need you to show up in terms of single sign-on? What is the requirement that they have?

And so, anyway, I'm going to stop. But thank you. It's nice to meet everybody.

Thank you. No, that was wonderful. And I think your analogy that you started with on the language is spot on. There's a translation – you mentioned being bilingual – there's a translation that goes on in your head. And that's what both sides of this conversation need to do. The business person needs to think about things from a technical side. Why are the engineers considering these things to be important?

Why would my customers care about some of these things that the engineers are telling me about? That translation's critical. And you mentioned the restaurant analogy. Love that. Front of the house, back of the house. How do they succeed at both serving the customer? They've built a system. They have communication. They know, oh, this table has a food allergy. That's critically important information. So they have a method for doing that.

They don't just pass the buck through the window. It used to be that people would talk about doing something and then throwing it over the wall to the other team, and how bad that is. Well, the reason that's bad is because the communication's not actually happening. You need that window to be able to pass those messages and those communications so that each side receives them properly – not just that you're sending them, but that each side receives them. So I love that.

26:46 “Technical” and “non-technical” as status words

Mannan I just wanted to kind of ask the last question – and, no, I can go on for another minute with all of you. Is that okay? So, Michael's last question, and then we'll go into that.

Michael That's a good place to end. My big takeaway on this problem is, as I mentioned in the chat, it feels universal. It feels very much like every organization I've ever been a part of has some degree of this tax. Some are fatally toxic and some are mild, but they're all there. The question about what we do about it is important, and I think the question of where it originates is even more important.

And just to put one little thought on the table here: when we speak to each other across disciplines, the terms that we use often carry with them inherent assumptions about status. So one of the things that's a little pet peeve of mine – but everyone that I know of, almost everyone, uses the term technical and non-technical. I am non-technical, right? A lot of business people will say that, and they will say that proudly: I am non-technical.

And implicit in that self-own, if you will, is that it is not important for me to be technical, because I'm non-technical and that's okay. Now, a technical person who prides themselves identity-wise on being technical hears that and says, what, do you think my fucking role of being technical is not important enough for you? That's an implicit thing. Now, people use that language all the time and it grates on people from two different directions.

Technical people use that same definition – well, you're not technical – as a status indicator, which means that your product manager, or your business person, or your salesperson, the other people who you need to trust, are somehow beneath you on a status hierarchy. Same thing applies to your business/non-business, your sales, your customer-facing, your not-customer-facing. These ways we use of describing each other carry these implicit sort of microaggressions, to use that woke term.

But it's real, and it manifests. And so my big question is – in my experience of having to iron this out, establishing trust between these groups starts with calling that out and saying, don't use those damn terms, guys. You've got to understand that when you use that completely innocently, you're really pissing someone else off and eroding the very trust that we all agree is important here. So I'll just throw that out there as an observation. What do you think, Korey?

I think that's absolutely a fantastic observation. I completely agree, and that's actually a whole different talk that I find myself getting into a lot: unconscious bias. And there's another one in there on power dynamics. But the bias that you're calling out, the connotations, the words that people use, those connotations – so I mentioned this earlier about the restaurant. Communication is not, I am being clear with my words.

Communication is, I am using my words in a way that they can be heard and understood in the way I intended, right? So there are three parts to communication. There's the sender's message, there's how it's being received, and there's the medium that you're communicating through, right? Because I think we can all agree that text messages and email have a very different conversation than if you're on the phone.

That's why a lot of those conversations end up moving to DMs and Slack messages, when the engineers start actually talking about what they feel. But you're a hundred percent right. The biases between the parties – it's not just the words they speak, but it's their background, and it's the words that they use for the other people involved in that conversation. It is something that, if you are brought in to do that translation – remember I said it's not about mediation, it's about translation.

Mediation's important, I'm a formally trained mediator, but it treats the symptom. It calms the environment. But then what you actually need to do is come together and have a shared taxonomy, right? A shared language that you're using. I don't know that it's necessarily the best approach to come in and say, don't use those damn terms, just because I think that that's going to have people that are going to lose trust in you.

But effectively that's the conversation you need to have. It's, let's have awareness, let's have clarity around what terms we're using and what impact that has toward a perception of a status hierarchy, which adds to the strain and adds to the distrust and the disrespect.

Michael Well said.

Mannan Thank you so much, Korey and everyone. Sorry we ran the meeting over. I think this is quite a good place to stop. I just want to make sure that we always end on time. I think that's more important than starting. Thank you so much. Let's have a follow-up on this.

Michael I look forward to talking with all of you. Please communicate independently if it's of interest.

Everyone Yeah. Likewise. Take care. Bye-bye. Thank you. Bye.