McKinsey 7-S framework for design leadership

I interviewed my team members. These long and detailed sessions gave me a thorough understanding of the team and the organization’s UX maturity. I already recognized patterns, issues, and opportunities. Most importantly, each team member shared suggestions on how to proceed.

I had gathered plenty of signals yet to be processed and analyzed. There was a lurking understanding of something not yet uncovered – like gaze detection¹, people recognize being stared at before they can name what they are sensing.

I turned to McKinsey’s 7-S framework to give the signals structure.

McKinsey’s 7-S model² has seven elements: Strategy, Structure, Systems, Shared Values, Style, Staff, and Skills.

The seven elements divide into two groups:

• Strategy, Structure, and Systems are the hard S’s – tangible, directly manageable, and the ones a design executive can reshape with formal authority.
• Style, Staff, Skills, and Shared Values are the soft S’s – slower to shift, shaped more by culture, identity, and relationships than by decisions alone.

My leadership style is mine to shape. Staff, Skills, and Shared Values are managed by team leads and by the team itself – I influence them, but I do not own them. Knowing which S’s sit in your direct control and which require influence rather than authority changes how you approach each dimension.

Initially, it was a journaling exercise. The structure made it quick to describe what was working, what was unclear, and where I needed to act. Similar to the Leadership Roots exercise I had used to examine how past influences shaped my leadership style.

Strategy

How will the team match with the organization’s strategy? How should the team evolve to support the organization in competition?

Until then, the UX design team had undergone multiple development cycles, mainly directed by higher management. The organization had a solid customer-centric business strategy, which was communicated and executed. The UX team existed because of it. Still, the connection was vague. We had a sense of who we were and what we did, but it lacked clarity and was not consistently communicated. That was an important realization – I needed to create and communicate our story.

The broader problem was visibility. The UX team was so different from the surrounding product development machine that the connection between what we did and what the organization was trying to achieve was invisible to most stakeholders. Strategy in the 7-S sense means being able to explain, consistently, how your team’s work contributes to the organization’s competitive advantage. We could not do that yet.

Structure

What is the management structure for the team? Who has authority, and who is responsible for what?

At that time, the team was tiny compared to the surrounding product development organization. The management structure was clear – I had the authority to make most decisions, confirmed by my manager. I planned and agreed on projects in collaboration with peers from product development. My reach and capacity were limited as I was managing a growing team. I had become a bottleneck. We needed to redesign leadership and management systems.

McKinsey’s spans and layers model adds a useful lens here. Spans of control – how many direct reports a manager holds – and the number of management layers above and below determine how quickly decisions move and where accountability sits. In large organizational structures, these dimensions are rarely yours to formally redesign. I have approximately four management layers above me, and I now have more than fifteen direct reports – a span wider than most frameworks recommend.

What I could redesign was how we ran within that structure. I started by virtually slicing the design function into three sections: UX research, UX design, and UI design – each with its own focus area, prioritization logic, and accountability. As the team grew and product complexity increased, that became four: UX research, product-oriented UX design, platform-oriented UX design, and Design System and UI design. The formal org chart did not change. But from a work and decision-making perspective, the function became navigable – narrow spans operating inside a formally wide one.

Resolving design decision authority required a different approach. I defined three tiers of responsibility within the function.

Design System and UI designers hold authority over brand representation and the unified design system. They direct how design system components are used to represent brand values and maintain consistency across all digital channels. Escalations come to me.

Platform-oriented UX designers hold authority over the design grammar of specific channels – mobile, internet banking, website, internal tools. They direct how flows and patterns work within each channel to keep the experience familiar and consistent. Escalations go to the channel’s product owner.

Product-oriented UX designers hold full authority over design flows and the business logic of their interfaces. They design customer journeys within platform templates using existing assets to reduce friction and enable business outcomes. Escalations go to the product owner.

If an escalation remains unresolved, I step in as the design executive accountable for overall design consistency and digital brand representation. Decisions involving product or channel strategy go to the respective product owner or CPO.

One gap remains: everyday team member management. The 1:1s, performance conversations, and skill development for embedded designers still lack a clear authority. The virtual slicing solved design decision authority. It has not yet solved the people layer.

Systems

How do you manage your team’s work? What are standards? What is input-process-output?

