Improving the Developer Experience (and everyone else too!)

I've worked at different types of companies, talked to people that work at others, and I've noticed a common theme across both: when the developer experience is great, the work is great. If it's not, it quickly can stifle innovation and lead to a mass exodus of developers from a company, potentially running it into the ground. I want to offer my opinions on how to improve the DX (Developer Experience).

It's no secret that some of the largest companies in America are primarily engineer-run companies; Amazon, Microsoft, Apple, Google, Facebook, etc. These companies have put people in place that strive to keep their employees happy. They support their developers who in turn support the company through creating new products. It's a symbiotic relationship. These companies have put in place a system to ensure that their product is continually iterated upon and eventually released to the general public.

Many companies don't have this luxury. Or they deliberately choose not to. It seems like such a simple concept to me: "do unto others as you would have them do." Yet I see many decision-makers at many companies that choose to push and prod developers into launching half-finished, half-working, and rickety projects "because marketing wants it now." That's not how a good company should work.

Developers within the workforce

Now, I'm not going to bash the decisions that people made or will make in the future. What I want to talk about is improving the overall workforce culture to be more accepting of developers, especially with the proliferation of people learning how to code. I believe there are three things that we can do to promote effective DX from an external perspective:

• Include developers in product planning talks
• Have clear and set-in-stone expectations
• Protect developer time

Developer inclusion within planning periods

Including developers in the planning phase of any project is an immense boon to the project. The stakeholders are better able to divulge their problems, the designers can work towards an actionable product, and the developers have a clear goal of what the product being delivered is. This allows for better inter-team cohesion and we can work together towards a common goal. When multiple like-minded people work together towards a goal, it feels much less like slogging through the daily grind and work becomes more fulfilling.

Clear and unchanging expectations

As a developer, changing expectations is the most frustrating thing ever. I've been run over by multiple changes that are "quick fixes" but have a large impact radius. If more than one person submits a change request that conflicts with another person's change, then you have a recipe for disaster. The best team I've worked with has a workflow where outside stakeholders inform the team of their problems and the team would do research as to how to solve that problem internally. This solution would be backed by A/B testing, user surveys, UI and UX testing, etc. Then we have an effective solution to the stakeholder's expressed problems that is solidly rooted in verifiable data. This allows us to remain steadfast in the face of an ever-changing, mysterious abyss of half-assed solutions caused by one-off business decisions to capture a small percentage of the target market.

Actionable time is valuable

Developer time is immensely valuable. I've been taken away from working and delivering the product that was asked; for a "quick meeting" that never really is.

"Preempting work-in-progress has a cost, both in terms of productivity and morale." - Nick Husher

It can be easy, especially coming from a marketing or sales background, to set up meetings to ensure that everyone is on the same page about a hypothetical product. This is fine to start with. What causes issues is repeated interruptions that could be remedied with a simple email or Slack message. The cost of these interruptions adds up quickly. Jason Heeris explains this phenomenon far better than I ever could.

A good solution is to set aside a specific time in advance that developers can work around and prepare for.

Another thing to think about is that developer skills aren't malleable. If you repeatedly ask a C# developer to code in Java, they will get frustrated or bored and quit your company. I think this kind of behavior is a death knell for larger companies that struggle with retention.

Non-developers in the workforce

I spent a lot of time talking about developers but I want to make clear that this advice is applicable to other sectors within a business.

Melting Pot > Homogenous Culture

Melting pots are known for the amalgamation of flavors upon contact with the taste buds. The sole purpose of partaking food that has been cooked in a melting pot is to enjoy the flavor given to you through the mixture of ingredients. In this case the taste buds are the employees, and the food is the company culture. Tasting a wide variety of flavors is more appealing than a single, bland flavor. A lot of what I see is more traditional companies shoehorn the same kind of culture for developers compared to other departments simply for the sake of having a homogenous culture.

I feel this will lead to an overall dissatisfaction in the workplace for both developers and non-developers.

"Culture is like taking the rituals of a small group of people and trying to come up with ideas big enough to wrap around a lot of people at once, who may not know each other that well." - Nick Husher

This is also why technical interviews put a lot of focus on culture fit, especially in the later rounds. Companies should try to strive to allow each team to dictate the workflow that is most effective for that team rather than try to force a system "because that's what everyone else is doing."

Recognizing good work

Another area where I feel many companies stumble and fall is recognizing their employees outside of their own internal teams. This recognition can occur in a multitude of ways. I'll explain a few that worked for me as a starting point.

• Putting an employee under a positive spotlight for their achievements
• Critique them away from their peers, in private

These two points will go an extremely long way towards creating a company culture that promotes people to do better and improve. After all, isn't work supposed to be a place where you continually strive to sharpen your skills?

That being said, there are pitfalls. It can be easy to hand out participation trophies and trivialize employee rewards. What I want to emphasize is that the employee recognition awards should be meaningful. They should have some thought put into them and recognize details rather than it be cookie-cutter. This can also direct other employees to strive for those awards, thereby promoting the culture businesses want to instill.

The road to success

The road to hell is paved with good intentions. I feel it's extremely important to make clear that awarding your employees with trophies and certifications are not and should not be the only way to mark success within a company. There should be multiple ways for employees to succeed in an ideal company. A few ways can be: a salary increase, a promotion, or a few extra days off. This makes it so that each individual employee is given the opportunity to choose how they want to be recognized. Everyone wants to feel noticed and valued and if you reduce the available paths to distinction, the fiercer the competition will be for those paths and that can cause a huge issues within a company.

Summary

This article talked a lot about the workforce in the context of developers, but I think it's applicable to employees within a non-developer space also. It is extremely important to cultivate a good working environment for your employees. I've seen it time and time again where someone new steps in to manage the dev team and the entire team hinges on one person leaving, then that person exits the team and the rest of the team takes this as a green light to start a mass exodus. This is incredibly dangerous for many companies as you are losing talent and the business logic's relationship with code. Both are incredibly expensive for companies to recover from and can have immense ramifications for any company trying to deliver a product.

Additional reading: http://randsinrepose.com/archives/meritocracy-trailing-indicator/