March 2, 2021

Workforce and Talent: The Seven Domains of Transformation

By IT Revolution

Why Is Workforce and Culture Important?

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.

What Is Workforce and Culture?

As we assessed the fourteen companies interviewed for this series, a few common strategies related to workforce and talent emerged:

Establish modern product roles and team structures.
Upskill teams through immersive learning environments (Dojos), growth mindsets, and by establishing a learning culture.
Focus on employee insourcing (versus outsourcing to third-party contractors).
Drive toward a lean organizational structure by reducing management layers and non-technical roles.
Break down or pivot the role of the traditional Project Management Office (PMO).

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.

Team Structures and Roles

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:

Product Owner/Manager: The person responsible for discovering what is valuable, usable, and feasible for a product. The product owner owns the product vision, understands the customer needs, and drives prioritization and decision-making around the product requirements. The product owner ensures the team is building the right things. This role is often from a business organization, but may sometimes exist within the technology organization and are often referred to as technical product owners. The technical product owner is a more technical role focused on platform or IT-for-IT products. Product owners who originate or reside in the business are more focused on how functionality should be delivered for a customer-facing product.
Designer: The role responsible for the usability of the product. With a more front-end, customer-facing product, this would typically be a customer experience (CX) designer, but it may be a more systems/technology architect for a back-end product or platform.
Engineers: These are the team members responsible for the feasibility of the product; they ensure the right products are built the right way. The engineers are intended to be organized full stack and full life cycle. This means they have the technology skills needed across the front-end and back-end components of what they are building. They also have the skills needed to drive the planning and delivery across the entire value stream, including analysis, design, engineering, QA, automation, and other skills needed for the product.

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.

Sign up for the IT Revolution Newsletter to read more articles like this one.

Healthy product teams:

Are passionate about the problems they are solving
Spend time on iterative research and prototyping
Focus on roadmaps around customer challenges, not features
Commit everyone to solve customer problems
See a release as a beginning, not the end
Celebrate learning, even from failures
Understand the competitor space
See technology as a tool only and are focused on the outcome a technology can help create, not the technology itself
Constantly renew their worldview and have a growth mindset
See the product as part of a bigger customer journey

Other potential roles that could be considered as valuable in a product operating model include:

Value Stream Architect: The goal of this role is to accelerate the delivery of value across the value stream and work with the product owner on product priorities. The value stream architect assesses value across the value stream, invests in reducing technical debt and building new features, and assesses risk, dependencies, and redundancies across teams within the value stream. Ignoring technical debt will have an impact on speed, quality, and happiness measures. This role is typically aligned to the product portfolio, working holistically across the value stream of products within a portfolio.
Scrum Master or Agile Team Lead: Acts as a servant leader to the team, protecting them from distractions and blockers. The scrum master wears multiple hats, including teacher, coach, mentor, facilitator, and motivator. The primary focus of the scrum master is supporting the team’s continuous improvement needs. One myth that should be dispelled about this role is that it is a meeting facilitator role. If the scrum master is focused only on facilitation, then the most important aspects of the role are being missed.
Enterprise Product Coach: Provides knowledge, experience, and guidance to lead teams throughout the transformation. Moving to a product-centric model is likely new for everyone involved, so having a team of experienced coaches who can help people through the transformation is critical to success. Teams are naturally delivery-focused due to learned behaviors from a traditional project model. Project-minded teams are accustomed to delivering all planned requirements without scrutiny or exploring customer needs. These teams take orders and execute them without full empowerment to design solutions that directly solve customer problems. In a product-centric model, teams need to learn how to manage products through continuous product discovery and delivery. Product discovery is often an area where coaches upskill product teams. Shifting their focus to customers versus project deadlines, milestones, and deliverables requires coaching guidance to learn how to fully incorporate discovery and delivery practices into routines. Enterprises will often enlist third-party consultant firms to define and implement the transformation, but it’s the internal team of coaches who drive the day-to-day change within each portfolio. The Dojo (which is further explained in the DevOps Enterprise Forum paper Getting Started with Dojos) is a recommended coaching environment that enables safe experimentation, learning, and acceleration through change.

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.

