How to Build Your Own “Spotify Model”

jon-flobrant-187778.jpg

It is early 2011 and you are the CTO of Spotify. You’re staring out of the window of a coffee bar in a snowy and dark Stockholm. It has been an amazing year. Your company is acquiring customers faster than ever and you’re launching in more and more countries. However, Google and Apple are catching up. It’s not a question if they will launch their own music streaming services, but when. To survive that eventuality Spotify must become a truly global player.

You have to do this while still figuring out how the music streaming business actually works. What do customers really want? What will they pay for? What do you need to do to convince someone to stop buying CDs or MP3s and instead be willing to pay for a monthly streaming subscription?

“We need to innovate, experiment and learn faster than the competition.”

To do all this on a global scale you have to grow your engineering team. It has been a huge challenge to grow your team from 10 to 100 in the last year. Some people predict you might even need to attract another 1,000 engineers to pull this off. You feel overwhelmed. How can you attract the right talent with the right mindset across the entire globe?

Managing a team of 100 is already complicated. But if you grow even further, how do you stay agile? How can you keep the start-up culture that has brought success so far and prevent becoming a lumbering bureaucracy?

Spotify’s organization design

Another two years have passed and the company now has 15 million customers. The engineering team has tripled in size to 300 people. A challenge that has been top of mind for a while now is, “With 30 teams, how do we make sure we build a castle that makes sense to the customer, instead of a pile of 30 bricks that nobody likes?”

The teams have started to experiment with a scaling model that uses Squads, Chapters, Guilds and Tribes who aim to implement ‘minimum viable bureaucracy’ and balance high autonomy with high alignment.

This structure is just one piece of the puzzle, though. Through a few workshops, the agile coaches came up with a set of organizational design principles with the autonomous team as the core concept. This extension of the agile manifesto is called “Agile à la Spotify”, and has been printed on the walls across the office:

  • Continuous improvement: At Spotify, part of my work is to look for ways to continuously improve, both personally, and in the wider organisation.
  • Iterative development: Spotify believes in short learning cycles, so that we can validate our assumptions as quickly as possible.
  • Simplicity: Scaling what we do is key to Spotify’s success. Simplicity should be your guidance during scaling. This is as true for our technical solutions, as for our methods of working and organising the organisation.
  • Trust: At Spotify we trust our people and teams to make informed decisions about the way they work and what they work on.
  • Servant leadership: At Spotify managers are focused on coaching, mentorship, and solving impediments rather than telling people what to do.

 

aditya-chinchure-494048.jpg

Full autonomy is a trade-off

Fast forward to early 2018. Spotify has 140 million subscribers in 61 countries. It has announced an IPO at a $20 billion valuation. Engineering is now 150 teams and 700 people. In total, Spotify employs over 2,500 people: the organization is no longer a startup, it’s a global enterprise.

A lot has gone really well. The culture is known for a high level of empowerment and trust, a focus on personal development, and is known for its sense of purpose. Teams are fully empowered to fulfill their mission and have the freedom to act independently. But as Joakim Sundén pointed out, it is far from an agile nirvana.

“What is the best thing about working at Spotify? What is the most challenging thing about working at Spotify? The answer for both questions is the same: Autonomy.” — Joakim Sundén

Managing 150 autonomous teams can feel like herding cats, especially when it comes to projects that span across teams.

Some recent examples: implementing SOX compliance to enable the IPO, keeping up with new privacy laws and moving all infrastructure into the Google Cloud. Also, the lack of focus on architecture and technical standards has made it challenging to scale the platform to support its growing user base.

Implementing these initiatives top-down wouldn’t work in Spotify’s culture. A team can simply say “I don’t want to do it” and would need to be seduced to give these priority.

Over the years, the lack of central planning and standardization has enabled hyper-speed, hyper-growth and hyper-innovation. But it has made certain things a lot harder that are easy for more traditional organizations.

“There is no right or wrong, it’s all trade-offs” — Henrik Kniberg

Time will tell how Spotify will continue to evolve. It’s a challenging balancing act between doing the right things, doing the things right and doing things fast.

Don’t copy the model

As agile organization designers, we’ve been following Spotify closely. Over the years, we’ve visited their offices several times. It’s an awesome company and there is much to learn from them. We love how the engineering culture videos have inspired thousands of people to start upgrading their organizations.

However, if you’re considering implementing the ‘Spotify model’, please think again. Is your organization building a music player? Is your organization still trying figure out its business model? Is your organization facing hyper-growth? Is “move fast and break things” applicable to your product?” Maybe. But, probably not.

Source: xkcd

Source: xkcd

When people copy the ‘Spotify model’, it often happens through a top-down directive, without taking a close look at what kind of culture and leadership is needed to make it work. Often the existing hierarchy is changed into a new, static matrix blueprint (even if the matrix is labeled with Squads, Chapters, and Tribes), instead of growing a culture of continuous participatory change. This will inevitably make things worse. Even people who work at Spotify recommend to not copy their model.

Don’t get us wrong: in order to enable agility in an organization, we do recommend that you move away from top-down management and focus on empowering capable teams. But to copy a pre-existing model and believe that your problems will also be solved, is short-sighted and naive.

“The only Spotify way of working that actually works is turning on the Spotify volume really loud and dance.” — Erwin Verweij

Evolve your own organizational model instead

Just as startups are focused on finding product-market fit, we believe you should start on a journey to find your organization-context fit. Spotify has been able to do both.

We love this quote that is at the heart of what we believe:

“Stop trying to borrow wisdom and think for yourself. Face your difficulties and think and think and think and solve your problems yourself. Suffering and difficulties provide opportunities to become better. Success is never giving up.” — Taiichi Ohno

So what can you do if you want to gain agility, speed and innovation? Where to begin?

