Application Developer Productivity and the Developer Shortage – Dana Lawson, Netlify

This is texturing TV. Hey guys. Thanks from the throw.

We're here with Dana Lawson who's head of engineering for netlifying we're talking about developer productivity and some of the misconceptions that exist out there. Shall we say around that whole concept Dana welcome to show. Thanks for having me every time you turn around somebody.

About a shortage of developer talent. And the question is is that really the case or is it more the simple fact that maybe we just make development too hard and we're not simple buying enough to get the most out of the books we have. Well, I don't know.

I mean if you asked me six months ago, there was a developer shorter did say yes, but a seems to be swing in the other way, but that doesn't take away the fact that you know, the developer experience is one that we need to ensure is great. No matter what we do and some of the challenges that we have when trying to enable developers or you know, help them Reach maximum productivity or because of the tools and the processes and policies that you know, we put in place and we just need to get back down to Grassroots and help these wonderful humans that create digital experiences do what they need to do without me friction. And who is picking the tools for these developers?

Because sometimes I feel like the developers themselves don't get a vote in the tools because some company has already standardized on something and sometimes is the person who's picking those tools do they actually are the same people who use those tools? And is that part of the disconnect? I mean it really depends, you know, it all starts at how you you know?

Think about your culture your company. Empowerment of your team and there's different variables in place when you have to go to Tool picking. I think I think at the heart of it people have the best intentions typically but the best intentions aren't always the best outcomes when it comes to toll Choice.

Sometimes it's so disconnected from the actual person that's you know, utilizing what you've purchased. And so, you know, I hope in the least organizations I've been in that, you know, you have manager enablement and you know good ideas come from anywhere you're listening to your engineers on what's going to help them be productive and standardize on that and typically You know a good organization does. try Engineers, but sometimes you have Legacy tools or you have something that It started off with small usage that have become tightly inner wound with what you're doing.

And now there's a fear of removing the tool or even just changing a workflow can be challenging and it really it really does depend. I mean in really good organizations, you're always doing an annual tool review and understanding who's using it. How are we using it?

Why are we using it? But in some places you get stuck with what you get stuck within it typically in my opinion happens at larger organizations where there's a lot more to consider from just the usage amount on how to unwind that and so the decision making for changing the tools shifts sometimes. All right.

Well that wrote the hell that you just described as paved with those good intentions. It is her. Are there bottlenecks that you see consistently that could be addressed that we just thought it through a little bit more.

It seems like organizations are all insular and they don't always see the same thing that you might see because you talk to so many folks with the question is, you know have the devops processes become a bottle neck. Is it the security issues where where are the bottlenecks? Oh my gosh, I mean it's it's too much on either side of the spectrum.

You've overly implemented something and now you're so process heavy heavier, depending on this really long tool chain to do whatever you need to do so it can create bottlenecks because now you're like well just slow people get used to bad tools or on the other side you've tool spa and you haven't standardized on anything and everything is net. New this person ships code this way this person does it this way and you have this managerie of different different ways to do the same thing. And so then you're then you're changing a lot of different bottlenecks if it's the security group or if it's the devops group or if it's your own self.

So to me, I think the bottleneck occurs when you just aren't intentional as you said it Mike you got to be intentional what problem are you trying to solve? What are the best schools and then if new problems emerge it's like how big are the problems do? We really need a new tool set or do we need to tweak what we're doing?

And I think the difference that I've seen and at least in the past year is This kind of like wow, you know everything's available and open and the international series of apis and so are tools so it's just been you know, the Field of Dreams you can Implement everything and now you you know, a lot of companies and I've been Adam and been responsible for myself or just like wow, there's too many choices in the toolbox. It's the power of decision you get lost in the decision-making instead of just doing what you wanted to do in the first place, which is hopefully for developer ship some clothes code. So I think the bottle neck And it's just when you you don't have intentionality, you haven't defined the problem enough and it can really start from anywhere because you've overly defined it or you have it given it enough attention.

It seems like these days shift left is the answer regardless of the question, but it's not clear to me that that's eminently feasible because developers already have a few thousand other things that they're trying to do. So have we gotten into some sort of rut where we just assume we'll pushed everything left onto the developer and they'll figure it out. so but You know.

A good organization has to keep in mind that eventually you're going to have to pay for that debt. You can't you can't shift left forever. There has to be balance in there and at the end of the day if you still rely on humans to get your job done, whatever it may be then The Human Experience has to be considered and has to be weighed and I think the number one annoyance for any kind of Builder or maker is the inability to build mate to be consistently stopped when you're in the flow when you're trying to innovate there's a ton of studies that have shown every time a developer is interrupted.

