On Managing
|
[SUMMARY]
I was hired at Sapphire as a design manager, but truthfully didn’t really begin “managing” in any meaningful way until I became director. With the Zelis acquisition, increasing team size and product scopes, I went through that very predictable reduction in individual contributor time. However, what surprised me was how much I took to managing an expanding team: the increase in 1:1 coaching; navigating relationships; consuming company and industry knowledge to digest and communicate it to the team; setting some sort of direction for Design. The below case study is broad and perhaps better looked at as an emerging philosophy on management, put in context with examples of how I managed the team at Zelis over the last few years.
|
[ROLE]
Director of Design
Insights & Empowerment, BU
|
[COMPANY]
COMPONENTS OF MANAGEMENT
As a structuring device, I’ll talk about managing along three separate (yet related and reinforcing) categories: the structural chassis of the team, coaching, and building culture.
Chassis
The underlying framework of the team, composed of recurring ceremonies and shared understanding of key, relevant concepts.
Coaching
Intentional, repetitive skill building in craft, soft-skills, and product and industry knowledge.
Culture
Shaping of activities and values that inform how the team behaves as a group and with the broader organization.
SECTION 1
CHASSIS
// PARTS //
01: Team Structures
02: Concept Structures
[01]
TEAM STRUCTURES
The recurring meetings, ceremonies, and discipline artifacts that provide a baseline for how the team operates.
Much like the chassis of a car, any team needs a sturdy, underlying framework to support its core function. This foundation is composed of both team structures and shared concept structures.
Team structures include one of the most fundamental chassis-elements, the recurring meeting. Although this could be thought of as part of the broader, catch-all “Design Ops,” I’m focusing strictly on the people-management element of why you have a given meeting and it’s purpose in providing your team with a reliable rhythm and structure (this feeds into culture-building as well).
The other foundational component of the team's chassis is what can be thought of as concept structures, and are primarily the responsibility of the manager to cultivate and propagate: the discipline related concepts, frameworks, industry knowledge, and shared mental vocabulary that allow the team to operate in sync, at a faster clip. These simplify complicated, intertwined problems so that a team member has context to make better decisions.
Meetings
The recurring meeting: something to dread or reassuring slivers of driftwood to hold onto in the open waters of your calendar? – it can be both! For us, our repeating ceremonies became:
Bi-weekly stand-up ("What are you working on, what are your primary objectives for the week?")
Design Lab ("What are you wanting feedback on from the team? Mocks, decks, prototypes, Design Ops improvements all welcome!")
Product Lab ("What should the rest of the Product Team be aware of you’re working on?")
Member Experience (MX/CX) Office Hours ("What in-progress work do we want our client's feedback on and what research can we learn from them?")
The way we approached recurring team meetings changed a lot over the years, with ones coming and going, purposes of meetings changing, and various teams being included then excluded from a given ceremony.
An individual contributor's week is inevitably going to expand and fill with the needs of their project workloads, so having a core, reliable, intentional set of meetings serves a few purposes:
It creates a sense of unity as a singular team.
Provides visibility into other people’s work-streams and deadlines.
Allows team members to be inspired and provide feedback on other designer’s work.
Gives the manager a chance to disseminate information and set the tone of conversation for the week.
Career and Discipline Standardization Artifacts
Another fundamental team chassis item (which yes, is firmly under Design Ops) involves documenting the role expectations and types of skills pertinent to a designer as they progress in their career. Much can and has been said on skill stacks, skill ladders, whatever you want to call them...the point is these are a helpful chassis element for standardizing what’s expected of someone at a given level and having a jumping off point for conversations on what people do well or want to work on improving. My former co-director and I based a lot of the initial version of these artifacts on the content in Org Design for Design Orgs, so big shout out to Kristin Skinner and Peter Merholz.
The two skill stacks that ended up being the most helpful for career direction were “product mindedness” and “problem solving.” Advancement in craft verticals was just expected, natural progressions that came about as a result of people’s project work. However, spending time on what these concepts were and why they mattered, especially for Product Designers and UXR, helped build team members’ confidence in their decision making and show up to conversations with other teams more informed. It ties into and feeds the concept of “perspective” formulation, that I talk about in some of the other case studies.
In addition to the above examples, I made variations of the skill stacks for UXR and communication design. Skill stacks were primarily used during mid and end year assessments as a way of making those mandatory meetings more meaningful and contextual. In retrospect, I think I could have used these more in bi-weekly 1:1s, but you do run the risk of fealty-to-artifact: the idea that “doing the process item steps” is what matters, as opposed to treating the artifact as a single, potential tool that can help you improve the way a person does their work.
Team Composition
(I’m going to reference the way people are arranged on work inside a company as “team composition,” but if you want to call this “team topology” instead, please, be my guest [I think most people when you talk to them, myself included, only have a vague sense of what topology means, so when discussing the broad concept, I’d err to mutual understanding).
In the case study on the Design Discipline, I talked about the different configurations over the years at Sapphire of product, design, and engineering. The point I want to focus on here isn’t the ideal structure or way we worked with broader cross-functional teams, but a “chassis” structure, which is a colleague or parter you can rely on for stability: a continuous relationship that grows over time. We were very intentional pairing specific product designers and PMs together, which we referred to as “duos” (a play on the “product trio” concept and the reality that myself and product leadership were small enough that we could actually get these relationships to stick).
Both design and product operated with a centralized team, but the duos were an intentional choice to connect people to a structure that was driven by providing customer value. In this case, that was tying them to individual “micro journeys,” or specific tasks a member was trying to complete when they came to the product (eg. “find a new specialist versus” verify a “known piece of information”). Micro journeys were measured by the MX Index, which were connected to business value, most often protecting revenue. By keeping a product designer and product manager together on a micro journey, we were able elevate individual working relationships beyond singular roadmap related projects and move them closer to an outcome-based model. Beyond the product-benefit, this helped form sturdier relationships and gave people more stability.
Project Tracking, the Elusive White Whale
“Towards thee I roll, thou all-destroying but unconquering whale; to the last I grapple with thee; from hell’s heart I stab at thee; for hate’s sake I spit my last breath at thee.”
For the life of me, I couldn’t seem to get any successful project tracking to stick over my years at Sapphire. We cycled through tools: Asana, Trello, Monday, Harvest, Jira, Jira Extensions, Airtable, only to have momentum tumble the moment I took my foot off the pedal of enforcement. That’s really my key lesson: that this notion I had of building the structure out of the tracking tool and doing a few weeks of “hands-on” training in stand ups, was somehow going to create this perpetual engine of activity tracking and capacity management that I could observe with my feet up and hands behind my head.
There was a series of needs with project tracking: my boss wanted to see the overall team capacity and velocity so he could make a better assessment of what we could sign up for work-wise and make sure velocity wasn’t dipping – make sure the roadmap was on track; I wanted to quickly see what activities people were working on and were tracking to key milestones; and then the working teams needed a way of planning their day-to-day. Different people started making different boards in different tools to meet this needs, which I honestly think is okay: the idea that all tracking must be done in one tool is something I’ve never bought into and outside of financial reasons, don’t see the point.
There were periods of tracking that were more productive than others, but it was still scattershot and inconsistent over my time leading the team. Looking back with a lens of honesty, given our size, I should have been more heavily involved in project tracking and made it part of my weekly workload, even with the more senior members of the team. Providing clearer, more consistent awareness around deadlines and expectations around output, is a fairly easy thing to say: making it habitual and institutionalized was the trick I couldn’t master.
In our specific situation, I think the key would have been to ensure that any project tracking:
was low-lift (made sure the tool was simple to populate and we’d paid for the timeline feature [Airtable was realistically the best tool we used, but many others work as well]).
capturing activities as notional (just have them in there backed up from the deadline)
empowered individuals to update and change things as they see fit, but allow a manager to get their eyes on it at least twice a week
[02]
CONCEPT STRUCTURES
Building shared knowledge is the most important aspect of management for increasing your team's velocity.
As mentioned at the start of this case study, another one of the foundational components of a team's chassis is alignment on concept structures: the discipline (design, product, engineering, etc.) related activities, frameworks, industry knowledge, and shared mental vocabulary that allow the team to operate from a place of shared understanding. This is turn allows them to move faster through more complex work.
It is primarily the responsibility of the manager to engage in the work of identifying which concepts the team must learn, reduce it's complexity, and then communicate the content through formal teaching over and over.
Through my time at Sapphire and then Zelis, I worked to simply several key concepts for the team including:
The fundamentals of health insurance policy (especially for the more junior members of the team).
Issues with provider data accuracy.
Emerging product frameworks like Opportunity Solution Trees and Continuous Discovery Habits (more detail on this can be found in this case study).
Key perspectives on search intent, such as "known-item" versus "exploratory" task types (which in turn influenced how we developed most UXR protocols).
The idea of micro-journeys as a classification method for tasks members were attempting to complete in our product (the idea came from my boss, but I worked to break it down, classify member issues in relation to them with a shared framework, and built the CX metrics discipline around them – view the case study).
Our business unit's main product was a provider finder, that embeds into a health plan's online portal. "Find," which as an umbrella term includes search, browse, quick-links, telephonic assistants, and any way a member might find a piece of information they're looking for, is the backbone of the entire member journey. Below is a "mini case study" on how I worked to simply the complexities surrounding "find" as a product concept and help the team center on structural issues with our implementation of it, align on terminology, and work towards ways of continuously improving the experience.
The Importance of Education
I’ve observed this tendency for people to expect others to naturally absorb whatever information they’ve put into the collective company sphere. This obviously is true from a top-down perspective (eg. a people leader crafting a strategy and posting it to an internal wiki page) and even more so between individual contributors on different teams (eg. a product team capturing release notes for a market-facing team). What often happens, to reference Simon Winchester, is that the “natural osmosis” of information never occurs. Singular hand-offs of information take the place of repetitive and contextual education, true knowledge fails to transfer, and every side feels let down by the other.
This isn’t to say that individuals abdicate a responsibility for trying to educate themselves, rather, I’m trying to reinforce the importance of intentional and repetitive teaching, driven by a manager or head of a given team, with an expressed purpose of making your people higher functioning and better at reaching specific outcomes.
I talked about “standardizing team knowledge” above and referenced it in the “Simplifying the Complexities of Find” diagram. Below, you’ll see the parts of a diagram I made attempting to explain and classify key concepts around what it means to “find” information in our product. I shared this with the team in a few meetings, but also placed it in multiple Figma files as the team north starred different concepts: an attempt to formally teach how the parts of “find” work and how the designers could better tease out the larger issues with the experience.
SECTION 2
COACHING
// PARTS //
03: Coaching an Expanding Team
04: Coaching Through Uncertainty
[03]
COACHING AN EXPANDING TEAM
Definitions
Admittedly, there is a bit of overlap with the management concepts of chassis and coaching. In this case study, chassis refers to the underlying structures that make up the foundation of how a team operates over time. These are the activities and artifacts (reoccurring meetings, role definition documents, skill stacks, etc.) that provide stability, definition, and the frame for identity for a team. Coaching refers to an intentional attempt to help someone improve in their craft or work through project-related problems, mostly through active dialogue. This tends to take the form of open ended questions posed to the person receiving coaching and is part of an ongoing series of discussions.
Although coaching can use chassis-based “structures” such as reoccurring meetings to encourage and reinforce it’s delivery, the outcome of coaching is ultimately around fostering a sense of self-reliance and growth in the individual. Similarly, this is where engaging coaching differs from providing feedback:
When I’m talking about delivering feedback, I am specifically referencing the observations I shared with a team member about the quality of their design output, their behaviors on a call, or any other job performance related instance, whether it be something they should consider, improve, or were doing well (tried to balance doing the latter in group settings). Feedback occurred in any of Design or Product Lab sessions, project crits, or 1:1s, and was often reactionary on my part. Coaching, on the other hand, would be more thought out and intentionally tied to larger project or personal goals. It was bi-directional in nature, question based, and intended to lead to exploration over the directness of project-specific feedback.
The Team Expands
From 2018 until around mid 2020, I only managed two direct reports and split leadership of the team with a co-director. Mentorship and coaching was much more straightforward at this time: it was easier to be heavily involved in both direct reports work, be kept up-to-date on any project advancements, and sit in on several of the meetings for the project. This enabled me to be the one driving coaching based off what I saw through direct observation. However, in 2021 I became the single director of the team and we grew in size to a team of nine. Managing and coaching gradually began to become reactionary; often related to a capital I “Important” project needing specific guidance at some juncture. I would hop from project to project and certain people received more coaching based on my limiting scope of observation.
The Introduction of Problem Solving Sessions
To address this limiting scope, I introduced a concept I took from my time at McKinsey, the use of Problem Solving Sessions (PSS). The goal of a Problem Solving Session is to help a working team move through a roadblock or fork in their path. You present to leadership (eg. AP or Partner) the context of the question, the team’s synthesized learnings so far, and the possible paths to take. You are clarifying your thinking by taking this approach and trying to get to some kind of point of view. The output of the PSS should be both increased awareness of the project’s progress for leadership and the return to forward momentum for the working team.
Since the size and scope of the team made it difficult to follow every project in-depth, I introduced the concept of the PSS as way for team members to proactively engage with me when they needed coaching (this didn’t replace the coaching I saw as needed, just allowed for self-governance and ownership of moving through problems). Someone would Slack me when they wanted a PSS, or I would request one when I felt there might be stagnation, and we would put time on the calendar.
For structure (to make the PSS into a “chassis” element), our version of a Problem Solving Session needed to be:
Focused on a singular, tackle-able problem, which was part of a larger work stream.
Presented to me with context on how they got to the problem, what they’re considering, typically in a visual way (eg. Figma file)
Able to be discussed in under an hour
Scheduled ad-hoc
This opened up coaching for the team into something that could be self-governing (used as much or little for a given project), low-stakes (“hey, can we PS this afternoon or a bit?”), and part of the reoccurring DNA of how we operated. It also made it easier for me to dip in and out of all work across the team.
Most PSS centered around project-specific feedback, but I also extended the concept to working through topics like project or people management, as well as how to deal with interpersonal conflicts. Likewise, I also found myself doing PSS with a few PMs that were receptive to the concept.
[04]
[MINI CASE STUDY]
COACHING THROUGH UNCERTAINTY
Helping a product designer navigate the complexities of an undefined project scope with our largest client.
The duration and intensity of coaching varies from project and by person, but one work stream from Q3 2023 to Q1 2024 serves as a good demonstration of how continual, intentional instruction helped a team member move through a particularly convoluted set of problems and emerge as a team SME in multiple aspects of the product, and form one of the first significant non-managerial relationships with a client’s CX team.
Midway through 2023, our largest client (referred to synonymously as an “alpha client” in this case study) communicated to our leadership team a significant dip in tNPS scores across their digital ecosystem. The client’s measurement team pinpointed significantly lower scores for the provider finder portion of their experience, which was the core product our company built and plugged into their portal. The client’s CX team had conducted their own independent member research and formulated a list of pain points, categorized by severity and desired UX improvements. This coincided with Sapphire’s own expanding CX measurement methodology and new approach to continuous improvement and journey-based team groupings. To begin merging efforts, we partnered with key players from the client’s member experience teams and tasked one of the Duos (a paired PM and product designer) to serve as the main representatives as we began adding project definition.
During the initial phase, I helped lead both internal and client teams to:
Parse both groups member feedback and existing metrics, categorizing them against a common problem definition framework
Align the client’s specific prioritized user issues to our already in-flight continuous improvement efforts
Form a tighter working relationship with client teams we historically had ironically not had a close partnership with (CX and data/measurement)
Accept a shared measurement framework for assessing any solutions we implemented as a result of the collaboration
Where to start?
Even after aligning process and measurement models, we still faced the difficulty of narrowing in on a manageable problem space. Both teams observed an abnormally high number of searches coming back with “no results” when a member tried looking for specialists. One of our solution-architects was was able to conduct an analysis that compared results for specialty searches that were leveraging the client’s local data (aka they collected and mapped themselves) and national data (pulled from a mix of other Blue Cross plans).
Honing in on this specific issue: reducing the instances of no results for members trying to find specialists in their home state and focusing specifically on configuration and data related solutions, helped put bounds around the project and make the larger issue of lifting tNPS for the totality of the provider finder experience manageable. This specific problem also perfectly fit with the Duo’s key product area they were tied to (improving the experience for members trying to find a new specialist).
This presented a great opportunity for the team to be connected to outcome driven product work, but even with the whittled down scope, there was still a mountain of unpacking and exploration of how to arrive at a solution that lay ahead of them. That’s where the frequent, intentional coaching came in:
The Figma file she used is also a great visual example of how PSS can operate and help move the work forward. For instance, when she and her product partner hit a problem, “we don’t know why there are so many issues with specialty search...there seem to be so many different breakdowns occurring and we’re unsure of how to untangle it all,” we were able through several sessions of coaching to:
Frame the problem (leveraged existing documentation, talked to internal SMEs, etc.).
Create issue trees based on McKinsey problem solving techniques and Opportunity Solution Trees to get to hypotheses and visually track our thinking.
Clarify the root problems they were facing with any potential product solutions and processes for implementation.
List possible paths forward and assess the pros and cons of each.
Come up with a perspective on which paths forward made the most sense given our resource capacity and level of engagement with the client.
SECTION 3
CULTURE
// PARTS //
05: Cultivating Behavior
[05]
CULTIVATING BEHAVIOR
Moving away from vague statements of intent, to specific actions the team can take.
Culture is one of those subjects that can be as narrow or wide as you’d like; the grand manifestation of Design at the organizational level and how it’s perceived as part of the overall business, or, it could be distilled down to the single, initial, flickering emotion a product designer feels when asked twenty years from now, “what was it like working at that healthcare company; that first job you had out of college?”
For the sake of this case study, I’m not going to get into the design culture within the enterprise (that’s covered somewhat inadvertently in Building the Design Discipline). Rather, in the context of the culture within the Design Team at Sapphire/Zelis over my years as director, I worked to intentionally cultivate specific behaviors:
DLS work is continuous work: In leui of having a dedicated Design Ops team, each product designer had to have a certain level of attachment to monitoring, improving, and sharing with the team the improvements to our design language system.
Show up with a perspective: you don’t have to be “right,” but you need to have done the leg work ahead of time through things like research, reading, or brainstorming with certain frameworks what it is you believe about a problem or solution at a given moment in time. This is crucial because it helps elevate Design from an organizational perceptive and allows you to hold your own in conversations at the product and strategic level. We need to be more comfortable with research and looking at data in all it’s forms.
Make UXR and talking to members less “precious:" This was so crucial – the idea that the act of talking to members was more important most the time than the artifacts you made from it. This was a big distinction – yes, we need to create decks that summarize our findings through research – yes we need to do usability tests to see what’s working or not with different design directions – but first, we all need to feel comfortable launching tests, talking to members, and looking for patterns in what we observe. And you can’t do all that if you feel like doing UXR needs to be perfect.
Getting these behaviors, these elements of our culture, to take hold, often required use of chassis elements. To borrow a framework from McKinsey, the Influence Model can be used as a means to look at different levers I pulled to help these items take:
The general principle behind the Influence Model is that you increase the likelihood of behaviors taking hold in your organization if you “pull” on all four of the levers for a given desired change. You can’t just “role model” what a specific behavior is, you need to also help people understand why you’re trying to change to something, build up skills when necessary, and reinforce the behavior with structures and processes.
Below are specific actions I took to help cultural actions on the Design Team take hold:
What I don’t want to downplay or have get lost in the shuffle of connecting culture to business outcomes is the simple emotional resonance of what “culture” reverberates – when someone asks you “what’s the culture like at the place you work?” That vague, formless, smear of emotion you feel that’s a constellation of memories and events that pervade a general emotion...much in the same way you think of your hometown or college years or any other thing that’s far too large to be a single thing and is the average emotion of that great combination of all it’s moments.
Culture is also a general feeling.
And lastly, something that was just a fun thing we did one time.
