0:00
A lot of teams hear internal developer platform,
0:02
and they immediately think new portal, new dashboard,
0:06
new interface. But that is probably not where
0:08
this is going, because the real problem was never
0:11
just we need another place to click. It was always
0:14
too much friction, too little context, too many
0:17
handoffs, and too much time between idea and
0:20
production. And now with AI and coding agents
0:23
starting to change how work gets done, that question
0:25
gets even sharper. If developers are spending
0:28
less time clicking through dashboards and more
0:31
time working with agents, then the platform layer
0:33
has to change too. It has to become less about
0:36
UI and more about context, automation, and safer
0:39
paths to action. Hey, I'm Brian. I work in DevOps
1:00
and SRE, and I run Tellers Tech. This is Ship
1:03
It Weekly, where I filter the noise and focus
1:06
on what actually matters when you are the one
1:08
running infrastructure and owning reliability.
1:10
Most weeks, it's a quick news recap. In between
1:13
those, I do interview episodes with people building
1:16
tools, running teams, and thinking hard about
1:19
where platform engineering and DevX are actually
1:21
headed. Today is one of those conversations.
1:24
I'm joined by David Tuite, founder and CEO of
1:27
Rhody. a managed internal developer portal built
1:30
on Backstage. And this one is really about what
1:33
IDPs are for, how teams should think about them,
1:36
and how that changes as agentic workflows become
1:39
more normal. We talk about the difference between
1:41
a platform and a portal, the three big problems
1:44
teams are usually trying to solve with an IDP,
1:47
why adoption is often more of a human problem
1:50
than a technical one, and why a lot of teams
1:53
should start with automation first, not just
1:56
a service catalog. We also get into self -hosted
1:58
backstage versus managed backstage versus more
2:02
opinionated SaaS options. What trade -offs actually
2:05
matter there? And why the future may be less
2:08
about single pane of glass dashboards and more
2:10
about packaging the right context for humans
2:13
and agents at the moment they need it. And maybe
2:16
my favorite part of the conversation is that
2:18
David does not really answer this from a hype
2:20
angle. He keeps bringing it back to something
2:22
a lot more useful. Talk to your users. Define
2:25
the real problem. solve what painful is, and
2:29
do not build a platform strategy around a fantasy
2:32
version of the future. If you like these kinds
2:35
of conversations, follow the show wherever you
2:37
listen, subscribe on YouTube, and check out shipitweekly
2:40
.fm or tellerstech .com for more episodes, show
2:44
notes, and everything else that I'm building.
2:46
All right, let's jump in. Today, I'm joined by
2:53
David Tuite. He's the founder and CEO of Roadie.
2:56
Roadie is a managed internal developer platform
2:58
built on Backstage. And David's got a strong
3:01
take on where IDPs go next as coding agents become
3:04
normal. David, thank you for joining me. No problem.
3:07
Thanks so much for having me. Yeah, I've been...
3:09
kind of around the IDP space since its genesis,
3:12
I guess, about five or six years ago. I was originally
3:16
a software engineer and then an infrastructure
3:17
product manager at Workday. We built a IDP internally
3:22
inside Workday before IDPs were a thing, before
3:25
Backstage was open source, before companies like
3:28
mine existed, obviously. And so we kind of learned
3:30
some of the lessons through that process. We
3:32
experienced the pain points of why people want
3:34
to have an IDP. And when I say IDP, what I mean
3:36
is internal developer portal. as opposed to platform.
3:40
But yeah, we experienced the pain points of why
3:42
you would want one in the first place. And that
3:44
was what gave me the impetus to start Roadie originally.
3:48
Give me the thought behind platform versus portal.
3:51
Yeah, well, the way I differentiate them... is
3:54
kind of around the goal of what they're trying
3:57
to provide. So platform, I think about being,
4:00
as being deeply integrated, like vertically integrated
4:04
throughout the stack. So it's not just the visualization
4:07
of what's running and where and so on, but it's
4:10
also the orchestration. It's what is deployed
4:13
where, how do I move it to something else? And
4:15
it'll try and control that entire stack. Whereas
4:19
a portal, I think, and this is not necessarily
4:21
true, but as a general rule is a thinner layer,
4:24
which is trying to sit more broadly across more
4:27
of your stack. So how this manifests itself really.
4:29
With a platform, you often have like a pretty
4:31
high initial setup cost where you literally have
4:34
to move everything onto the other platform. Whereas
4:37
a portal should be more able to kind of work
4:39
with whatever you've got, integrate with the
4:41
tools that you already have, and just give you
4:43
a unified interface across all of those tools.
4:46
So if a team was deciding between self -hosted
4:49
backstage versus a managed backstage or another
4:52
IDP, what signals do you think matter most? So,
4:55
I mean, well, let me maybe take it back a step,
4:58
if you don't mind. and talk about why you would
5:01
want to have a developer portal in the first
5:03
place. So, because if you can answer that question
5:06
first, it's usually a good place to start when
5:08
it comes to which solution should I have, right?
5:11
But typically, and this is, I recommend that
5:14
people do this all the time, but try to define
5:16
the problem first. And so what I see out there
5:20
in the marketplace, and this has been broadly
5:22
true, I think, for the past five years that Backstage
5:25
and other technologies have existed, is... three
5:28
different problems or three different categories
5:29
of problems, I would say. So the first one is
5:31
that what I would call the discoverability problem.
5:34
People feel like there's too much software. There's
5:36
too many humans producing all of this software.
5:39
And it's just difficult to answer basic questions
5:41
about, you know, where are the bills for the
5:43
XYZ service? Does it even have bills? Who would
5:45
I go to ask in the first place? And obviously
5:48
that... That extends to, or the complexity of
5:51
those questions is multiplied by the number of
5:53
different tools that you're using, the number
5:54
of services that you've got, the number of humans,
5:57
and so on. And so that becomes a problem in and
6:00
of itself. Really, what you're trying to do there
6:02
is get the right context to the right humans
6:04
at the right time. And we'll talk about this
6:07
later on, but that problem is probably changing
6:10
quite a bit as we become more agentic. The second
6:13
category of problem is around speeding up the
6:16
path to production. Really like speeding up the
6:20
time it takes from an idea in a developer's head
6:22
to a service which is actually running in production.
6:25
There's typically, I mean, back when I was at
6:27
Workday, we had a 40 -page Confluence document
6:30
full of checklists that you had to go through.
6:33
Teams talk about ticket ops a lot. Most operations
6:36
require opening a Jira ticket against the platform
6:38
team and waiting for it to be done. You want
6:40
to kind of take away all of that. and essentially
6:43
provide self -service automation to the developers
6:45
who are running their software on the platform.
6:47
And then the third category of problem is really
6:49
about putting guardrails in place to ensure that
6:53
software which is running on the platform meets
6:56
a certain set of requirements, right? So this
6:58
could be simple things like, you know, if you
6:59
want to have your software running on our platform,
7:02
you should have a readme in the repository, right?
7:04
And it can extend to far more complicated things
7:06
around using the correct Docker base image, let's
7:09
say, that the platform team has just released
7:11
to run your software on the platform. And really
7:13
that's about improving homogeneity, trying to
7:16
make it a more consistent environment in the
7:19
platform. to improve reliability and stability
7:22
and speed. So those are the three kind of ways
7:24
that people typically explain their problem when
7:27
they originally come to me. And that's the job
7:29
of an IDP is to try and solve one or more of
7:33
those problems for a team. Does that make sense?
7:35
No, totally. So with those three areas of focus
7:38
in mind, is there a overwhelming majority like
7:43
common? problem statement that you see over and
7:46
over again? Yeah. Well, they typically always
7:49
have the discoverability problem. So they'll
7:52
have that problem first and then they'll have
7:53
one or more of the other problems. Now, it varies
7:56
a bit in terms of size of company. So firstly,
8:00
for IDP purchasers, they're typically 100 engineers
8:03
plus. That's the kind of minimum size of company.
8:06
Now, we do have smaller customers and there are
8:08
smaller teams out there who want IDPs, but to
8:11
really be successful or really have the pain
8:13
that an IDP can help you solve, you want to be
8:16
100 engineers or larger because you want to have
8:18
a certain size. is a certain amount of complexity
8:21
in order to be able to, in order to need to purchase
8:24
a platform or a portal to solve the problem.
8:27
But after that, it's really kind of maturity
8:29
specific or it depends on the maturity of the
8:32
team, right? A lot of the time, if they're a
8:34
new platform just getting started. or if they're
8:36
trying to migrate from a legacy platform to a
8:39
new platform, then the top priority for them
8:42
will be the automation pieces. It will be speeding
8:44
up the path to production because that's pertinent
8:47
for the job, the initiative that they're trying
8:50
to complete at that time. We see a lot of teams
8:52
also who are moving, let's say, from Bitbucket
8:55
to GitHub or Azure DevOps to GitHub or something
8:59
to GitLab, et cetera. And so they want to provide
9:01
automation to their teams in order to speed up
9:03
that migration. And so they'll be less interested
9:06
in the catalog and the discoverability pieces,
9:08
but they'll be more interested in the automation
9:10
pieces. So it depends a little bit on what the
9:13
initiative is. That's kind of why one of the
9:16
first things I'll often ask teams when they come
9:18
to Rhody is, What is the initiative? Why is now
9:21
the right time to bring in an IDP? Why wasn't
9:24
it six months ago? What's going on in the company?
9:26
And really that informs the IDP that you choose,
9:30
the features of the IDP that you want to roll
9:32
out first and how you want to use it and how
9:34
you want to communicate it to your teams. Cool.
9:36
So I know that I want an IDP. I've figured out
9:39
that problem statement. Maybe I need a service
9:41
catalog or I want that automation. How do I decide
9:44
between port, roadie, backstage? You know, where
9:48
do I start? Yeah, yeah, yeah. Well, I mean, regardless
9:51
of which platform you're going to have to choose,
9:53
and there is a way to think about that also,
9:56
you want to think about how you're going to get
9:58
it into the company or how you're going to drive
9:59
adoption of it. uh throughout the company right
10:02
so so i mean this is often much more of a human
10:04
problem than a technical problem i think and
10:07
people underestimate that so the if you take
10:09
a simple question you're gonna know you're gonna
10:11
want to have a catalog in your in your in your
10:13
developer portal that's typically the piece where
10:16
a lot of the functionality hangs off you know
10:18
you go and look at a service and then you can
10:20
see who owns it or you can redeploy it or click
10:22
a button to do something right So how are you
10:25
going to populate your catalog is one of the
10:27
first things that I would suggest that people
10:29
think about. The two paths that you have there
10:32
are some sort of automated population where you're
10:34
essentially going to connect it up to GitHub
10:36
and pull in the repos and connect it up to Argo
10:38
CD and pull in the applications from there. And
10:41
it makes form some sort of relationship between
10:43
those two things. That's going to be good for
10:47
catalog completeness, but it's going to be poor
10:48
for... giving the teams a sense of ownership
10:51
over how their service is represented in the
10:53
IDP because they'll feel like you just did that
10:56
work and it's nothing to do with them really.
10:58
The other end of the spectrum maybe then is backstage
11:00
is kind of traditional YAML files where you're
11:02
asking teams to put a YAML file in their repository
11:06
and maintain that over time. which is the other
11:10
end of the spectrum. It gives them a high sense
11:11
of ownership, but it's going to be less up to
11:14
date. There's going to be a lag between changes
11:16
happening in the real world and changes being
11:19
represented in that YAML file. And there's going
11:21
to be a slower rollout there because you're asking
11:23
teams to do something. But those are both ways
11:26
that we've seen be successful. But even beyond
11:28
that, you have to think about what is our data
11:31
model in this company? And that can often be
11:34
a hard thing to pin down in the first place.
11:37
before you even try to define that in YAML files
11:39
or in code or however you're going to do it.
11:42
You can get your architects in a room and talk
11:45
to Bill and talk to Mary, and the two of them
11:47
will disagree about what constitutes a service
11:50
in the company, or is the payment service part
11:53
of the payment system or the billing domain?
11:57
What is the nomenclature that we use to describe
11:59
the company, right? These are all things that
12:01
need to be decided at a human level before you
12:05
can dive into choosing your IDP, I think. You
12:09
would be surprised, or I think a lot of people
12:10
who maybe work in smaller companies would be
12:12
surprised at the level of chaos that exists out
12:14
there around some of these operations in larger
12:18
companies. We have plenty of customers who can't
12:21
answer a simple question like, what's a team?
12:23
If they go to Workday, they'll see one definition
12:26
of who's on a team. If they go to GitHub Teams,
12:28
they'll see another definition. And these things
12:30
mean... They're not incorrect. It's just that
12:33
in different contexts, what you would call a
12:35
team is slightly different. Maybe, you know,
12:38
your manager in Workday is a certain person.
12:40
And so you are in that team, but you're also
12:42
on call for a service which is actually owned
12:44
by a different team. And so you're kind of in
12:46
that team too, right? And so the messiness of
12:48
human environments really takes a toll when it
12:51
comes to organizing your data model and keeping
12:53
everybody happy. And so I do think that teams
12:55
should... think deeply about how they're going
12:57
to do that before they get an IDP at all. Other
13:01
good things to think about are what is your first
13:05
feature? What's the first problem you're going
13:08
to try and solve with your IDP? Which I think
13:11
can have a large effect on whether or not the
13:16
initiative is successful. recommend that teams
13:21
start with the automation use case in backstage
13:24
-based deployments or in Ro. The reason being
13:27
that catalogs have network effects effectively,
13:30
right? When you take some time to build out your
13:33
catalog and in those initial stages, when people
13:35
go to visit the catalog, they're not going to
13:37
see the things that they need. And so they're
13:38
going to be discouraged from adding their own
13:40
software. It's kind of, it ends up being a bit
13:42
like a social network, like Facebook or anything
13:45
else. Whereas automation has immediate ROI. If
13:49
you can take a process that used to take a month
13:52
and you can make it now 15 minutes, then you
13:54
can very easily multiply the amount of times
13:56
that that process is run by the time saved. And
13:59
then you can easily explain that to your VP of
14:01
engineering and claim a win and take that forward.
14:04
There's no waiting period before you achieve
14:08
that benefit. So we recommend people start there
14:10
a lot of the time. Of course, taking into consideration
14:13
the actual needs of the organization. If you
14:15
don't have a need for automation, don't start
14:17
there, obviously. But then, okay, so after all
14:22
of that happens, you've decided that you do have
14:24
a real use case for an IDP. You've thought a
14:26
bit about how you want to roll it out and so
14:28
on. The market, I like to think about, kind of
14:31
divides itself on a spectrum of extensibility
14:34
to ease of use or speed of deployment, let's
14:36
say. So at one end of the market, you do have
14:39
self -hosted backstage. It is, and let's be clear,
14:42
self -hosted backstage is the market leader.
14:45
Like probably 90 % of the market is using self
14:47
-hosted backstage. 3 ,500 companies out there
14:51
who have adopted Backstage from the largest companies
14:53
in the world to small teams of 10, 20 engineers.
14:57
The thing to keep in mind about Backstage, though,
14:59
is that it's a framework for building a developer
15:01
portal. It's not a developer portal itself. It's
15:03
kind of funny to think about, but back in the
15:05
early days of the Backstage community, I noticed
15:07
that there was a trend of people searching for
15:11
Backstage Docker container or Docker image on
15:14
Google because people were looking for not a...
15:18
TypeScript library, a bunch of TypeScript libraries
15:19
that they could build together into a developer
15:21
portal, but they were looking for a Docker container
15:23
that they could just run. And so one of the first
15:25
things that we did in the community was actually
15:26
just build that Docker container and make it
15:29
available. But that was a long time ago. Things
15:31
have moved on quite a lot. from there. But the
15:33
core nugget of truth is still true. Backstage
15:37
is a framework for building a developer portal.
15:38
You mentioned just before we started the call
15:41
that Spotify had said that teams should be six
15:44
to eight engineers dedicated to Backstage to
15:46
be successful for it. Our data shows the same
15:49
thing, really. And we ran a survey last year
15:53
called the State of Backstage. And when we analyzed
15:56
the data from that, people who reported being
15:59
very satisfied. with their self -hosted backstage
16:02
deployment had at least three engineers dedicated
16:04
to it. That's kind of what we saw across the
16:06
market. So that's all true. Time to value you're
16:10
expecting to see is six to 12 months. This may
16:13
have changed recently with the development of
16:15
AI probably has come down in the past three months.
16:18
I feel like Opus and improvements to Codex have
16:21
really increased what AI can achieve. So that
16:25
might come down a little bit. But the core work
16:28
that you have to do is still there. It's about
16:31
going and talking to your internal developer
16:33
community, distilling what they need. turning
16:36
that into features. A lot of that work you still
16:39
have to do. Building in things like role -based
16:40
access control, which doesn't come with Backstage
16:42
out of the box. You know, this is all kind of
16:44
boring stuff that I think at least we would claim
16:47
that your engineers are better off not doing
16:49
and just using a kind of existing solution instead.
16:52
But you do have Backstage, self -hosted Backstage.
16:54
That's at one end of the spectrum. It's going
16:56
to be the most extensible thing that you can
16:58
get. No matter what your internal tools are,
17:00
no matter how homegrown or legacy they are, it's
17:02
going to be able to integrate with them because
17:04
you basically build your own developer portal.
17:06
then at the other end of the market you have
17:07
port cortex etc um really what you're trading
17:11
off there is control for reduced time to value
17:15
so you're going to get more features out of the
17:16
box You're going to get things like scorecards,
17:19
role -based access control, built -in AI, et
17:21
cetera. All those things are going to come out
17:23
of the box and you're going to be able to just
17:24
use them on day one. And then when you're trading
17:27
off in terms of control is vendor lock -in, restrictions
17:30
to the amount of integrations that they provide.
17:33
You kind of are locked into their roadmap. Same
17:35
as with any other SaaS solution, limited customizability,
17:38
et cetera. But it's going to be more opinionated.
17:40
You're going to get started more quickly. And
17:42
so that's a path that you can go, of course.
17:45
Roadie is slightly different, and I don't want
17:47
to turn this into a sales pitch for Roadie, but
17:49
just to explain, because we are based on Backstage,
17:51
we give every customer a full Backstage stack,
17:53
but then we build in the kind of ease of use
17:56
that you need on top of it. So, you know, adding
17:59
integrations is just a matter of dragging and
18:01
dropping things around the place. There's no
18:03
re -employments. We give people search, which
18:06
is based on open search. role -based access control,
18:09
scorecards, et cetera, all those things are built
18:11
in. So the idea really is just that you're getting
18:13
the extensibility of backstage, but you're also
18:15
getting the ease of use and the reduced time
18:17
to succeed that you will get with port recording.
18:20
So speaking to the automation angle, how do you
18:23
think agentic workflows change IDPs or how they
18:28
may be implemented going forward? Yeah, I think,
18:31
I mean, we're in the middle of a massive shift
18:33
right now. I mean, I don't know how much you
18:35
can, how much you're perceiving it. I still am
18:40
hands -on keyboard writing code whenever I can,
18:43
you know, which is typically just my spare time,
18:45
but I'm making small changes. I'm not allowed,
18:47
the engineers don't allow me to make changes
18:50
to the actual products anymore, but I hack on
18:52
our marketing website whenever I can. And, you
18:55
know, I haven't written a line of code in maybe
18:56
three months or so, since Christmas, I would
18:58
guess. Everything is produced by Claude. So there's
19:02
a massive shift happening right now. I think
19:05
that IDPs existed to try and bring information
19:08
from external sources, LaunchDarkly, CircleCI,
19:13
whatever tools you're using. into one UI so that
19:16
you could have a kind of a single pane of glass
19:18
experience. You know, that's what people would
19:20
talk about a lot. I think that the need for that
19:22
is shifting. At least I feel now like I want
19:25
to be in my terminal or in Visual Studio Code
19:28
or whatever it is that you're using all of the
19:30
time. And I feel like the information can come
19:32
to me. So I think that's one huge shift which
19:36
is happening. Why would I go to a catalog and
19:38
click through an interface? to find a service,
19:41
to be able to see a piece of information when
19:43
I can just ask the question directly in my terminal.
19:47
So, I mean, that's how I think the shift is being
19:49
pushed onto the market. And so the UI layers
19:52
of IDPs, I think, are becoming less and less
19:54
relevant over time. So that's one change. And
19:57
then the other thing that we're seeing, and we're
19:59
a little bit earlier in this, but the more and
20:01
more work is being done by agents. And I don't
20:05
just mean when you're in cloud code. plug code
20:08
as an agent, but I mean an actually externally
20:10
triggered, hey, something went down, an agent
20:13
fires and makes decisions about what to do about
20:16
that. So these are operations decisions. It could
20:18
be, you know, add a second cluster or something,
20:20
right? We're earlier in that, but my expectation
20:24
certainly is that that is going to become more
20:26
and more prevalent over the next two years or
20:29
so as we can trust OLMs more and more. obviously
20:34
it's a lot riskier but the earlier stages of
20:36
that i think are are humans or humans building
20:40
working directly with llms quite closely to answer
20:44
questions you know i mean take an example of
20:46
something like figure out why the payment service
20:48
went down last night between 3 and 4 a .m right
20:50
like that's an actual use case from inside and
20:54
roadie that we were discussing recently but if
20:57
you think about the context that's required there
20:59
for the agent to be effective it's What is the
21:01
payment service? Where is the logs for it? What
21:03
log group? Where is the metrics? Which cloud?
21:06
What region? Etc. There's so much context that
21:09
an agent needs to be able to be successful. So
21:12
I see the job of... IDPs shifting a little bit
21:16
from providing context to humans through UIs
21:20
that they can click through to providing what
21:22
I would call context bundles to agents so that
21:25
they can have historical data if they need it,
21:28
real -time data if they need it, concise, accurate,
21:30
correct, to be able to make decisions about how
21:34
certain changes in the environment should be
21:38
reacted to. So building like a centralized MCP
21:41
for all? information around the development cycle
21:45
i think that can i think that can certainly be
21:47
part of it yeah um that will give you the kind
21:49
of real -time access to well let me let me let
21:52
the agent ask a question to be able to get a
21:54
result right i think that's certainly part of
21:57
it i think that i'm not sure that that solves
21:59
the entire conciseness part of the problem and
22:02
it certainly doesn't solve the kind of historical
22:04
data or what has changed over the past hour part
22:07
of the problem But certainly that will be involved.
22:09
Yeah, for sure. So if coding agents make dev
22:12
faster, why wouldn't DevX teams suddenly have
22:16
time to build whatever, everything? Yeah, well,
22:19
I mean, I guess like I would be, the engineer
22:21
in me would be hopeful for a world where they
22:23
would. But I guess the CEO in me is not necessarily
22:28
sure that that's how it's going to pan out. You
22:30
know, I mean, it certainly does make it easier
22:33
to make changes, faster to make changes. That's
22:35
irrefutable at the moment. But I think that.
22:38
That doesn't necessarily mean that an internal
22:41
platform team is going to have all the time in
22:43
the world to build whatever they want. I worry
22:45
that people in the C -suite are going to look
22:48
down at that team and think, well, okay, now
22:51
we can actually take two engineers off that team
22:53
because everybody else is more productive and
22:55
put them on the revenue -generating side of the
22:57
business. I still think that that fundamental
23:00
tension between the revenue generating side of
23:03
the business and the platform team or the internal
23:05
teams still exists. And I still think that trade
23:08
-off exists. And so it's not necessarily clear
23:10
to me that you're going to have more time to
23:13
work on internal projects. I still think that
23:16
even with AI, I mean, the return on investment
23:19
equation does change, but I still think it's
23:23
difficult to prove the benefit of that or prove
23:26
that return on investment. to the executive level.
23:29
So this is a challenge that we deal with a lot
23:31
in the IDP space because IDPs are at their highest
23:35
level supposed to improve productivity of developers.
23:39
But we're not even all that good. And I mean,
23:41
when I say we, I mean the industry at large is
23:43
not all that good at measuring productivity of
23:45
developers in the first place. So showing a delta
23:47
between where it was before and where it is now
23:49
is even more difficult. And I still think that
23:52
that's going to be true as well for internal
23:53
projects, even with AI. You can obviously claim
23:55
the cost is reduced, and that's true. But the
23:58
cost reduction mostly... shows up in the front
24:02
of the application build -out lifecycle, right?
24:06
So, you know, it's easier to get started. It
24:07
still gets a bit slower to improve software over
24:10
time, or it's still slower than it is to start
24:13
a Greenfields project. I mean, we see this with
24:16
backstage upgrades internally, right? One of
24:17
the benefits of Brody is just that you don't
24:19
need to upgrade backstage anymore. But AI is
24:21
not all that good at upgrading a sprawling backstage
24:24
application, making broad changes across the
24:27
code base. And so that's still going to be true
24:29
if you build your own. and out of software. Scope
24:32
is going to increase over time and you're going
24:35
to have to do wide changes internally. And that's
24:37
still, I think, going to be difficult. And then
24:41
the other large source of waste that I see inside
24:44
software engineering organizations is not necessarily
24:46
not building the thing fast enough, but it's
24:49
building the wrong thing in the first place.
24:50
And I still think that that's going to be a problem.
24:53
I don't think AI necessarily tells you what to
24:55
build or how to solve the pain points of your
24:57
users. And so one of the benefits of... I think
25:00
picking off the shelf software is that it's built
25:03
out of the lessons which have been learned over
25:05
many, many years from rolling out at lots of
25:07
different companies and solving all sorts of
25:09
problems that you don't necessarily want to slow
25:11
yourself down by having to reinvent the wheel,
25:14
solve those problems again. So, okay, given that
25:17
it sounds like we're moving from dashboards to
25:20
workflows, IDPs become... the source of truth
25:23
for context to some degree, which I think is
25:26
an organic move. What should teams do now so
25:29
they're not rebuilding everything again in 18
25:31
months? Like, how do we prepare? That's a million
25:34
dollar question. I wish I had the answer to that
25:36
myself. It seems like everything you put in your
25:39
roadmap might get released by Anthropic six months
25:42
from now and might disappear, right? I think
25:44
you have to stay close to your users. I have
25:46
to, and I feel this too, right? Because as a
25:49
startup founder, you somewhat... have to live
25:51
in the future, right? You're trying to keep track
25:53
of what's happening out there in the world and
25:56
what's coming in the next six months. But I have
25:58
to go back and put every idea through the filter
26:01
of, well, where are our customers now? And I
26:05
think that internally, if you have internal customers,
26:09
which is what a typical platform team has, I
26:11
think you need to keep that in mind too, right?
26:13
Like, what are the needs of the business right
26:14
now? Where are my users? What are they capable
26:17
of? What does our security restrictions and our
26:20
governance rules and everything else allow us
26:22
to do? I kind of build for now with an eye on
26:25
the future. I think, you know, I guess some myself,
26:29
I still think that developers are going to be
26:32
around for quite a while. And this is, again,
26:35
just pure speculation on my part. Nobody really
26:39
knows, but I certainly feel like the human and
26:42
AI loop. is is quite important and will be for
26:45
for the next while i think we'll be augmented
26:48
by ai i think it's a bit like having an exoskeleton
26:51
you get stronger you get better um you get faster
26:54
but i still think that the creativity part um
26:57
exists and and will do for quite some time the
27:01
state of dorametrics report end of year last
27:04
year um i thought it was interesting they talk
27:08
about how engineers in general say that they're
27:11
getting more productivity out of ai or with ai
27:14
but yet we're not actually seeing like more tangible
27:18
deployments or like feature rich work being deployed
27:20
where engineers think that they're getting more
27:23
more out of ai but they're maybe not you know
27:26
or at least not as quickly as we would think
27:29
that they should maybe with the efficiency gains
27:31
yeah Yeah, well, I think, I mean, this is, again,
27:34
just personal thoughts. So frame this however
27:36
you want. I think that it's tempting to do more
27:39
busy work now, I think is the first thing. Like
27:41
things that where you wouldn't have necessarily
27:43
made, you wouldn't necessarily made that feature
27:45
before, but now because it's easier, now you
27:47
will. But that doesn't necessarily add to like
27:48
the bottom line, the overall productivity. I
27:51
think the developers who are able to make product
27:54
decisions have gone up in value. a lot over the
27:58
past three to six months as well. Because again,
28:01
the AI won't tell you what to build. It will
28:03
build it faster. So I think if I was going to
28:07
give advice to someone who's starting out in
28:08
software engineering now would be to try and
28:10
be a well -rounded individual who knows some
28:14
UX, who knows some... UI design, who understands
28:18
why people use the software, because then you
28:21
can kind of build towards your customer and you
28:23
can actually solve problems in a very real way
28:25
for people versus just moving code around, which
28:28
I think is a risk. And I think there's also just
28:30
a, there's a general economic diffusion problem
28:33
that we have to solve at the moment as AI just
28:36
percolates through the economy over the next
28:39
couple of years. So, I mean, an experience I
28:42
had recently was we had a, we had a full company
28:44
offsite. And we're a remote company, so it's
28:47
rare for people to all be in the same room together.
28:50
But we got the technical people in the same room
28:52
as the non -technical people. And if you're not
28:56
on camera, you can't see that I'm doing air quotes.
28:58
But the air quotes are because I feel like everybody's
29:00
a bit technical now. It was eye -opening for
29:03
some of the non -technical people, people in
29:05
customer success, people in sales, etc. Eye -opening
29:07
for them to see what the engineers were able
29:09
to do in a very short amount of time with AI.
29:15
And I'll give you a great example. I mean, one
29:16
of our customer success people went, took the
29:19
lessons from that offsite, you know, just kind
29:21
of, it was, when I say lessons, it was more of
29:23
an eye -opening experience. It was just, oh,
29:25
wow, that's what you can do. And once he'd been
29:27
shown what was possible. He was able to go back
29:30
and he's never written a line of code in his
29:32
life, but actually make his own customer success
29:34
dashboard, which pulls information from lots
29:36
of different sources and shows the health of
29:39
each of our customers, etc. So I think there's
29:41
a certain amount of just realization of what's
29:44
possible that has to happen throughout the economy.
29:47
The models don't need to get much better, although
29:49
they will. the knowledge has to percolate through
29:52
the economy. And I think that that's when you'll
29:54
see the real productivity gains. Yeah. It's almost
29:56
like we're all becoming managers now and we're
29:58
all like the skill set is really knowing how
30:01
to prompt an AI, but then also how to be critical
30:04
of the output of the AI too. Like, because it's
30:07
very, it's very good at being confidently incorrect.
30:09
So if you don't give it the context, like you
30:12
said, it's going to make assumptions, you know,
30:13
so you have to know how to. how to actually reason
30:17
about what it's giving you and then be able to
30:19
give it the right input so it gives you the output
30:20
that you're expecting. Yeah. And just because
30:22
you can build anything and everything doesn't
30:24
mean you should. Yeah. We've all used bloated
30:27
software. I mean, it's one of the top complaints
30:29
of people who actually produce software when
30:32
software is bloated. But, you know, AI can help
30:35
you make your software bloated much more quickly
30:37
than you could before. Very true. Okay, so wrapping
30:39
up, what's one piece of advice for platform or
30:42
DevEx teams starting an IDP this year? Put your
30:46
laptop away and go talk to your internal users.
30:49
That's fair, yeah. Right? You know, go and ask
30:52
them, hey, what are you doing for 90 % of your
30:57
day? What's the biggest frustration you've got?
30:59
What takes the longest time? Because you might
31:01
find out that it's actually, well, the bills
31:02
are slow or whatever, right? And it's not that
31:05
they're trying to search for who is. the owner
31:08
of the payment service or who's the manager of
31:11
that team or whatever else. I think go talk to
31:13
your users. That's the number one piece of advice.
31:15
If you actually are in a situation where you
31:18
want to have an IDP or you have a need for an
31:21
IDP, I would suggest trying a little bit of self
31:24
-hosted backstage, try a pure SaaS solution and
31:27
try Roti just so that you get a good overview
31:30
of the market. An IDP is something that you are
31:33
going to roll out across your entire organization.
31:36
You're going to live with it for quite a while.
31:38
And so you want to put some thought into that
31:40
decision. It's not necessarily the most reversible
31:42
thing in the world. So I think just take a look
31:45
at a couple of different solutions and see how
31:47
they each perform. Yeah, that's fair. Where should
31:49
people follow you or read your stuff? I'm probably
31:52
most active on LinkedIn, which almost makes me
31:55
shudder to say. The inner developer in me hates
31:59
that, but it's probably true. So just search
32:01
for David Tuite on LinkedIn. Yeah, that's probably
32:04
the best place. Very cool. I'll leave all that
32:07
information in the show notes as well. David,
32:08
thank you for coming on. Really appreciate it.
32:10
Super. Thank you very much. Thanks for having
32:11
me. All right. That's my conversation with David
32:14
Tuite. My biggest takeaway from this one is that
32:17
the future of IDPs probably is not build a prettier
32:20
dashboard. It is building the right context layer.
32:23
For developers, for platform teams, and increasingly
32:26
for agents. That means discoverability still
32:29
matters. Automation still matters. Guardrails
32:32
still matter. But the shape of the experience
32:34
is changing. Less clicking around for answers.
32:37
More workflows. More context delivered where
32:40
the work happens. More systems that can help
32:43
humans and agents make better decisions faster.
32:46
I also liked that David kept this grounded. He
32:49
was pretty clear that teams should not start
32:51
by chasing hype. or by building towards some
32:54
imagined 18 -month future that may change again
32:57
in six months. Start with the pain you actually
33:00
have. Talk to your internal users. Figure out
33:03
what slows them down. Figure out what causes
33:06
friction. Figure out what should be self -service.
33:09
Then build from there. This is a much healthier
33:12
way to think about platform work. And honestly,
33:15
it is probably the right way to think about AI
33:17
too. Because just because we can build faster
33:19
now does not mean we automatically know what
33:23
is worth building. If you enjoyed this episode,
33:25
follow Ship It Weekly wherever you listen to
33:28
podcasts. If you want the full show notes, links
33:30
to David, Rhody, and the resources we talked
33:33
about, head over to shipitweekly .fm. Thanks
33:37
for listening, and I'll see you later this week.
