While developing the Platform of Trust Developer eXperience, I’ve come to situations in which I or someone from the team wonders would some idea be inline with the goals we have with DX. We don’t have a 2 year plan or fixed goal (numbers or such) that has to be reached for example 2021. But since we don’t have such a plan, people are wondering and sometimes reluctant to surface their ideas. People should have tools to evaluate ideas so that micro management is not needed. DX principles also aligns the thinking across the teams. Since we are a new companywe don’t have the legacy burden of product-centric thinking but instead service and customer oriented thinking has been build in to our activities.

To fix this we have created Developer eXperience Strategy. Actually that is too grandiose to describe what we have at the moment. We have guidelines or principles. The principle are really high level guidance just giving the direction where to go. There no speed or target elements, just the direction. It kind of resembles the API Design Guide, which we corverted a month ago to Platform Design Guide. That Design Guide is not dictating all the details. It contains some details occasionally, but mostly it defines boundaries and patterns.

Some companies include DX principles in the API Strategy, but we think DX is so imporant that it deserves to be addressed as such. If you look at the 5 principles as a whole (just the topics) you’ll notice that 3 first principles are about the developer and their daily life. This is due to customer or developer-centric thinking discussed above.

Similar thinking in Tech team

Another example is The tech teams which has their own version of principles. Tech team here refers to our group of hardcore developers. It acts as guidelines for internal developer experience Here’s just few points from it:

Five principles of DX development

DX development list of items is shorter than the Tech team’s and mostly not so detailed as some of the items in Tech team list are.

We have 5 principles to follow. The below principles define the strategy, high level guidance on Developer eXperience development. If you are wondering if your idea on DX development should be discussed further, then see if you can justify it with the below principles. If your idea implement the principles, then it probably is a pretty damn good idea and you should raise it in Slack.

1. Developer in the center

Understand the needs and workflows of our customer as well as their (developer) culture. We need to know who the customers are, how they use our services, what kind of frameworks and tools they use, are they hobby developers, professional developers or something else? We do not proceed product-first, we value customer-first approach more. Keep the developer personas uptodate. Increase the accuracy of developer personas all the time. If they succeed, we succeed. Thus for example guides are written from developer to developer eg managers do not define what exactly in the getting started guides. Managers review the results and DX lead makes sure all is inline with business goals.

2. Enable flow state to increase happines and productivity

Help developers to be more productive and happy. Developers are hunting flow state all the time. That is when they are most productive and challenges gets solved. Some say their DX should not hinder developer flow state, but we want to look it differently. Our DX must enable their flow states and make it easier get into flow state after a break easily.

3. Support workflows

As a platform we need to provide end-to-end support. Our DX must be fluent from data integration to UX of apps consuming the standardised data. We must understand how our customers use our platform in their daily work, what role it has, how we take away the pain. Identify the pain points and figure out the reliefs.

4. Self-service tools

Platform is developed with API-first principle. Our customer service is build with self-service first. We must enable stabiloity and availability 24/7. We don’t know when some developer around the globe is willing to try out our platform. Self-service is expected by our customers. Tooling is one of the fundamental elements which can make our customers happier and get things done when they need it. Tooling refers to CLI tools, API client test packages, excellent documentation, status information, libraries.

5. Be in the front-line in global level

Getting where we want to be, the top, requires experimentations and culture of fast failure. We can’t be in the frontline if we do not take calculated risks and experiments. Our benchmark are the global leaders of API and platform economy.


Some more to read from 100 Days DX