First, ask yourself, is there a clear picture of what issues you’re trying to solve with a new organizational model? If possible, find a few measurable indicators of what needs to be improved.

Involve not only your leadership team, but also a wide variety of people in the organization to gather ideas and co-create a picture of the desired future state. A good question to ask is: what is holding you back from doing the best work of your lives?

Don’t forget to appreciate what is going really well and decide what you definitely want to keep.

Take inspiration from a wide variety of future of work practices and companies. Look at different models of self-organization that fit different scale and risk contexts. Look beyond Spotify and even look beyond agile to gain org-wide agility.

Figure out what the main capabilities are you need to upgrade and where in the organization they are rooted. The OS Canvas is a useful tool for this exercise.

Design and start a number of pilots that help you try out new ways of working and allows you to quickly learn if it fits your specific context. Expand the pilots that show promise. End the ones that don’t produce the effect you’re looking for. Build your organization’s ability to constantly try new behaviors and learning from those experiments.

At the end of the day, use the Spotify model as an inspiration for what’s possible when you spend time and attention developing your own operating system — not as a model for what your own system may end up looking like. Design, test, and evolve your own model as inclusively as possible. Don’t do a big-bang change towards a new static target operating model, but instead build the muscle for continuous participatory change.

Don’t “do the Spotify model” — do your model.

Co-authored by Roy Gielen (Agile enabler, trainer & coach at Ctree)

Beyond Agile: Why Agile Hasn't Fixed Your Problems

Most organizations today are slow, bureaucratic and broken. Employees, executives, stakeholders, and customers are unhappy. Agile is seen as the remedy, the magic cure that will solve all the problems. And after all, everyone is doing it, so why shouldn’t we?

Adopting Scrum, Kanban or other agile practices is a great way to start fixing the organization: it puts the focus on learning and iterating instead of planning and predicting. It helps you move away from the hierarchical model to a more networked model of autonomous teams. But it is far from a silver bullet.

At The Ready we have learned that a lot more is needed to unlock organization-wide agility and become future-proof. The truth is that most agile transformations fail to deliver what is promised. On several occasions we were asked to repair a failed attempt to bring agility and responsiveness into the organization.

What we often see is that organizations try to adopt agile in a way that is fundamentally at odds with the underlying mindset that it tries to introduce.Here are some of our observations.

Top-down agile doesn’t work, it simply creates a new command-and-control structure

The agile manifesto and its 12 principles provide a lot of wisdom of how to effectively create value in organizations. The manifesto tells us to ‘build projects around motivated individuals … self-organizing teams … and trust them to get the job done’. However many organizations and leaders end up adopting agile frameworks with the same plan-and-predict mindset they’ve always had.

Too frequently, the old, centralized, command-and-control system of management remains in place. When using Scrum, product owners mandate project scope and deadlines, and Scrum Masters assign tasks to team members. Now that backlogs have become transparent, even more time is spent on long-term upfront planning than before. The detailed plans and estimations need to be approved by oversight committees, whose main job is to “align” the agile teams. Time of team members is tracked in detail, and people are summoned to explain if there is a deviation of the plan. Failure leads to blame, instead of learning and innovation.

Teams suffer from slow decision making processes and policies that are incompatible with agile. Many teams never actually interact with a customer but end up executing whatever management tells them what to do. They arenot empowered to decide what makes most sense for the customer or bottom line. It’s almost impossible to get approval for great ideas that originate within the teams themselves.

“I tried to be innovative once, but I got stuck in meetings.” —source unknown

We can’t deal with the increasing world of complexity and unpredictability by doing more controlling, planning and prediction — even if we’re “doing agile.”We have to let go of our linear, reductionist mindset and instead aim for self-management enabled by servant leadership. The leader’s new job is to workon the system, creating a healthy environment in which people can grow and results can happen.

Comic by geek & poke

Comic by geek & poke

Agile is not a fixed end-state, it’s a way of being

The agile manifesto told us to value ‘individual and interactions’ over ‘processes and tools’. And yet, agile has become a jungle of tooling vendors and consulting companies selling frameworks that are implemented as a static blueprint.

Agile becomes the new ‘standard process’ and the attention shifts to implementing and enforcing the agile practices. Maturity models and reports are created to measure how much of the teams are complying to the new way of working. Doing ‘agile right’, while ignoring the underlying values and principles, will not lead to agility.

We are often asked “what does the organization look like when the transformation is completed?” That’s the wrong question. If you’re looking for a new fixed end-state, you’re missing the point of agile. To keep up with a fast changing world, the organization needs to change continuously — it needs to be agile everywhere. Successful organizations are like shapeshifters or chameleons. They go beyond agile practices. The organization is being ‘worked on’ every day, with everyone’s input, all the time.

Agile doesn’t fix your problems, it shines a light on them

Agile shines a light on the real problems of the organization but doesn’t necessarily offer a way to fix them. Agile is designed to make teams faster. This additional speed will put more pressure on the system, revealing the leaky pipes which then need to be fixed.

Very often the leaks are so deeply embedded in how the organization works that even the most experienced executive will be unable to fix them. Things that commonly need to be changed are decision making, prioritization, resource allocation, policy enforcement, performance management and organizational structure. Chasing such a big org-wide change can pose a risk to the person’s career progression or reputation in the organization even when that person is already at the top.

Scrum, Kanban and other agile methods can help organizations become more agile in pockets. But eventually these efforts plateau, and even stall, as they reach organizational constraints. The problem is not the people or their skillset, but legacy structures, practices, policies and even culture that reinforce old mindsets and patterns. If these stay in place, agility will remain constrained.

0_oBix46uOsrWE6PEG.png

 

Agile lacks the language to go beyond IT

