Show Notes
Andy and Mon-Chaio talk about the dreaded request for team performance metrics. Rather than simply agreeing to start measuring, we explore a different approach.
Opening quote from “Nonviolent Communication: A Language of Compassion”
References
- Explore, Expand, Extract – https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-expand-extract-6d4c94a7539
- Commandos, Infantry, Police – https://blog.codinghorror.com/commandos-infantry-and-police/
- SPACE Metrics – https://queue.acm.org/detail.cfm?id=3454124
- DevEx metrics – https://www.infoq.com/articles/devex-metrics-framework/
- NVC – https://www.cnvc.org/training/resource/book-chapter-1
Transcript
Andy: All criticism, attack, insults and judgements vanish. When we focus attention on hearing the feelings and needs behind a message. The more we practice in this way. The more, we realize a simple truth behind all those messages. We’ve allowed ourselves to be intimidated by are just individuals with unmet needs, appealing to us to contribute to their wellbeing.
Hello and welcome to another episode. This time we’re gonna tackle. A bigger and a meatier topic. Actually, that’s kind of scary. Let’s not do that because that’s kind of too much given the meaty topics we’ve already tackled. So we’re gonna tackle a, hopefully, somewhat smaller, manageable topic.
Metrics. That’s small, isn’t it? Mon-Chaio,
Mon-Chaio: Absolutely. There’s nothing really to talk about for metrics. You just measure them and you go on your way.
Andy: yeah. Yeah. And the best metric probably is lines of code. You’ve got these command line tools. They’ve been around for years, Klock tools, and you just run that on your code base and day after day, and you count the numbers and it’s all happy. But all joking aside where these things come from is that you have a cto, an engineering manager, a ceo, and they’ll start asking questions and I think they’re fairly reasonable questions, which are things like how do I know if my team is working at peak efficiency?
Or how do I know that my technical organization is spending the company’s money well?
That’s a fairly reasonable question. And what ends up happening is that we very quickly move towards a thing that we believe we can measure. That we think answers that question for us, and I want to say, I think Mon Chao that I don’t think that that works Well.
What do you think?
Mon-Chaio: I would agree. And let’s step back for a second. You mentioned metrics, but we’re not really talking about metrics. Capital M metrics, we’re specifically zeroing in on a subset, right? What some people might call dev efficiency metrics
Andy: or,
the, the, yeah, the Devex that came became popular recently, or the space metrics
that became popular recently. But we’re not really gonna talk about them too much because we don’t think the point is those metrics.
Mon-Chaio: Absolutely. And so regardless of what you call them, I think the questions that you mentioned around what your c e O or C T O asks, I think are, that’s what we want to dive into and that’s the pertinent problem space that we want to observe.
You sent me something that you found and I think the I think it was a question that was posted to a message board I think the raw questions that people ask oftentimes aren’t listened to enough. And so I like to read it and we can kind of chew into it in a bit. So this person asks, “as an engineering leader, How do you measure your team’s productivities and know that they are being productive slash impactful relative to what the teams are capable of?”
Why I wanted to read that question verbatim is I think that is, that raw question is more similar to the questions that you often hear asked by CEOs and CTOs, or honestly, maybe not even, maybe they ask a question in a different way that tries to imply the contents of the question.
And often I feel like the answers that they get. Don’t have credibility to them in answering that type of question, they immediately jump to the next level around, oh, well there’s all these DevEx metrics that we wanna measure, or there’s this space paradigm that’s useful for measuring, engineering organizations and how effective they are.
Would you agree?
Andy: I think so. I think you’re right. What I see in the question is that the person has a need and. Unless we engage with their question as it is and understand their context, simply putting in place one of these existing metrics that might be out there, it’s almost random chance whether or not it actually addresses their need.
And so in some ways it’s like being blinded with science. It’s like, oh, there’s this thing. It’s been studied and it shows certain results, but that doesn’t say that it answers the question they actually posed.
And so I, think that this is really interesting because now we can actually get into what is the question they posed?
Mon-Chaio: Well, let me start with some of the responses in this thread and this is not to. This is not to pick on these people who give responses. This is because these are responses that are very similar to most of the responses that I hear when this question is asked. So for your listeners, imagine if you are your CEO and cto and you do wanna know, Hey, you know, I’m spending 2 million a year on my engineering team.
Am I getting value out of them? How do I know? Maybe if you’re a ceo, you’re not super technical. And so, You know, you’re like, I, I don’t know how to measure this. Maybe if you’re CTO you feel like you’re too far removed from the days of writing code and you don’t really understand how modern code is being written, and you wanna know are there efficiency or effectiveness gains to do?
Can I improve process? Can I spend more money elsewhere? And imagine you ask this question and the answers you get are like, such. If they’re meeting their delivery commitments and they’re productive enough, I wouldn’t worry about it. Or I’ve started saying that all these fancy things don’t work without deeper leadership infrastructure, quote unquote.
We want to measure goals or performance or yet autonomy or anything. It’s like buying a dishwasher if you don’t have electricity or running water, it doesn’t make sense. Now these are seasoned engineering leaders and I think that they do have a point. I actually think that they’re, that what they say is very relevant.
Sorry, that’s not the right word. I think what they’re saying is correct, but I don’t think it’s relevant to the question, at least not the first level of the question being asked.
Andy: The way I’ve, thought about this before is that their responses are not responsive to the question
Mon-Chaio: In previous episodes, we’ve mentioned things like TDD for people, right? I think that might have been just been the last episode that we talked about, or starting with why, or a lot of these other ways of expressing curiosity and being in a learning mindset. And I would say that those answers to the question does not express a learning mindset, but.
Sometimes you can’t blame them because I don’t think the question itself expresses a learning mindset. Right
Andy: I think that is an aspect of this, is that the immediate reaction that I have as being someone who’s sometimes subjected to these measures and these arguments of I need to know exactly what you’re up to and how much you’re producing to know if I can get you to produce more for me,
is I immediately feel fairly defensive.
I feel like this isn’t going to go anywhere good. I’ll start working overtime and I’m gonna, I’m gonna start having more controls over what I do and I’ll have to start answering these questions about why did I spend five minutes on this feature and five hours on this other one.
Mon-Chaio: That’s not unfair. I think we, when I think about that, there is a seminal experience from a time when we both worked together, right? When the CEO came into a meeting with the ENG team and he said, we have to really pick up the pace. And one of the things he said that really stuck with me is, I don’t know when this pace pickup will end.
I’ll know it when I see it, or I can’t tell you when this pace pickup will end, but I’ll know it when I see it,
so you can imagine as any practitioners, you, me, and all these other people that are answering this question on the message board, if that’s been your history, you can imagine why they might be defensive, especially when the question is asked in a inartful way.
Andy: Yeah. And I should say, I think the way this one was asked it was attempting to be artful. It was attempting to say, I have this interest and I have this I want to know this thing.
It’s missing some parts, but it’s something to be, to work with. Some, sometimes you don’t even get the question, you just get the demand.
Mon-Chaio: Right. Absolutely.
Andy: That’s the demand of I have this new me metric for you. Optimize it.
Let’s start going through the particulars of this question because I think there’s something there. We don’t have the person who posed it, so we can’t know what they were thinking.
But I think Mancha, you’ve been in similar situations in the past, similar roles in the past where you might end up having to ask this question.
Do you think we could do a role play where you try to be that person and we try to uncover what. What is going on and how we could fulfill your needs?
Mon-Chaio: Ooh, that’s interesting. Yeah, let’s do that. This is not the direction I thought this episode was gonna go in, but I like it. Let’s give it a shot. We can always edit this out and rewind a little bit and try something new, but All right. So if we’re gonna do role play, perhaps I am the person I will play c e o, man, and you can play eng, executive leader, man, that sound reasonable?
Andy: Give that a shot.
Mon-Chaio: Alright. Perhaps I come to you, Andy, and I say Andy. You know, I’m getting pretty antsy. Our next round of funding is coming up and I wanna make sure that we’re, know, we’re really crushing it so that we can show our investors that their money’s being spent. Right. Can you tell me, is our engineering team up to snuff?
Could we be doing more? Could we do be doing more with less? Is there any way you can measure that?
Andy: Are you feeling a little worried that the investors aren’t going to believe that we’re kind of spending their money
Mon-Chaio: the investors maybe, but also for myself, right? What I see is I, you know, we’re bigger than we were six months ago. We’ve doubled the size of the team, and I don’t think we’re moving twice as fast. In fact, sometimes it feels like we’re shipping features slower than ever. I feel like I asked for a feature to come out.
Let’s say it was sending out an email every time an order is late, and I feel like that’s something that should be done in an hour, and I’m often told, oh, it takes two or three days.
And I’m certainly not seeing that when I’m talking to my buddy over in startup, you know, Z Land. He seems to me be moving really fast and I see his app updating every day and he’s always bragging about how great his engineering is.
And I’m just wondering, are we behind?
Andy: I think what I’m hearing is that you are disappointed in the rate at which you see us putting new features out there. So from. Kind of from the time that you ask to the time that you see it, you’re disappointed in that in the times that you’re getting there. Is that right?
Mon-Chaio: I think that’s part of it. I mean, but even if I was happy with it, how do I know whether it’s best, right? Like, we wanna be the best. Um, I didn’t come into this starting a company to be second or third, right? I wanna crush my competition and I could, th I feel like I can only do that if my eng team is the best of the best.
how do I know they’re the best?
Andy: That’s a really good question. And what, what do you think you would be seeing to tell you that they are the best
Mon-Chaio: I don’t know. Uh,
Andy: and,
Mon-Chaio: think would.
Andy: I, I’ll, I’ll say right now, I have to admit I’m in a similar position. I don’t really know when I hear that what to point to, cuz it is such an open question. But I’m interested in exploring with you what it might mean for us, for us to be the best.
Mon-Chaio: I think maybe we can pause on the role play here because I think we’ve gotten to a very interesting juncture that perhaps we can dive into.
I think we’ve gotten to a space where people might feel uncomfortable, so maybe this is a question we should explore. Is measuring a, is my engineering team the best, quote unquote, whatever that means,
Andy: Yep.
Mon-Chaio: or the second unstated assumption, which is, is this group of people possibly the best, again, quote unquote, the best that these group of people can possibly be.
Andy: Yes. So that is a very important thing. And what I was trying to work through on that was I was doing a couple things. One was to reflect back to you what I was hearing as well as your emotion about it. So that you’re worried or you’re concerned you’re frustrated. And the particular thing that it was that I was hearing that you’re frustrated about
And the reason I was doing that was one, to make you believe that you’re being heard, that I’m taking you seriously, cuz I was trying to,
And the other one was to see if, what I believe about what you’re saying.
Is matching with what you believe about what you’re saying. And you, you corrected me a few times, which was excellent.
Mon-Chaio: Right.
Andy: And then on that question about best, I felt uncomfortable about that and I, think I fumbled it a little bit, but I was trying to tell you that I’m not sure how to do that. I don’t know.
I’m uncomfortable about it. But I was willing to explore it with you.
And now to me, one of the things that’s important here is that we actually have that conversation. And so I want to ask you, how did it feel from your perspective on the role play of having someone ask those questions and kind of, give a little bit of a challenge as well?
Mon-Chaio: I think it felt good to hear that you were engaged. Unlike some of the answers that we’ve heard delivered in the past it didn’t feel like you were immediately jumping to, I don’t know, this is unmeasurable. Have you ever read that book? Measuring the Unmeasurables? You know, there’s a psychology studies that he says you can’t measure people’s product X, Y, and Z.
Right. Jumping to that. Doesn’t really work. And so you didn’t, right. You engaged with curiosity. I liked that. As my role played ceo, I would say putting myself in that role, a frustrating part may have been, Hey, Andy, I hired you, or maybe we’re co-founders. And I’m the non-technical side. You are the technical side.
I feel like I have all the answers from the marketing perspective or whatnot. And now all I’m asking you is something that. I feel like it’s very reasonable that I demand for example, my salespeople, right? I give them quotas. I set, you know, huge goals for them, and I know if they’re like crushing those goals or not.
Maybe I was a salesperson in the past, and so I can feel I can count the number of conversations you have. I can count lead times, you know, all of that stuff. And yet when I ask you about engineering your supposed expertise, you’re not giving me any of that.
Andy: Mm. Yes.
I’m not speaking to you in the same language.
Mon-Chaio: Absolutely.
Andy: And I should say that’s where I was trying to take it, is to understand what is the language that you want
Mon-Chaio: mm-hmm.
Andy: so that I can start talking to you in that language.
Mon-Chaio: Mm-hmm.
Andy: hopefully in our relationship, we would’ve gotten to this a little bit sooner than like, we’ve got a hundred person dev team.
But you are where you are.
Mon-Chaio: Exactly. And sometimes. Know, I, I brought up in my role play this idea of we’re twice the size we were six months ago and we’re moving slower than ever. Sometimes you don’t get to these conversations because of the euphoria of early dev teams.
Andy: And it’s only when issues start to show up that people start getting uncomfortable and thinking, I need control, and how do I get control? I start measuring, I start getting people to justify what’s happening.
Mon-Chaio: I can’t remember where I read this first, but I’ve seen it written. In numerous places. So I don’t think the attribution is necessary, but there’s this concept of like, explore, expand, extract, which you’ve probably heard of,
Andy: Mm.
Mm-hmm.
Mon-Chaio: three stages that a company operates in where when you first go out, you’re doing experimentation to try to find where you need to go.
And then, you know, the second stage is more experimentation. The third stage is you know what you’re doing and you just have to extract as much value out of it as I often think that perhaps CEOs or companies in general are very euphoric in that explorer stage. Their teams are usually smaller experiments usually happen more rapidly and in the explorer stage it’s not. Really a great idea to develop a lot of platforms or to develop tool chains, or one might say ci cd. I don’t necessarily believe that, but what you’re trying to do is you’re trying to move super fast in a direction with or without technology, with or without tooling. And so for the leader of a company that might sound very akin to what they understand.
And then as a company moves into the. Explore phase, they’re starting to settle down, or sorry, when it moves into the expand phase, they’re starting to settle down. They’re starting to try to scale, and it feels different,
Right? And so I would say when you get there often, that’s when these conversations start to come because it feels different and it just doesn’t feel the way it felt before.
Andy: Yeah. And there’s, there is another way of talking about the concept. Very similar. I think there’s some nuanced differences to it which is commando’s, infantry, police if you want a less militaristic one, it’s pioneers, settlers, town planners.
Yeah. And the idea there is very similar that in a commando phase it’s kind of anything goes, you do what it takes to get that objective. In the infantry phase, I now you’re, trying to organize a much larger group and it all comes down to logistics. So like armies move on logistics.
So at the intrafy phase you’re working on those logistics and things will feel much more plodding if you’re looking at the same scale, if you’re looking at the same way of thinking about progress. And then if, you get to the town planner phase, it feels like nothing changes. If you’ve ever watched a city and you’ve looked around I can return to this city in 10 years and I know where everything is. And I think that’s going to be an important thing where this conversation about how do I know that we’re still effective?
It’s context dependent. The answer will change. And so in fact, you should expect this question to come up, even if you’re already providing a view into this. It may be that you’ve entered a new phase or a different dynamic, and the way you need to answer it now has changed.
Mon-Chaio: I like that. I like that a lot. I think we’ve explored why this conversation might come up and when it might come up. Maybe we can explore now, the nuts and bolts of these asks, we started off by saying, are we the best dev team? And then there’s a similar question, which sounds the same but is actually quite different, which is, are we the best that we can be
Now, Andy, do you think. Either of these questions is a valid question to ask. Sorry not to ask, but I don’t know how to say it. You can ask any question,
Andy: you can ask any
Mon-Chaio: have a query your mind, right? If you have a query in your mind, you should ask it, but
Andy: Is it answerable?
Mon-Chaio: is it answerable or relevant?
Andy: I would say it’s one of those things, the value of a question can be in the exploration of it. Quite often you see this in research where the value of a hypothesis or the value of a theory that’s put out there isn’t necessarily the theory itself, but it’s the Process you take to try to understand it. And so I would say there is a danger in sometimes imposing these.
I, I don’t believe that there is a way of answering either one of them because there’s so much about unknown you, you could say, compare us to another group. Are we comparable to X? Are we comparable to Y? But are we the best? That’s an impossible thing to answer that assumes that people, I think there’s an underlying assumption that I chafe against, which is it assumes that people are, in some ways mechanistic or assumes that the software development process is mechanistic.
It would be similar to asking are you the best sales team? That’s an unanswerable question as well. You didn’t get that sale, but the best sales team would’ve.
I’m gonna analyze that a little bit because I said it, but there is actually something interesting in that if someone’s going to say that they have an expectation in their mind of something better than what they’re seeing, and the conversation needs to be around that, what is that expectation?
Let’s get that stated. And it, and if it ends up getting to a point where they’re just disappointed that we didn’t get that sale, that’s great. Then we can understand that people are disappointed. Great. I’m disappointed too. We didn’t get that sale.
And I think that’s part of it is getting to that point where you can kind of pull apart where someone’s getting an emotional statement and getting one that’s.
Kind of a critical statement, not critical in the bad sense, but critical in terms of critique.
But what do you think, what do you think about the statement of the best software team or our best working at our best selves?
Mon-Chaio: I think those are interesting questions to your point to explore, and I can see why somebody would want to know that. I do believe that best is difficult to define, but I think if we go to the next stage that might pose an interesting discussion point, which is often you can’t define best. And so if you remember in my role played CEO’s example, I mentioned I have Buddy who works over in startup Z who seems to be working really fast, right?
They seem to be getting features out all the time. So maybe that’s the next thing we should tackle. And you mentioned it a little bit, what about comparison of teams? Is that ever valid? And if so, how would we go about doing that?
Andy: I would say, once again, there is validity in it,
And you go about doing it by having the discussion about. Hmm. Let me think about this my gut reaction is I don’t wanna be compared, I don’t wanna be compared, but why? Because I’m afraid that I’ll be found lacking. And I think that’s, it is one of the things that we need to have in these discussions is making sure that it doesn’t turn into a stick to beat people with.
If it’s a comparison, you could say, when I’m learning by reading the writings of Kent Beck, or learning by observing a YouTube video where someone’s doing some programming,
I’m essentially doing comparison. I’m comparing what I would do with what I’m hearing them doing. .
Mon-Chaio: I think the difference there might be that you go into that. With the concept of they know something you don’t, and that’s why you are watching the YouTube in the first place
And perhaps you even believe, and I would certainly say that often that’s how I go into it, that they are quote unquote better than me at the thing that I’m watching them, right?
You rarely go into watch YouTube videos and you’re like, I’m there to laugh at these people who are obviously worse than me. So that may be a difference. You already have ascribed that they have one information to give you, and possibly that two, they are quote unquote better, whatever better means.
And so your mindset is different in that comparison.
Andy: And so I think though that gets to a, valuable principle for. These kinds of discussions, which is that if we’re coming up with some way of, very clearly defining what the CEO is looking for or what the CTO is looking for, we also have to take into account the other stakeholders the other people in the group that are going to be in some way affected by this or using that information. And jointly designing with them as well, what this thing is. Because if they don’t believe it, if they don’t believe in that idea it’s not going to go very far, I believe. And so if it, comes up say we continued , the role play conversation, or we got to a point where what you’re really concerned about is this turnaround time.
On features that have been identified to be key for a particular sale that’s coming up, and that’s really what got you going? I’m just making that up.
And it turns out that the product managers don’t agree with you and the lead engineers don’t agree with you.
They’re not going to be interested in what you want out of that, which is that they start optimizing towards that. That they start moving their practices to get that that number lower and lower or higher and higher depending on how the measure is done. And so that they need to be brought on board as well to kind of have this agreement that, yeah, yeah, this is an important concept in our world.
Mon-Chaio: I agree with you, and I think as we talk through it, there will probably be this theme of jointly, not just ceo, cto, but within the entire org, helping to construct metrics together by understanding everyone’s point of view. I think in my experience, I have seen a lot of tactics being brought to board, sorry, tactics brought to bear against this question. And I think sometimes as a leader you end up being held hostage by these tactics. So, and the problem is that they are unable to truly express the feeling that they have. As they’re being nitpicked into examples, or nitpicked is the wrong word, as examples are being drawn out of them. So let me use the example you gave.
So as we went through the role play, I might have definitely said the, yeah, absolutely. The number of features from conception to delivery is really slow, and I really want this to ship out. Before the end of the quarter so I can point my investors to something really important that’s shipped. I would still say oftentimes that is a symptom. That’s just the one thing that they wanted at that one time. And when we start to build process that to solve that, that doesn’t get back into their innate need. And I think really oftentimes the innate need goes back to, I have this gut feeling that I could be getting more with my money.
Andy: Mm-hmm.
Mon-Chaio: don’t know how to express it.
And I could give example after example and often tech teams love solving by example, but when you don’t address that innate need, it’ll always come back up and it’ll never to Part of our last episode really build that trust necessary to get beyond the tax of always having to revisit this issue over and over again.
Andy: I agree. What tactics can we use, or what tactics do we have available to us to. Improve the chance that we get down to that need rather than get stuck at the superficial level.
Mon-Chaio: I think one that I hadn’t thought about until we had this discussion was perhaps trying to reframe it in the explore, expand extract or the pioneers, settlers, townspeople framework. It might be interesting to say, Hey, well, you know, we have actually just moved if it’s true. Look, part of the reason is you asked us to scale to, you know, uh, we had a million new users now, and you’re asking us to scale to a hundred million. We’re no longer in the explore phase. We’re in the expand phase, and that has a, and if we want to move faster, perhaps we should find a way to get back into the explore phase. And I think that might be a reasonable way to have a conversation around one reason. It might feel slow to that person.
Andy: And what you’re doing there is you are acknowledging what they’re experiencing. You’re saying, I believe you, I believe that that is what you feel. Let’s understand it. Let’s see where it’s coming from and then let’s come up with an alternative. Cuz we might say from the engineering standpoint, well, we’re trying to go from 10 million users to a hundred million users. The entire architecture needs to change. So yeah, we’re rewriting everything because the way that you wrote it when it was in your garage, it doesn’t work anymore. And to write it the way we need it needs all of these components that distribute the load out in all this manner to make it so that we can cache everything.
And it just takes us a long time to coordinate all of that. But what I hear you saying is that that’s not the part you’re actually concerned about. You’re concerned about can we get product market fit on this new feature if that’s the thing that we really are concerned about. Let’s come up with another approach for that feature.
Mon-Chaio: I think an interesting thing that comes to mind that’s definitely worth discussing is as you’re engaging through these conversations, there’s an element of trust that has to exist. And we’ve talked about the types of trust before, but here is an area where I think these conversations come up a lot where the eng, or sorry, where the CEO. Oftentimes has a specific lack of trust, and sometimes that’s warranted and sometimes that’s not. And I think the lack of trust is around trust of knowledge.
He or she does not feel that their ENG leader perhaps has the knowledge that other ENG leaders have. And I think that makes folks feel very uncomfortable when the conversation heads in that direction of, yes, here’s solutions I’m giving you, but give me more, right?
Or, here’s solutions that you’re giving me, but give me more I have in my head that perhaps there’s something that you haven’t thought about or that you don’t understand, and give me more. And sometimes that’s not valid, right? Sometimes I think the CEO asks the wrong question. But I’m interested perhaps in exploring the other aspect of what you do when it is valid.
Andy: That
Mon-Chaio: So our
Andy: thought of and you just never thought of them.
Mon-Chaio: Absolutely. So to use an example from our experience when we started mostly you, I mean, you brought in Agile and XP into the team. The team never thought that they could operate in any other way other than the way that they were operating.
And so when folks would say, move faster, it was move faster within the bounds of what we know.
And luckily you were within the team and you said, look, things aren’t working. We tried this, but I have this other idea of what could be working. We could do some pair-programming, we could chunk projects up into more iterative deliverables that we could deliver in shorter timeframes. And weirdly, this was back in the early two thousands.
I’ve seen teams nowadays that come up with the same problems, right? Where you have engineers that really don’t know how to iteratively chunk up work. Or don’t know how to work collaboratively. And so there’s absolutely possible knowledge gaps within your team that your team isn’t even aware that they have or ways of working that they aren’t even aware they can do. So if you are the CEO and you have this gut sense that that might be true, but you’re not an expert, so you don’t know the details of it, and you have a team which is fairly convinced that they know how to do engineering. How do you get past that?
Andy: So I’m gonna say we’re talking to. The engineering leaders, not the ceo In this, podcast. I’m, I’m assuming that we’re not talking to many CEOs out there. actually assuming at the moment we’re not talking to many, many people out there, but we, we looked at our stats. We got eight listeners at the moment.
That’s great. And so , I’m gonna say you are probably going to be the person in the position where you feel your credibility is being questioned. And that’s hard because your initial reaction almost certainly is to become defensive and to tell the CEO you don’t know what you’re talking about.
You can’t measure those things and just leave me alone. I know what I’m doing,
and that won’t end up with the outcome that you want. This is gonna be the hardest part, is learning that reflection in action. It’s called to notice your reaction. Take a beat, come up with a reasoned response, and I’m gonna give you a formula that you can use.
Which will be really hard to produce. I expect that. And it’s to say, yes, you are right. And then you find something in what they’ve said that you can agree they are correct about.
And that starts the conversation. And from there you kind of have to now. Continue going with the curiosity, but you got past your initial defensiveness, but starting with the Yes, you are right. It’s really hard to do.
Mon-Chaio: I think that is a good tip. It kind of gets back to some things we’ve talked about previously around believing that other people have information that is correct and useful, right? And when you, when other people say stuff, it’s an opportunity to learn something you don’t know. And that doesn’t mean that they’re right, but starting with a, you’re right.
And finding something that they, that you can agree to write about gives you the space to learn. And perhaps when you do that learning, you will learn well they were wrong.
write about that little
Andy: they were right about that little point, but they, and maybe they were wrong about the rest and now, but they’ve now been heard enough. That when you talk to them about that rest, you have the opportunity to change the way they think about it.
But I will also ask people to be open to what you were saying, Mon-Chaio which is that you might not actually have the skill.
I see this quite often when I do technical due diligences on companies. I see people. Incredibly bright. They , have a, a strong history, but they’re now doing a job that they’ve never done before, which means that by definition, there’s a whole bunch of stuff that they don’t know about what they should be doing or how things could work. And so there’s a thing of a bit of humility involved in that. In saying, I actually might be missing it. And so having that curiosity to say, what is it that you are seeing maybe this is something I need to go explore, even if I don’t believe it right now, maybe it’s something I should look at.
Mon-Chaio: That’s so important from an eng leader perspective. You don’t even have to be CTO for this piece of advice to make sense, right? You could be dev lead of a two person pod once you start. Once people start looking to you for guidance. It is important that you recognize your humility and that you know, not just that you know when you don’t have the information, but that you leave open the possibility that the thing you think you have complete information for, you might not, and hopefully that’s the reason you’re listening to podcasts like ours is because you’re naturally curious. But I would say as an ENG leader, if you’re not doing continuous learning you’re doing yourself a disservice because by the time these types of conversations come up, I won’t say it’s often too late, but I would say you’ve done yourself a disservice because you’re less prepared and less armed for conversations like these, which are super, super important to the progression of your company and your engineering team.
Andy: Yeah. If you were encountering this situation, what are approaches that you would use? How would you. Try to finagle it into something that grows yourself and grows the team around you.
Mon-Chaio: I think some of the things that I would do, we’ve already stated, right? I think making sure that you and the other person are speaking the same language is super important. The meaning of the words. What does it mean to be the best? What does it mean to be effective? That sort of thing. And sometimes agreeing on a framework like explore, expand, extract, can help that. Because when you agree on a framework, then that puts you in the same state where you can say, oh, but don’t you think this is explore without having to really dive in the nuance of the specific project or the specific context of the specific instance. It’s a shortcut. For helping make meaning. Right.
Andy: Mm-hmm.
Mon-Chaio: I think we often like to say on this podcast, all models are wrong, but some models are useful and I think finding the useful model to center a conversation on is super important.
Andy: Absolutely.
Mon-Chaio: I think we’ve touched on also trying to dig into not just the symptoms, but the actual underlying need, which is very, very, very difficult. Oftentimes that underlying need is a distrust of you, the ENG leader, in some way. I need to know that I can trust your feeling. The same thing I’m feeling. I need to know that you have the same values around that ENG team has gotta be efficient and effective. And to also, I need to trust that you have the skills within you to be able to act action on that. My buddy Achmed over there, he seems to have a cto, which is well attuned and has their ENG team running, tip top efficiency. So I need to trust that you are that for me. I think those are uncomfortable situations and I think you’ve presented some specific things you could do, like starting with the your right concept but also just that concept of being curious and understanding that you need to build that trust.
And we have a whole episode, our previous episode on how you build trust. Go give that a listen. Hopefully some of the tactics there help you. And then I think the third thing about . Having humility and understanding. You may not know what you don’t know, and are you not just in that particular instance, but in general instances, really thinking and learning enough to fill everybody’s gaps, right?
Everybody has gaps. No matter how much learning you do. Are you doing that and are you seeking out different opinions, not just ones that reinforce the way you think? In this particular example you might offer to your ceo, Hey, your buddy Achmed over there for Startup Z. I would love to talk with Achmed and see what he and his CTO are doing that might be different than what we’re doing here.
Andy: I actually love that because,
it opens up so many avenues. It opens up that curiosity. I want to go see what they’re, but it also opens up , a potential relationship that now you two can learn from each other and you may find out things that you’d never heard of before or thought of before.
I actually watched that happen today. A consultant friend that I work with talking to the CEO O of a company said, I know a few other people who are in the situation you are in. Would you like me to introduce you? And the relief that the c e o showed on his face when he got asked this, you, it was just like he was.
He was so thankful that he was gi being given kind of a lifeline
To learn from someone else and see one of the people had been described as, he’s been in that same industry for about 30 years. That he was like, that is amazing. That would be so good for me. Thank you. And I think that’s what you want is.
When someone is pointing out that there are others out there that you can learn from
that they themselves trust, take them up on it. There’s no downside for you.
Mon-Chaio: There really isn’t. Talking to people that you might not normally talk to, right? You might not normally like to talk to CEOs because they always ask these questions, which you think are irrelevant or difficult or whatnot.
You want their point of view because it’s important for you to understand that mindset of people that you know, archetypes of people that you’re gonna want to have to interact with in order to do the best that you can in your role. The other part, Interacting people that are like you, right? But perhaps have different points of view. And I think that’s really difficult too. I see this a lot with ENG leaders who are told, Hey, we have some people on our board that are VPs of engineering somewhere else, or CTOs somewhere else that could really provide value. Sometimes the answer is no. They can’t really provide value, right? They’re from an old, stodgy company.
Maybe that’s why they’re sitting on the board of this particular thing. They were brought in by a VC company cuz they have a lot of experience or whatnot. But I think being open to the fact that they have some information to give you. Or at least to their point of view, I think is important. It, it’s interesting.
I can’t remember whether we were talking about it or I was talking to someone else about it, but we were laughing. Whoever this was, I was talking to, we were laughing and saying, you know, there’s a lot of bad podcasts out there, and there’s a whole podcast series that you could do just based on listening to other podcasts and critiquing what they’re saying. Even when I listen to a podcast where for the most part I’m rolling my eyes and I’m thinking, man, ugh. What is this person talking about? Has he even read this paper? Has he read that paper? Has he like worked in an organization? I would say very, very rarely do I ever come out of it, and I say the entire thing was bunk. There is 0% that I learned. From that person’s conversation,
Andy: True.
Mon-Chaio: very often there’s a nugget somewhere. Oh, I didn’t think about it that way. Hmm, I don’t believe that, but I don’t know why. Let me go read some more and think about that.
And so I think that mindset is always really important is especially so in the case that we’re talking about now, That mindset is super important. In the cases where you’re so defensive, where you feel like you, you and your ideas, and the foundation of the way you believe engineering should be done is being ripped apart by one of your closest partners in business.
Andy: I think that’s right, that practicing that empathy, practicing that curiosity wherever you can, so that when it does come up with one of these partnerships that in your day-to-day life is really important. You’re already practiced in how to inquire and how to be vulnerable and how to find what they’re saying that you can agree with
Mon-Chaio: Mm-hmm.
Andy: it, it does take practice.
Andy: I feel like we’ve hit a really good end point on this one. Do you.
Mon-Chaio: Possibly. I was gonna suggest that we spend a little bit of time touching on what happens when you get beyond that,
Andy: and we can always have another podcast that does a good job on that too,
Mon-Chaio: That’s true. That’s true.
Andy: because I’m thinking what we’ve done so far is a really good thing of. Before you dive to the metrics, seek to understand
, that there’s a need that they’re expressing and a concern or a worry or a fear that they’re expressing and working your way towards that will build that relationship as well as get you a good, clear picture of what they’re asking for, which may be a metric or it may just be acknowledgement that you are worried too.
Mon-Chaio: Right. I think what I’ll leave with is that I do think metrics are important, and I do think frameworks like space are really important. I. That’s not for this episode, but there is a need to measure what ENG teams are doing. But until you’ve done what we’ve talked about in this episode, really establish what it is that the person is asking for.
Those things will not make, I think, a difference in the key parts of trust building with that person.
Andy: Yeah, I think you’re right. It wouldn’t build the trust with that person. It wouldn’t, probably wouldn’t answer the question that they really have because you don’t know what it is, and it would just be wasted effort. So. Have the curiosity to find the thing that they’re actually interested in, and then if it turns out to be something that needs to be measured, we’ll talk about that another time.
Mon-Chaio: Sounds great. Well, hopefully you all have. Really enjoyed listening to this episode. We’ve enjoyed talking about it. We’d love to hear also your war stories. Have you, as ENG leaders had challenging asks around measuring the productivity of your engineering teams? And if you have, have you tried some of these tactics or do you have other tactics that you would recommend? Always interested to hear your thoughts as well as other topics that you would like us to touch on.
Leave a Reply