Two things that will never work here

When working with organizations on their service delivery capabilities, there are two recurring themes, which are somewhat humorously contradictions.  Many organizations simultaneously have a view that they are unique, while also deciding that they can borrow the work of others and everything will work out fine.  Both of these things are true.

Flow

As someone who has made organizational and technical transformation throughout my career, I’ve often come up against “that will never work here.”  It often manifests itself as “we can’t be more like Netflix because they only serve movies and we run a serious business.”  The fact that Netflix is more highly available to their customers than the “serious business” is never considered.

Recently, working with clients to improve the speed and quality of their delivery, we are often told that “our customers don’t have any tolerance for us releasing often – we run a serious business.”  Having been an architect in Infrastructure Engineering at Salesforce, I’m very familiar with large customer companies being intolerant of continual changes to UI or features.  However, there is more to shipping than simply UI tweaks and features.

In his book, Project to Product, Dr. Mik Kersten describes four different “flow items” that can move through the system and that should be allocated in different proportions based on the needs of the business.  They are:

• Features
• Defects
• Risks
• Debt

They are described more fully in the book, but readers will note that features are only one of the items.  Do teams ever express that they don’t have time to work on technical debt?  Often.  Are there bugs (defects) that need to be fixed?  Always.  Are there improvements that can be made to increase security and reduce risk? 

As can be seen, there is more to be shipped when running a production system with speed and quality than features, so having the capability to ship rapidly and safely can definitely “work here.”

The Spotify model

Saying “that will never work here” only applies to certain aspects of the business.   For others, what has happened at other organizations definitely will work here.  When I am talking with leaders about their organizational structures and I hear words like “squads” or “chapters,” I know the “Spotify model” has been there before me.   There is nothing wrong with the Spotify model.  Or rather, there wasn’t, for Spotify, when it was their model.

Spotify is an agile organization.  As such, they are agile.  Meaning they adjust to the circumstances at hand.  As circumstances change, so does the model.  In truth, there is no such thing as the “Spotify model.”  The model that people classically refer to is a specific point of time in the past for a specific set of circumstances for which the model was a good fit.  If you were to spend time with Spotify today after having read about the model for the first time, you would be very confused that the organization was not a time capsule of a previous time.

Just as the Model-T does not represent all cars, the Spotify model does not represent all organizational structures of Spotify, nor the optimal organizational structure for any organization.

The key is to examine what circumstances the Spotify model was meant to solve for and figure out the circumstances that exist in your organization.  Given the specific culture that already exists in your organization, what are elements you’ve seen in other places that you might apply?  What are things that your organization does well that could be expanded?  What are things in your organization that should be retired, as they were meant to solve for a past set of circumstances that are no longer relevant?  It is only through creativity, collaboration, and experimentation that you can solve for the circumstances you are facing today.  Just like Spotify did.

Also like Spotify, your organization should continue to examine, hypothesize, and adjust for changing circumstances.  Plan on doubling or tripling the size of the engineering team this year?  You’ll need to adjust.  Are your private equity owners planning two or three add-ons to your company?  You will need to adjust.  You will need to be agile.

Make it work here

No two organizations are exactly alike, and no two organizations are so different from one another that every situation is unique.  The DevOps movementhas taught us that speed and quality are essential for high-performing organizations.  Not just to ship features, but to operate the business. 

When operating the business, we can take inspiration from many sources, but ultimately the problems we need to solve are our own.  If we aim to be agile about operating the business, instead of freezing in time a single organizational model, we can create happy, thriving organizations for everyone involved.