Changing an organisation is hard - really hard. So why do it? For us it was simple: we were not happy with our results, however we measured them. We weren't happy with our product and customer experience, or our growth and revenue, or how our people were developing.
We were pretty good - with a market leading business, talented people, modern technology and agile engineering processes to build our products. But we believed we could achieve more by transforming our entire organisation to be the best at what we do.
We've been a good agile engineering team for several years, using continuous integration, XP, kanban, lean UX and other contemporary agile practices, with a talented and diverse team that prides itself on our engineering culture. However, our assumptions on how to build our product have been disrupted by new entrants ranging from startups to global established players.
We tried to respond to this several times, but we learnt that to achieve this, we needed to reorganise around our customers and how they use our products and services. This has required us to change the anatomy of the entire organisation by evolving our organisation through experimentation, failure and learning. It's a continuous process.
In our current state we have teams that are autonomous units, dedicated and accountable for specific parts of the user journey. They are continuously learning, self-sufficient and empowered to make decisions within their scope.
We no longer have a roadmap and competing goals across teams. Instead, we have one set of company-wide goals and the teams identify how we can achieve the outcomes we want. We measure everything against these results and therefore no longer push for features per se.
Our previous assumption - that more features leads to more impact - has resulted in product bloat, leading to a compromised customer experience. Our new focus is on changing customer behaviour rather than shipping features. If the feature does not have the desired impact on customer behaviour we kill it, leading to a simpler product for our customers and for us to maintain.
These are hard decisions, so the only way to align everybody is to bring data to the conversation. That means embracing customer development, getting out of the office and talking to people, fake-door testing, etc. We encourage the team to take small risks and learn quickly.
But we need more than process: it is the team, what they believe and how they behave that makes this happen. Silos used to compete for resource - our roadmap process made sure of that! So collaboration was poor, and our product became a representation of our organisation structure.
Today, people align on values. In each team we need leaders, collaborators, risk-takers, organisers, coaches and decision makers. The one thing they have in common is a passion for achieving outcomes that takes us towards our North Star.
With over 15 years' experience in the software engineering domain, David has had the opportunity to work for a number of leading companies building high traffic systems.
He started his career as a developer in a consultancy, working for telecoms companies, before moving into technology management and leadership. In the last 10 years he has worked for a number of companies, including Autotrader and eBay, building consumer facing websites and mobile apps. During this time he has played key roles in transforming how software teams work and improving their impact by adopting agile practices.
In his current CTO role, transformation goes beyond the product and technology teams; eBay is transforming its entire business to an agile, customer-focused product-led business. This is driven from David's passion for using technology and agile thought leadership to ensure products impact customer behavior for the benefit of customers and the business that serves them.
To buy tickets to see this fantastic talk, and many others like it head over to our ticket page.
Need help planning which sessions to attend? We've provided a breakdown of our various session types below.
A presentation and discussion of real-life (not theoretical) experiences of the application (or mis-application) of Agile and Lean practices. Case studies and experience reports include some discussion of lessons learned and an indication of how novel the work is.
Participants learn a new approach, tool or technology through using it to solve one or more practical exercises. Any software/hardware requirements are disclosed in the session description.
A session focused around some specific tool, technique or issue. Primarily led by the speaker, tutorials usually include some elements of interactivity or individual / group exercise.
An in-depth working session on a specific topic. May include paper presentations.