Fix Your Foundation: Developer Experience

If you enjoy this brief look at DevEx, please make sure to click follow so you don't miss any future Adventures of Blink... and stop by the youtube channel, where I build cool stuff!

Does it ever seem odd to you that some organizations can move so quickly, while others seem to churn and churn without achieving nearly as much? It isn't as if they intend to behave differently... in fact, if you ask their leadership what their goals and desires are, you get the same general answers:

• We want to get to Production faster!
• We want our development work to cost less!
• We want everything to be safe - no security breaches!
• We want systems to be stable and performant!

So how is it that two organizations with the same goals have such wildly different results? Today I'd like to explore the foundational difference I've observed between the blazing-fast and the sluggish: the Developer Experience.

Wait, what does Developer Experience have to do with Productivity?

Developer Experience (or DevEx) is a term that describes how developers interact with their work environment, including the tools, processes, and organizational culture. The goal of DevEx is to create an environment that is efficient, enjoyable, and seamless for software development.

But how does DevEx make the company productive? To illustrate this, let me tell you a story:

The Tale of Poor Developer Experience

Imagine you're newly-hired onto a software engineering team. You show up on your first day, expecting to get started digging into the codebase of your team's application...

1. Your system account isn't created yet. It might be tomorrow before it's ready.

2. Your computer doesn't have any developer tools installed, and you don't have the ability to install anything yourself. You have to open tickets to have someone install all your development tools for you. The tickets by default are marked as a low urgency - it could be days before they're completed, depending on the technician's workload.

3. When someone finally comes to install the tools, their definition of "installed" doesn't include configuring the tool to work- that's left up to you, after the fact.

4. You have to piece together the system documentation for your team's application from 3 different document sources.

As the new hire in this situation, what thoughts are running through your head?

• This organization I've joined seems disorganized. Were they not expecting me to join the team?
• I was hoping to be able to get started on meaningful work soon, but now I'm going to spend hours, or even days, working not on making a difference with the team but just on being able to actually function.
• It's going to be very hard to get anything done here.

Contrast this with a different story...

The Tale of Good Developer Experience

Imagine you're newly-hired onto a software engineering team...

1. A week before your start date, your laptop arrives at your door with a note that says "don't start this up until day 1".

2. On your first day you get a personal call from the helpdesk, and someone walks you through connecting your laptop to the network and logging in for the first time.

3. You don't have all the tools you need installed, but you have access to install them yourself.

4. You can go to "docs.company.com" to learn how to do anything - from using the company's products to navigating the organizational structure to finding out about how to request a parking pass so you can visit the office.

As a new hire in this situation, you probably have a completely different set of thoughts running through your head:

• The company is enthusiastically welcoming me to the team by being prepared for my arrival. "Someone's effort is a true reflection of their interest in you."
• I'm in control of my destiny; if I need some software I can get it easily. I feel that my skills and training as a software developer are respected because I can make the decisions and get my stuff set up the way I like it.
• I feel that I can be self-sufficient with a lot more questions I have; easy access to documentation means that I can read through it at my own pace and search for things I need, instead of having to always ask someone else for help.

Blink, you're overreacting here.

It might be easy to dismiss these concerns. "It's just part of the onboarding process. There are valid reasons for the delays in getting accounts created. There are security considerations that must be addressed before they allow developer tools to function on company assets." When the problems are this pervasive, it's easy to get overwhelmed by them and just assume this is how it has to be. But what if it wasn't?

Putting the Developer First

Here's what I believe:

• If you genuinely want to succeed, you have to take good care of your customers.
• If you genuinely want to take good care of your customers, you have to be able to respond rapidly.
• If you genuinely want to be able to respond rapidly, you have to have fantastic engineering teams.
• If you genuinely want to have a fantastic engineering team, they have to be empowered to get things done.

Now here's the kicker:

- If you genuinely want your engineering team to be empowered to get things done, you'll obsess over removing obstacles from their path.

...and if you're genuinely obsessed over removing obstacles from their path... you're focused on... the Developer Experience. 😏There it is, in black & white - Developer Experience is the FOUNDATION of success.

Are you an executive who's trying to transform your organization? Start with the Developer Experience.

Are you a software engineer who feels like you're churning constantly and never making meaningful progress? You're likely hindered by some aspect of your Developer Experience that's broken... find it and fix it, and watch yourself speed up.

Are you a project manager who can't figure out why your team is always slipping dates? Think about the things that make it hard for your engineers to do their jobs, and either fix them or take it off their plates.

How to Fix Developer Experience

There are tons of ways to improve your DevEx... but here are some big ones:

Remove approval chains. Nothing is more soul-sucking than a process that requires me to wait until 17 people have signed off before I do anything. Ask why all those people have to sign off - can you switch from "approval" to "awareness" for any of them?

Prioritize self-service. When I have to request something from another person, it introduces queue time to the equation... I have to wait until they can respond to my request. That kills my momentum... I was in the zone, and now I come to a screeching halt while I wait for my turn in someone's workload. If there's a way to keep me in the driver's seat, I'll go farther, faster.

Cancel the meeting. If you want an engineer to move fast, give them space to work. Meetings are incredibly disruptive to flow, and getting back to a flow state after a disruption can take 20 minutes or more. Is it really necessary to have me in this meeting?

Wrapping up

Your engineers are most likely some of the highest-paid folks in your company. Why would you ever allow anything to reduce their effectiveness? Focusing on Developer Experience ensures that these folks can operate at their best.