Agile’s aim was to “uncover better ways of developing software”, and it did. Nowadays, it is successfully applied to other disciplines and other places where people work in teams to achieve a goal together. But because of its origins, it continues to be seen as the latest tool that we can use to execute IT projects successfully. The manifesto and its practices lack the language to get what we desperately need: a mindset shift in the way we organize work in the 21st century.

To bridge this gap, we like to articulate agile principles in broadly relatable language. These principles and questions will help you move from ‘doing agile’ to ‘being agile’.

Vulnerability over Professionalism
Bring your whole self, call it like you see it, stay open.
Do we talk about our emotions? How can psychological safety be enhanced?

Trust over Verification
Give your colleagues the benefit of the doubt (or get new colleagues).
Are people told what to do or can people self-organize and decide how to work?

Consent over Consensus
Make decisions “safe to try” and move forward.
What can be done to improve the speed of decision making?

Progress over Perfection
Have a bias for action, learn as you go, iterate. 
Do we try to get it right the first time, or have we adopted a mindset of making every step as small as possible?

Doing the Work over Discussing the Work
Go try something, get some data, come back.
How can we make meetings more effective and reduce the time spent on them?

Participation over Power
Seek cognitive diversity, perspective taking, engagement.
Do we ask for everyone’s input on how the organization can be improved? Can we let people decide for themselves what to work?

Open over Closed
Embrace transparency, let information flow, work in public.
Does everyone has the information they need? Can we provide clarity and improve transparency of priorities?

Sprints over Big Moves
Take small bites, timebox, steer continuously, commit to a cadence.
Do we steer continuously or are we still making long-term plans?

So as a leader, when I feel ‘yes this is true for me’, what should I do?

Do small experiments and learn how change happens in your organization.Learn what your people need. Point your agile toolkit at the organization itself. Don’t stay stuck in dogmatic agile practices. Let them bend and flex in order to serve you better. Start asking your teams what is holding them back from doing the best work of their lives. Ask them for suggestions to change the organization.

Imagine leading an organization where everyone is engaged in making the organization better every day. I recently saw a quote from a LinkedIn update that perfectly encapsulates this idea.

0_PRvtmyZjFN0eV3me.png

Too often organizations think becoming agile is something that needs to be added on top of what they already do, when in reality, as Rick states above, it’s more about unlocking the potential that already exists.

Don’t stay stuck in top-down agile. Instead, adopt an agile mindset and start addressing the deeper and more fundamental challenges in your organization.

Is time wasted in your organization?

This article was originally published on the blog of Headroom, and is also available on Medium and LinkedIn.

I help my customers transform into more adaptive, responsive and self-organizing companies. This is necessary to survive in today’s fast-paced, unpredictable business environment.

But as a small consultancy, the danger of extinction is also imminent. To prevent this, it’s important to work on these three things:

  1. be the most knowledgable in your area
  2. show the world that you have this expertise
  3. do paid work

Slack time

Many consultants forget to make time for learning and publishing, and actually I’ve stepped into this trap a few times myself. Due to the increasing amount of client requests, it’s very easy to get swamped by paid work, with the risk of losing your expert status and becoming irrelevant.

This is why planning slack-time is very important. Slack (not the famous team communication tool) can be defined as:

Slack
1. unused capacity
“still some slack in the economy”
2. lacking in activity; not busy
“a slack season for the travel business”

A while back I saw this helpful graphic in a deck called “How to improve your life” (by Henrik Kniberg) that explains the self-enforcing loop that he was aiming for.

slacktime

Be conscious of how your organization spends its time

In the article, he makes another great point:

“Organizations with slack are faster than organizations where the goal is to keep people busy all the time.”

It is useful for any kind of organization to be a bit more conscious of how time is spent. If it’s spent on unfocused meetings and an overload of e-mails, bureaucratic processes that add no value to the customer and slow hierarchical decision making, then it’s time to rethink your organization’s operating system. It might just prevent you from going extinct.

This company achieves 100% customer satisfaction with 0% managers

This article was originally published on the blog of Corporate Rebels, and is also available on the Medium and LinkedIn.

Photo by Michel Claus

Photo by Michel Claus

When I entered the office, it quickly became clear: this is not an average IT service provider. On our way to the meeting room, we passed through the canteen with a fully equipped bar and kitchen and a dining table that is at least 20 meters long. I sat down with their Organizational Development circle, which regularly comes together to improve the way their bossless organization functions. Nobody held back when talking about their culture: I sensed passion, candor and strong opinions. It was clear to me that these people are 100% committed. About halfway through our conversation, the company’s chief cook brought in a delicious lunch salad, served beautifully, as if we were in a high class restaurant.

Schuberg Philis

Founded in 2003, Schuberg Philis has approximately €50mln yearly revenue and consists of 230 people. Banks, energy companies, supermarkets, airlines and government agencies rely on them to keep their mission critical IT systems 100% operational under any circumstances and at all times. Their office, with in-house datacenter, is close to Schiphol Amsterdam Airport.

A large part of the Dutch society relies on their services, so some people would expect that in order to promise such high reliability and security, you need strict control, done by management. But that is not the case, Schuberg Philis is fully self-managed and has 0% managers. Their experts are in the lead.

“People are perfectly capable to make important decisions about their own life, why wouldn’t people be able to make decisions about how they work? People don’t need a boss to tell them how to do their job“. When asked if everyone could function in a self-managed organization, he responds: “I don’t believe it has anything to do with intelligence or having a high education; being responsible for your own life is a universal value” — co-founder Philip Dries

Customer teams

In most IT companies, the sales department negotiates with the customer about price and scope of the assignment and then hands over the assignment to engineers for implementation. Often, the engineers discover that was promised is difficult to deliver within the promised timeframe.

