The ING Direct way of working — Part 1: How we organise our teams
I’ve started a new publication about The Future of Work. A newsletter for people who want to change the Future of Work. Makers (aspiring entrepreneurs, creators, bootstrappers, Indie Hackers…) looking for inspiration to help create more fulfilling, humane and equitable futures.
Follow me on Twitter (@leandropinter) if you would like to hear more about it.
In this post series I will share with you the ING Direct Way of Working. A combination of Design Thinking, Agile and Lean Startup. We call it PACE.
I’ll split this series in 4 parts:
- Part 1 : How we organise our teams
- Part 2 : The stages of PACE
- Part 3 : How we generate and validate ideas
- Part 4 : How we deliver and measure success
Here is a quick overview:
Our guiding principles
We’ve designed this structure and way of working based on some key guiding principles:
- Deliver value to customers, faster
- Reduce hand-offs
- Simplify and de-layer the organisation
- Involvement rather than sign-offs
- Preference for cross-functional and stable teams
- Move the work, not the people
- Regular reflection and improvement
How we organise our team
Domains
Domains are cross-functional “business units” with between 4–10 Scrum teams each. We’ve designed them to have everything they need to meet their customers’ needs, as autonomously as possible.
We’ve used “Dunbar’s number” as a guide to determine the size of our Domains. We’ve designed them to be smaller than 100 people or so.
We have 4 Domains:
- Product & Marketing — Domain responsible for the creation of products and services.
- Experience — Domains responsible for the customer experience in all our channels
- Automation — Making things simple, fast and easy for our customers and ourselves
- Information — The right data. To the right people. At the right time
Domain Support Team
Each Domain is home to a Domain Support Team. These teams are responsible for ensuring the Scrum teams have everything they need to succeed.
They’re made up of dedicated experts in business and IT. In areas like user experience, product development, process and IT architecture, change and project management, risk, and finance. Each support team also has an Agile Coach.
There’s one support team per domain, and they’re co-located with the Scrum teams. They’re on-site to give their expert advice and guidance throughout the delivery process. This keeps our delivery processes fast and responsive.
Scrum Teams
All our teams are cross-functional. They have the necessary expertise to deliver any given piece of work. We try to keep the teams small — no more than 8 people.
The teams always have a Scrum Master, Product Owner and the Development team. The development team composition varies depending on the initiative and Domain. Most of them have designers, software engineers and test engineers.
Guilds
We borrowed the term guild from Spotify but tweaked the concept to suit our context. A guild for us is a combination of “community of interest” and “community of practice”.
We defined it as a group of people who want to share knowledge, ideas, code, and good practices. Guilds are cross-domains and open to anyone in the organisation.
So, how are we going so far
This structure has been in place for a bit more than a year and we are getting some good results. We are also making changes as we learn new things. (will share more on this in future posts)
In part 2, I’ll focus on “How we generate and validate ideas”. I will also touch on how we prioritise ideas, validate problems and solutions and last but not least, how we engage with our customers.
Have you implemented something similar, or completely different? I would love to hear your story.
Here are some articles I’ve published:
Making work more humane, fulfilling and equitable
The Maker Movement
