Developer Experience: The Gap Every Brand And Retailer Needs To Know About

What is Developer Experience (DX)?

Whether you employ developers or use agencies & system integrators, DX affects your customers.

DX is how software developers feel about their work. As a general rule, a positive experience leads to productivity and a sense of ownership. A negative experience leads to negative results. 

What is CX again? And how does DX affect CX?

If you want people to buy a good product, what do you do? Highlight the quality because that’s what proves your product is good.

If you want many people to buy a product, what do you do? Focus on the right price because money is the most common way we value products.

If you want many people to buy a good product, what do you do? Focus on customer experience (CX) because experience is the emotional trigger that convinces a person your product is worth having. 

Experience is like gravity. You cannot see gravity, but you feel it. You know it’s there because the earth below keeps your feet grounded.

Imagine you slept funny last night. You get up to brush your teeth, but the water tap is not working. You tuck in your cereal. As you pour the milk, it comes out lumpy and slimy. Honestly, how does that experience affect your working day?

Your experience affects your colleagues until it transmits to your customers. Like LinkedIn, every person is connected in some way.

For money-savvy people, think of experience as VAT tax. VAT tax is passed on from one business to another until it reaches the consumer. 

The crudest saying is...crap rolls downhill, and at the bottom of that hill is your customer.

The point is this; customers interact with the website built by developers. DX transmits to the product they create, which affects your customer. 

3 specific ways DX translates to CX

Quality of the Storefront CX

You can always tell how good an organisation’s DX is by looking at the storefront. Here are a few helpful questions to diagnose DX issues.

• Are you experiencing high bounce rates and checkout abandonment?
• Does the website suffer from performance issues?
• Does it lack finesse on how elements transition as you interact with the UI?
• Has it failed accessibility audits more than once?
• Is your SEO not ranking high enough despite your content efforts?
• Have you received security incident reports that keep happening?

If you said yes to more than 3 of the items above, your technical team is suffering DX issues. While the list above is not always visible to the naked eye, the customer knows something is not quite right. When they sense a lack in your commerce storefront, they leave. Every detail from error messages, pixelation of images, loading times and so on... affects the customer experience. Customers are generally quite forgiving, but a compound of issues may just break the customer’s patience and shop elsewhere.

Often CX issues are masked DX issues. When you have reoccurring issues on your website, that’s a sure sign that DX is the root cause.

Speed of delivery

The speed of delivering customer features is another measure of DX. 

• Is your competitor developing faster than your development team?
• Is the development team complaining about legacy code?
• Are your staging and test environments not reflective of the production instance?
• Are code deployments slow and cumbersome?
• Do you find a lot of missing requirements when testing features developed?

DX issues limit your ability to serve your customer fast enough. Imagine running a physical shoe store. Your customer likes a shoe, so she requested to try her size. The sales rep radios the stockroom, but the team is taking longer for whatever reason. In the meantime, the customer uses her phone to check the stock from your competitor’s website. She taps a few buttons and leaves. She just reserved the shoe with your competitor and has gone to collect it. You’re frustrated because the click-and-collect feature has been in your product roadmap. However, you keep facing technical issues, and you can’t seem to ship software fast enough.

Cost of running development teams

Another way to measure your DX issue is through HR stats.

• Do you have a high turnover of technical staff?
• Are you not able to retain the technical staff you want to keep?
• Is technical recruitment not producing the same results as before?

Staff turnover is the most common measure used for DX because it’s the easiest to notice. However, recruitment issues often blame supply shortage. At the same time, retention issues are invisible if the quality of retained engineers is not measured. 

3 common mistakes when fixing DX

Before we delve into fixing DX, let’s look at 3 common mistakes people make when trying to fix DX issues.

Add new toys - The most common way organisations try to fix DX is by throwing in newer technologies. Engineering complains about legacy code. This leads to a 2-year long digital transformation programme. They replace the whole system and introduce new tech but end up with the same complaints two years later. Fixing DX issues with newer technologies is like offering a child candies to appease their toothache. Not only is it a temporary fix, but it sends the situation on a downward spiral.

Add more developers - You've heard the cliché, nine women can't give birth to a baby in one month. Furthermore, having nine women means nine problems instead of one. Apart from adding useless cost, adding more people complicates team management and dynamics. However, the pressure to meet a deadline (or too much money) often leads to a common irrational. Experienced practitioners know more people does not accelerate progress but succumb to the request to reduce noise. You see the numbers game played out in large enterprises all the time. They hire a hundred offshore developers to end up with the same results as hiring five experienced engineers.