At Schuberg Philis, there is no sales department. Instead, customers work directly with experts. Every customer is connected to a dedicated team of 5–10 engineers that has full responsibility and mandate. Because there is no other department telling them what to do, the teams only commit to things they can actually deliver. They own planning and manage their own budgets. Because they are the ones keeping the service online 24/7, they make sure quality is high. Therefore, it is no surprise that Schuberg Philis has the highest customer satisfaction score of any IT infrastructure company in The Netherlands, for 10 years in a row.

The engineers have a 100% focus on the customer and try to understand all aspects of the customer’s business. This leads to involvement on all levels. One engineer said: “one moment I’m working on a deeply technical problem, another moment I’m walking around the customers’ trading floor and giving them advice about their strategic direction.”

Employee engagement

Schuberg Philis invests almost a quarter of their profits in enhancing the wellbeing of its colleagues and their families: there is an in-house psychologist, physiotherapist, sports programs and the in-house restaurant serves daily fresh healthy meals.

People decide their own office hours and when they go on holidays. Because of the high level of freedom and autonomy, there is a high sense of ownership and commitment. Engagement and retention at Schuberg Philis is very high.

People work very hard, but are much happier than in their previous jobs. Due to this lack of stress, absenteeism due to sickness is low (less than 1%). There is no stress from things they can’t influence: decisions made and imposed on them by managers, there is no stress from unproductive reorganisations or unrealistic targets.

No HR department

Even though there are no managers, people still want to have someone to talk to about their performance, growth and well-being. In the first few years of Schuberg Philis, one person was responsible for all performance evaluations and appraisals. But when the company grew, this was no longer feasible. They did not want to create a separate HR department because they felt this wouldn’t fit the culture of self-managed teams.

Instead, Schuberg Philis created the role of coach, which about 17 people took on next to their regular work. People select who they want to be coached by. This can lead to some coaches having no coachees. Chief DNA officer, Lotta Croiset van Uchelen calls this a self-correcting hygienic system: “by letting the individuals choose, you don’t need to create complicated policies”.

The engineers’ high sense of ownership and involvement can lead to overcommitment by team members. Coaches and team members tend to pick up these signals and are expected to give each other feedback. Vulnerability is key: asking for help is considered a strength, not a weakness.

Recruitment is done by the teams based on expertise, cultural fit , their ability to be self-reliant and work in multiple roles. Less than 5% of applicants are hired. New hires coming from corporate organizations need up to two years to get used to the level of self-management and fully ‘de-corporate’.

Standardization and decision making

Because of the way they are organized, some things are more difficult than in other companies. One of them being standardization. Because the engineers are used to innovate, they sometimes reinvent the wheel. It would be more efficient if teams would share best practices across teams and strengthen each other. But because the engineers are very autonomous, it is not easy to trust somebody else’s decision.

Another challenge is their ability to do group-decision making as the company grows. In the past, everyone had to agree unanimously (consensus), nowadays this has changed to consent: everybody has to actively say they don’t have objections. The next phase is to start experimenting with the advice process, because it allows for faster decision making, while the individual stays responsible.

There is also an increasing need to clarify who hold decision making rights for certain domains. That’s why they recently tried Holacracy, in which roles and accountabilities are very explicitly defined. But after the experiment, they decided it’s too technocratic, too slow and doesn’t fit their culture.

“Our core belief is that people should always be able to stay responsible for their decisions, and should not be able to refer to another role that is responsible. Because circles ask for mandate from super circles, we also suspect Holacracy could lead to a top-down hierarchy of circles. Instead, we want people asking for advice before making decisions. We think it’s a stronger mechanism as compared to setting mandates and boundaries.”– Ilja Heitlager

Meritocracy

Full disclosure: while doing my research for this article, I was asked to help Schuberg Philis as a consultant to improve their agile capabilities and some of the fore mentioned challenges. The way I was introduced to the teams also says something about their culture: I had to first present and show my expertise in a knowledge sharing session, only after which I started to get requests for help from teams. In a self-managed organization, nobody has the ability to push a consultant to teams. It will only work if there is ‘pull’.

“Although we don’t have management or hierarchy, there is still an informal hierarchy, just like with any group of living beings. Influence is gained through ability, talent and seniority. Leadership is on all levels. It’s a meritocracy.”– Lotta Croiset van Uchelen — Chief DNA officer

Conclusion

Even if you don’t want to completely move towards self-organization, there are several valuable lessons that can be learned from Schuberg Philis:

  • build small, independent, multi-disciplinary teams of experts who pursue a clear goal together;
  • let the experts that do the work, make promises to the customers;
  • let people decide how to organize their work and what they want to contribute to the organization;
  • let people choose a coach that looks after their well-being, instead of forcing a manager upon them;
  • experiment with different practices and decide what fits your culture.

Corporate agility centraal

'De juiste context voor waardecreatie'

Interview in CIO magazine (in Dutch). Tekst en foto door Hotze Zijlstra. Ook beschikbaar op LinkedIn of in PDF.

Aegon heeft een nieuwe cultuur en werkwijze gemodelleerd, waarin corporate agility centraal staat. De basis wordt gevormd door zelforganiserende teams die sturen op door de directie gedefinieerde waarde. Het zogeheten Next-programma is er niet alleen op gericht om de IT-teams agile te maken, maar moet de rest van het bedrijf meenemen. CIO Kees Smaling en zijn MT belijden de principes in woord en daad. Een open gesprek met sleutelfiguren Pieter Hartman, Germaine Doop en Jurriaan Kamer over veranderbaarheid, geleerde lessen en de volgende stap.

Aegon heeft naam gemaakt door de innovatieve initiatieven en een organisatieverandering die voor een groot deel gebaseerd is op agile-principes. Zijn jullie nu een soort evangelisten?

