Inspire, develop, and guide a winning organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
Understand the unique values and behaviors of a successful organization.
Explore our extensive library of experience reports.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
Weekly discussion around “Deming’s Journey to Profound Knowledge” with author John Willis.
VIRTUAL — Helping leaders succeed and organizations thrive (formerly DevOps Enterprise Summit).
Venue: Fontainebleau — Helping leaders succeed and organizations thrive (formerly DevOps Enterprise Summit).
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Is slowify a real word?
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
March 2, 2021
Traditionally, organizations have been based on hierarchies with decisions made at the top, with detailed direction flowing downward through multiple management layers to the teams.
Traditional enterprise structures organized employees by functional specialty departments, each with their own work intake mechanisms, procedures, and goals. Work was heavily governed by a traditional Project Management Office (PMO) focused on prioritizing the work for temporarily constructed project teams. People would be partially allocated to a variety of projects as determined by their respective managers as they manage overall team capacities.
The traditional workforce would often be heavily outsourced to contracted third parties to reduce the overall IT spend within an enterprise.
As we look to a more modern product operating model, many of these organizational structures require significant changes to fully realize the benefits of being a customer-obsessed, technology-driven enterprise.
Frameworks don’t transforms organizations. Building high performing teams and then enabling them transform organizations. Simplifying the management structures, minimizing control-oriented functions, and investing in growing your talent are critical to achieving this outcome.
Sign up for the IT Revolution Newsletter to read more articles like this one.
When addressing these problems, far too many organizations try to simply adopt an Agile scaling framework without addressing these foundational elements, then they wonder why they aren’t seeing the same improvement results that truly Agile organizations are able to achieve.
Success comes when you have a committed and engaged workforce who believe in the transformation and in growing the skills and practices necessary to be high performing. This can also create a flywheel effect as top talent tends to attract top talent, enabling you to hire more skilled candidates than you may have been able to previously.
As we assessed the fourteen companies interviewed for this series, a few common strategies related to workforce and talent emerged:
Traditionally IT teams have been organized by functional specialties such as front-end teams focused on user interface/user experience, back-end teams developing code, database administrators, testers, support functions, and a variety of non-technical project roles (e.g., project managers, business analysts, process and functional analysts, etc.).
A full-stack product team brings together all the necessary skills into a team that will take full ownership of building and running the product. A suggested target team size is approximately five to ten employees that fulfill all key product roles as outlined below.
Product teams should be empowered to own the product end to end, meaning they will take full ownership of product planning, design, build, delivery, and support throughout the entire life of the product.
The product team members must be 100% dedicated to the product and not partially allocated to multiple projects. Partial allocation creates context switching that is detrimental to a team’s predictability and productivity.
To maintain an innovative critical edge, it is recommended that the product team members be employed engineers (insourced) and not temporary contracted resources (outsourced). This is critical to building a strong product engineering culture within the enterprise. Internal intellectual property will accelerate innovation and speed to market without dependencies on external third parties.
Additionally, the most innovative ideas that will drive your business forward come from motivated individuals who feel ownership and a sense of personal connection to the solutions they create and the problems they solve for their customers. This connection is difficult to attain when the contracted engineer doesn’t have permanent skin the in game.
During the incubation stage of your transformation, explore the product team roles. Find a team or subset of teams to experiment with placing people with relative skill sets into the product roles. Demonstrating success with a smaller, cross-functional product team can generate the momentum needed to scale to other teams.
At a high level, the structure of teams following a product model consists of the following roles:
Empowerment and decentralized decision-making are both foundational to a product team. Traditional hierarchies diminish the team’s ability to fully own and run their product. Product owners have the accountability to ensure the team is building the right solutions for their customers and the team has the accountability to ensure they are building the solutions the right way, ensuring feasibility and user experience are optimized.
Healthy product teams:
Other potential roles that could be considered as valuable in a product operating model include:
The role of the traditional PMO should also pivot and/or significantly diminish in a product-centric operating model. In the companies we assessed, this step typically occurred during the optimize stage of the transformation. Traditionally, the role of the PMO was to direct, control, and standardize project delivery across the enterprise. Heavy governance and oversight are prominent in a traditional PMO, which become anti-patterns in a modern product model. In some examples we examined, the PMO was diminished over time and then eliminated.
An alternative approach could be to transform the PMO to become more focused on enabling continuous improvement for the product-centric operating model. The PMO could become an ambassador for change by evolving its responsibilities to support an Agile and product-centric culture. The PMO team members could each be assigned to a product portfolio as a supportive partner to the product portfolio executive and product manager/owner roles. Reporting product metrics, financials, and key product insights at the product portfolio level can become a gap if there isn’t someone in place to aggregate this data at the portfolio level.
During the scaling stage of the product transformation, the PMO could play a partnership role with Finance to ensure funding for the product teams is enacted, moving the enterprise away from funding capital expenditure projects. The PMO can also assist with reporting value, ROI, cost of products, and cross-product portfolio-level cost and value insights. Additionally, they could modernize compliance requirements by providing product teams awareness to compliance needs and guidance on how to best comply (e.g., risk and compliance, audit requests, evidence, etc.).
However, this shift in PMO responsibilities can’t be taken lightly. In many cases, while the PMO does attempt to shift to these new product-oriented responsibilities, its underlying mindsets and skills haven’t shifted. The end result is that the same bureaucratic control-oriented practices quickly creep back into your product-centric model.
The partnership between technology leaders, business leaders, and Human Resources is critical when designing the product-centric workforce model. A workforce strategy that considers delayering management, insourcing talent, and converting traditional roles to modern product roles should be a collaborative approach between leaders and Human Resources.
Delayering or leaning out the organization is likely to become necessary for a product culture to stick. Delayering strategies tend to begin during the scaling stage and continue through optimization. Multiple layers of management approvals will paralyze a product team’s innovation and speed to market. Product decisions become decentralized from the management layers with product accountability residing with the product manager/owner.
Delayering is necessary initially to flatten the organization, removing multiple middle manager roles. Drive toward a leaner organizational structure with less bureaucracy by reducing management layers. In some of the companies we assessed, delayering reduced management from ten layers to three or four, significantly leaning out middle management.
The manager role changes significantly with an Agile and product transformation, shifting the role from directing the work to servant leadership as product strategy and decision-making become decentralized. Some middle managers will lean into the change, finding a new path for themselves as engineering managers or product managers. Others may opt out as they’ll find the loss of control over their space and team to be frustrating.
Even more common, middle management is most commonly cited across enterprise transformations as the stakeholder group that resists change the most, making it very difficult to drive these changes across the organization. “The frozen middle” is a term that best describes this problem and will be discussed further in the Culture and Leadership section.
Traditional project family roles, such as project managers, business analysts, process analysts, functional analysts, and testers will need to be repurposed into modern product and engineering roles. Much like the delayering approach, role conversion typically begins during the scaling stage as product teams are being formed.
A strategic approach will need to be determined to gracefully transition existing people into new roles and/or hire externally to fulfill the necessary skill sets. In some of the cases we studied, this role conversion was approached through skill assessments and data gathering followed by a “big bang” approach of shifting people into new roles.
This approach can be challenging if people aren’t supported appropriately with proper training and onboarding into their new roles. An organizational structure that supports a product-centric operating model is one that eliminates functional silos, heavy PMO governance, and traditional paperwork-heavy hand-off processes.
Outsourcing is often viewed as a strategy to reduce cost while also shifting responsibility to a third party. At the heart of a product model is empowering autonomous teams to truly own their products. You need your teams to have an owner, not renter, mindset. This is very difficult with outsourced teams.
Focus on growing engineering talent within the enterprise, nurturing an engineering culture. As companies scale the product model, insourcing becomes a great focus as skills are assessed and product teams are formed. The quality of code will inherently improve if engineers have long-lived experience with the product they own.
In-house engineers will have a better understanding of the overall architecture and ecosystems within which their product lives. Teams made up of employees will have experience and expertise in managing the technical debt of a product, they will also have the motivation to build loosely coupled, extensible code and have the ability to proactively fix issues more permanently then a less experienced, temporarily (or shorter-term) contracted developer. The bottom line is that mindset drives outcomes.
Outsourced developers often focus on delivering with a project mindset, focusing on deadlines, cost, scope, and often even specific activities required by the terms of their contract. This tends to stifle innovation. An insourced team of engineers who own a product end-to-end will generally have passion, motivation, and creativity to innovate quality solutions for their customers. Obviously, it isn’t realistic to insource all technical talent in most enterprises. While functional outsourcing should be avoided, staffing some roles on a product team with contractors to scale up the team can be a reasonable strategy as long as the team is still primarily employees committed to the product long-term.
In some of the companies we assessed, the engineering ratio of contractors to employees drastically changed during the scale and optimize stages of the product model implementation. In one enterprise, the IT footprint was over 10,000 people in IT; 70% of them were contractors and 30% were employees. Within one year, this footprint was reduced to approximately 6,000 people. This drastic change was achieved by a concerted effort to remove contractors, which pivoted the ratio to 70% employees and 30% contractors. A few years later they leaned out the organization even further, reducing the overall IT footprint to 3,500 people.
Once the product teams are formed during the scaling stage, they’ll need support to accelerate and optimize their practices. There are a few approaches to accelerating new teams. One approach that has proven to be successful across a variety of enterprises is to establish a Dojo staffed with Agile, product, and technical coaches.
A Dojo is an immersive learning environment where teams are guided toward new ways of working, leveraging Agile, Lean, DevOps, and product-oriented and modern engineering practices. Teams learn by applying new skills on real product work that delivers value frequently throughout their Dojo experience. The Dojo is a safe environment for teams to experiment, fail, learn, and adjust rapidly.
A few activities that are critical to team success as they initially form include:
Some of the key constraints that have been observed related to workforce and talent include:
There are many aspects to the workforce that should be considered when shifting to a product-centric operating model. The critical focus comes down to building small, empowered, autonomous, cross-functional product teams who have full ownership and accountability for their product end to end. Traditional functional specialty roles do not translate to a cross-functional product team. Build the teams with the right skills and roles, then trust and empower them to deliver value continuously.
In the continuing posts in this series, we will explore each of the Seven Domains of Transformation in more detail.
In the full white paper, The Project to Product Transformation, you will find not only the guidance indicators to create, increase, and sustain velocity, but also the negative force learnings that should help you avoid pitfalls in your transformational journey.
Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.
Welcome to the twelfth installment of IT Revolution’s series based on the book Investments…
In today's fast-paced and ever-evolving business landscape, organizations are constantly undergoing transformations to stay…
Holy cow, Enterprise Technology Leadership Summit Europe Virtual is happening next week, and I’m…
Welcome to the eleventh installment of IT Revolution’s series based on the book Investments…