Presentation: Removing Friction In the Developer Experience
Abstract
Our ability to be productive engineers can be distilled to the sum of two forces: things that motivate us, and -things that hold us back. While the levers of autonomy, mastery and purpose and their effect on motivation are well popularised, engineering organisations are often held back by different forms of friction. We’ll discuss how we’ve applied a potent blend of microservice / serverless architectures, continuous deployment, and cloud technology to make it easy to push code swiftly, safely and frequently and operate it reliably in production . And, we’ll discuss the organisational tools like team self-selection, team ingredients model, voluntary adoption, internal startups that allow us to decentralise and decouple high-performing teams.
HBC Digital is the tech team behind the luxury experience at saks.com, saksoff5th.com, gilt.com, lordandtaylor.com and thebay.com.
QCon: What’s the motivation for your talk?
Adrian: Share the learnings of rolling out startup-style dev-ex in a large, corporate engineering organisation.
QCon: What’s the level & core persona?
Adrian: Engineers, team leads, CTOs.
QCon: What 3 actionable things do you want persona to walk away with?
- Autonomy, mastery and purpose are necessary but sufficient for great devex. You need to ruthlessly identify and remove the processes and architectures that stop you from getting change swiftly, safely and frequently to production.
- Stop wasting your time in the 'theatre' of staging and QA environments. Adopt techniques that allow you to test safely in production.
- Adopt devops principals so that your engineers own their code in production.
QCon: This all looks awesome Ade, but how do I adopt these techniques in my organisation?
Adrian: It's hard to change an existing architecture or organisation: change often meets resistance and that resistance can be overwhelming. Instead of trying to boil the ocean, why not simply draw a line around the existing system and practices of the organisation and say 'okay, everything outside this box is new, and in this new space we're going to think and act differently'. If you can show that these new techniques work, then folk within the box will want to adopt them and you'll get a natural shift to better devex.
Similar Talks
Scaling DB Access for Billions of Queries Per Day @PayPal
Software Engineer @PayPal
Petrica Voicu
Psychologically Safe Process Evolution in a Flat Structure
Director of Software Development @Hunter_Ind
Christopher Lucian
PID Loops and the Art of Keeping Systems Stable
Senior Principal Engineer @awscloud
Colm MacCárthaigh
Are We Really Cloud-Native?
Director of Technology @Luminis_eu
Bert Ertman
The Trouble With Learning in Complex Systems
Senior Cloud Advocate @Microsoft
Jason Hand
How Did Things Go Right? Learning More From Incidents
Site Reliability Engineering @Netflix
Ryan Kitchens
What Breaks Our Systems: A Taxonomy of Black Swans
Site Reliability Engineer @Slack, Contributor to Seeking SRE, & SRECon Steering Committee
Laura Nolan
Cultivating High-Performing Teams in Hypergrowth
Chief Scientist @n26
Patrick Kua
Inside Job: How to Build Great Teams Within a Legacy Organization?
Engineering Director @Meetup