Kees Smaling: “Hoewel ik ontzettend enthousiast ben over agile, gebruik ik de term het liefst zo spaarzaam mogelijk. Het risico bestaat namelijk dat het door een etiket zo ‘verhyped’ wordt dat het z’n doel gaat missen. Je moet voorkomen dat je het te dogmatisch gaat invullen, waardoor de kans op weerstand groter wordt. Sommige trajecten lenen zich minder voor agile en meer voor een meer planmatige aanpak. Begrijp me niet verkeerd: ik geloof er juist zo erg in, dat ik bang ben dat je door het oproepen van die weerstand het kind met het badwater weggooit.”

Het moet vanuit de organisatie zelf komen? Mensen moeten zelf de autonomie pakken?

KS: “Tot zekere hoogte. Teams controle en zelfsturing geven is nuttig en gevaarlijk tegelijk. Wanneer je het op basis van de verkeerde waardes doet, dan ‘agileren de teams zichzelf het geheel uit’ – een mooie typering die ik voor de gelegenheid even leen van Ton van Rhijn (CIO CZ, red.). Daarom leggen we zoveel focus op het toevoegen van waarde, competenties en zelforganisatie in plaats van zelfsturing.”

Jurriaan Kamer: “Veel agile-principes gaan over teruggaan naar de basis: waar gaat het om en waar doe je het voor? Je gezonde verstand gebruiken om zo de veranderbaarheid erin te krijgen. Sommige mensen hebben een sterke behoefte aan vastigheid. Een groot deel is best bereid om stappen te maken. Een verkeerde verandering roept weerstand op, een goede verandering niet.”

KS: “Mensen hebben moeite met veranderen als ze de ratio’s niet kennen. Nadat we in het kader van de beoogde versnelling agile hadden omarmd liepen onze architecten bijvoorbeeld vast op allerlei initiatieven waarin ze mee moesten. Ze wilden overal grip op houden, wat natuurlijk niet lukte. Ik heb toen voorgesteld het om te draaien: niet voortdurend alles checken, maar de vangrails meegeven waarbinnen teams moeten bewegen. Binnen die marges – de zogenoemde ‘non-negotiables’ ofwel ‘ten commandments’ die architectuur heeft opgesteld — konden ze tempo maken.”

“Mensen hebben moeite met veranderen als ze de ratio’s niet kennen”   

Architectuur heeft sowieso vaak z’n eigen dynamiek.

Pieter Hartman: “Architecten moeten idealiter een half wiel voor rijden in plaats van enkele mijlen vooruit. Het lastige binnen een architectuurdiscussie is dat het punt waar je naartoe wilt conceptueel nog te ver weg ligt. Daardoor is de bereidheid en urgentie om aan te haken een stuk kleiner dan wanneer de doelen meer tastbaar zijn. Architecten zijn bij uitstek bezig met de langere termijn en die lange termijn continu vertalen naar het halve wiel voor rijden. Door architecten dicht tegen de business te plaatsen kunnen bruggen geslagen worden.”

KS: “Het belangrijkste is de aanleiding: want als je begint te praten in termen als tien niet-onderhandelbare geboden, dan stuit je al direct op weerstand. Terwijl dit juist hebt bedacht om te kunnen versnellen! Je moet dus beginnen met communiceren waarom je iets doet. Dan kunnen we bovendien melden dat we van zestig naar tien geboden zijn gegaan. We hebben er liefst vijftig geschrapt.”

Germaine Doop: “Wanneer je de meerwaarde uitlegt willen mensen graag meebewegen. Die waarde is vaak een stip op de horizon, een langetermijnvisie, die moet worden vertaald naar waar de teams dagelijks mee aan de slag zijn. Wanneer de doelstellingen en de context helder zijn, willen teams best gaan rennen.”

We duiken meteen de inhoud in. Wat Kees als CIO doet weet ik, maar wie zitten hier verder aan tafel?

PH: “Ik heb vanuit IT een uitstap naar marketing gemaakt. Intussen ben ik als Manager Digital Business Development weer onderdeel van IT, omdat IT en marketing ineen zijn geschoven. Samen geven we vorm aan de digitale transformatie. Zo hebben we anderhalf jaar geleden cXstudio opgezet, onze joint-venture met HCL die continu werkt aan de digitalisering van Aegon. Met Jurriaan en Germaine heb ik het model voor agile werken uitgetekend.”

GD: “Ik ben als interim enterprise coach door Next gevraagd om de corporate agility verder vorm te geven. Om de organisatie mee te krijgen in een ander gedachtengoed ben ik praktisch betrokken door te coachen, een andere manier van communiceren in gang te zetten en weerstand te voorkomen en weg te nemen.”

JK: “Ik ben in 2015 gestart om als interim manager cXstudio goed op de rit te zetten. Daar ben ik samen met Pieter en de rest van het team tot het einde van dat jaar druk mee geweest. Vervolgens was ik betrokken bij de ontwikkeling van het Next-model en de agile manier van werken van Kees' MT. Intussen manage ik een cultuurveranderprogramma gericht op interne beheersing. Totaal iets anders, maar wel met zelforganiserende agile teams zoals bij Next.”

Wel opvallend: agile-denken in domeinen als architectuur en beheersing, dat gaat best ver…

KS: “Ja, al zou ik achteraf bezien toch iets meer maturiteitsslagen binnen IT gemaakt hebben. We hebben het nu wel heel snel breed getrokken; HR is ermee aan de slag gegaan, marketing en het interne beheersingsprogramma. Ik ken geen bedrijf dat zo gretig agile heeft omarmd. Veelal werkt de IT-functie agile en kost het grote moeite om het de rest van de organisatie daarvan te overtuigen. Hier was op een gegeven moment bij wijze van spreken bijna geen IT’er meer betrokken. Dat kon niet de bedoeling zijn en dat hebben we inmiddels gerepareerd.”

