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.