Org Structures and Measuring Platform Team Success
- 00:00 Introduction to the Role of a CTO
- 00:34 Meet the Hosts: Scott and Brad
- 00:47 Challenges Faced by Engineering Leaders
- 02:26 Organizing Engineering Teams
- 05:35 The Importance of Platform Teams
- 16:14 Balancing Profitability and Maintenance
- 20:50 Cultural and Process Considerations
- 25:33 Real-World Examples and Strategies
- 27:18 Contemplating a Shift in Platform Strategy
- 27:31 Defining Platform KPIs and Value
- 28:40 Customer Satisfaction and Platform Velocity
- 30:14 Balancing Cost and Velocity in Platform Teams
- 34:58 Organizational Structure and Conway's Law
- 39:19 Engineering Metrics and Success
- 42:36 Connecting Technology to Business Success
- 45:48 Implementing and Socializing New Ideas
- 52:37 Podcast Conclusion and Call to Action
Brad: I feel like one of the most important parts, if not the most important part of the job of a CTO is to be that bridge from is the business working to how is this thing called technology that I am the chief officer of contributing to that business success?
Scott: Yeah,
so welcome to How Many CTOs Does It Take podcast.
Brad: Yeah.
Scott: My name is Scott Porad. My co-host here is Brad,
Brad: Brad Hefta-Gaub.
Scott: and we're here to talk about what?
Brad: The Well,
you sent
Scott: engineering me. management.
Brad: Yeah,
you said yeah.
And you sent me a really interesting sort of list of topics that I think every almost every engineering leader runs into at some point in their career.
Scott: Yeah.
Brad: And I and I think that there's like an endless amount to talk about on these on these topics.
Do you want to do you want to kind of tee it up
Scott: like? Well, yeah.
So look,
we could do that.
This is all I want to talk about. It's the only problem.
Brad: It's
Scott: It's
Brad: always
Scott: the only
Brad: the
Scott: problem.
Brad: only problem of all businesses,
right?
Scott: It's funny.
I was just texting with a friend this morning,
a guy who's a director of engineering somewhere.
He was asking me how it's going.
And what did I say to him?
I said, well, you know, we've got too much work and not enough people and lots of tech debt. Have you ever heard of a situation like that before?
Brad: Yeah, like that never happens.
Scott: That never,
Brad: Never
Scott: ever.
Brad: ever happens.
Scott: I was going to say the topic on my mind is I've got this engineering team that I'm trying to uplift to help me better.
I think the team.
It doesn't feel like it's firing all pistons and the stakeholders don't feel like it's firing on all pistons and not all of that is the fault of the team. Certainly some of it is.
I would say there are some historical and structural and cultural things in place which make it very hard for the team to thrive.
But within that contest,
I'm doing my best.
Brad: Totally.
Scott: So let me let me tee up a topic for you.
Brad: Yeah,
Scott: totally. I mean, I got many topics to discuss.
Well, to start with this one, I'm going to first I'm going to ask you just general opinions,
then I'll give you some more detail so you can refine those so they're relevant for you. So the topic is, how do you organize?
engineering teams to be most effective and I'm going to give you just one willing to start there and then I'll start adding more details so what are your sort of philosophies or principles or ideas or thoughts on how to do that
Brad: Yeah, that's a great rich vein of learnings and failures and successes.
Man,
I hate that my answer,
my off-the-top answer is going to be it depends,
right?
Scott: Do you know Kevin Goldsmith?
Brad: I don't.
Scott: Well, Kevin's a CTO.
He was at Spotify a lot. He's a distro kid right now.
He just published a book. We'll have to get him on here.
Brad: Yeah.
Scott: He just published a book called It Depends.
Brad: Yeah.
Totally, right?
Scott: Well, what does it depend on? That's the question.
Brad: Well,
Scott: What does it depend on?
Brad: I okay.
So here's my quick answer to that.
It depends on what the high order bit challenges that the business and team are facing in the moment.
Scott: Okay.
Brad: Right.
So a good example of this might be,
let's say that the.
You know, let's say,
for example.
the stage of the of the software life cycle you know like how old is the code what state are you in a rebuild are you in a building stage are you like starting out like the current venture that i'm working with like we're so brand new right you have a um significant once you're in the legacy uh code base stage then you have to ask yourself well what are the problems that i'm facing right now
Right now,
Scott: Mm
Brad: right?
Scott: -hmm.
Brad: Like you might have a problem where like it makes sense to have like one of the classic divisions in managing your engineering team.
And we saw this at the 98.6 where you and I were both together most recently where.
You could say like,
oh,
we have two distinct business problems that we want to kind of accomplish simultaneously.
So let's have two fully fledged, fully autonomous,
fully able to execute,
fully, fully equipped teams to go take on these two different business problems. Like let's split it that way. Right.
Scott: Mm-hmm.
Brad: But you also might be like,
well,
actually, these two business problems have.
the same fundamental foundation that they need to work on top of.
So let's implement this with a platform team and then two application teams on top of it, right?
So those are two very different configurations of potentially the exact same problem statement where you intentionally choose two teams or three teams.
Right.
Scott: Okay, so let me ask you a few questions.
First,
I want to throw another it depends dimension in there,
which is the profitability of the company.
Brad: Oh, yeah,
of course.
Scott: And this relates directly to the platform team.
proposed and how it connects to that is in two ways the first is as an engineering manager what am i holding the platform team accountable for how do i measure whether they're being a successful platform team or an unsuccessful platform team is is one dimension aspect there and the other aspect there is in my experience the less profitable the company is or if they're burning money and unprofitable
The harder it is to explain to the business why you
Brad: Why
Scott: need to
Brad: you need
Scott: invest
Brad: a button.
Scott: in these things that don't seem to really directly derive revenue or
Brad: Totally, totally, totally.
Scott: profits.
So my question for you is let's just let's set aside the business part of it. We'll get there. If you have a platform team,
how do you measure?
I mean it doesn't have to be numerical it could be quantitative but I like numerical better uh you know how do you measure if they're being successful what is it what is the measure of their success in
Brad: I think that like straight out of the gate, there's a couple like there's a couple metrics that are just sort of like you put this on all all teams and all software,
which is like sort of the does it do what it's supposed to do metrics.
So those are like.
Meantime between failure,
number of, you know, sort of like SLAs, any
Scott: Mm hmm.
Brad: kind of SLA around uptime, any kind of SLA around performance metrics like, you
Scott: Yep.
Brad: know, speed
Scott: Yep.
Brad: of the services or whatever. So if you've got good, you know, quantitative metrics for measuring like, does it work?
Right.
Scott: Yep, so you have that in place.
Brad: So you got that in place. So one measurement of the platform team is if it's not working, then that's a direct measurement of like,
hey, platform team needs to make it work. Right.
Scott: Yeah.
Brad: Or if it's not working well enough,
right,
like it's you know, you've got some, you know, like you're at.
you're at three nines and you want to be at four nines you know you're at four nines and you want to be at five nines for whatever reason well those are you know those are varying degrees of is it working um and that's a and so then you're measuring like are you hitting the goal um and then of course
Well,
that makes sense,
right?
Like we agree on that basic idea
Scott: It
Brad: that
Scott: makes sense.
Brad: there's
Scott: And we put
Brad: metrics where it works.
Scott: this platform team in place so that each sort of application team wouldn't have to do this stuff on its own. We thought there was some leverage there that
Brad: Exactly.
Scott: they
Brad: We
Scott: would get.
Brad: thought there was leverage,
right?
We knew that there was this common substrate that the business wanted to go do multiple things.
They like to have the freedom and the.
the agility to move quickly on the multiple things and the people building the multiple things, these applications or these higher level things, they're all like,
gosh, we all need that substrate.
We all need a reliable substrate to work on.
We're all for building it ourselves.
Scott: You know the perfect example,
right?
Brad: Yeah.
Scott: Authentication and user accounts,
right?
You know, we got this.
big SaaS product and a bunch of different things in it. We don't need two user databases.
Brad: Totally.
Exactly.
That's a great example.
And so you get leverage.
So, okay,
so we just assumed some facts not yet in evidence,
right?
We assumed that the business has multiple applications that it wants to accomplish,
multiple application lines, multiple lines of business, multiple...
uh sort of paths if you only have one path if you're only building one thing right so again i'm going to go back to your original meta question like how do you organize a team if you only have one application i would be reluctant to make that platform application split right um
Because all you've done, if you don't have two applications or you don't have two use cases of the platform layer,
all you've done by making that split is you've just increased a barrier to communication,
right?
You've increased a barrier to autonomy.
You've introduced roadblocks that you don't really get an advantage of.
Right.
Scott: Yeah.
Brad: But it sounds like in your case,
you do have multiple kind of things you're trying to accomplish that are different enough that having them.
segregate from themselves about the things they're trying to accomplish but borrow the common the common features like authentication you know
Scott: Well, here's where my head's going,
right?
As soon as you have something like 10 engineers.
such
Brad: Right.
Scott: that you'd divide up into two work streams so that group a is building they're all built let's say all these 10 years are building consumer facing you know user facing and it could be consumers but user facing features and capabilities right and you've just divided in two so that you know this team is doing one thing and this team is doing the other thing sort of as soon as you get to two then all of a sudden the need for platform comes in
Right.
Brad: Right. And the only question is, do you you can still have the so you can have the.
Code architecture.
Differentiation and but not necessarily implement that through a team ownership.
Scott: Right, right.
Well,
I think what I've seen more commonly is the opposite,
which is you've got code that is a classic ball of mud,
and
Brad: Mm hmm.
Scott: then now you've piled many teams on this.
Brad: Yeah.
Scott: um not just two but maybe it could be two usually with two you the team can work it out small enough that everyone can get in the same room and have a conversation right you got a team of 10 engineers let's just say to keep it simple you're going to you know a third of them are going to be senior engineers a third of them are going to be mid-level a third of them are going to be junior you can get everyone in a room and basically work out the details there what happens i've seen is
Now we're going to pile 15 teams on this thing and
Brad: Yeah, totally.
Scott: I don't know team seven
you want some feature and authentication and goes and just hacks it in there because they're not really focused on authentication they're focused on doing whatever they want to do to push whatever business goals that's in product manager brought to them ahead
Brad: Right.
Scott: and okay so team seven does that but then you know every team does that once a year for seven years and you've got what's 15 times seven it's like you know you get 100 hacks on the authentication system
Brad: Right,
Scott: and
Brad: right, right.
Scott: now it's just a
a brittle mess and somebody comes along and says hey let's make this integrate with octa or something and i'm making this up and it's just like oh my god this is this is a disaster and so then someone says well we need a platform team to own authentication and then the platform team is supposed to somehow go like extract all this out of the monolith and then so that's like their first big project extract it out into some nice service and then
sort of their customer becomes the product
Brad: all the other teams yeah
Scott: all the other teams um
Brad: sure
Scott: and like rinse lather repeat about for however many domains you have in your application which let's just say it's going to be somewhere between seven and fifteen
Brad: right but that's it but what's okay so like if we rewind though like i think that
I totally understand the way you're going and it's the way that we almost always go,
right?
Like we immediately start having the conversation about the teams and who's the ownership.
And I guess the thing that I would say is maybe that's what we should be challenging and that the first principle is not the who's not the how we divide who's responsible.
But maybe the first principle needs to be,
are we aligned on sort of like the code paradigms? Like, are we aligned on what we consider correctness to be?
Mm-hmm. Because what I think your story is really telling.
You're sort of saying like every time the team went in, all the seven different teams and went in and they sort of like, you know, layered on their opinion on the authentication service.
Right.
It sounds like in that history,
which,
of course.
You've come too late, right?
Like we always show up as the CTO hired to fix things and it's like,
yeah, there's already 10 years of history,
right?
Scott: Right, right.
Brad: But to me, it's like the reason that a lot of organizations go with, well,
I need a platform team,
the authentication team,
and they own the code,
they own the authentication code,
and they become essentially gatekeepers of the functionality and the code itself.
And, you know, what you're partly what you're saying is we need someone to give a damn.
We need someone to give a damn about this code and to defend it and to be its steward, to be its code steward.
And a very, very easy way to do that or a way to sort of like enforce that is we're going to give you a team,
we're going to make you get control and everyone has to come through you.
Scott: Yeah,
Brad: But
Scott: so that's we.
Brad: not the only way to solve that code problem.
Scott: That is true.
Now let me, this is interesting because I've been kind of going a different direction recently, but I want to explore, and I'll tell you what that is, but I want to explore this for a second.
It comes back to that profitability question.
If I am a profitable business,
okay,
let's assume the features of my authentication system have been defined.
It's all set.
The system has been built.
It is operating correctly.
A less profitable business will say,
I need to redirect these resources to go and work on something to make me more profitable.
A more profitable business will say,
okay,
well,
I can afford to have a team here just maintaining this thing.
Right. Because there is a maintenance cost to it and I can afford
Brad: Right.
Scott: that.
But a less profitable business will say, I can't actually afford that right now.
I need to put as many resources as I can. I need to devote to getting the profitability.
I think that adds another dimension of complexity there,
which is the give a damn.
It's hard for an unprofitable business to continue to give a damn.
because they want to redirect the community to have people that give
Brad: Right.
Scott: a damn.
So you said there's other ways to accomplish that besides having a team.
What would that be?
Brad: I have to rewind to sort of give you the answer to that,
but let me kind of give the answer and then I'll rewind. This is something you and I have talked about,
the rewind we've talked about is.
You know, the classic question,
whenever you're whenever you're whenever you're looking at a organization,
you're trying to up level, you have to answer the question like, is it is it a people process or tech problem?
Right. And it's almost always a combination of the three. Right.
Scott: Mm-hmm.
Brad: And so my partial answer to the.
There's ways to give a damn is you
can institute things like clearly articulating accountability or changes to code. Right. So,
for example, you can say all code.
all code must be you can implement processes that sort of force give a damn on code that is community owned right like it's the comedy it's it's the tragedy of the commons right is the problem that we're trying to deal with and and so and
Scott: Yeah, that's true.
Brad: so
The solutions to the tragedy of the commons is, yeah, you can put an armed guard up and make everybody go through them, right?
Scott: Yeah,
Brad: Or
Scott: yeah,
Brad: you
Scott: that's
Brad: can
Scott: the
Brad: create
Scott: team.
Brad: a team that owns authentication or you can create a culture where everyone values the commons, right?
Scott: Yeah,
Brad: And.
Scott: that's very interesting,
right?
Because in that unprofitable business,
the less profitable the business is,
the less the commons are valued.
Brad: Well, and it's funny that you say that. That's a really great line.
It's funny. I was on my run this morning and I was thinking about getting together and talking with you about this. And I was like, I was like, you know, what's interesting? I think I think software engineers,
computer scientists, people that we hire is basically like in our teams. Right.
I think that they have a natural kind of innate knack for understanding if things work or are working.
Scott: Mm
Brad: And
Scott: -hmm, mm
Brad: they don't always necessarily have the answers to how to make it work,
but they definitely know when something's not working,
right?
Scott: -hmm.
Brad: And I think that applies to not just their code and the way they think about building code,
but I think that applies to they look around the organization and if they might not be able to tell you, hey, I know why this business isn't profitable,
but.
Scott: Mm-hmm.
Brad: They probably get this sense when it's not profitable,
like there's
Yeah.
something wrong here.
Yeah.
Right.
And it's not just the business, but it could also be the processes.
Right.
Like if you've got processes in place and they're just like,
yeah, I'm following the process, but it just seems wrong.
You know, they wouldn't necessarily be able to tell you how to change the process,
but they're definitely going to have this instinct of like something's not right about this process.
and the same would be true for culture right and so yeah i think that like getting really clear with engine like don't bullshit an engineer right like getting really clear with them like hey guys like the the auth system is fucked up right we agree right
Scott: Yeah,
Brad: and
Scott: we agree.
Brad: and someone's gonna go like
Yeah, you're right. It's fucked up.
Well,
And maybe.
you mentioned an interesting
Yeah, go ahead.
thing about culture,
which is what I've seen in a lot of places is where sort of the business side of things is focused on its – how should I say this right? Because the business and the engineering, they all have the same goals.
What I'm trying to say is – I don't know how to describe this exactly. Let me do my best.
when the near-term business requirements, and those near-term can still be within a couple of years, when the relatively near-term business requirements and demands and focus overwhelm the caretaking of the commons, right?
And so the business is kind of cutting off its nose despite its face,
right?
But it's really hard to explain to a business person the value of those comments because we can't put it in – the language they speak is dollars and cents,
right?
Yeah,
And so when I say, look, when an engineering leader myself already says,
look, trust me,
you do not want to let the authentication system decay.
right.
And they're like,
yeah, but what's it – tell me how that affects my P&L.
Right, exactly.
Because that's the because I'm playing a game and that's the scorecard I use.
Yep.
And so I'm like, I don't really so it's interesting.
So we talked about culture, but it's interesting. A part of that culture, I guess, is what I'm trying to say is the balance or the effect of the balance between sort of.
In the tragedy of the commons, you've got the commons and then I guess you've got the consumers of the commons, right?
I don't know what you call those people,
but it's the balance between those things.
And I guess as engineering leaders, it's our job to really build into, you know, it's hard, but to build into the culture that the business,
the consumers of the commons understand the value that they want to care take because they understand that caring for the commons is caring for their own business.
They're almost cheap, right?
Well,
and so 100% agree with that point,
right?
Like the – if we're basically like talking about like the simple example of the commons is like it's the public square and there's litter all over the place,
right? Well,
the – if –
You know,
this is a you know, there's an element of like if enough people say I'm going to clean up the litter and I'm not going to ever litter.
then eventually
Mm-hmm.
like it becomes like if it's completely shrewd with garbage then you're going to have to do some kind of intervention but if you can prevent the garbage and the litter from piling up then you're better off now the one thing i would i i'll challenge you a little bit here because i think that um you one interpretation of this is to say hey
business owners you're pushing the team in such a way that they're unable to maintain the commons right and yes that happens and yes that's
You got to work that side of the equation to be like, hey, business owners, like we need to think about your ROI.
We need to think about this tipping point where if you never maintain your law,
your authentication system,
you know, here's your ROI on your authentication system.
If it falls over and gets broken,
then none of your customers can use your software and use your product at all. And then your whole business goes to zero.
And in that particular example, right,
like you can you can retell the stories of past lives,
right,
because that was one of the very real issues that we dealt with in our past life where we use this external authentication provider and it was the thing bringing down our SLA, right? Like it
Oh,
was
really?
the yeah,
it was the thing that prevented people from patients and doctors from logging into the app,
right? It
Interesting,
interesting.
was like.
you know we're like getting these you know we're getting these like you know fry zero you know problems like hey the authentication is down and we had to make the case like we got to we got to get off of this system it's it's killing us yeah
I've been kind of advocating for a slightly different direction with my team.
So I told you when we first started talking general thoughts, now we'll just dial in a little
bit. yeah dial in
Okay, I've got 120 engineers.
plus product managers designers etc etc all hacking on one monolith that is 15 years old as you can imagine the tech debt is high cycle time velocity wherever you want to say the ability to get things done rapidly and nimbly is slow
Yeah.
it's a it's a multinational app meaning it serves u.s canada and europe so there's complications just not by itself so and you know everyone's unhappy with everyone you know business people are unhappy with how long things take you know there's legitimate reasons things takes long like hey we got to do it for all these countries like it's just you know there's just a bunch of work there but
And there's, you know, a lot of it's driven by tech, a lot of it's driven by organs that are, okay, so this org is designed, as you would kind of think,
there's an infrastructure,
kind of infrastructure as a service,
platform as a service,
applications on top, software as a service on top of it.
That's the kind of idea.
And the frustration I've had is like,
when I say this sort of the platform person.
How do I know, how do you know if you are doing a good job, right?
Right.
If you were to present me a single slide with no more than seven KPIs on it,
which tell me the story of here's how you know if my team is doing a good job,
what would be on it,
right?
And, you know, it's like because that platform layer has many different domains in it,
it's like, well, it's all over the place, right?
So I'm kind of contemplating a shift, and I think it's an appropriate shift, or you said it depends,
for this phase.
Hold on a second. Before you talk about your shift,
I want to ask you a question.
When you asked that platform leader for their KPIs of their platform's performance,
in your mind's eye, what did you have their answer be?
I don't know.
I mean, there's the correctness piece,
The
right?
Are correctest beats that's on the list.
these systems up
And then I have another one. I have a second one.
and running properly?
Are they secure and compliant?
Things like that. That's very easily.
But what I didn't know is.
How to measure what is the value that these systems are providing to the business? When you say a platform guy,
you've got 38 engineers working on stuff to
What are they doing?
move this business ahead towards its goals. How would you?
How would you justify or maybe not justify isn't the right word, but how would you illustrate or explain this is how you my team,
this is how I know if my team is doing a good job moving the business ahead.
And I guess maybe to me, just, you know, that sort of correctness uptime layer is the system working is insufficient.
Totally it is.
Okay,
There's another big half of this I think you have to also include in that list.
let's hear it.
It is effectively,
are my customers happy with my product?
Right.
And my customers are the application developers building on top of my platform as a service.
And how do I measure their happiness?
Their happiness is going to be something like the velocity that my customers report back.
about their ability to move quickly because
Yes.
of my platform and so then the specific so for example i might have like you know i mean i can come up with several different like you know um uh quantitative measures for that so it might be something like you know uh
You know, velocity slash story points of application teams that touch platform APIs.
Right.
Mm
So if
-hmm.
you can measure like.
application teams build you know new features at a rate of you know x units per week
So
or you're something
essentially
like
getting
that exactly
into your Dora metrics,
the cycle time of your application teams.
you want to you want your cycle time of your application teams to be the metric of is your platform delivering value
Okay, that's a whole,
this is like a whole other 74 podcast we could talk about in terms of velocity.
But let's assume that's correct for a second.
I did not talk to you about this in advance because you were actually walking into my trap.
Go ahead now tell me your plan
Well,
I sort of said to myself,
fundamentally, we're having these platform teams because we think they are making.
are what I refer to as product teams or application teams.
We think they're making the application teams faster.
That's
Yeah, why the
we do it.
app teams get leverage from the fact that we have a platform.
That's why we do it.
So I've kind of taken these, but not all of them.
Some of the platform teams,
we do it because we think it saves them money.
like actual dollars and cents i'll
Like you could a platform team that owns authentication could all.
give you a concrete example we have a we have a payments and commerce team right and they're working on things like uh you know a simple project that we're going to write it's not simple but like a straightforward way to explain this different types of retries when things fail
like we have transactions that fail and we sometimes don't actually the transaction happens through the application and we have money transact but we actually don't ever collect it from someone's credit card so we lose money right and so
You know, for instance, a variety of reasons,
right?
It could be bugs, it could be design of the system, whatever.
And so they're working at making our making us collect a greater percentage of our actual money so that we're more profitable.
That's
Yeah.
what they're focused on. Okay, so I've taken all these platform teams and infrastructure teams and put them into two categories.
And there's some imperfection here because nothing is ever just one
thing. Yeah,
But
of course.
the two categories are either your primary focus is generally
trying to generate velocity or reduce cycle time or your primary focus is trying to reduce cost actually I shouldn't I should say differently than reduce cost because this is a sticking point with me your primary focus is to operate within the cost budget that has been allocated for this thing right because yeah I could reduce as I said with them I can reduce the cost to zero by turning it off so
Right, exactly.
um
If you need to deliver.
To deliver your service in the envelope of the budget we gave you.
Right, right.
So, and the cost,
I also say this, the cost is balanced by that correctness, meaning there are two, those, those
And
costs
arguably by
actually.
that velocity too.
Like eventually you get if you if you if you get sophisticated enough about this,
the cost of your platform,
if if if your platform costs you a little bit more, but it generates way higher
fair
velocity
yes
from
good
your app teams,
point that
you may choose that
yes
trade off. You might choose that.
is right so i guess yes so both teams the the
the velocity team and the cost team are both have a guardrail which is correctness and then on top of the correctness one is focused you need to operate within the budget we have which is you know x dollars per transaction or cents per transaction what it is and the other is you need to
reduce our cycle times by whatever target we have and so the reason i'm kind of trying to move that direction is i mentioned we have about 120 engineers here and each of those teams that that group of people is let's just say 50 people altogether and so i can divide those up i have a leader for each of those groups and i can say to that leader very clearly hey brad your goal we have got a we have um you
We have budgeted $1.18 per transaction in cost this year between hosting and credit card fees and all that kind of stuff.
Your job is to keep the system correct and operate the system within that budget.
And if you're doing that job,
then if you can come to me and say,
look,
Scott,
I'm doing this.
Right.
you're doing a good job high
Yeah, exactly.
five right and so um and
And hell,
within that
if you can even beat that number, then higher five.
But your goal is to hit that number.
goal is to hit that number and within let's say 25 people that we let's say we divvied up equally you've got some you're empowered to figure out how to get there right
Yeah, totally.
and same with the velocity person i can say look
look, your goal is correctness and then figuring out how to reduce the cycle time of these application teams and you get to choose how to do that.
Yeah, totally.
And if you can come and so what I like about this approach is it is sort of outcome centric.
It is not software centric. Now the challenge with this approach is Conway's Law.
Right.
as always but we've already got a i already have a conway's law problem which is it's a monolith anyhow so we need to decompose the monolith and maybe that velocity team will say hey we think the best way to solve to improve cycle time is to yank some stuff out of the spondyla or maybe they think it'll make even make the development environment better or maybe they think it'll be make the staging or the cicd pipelines better i don't know what
Right.
Okay.
Maybe it's maybe it's refactoring the front end framework one more time or,
I
you know, I
love everything
What
you're saying.
do you think of this idea?
I love everything you're saying. I love everything you're saying.
One of the questions that pops to my mind is, how have you solved the ownership give a damn problem?
I assume that these two teams are both operating within the same portion of the monolith.
um it's yeah well no not necessarily i mean like i haven't totally you know okay how to solve the give a damn problem it's
Oh, do they
definitely well
share code?
everybody shares code because it's all one big thing um but uh you know look let's think about this
In the velocity team,
right,
I'm taking, so one of the things I'm trying to do with this is not kind of have the teams within there be as defined or at least giving these teams the ability to redefine them as they see fit.
But the ones that I'm taking and bucketing together in the velocity space is what we call the web and mobile platform team.
So those are basically the teams that are.
making it easier for our web and mobile developers to to do
Build cool shit.
their work
Yeah.
yep and i should note for the for the audience right i'm working on a consumer internet product right consumer internet product
Yeah.
service right that's what i'm doing here so it's basically web and mobile clients with a back end you know it's pretty pretty standard databases messaging pretty ordinary so in that velocity you're gonna have the web and mobile
We have a test automation team.
We've got, there's four in there.
Oh, there's test automation.
We have a quote unquote developer experience team,
which kind of ends up becoming the junk drawer team.
In
Yeah,
theory, they're supposed to actually be working on engineering philosophy,
but if they
you don't have
don't a really.
junk, if you don't have a junk drawer team,
you, you, you.
You aren't really in business,
I guess.
it's true um so but they're supposed to be the engineering velocity team but they're kind of end up being junk or two and then we have this thing that we call core services right which is like we're authentication bits okay on the cost side we've got devops security
payments like i mentioned to you and uh what's the fourth one oh uh support uh you know support experience and uh you know that kind of in terms of helping our support agents be more efficient or resolving issues
Yeah.
dispatching on things getting our sports those are the cost side of it so we've got this little bucket right now which you know this little team that we call core services which is the bucket that owns you
Like what are the projects on their roadmap for like the next year or six months or whatever upgrading authentication upgrading the message bus,
right? So like they kind of own those pieces
The commerce the payments team sort of owns the commerce piece
The support team sort of owns
the commerce the the support tooling but they're all kind of within this big monolith so and there's other parts that um that
How
aren't
big sure of a how okay,
so have you rolled this out you're
well no i'm just having this conversation with people now to talk i'm trying to i'm trying to say like hey i think we could be more effective
socializing
if
the idea and
i think we
what's
could be
the reaction
more effective
what's the reaction
Well,
I get a lot of funny looks because people want to have it, they want to, they hear about Conway's Law and they say, well, we want to have the organization reflect the software we want to have, which is an infrastructure layer,
a platform layer, an application layer.
And my response is I get it.
But what I'm actually thinking about is kind
of.
Scott: management slash effectiveness i'm really thinking about that thing which is as a leader of a team as a leader of a group or even a team how do i tell people if i'm doing a good job
because i think this gets this is going to get to another thing which is like a topic for a whole other conversation i think our industry has a disease and the disease is we're a bunch of people for whom straight a's isn't good enough
Brad: Mm-hmm.
Scott: And so like we have all these engineering teams and nobody ever knows if they're doing a good job and the pressure on them is immense to always do more because businesses by their nature always want to have more.
And I think that causes a lot of unhealth and dysfunction and frankly lack of effectiveness.
Brad: I think I've probably told you this before.
Back a couple of companies ago,
we had an operations,
you know, we were running an online business.
We had a weekly or maybe monthly operations review where all these different teams have metrics and there was I remember this.
one situation that really struck me there was somebody they had an SLA I can't remember exactly what it was let's just say they had an SLA if something had to happen under like 10 seconds okay and you know we're doing this review and the person leads that group says well last month we were at 12 seconds we did some work we got it back down under our SLA at 10 it's down to seven seconds and we got some more things we're going to work on this month to get it to five
And I just remember turning to that person saying,
I don't get it.
Like you're within the SLA.
Why would you keep on working on that when you've got other problems to solve?
Or implicit in that statement is if there's nothing to do, then we should go reapply those engineers to work on something
Scott: Oh,
Brad: else in
Scott: 100%.
Brad: our business because our business has agreed that 10 seconds here is a satisfactory SLA for this thing.
And what struck me about that so much was that feeling of being good enough. I wanted to say to this person,
like, hey, you're good enough. You've achieved
Right.
the goal.
Yeah.
Like, be happy.
Yeah.
And something,
there's this illness in our industry which we are never satisfied.
Ever.
And so part of what I want engineering leaders to be able to say,
this is how I can tell you if my team is doing a good job.
is actually believed that, well,
that's important in itself,
it will create positivity and success begets success and then morale will be positive and there'd be a bunch of positive things that come out of it over the constant like we're not doing enough, we're not doing it fast enough, nothing's ever good enough,
etc,
etc.
Scott: Right.
Okay.
So everything that you just said resonates with me. And I think that, again,
like I would.
I would kind of go back to first principles.
And I think that the challenge of saying to a group or an engineer,
an individual engineer,
an engineering team,
a group of engineering teams,
the challenge of saying to them of what does success look like for you? How do you know if you are delivering value,
right?
Brad: Management 101.
Scott: It's management 101,
right?
And I think that one of the one of the this is this is to me the most important part.
I feel like one of the I feel like one of the most important parts, if not the most important part of the job of a CTO. How many CTOs does it take is being that bridge between we are a business.
And there is no question about how the business is measured to be a success.
Is it profitable?
That's the only answer that matters as a business.
To be that bridge from is the business working to how is this thing called technology that I am the chief officer of contributing to that business success?
positively or negatively?
And what am I doing to make it positive,
right?
Brad: Mm hmm.
Scott: And that bridge, that mapping of the business to the why we even have a technology group at all,
that's the core of our job as CTOs.
Brad: I say this all the time. If, you know, if they could do it faster with smokes, faster,
better,
cheaper with smoke signals.
smoke signals were once modern technology they
Scott: Exactly.
Brad: would do it that way today interconnected apps are modern technology that's how they're doing it in the future it's gonna be something else they're gonna do with this is just a means to an I will minor point I will take issue that the goal is not always profitability but we'll set that aside second
The
Scott: The business business, whatever
Brad: yeah.
Scott: the business objective is, let's let's be clear about that because it could be like it could be could be hyper growth.
It could be whatever.
Right.
But ultimately in capitalism,
it's about it's ultimately in capitalism.
It's
Brad: At some
Scott: about.
Brad: point it becomes about profit.
So yeah, that's right.
I think what you're saying is, well, what I hear you saying is our job is to connect what we do with.
We have people who hired us to do it and yet to
Scott: And me and
Brad: this approach is
Scott: to me,
Brad: going to that's right. is going to do that better
Scott: And well,
here's the point, right?
I said bridge.
Right.
Because.
you've got to explain to the business owners like why do we fucking matter at all like why do you even have us why aren't you just using smoke signals you should be using us because dot dot dot right
Brad: Yeah.
Scott: you're explaining to the business owners that but you also have to be the bridge we also as ctos have to be the bridge to these engineers to connect them to the business
Right.
Brad: Yeah.
Scott: Because as I said earlier,
like innately, they know when something's not working. Right.
They know if we're treating them like mushrooms. Right. They're not going to they're not going to stand by to be just kept in the dark and fed shit.
Right. They they know that they have this innate sense that are they are they adding value? Is the business working?
Is my contribution doing something?
something right so
Brad: Yeah.
Scott: helping them connect that helping both sides of
Brad: Yeah.
Scott: this conversation connect that's the key
Brad: I think that's right.
I mean, I feel like I'm getting validation for this notion of where I'm trying to push my team.
Scott: Oh,
Brad: he
Scott: 100%.
Brad: was that correct gotcha
Scott: Yeah,
Brad: so
Scott: I think so.
Brad: is
Scott: And it's
Brad: dhg approved i'll tell everyone that
Scott: a VHE approved.
But I'm also sort of saying like, I think part of your next step is to socialize this, connect with your engineers by helping them really interrogate the question of how am I adding value to the business?
Brad: that's part of an island you know the thing put the engineer i'm trying to put the engineers in a position which engineers are good at which is solving problems if
Scott: Totally.
Brad: you give i'm if you give an engineer engineers are smart you know not unusually smart but they tend to be a smarter lot and if you say look here's a chart and make this go up and to the left or down to the right or whatever you want to say
They will find ways to do it. They're smart.
Scott: Yeah.
Brad: Like, oh,
Scott: Give an engineer a problem,
problem solved.
Brad: yeah,
Scott: Give an engineer the wrong problem,
wrong problem solved.
Brad: that's right.
We're so busy climbing up the ladder,
we neglected to realize it was leaning against the wrong house.
That's exactly right. Part of me feels like by zooming out a little bit and saying to an engineering leader and a group of engineers,
this is the metric I want you to move.
Not these are the software systems I want you to run, but this is the metric I want you to move will free them to do what they're good at.
and probably do some things that aren't very sexy which will make a real difference so I'll give you a concrete example there's all this talk in our organization about like let's build these teams to build these new platform domain services blah blah blah but there's these other people saying you know our development environment is really slow
and it's hard to get the monolith is so big that's kind of hard to run locally and it makes it really hard to test things and also you know our business it's hard to get the data in the right condition for doing QA so we don't do a lot of QA locally so
Scott: Yeah.
Huge problem.
Brad: There's other people out there saying,
if we want to help engineers go faster,
fix these problems.
Don't make yet another domain service that's halfway complete and doesn't have a team to maintain it and so
Scott: And I think
Brad: forth.
Scott: that's a great example of, right,
what I said earlier,
which you had already kind of come up to the conclusion yourself. I was saying like a measurement of a platform team is correctness.
cost of you know cost of running it and then are my customers happy customers being these developers that are using the platform right and
Brad: And the measurement of happy is cycle time.
Scott: and the measurement of happy is probably cycle time right but that's a great example where would you know okay so let's let's play this out should i
work on making build times faster and local debugging practicable or
Brad: Mm-hmm.
Scott: could I add a new
authentication layer that is you know one function call and everything else gets handled right whatever I'm just making up two examples those are both great sounding projects
One of them improves the, you know, one or both of them, but one of them improves the cycle time of more teams more than the other.
And whichever one it is, is the one they should be empowered to go do.
Brad: That's right.
And that's their choice.
Scott: Yeah.
But they need to have it through that framing,
right?
Brad: Mm-hmm.
Scott: Framing is not,
well,
I added more APIs,
right?
Like the classic like, you know, how to measure engineering efficiency,
right?
The joke of clocks,
like let's use thousand lines of code as our measurement, right?
It's the world's worst measurement of engineering efficiency.
But you could pick a hundred quantitative metrics.
or a platform team that would all effectively be clocks right like number of APIs you know
Brad: Right.
Scott: who fucking cares an API is not an API unless it's being used to improve the you know cycle time of your app teams I
Brad: Yeah, that's right.
Well,
Brad,
this has been helpful today.
I feel like I've solved it.
Scott: all right
How
Brad: I'm
Scott: many
Brad: just going
Scott: videos
Brad: to take this
Scott: does
Brad: recording and
Scott: it take?
Brad: just
Scott: In this case, two.
Brad: I'm just going to take this recording. I'm going to sit my whole team down like when we were in elementary school and the teacher rolled out the VHS cart.
Scott: Yeah.
Brad: And actually pre-VHS cart for me, it was rolled out the film projector.
Scott: Yeah.
Brad: And I'm going to say, kids,
watch this video.
Scott: Love it.
Well,
I love to hear like let's get together a week from today and we'll hear about what kind of resistance you ran into in trying to pitch this idea.
Brad: Yeah, well, I've been I've been socializing it for the last week.
And, you know, the resistance isn't strong.
It's just not quite how people imagine it. There's there's been a little bit of a culture.
a lot of people have been involved in improving velocity and they're kind of they're concerned about well you know I still want to be involved in that and I'm trying to still look it's not that you I'm not saying we're only putting our velocity efforts into this one team I'm just trying to say like this is how this team can tell us they're doing a good job and this is how this other team can tell us you know the cost this is how they can tell us that they're doing a good job and
Scott: Yeah
Brad: It's not perfectly clean because I mentioned for instance that payments team Well, they're also working on some new capabilities for payments like, you know the ability to do say buy now pay later that kind of thing,
right?
So it's not perfectly clean
Scott: But Maybe
Brad: at least directionally it allows me to say to a group people like
This is the target and this is the target the business cares about
Scott: Yeah, it's not wrong to have multiple metrics that you're shooting for.
And so maybe having them both have both metrics is reasonable,
but tell them that you currently want the dial of the one team set aggressively towards improved velocity of your users and you want the dial of the other team set more aggressively towards,
you know, hit your cost metric, you know, run your service correctly on.
in the cost envelope that we've given you and the fact that you know in in q2 2024 that's where i've set the the dials um uh
Brad: Mm-hmm.
That's clever.
Scott: you know we might come back we might come back in q3 or q4 and adjust your dials slightly differently uh
Brad: Yeah,
that's right.
Scott: hey this is another really great episode of how many ctos does it take podcast um
My co-host,
Scott Porad. I'm Brad Hefta-Gaub.
Thanks for taking the time to listen.
We hope you got something out of it. I know I got something out of this conversation.
And what do we like to say,
Scott?
Remember to smash that subscribe button,
rate and review.
And thanks again for spending time with us today.
Brad: This episode of How Many CTOs Does It Take podcast was edited by Saffron Epigal.
Our theme song was AI generated by Brad.
Please follow us on all the social media platforms at at HowManyCTOsPod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok,
and Patreon, or at our website at HowManyCTOsPod.com.
And remember to rate,
review, and subscribe on the podcast platform of your choice.
Thanks for listening.