Ook als MT werk je agile, kun je daar iets meer over zeggen?

KS: “Ten aanzien van het MT geldt hetzelfde als met architectuur: de veranderingen zijn zo talrijk dat je niet langer alles kunt checken en bijsturen. Je zult dus een vergelijkbare werkwijze moeten hebben als rond de tien geboden. Veel meer coachend: zorgen dat je de waarde belegt bij de juiste eigenaren en het niet allemaal zelf doet. Dat proces hebben we in gang gezet. Qua werkwijze zijn we van wekelijks vier uur MT-overleg naar tweewekelijks twee uur gegaan. Niet meer elke dag een call van een haf uur, maar een keer per week. We spreken problemen kort door en dragen het vervolgens over aan de waarde-eigenaar. Presentaties in het MT zijn voor iedereen toegankelijk. Het MT is open gegooid, zodat iedereen binnen de organisatie dezelfde context heeft.”

GD: “Door deze transparantie faciliteer je de corporate agility voor het gehele bedrijf. Wanneer iedereen van elkaar weet waarmee men bezig is, kunnen mensen elkaar weer verder helpen. Zo kun je organisch groeien.”

KS: “Het is wel behoorlijk lastig om iets organisch te laten groeien zonder belerend te worden. Je moet vooral helpen de vraag te formuleren in plaats van antwoorden geven. Mensen zijn al heel snel geneigd te denken dat je wilt kaderen, standaardiseren, nieuwe afdelingen zetten. Dat staat zo haaks op het gedachtengoed.”

PH: “Mensen denken in termen van sturen, besturen en eigenaarschap in plaats van wie samen iets tot een succes kunnen brengen. De vraag wie het precies gaat leiden is veelal minder relevant.”

GD: “De verandering die op mensen af komt raakt alles: het functiehuis, de rollen en daarmee de identiteit van mensen.”

Het oude denken en hiërarchische verhoudingen zijn de grootste hindernis van verdere ontwikkeling.

KS: “By far! Niet de mensen persoonlijk, maar het gedrag en de structuur. Zichtbaarheid van managers is niet belangrijk meer, al zitten we nog in de overgangsfase. Op een gegeven moment gaan van nature dienende managers, die omdat ze door mindere zichtbaarheid de credits dreigen te verliezen, zich toch zichtbaarder opstellen. Dat remt de versnelling. Het is een best lastig fenomeen. Ik krijg er bovendien de vinger niet achter wanneer het nuttig is om directief te zijn, al is het soms duidelijk dat er ingegrepen moet worden.”

JK: “Je moet de balans zoeken tussen een team beschermen en tegelijk het bevredigen van de behoefte van de rest van de organisatie. Op die manier kun je het nieuwe laten groeien.”

KS: “Als die context nog niet rijp is voor sterk faciliterende managers, omdat we daar een beeld van hebben dat ze te weinig doen, dan heb je blijkbaar meer tijd nodig. Er is al heel veel ten goede veranderd: openheid, flexruimtes, sturen op waardes, andere manieren van werken. Als je hier voorheen om 15.00 uur het pand uit liep, dan kreeg je direct een flauwe opmerking naar je hoofd.

JK: “Bedrijfscultuur is een sterk fenomeen. Wanneer je het anders gaat doen, is het gevaar groot dat de antilichamen in actie komen. Voor je het weet is alles weer bij het oude.”

“Het MT is open gegooid, zodat iedereen hier dezelfde context heeft”

Top-down of bottom-up?

KS: “Er pleit een ding voor een top-down model dat bedrijfsbreed wordt doorgevoerd, en dat is dat je niet meer terug kunt. In een organisch model zoals bij ons loop je toch nog lange tijd het risico dat het uiteindelijk wegebt. Kijkend naar de essentie van agile is het evenwel tegenstrijdig om het top-down aan te vliegen.”

GD: “Op onze manier creëer je een intrinsieke verandering op de lange termijn bij mensen. Top-down is dat anders, omdat mensen dan mogelijk alleen voor de vorm meedoen.”

Waren er nog andere geleerde lessen of momenten van inzicht?

KS: “We hebben aanvankelijk veel gekeken naar anderen: Spotify, LinkedIn, Facebook, Google. Op een gegeven moment heb ik geopperd om daar eens te mee gaan stoppen. Wat hier zou kunnen werken is – het is al meerdere malen gezegd – voor een groot deel gezond verstand. Geïnspireerd door anderen, maar op onze manier met onze context.”

JK: “Spotify heeft ook goed gekeken naar anderen. Ze hebben net als wij gekeken wat voor hen het beste werkt.”

PH: “Zodra agile een verplichte werkwijze wordt, ben je het leereffect alweer kwijt.”

KS: “Dogmatisme voorkomt dat je genuanceerd moet worden. Je hoeft niet meer te denken, want alles is zwart-wit. Lekker makkelijk. Agile dwingt je te blijven denken en dat houdt je scherp.”

GD: “Je moet jezelf constant bijsturen.”

KS: “Het gevaar is dat je het nuance-verhaal misbruikt om op pragmatisch wijze de weerstand te omzeilen. Soms moet je er gewoon doorheen. De ervaring is dat agile veel gedisciplineerder is dan traditionele werkwijzen.”

Jullie zijn een behoorlijk eind op weg, wat wordt de volgende stap?

KS: “We zijn enthousiast over de sfeer, de energie en hoe de mensen erin zitten. We vermoeden ook dat de performance verbeterd is. De volgende stap is de meetbaarheid van het succes. Daarnaast zijn we erg druk geweest met elkaar voortdurend te vertellen over de nieuwe manier van werken. Terwijl we het er juist over eens waren dat de manier van werken er niet meer zo toe doet. Het moet zo gewoon zijn, dat het niet meer speciaal is. Je moet het hebben over de waarde. Agile is geen doel op zichzelf.”

