Definitely is the top International software
development conference with an emphasis on coding architecture
and Tech leadership skills. The lineup for this year is
truly stellar and features many Legends in software development
names, such as Robert Uncle Bob. Martin can back Scott Hanselman
Franca subramanium, Carolyn honey, Alan.
Hello. Mary poppendieck and many other
prominent names including some of those who have also appeared
in this podcast before the conference.
Takes place online so you can enjoy it from the comfort of
your couch. We spoke to the definitey
organizers, and I'm happy to share that technology.
You know, has got the 10% discount code for you, enter the
promo code, awsm underscore tlg. When you purchase the ticket on
definite e.com, here's the promo code.
One more time awsm underscore, tlj.
Depending on the time when you purchase a ticket, early price
is still available. See you there developer
experience is one approach to thinking about engineering
excellence and maximizing engineering performance.
And developer experience is really about focusing on the
day-to-day experience of delivering software and a team
understanding. What is getting in the way one
of the biggest constraints and bottlenecks and frustrations in
that process and improving those to increase.
The capacity and performance of individuals, and the team as a
whole Hey everyone. My name is Henry Surya with
Robin. And you're listening to the
technology, you know, podcast the show where I'll be bringing
you the greatest technical leaders practitioners and
thought leaders in the industry to discuss about their Journey
ideas and practices that we all can learn and apply to build a
highly performing technical team and to make an impact in your
personal work. So let's dive into our Journal.
Hey everyone, welcome to the technology.
Now, podcast the show where you can learn about technical
leadership and Excellence from my conversations with great
thought, leaders in the tech industry.
If this is your first time listening to tackle, it Journal,
subscribe and follow the show on your podcast app and on
LinkedIn, Twitter and Instagram. And if you'd like to support my
journey, creating this podcast, Please Subscribe, as a patron at
package. Another death / Patron, Be my
guest for today's episode is a be no de.
RB is the CEO and co-founder of DX a platform that helps
engineering, leaders, measure, and improve developer experience
in this episode, I'll be open or discussion by sharing.
What developer experiences, why it is becoming such an industry
Trend, nowadays, and the different ways of how it is
being implemented. In the industry are be explained
why the traditional metrics normally used to measure
developer productivity? Do Really work and can even
provide perverse incentives are be then.
Touch on the two. Popular research has widely
known in the industry. IE the Dora report and space
framework before then explained how the x is building on top of
both researchers to provide the measurements and kpis to measure
developer experience and productivity towards the N are
be shared his advice on how we can start investing in improving
developer experience, including when to form a dedicated
developer experience team. Getting the buy-in from company
Executives. I really enjoyed my conversation
with Abby and developer experience is also an area that
I have much interest in lately, which I believe can be a great
area. Any engineering team can invest
in, to improve the overall productivity and engagement.
If you find this episode useful, please help, share it with your
friends and colleagues who can also benefit from listening to
this episode. I really appreciate your support
in sharing and spreading this podcast.
The knowledge to more people. Let's dive into a conversation
after hearing some words from our sponsors.
Mental will be is a silent pandemic.
According to the who depression and anxiety caused the global
economy over one trillion US dollars every year, it's time to
make a difference, learn how to enhance your life through a
master class from Founders well-being.
And my good friend Sandy brow on mental Wellness, visit Founders
well-being.com / masterclass to enroll and enter TL.
AJ 24, a 20% discount be a better version of yourself and
make an impact. Today's episode is proudly
sponsored by skills matter. The global community and events
platform. With more than 100,000 software
professionals here members. Can organize their learning
experiences around the technology topics.
They care about most you get on-demand access to their latest
content thought, leadership insights, as well, as the
exciting schedule of tech events running a Cross all time zones.
So whether devops our data science is your bus or you're a
fan of functional programming or all things Cloud, you can make
real connections with people who share your interests head on
over to skills, method.com to become part of the tech
community that matters most to you.
It's free to join and you will find it easy to keep up with the
latest tech Trends. Hello everyone.
Welcome back to another new episode of the Attack.
Original podcast today. I have with me a guest named
Albie NoDa, so I'll be is the co-founder and CEO of the x or
some people also refers to it as get dx.com.
So DX is a company that helps software organizations to
measure and improve developer productivity and experienced.
Previously, our be also was the founder of pole Panda which got
acquired by GitHub and thus he spent maybe about one and a half
years in GitHub to become like, the product manager are looking
at developing inside, So as you can tell Abby's background is
all about developer experience, developing sites and
productivity. So I'm really looking forward to
discuss with you today about this topic because it seems to
be a pretty trendy these days. Talking about developer
productivity, and developer experience.
So welcome to the show, I'll be thanks so much for having me.
So I'll be I always like to start my conversation by asking
the guests to share more about yourself.
So maybe if you can share any highlights or turning points in
your career, Yeah, first of all, so excited to be here, I'm
programmer. That's what I do by trade and
that's what I've always done since high school, in terms of
my career, about seven years ago, I transition from just
being an individual contributor to being an engineering manager.
And I still remember that shift I made.
It was so exciting at the time because you go from being so
focused on shipping tasks and programming features and
suddenly you're now responsible for people and the Dynamics of a
team. And so, a big fan of your
podcast, and big fan of sort of the science and art of software
leadership. When I became a software
engineering manager, one of the problems I kind of became
fascinated by was the problem of how do you measure software
development? How do you measure software
development teams, the event that sort of prompted, that was,
I was the CTO of a start out in California and the CEO came to
me one day and said, hey, I'll be our leadership.
Team is going to start having metrics that.
We review together each month. Can you bring some metrics for
engineering to understand the productivity of your team?
I remember my initial reaction was, I don't know if there is
anything but really is an accurate, depiction of what
we're producing. And certainly there was nothing
that I felt would be reasonable to also use with my team.
I could report something like velocity points or number of
pull requests or number of features to the rest of the
executives. But I knew that number, Nothing.
So, the actual developers on my team and so, that moment has
sparked a now, nearly 70 or journey to try and figure out
this problem. And along the way, I first
started a company called pull Panda, which had a few different
products. But primarily was still focused
around this problem of measurement with pull Panda.
The approach we attempted was to use development sort of exhaust
that I write so data from GitHub and jira tools.
Like that and compile those into metrics for managers and teams
and leaders to measure how they're doing.
That company was acquired by GitHub.
Where, as you mentioned in the intro, I led a similar product
with in GitHub GitHub. Also wanted to bring a product
to Market that tried to solve this problem.
Then along the way, I kind of came to the realization that
there was maybe a different way to approach this problem,
perhaps a better way. And that's really the Genesis of
DX. The company that I've been
working on for the last Two years and running today.
Thanks for sharing your story. I think is really fascinating.
You have been dwelling with this problem for 7 years.
So now that you get a chance to found a company working on that,
I think it's really exciting. You mentioned that you are kind
of intrigued by this problem these days, actually, it is
becoming like a trend, like everyone's problem.
Everyone is thinking about it, especially so many startups,
software company these days and they want to measure this kind
of a developer experience and productivity.
So why do you think only Only these days.
It becomes like really hot and trendy.
I actually don't think it's that new.
I mean, I think people in business of, always tried, to
measure performance, businesses and public companies, have their
stock price public to the whole world that everyone can see how
well your quote-unquote performing.
And of course, if you're ever inside of a sales organization
or a marketing organization, it's very much driven by targets
and numbers and performance. I think Business Leaders have
been trying to do the same thing.
For engineer organizations for a long time.
Of course, I think at some point in their careers anyone who's
worked in Tak has kind of bumped into this.
But the most primitive approach to trying to measure was through
metrics like lines of code or velocity points.
Just people looked at programmers acedo, they produce
code. Let's count how much code they
produce. And of course, everyone who's
ever written a line of code understands why that doesn't
work. But that approach is still
pretty common today, actually, surprisingly, even at really big
reputable Companies. But I'm sure we'll get back to
kind of more like the progression of how this happens
later in terms of, I think why it's been a Hot Topic.
As of late is partly the shift to remote and hybrid working
models. So the whole world changed and
Business Leaders naturally. Wanted to understand how has
this changed our capacity as an engineering organization.
I think it's also that software is just becoming such a more and
more important part of every business.
It's not see. As a cost center as much as a
really, the lifeblood of every organization is the key to
success is innovation and technology.
And so, I think as more companies realize that and the
job market, the market for talent has become more and more
competitive, it's just created more pressure overall in the
whole system to understand how well you're doing as an
organization or even as an individual.
So that's my perspective. I mean, we have been talking
from the engineering leaders point of view we want to have X,
we want to have measurement. We want to know how features get
delivered and that's impact the business performance so to
speak. But what will be some of the
impacts may be for developers Engineers or the software teams
themselves if they actually put more, focus on, improving their
developer experience? So maybe you can share a little
bit on this. I think everyone in any
profession and any trade you want to feel like you're good at
what you do, you want to feel Mastery over your craft and I
think that's true. Much trip software developers.
It's very much a craft there's very much a lifelong pursuit of
Mastery in it that almost every professional developer sort of
embodies in terms of developer experience developer
productivity and measurement today.
It's not so much about measurement.
I think for a team as just about working in more effective ways,
I think just as much as measurement has been kind of a
mystery and Elusive problem for software organizations, how to
actually be good has also Then sort of elusive, right?
Software organizations are constantly trying to figure out
what technology should we use? How should we organize our
team's? What kind of processes should we
use to deliver software? Should we do scrum?
Should we do save, should we not do any of those things teams?
Apologies microservices, it's just always changing.
And so, to boil this down for a team developer experience is one
approach to thinking about engineering excellence and Max
Rising and cheering performance. And developer experience is
really about focusing on the day-to-day experience of
delivering software on a team. Understanding.
What is getting in the way one of the biggest constraints and
bottlenecks and frustrations in that process and improving those
to increase the capacity and performance of individuals, and
the team as a whole. So that is really what developer
experiences about from the standpoint of an individual
team. And if I'm not mistaken there,
so many terms in the industry, referring to the same, almost
the same thing, I guess, but not really the same.
So develop experienced developer, productivity team,
maybe you can share a little bit more.
What summer for the companies do to solve this problem.
That's really interesting. This is something.
I've been focusing a lot on through my own podcast and
research and talking to leaders across the industry for many
years. Organizations have stood up
special teams or Herbs with then the organization that are
devoted to making the rest of the organization?
More excellent. And in fact, one of the, I think
slightly did it. I should say names for these
teams are engineering, Excellence groups, engineering
Excellence teams. But when you look, broadly
across the industry, you see, a lot of different flavors of this
type of work happening. I think, if you had to give it
one label across the industry, I would call it enablement.
These are teams. Cartman's whose responsibility
is to enable teams and developers across the rest of
the organization to be more effective and more successful.
So when you look at the industry today, I'll just list them off.
You'll see platform teams infrastructure, teams developer
productivity, teams developer experience, teams, engineering
Excellence, teams software, delivery life, cycle teams,
engineering, enablement teams. Forgot that one the list kind of
goes on. And what they, all share is
roughly the same Charter. They all exist to help.
They all Focus inward. They're not external customer
facing their inward facing and they focus on helping
development teams. Be more effective.
Saving them time, helping them adopt better practices
supporting them in specific areas of their features or
products that they need support in the ways in which these
different types of teams. I described accomplish, that
goal are a little bit different. Here and there.
But if you had to kind of take a 10,000-foot view on it, I would
say some of the teams tend to be more process and culture
focused. Whereas some teams are more
tools and Tech focused and then others are sort of just a blend
of both to bring this full circle.
Developer experience, teams are, I think the newest kind of
evolution of these enablement teams developer experience teams
have really been born out of platform and developer. 30 teams
that were traditionally very focused on internal, tooling
particularly around builds and tests the way in which developer
experience teams are different or that instead of just being
responsible for a few tools that developer use, they're
responsible for looking at the developer experience
holistically across all the different tools they use.
Because in fact, that's where a lot of the friction is between
the different tools, not within each of the individual tools.
So looking at the developer experience holistically and
finding ways to improve, Prove that not only through technology
and tools, but also through Best Practices, cultural changes even
organizational changes. So if I also can share, when I
read your, get the ex white paper, there are certain impacts
that organizations can get when they invest a lot more in this
developer experience. So things like of course
efficiency developer gets more productive and more velocity, so
to speak. And then also Engineers
attrition thing if you probably work, Company that has so bad.
Developed Express. I guess Engineers would probably
find another place to work at and of course, the satisfaction
working there at the end of the day is always about business
performance, right? If the engineers are productive,
of course, you will drive business performance as well.
So you mentioned in the beginning about different ways,
traditional companies, use to measure their productivity lines
of code number PR, maybe prh number of box number of
features, ship software, velocity, so maybe tell us more
What are some of the problems if we try to measure productivity
by using this traditional metrics and maybe they are other
more traditional metrics that you can share as well.
Yeah. So for quote unquote traditional
Matrix or metrics that are I think most commonly misused
would be really anything that revolves around like counting
widgets of what programmers produce.
I use the term widgets because the flaw is in the way leaders
view software development as something that produces Widgets
in other words, they do it as a sort of factory assembly line.
And as a side note, what's really interesting is a lot of
the most popular software engineering metrics like cycle
time, for example or lead time. Actually those have been used in
manufacturing for many more decades and they've been used in
software development. So it's interesting that our
discipline has adopted these manufacturing metrics when
anyone who's built sulfur understands that it's not a
repetitive assembly line sort of process, right?
It's a creative process. Is so going back to kind of what
the problematic metrics are. So things like lines of code.
Number of pull requests velocity points.
Those are probably the most notorious metrics velocity
points, which really is about counting the number of agile
points that come from sort of agile, ceremony of assigning
points in the estimation process.
Suffers a really, really harmful problem in that agile estimation
points are tool for estimation, and therefore, you're measuring
your Asian based on how much work they completed based off of
the estimates, which may or may not be what actually occurred in
actuality. That's not even the worst part.
The worst part is that by incentivizing teams to be sort
of graded, based on their velocity points, you're actually
incentivizing them to inflate their estimates.
And so you actually in this process, completely ruin the
actual purpose of velocity points in the first place, which
is to provide a And useful way to gauge the capacity and
forecasts of delivery for an organization lines of code.
I mean we joked about it earlier but again anyone who's written
software understands that writing more code, is that
better? So therein lies.
The critical flaw with using lines of code.
But in a more nuanced way, it just doesn't really make sense
because as any software developer knows depending on the
programming language, you might write more or less lines of code
just based on the syntax. It's funny, I've actually talked
to organizations recently who joke and say they're actually
incentivizing people to delete code that add code.
We want less code AS software developers and organizations,
like all code is just tapped at waiting a happen.
We want lesko not more. So, incentivizing lines of code
just creates a completely perverse incentive to actually
write poor quality software and on maintainable code.
So, those are some examples of problems with what I would call
the traditional. Estate developer productivity
metrics. And this has been talked about
for decades. I mean, there's a Martin Fowler
article called cannot measure productivity.
I think it's from my 2002 where he talks about wine zip code and
how leaders just keep using it even though it doesn't work.
So developers have been telling leaders that these metrics don't
work for a long time. Unfortunately that still hasn't
stopped a lot of companies and businesses from at least
attempting to use them. So, I guess, one of the common
challenges, why companies still using those numbers is because
probably is hard to get the quantifiable measurement, right?
So mostly at maybe anecdotal or perception within the company,
I'll build a slow, I'll build socks, or our environment is
bad, but nobody really quantifies that.
So I guess it's really hard for me.
That's probably to choose those numbers, but I guess lately
there are so many research done around these topics, or maybe
previously was there as well, but it was just not popular.
So there are few things that I can picked up from the industry
versus about Dora state of devops report or Dora reports.
Some people call it and also space from Microsoft.
So tell us more about these two popular research.
And what is your thoughts about using some kind of research
based approach to measure productivity?
Well, first of all, I think we all need to be looking more to
research for answers to this problem because it's so
difficult. Not only is it so difficult.
There's a lot of non-research out.
So many vendors selling their magic metric for developer
productivity, so many leaders choosing and adopting
ill-advised metrics with organizations that harm their
organization. So we all really need to be more
prudent and how we think about this problem and Leverage The
Wonderful research that's come on in the last few years.
I'm a huge fan of both Dora, the book accelerate and the space
framework I work with Margaret and story who is one of the
authors of space and the Cole, Force, grin, another author of
space, and of course, the she was the chief scientist and
researcher and author of accelerate.
And the founder of Dora, Dora was a Monumental step forward
for the industry. Because what dora proves was
that engineering performance software delivery performance
actually helps business. And this goes back to the
earlier point I made about how in the past software development
was seen as a cost center, how much are we spending on I.T?
Whereas today, we I know that all the biggest and most
successful companies in the world are really technology
companies. And so accelerate above all
Wiles prove that using real rigorous statistical research
one of their findings was also that there were these four key
metrics which made up the construct, which they called
software delivery performance which correlated highly or
predicted business performance, those four metrics of course
have sort of taken a life of Their Own That Nicole and other
authors of the book, never anticipated or intended, we can
maybe come back to the Merit of those four metrics.
But in terms of using them in an organization, the science behind
what those metrics correlate to Across the industry is real and
Google continues to produce the annual report examining those
four metrics and stats across the industry.
To this day space, which is much more recent was about developer
productivity. Which is very different
accelerate was around software delivery performance, which is
not developer productivity. That's why Nicole wrote space
because it was a different problem to be solved.
I love space, I love the premise and the findings and advice to
practitioners and leaders that are embodied in space.
And I think the biggest shift that space has made in the
industry as that leaders are finally, realizing that
developer productivity. Is more than just counting,
widgets space talks about how there's five different
dimensions of developer productivity and that a
developers day is complex and multifaceted and it's not just
about cranking out code, it's about collaborating with peers
and reviewing code and planning designing features and even
talking to customers. And so space really put forth
the idea that developer productivity is complex and to
understand measure or improve developer productivity.
Need to be looking at it from different angles.
And so, you've seen organizations try to implement
these things, both Dora and space and I think that kind of
brings us along to my work today which is space and door really
help the industry think about software rendering performance
and developer productivity in the right ways.
But I think there's still been a real challenge with.
Okay what do we actually measure?
How do we measure doormats? Works.
Now that we have the door metrics, what do we do with
them? How do we measure space metrics?
What does that mean? That's really the work that me
as well as Nicole and Margaret and story are doing today, is it
really Builds on the work that they've done.
It builds under a Builds on space but what we're trying to
do is kind of bring that into a more applicable set of
Frameworks and tools and Concepts to really help
organizations, actually, apply this both measure.
Improve developer productivity, using a set of practices and
measures that work. Thanks for sharing this in
details because yeah, Dora took the industry by storm.
I read the accelerate book as well as really good for those
who haven't read it, please go and check it out and space which
came in the last, maybe, three years or four years.
He was also quite revolutionary before.
People were talking about the four key metrics from Dora but
hey yeah that's another angle of developer productivity
satisfaction and things like that that maybe we should not
neglect as well because that also improves the software
development performance at the end of the day, I was so excited
when I saw that dr. Nicole and dr.
Margaret and was also part of your company, they are probably
the researchers in your company and hence comes with the DX
unique way of measuring this developer performance and
develop experience. So maybe now it's time to tell
us more how exactly the X actually do the measurement.
I know that you have the x k pi numbers, right?
And also top drivers that you measure.
So tell us more about all these kind of measurement that the
acts differently I think important to start with the
philosophy of what we're doing because one of the things that's
been a little lost and all the conversation around metrics all
the time is what are we trying to measure?
What are we trying to improve again?
When you look at some of those old notorious metrics like lines
of code or even things like cycle time, it's all about
looking at your software developers from the top down and
observing what they're doing and then making an assessment of
whether that is good or bad that doesn't actually Improve things.
And it actually doesn't even tell you if anything's wrong, or
if something is wrong, what it is.
And so, the philosophy behind developer experience is that, we
believe that the developer experience which we talked about
earlier. Meaning, the day-to-day friction
that developers encounter the things that make them stuck, the
things that make them frustrated, the obstacles that
get in the way, from them shipping and being able to
deliver things that customers as quickly as possible
understanding. Identifying and improving those
things is the key to productivity.
So that's the philosophy of what we're doing and so when we talk
about what do we measure? It's all around.
How do we identify? How do we measure that friction?
How do we understand where the friction in the organization
exists? How do we know if that friction
is good or bad? Meaning compare it against
industry benchmarks understand? Is this process slower or faster
than other organizations are high performing organizations is
this A typical or is it a sign of a bottleneck in our process
with DX? It's a little bit of a
long-winded response to get into kind of what we measure.
But in principle what we do is we look at the developer
experience as a whole and we publish the paper that's on our
website. That was our first peer-reviewed
paper on what actually is developer experience and what is
it made up of. So what we do at DX is we
identify what are the top drivers of developer experience.
What are the things in the day-to-day experience?
It's that most affect developers, things like slow,
tests, or nasty code or poor requirements on the task.
They're working on or delays in handoffs between developers or
difficulty building their code, deploying their code, releasing
their code or just slow feedback loops in terms of getting peer
review or getting feedback, even from customers.
So we constantly are looking at. Okay, what are the top things
crossing the street that affect organizations?
The most, I don't, we measure them.
With a multi-faceted approach. So we look at really three
dimensions, we look at first of all, the subjective experience.
Meaning, what's developers attitudes towards these things?
Are they satisfied with their tools?
Are they happy with the code review experience?
Do they have an easy time deploying code?
Or is it really difficult in addition to those subjective
measures? We also look at objective
measure, so we look at OK developers, feel like it's
difficult to release. Things.
How many steps does it take? How long does it take them to
deploy or developers are unsatisfied with the card review
process? How long do they typically wait
to get a code review? How difficult is it to review
other people's work? So we combine subjective and
objective. In the last Dimension, we
measure is around importance because something can be really
bad, but unimportant because you don't experience it frequently,
vice versa a really small. I like the analogy like Pebble
in your shoe, something really. All that's really, not that bad.
But you experience at every single day, could be really
important. So we really look at those three
dimensions. I like to call it a Triad of
developer experience. Well really, you can measure
those things in a number of ways, a combination of surveys
as well as helping customers instrument their systems to get
some of that data. In real time, we bring that all
together to customers and help them make decisions on where to
actually invest to improve their organizations.
Those Ittle bit long-winded, but in the gist, that is how we
think about improving developer productivity and how we approach
measurement around developer experience.
Thanks for sharing and details, actually, it really gives the
listeners more concrete ideas of how the ex works.
And apparently I also have given it a try.
So the way it works like you asked developers through surveys
and then they will provide answers these three dimensions,
like the subjective experience the perception.
And then the objective for How many probably days, it takes you
to finish a task, for example, and you have both subjective and
objective measurement and the other part the dimension of
importance is for you to choose after you get all these results.
What will be your focus area? So the team themselves can
choose each team's can have different Focus area so to speak
from there you will then do it again over the time and hence
creating this maybe flywheel effect that you keep on
continuing to improve the developer experience in
different parts of the Organizations and I just want to
highlight also this DX kpi's. So all these top drivers and all
these results, actually, the ex tries to come up with much more
like four key metrics Endora, right?
Like for KBS from the X which are engagement, productivity,
effort to deliver and time loss, it seems like different from
Dora or space. So tell us more about these
kpis. Yeah, great question with
developer experience, it's about what a kpi is like Nordstrom at
It's about what is the goal of all this.
So, when you take a step back and look at an engineering
organization, and you're talking about productivity, you're
talking about developer experience.
What's the goal of all of that? And that's what the dxk apis
are. So, as you mentioned, if your
developers are really productive and your processes are really
efficient those map, those dried, those predict or
correlate to better performance across the kpis.
So developer engagement is a measure Oh, Employee Engagement
of how energized and excited developers are in their work.
And that's such an important kpi for businesses.
Because if, you know, developers, their actual
day-to-day productivity is very much driven by the level of
passion and excitement. They have towards what they're
working on receive productivity. Looks at a slightly different
dimension of more cognitive and rational one of how productive
do developers self report themselves to be.
I mean, every manager will Developer, how productive did
you feel this past week? And that tells you a lot.
That's essentially what we surface at the organizational
level with that kpi effort to deliver really centers more
around tools. Although, it does touch on
practices. If you think about the ideal
software, delivery lifecycle from the standpoint of an
individual developer, you want it to be easy.
You want it to be really easy to start.
On a new feature, make changes test.
Those changes may be deploy, those changes.
To another environment staging environment manually test them,
send them to your CI CD Pipeline, and ship it to
customers. You want that to be really easy.
And so effort to deliver is around understanding the overall
ease or difficulty of that process.
And then, lastly time loss is about, literally, how much time
is being reported to be lost due to waste and inefficiency in the
process. So it provides a way to
understand those bottlenecks, the things Going to way of
developers in a way that can actually be translated to
Dollars. And that's what's so important
about that last kpi whereas the first three are similar to
employee engagement and that their sentiment scores time loss
is still a perceptual measure. However, it can be conveyed and
dollars that matter of the business.
And so with these pork apis, it's really about aligning
around. What is a good software
engineering organization look Like that's what the kpis really
provide to businesses in terms of how we came up with the kpi
sir, actually rooted in our research paper, I won't go into
full length out how that works. But really one of the things we
know about developer experience or experience in general, is
that it's based on this concept in Psychology called the trilogy
of the mind. And so there's really three
dimensions of experience, and three of the four kpi's.
So, all the kpi is except time loss actually map.
To those different dimensions of experience in Psychology and
they're also useful to businesses with our kpis.
One of the things that were working on is understanding
their predictive power similar to what dora did.
So we not only believe that these are from a research
standpoint, the right, North Stars for organizations.
We also believe that these Northstar metrics will predict
and correlate With Better Business performance and
outcomes things like attrition Things like financial
performance or non commercial performance, and that's
research. We're still working on and hope
to be able to share with the world early next year.
Wow! Sounds really exciting.
I'm looking forward to another research to complement Dora and
space. I'm sure looking at dr.
Niccole's and Margaret. And as part of the research
team, I'm sure it's going to be revolutionary as well.
But for all the X users, maybe you get a glimpse of it since
you've been using it as part of the software itself.
And I think this kpi is the most important.
Then for leaders, right? Because previously, they want to
get numbers the targets. So these kpis sort of give them
a numbers that they can aspire to improve and they're just for
not many. So you can actually look at the
apis for leaders. And then for engineers, the top
drivers, probably the focus area that you will improve.
So I'm sure all the listeners here who are Engineers or maybe
leaders. They are excited, they want to
improve developer experience but maybe they don't know how to
start or maybe getting into get the axes one but How should
people build a case in a company?
Which probably haven't invested a lot on developer experience.
Yeah, so I talked to a lot of companies about their Journeys
and investing into developer experience.
In fact I talked to a lot of companies that are really early
on that Journey so companies were it's just a couple of
developers kind of Grassroots trying to tackle developer
experience all the way to large corporations where c-level
executives are excited about developer experience but don't
know how to actually He began working on it.
I think from everything I've learned with developer
experience I probably wouldn't recommend just one day waking up
and saying we need to do developer experience because
that's not really what developer experience is about.
Although it is now a buzzword I think it's just dangerous to
kind of Chase Trends and fads and buzzwords in the tech
industry because that's how we ended up with like 1000
JavaScript Frameworks with developer experience.
I think the success stories I hear often all revolve around
there being an Viable pain in the organization that can take
many forms. Sometimes it's that people are
leaving. There's a tradition, in fact,
that app in the Airbnb, sometimes, it's that things are
just low hiring more and more developers, but you can tell,
it's just becoming harder and harder to actually deliver
things. And you're not really seeing
things accelerate as much as they should, as you hire more
people, other times you're, well, aware of developers
complaining about the problems and challenges they're having in
their day-to-day work. Whether it's the Old Times going
into the hours or even days or multi step process to test work
before they can deploy it to customers.
And so, I think beginning The Tackle developer experience,
should really just begin with picking one concrete thing
within the organization. Something that has leveraged you
want something that's going to provide a return for the
business. Simple way to illustrate, this
would be if builds take let's say 45 minutes to pass and
developer needs to run 10 builds a day.
On average. Just as part of their work, if
you can cut that time in half, you could be almost doubling the
capacity of your organization in terms of the productivity of the
developers and what they're able to Output.
So that's a simplified example. But there's many opportunities
like this for. I think most companies.
If you go looking, I think that's where you should begin as
identify as a single project and picture that to leadership
picture that to business stakeholders.
Use that. When to then start building that
muscle, start building that awareness and start building
that credibility and buy-in for the power and impact that can be
achieved when you invest in developer experience.
I think that's where I would sort of begin in terms of baby
steps. So I think that speaks to a lot
of leaders out there, right? So don't chase the buzzwords.
Start from the real problems that you see in your engineering
teams, you mentioned things like people leaving.
So that's probably a Earning sign already, although it's
like, probably too late by that or slow.
Build tests are flaky. Those kind of things focus on
solving that because that will definitely give a lot of impact.
If people are complaining a lot when it gets resolved, I'm sure
it will give a lot of impact and satisfaction.
But the other thing that I learned from my journey as well,
these things tend to change over the time.
So maybe these day. It's about built tomorrow.
It's documentation. The next could be test when you
write a lot of tests, maybe they are flaky or take.
Long to pass. I guess all these things like
Evolution, right? You probably never get a perfect
state. I'm sure.
Maybe some organizations think, oh, they want to have a perfect
developer experience. I think it's kind of like
difficult especially these are people problem as well, social
technical problem. So I guess these things them to
change and you mentioned in the beginning, some companies
actually invest in building dedicated team, maybe they are
called like enablement team developer experience team.
So for companies who are at that stage, maybe they are big.
Enough or they have hundreds of Engineers.
When do they need to start investing building such team and
how should they go about it for most readers who have developer
experience team? So typically talk about how they
should have done it sooner. So I think there's no sort of
singletrack answer to that question.
But I think, as soon as you're probably hitting around 50 to 80
engineers and growing and also probably hit a point of like
product Market fit in your business where you're not just
wild, Scrambling to ship things. You might throw away as soon as
you sort of have a longer-term view on the business and plan
for growth. I think that's the right time to
take a good hard. Look at how can we get double
the output out of our organization?
That's what developer experience is about.
It's about taking the people, you have and empowering them to
be able to do so much more. It's about getting the most out
of your investment. If you want to think, I have
business terms. And so I think the right time as
I said, if I sort of take the average of all All the different
companies I've spoken to, I think around 50 to 70 Engineers,
post product-market fit is a good time to start establishing
a muscle around developer experience.
I wouldn't necessarily say, you have to form a team because
there's many different ways to tackle developer experience.
It doesn't have to be a dedicated team necessarily, but
I think at that point, you would definitely want a senior leader,
really taking a good hard. Look at the developer experience
and looking for opportunities, starting to build a roadmap
starting to think about I2g and considering forming a team
around that if that's the right way to tackle the problem.
So yeah, I think I also myself faced this challenge with my
engineering team sometimes. Yeah, they are just anecdotal
complains. Okay, we had bad process here
but process there, but we're to tackle, sometimes is hard and
there's no dedicated team as well.
Every Engineers are just tuning out features over features of
visitors who will build the enablement team.
So I guess this is something to think about for those leaders,
right? When Is the right time for you
to start. Really investing maybe create a
more dedicated team build more purposeful tools so that
Engineers are more productive. Maybe this is a little bit more
of a challenging question for you to answer but what if a
company doesn't want to invest in develop experience?
They think. Oh, they're just Engineers.
They're just here to produce code.
So what would be your advice or maybe tips here?
That's such a good question. I mean, I think of this one
company that I know. I think they're around 300
Engineers. There's a couple A, they're
trying to get a Dub Fx function off the ground and doesn't sound
like leadership super bought in and I really feel for those
developers clearly, there's huge opportunities to improve the
productivity of the organization but executives are skeptical, to
be honest. I don't know if that's always a
problem, you can solve from the inside, you think back 10 years
ago even devops was hardly a term.
So I think in a sense the shamelessly, I would say calling
up a company like us to come in and talk to your Executives and
Tim bought in to the idea of developer experience.
That's part of what we do really is help developer experience
teams. Get buy-in from Executives by
taking a very sort of precise and methodical approach to
developer experience. It's really aligned with the
business. I think it's just hard.
Sometimes as developers were not used to some of the corporate
politics and the ways of the businesses kind of need to
operate and determine where to make investments.
So that's where I think developer experience has trouble
getting The ground sometimes is really speaking in terms of the
business can understand. Because I think if you use the
right language and present developer experience in the
right way, the ROI is very obvious and the organizations
that do invest in developer experience know that.
So I think it'll take a little bit of time before developer
experience. Sort of goes fully mainstream if
you will. Yeah, I talk to people all the
time about this and I think most in the industry would agree like
developer experience is still kind of early on that adoption.
Curve. And so if you're out there
listening to this and you're having trouble getting buy-in
from your Executives, that's to be expected.
Not every company that every leader is going to get it, but
try to make the case and terms that the business can understand
not using buzzwords, not pointing to Trends or fads in
the industry. But just point out the dollars
that are being lost or the dollars that could be gained
back, if that latent sort of potential could be unlocked
within the organization through And so developer experience,
that would be my advice so I know it's a hard problem, thanks
for trying to answer that. So I think any kind of
organizations, when they build Tech teams, they always think
about feature teams, right? We want to feature teams product
teams, whatever that is. I'm sure one day, you will reach
a point where but just feature team that they will build, they
will also build this developer experience team or engineering
enablement team straight away from the get-go and I guess I
would also rely on researchers your company and some of the
researchers behind the company. To actually publish this kind of
paper so that it becomes revolutionary.
So people take it, just like there are metrics right.
Oh, we have these four key metrics that we also should
think about when we talk about developer experience.
So I think the work that you do with your team is exciting, I
hope that something good covered in the industry to improve on
this. So I'll be, it's been a pleasure
talking to you. I learned a lot about improving
developer experience. So as we going to wrap up this
conversation, I have one last question, which I always ask for
my guests, which is to share this thing called Three
technical leadership wisdom. We can think of it just like
advice for listeners here to learn from your journey, your
experience, or your expertise. So what will be your three?
Technical leadership is the great question.
I think. Now the topic we've been sort of
discussing today, I would say be very discriminant about how you
choose metrics. There's a lot of stuff out
there. There's a lot of vendors out
there including us. I'll admit there's a lot of faux
research up. There's a lot of good research
up there. Know exactly what it is.
You're trying to drive in your organization before you start
picking up metrics. I see so many leaders shop for
metrics instead of really think critically about the types of
outcomes or hoping they achieve in their organization.
And then ask, if there are measurements that could help
them achieve that. So that would be the first.
The second would be surveys are very underestimated in our
industry. I think it's because we're
programmers and we love streaming real-time data.
Coming out of systems into pipelines and D3 charts, but one
of the biggest mistakes I've seen and Nicole for Scranton
would agree with this. We've talked about this is we've
seen Corporation spending tens of millions of dollars during
the instrument their systems to measure the door and metrics
when in fact what they don't realize is that even in her
research Nicole use surveys to measure the door metrics.
And in fact, the whole last third of half of the book goes
into y and And how she did that. And so surveys are way to
measure, both subjective and objective metrics.
There are limitations to using surveys.
For example, you can't measure things on a real-time basis.
You can't run surveys every hour.
You also can't measure things down to the millisecond with
surveys but there's a lot you can measure and I think a lot of
leaders are spending too much money too much hassle trying to
get poor metrics that won't even Help them.
When a more obvious starting path, if you think about it, is
to just start asking your developers questions about
what's getting in their way, how their processes are other tools
are working for them. The last sort of word was, I
would share here would be definitely to just follow the
research that's coming out in the industry.
Whether it's research on the different types of agile scrum,
kanban practices, or whether it's research, On algorithms
hardware systems. There's so much amazing research
coming out of academic institutions, as well as
companies like Microsoft and Google.
That's one of the things I've been working on.
Is I have a newsletter where we write summaries of research,
these research papers are pretty dense to read.
It's not really casual reading. And so, we're trying to make it
a little more accessible for practitioners.
And we have a multi-year, long, backlog of papers, we're looking
forward to sharing, but there's really amazing stuff.
As we talked about earlier, it's so important because the
research often debunk, some of the sort of trendy opinions of
the year as far as Fair, what you're hearing on blogs that
you're reading on Twitter. So I think more leaders more
practitioners even developers should be following the research
that's happening and I think would be able to use that within
their organizations to make the case for things like developer
experience, much easier if they were leading on Research rather
than for example tweets. I mean, they love all your
wisdom is really unique. So some of the key takeaways for
me is like Wes don't shop metrics.
Think of what actually the underlying problems you're
trying to solve and try to find measurement out of that then
surveys underestimated. The I agree with you.
Sometimes we engineer's, especially if you have a
dedicated team. They will tend to build
Technologies to solve a problem, and they will take a lot of
effort and time to actually build it.
But, at the end of the day, maybe survey itself suffices,
right? So, the ratio of input and
output properties with its 02 Let's do 70.
Lastly, I'm a subscriber to your sub stack newsletter, I find it
really interesting. You cover a lot of software,
engineering kind of a related research.
I was unaware of those kind of research people and luckily you
do all this so that I can read it in an easier way but like in
a dance complicated way of explaining things.
So thanks for sharing that and I'll put a plug for the
newsletter. So people can also subscribe and
read from there. I think it's really useful for
engineering leaders. So if people want to connect
with you or talk, Talk more about developer experience
online. Is there a place where they can
reach up? Yeah, always love connecting
with people. So I'm on Twitter, I'll be no.
Te you can email me, I'll be no DirectX a come or on LinkedIn.
Yeah, always happy to connect with people.
Sure advice by can help and hear what people are up to in the
space. Then a b also has a podcast, so
if you are into developer experience, do check out Abby's
podcast as well. So thanks again for your time.
I'll be really excited about all the research that your team is
doing. So, Good luck with all that and
looking forward to the paper being published next year.
Thanks so much. Thanks for having me.
This is fun. Thank you for listening to this
episode and for staying, right until the end, if you're highly
enjoyed it, I would appreciate if you share it with your
friends and colleagues who you think would also benefit from
listening to this episode. And if you are new to the
podcast, make sure to subscribe and leave me your valuable
review and feedback. It helps me a lot in order to
grow this podcast better. You can also find the full show
notes of this conversation on the episode page at tackling
Journal, dot death website, including the full transcript
interesting. Quartz and links to the
resources mention from the conversation.
And lastly make sure to subscribe to the shows mailing
list on technology. No dot f to get notified for any
future episodes. Stay tuned for the next
technology, you know, episode. And until then goodbye.