Add buzz rules - Agile is dead. Don’t do agile, be agile. Spotify agile. SAFe agile. Waterfall is evil... Software delivery frameworks are humorous and entertaining. It’s like watching Tom & Jerry bash each other on the head. Every episode, they run around repeating the same formula. The only thing that changes is the method of inflicting pain. Software delivery is a bit like that. The entertainment value is what keeps people fascinated until you get bored of the repeating pattern. You realise it’s a trojan horse strategy. The issue is usually much deeper rooted, and buzz rules are just a way for consultants to get in. That’s why merely copying tactical methods don’t work.

Improve DX through stronger technical leadership

Organisations often think DX is about technology modernisation or delivery frameworks—it's not. DX is primarily a people issue. Therefore, the way to fix DX is through stronger technical leadership.

In 2002, Google removed all their managers. No leaders, no bosses. It was a complete disaster. Leadership matters a lot. I’m not sure why Google needed an experiment to prove anarchy, but there we are.

The correct way to handle DX is through stronger technical leadership. I often find that organisations have excellent teams and incredible products. What weakens the brand is its technical leadership gaps.

The gap is not always caused by bad leadership. Often organisation leaders are capable, hardworking individuals who are willing to give 110%. However, technology is a moving target, and the pace of change makes the gap difficult to close. As organisations increase technology investment, the need for more technical leaders will continue to grow—and the gap will continue to widen unless you fill the gap.

3 leadership challenges that are increasing the DX gap

Organisations are struggling to sustain, replenish and retain their technical leaders.

Here are three challenges organisations face in every life stage as they try to develop leadership capability.

Existing Leaders - Sustaining technical knowledge

Technology is evolving and revolutionising. The technical competencies relevant five years ago are no longer relevant today. For example, JavaScript is starting to replace Java as the language for enterprise applications. 

Another example is web performance optimisation techniques. Domain sharding and various caching strategies are now redundant since HTTP2 came out. While businesses grapple with HTTP2, HTTP3 is being worked on with positive test results and will soon be released.

Microservices, cloud infrastructure and data-driven strategies are other technology shifts disrupting traditional practices with different ways of working.

Unless existing technical leaders keep up with the changing landscape, the gap will continue to widen. Keeping up with technology is like chasing the wind. You’re constantly running with no end in sight.

Future Leaders - Repleneshing engineering talent

There are also challenges in finding engineering talent that prevents organisations from building long term strategies. For example, nearshore and offshore hotspots such as Eastern Europe and India are no longer emerging markets. Economies and populations are fluctuating, which means new grounds need cultivation. The price and the business need are no longer matching up.

For western economies, engineers are more focused on product development more than ever. Product organisations and pure players are scooping up young talents. Traditional enterprises are like Titanic ships; they take time to move. Startups are like a speedboat; they can quickly manoeuvre to entice younger cultures. 

The changing economy and society are squeezing traditional enterprises out of the game.

Supply and demand are favouring engineers, and organisations are not the ones picking. Traditional enterprises are like that goofy kid no one wants in their team. Younger people are choosing to ride with fast and dangerous startups instead. Adventure is a stronger desire than the safety and security offered by enterprises.

Upcoming Leaders - Leadership development for engineers

The most complex challenge out of the three is leadership development. The industry is not producing enough technical leaders. Many engineers are prematurely promoted out of need, leading to high dissatisfaction on both sides.

The challenge for engineers is the lack of training opportunity. As a generalisation, technical people spend their day to day understanding the world through STEM.

• Mathematics - functional programming, 
• Concrete objects - object-oriented programming, 
• Observability - reactive programming, 
• Scientific method - test-driven development, 

...and other skills that promote a person’s ability to harness things but ineffective when relating to people.

Put simply; we can't expect leadership skills to develop naturally. External intervention and internal motivations are required. The current laissez-faire attitude in software culture is a glass ceiling that stops engineers from developing leadership skills. Organisations cannot just cross their fingers and bury their heads under the sand. Sometimes doing nothing is a form of action, but nothing leads to nothing when it comes to leadership development. 

Unlike technical skills, books are not sufficient in teaching leadership skills. Role modelling is a core part of any leadership curriculum—because leadership is not only about competence but also character.

3 ways to get started with DX and get fast results

So how exactly do we fix DX issues? DX is a huge undertaking but not impossible. A proper DX strategy takes a lot of time and money to implement. 

But here are 3 hacks I’d like to offer organisations wanting to take DX seriously.

Reduce DX scope through SaaS and Cloud-Native

