Developer Experience (DevEx) is a common pattern that exists in many companies. DevEx teams tackle problems that cross frontend/backend/devops boundaries. These teams typically have members who are skilled at communicating with stakeholders at different levels of an organisation. They focus on addressing complex issues that are blocking other people.
If web development is plumbing, then DevEx teams unblock pipes and ensure things flow as efficiently as possible. This takes a great deal of skill, and DevEx is a challenging job. It is challenging technically, but also because it invariably involves stepping on other people’s toes. It means innovating new ways to unblock processes that others may not see as blocked. This comes with the need to learn new tooling and ways of working, which can be unpopular.
If you do what you’ve always done, you’ll get where you’ve always been. DevEx teams know this and work within the constraints of the organisation to promote the strategic objectives of the organisation.
Force Multiplication as a Practice
Force multiplication as a practice involves thinking about the consequences of decisions.
The consequences of some decisions can be nonobvious and not apparent at the surface level. Code may work and by all accounts function as expected, but some decisions in that code may eventually lead to problems of a compounding nature that reduce efficiency. This is a multiplicative problem, particularly if that code itself sets a standard that is later copied across an organisation.
Force multipliers consider foremost the impact that their decisions will have on velocity. They look towards medium and long term impact, and are principally concerned with implementations that are generous to other developers. Such solutions focus on interoperability and simplicity over just getting the job done.
The best way for a developer to improve their own efficiency is to produce work that improves the efficiency of others.
DevOps Pipelines and DevEx Impact
DevEx teams act as force multipliers with an unquantifiable but outstanding impact on an organisation. They can:
- Identify issues that may not be apparent
- Address issues affecting Continuous Integration pipelines that slow everyone down
- Create better ways of handling Continuous Deployment and infrastructure as code
- Innovate internal tooling that solves organisational issues. Even if, and particularly if, other teams don’t perceive a problem
- Create architectural patterns that set standards and resolve problems at an organisational level
When DevEx Works, and When it Doesn’t
DevEx works when:
- The team is empowered to make decisions that benefit everyone
- There is understanding that those decisions may entail new ways of working
- The team itself communicates effectively without ego and from the perspective of those they engage with
- The team is cross functional and has members who are selected for their curiosity to know how things work. Knowing how things work leads to better decisions that benefit the organisation
DexEx doesn’t work when one or more of the above is partially implemented.
Traits of DevEx Teams
DevEx teams are developer avocados who tackle a different problem domain than other teams. They tend to think along the lines of:
- What are the consequences of technical decisions? Have these consequences been accounted for? Can we do better?
- What are the consequences of processes as they are currently implemented in an organisation? Can we do better?
- What are the bottlenecks in a system and what opportunities exist that could eliminate them?
They know the Pareto principle. They don’t seek to over optimise, and they know when to stop. They also know how to communicate this with others.
They do things the hard way. They believe in doing things right first time.
They identify people who bring a unique combination of talents. They also understand how to combine and arrange those people efficiently into a team that most effectively promotes the goals of the organisation.
DevEx is About Governance
DevEx teams govern themselves. They set standards that promote the organisation. They understand that governance is about making effective decisions, and they produce guidance for other engineers.