JK: “Terug naar de basis: je gezonde verstand gebruiken. Het MT ten dienst stellen van de organisatie: zorgen dat de teams goed kunnen draaien, dat je blokkades wegneemt en desgewenst richting geeft.”

PH: “Voor 2017 wil ik meer eigenaarschap op de waarde. Zodra bijvoorbeeld ergens sprake is van een afhankelijkheid, dan benoemen teams die afhankelijkheid als het probleem omdat ze niet meer zelf kunnen sturen. Dan zadelen ze de manager op met het probleem. Terwijl het team zelf het mandaat heeft om het samen met andere belanghebbenden op te lossen.”

GD: “De gedeelde visie dat we met het MT faciliterend willen zijn aan de teams, is al best een grote stap. Met het loslaten en ruimte geven komt een grotere verantwoordelijkheid bij de teams zelf.”

“Agile dwingt je te blijven denken en dat houdt je scherp”

Kees, welke rol speel jij daarin als CIO en vanuit je MT?

KS: “Vanuit mijn rol is dat de juiste context creëren. Net als bij innovatie: ik moet de kans verhogen dat hier iets innovatiefs ontstaat. Dat betekent de juiste mensen naar binnen halen, ze soms de vrijheid geven, soms wat vragen stellen, het kan van alles zijn. Dat zou de toegevoegde waarde van management moeten zijn. Om dat proces op gang te krijgen heb je soms wat directieven nodig.”

JK: “Maar wel met een luisterend oor.”

PH: “Aanwezig zijn als het moet.”

KS: “Dat is qua beschikbare tijd nog een uitdaging op zich.”

 

Leading agile change

7 ways to effectively manage an agile transformation

This article was originally published on Emerce (Dutch), and is also available on LinkedIn (Dutch) and Medium (English).

Managers who ask: “Why are we not speeding up?” Teams who say: “We keep on explaining the reasons we are being held back, but nothing changes.” “Great that we are now a self-organizing team, but it’s still the managers who are calling the shots.” Just a few remarks from the employees of a large financial institution that implemented agile. Do you recognize this? In this article, you will learn about the 7 characteristics of a successful transition team and what you need to do to ensure that your agile transformation will run smoothly.

It doesn’t happen by itself

Just like many other companies, the financial institution had realized that their way of working was no longer able to meet the requirements of this day and age. Slow procedures, low motivation, disengaged staff. They decided to implement the solution that everyone was talking about: Agile. Working with self-organizing, multi-disciplinary teams should save the company from going down. When the changes did not have the expected effects, the CEO asked us for help.

Unrealistic expectations

During our talks with management and with the teams, we discovered there was a lot of frustration. The teams did not know what the objectives were and why the changes were necessary. At the same time, the managers didn’t understand why things weren’t moving faster. Agile was seen as a silver bullet that would lead to improvements straight away.

“We trained everyone, we instated a project leader, implemented the transition plan which we carefully monitored through the steering committee. But still, we aren’t seeing the teams accelerate and we aren’t seeing an improved bottom line”- member of the steering committee

Start at the beginning

We have helped many different organizations with agile. Most of them apply it in their IT department, others use it for their marketing and growth teams. We see many similar challenges. An agile organization requires a different kind of leadership, a transition team (T-team) that functions well is essential. When we put a transition in motion, we always make sure the following seven requirements are in place:

“We’ve implemented Scrum, but it is unclear to me why it was necessary. All those extra meetings cost a lot of time. It’s a hype, it will pass.” — team member

1. Define your “awesome” end-state

Becoming agile is not an objective in itself. Agile is a method that you use to reach a certain goal, and that goal needs to be crystal clear before you start. Common goals are: shortening the time-to-market, becoming better at dealing with change, more innovation, increasing quality, less bureaucracy, bringing more energy and fun into teams, increasing commercial effectiveness, staying ahead of competition. Make sure the rest of the organization knows why your vision is important and what your “awesome” end-state looks like. By making the goals measurable, you can also make a fact-based assessment of how the transition is going. Just like when you’re trying to lose weight, you weigh yourself often so you know if you are on the right track to achieving your goal.

“We have explained very often that we can’t speed up because we are dependent on another department. But it seems nothing is being done to change this situation.”- team member

2. Remove impediments

Every team will run into impediments while implementing their new way of working. Examples of such impediments are dependencies on other parts of the organization, political games, unnecessary rules and procedures, unsuitable reward systems, conflicting goals. The transition team’s most important task is to take away the impediments that the teams cannot take care of themselves. You are the A-Team that comes to the rescue when they get stuck.

“My experience is that the biggest speed killer is us, the management, because we keep behaving in the old way. The largest change that needs to happen probably needs to happen within myself.” — a manager from the transition team

3. Don’t be the bottleneck

We often see that leaders think the staff needs to change. “If they implement Agile, our problems will disappear overnight.” However, the following is true for every change: leaders go first. In order to become agile, a change in mind-set and behavior is necessary, this includes the management team. As T-team you are the enabler of the transition, not the driver. Stop micromanaging and rethink the way you keep a handle on things. Make sure you don’t act like a steering committee that says: “You should change”, but instead, send the message: “This is the direction we would like to be headed. What do you need to get there?” That way, you remove the gap between management and staff.

4. Lead as an agile team

Do not underestimate the power of leading by example. When the T-team adopts an agile way of working, you show people that you believe in the change and that you understand what the new teams are going through. Work in sprints, do daily stand-ups, give a demo, keep your own backlog in a visible spot. By holding retrospectives, the T-team becomes a well-oiled machine that is constantly improving. A safe place where members are open to each other and are able to express their doubts.