It takes them about 23 minutes on average to get back in a state of flow. And as a person that creates software you want people to be in that state of flow because then you're shipping and you're consistent and I think because you can turn and put all these little problems under the developer. It's like what do you pay for?

There's a reason that devops became a practice. There's a reason that Automation and tool sets are are now, you know, A Forefront of how we deliver digital experiences and so you can only do that for so long, but I think you can also spend all your energy and effort. Going the other direction.

It's really just striking balance and having good practices on reviewing what you have in place. How do the humans in the developers and the team around get interact with it and then really measuring your outcome getting back to the simple practices of what matters most and how can you you know ensure you take care of the short-term by not losing sight of the long-term and it's the same problem. We've been faced with I don't know in every industry and every business no matter what you do.

It seems like the workflows are disjointed and a lot of times we're coming back to developers and asking them their address issues days weeks after they were writing their initial code. So can we get better at helping them find these issues while they still have the context for whatever it is. They're working on because I don't know about you, but I can't remember when I was working on last month.

Never mind yesterday. Yeah, I mean shoot black working on last month. It was like what I have for dinner last night.

I think it comes down to having a healthy balance of what you're working on at any given moment and creating a culture that actually supports and enables that so I I don't think any of us like to have our calendars 100% filled. We need that Focus time. We need that space.

We need that freedom. We need to be able to have a bucket of work that just helps enable the Future bucket of work. And so, you know practicing good discipline a lot of engineering, you know, workflows will say 60% you know planned work 40% unplanned work but unplanned work when we talk about that kind of split from feature delivery or you know project project additional.

You know adding on to a project you can't just have it be the wild west you want that 40% just to be like only 40% always on Innovation 40% always on one type of particular problem. We try to have this swim Lanes be defined and also created equally and it comes back down to you know, being kind to your future self and giving the space and time to be kind of your future teammates as well. And so as an engineering leader, I try to ensure that are Engineering Systems policies tool sets.

Have equal importance is the deliverables that we have and that we're fine-tuning and keeping an eye. There's a ton of great. Once again rubrics out there like Dora metrics, you know, how quickly are you deploying how fast are your rollbacks?

These are good pieces of ways pieces of information Frameworks that can help you measure and they say that the health of an engineering organization is the tempo at which it ships. And so if you're monitoring and you're measuring that Tempo and you're using these metrics that have been defined out there on on how to be able to measure, you know productivity, which is very subjective. Then at least you get some signal that says am I ignoring everything am I putting the workflow back onto the people or am I actually going to make us better every ship that we make because people can't remember the pain, you know, if you say oh, you know what we're just gonna we're just gonna put a whole bunch of comments in there and we're just gonna ignore these get errors and these get commits.

We'll come back to it next pull request. You're just putting that on somebody else's shoulders. We maybe even on your own shoulders and you're always gonna be a couple steps behind.

So I think it's about, you know, having some discipline utilizing measurement and also creating culture where it's important to clean up that and and what's again be kind to your future self and your teammates. I am reminded of some wisdom. My father once shared me.

He said friends don't make work for friends. So anybody makes work for you is not. That's right.

And even if it's yourself, you know, like treat yourself like you with your friends. Would you do that to your buddy? No, then don't do to yourself.

There you go. What's the level of automation people should expect to have if you're a developer. Would you evaluate an organization before you joined it based on the level of Automation and how much time and effort they've gone to to get rid of a lot of the toilet because you know, nobody wants to take out the garbage all the time.

I'll totally I mean, you know, I don't know I've been doing this so long. It's like if you're Scrappy, you know seed rounds start up and you don't got nothing and you're coming in like cool like put the best practices in place now everybody tries to push them off and say our series a series being I'll come and get to it. Maybe your Enterprise.

I definitely think that I'm you have to look at the The leadership and say do they believe in automation do they believe in future proofing the work that they're doing and enhancing, you know, the human developer experience so that you can work more efficiently there has to be this belief behind it. Even if you maybe don't have an implemented all the way. But if it's Asian.

This is like yeah, whatever will get to it. I'm gonna say no they're probably don't have you know, maybe maybe you like the toil maybe you're looking for punishment and that's what you get kicks off is just doing the same work over and over but I think a lot of Engineers once again, you know created software to do the job. They didn't want to do manually, I believe in the lazy engineer.

I am the lazy engineer. We want these for people patterns taking care of we see the rise of these AI tools doing it. There's If You're Gonna Go evaluate your next gig.

I don't know. I'd be very skeptical of feeling I'm gonna have a lot of you know growth and opportunity in my career. If they don't even believe in like the table Stakes of what you know modern development is and it is and it is even if you're not, you know tech company, um, you know, most most products are now digital products in the pandemic pushes to do that.

So I would I'd be worried. I know personally I don't want to be a garbage man. No way.

