Design Manager · HashiCorp Cloud Platform (HashiCorp → IBM)
Design Management Through Change
When someone’s performance and their capability don’t match, something is in the way. Finding out what, before assigning blame and before prescribing a fix, is most of the job.
I was not the team’s first change that year. I was the latest one.
- Team
- 6 designers, plus 4 senior and lead designers for one quarter
- As IC
- April 2024 to January 2025
- As manager
- January 2025 to present
- Backdrop
- IBM acquisition. Announced the month I joined, closed five weeks after I moved into management.
- Inherited
- Several senior managers gone in six months. Minimal handoff.
The actual problem
Not “how do I run this team.” The team had watched several managers leave in six months and had no reason to believe I’d be different, or still be there in a year. Investing in a new manager is a bet, and they’d recently lost that bet more than once.
So nothing I could say was worth much. Reassurance from the fourth manager in a year is just more talking. What was available was mechanism: things that would keep working whether or not I was still there, and that they could change without my permission.
That’s the condition everything below sits inside. Three claims came out of it.
Diagnose before you act
The rest of the job is diagnosis. When someone’s performance and their capability don’t match, something is in the way, and it’s rarely where people are pointing. You only find it if people tell you things.
Leadership wanted to PIP a senior designer.
- The read
- They weren’t pulling their weight.
- What was actually in the way
- The work they were being given.
This was before I formally had the role, during the conversations about me taking it. I asked one question. Were they being given enough challenging work to pull their weight, or were we shutting them down every time they brought a new initiative, and making them look like they weren’t contributing?
The decision changed. Instead of a PIP, the org found them a different manager and a better-fitting context. They now lead a Terraform onboarding initiative, partnering across value engineering, product engineering, product and other designers. I asked the question; a different manager did everything after it. They never joined my team, so there was nothing in it for me.
A designer doubted their own fit, not their effort.
A separate case, same pattern, lower stakes: a designer was hesitant about a new, high-visibility platform initiative. Not reluctant to work, doubtful about fit. This time the wrong read was their own. I named the specific thing they were already good at and where the initiative would need exactly that, which is different from telling someone they’ll be fine. Two months in they were thriving, and the work became the basis for a fast-tracked promotion. Placement mine, performance theirs.
The last research team had failed and nobody had done the post-mortem.
- The read
- We need a research function.
- What was actually in the way
- We’d fund the same failure twice.
I ran it as a design problem. Interviewed people who’d been there longer than me, mapped what had actually gone wrong, identified which collaboration models with EPD and extended partners had held. Those findings became guardrails inside the funding case. I ran it alongside a newly joined designer I had real friction with, and coached them on org norms while the project ran rather than routing around it. That collaboration produced the case.
Sixty days of investigation, about a quarter for leadership to secure reqs, roughly a month from interviews to offers. Four hires: a research manager and three researchers. Investigation and case mine; approval and hiring leadership’s.
Someone on my team had burned their relationships with engineering.
- The read
- Their partners were being difficult.
- What was actually in the way
- That, partly. Their reactivity took longer to become visible.
Early on, it looked like ordinary friction with a couple of partners, nothing more. It took months for the pattern to become undeniable: once it had repeated across enough separate projects, the read changed. The partners weren’t the only variable. The IC needed direct support too.
About a month of consistent coaching followed: reducing reactivity, stepping back before responding, and me taking some of the conflict directly instead of leaving them to absorb it alone. They were also unhappy about not getting high-visibility work, and there wasn’t any to give, which is the harder version of that problem. So rather than manufacturing visibility, we built a plan around a pain point they had identified themselves.
Two things came out of it. A systematic sweep, run with other ICs, surfacing low-hanging usability problems that could be fixed immediately, now used by 100+ designers across the HashiCorp business unit. And a QA agent in Figma, built on IBM Bob, that runs against any file and returns a heuristic evaluation, an accessibility audit and design-system checks, putting the problems that normally surface in development or an audit into the designer’s hands at design time. Also 100+ designers, daily.
They built both. The person nobody wanted to work with built the thing everyone now opens every day.
While this was going on, my manager noted something I was already acting on:
handling challenging personalities on his team and providing coaching to them on how to handle situations in more productive ways.
I had already started. That's what the middle of it looked like from the outside, and the review was right that it was unfinished.
Build the mechanism, not the persona
A working agreement
One page. Culture, values, how we show up for each other. Editable by anyone on the team without asking me. Its central provision is that accountability is peer-to-peer, not manager-enforced. The team holds each other to it, not me.
Making it editable wasn’t a gesture. A team that has lost three managers can’t keep its culture in a manager. If the document lives on my authority it leaves when I do, and they had every reason to plan for that.
What proved it It was also the test. Two designers wrote their own versions, we worked through the differences together, and adopted what came out of it. A culture document nobody edits is one nobody believed in.
The ceremonies, restarted
Anniversaries. Birthdays. Small things the team used to do that got lost in the churn, because they had quietly stopped being anybody’s job. Easy to dismiss in a case study. The reason it isn’t nothing is that noticing what had stopped was the work. Nobody asked, and nobody would have.
A retro framework for EPD
Guidelines for running retros with engineering, product and design together, plus a quarterly path for findings to reach leadership. Retros that terminate in a document nobody reads are the standard failure. The escalation path is the design decision, and it’s what makes raising a problem worth the effort.
A measurement practice for HCP
PostHog had been onboarded with nothing wired to it, a tool with no practice around it. Every project now defines three to five hypotheses and states how the answers would change the team’s decisions. That second half is what separates measurement from instrumentation theater. I wrote the documentation and tutorials so it wouldn’t route through me. Adopted by every IC designer across HCP, not just my team, taking coverage from two or three ad-hoc tracked features to double digits, on a 3/6/12-month review cadence.
An AI sharing series In progress
Everyone is adopting AI in individually invented ways, so nothing reproduces. I didn’t start with standards, I started a corpus. People present real problems and how they’re using AI on them, recorded and transcribed. Patterns get extracted from practice once there’s enough of it. Gaining traction; no outcome to claim yet.
None of this was about expecting people to trust me simply because I was new. Instead, it was about building confidence in the process. My goal wasn’t to have people trust me personally from the start, but to create a transparent, consistent process they could trust, allowing credibility to develop naturally over time.
Own the limits
What I couldn’t cover
The working agreement governs how we treat each other. It has no jurisdiction over what the company decides.
I had to tell an intern that IBM’s post-acquisition policy changes eliminated their full-time offer. Nothing about it was a performance call, on their part or mine, which made it harder to deliver, not easier. None of the mechanisms above reached that conversation. The agreement didn’t cover it. The escalation path exists to send problems up to people who can fund solutions, and this one came from up there, a policy decision, not a local one. There’s no version of the delegation thesis that makes it someone else’s to carry.
It’s the hardest thing I’ve done in this role, and it’s the honest limit of everything above. I could design how this team worked. I could not design what happened to them.
Did it work
Nobody left
Across the acquisition, the integration, and the manager churn that preceded me, there were no voluntary departures and no involuntary ones from the six-person team.
Two promotions
On a six-person team, during the same period.
Somebody else’s draft
Two designers rewrote parts of the working agreement themselves. What the team adopted wasn’t the version I’d have written alone.
a steadying force for those designers navigating the platform changes, as well as a trusted advisor for those working in other areas.
My manager’s written performance review
What I’d do differently
The conflict-designer situation is the one I keep coming back to, not because I read it wrong, but because of how long it took to become clearly a pattern.
What I’d do differently now: insert myself into a conflict like that as soon as it starts, and talk about it directly, rather than wait for the pattern to become undeniable first. Once I actually stepped in, the fix took about a month. That was available from the start.
Impact
Every outcome here is split into what was mine and what wasn’t. “None” means nothing was claimed on that side.
| Outcome | Mine | Not mine |
|---|---|---|
| Zero departures from the team, voluntary or involuntary, across the acquisition | The conditions | Their choice to stay |
| Two promotions on a six-person team | Placement, and the case for one of them | The performance |
| Working agreement co-authored and adopted by the team | The document and its accountability clause | Two designers’ revisions, and the team’s decision to adopt them |
| PIP averted; designer now leads a Terraform onboarding initiative | The question that reframed it | The turnaround, run by another manager and their own work |
| Research function funded, 4 hires (1 manager, 3 researchers) | 60-day investigation and the case | Approval and hiring |
| Usability sweep, 100+ designers across the HashiCorp business unit | Conditions and coaching | They built it |
| QA agent in Figma on IBM Bob, 100+ designers, daily | Conditions and coaching | They built it |
| Measurement practice adopted by every IC designer on HCP | Practice, documentation, enablement | Instrumentation and adoption |
| Tracking coverage: two or three ad-hoc features to double digits | None | Team |
| Ceremonies restarted; EPD retro framework with quarterly escalation | Both | None |
| AI sharing series | In flight | None |