DevOps Maturity Curve

I recently attended a meeting with Tech Leaders from various cloud projects in different stages of maturity.  We started discussing how each of us defines "DevOps", whether we think we adhere to DevOps principles and if we think we are successful with DevOps or not.  While we discussed an interesting pattern emerged:  the more mature (5+ years) projects moved to a development vs. operations model.  In this model the development and operations teams are separated and there is a "hand over" from dev to ops.  The startup projects (< 2 years) seem to adhere to a "pure" DevOps model.  In that model development and operations are one and the same team.  All teams thought they are managing their resources most effectively and are successful with what they are doing.

That got me thinking whether there is a DevOps Maturity Change Pattern.  Here are a few discussion notes:

• Continuous Integration / Deployment:  ... always needs to work from day 1 with 100% automation.  If that does not work you have nothing, don't even bother to do anything else until CI/CD is up and running.
• Code Ownership:  One key DevOps principle, in my opinion, is that each developer is responsible for how his or her code operates.  Does it scale? Can it be monitored? Zero downtime updates? etc.  We discussed that it is essential in the immature stages of a project that the developer receives the pain for his code failing, meaning he will receive the call from the customer Sunday 0100 AM.  Once a project is more mature we discussed a staged problem resolution process (Triage) is more effective.  That does not change the responsibility each developer has but that with organizational size and maturity specialization of tasks can lead to better effectiveness.
• Security and compliance:  We discussed that it is required during the startup phase of a project for developers to have access to production systems.  We also discussed that this is the opposite of security best practices such as separation of duties.  With project maturity all projects introduced special operations teams who could access production systems, production access by development typically was removed for security reasons.  Again this requires a flawless CI/CD process.
• Start small:  most "on prem" software development companies struggle because they have no experience operating their own software.  They focused on the 20% functional development and trusted someone else would figure out the remaining 80% of the overall effort to develop and operate their applications.  Which brings us to:
• Business and Executive responsibilities:  the teams who routed all their alpha, beta and first release customer support requests through their business and executive teams were more successful developing reliable, resilient and mature services than others.  Your service is unavailable in the middle of the night?  Have the customer wake up the person who decided to release prematurely or decided not to fund the effort to develop automation for preventing outages.  It might be more painful for everybody but necessary for educating the Business and Executive Leadership on what it takes to develop cloud services.  And it will help in the long run getting to a reliable and stable service.

What do you think?