The first thing organisations should do is to reduce the scope of their DX problem. Relying on SaaS and IaaS products are a great way to minimise the DX scope. In truth, the most significant value SaaS offers is not the existing feature set but their DX. Organisations with a strong DX culture will continually develop faster and better software. Therefore, the trick is to know how to buy a good product well. A product with fewer features but good DX will always be worth more than a product with a vast feature list but poor DX. Beware of products built through stitched acquisitions. They might look good on a spreadsheet but will take time to be well integrated. 

As you scale, you can replace your SaaS products with custom-built solutions fit for your business purpose. 

Engineering teams are like football teams.

• Goalkeeper - Infrastructure Engineers
• Backs - QA Engineers
• Midfielders - BE Engineers & Fullstack Engineers
• Forwards & Strikers - FE Engineers

Using SaaS and IaaS solutions replaces some of your technical members. In turn, this reduces the DX scope.

Prioritise Storefront DX

The second thing organisations should do is to prioritise their storefront DX. You can do this in two steps:

1. Decouple your storefront
2. Invest in your storefront

Decouple your storefront means moving to headless commerce. By decoupling your storefront, you reduce the DX impact that your BE systems are creating. A decoupled storefront allows frontend developers to ‘pull’ data from APIs. In contrast to monolith implementation, where data is ‘pushed’ to the storefront. A ‘pull’ workflow limits the impact of DX issues from the backend. Furthermore, a decoupled storefront allows a frontend led engineering team. Good frontend developers are CX focused, which leads to a multi-fold return on investment. CX focus + DX that leads to CX returns multiple CX benefits, which results in a CX inception.

Invest in your storefront means setting aside time and money to improve the storefront DX. 

Here are some examples for improvement:

• Introducing automation for performance, security & accessibility, 
• Static code analysis & other quality gates,
• Fostering technical improvement and craftsmanship through tech meetings,
• Increase cross-collaboration with design and UX through design systems,
• Provision of various testing tools to ease development & debugging,
• Bake in mentorship through pair programming and other training strategies

By prioritising storefront DX, you are protecting your frontline business teams. Thus, enabling them to serve your customers with joy. 

Ultimately, you want to fix DX, so it translates to better CX. The point is to increase profitability. Therefore, improving your customer touchpoints should be the priority for any DX initiative.

Appoint technical leaders with relevant expertise

In 2016, the USNWR report suggested that doctors are the best hospital managers. In the same way, engineers are the best managers for other engineers. The idea is simple, credibility in leadership is essential. Highly skilled professionals will only yield to people they respect.

Furthermore, you can’t teach what you don’t know, nor do you want to keep up with the latest techno buzz of the month. For example, can you Vue the Angular and React when Svelte takes over? As in, can you see the upcoming threats and opportunities of the technology landscape? Can you rescue engineers when they get stuck on a technical problem?

The most popular career ladder is the two-track programme separating engineering management from technical leadership. While it can work, even this is an inferior strategy that organisations need to think through. Over time, those who have chosen the management route will suffer competency gaps—a breeding ground for DX issues. In software engineering, that gap can start to widen in as little as two years.

Technical competencies are essential for maximum effectiveness. Without relevant expertise, the DX gap will widen and hurt promoted individuals and your organisation.

Therefore, appointing technically competent leaders at every level will ensure you limit the passing down of bad DX. Equally, good DX creates a virtuous cycle that translates DX to CX and pushes it up to other customers.

Final thoughts

For brands and retailers, tackling DX seems daunting, especially if you don’t have a technical background. Even if you rely on agencies or system integrators, remember that DX affects your customers.

Focus on taking small steps. Over time, small changes add up and make a big difference.

In October 2012, Sir Alex Ferguson, the Manchester United manager for 26 years, lectured at Harvard Business School. He emphasised the care he took for choosing the captain of the team. Without a leader, a team loses direction and discipline.

Start your journey by appointing the right technology leader for your storefront. Protect your CX by setting up your frontline DX first and foremost. As with any good planning, you focus on the results and work backwards. When you appreciate DX, you strengthen your CX offering that leads to a multi-fold return of investment.

For aspiring technical leaders, be the technical leader organisations need by striving to live by these three technical leadership principles.

About the author

Kane Balagtey is an experienced technical leader, having led onshore, nearshore and offshore teams for household brands and enterprise retailers. Kane’s goal is to help commerce organisations struggling with technical leadership by providing consulting and hands-on support. 

Kane led and strengthened a team of 23 frontend engineers based in Europe and LatAm, distributed across eight scrum teams.

If you need a technical leader for your commerce team, send me a message. I can personally help you or point you to someone who can.