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.\nFlow\nAs someone who has made organizational and technical transformation throughout my career, I\u2019ve often come up against \u201cthat will never work here.\u201d It often manifests itself as \u201cwe can\u2019t be more like Netflix because they only serve movies and we run a serious business.\u201d The fact that Netflix is more highly available to their customers than the \u201cserious business\u201d is never considered.\nRecently, working with clients to improve the speed and quality of their delivery, we are often told that \u201cour customers don\u2019t have any tolerance for us releasing often \u2013 we run a serious business.\u201d Having been an architect in Infrastructure Engineering at Salesforce, I\u2019m 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.\nIn his book, Project to Product, Dr. Mik Kersten describes four different \u201cflow items\u201d that can move through the system and that should be allocated in different proportions based on the needs of the business. They are:\n\nFeatures\nDefects\nRisks\nDebt\n\nThey 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\u2019t 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? \nAs 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 \u201cwork here.\u201d\nThe Spotify model\nSaying \u201cthat will never work here\u201d 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 \u201csquads\u201d or \u201cchapters,\u201d I know the \u201cSpotify model\u201d has been there before me. There is nothing wrong with the Spotify model. Or rather, there wasn\u2019t, for Spotify, when it was their model.\nSpotify 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 \u201cSpotify model.\u201d 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.\nJust 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.\nThe 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\u2019ve 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.\nAlso 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\u2019ll 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.\nMake it work here\nNo 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. \nWhen 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.