5. Have a team that can make an impact

Make one member of the transition team responsible for keeping track of the backlog; this person takes the role of product owner. This person does not have to be senior in rank, but he/she should be the one leading the transition. Additionally, the transition team also has an agile coach, who facilitates the team’s working process.

When it comes to removing impediments, you need people in your team who are able to do so quickly and effectively, for example the managers of the employees in the teams. It is also important to have a sponsor from senior management, who can join the team regularly and take away any impediments. Structural impediments do not disappear by themselves, it costs time to solve the issue properly. T-team members must have sufficient time available to make this happen.

“It is great that we are being asked what we need to make more impact. I get the feeling that management is now working for us, rather than the other way around”- team member after visiting the T-team demo.

6. Be transparent and ask for feedback

The transition team should present their results regularly in the form of a sprint review or demo. In this event, you present which steps you took, still have to take and which changes and obstacles you see ahead. Show what works, and don’t be afraid to show what doesn’t. Don’t forget to ask for input: “Do you feel that we, as a transition team, are doing the right things?” The management does not always have the answer to everything, and when you don’t have the answer, stop having meetings about it but quickly bring your challenge to the agile teams for advice.

A demo is a good time to continue the conversation about why the changes are important for the organization and what the end-goal is. This creates clarity, which helps to reduce stress.

7. One step at a time

For a sustainable change, it is best not to turn the whole organization around in one go. So focus on the most important issues, create short-term successes and gradually move to bigger things. Experiment and find out what does and what doesn’t work in your context. So no “big bang”, but “inspect & adapt”. By dealing with the changes team by team, you will be slowly permeating the old organization, until you reach a critical mass and “the others” will be forced to join the change. Be patient: it can take months or years for the culture of an organization to transform.

*Co-author Timo Mulder: founder & managing partner of Value First. He helps growth companies and corporates to speed up their innovation and marketing teams using agile and lean startup techniques. Together, Timo and Jurriaan have helped more than 200 teams and 30 organizations make a bigger impact.

Hackathon: spitsstrook voor innovatie

Dit artikel werd gepubliceerd op AG Connect, en is ook beschikbaar op LinkedIn.

Vrijwel alle succesvolle techbedrijven doen hackathons. Het is de manier om innovatie te stimuleren. Ik woonde de laatste hackathon van bol.com bij. Die dag konden ongeveer negentig techneuten zelf bepalen waar ze aan wilden werken. En als mensen werken aan iets wat ze zelf graag willen, ontstaan de mooiste dingen.

Spitsstrook

Het komt niet vaak voor dat je op je werk volledig vrij bent om te bepalen wat je doet. Meestal is er een manager die de plannen goed- of afkeurt. De tijd die je eraan besteedt, moet namelijk wel iets opleveren. Dat is ook logisch, want geld kun je maar één keer uitgeven. Dat verklaart ook waarom er strakke procedures bestaan om initiatieven, projecten en doelen tegen het licht te houden. Maar hierdoor wordt wel de drempel verhoogd om spontaan iets te doen wat je leuk vindt. Met een hackathon open je een soort spitsstrook, zodat je om de file heen op de snelweg kunt rijden.

Met hackathons maak je gebruik van collectieve intelligentie

Je bent als management nooit slimmer dan de tientallen of zelfs honderden andere mensen die in het bedrijf werken. Met een hackathon maak je gebruik van de collectieve intelligentie, want mensen kunnen zelf kiezen waar ze aan willen werken. Zo zorg je ervoor dat de intrinsieke motivatie, de passie voor het vak en de nieuwsgierigheid van mensen zichtbaar worden.

Wat levert het op?

Tijdens een hackathon werken mensen aan dat ene dingetje dat ze altijd al hadden willen doen, maar waar ze steeds niet aan toekwamen: iets wat nu echt opgelost moet worden. Daarnaast wordt er geëxperimenteerd met nieuwe technologieën en geleerd van vakgenoten die verspreid in de organisatie zitten. Want tijdens een hackathon helpt iedereen elkaar.

Omdat mensen aan het eind van de hackathon presenteren wat ze hebben gedaan, kun je er volledig op vertrouwen dat mensen hun tijd goed besteden. Bovendien: de hackathon hoeft niet meteen iets op te leveren. De inspiratie en motivatie zelf zijn al waardevol genoeg om het te doen.

Hoe organiseer je een hackathon?

Hackathons zijn er in verschillende soorten en maten. Van één werkdag op kantoor tot een volledige ‘hackweek’ op een externe locatie. Om draagvlak te creëren is het de moeite waard dat mensen uit de business de uitdagingen presenteren waarvan zij hopen dat iemand er iets aan kan en wil doen. De techneuten kiezen vervolgens zelf of ze aan een van deze initiatieven willen werken. Lees meer over hoe SpotifyFacebook en Uber dit doen.

Een simpel format voor een succesvolle hackathon is:

  • plan een dag in, nodig mensen uit;
  • zorg voor eten en drinken, muziek en sfeer;
  • bepaal een thema of definieer een business probleem (optioneel);
  • plan een demo;
  • evalueer wat wel en niet goed werkt, en plan de volgende.

Zo simpel is het. En is het alleen iets voor IT'ers? Zeker niet. Iedereen kan meedoen, ongeacht rang, stand of functie. Je hoeft ook niet per se software te maken; een goed idee uitwerken naar een prototype van karton is ook nuttig.

Agile CIO richt zich op het toekomstvast en wendbaar maken van organisaties door de best practices van bedrijven als Spotify, Google, Facebook en Airbnb toe te passen. We organiseerden hackathons bij o.a. Digidentity, Mijndomein en Aegon.