This session will explore the conditions needed to facilitate developer autonomy and create an awesome DevEx. What makes a good developer experience? What are the common stumbling blocks? How to architect to manage risk, governance and autonomy? How to build modern team topologies that don’t hinder progress and ensure long term sustainability? How to build a culture that is transparent and breaks down silos?
What is DevEx?
Developer Experience is about creating an environment in which a developer can do their best work.
How do developers feel about the processes, …
The work we do should not be the cause of all these negative feelings
Why is DevEx important?
it has impact on the organisations performance, the bottom line!
developers are expensive, why make it hard to do their jobs? -> Profit???
What does good DevEx look like?
- Heroku - do everything via the cli and Git
- Monzo - cli tools for deploying
DevEx is contextual
developers exist in an environment that is unique to your organisation and environment -> copying what other orgs does might not work for your org
A good developer experience is emergent!
=> create boundaries for risks and responsibilities
=> good fences make good neighbours
- builds, owns and runs the product - owns the product governance - owns the product risk - owns the end to end delivery - owns billing and financial risks
vs the Platform Team
=> create a shared responsibility model between Product Teams and Platform Teams
don’t try to make everyone do everything
=> create team interaction for fast flow -> Conway’s Law
Conway’s Law affects the developer’s experience
example: CTO responsible for engineering and QA vs COO responsible for Ops
=> adopt an internal OSS model -> platform/dev tooling code is visible to everyone
- everyone can contribute to making things better
- but must be clear who is responsible for it
an internal OSS model removes barriers to collaboration
example: Devs are not allowed to view Ops team’s code
=> create fast feedback loops
good DevEx facilitates this
How do we measure DevEx?
the SPACE framework
- S - Satisfaction and Well-being - P - Performance - A - Activity - C - Communication and Collaboration - E - Efficiency and Flow
– Forsgren et al., 2021
First time seeing the SPACE framework for #DevEx. Definitely taking this back to work so I can work with the devs to make their lives better. Cheers @hibri for the new info - and cheers @nicolefv for a new tool. #aotb2022
Dispelling developer productivity myths
- productivity is only about individual performance
- one productivity metric can tell us everything
- productivity is only about engineering systems and dev tools
- the biggest myth: productivity is about developer activity -> being busy
- finding flow is key, interruption is a drag
- meetings are both awesome and terrible
- a two minute daily reflection (and not being busy all the time) can help developers improve their days
A good DevEx helps devs find flow and reduces interruptions -> get into that creative zone
A good DevEx reduces the cognitive load for developers
A good DevEx creates an environment of psychological safety
Conditions for an Awesome DevEx to emerge:
- there are good boundaries for risk and responsibility
- team interactions are optimised for fast flow
- adopt an internal OSS model