CTO Therapy: Managing Urgency, Expectations, and Trust
In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub delve into the critical issue of building a sense of urgency and trust within engineering teams. They discuss the importance of schedule accuracy, delivering on time, and establishing dependable processes. The conversation highlights the essential role of transparency in planning and breaking down large projects into manageable tasks. They explore the impact of culture, environment, and effective communication in fostering a trustworthy and efficient engineering organization. The episode offers insights into overcoming common challenges and bridging the gap between technical and non-technical stakeholders to ensure aligned priorities and timely delivery.
- 00:00 Introduction and Episode Kickoff
- 00:56 Discussing Engineering Team Prioritization
- 01:37 Importance of Schedule Accuracy
- 03:42 Building Trust with Stakeholders
- 05:40 Balancing Speed and Reliability
- 10:19 Collaborative Prioritization with Stakeholders
- 18:02 Understanding Urgency and Importance
- 28:09 Vendor Time Estimates and Trust Building
- 28:53 Evaluating Engineering Team Performance
- 29:42 People, Process, and Technology Framework
- 30:52 Team and Environment Alignment
- 31:52 Impact of Business Environment on Performance
- 33:40 Urgency and Perception in Engineering
- 36:24 Breaking Down Tasks for Better Visibility
- 40:45 Effective Communication with Stakeholders
- 46:35 Scrum and Agile Practices for Urgency
- 53:41 Reframing Project Risk and Progress
- 55:34 Conclusion and Podcast Wrap-Up
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCtos #Podcast #Ctos #CtoPodcast #Technology #Engineering #SoftwareDevelopment #Entrepreneurship #SoftwareDelivery #TrustAndTech #UrgencyVsImportance #TechLeadership #AgileDevelopment #ScheduleAccuracy #CTOTherapy
Brad: It's worth us challenging ourselves as CTOs to ask ourselves,
hey,
are there parts of the way that the engineering organization is behaving that may inadvertently undermine the perception of urgency?
Scott: Welcome back, everybody,
to another episode of How Many CTOs Does It Take?
My name is Scott Porad,
and I am here with my trusty co-host.
Brad: Brad Hefta-Gaub,
Scott: Brad,
what do we have on tap today?
Brad: we have I think we have an interesting topic to talk about.
I
Scott: Let's
Brad: think talk that,
Scott: about it.
Brad: yeah,
Scott: What is it?
Brad: well,
you,
well,
first of all, I thought you posted something on LinkedIn recently that I was kind of like, oh, that's, that's, that's a cool hot take.
And it was this idea that like the wrong question to ask is, can the engineering team do it?
And the right question to ask is when can the engineering team have it done?
And I think that there must have been something behind that post.
I have a feeling you were thinking about something when you made that post.
Scott: You think that post was a reaction to maybe an experience I had?
Brad: I think it's possible you might have been reacting to an experience,
and I would love to hear more about that.
Scott: It was pretty simple.
I was faced with a stakeholder who was asking,
can you do something?
And it was, well,
you know, we have a plan that's filled.
The company I work for right now is pretty good about long-term planning.
A lot of companies aren't, but we have a three-year strategic plan.
We have a one-year plan for what our engineering team is going to do.
And then we do quarterly planning and then we do sprints.
And nothing is really set in stone until you get to quarterly planning.
We strive to complete 80% of the things in a quarter that we set out to complete.
I refer to that as schedule accuracy.
I'm going to go on a tangent for a second.
I run an online software system,
a website,
a mobile app.
I think we do two things. We've got two jobs. We operate a system and we develop a system.
And I think the most important KPI that I have yet to find, so the performance of the development side of the team is schedule accuracy.
And that's because
schedule accuracy for to get that right forces the team to do a lot of other things right you have to understand the requirements you have to understand how your system works
You have to understand what you're really going to do to change it. You've got to break that down into small enough bits that you can estimate it.
You've got to not write buggy code, otherwise the project you had lined up next,
you're going to spend all your time going into that.
Just a lot of stuff has to happen, right?
Brad: I think it's a great metric. You've talked about that in the past, and I agree with you that it's a really good metric because it also kind of accounts for sandbagging.
Right.
Like if if a team's getting more than 100 percent of what they estimated done or they're getting 100 percent estimated done,
they probably were sandbagging a little.
Scott: Yeah, that's why we aim for 80 to challenge ourselves a little bit and but to be close enough that the company can rely on you to get things done because I have a hypothesis. I have a bunch of hypotheses.
One of them is.
Reliability is more valuable than speed.
I use an expression all the time.
There's no point in going fast if you still show up late.
Brad: Wait, wait, hold on a second.
Hold on a second.
Let
Scott: I'll
Brad: me let me
Scott: say that it again more slowly.
Brad: for a second. I'll
Scott: There's no point in going fast if you still show up late.
Brad: Yeah.
Scott: If you're zipping around at 100 miles an hour,
but you still get to your destination behind when you wanted to get there,
what was the point?
Brad: Yeah.
That's
Scott: Also,
Brad: a good way to I like it
Scott: you know, these companies that we all work for depend on us to do the engineering.
Nobody else picks it for the engineering team.
And a lot of other teams, well, they're depending on us frequently to make their plans.
When should we launch the new thing?
When do we need to do the marketing around it? When does support need to get their training around it? When should we account for maybe the revenue in the financial plan? When should the sales team start preparing its material?
its materials to go out doing all these everyone's depending on us right and my experience is simply it's more valuable to the company to be dependable and deliver so that everybody else can orchestrate we can all orchestrate together around what we're doing and get this to market and let's say you could get it there a little faster but those times when you miss
And you're not there on time. It really throws a wrench in everybody's gears across your whole company,
right?
No matter how big your company is.
So I always strive when I come into an engineering team that maybe is not performing as well as it should be.
The first place I say is, hey, let's get dependable.
If we...
We're going to deliver when we say we're going to deliver.
I like to use the expression,
if I can hammer something into the shape of a software project,
we can get it across the finish line.
And then once you do that, I genuinely believe in my heart, I believe that most people are trying to work as hard and take pride as they can. They're trying to get stuff done as fast as they can.
start showing up on time first then start trying to figure out how to optimize your whatever you're doing to go faster as opposed to the other way around which is you might get stuff done but the times you don't you really disrupt the rest of the company so that's why I lean on schedule accuracy and then once we get to that point where you are delivering then you start to say well what can we do to still be reliable but be reliable faster you
Brad: I think that makes a ton of sense,
and I think it's worth.
pausing for a second to kind of let that sink in,
right?
Scott: Mm-hmm.
Brad: And part of the reason I think it's important to pause for a second, let that sink in, is because of another theme that we've talked a lot about is that for non-technical product stakeholders,
a lot of what we do is completely mysterious.
And it's like an enigma.
And so if it's
one thing to be like,
well,
I don't really understand what it is that you guys do over there in engineering.
Like, I know I can describe what I want and then you guys deliver it.
And so.
If when I describe what I want,
you are really unreliable in what you say it's going to take you to do it, Mm that
Scott: -hmm.
Brad: just further increases that mystery.
Which further erodes trust,
which is such
Scott: Trust,
Brad: a critical,
such
Scott: trust,
Brad: a critical thing for you to be building with your stakeholders is trust.
Scott: trust, trust,
yeah,
absolutely.
Brad: And so.
To your point, like you're sort of like, I think you're starting to hint to this other topic,
which is the,
okay,
yeah, sure,
you delivered what you said you were going to deliver and you even delivered it on time with 80% accuracy,
but are you sure you couldn't have gone faster,
Scott: Yeah.
Brad: right?
And so before we, to your point, like before we start talking about like,
are we going as fast as we could be going?
at the minimum if we don't have a foundation of like i trust that when you tell me you're going to get something done
Scott: Mm-hmm.
Brad: you're going to get it done
Scott: Yeah.
Brad: like if we're missing that well then like going to your you know to your to your great little adage
What's the point in going faster if you don't get there on time?
Scott: That's right.
Brad: Or what's the point in going faster if you didn't get to the right place?
Scott: Yeah,
that's right.
It's exactly right.
Exactly right. Everything we do either generates trust or erodes trust.
And there are a lot of things every department in an organization needs its other departments for different reasons one way or the other to just trust them.
Hey,
trust me, I need to do this.
upgrade is something i might say the finance team might say i don't know trust me i need to account i don't actually know what a thing is but like every department
Brad: Oh,
Scott: needs to
Brad: trust me,
we can't afford to have all these employees.
We need to cut costs.
Scott: yeah yeah or yeah whatever it is so we all need to have that trust and to me the foundation of trust with engineering is like i said at least for an online system
Do you deliver what you say you're going to deliver is on the software development side and on the operational side,
is my system up and running?
And if it's not up and running,
do you respond rapidly?
Like to me,
those are like the three components of trust.
And there's a fourth I would put in there,
which is, are you operating within your budget?
And like.
Those are all really clear signals that are happening all the time that our stakeholders can use as signals and proxies for like.
When these people say to trust me about something like they want to go upgrade the flux capacitor and I don't understand why they want to do it and it has no impact on our business supposedly,
our business is we can measure it.
I need to trust them.
So, OK,
so this comes all the way back to the when.
Don't ask us if ask us when.
So we have a fairly good planning, but we have a year's worth of any given time we have a year's worth of work mapped out.
Right.
And then we lock a quarter in and of course we lock in sprints and so particular stakeholder this week was asking me, can you guys do this and kind of pressure and can you do it can you do it and it was kind of a squirmy conversation and then.
It was like, well, yeah,
Brad: So was this, by the way, just just for context,
was this something that was getting essentially added into the roadmap that was completely unconsidered, you know, at the during the plant,
the yearly planning process,
the quarterly planning process,
whatever that might be, how hot off the presses was
Scott: it
Brad: this idea?
Scott: was it was a thing that's come up and those happen from time to time.
And so they're asking if we can do it.
And and I kind of realized,
like, well,
that's the wrong question.
question like of course we can do this it's a question of prioritization which is like when can we do it like we could do it tomorrow if you wanted us to we would have to stop these other things that we're working on right and in my judgment you shouldn't stop those things you should slot it in at this particular point in time
Brad: So you just touched on two different parts of the when that I think are also really important for us to tease apart,
and that is like
there's the like how much effort would it take you to do it right so so like can it be done
probably the answer is yes like i often say like look it's all just software we can do anything right so the answer the answer to the can it be done is almost always going to be a yes it can be done um but then to your point there's the question of when could it be done by and that's a that's a mix of how much effort will it take to do it
And what other things is it competing with?
Scott: Yes.
Brad: And that's very important to then turn and put that accountability onto your stakeholders to say, look.
We're operating against a set of priorities that we agree to.
We can always change those priorities,
Scott: Mm hmm.
Brad: but introducing something new to the priority list definitionally impacts the other things that we previously agreed to do.
Scott: That's right.
Now, here's something which is this is great that we have a podcast about CTOs because here's something where I think a lot of engineers.
are uncomfortable with and I think I'm not trying to toot my own horn but I think it's helped me in my career which is sometimes that stakeholder CEO head of product ever they need a thought partner right if we just say you tell me the priorities that's kind of shoving into their face right lots of times I just did this today as a matter of fact said well look here's what it is here's how much work is going to be here's
Taking off my CTO hat for a second and just putting on my steward of the business hat,
here's my recommendation where we should slot it in.
I think we should slot it in after this project and before this project. That's what I think.
I've found that's helpful to the stakeholder a lot.
At least it's just something for them to react to and say,
no,
that's not the right spot. I think it should go here.
But it's a much more collaborative.
As long as I keep grounded or the CTO keeps grounded, ultimately it's this other person's decision,
whoever owns prioritization.
But I've found just shoving in their face,
well, you have to prioritize it gets me nowhere. But saying,
look.
and look here's here's here's what i would do and i just did this this morning i just said look we were talking about another thing which is like you know kind of getting at it and i was like there was some urgency about you know making a decision fast on it and i was just like look i don't think we're going to prioritize this ahead of anything we have in the next quarter and i sort of listed off the big projects in the next quarter so there's not a lot of urgency to make this decision until
we start planning for the subsequent quarter and that actually kind of took some stress out of the room because everyone's like oh yeah that's right we're not going to prioritize it against any of that any of that other stuff and and so I think sometimes as a CTO you can be a business partner to the stakeholders and
Brad: 100%.
Scott: we're not always business people because that's not our training but you know it's not our first rodeo either we've seen we've seen a thing or two and you can be helpful
Brad: I also think that like another part of that like collaborative conversation around like where do I want to prioritize this where where do I recommend that you prioritize this there's obviously like the implications to the business like oh is this revenue generating is this saving cost is this meeting the needs of a particular high profile customer like those are good things to include in that how do we prioritize but another thing that
stakeholders really often need to know is well how expensive what's your gut about how expensive this is
Scott: Yeah.
Brad: going to be right because a lot of times it's like if it's a if it's something that feels like a nice to have that you assume because again we're like like taking that product idea and turning it into functioning code is such a mystery often to these non-technical stakeholders if they're like
I genuinely thought this was going to be a super easy ask that was going to take like one developer and quad code like an afternoon.
Like the only reason I was prioritizing this high is because I thought it would be really simple and easy.
Well,
no,
turns out here's the implications that here's here's the likely cost of that.
And because of that,
my recommendation is it should be here relative to these other like cost reward ROI type things like they they can't have an ROI conversation if they don't know the I.
Scott: Yeah,
that's exactly right.
It's so interesting you say that because, again,
today's the day I had a conversation with somebody about that part today.
I think our organization is pretty good at detailed.
Like a detailed product requirement document,
a detailed technical design document,
a detailed estimate.
We're not great at like the low fidelity.
Like, can you just give me a one pager for your requirements,
a one pager for the design, and we'll give you a rough estimate.
And it's something our organization, we're getting better at it, but we're not great at it.
And I was actually challenged today with this very same conversation I was telling you about.
about this morning we were talking about something that had no estimate and i was like look i mean i'm really shooting the scene my pants but i think if you gave me 12 engineers for a year i could get it done but like i need you guys to really understand like there's there's four parts of this and like one two three four like one we understand the solution two we understand the solution but it's got a lot of scope variability
and pick four like we don't even know like we have no idea like I mean if someone spends two hours thinking about this we'll know but like nobody's thought about it yet right so I'm just really guessing so yeah as a CTO you got to be able to do that and stick your neck out a little bit and it does come with experience and also
like i was just saying a minute ago knowing how to message but really message this to the stakeholders like hey i need you to understand i'm shooting from my hip right like i you know and the takeaway from the meeting i just had
close the loop on the story is we walked away saying hey we need some people to go get us a little bit better estimates we want to run an experiment to understand the impact of one of the changes that we might make and we want to do a little bit better financial modeling of what we think the costs and benefits are and so to me that's very natural like cone of uncertainty we went from
very you know a month ago very uncertain that's slightly more certain and we weren't still yet certain whether we wanted to make decisions we said well let's take another step and just do a little bit more work to just steal it out and see if this is something we want to invest in
Brad: By the way,
You know, at the risk of getting too self-helpy woo woo
Scott: Yeah
Brad: or something,
you know, I'll acknowledge that like,
you know, decades ago,
reading The Seven Habits of Highly Effective People from Stephen Covey, you know, one of the things that really struck me was that whole notion of the four quadrants, right,
of, you know, urgent,
not urgent,
important,
not important.
And it feels to me like there's this interesting thing that happened in your story there where somebody came to the table with this is important and urgent,
Scott: Mm
Brad: right?
Scott: -hmm.
Brad: Like we need to solve this now.
And in the Covey model,
it's like,
okay,
that's the quadrant you want to manage things that are in that quadrant.
things that are in the important not urgent quadrant that's where you really want to focus your time that's the place you get the most leverage and what you did it sounds like in your story what you did was you actually took somebody who was kind of reacting in an urgent important way and you were able to like collaborate on it in a way that you shifted it into the
not urgent important zone and that's
Scott: Yeah.
Brad: where you're able to kind of go like hey is it really urgent right now let's we have or do we have time to do this right do we have time to focus on it appropriately and if you're able to do that kind of that's like a really powerful technique to help turn down chaos and turn up
quality and focus.
Scott: I'll take that as a compliment,
but I have a question for you.
Brad: Yeah.
Scott: I have,
the word urgency is a trigger word for me.
So in that two by two, urgent versus urgent and important versus each other, the quadrants, what does urgency mean?
Brad: Yeah.
Scott: Does it mean time sensitive?
Brad: Yeah, I think it means time sensitive.
In Covey's language,
he uses that to mean time sensitive.
Scott: Okay, so important and time-sensitive.
Brad: Yeah, if it's important and time sensitive,
that means it's like it's kind of like, you know.
it's like a firefighting thing that's real firefighting
Scott: Yeah.
Brad: you know and you got to be good at delegating and you should sort of like you know it's crisis you know it's crises and pressing problems that's and so that's just like you have to manage you have to block it and tackle it right um you know if it's like the stuff that's like you know another good example of this is like the urgent and not important right well that's just like
that's just like busy work it's like interruptions and that stuff you got to get really good at just like avoiding like just like no no that's not important we're not going to focus on that right now that's not a thing that we worry about um you sort of have that also like in the bottom quadrant of like uh not important and uh not urgent uh that that's like bike shedding or like distractions right
and those you definitely need to like create a culture that limits that
Scott: Yeah,
Brad: right
Scott: yeah.
Brad: so it's really kind of like the way i think about this quadrant and it's like um in business all the time we're going to have these this sense of urgency that's going to happen where like this is time sensitive i need to solve this right now and so like and then you have other stuff that's like um
It almost feels like if you're, you know, like a big part of like this, this, this urgency important quadrant is this idea of like, it feels like you're doing good work. A lot of people get trapped in the like,
I'm, I'm dancing as fast as I can,
everything I'm doing feels really urgent.
Scott: Mm-hmm.
Brad: Right.
And the insight is like,
that's not where you're going to do your best work.
Scott: Mm-hmm.
Brad: And so the first step is for you to answer the question,
well,
is it really urgent or not,
Scott: Mm-hmm,
mm-hmm,
Brad: right?
And there's a lot of things that feel urgent in the moment that you can actually say that turns out that's not that urgent,
Scott: mm-hmm, mm
Brad: right?
And then once you've kind of like dealt with this,
like is it urgent or not,
then you can kind of like split the vector of is it important or not, right?
Scott: -hmm.
Brad: And the not important things are the stuff you want to get rid of.
Scott: Sure.
Brad: But if you're stuck there in the urgency zone,
everything feels important,
right? Urge, like if you're stuck in that sense of time sensitivity,
it's really hard to distinguish like, is this important or not?
Anyway, so you started to talk about the word urgency.
Scott: Well, yeah, so that's a different definition that I think triggers me.
I've had bosses in the past, stakeholders, one sort or the other,
say to me,
you know, I just don't feel like the team is acting with enough urgency.
Brad: I can't – I don't think I've ever had a business stakeholder who hasn't said that to me at least once
Scott: I
Brad: in
Scott: know.
Brad: my relationship with them.
Scott: Yeah,
and what do you think they mean by that?
Brad: Well,
I mean I think – I mean first of all, that's called capitalism,
right?
Like even if we're doing great.
Shouldn't we be moving even faster?
That's like, you know, it's all about like driving greater, further,
you know, growth Yeah. from capitalism economic perspective.
Scott: Yeah, I often think about like,
well, what?
What are the things, let's say you think the team is working hard and getting stuff done on time and delivering value,
et cetera, et cetera.
And but because of capitalism, a stakeholder is always going to say that.
And I so then I think to myself and I haven't cracked this yet, but I'm so curious,
like, what would the signals or attributes or whatever,
what would be what is it that would make the stakeholder feel?
Like the team was acting urgently.
Brad: Well, that's a great question.
One way to answer that question might be,
what are the signals and the symptoms and the signs that make them feel like the team's not acting urgently, right?
Scott: I think the biggest symptom or signal or sign is that I'm
not getting the changes to the product as fast as I want them.
Brad: Do you think that that speaks to that whole mystery,
the enigma of like, what is it you guys are doing over there anyway?
Scott: In part, I think there's another piece to it, and this is a little philosophical.
So on my street, across the street, somebody is building a new house.
They tore down what was there, they're building a new house.
And I think the world, or at least the world I live in.
generally speaking understands a house takes roughly somewhere between nine and 18 months to get built you know some companies can build them faster some houses are more complex you know but on average somewhere in that range because lots of houses have been built and we've all sort of seen it and there's lots of contractors that have told us that's how long it takes etc etc
Whereas, you know, all software is totally bespoke.
Nobody's built it before.
And so there's no like generally accepted.
sort of societal understanding of how long something should take i've i've had stakeholders say to me like well i think it almost should take you guys like two or three months to build this i'm like i wonder you know i don't even know i'm like what makes what makes you think you have any idea how long this should take right or when people say like why is it taking so long why can't you do it faster and it's like what do you mean why nobody in the world knows how long this we just figured out for the first time how long this is going to take and no one's ever done it before
For sure. So I think it has,
I think there's this big piece of like, as a culture,
as an industry,
we have, nobody has any sort of common understanding of what things take.
And then I think there's this,
I think, I think there's a few things that really mess that up. I think vendors screw this up. I was watching a vendor presentation recently.
about you know the software they wanted us to buy and they're like showing it to us they're like it's so easy to get the setup you just run this command line and within 60 seconds you're already up and running and you know i was in the room with like my ceo and everybody was in this room and i was just like my heart dropped because i was like okay wait a second this person's not going to deploy this from their laptop like yes they're they can now code in this environment
on their laptop but they're they're not going to run this they're not going to deploy from their laptop so just let's just talk about a bunch of little things someone's got to set up a repo for this thing someone's got to set up a build pipeline for this thing it's got to get built and go somewhere so unless you've got a really nice like kind of infinitely automatically scalable container infrastructure someone's got to set up a little bit infrastructure like there's a bunch of stuff to sort of productionalize
someone's going to put the monitoring on it and the alerts on it and all that stuff but then the ceo hears 60 seconds and
Brad: Right,
Scott: all of a sudden you
Brad: exactly.
Scott: come back and they're like well i mean it's going to take us two months and they're like but the vendor said 60 in fact just so you know just to be very clear that vendor we told that vendor it was going to take i can't remember let's just say we said it was going to take 40 developer weeks i can't remember what the number was the vendor came back and said well we think it should only take 12.
And now I'm not personally anchored to that.
I get anchored to that. Why is it taking you longer than 12?
Oh, because this person who's trying to sell you something told you that's what they thought?
Brad: Well,
this to me, Scott,
is exactly the point that we kind of started with,
which is like it's.
So important that, you know, you that the engineering team builds trust with the stakeholders.
Scott: Yeah, for sure.
Brad: And I, you know, I can't count the number of times that, you know.
You know, you've been brought,
how many times have you been brought in as a CTO or fractional CTO?
And like the mission,
this statement is like, gosh, I just feel like that the engineering team is underperforming.
Scott: Mm-hmm.
Brad: Right.
And you're like, well,
OK,
that if that's what you're hiring me to figure out, then let me tell you what I'm going to do is I'm going to go look and I'm going to look at.
people process and technology and probably probably you should just know that it's not going to be one of those things it's probably going to be a pretty healthy mix of all three of those things are impacting and
When we talk about process,
it could be that the engineering team has a really great process, but they're not getting good guidance about what to build,
Scott: Mm
Brad: you
Scott: -hmm.
Brad: know, and so it could be that the reason it takes so long is because.
product team keeps changing their mind or the product team doesn't really know what they want or they you know um and it could be we have a bunch of engineers that aren't good like that could be
Scott: And
Brad: like
Scott: it could be your expectations for what sufficiently fast enough is unrealistic.
It could be your appetite for change to the system, you know, updates, new features,
whatever is insatiable.
And no matter how fast this team was going,
that's most of my experience,
no matter how fast the team is going,
it's insatiable.
In part as an industry,
we have no agreed upon way to measure productivity.
Brad: Yeah.
Scott: And
Brad: Oh,
Scott: that's, yeah.
Brad: and that's why you started out. That's why you started out by saying like, I feel like the way to measure this is estimation accuracy.
Right.
Scott: I want to present a slightly different framework from people, process, and technology.
Brad: Sure.
Scott: It
Brad: Promote.
Scott: was presented to me recently within the last six months and actually by our head of product world the Southern has actually served us really well.
And he basically said,
look,
our team plus our environment do not equal our ambition or do not, you know, like our ambition is greater than what our team and environment can do.
So we have some choices here, right?
We can lower our ambitions.
An ambition can be how much you want to do or how fast you want your business to grow or whatever it is.
We can figure out how to create an environment where people can serve those ambitions or we can adjust the people.
Brad: And that environment, just if I can double check on that, that environment is kind of what I would generally lump.
process and technology into
Scott: Yeah,
Brad: it.
Scott: there's other pieces in there too.
Like, I'll give you two examples from our environment.
One is like our financial profile.
So we're in a low margin business.
And so as a result, you know, we're not Microsoft with 90% margins, we got low margins.
And so the nature of a low margin business is the nature of a different than the nature of a high margin business,
you can't.
It's you know, you don't in a high margin business every customer you add like generates a lot of profit for you Whereas in a low margin business,
you got to add a lot of customers. That's one piece
We're a privately held company.
So that has a different dimension to the dynamic,
which is our owner has different expectations than, say, a venture capitalist would have.
And those affect,
you know, if we have venture capital size ambitions in terms of the growth and wanting to take over market,
but the way we're funded by the people that own our company.
fund us in a steady growth type of way or willing to fund it in that way we say hey we want you guys to give us 25 million dollars or 100 million dollars to go do this thing they'd be like are you nuts that's not how we operate so that's part of the environment certainly culture is part of culture can be part of the environment or part of a team i'm not sure which one it's probably more part of the team but
Brad: I throw it in the environment.
Scott: i think there's a lot of different parts of that environment that can shape
you know, what the team in the environment,
what they can produce and does that match what you want it to produce?
And that's actually been a useful tool for us to help understand some of the challenges that we have. You know, we have things that are going very well. It's been a good year for us, but we also have challenges and that's sort of been a useful tool.
And I think that actually fits a little bit with.
This urgency question,
like we got this big ambitions and we got things that allow us that people don't feel like we're moving fast enough, being urgent enough towards those ambitions.
One of the things I've come to call, at least in this world I'm living in right now,
my gut is it's 80% environment,
20% people.
Like you could take it, you remember the movie Trading Places with Eddie Murphy and the
Brad: Right,
Scott: Duke brothers,
Brad: right.
Scott: you know, they substitute it out Dan Aykroyd for Billy Ray Valentine and they change their behavior.
We could get rid of 100% of the people, bring in 100% new people.
They're still going to be dealing with environmental challenges.
Brad: By the way, that's why I put culture into environment because that's
Scott: Yeah, that's right.
Brad: it's more.
I mean, if you get rid of 100% of the people,
you're going to have a different culture. But if you're swapping people out, the culture is persistent.
Scott: Yeah,
that's right.
You might get a different culture, but you're still going to have low margins. You're still going to have whoever owns your company.
You're still going to have your tech staff you have to deal with, etc.
So I just I'm trying to get my team and both my the leadership team I'm part of in my engineering team and product team to understand what can we do to change our environment.
government.
Brad: Well, OK,
so first of all, I love this framework that you're talking about. I think it's a great framework. And I agree with you that I agree with the person that introduced it to you, your product owner that introduced it to you. It's like, yeah,
if you can have a completely out of sync mismatch between your ambitions and your environment and people,
then that's going to be.
problem,
Scott: Mm-hmm.
Brad: right?
And so like,
you know, you use the examples of the way you guys are structured as a private company versus venture capital, the same types of issues would exist in somebody that's bootstrapping, you know, a business or, you know, a small business that's, you know, so these differences in environment are super important.
I agree with you.
But I feel like I want to come back to the question I asked you earlier,
which is, instead of asking the question,
what are the attributes that would make you feel like the team was acting with correct urgency,
I asked the question,
well, what are the signs and symptoms that they are associating with a lack of urgency?
I feel like I feel a little bit like there's it's worth us challenging ourselves as CTOs to ask ourselves, hey,
are there parts of the way that the engineering organization is behaving that may inadvertently undermine the perception of urgency?
Scott: Yeah.
Well,
I can say one.
For sure. We talked about it already.
In fact, how we got part of how we got into this conversation.
Don't ask me if ask me when, because given the set of engineers I have, you know, the number of people we have on the team, there's a very, very, you know, much people have much bigger ideas, many more things they want us to do than we have time to do at any given moment. So,
you know, most of the time we're saying.
Well, we'll stick it in the backlog.
Right.
So we're frequently giving this signal of not inadvertently giving the signal of not doing things for you.
Right.
And might reinforce kind of as a as an undercurrent just reinforce that this team just never can get stuff done.
They're always just like, we'll do it later.
You know
Brad: Well, yeah,
totally.
So that's a great example where it's possible that maybe if you interrogate that dynamic,
you might be able to make some adjustments in the way that you talk to each other that might help flip that script and people feel more.
heard right
Scott: Yeah, that's
Brad: well
Scott: right.
What do you think some other things are?
Brad: i'll give you an example of something that i just ran into that i think is i i i feel like this this might be an example of the type of thing that that creates this sense of a lack of urgency um so uh
I was doing this evaluation on this organization and one of the things I noticed in the language that they were using was,
do I need to get designs for this?
Like, do I need to get design involved to do designs for this?
and i was talking to the ceo stakeholder and i and they were like hey do it like oh there's a plan but do i need designs for this and my reaction to that was no this is shovel ready like if you really really want like a very specific pixel perfect design right
and you have a specific aesthetic you're looking for then get design involved but that's going to add an extra step that's going to add some cost that's going to but if you're just happy with the idea that like yeah have the developer add a button and just move on then don't over complicate
Scott: Mm
Brad: things
Scott: -hmm.
Brad: don't add extra steps that you don't necessarily need right and i've seen this dynamic happen all the time right like
as a development team we're waiting around for you know the Figma right where a lot of times it's like just add the button
Scott: Mm
Brad: right
Scott: -hmm.
Brad: we already have the just add a new button just say add a button you know so to me that's a small example where
And we maybe we can talk about it in the context of like core values and stuff like this, right?
Like, like if the culture has if the environment slash culture has created this this mechanism, this this this dynamic where people feel that they don't want to start working until it's very fleshed out.
Scott: Mm-hmm.
Brad: Then that, I believe,
sends a signal of kind of like reluctance to move,
Scott: Yeah.
Brad: reluctance to act.
Scott: Not a bias for action, a bias for,
Brad: Not
Scott: yeah.
Brad: a bias for action. It's a bias.
C-Y-A,
right?
Scott: yeah yeah so like bureaucracy like hey we have to check this with legal we have to check this you have to check this with design we got to check it with the information security team whatever there's all stuff that makes people stakeholders feel like why aren't you just going for it
Brad: Why aren't you just going for it?
And I think there's a lot of reasons why that can get created in the environment.
And I think that...
So that's an example where if you're seeing that going on, I think there's an opportunity there to sort of like break down some barriers in a way that really would have positive impacts to the feelings of your stakeholders of like, wow,
they're moving way faster,
you know.
Scott: Well,
let me let me counter that for a second.
Maybe the reason that person says, should I go talk to design?
is because at some point some engineer didn't talk to design and shipped
Brad: Oh, yeah,
Scott: something
Brad: they got punished.
Scott: yeah that punishment isn't always it's not a big punishment not like a you're fired or you're gutted demerit or you're getting something in your review the punishment can just be something like in a meeting a superior whether it's the ceo or if you're someone says like well who did that button that looks terrible
Right.
Brad: Yeah.
100
Scott: You
Brad: %
Scott: know,
Brad: that would be devastating punishment, I think, for the average engineer.
Scott: and an engineer might say, well,
I did it. I just kind of went for it. And then it's like,
well,
look, quality is really important here. Right. We shouldn't be shipping things without having them go through design.
And so there's it's it's.
Brad: You just you just you by saying that as the leader, if the CEO said that quality is really important,
we shouldn't.
Like, you just inadvertently created an environment where things are going to feel less urgent.
Scott: Okay,
so these are all things where we might make our stakeholders not experience urgency. I kind of interested in the opposite,
though,
which is like, imagine I had a team that was working really hard, and I think I do.
How do we convey that?
How do we convey that?
To our stakeholders,
short of the most effective way, of course, which is a terrible way, okay?
Oh,
yeah,
the team's been working nights and weekends.
Brad: yeah no that's a bad way i
Scott: Oh
Brad: had i had i had a here's here's a quick example now this is admittedly a a smaller team so this this technique worked pretty well in this in the scale of the team that i was working with um but i have a feeling i'll describe it and then maybe we could figure out a way to scale it up to a larger thing um but there was like uh you know the question one of the questions came from my stakeholders is like oh well you know like
uh use an example here that's kind of a somewhat made up example but like oh well like what's what's what's qa doing like what what are they doing like what what tell me like am i getting value out of that right and
I basically kind of I was like, oh,
that's really a good point. Like there's this dashboard, you know, our sprint planning dashboard where you can clearly see like stuff moving, you know, left to right.
You know, the development team has got stuff moving left to right and eventually ends up and done.
But we didn't have like a visual place where QA was
Scott: Mm
Brad: doing something.
Scott: -hmm,
mm
Brad: Right.
Scott: -hmm.
Brad: So I was like went to the.
QA guy and said hey let's let's tweak this board a little bit so there's like a spot where like you guys do Yeah, your work right
Scott: you can see it.
Brad: and then I went to the stakeholders and said you know what you're gonna see what QA is doing
Because there's this lane there and stuff ends up there and if it sits there before it's done,
they got to get it out of there,
right?
So you'll definitionally see them doing their work because,
you know, there's that.
That level of the testing lane,
Scott: Mm-hmm.
Brad: the verification lane,
and you see stuff get in it and then you see stuff go out of it. And if you go look at any moment in that dashboard,
you're going to see like a little, you know, little RPMs meter that shows that something's happening there.
And that was a huge, yeah,
it was a huge transformation.
it was a great exercise in building trust and it gave the that department qa department like this like a sense of accomplishment right like oh yeah you know what i was working really hard now i have a way of showing you that
Scott: Okay,
as you talked about QA, you gave me a clue of another item that could be one that cuts our nose off to spite our face,
but also that we could address.
You know,
I haven't, when I'm running, you know, right now I'm managing a large team, so I'm not running an engineering team day to day.
But when I have done that,
I like to see tickets flow across the board, right?
I'm a break stuff down small guy,
right?
That's just how
Brad: I
Scott: that's,
Brad: am too.
Scott: yeah,
Brad: I am too.
I love it.
Scott: it's, you know, it's all my type A stuff.
And so because it gives you a really good signal when a ticket is sitting there.
And it's like,
hey, that thing has been in progress for 10 days now.
Like, what's going on with that guy,
right?
And so it gives you a really good signal. Okay,
so engineering
teams who
are,
would it be that are?
doing large projects where the deliverable not necessarily the tickets moving across but the actual thing that gets shipped is large units of time a month two months three months six months whatever it is large units of time just like you know that QA team saw tickets start flowing across the board
To the outside stakeholder the CEO or whomever they just see this one fat ticket sitting on their mental board for an entire quarter What has your team been doing all quarter this you've only been working on this one thing and nothing's happened
Well, I mean, a million things have we got all these tickets done.
So and sometimes it's hard,
but breaking that stuff down into another CEO is not really looking at the Kanban board,
but like they've got a mental Kanban board of like that thing. You guys have just been working on that thing for so long.
Nothing's happening.
Right.
And so figuring out a way to break those large things down into smaller things is valuable. And I want to come back to Scrum.
for a second because there's some things we can take out of scrum for this and they are
everything at the end of a sprint should be shippable the software
Brad: Yeah.
Scott: should be shippable at the end of a sprint which which
Brad: At
Scott: the
Brad: the very minimum demonstrable.
Scott: demonstrable and we in the way we use scrum these days not just at my company but everywhere nobody does i mean that's a rule that gets violated all the time and the sprint demo as you mentioned demonstrable the sprint demo and maybe perhaps a team can
mitigate the feeling of lack of urgency by leveraging some of these techniques that are already in Scrum,
which is break it down,
get it completed, demonstrate demonstrable by the end of the sprint and demonstrate it.
And that illustrates the stakeholder,
yeah,
lots of stuff is happening.
We're not sitting on a big fat ticket for three months sitting in progress.
We're flowing.
Brad: I think that is a huge,
I think that's very important.
And I think that's fully scalable.
And I think it's one of the things that absolutely an organization can do to help communicate that there is a sense of urgency.
You know, I think that Scrum and Agile can get a bad name from people who really, who feel like it kind of creates a lack of.
of accountability like there's a version of scrum that's like hey every two weeks i'm going to show you something and then we're going to come back and tweak it if you didn't like it right like that's there's a version
Scott: Mm
Brad: of
Scott: -hmm, mm
Brad: scrum agile that feels like that to people
Scott: -hmm,
Brad: that are like god i i was clear about what i wanted three months ago can you please just give it to me right so you want to try to avoid like letting the scrum turn into uh kind of just like
check-ins where you're not seeing progress right that's that's going to undermine that's going to undermine trust even more but if you are doing a good job of really sort of sequencing things and breaking things down then these periodic check-ins where we can show that we did what we said we were going to get done and it has this demonstrable element to it
um i think is a very powerful way even for now you have to with your non-technical stakeholders who kind of just have the big you know picture in mind you know the whole house being done in mind um you need to make sure that you tell them ahead of time hey look
You know, after the first sprint, we're going to show you that we're going to show you that we've got the architectural diagrams done.
You know, after the second sprint,
we're going to show you that the foundation is in and we've actually put up the, you know, the framing.
right and you got to remind them like hey foundation framing let me show you the architectural diagrams this is what's coming that you know walk them like how many i mean you you've either built a house or done a remodel right where it's like the general contractor walks you through the space and says look we've got all this framing over here you know and holds it in a this is going to be your kitchen this is going to be your kitchen someday you know
Scott: So I want to go back to urgency for a second.
to build on what you're saying so i think when someone says i don't feel a sense of urgency what they're saying is i don't feel like stuff is getting done fast enough and i want to break that down to three things stuff done fast enough okay and so we stuff we can set aside
Brad: In a trustworthy way,
in a trustworthy way,
in a way that I trust that it's really getting done the stuff I want.
is Yeah. getting done and you're not wasting time
Scott: Right.
Brad: doing it.
Scott: So I want to focus what we're really talking about is that is the first two parts of this.
The sprint demo is stuff is getting done.
So perhaps a big part of the not fast enough is the fact that the stakeholder,
whoever they are, product manager,
chief product officer,
customer,
CEO,
whatever.
If you solve the problem of them seeing stuff getting done,
I have a hunch, I know today as far as this conversation,
I have a hunch that you'll actually start to break into that feeling of fast enough,
right?
Because maybe the problem isn't really that stuff isn't getting done fast enough.
It's I don't feel like stuff is getting done because I don't have any
Brad: Exactly.
Scott: visibility into stuff getting done.
Brad: And yes,
yes, yes, yes, a thousand times yes.
So establish trust,
establish that when we say we understand what the stuff is and when we tell you how long we think it's going to take us to get it done,
that you can trust us.
Now, let me demonstrate over time that I am delivering against what the
Scott: Yeah.
Brad: stuff that was getting done in the way that I told you it was going to be best for me to get stuff done.
Scott: It
Brad: And if you're doing that, if you've established trust,
you're building trust with each of those sprints demos. You're building trust
Scott: becomes self
Brad: with each of those milestones.
Scott: -reinforcing virtuous cycle.
Brad: It's a self-reinforcing virtual cycle.
Now, it's easy to screw that up. Like if you show up every sprint and you didn't get it done and you have nothing but excuses for why you didn't get it done,
then it's going to be reinforcing negative.
Scott: Yeah. And here's another example of where we cut our nose off to spite our face.
So you say maybe not as much in a smaller organization,
but a bigger organization. OK,
we're going to have monthly or quarterly.
status updates and there's a there's a row there on the on the sheet which is like you know you know make this new thing for the customer whatever whatever the feature is right and um it just says in progress and it's every every time the ceo gets the tips like this thing's just been in progress forever you guys making any progress what what progress
Brad: Right.
Scott: are you making on this thing it's in progress when
Brad: And
Scott: will it then be done it feels like it's been months
Brad: God forbid it feels like it's been months and God forbid it slips.
because second it slips like of course that's the other thing right is the sort of like bad news needs to travel fast early you know but the problem with software is you don't if you're not if you're not doing a good job of like having like small bite-sized milestones that you know you're making progress against if you just kind of have a big milestone you kind of don't have the bad news until it's too late to make it travel fast
Scott: Yeah, that's right.
Brad: so that's another so that's another thing by the way
If that's happening in your organization.
then I think you're sending a signal that is going to be interpreted as the team's not having a sense of urgency.
Scott: Okay,
I want to digress on this for one second. I actually want to make one other point, but I want to come back to this for a second.
So when we set up a project that's like say five months, and then we know we do monthly status updates with our senior leadership team,
but we know for four of those months we're just going to have them wondering,
it's just going to say in progress, they'd be like, well, what's going on here?
We're shooting ourselves in our foot.
Okay, and then
And you just gave me a thought.
We do these status updates.
Everything starts out at the beginning of whatever time period is on track until
Brad: Right.
Scott: it's not on track. Then it becomes at risk and then it becomes off track.
Right.
And what you made me just think is, huh,
I wonder if everything should start out at risk.
And you don't get to be on track until you're really confident that this thing is going to.
land when it's supposed to land.
Brad: Yeah,
Scott: Because if
Brad: that's an interesting take.
That's a way of – it's a reframing that might really
Scott: it
Brad: make a difference.
Scott: seems true,
I guarantee you.
Brad: At the beginning of the project,
you are at the most at risk.
Scott: Yeah,
Brad: You have the most – you have the least amount completed.
You have the most uncertainty.
You are definitionally the
Scott: the
Brad: most at
Scott: most at
Brad: risk.
Scott: risk.
And we usually use at risk for when it starts to something starts to go wrong.
We kind of want to that's what we want to let bad news travel fast. Well, we better signal to our stakeholders that it's not quite going right. Let's say it's at risk.
Right.
what we really want to be doing is narrowing that kind of uncertainty go from at risk to less risk to less risk less risk maybe we start out at 100 maybe we should use a percentage there and your percentage of risk can get lower as you get closer to the ship date it should be zero um the
day before your ship oh
Brad: Yeah, well,
there is that notion of like burndown charts.
Scott: i
Brad: Those are techniques
Scott: love i love a burndown
Brad: that.
Scott: chart
Brad: that that um happens
Scott: I'm
Brad: there
Scott: such a burned out chart nerd.
okay look we've been talking for a long time here.
For anybody who's listening to us, they can't believe they've been listening for a whole hour.
This has been one of my favorite episodes,
Brad.
Brad: it's a great topic it's such a great topic and i think that it it strikes to the core of the job of the ceo right is navigating this
very important trust building dialogue between stakeholders and the engineers.
Scott: Yeah.
This conversation has made me feel like we should rebrand our podcast to CTO therapy.
Brad: I think that's how we started this, basically.
Scott: Well,
it's been a delightful week.
Brad: Yeah, thanks a lot for hanging out with me today,
Scott, and talking about this. I love that you brought this topic.
I think this was super fun.
And for all of our listeners,
what do we say?
Smash that subscribe button.
Scott: Smash. Yeah, exactly.
Thank you, Brad.
I appreciate your time today.
Brad: All right. Have a good one.
Talk to you next week.
This episode of How Many CTOs Does It Take Podcast was edited by Saffron Epigout.
Our theme song was AI Generated by Brad.
Please follow us on all the social media platforms at at How Many CDOs Pod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok and Patreon or at our website at HowManyCDOsPod.com.
And remember to rate, review and subscribe on the podcast platform of your choice.
Thanks for listening.