I want to I want to invest away for the garbage not to exist right? I'm not even putting it out there. So a good Engineers gonna be one that's always thinking about how can like you said like your dad said, how can how can you be better than you were the day before?

How do I get to there because a lot of organizations I think are just working off inertia. It was this is the way we always did it. So we do it this way all the time do I you know need to take I don't know two days a month and say all right.

Let's reevaluate the processes as the automation Advanced. Can we rethink this thing or what's the best way to approach that? I would speak.

Business language, right. I mean you can always talk and be a developer and talk developer speak and depending upon the type of company you're in it may not resonate. You know what I could say really?

It's okay. Like what business outcomes are you meeting? What are you not meeting?

Are you winning in the market? Are you number one in your space? Like you have to deeply analyze what successful outcomes look like for the business and speak the language of the business if you just talk about, you know, Shipping faster that may not resonate to the stakeholders that don't understand why you would want to put additional effort into tools development or automation.

But if you talk to the business outcomes and people start listening and I like to press on that it's like very business you want to thrive you want to win in the market and typically if a development team because you're trying to meet your markets needs by pushing something out there to the masses whether it's marketing site eCommerce digital information what not. You're trying to enable your voice and land whatever campaign you're selling or whatever product or whatever service you're providing and we can sit and look and say well How quickly are we you know meeting the public where we need to be how quickly are we gaining in the businesses? What is valuable to us as a company into our customer base and the translate that in into how you operate as a as a developer and as an engineering organization, I think a lot of a lot of Engineers when you're trying to Talk about the value and taking those two days a month to put in the work outside of what you're doing.

You got to look at it holistically, like what are you actually trying to enable and it does come down to Tempo and shipping and maybe you know, I hear over and over at netlify. We have a web hosting platform and some of the amazing things that we do as being able to separate, you know our websites. I know you're familiar with it.

Why is it important? Because we know that you can get that content out faster faster and we are customer say well I was only able to reach my customers once a week. Say let's talk about.

Automation once a week is that good enough for you when when you know, the world has an internet at their fingertips, I would say multiple times a day and so long story longer. I don't know. I poke holes when I hear that kind of nonsense and I say well Let's just really say, how are we winning at what we're doing no matter what it is, you know, if we're producing open source software or paid products.

Are we getting the ability to have these changes in people's hands because people want the latest and greatest and then what the best experience. How do we keep the joy in application development? Because there is a tendency when we talk about productivity to start measuring everything and then suddenly the place you're working in starts to feel like a factory and people get a little unhappy.

So how do I strike that balance between I want people to be more productive, but I don't want to have them feel micromanaged every second of the day. that's why I believe in automation, you know, not you know you good automation takes away some of the process and it just happens and so, you know, put your checks and balances in place, but when we talk about measurement and you know counting, you know, pull requests and all of that it's like Pull it back. Let's look at the bigger picture.

I think you have to have the bigger picture insight and say really how do we measure our success in a way that's consumable. I've seen objectives key results all sorts of Frameworks put in place to measure the outcomes of the business and the measure developer productivity, right? You heard me talking about Dora another way to measure don't go too deep.

Don't go too deep. Keep it keep it consumable have the the core one two, maybe four tops measurements in place that really signal the health of your business engineering organization and make it repeatable because what I see what happens is you put this measurement of productivity on this leadership shoulders and now everybody's kind of allergic to it and they're just like, you know counting beans and Counting pull requests. But does it matter it's a bunch of activity.

I can you can make vanity activity metrics all day. It's so easy to gamify life. But really what you should be focusing on.

What is the impact to our business and how can we make that repeatable over time? And how can we speed it up if possible instead of going down that deep and looking at a very singular level or measuring for measurement state or having status for status date? I say forget that nonsense, that's bureaucracy be a little bit Scrappy pull it up.

Get your pulse on what business outcomes you're trying to hit now make it understandable. So you don't want to go too deep because you know, what, we don't humans have the attention spanicles fish. We don't we don't want to go that deep.

Make it understood and make it be everybody's everybody's. Everybody's responsibility because when you went together, then you lose together too. And if you're not able to execute or have productivity then that affects everything that's what puts the Kinks in the chain.

So I try to keep it simple, you know, just keep it simple. Don't overly measure don't overanalyze, you know measures, you know back up your heart with your mind, but then take action and I think having a bias to action is more important than sitting there measure and stuff all day feel confident in your measurement and then go go All right, folks. You heard it here.

Productive development starts with happy developers make them happy and everything else will work its way through and don't be overly inclined to sit and look at a dashboard all day long. Hey Dana. Thanks for being on the show.

Thank you for having me. There's a lot of fun. Back to you guys in the studio.