With several layers of management and structured processes, the UX team’s input was scattered and had a relatively low impact. A clear operating model for the UX team was the missing foundation. The only way forward was to integrate the UX team into product development. This transformation had many steps, including setting up project management, prioritizing protocols, and creating a business model for the UX team’s processes. This became one of three key catalysts for our UX maturity.

The most recent layer has been measurement. Each virtual section now has its own metrics – UX researchers, product-oriented UX designers, platform-oriented UX designers, and Design System and UI designers each track different outcomes. What began as a coordination mechanism has become something more: when a team member can point to what their work produces and how it is measured, the identity shift from independent creative to business contributor becomes concrete rather than aspirational. Measurement turned out to be a change management tool.

Style

What’s my instinctual leadership style? How does it serve the team and organization?

My leadership styles were democratic and visionary, which helped me pull the team together and nurture our culture. Team members felt special and empowered. The cost was coming across as indecisive. We ran rounds of discussions – I facilitated, gave everyone space to voice ideas, concerns, and half-formed options. I knew where we needed to move. Closing the discussion and making that call explicit was a skill I had not yet developed.

I had not yet read L. David Marquet³ and his distinction between blue work – thinking, planning, deciding – and red work – executing. What I was missing was making the transition visible: stating clearly when the thinking phase was done and the decision had been made. I still make space for discussion now. The difference is that I make it explicit when the space closes.

This mattered most when the Systems changes came. Integrating into product development processes required the team to work in ways that felt foreign. A more directive style would have moved faster but risked losing the team’s belief in the change. Democratic leadership was slower, but the team owned the transition rather than enduring it.

Skills

What skills and capabilities are in the team and organization? How does it match market trends and the organization’s future needs?

The initial team’s skills and seniority were similar, with several exceptions. The team needed more specialized expertise and capable seniors who could mentor others. I needed to start planning skills acquisitions.

The Systems change exposed a gap I had not anticipated. Integrating into product development required the team to estimate work, plan in sprints, and track time in project management tools. These are operational skills. The team had never needed them before. Building them took longer than building the system that required them.

My democratic leadership style was working against me here. The team needed direction toward specific new skills, and I was facilitating instead of pointing. I had to guide team members explicitly toward future needs and lobby management to create the conditions for that development.

Staff

Who are the people in your team? How do they support each other within and outside of the team? How diverse is the team?

The team was growing, and we had many new members. I had plenty of exposure to people interested in joining our team. This gave me a good overview and a benchmark for people’s assumptions, expectations, and levels. At that time, my team only had one role and one level. I needed to update my team’s setup in HR to enable specialization and maturity within the organization.

The transition revealed a split that grew more visible over time. Designers who joined after the Systems changes had been established took project management and product team integration as given – it was simply how the role worked. For longer-tenured members, the same changes required a fundamental shift in professional identity. The work had not changed. The context, rhythm, and accountability had.

Shared values

What is your organization aiming to achieve? How do you make your team believe, support, and behave according to your values?

The UX team is customer-centric. We represent the customer’s voice in product development. Customer-centricity has limits, though, if it is only understood and owned by UX team members. The team’s shared values make the broader commitment explicit:

We educate and involve colleagues in our everyday work. We store, share, and present gathered customer understanding and insights. Our design decisions are based on evidence gathered from customer research. We share ownership and responsibility of product design with the dedicated product team. We experiment and keep our practices evolving. We focus on delivering customer-centric products with the support of teams and the organization.

The shift from those words to lived practice has been slow. The most visible sign that it is happening: the team has become more pragmatic. Experimentation still happens, but in intentional, time-bounded slots rather than as an ongoing mode. Delivery rate has grown. Limiting design variability through the design system has moved the creative energy from component-level decisions to flow and interaction level – how to make a journey effective with existing assets, and when the case is clear, how to improve the underlying component or pattern. That is problem solving.

Working through the seven dimensions gave me something cleaner than a plan: a map that showed where the team was, where authority was unclear, and where identity was falling behind new ways of working. Some of those gaps are closed. Others are still open.

For what came next – understanding the organizational rules that shape every gap the 7-S reveals – I had to learn how the game was played.

Updated July 2026 – substantially expanded with hard/soft S distinction, three-tier design authority model, chain reaction between S’s, and updated Shared Values section.