How Are Enterprises Achieving Success?

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 Flattening the Organization

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.

Sign up for the IT Revolution Newsletter to read more articles like this one.

Conversion or Elimination of Traditional Functional Roles

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.

Insourcing Talent

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.

Upskill Teams

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:

Product Definition: establishing a shared understanding and team alignment to what the product is; why it exists; the business value of the product; the life cycle vision for the product; who the product serves; the product community map depicting stakeholders, customers, and key dependency partners; the product’s problem space; and the product objectives and success measures. (See our previous post of product taxonomy.)
Team Working Agreement: establishing team norms and agreements about how the team will work together (e.g., tools, communication practices, routines, the definition of ready and done, values, backlog practices, etc.).
Product Discovery: establish an approach to quickly test product ideas against business, technology, and user experience to gain a holistic view of an idea, de-risking the idea and gaining immediate customer feedback through hypothesis testing and prototyping. Assume ideas are wrong until proven otherwise. Discovery helps the team determine the right products to build instead of building unnecessary and superfluous products. In a traditional project culture, we assume that our big ideas are correct and move them directly into a project for execution and delivery. Building without discovery is an expensive and slow way to learn that our ideas are wrong or don’t meet the customers’ needs.
• Foundational Workshops: establish Agile, product-oriented, and DevOps foundational training or workshops to ensure foundational mindsets are established consistently across the team. The team anchors to a mindset before practices or frameworks. This enables teams to safely experiment with frameworks to establish team optimization.

Constraints That Need to Be Overcome

Some of the key constraints that have been observed related to workforce and talent include:

Functional outsourcing: This leads to a product team structure with an imbalance of employed engineers versus contracted third-party engineers, which puts innovation and competitive edge at risk. Focus on the outcomes you want to achieve as an enterprise and fuel those outcomes with insourced engineering talent. Invest in the company’s innovation and future by growing an in-house engineering culture.
Functional siloing: Another common failure for transformations is when teams operate disparately and have individual goals. In this scenario, the teams aren’t dedicated and persistent. Employees often get conflicting directions from their functional managers and their product owners. To combat this, move to full-stack those that are truly organized around products and not leaders.
PMO-driven transformation: Earlier we stated that frameworks don’t transform organizations; building high performing teams and then enabling them transforms organizations. Typically, when the PMO is in the driver’s seat and is asked by their C-level leader to transform the organization to Agile, they are essentially being asked to disrupt themselves, which generally isn’t a recipe for success. The outcome tends to be a scaling framework layered on top of a project-centric organization. This minimizes the amount of real change in the organization and is incremental at best. It can even negatively affect team performance, as the team is now being asked to deliver in an Agile model while still being in a broader operating model and organizational structure oriented around waterfall project models.
Inadequate training: When people have been repurposed into new roles and haven’t been trained accordingly, it sets them up for failure. Support the teams by nurturing a learning culture. This can be achieved by providing continuous learning opportunities through formalized training and immersive learning experiences through environments such as the Dojo. Engage or establish an internal coaching team who can help accelerate upskilling product teams in product-oriented, Lean, Agile, and DevOps models.

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.

- About The Authors

IT Revolution

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.

1 Comment

zameen Jun 14, 2022 7:07 am

You said it right. What I believe is that if you have a good environment inside your company you will get success. The efficiency of your workforce depends on your own company internal culture. Like I have built it for my own real estate company. A good teamwork is also very important part of all this circle.

Reply

with Dominica DeGrandis

with Matthew Skelton & Manuel Pais

October 23, 2024

February 26, 2025

June 4, 2025

By Gene Kim

By Dr. André Martin

Workforce and Talent: The Seven Domains of Transformation

Why Is Workforce and Culture Important?