Sovren · Design leadership · 2022 to now

Twelve people across six functions, and I still held a design territory myself.

I was one of Sovren’s first four employees. I led the design systems and the user experience, and I ran the support and moderation teams that lived with the result.

Team12 direct reports: three product designers, plus customer success, marketing, moderation, trust and safety, and compliance
Hiring5 designers hired out of more than 40 interviews. I kept three
DecidesScope, requirements, engineering grey areas, and QA sign-off before release
ReachSeven products on five platforms, and the product direction five PMs worked against
01 · How I ran the design team

Standing territory, and a review of direction.

Four designers, me included, covered seven products. That does not divide by project, so it did not divide by project. Each designer held a standing area and everything inside it, and one of the four areas was mine.

What they did not own is the direction. I set it, and I reviewed against it before build. The limit was never what they could handle: priorities moved, and design moved with them. So I held the part that could stay fixed, and the rest was theirs.

Social · Pay Triton Cloud Website · Email Ads · Studio · Shop Developers are not consumers Launch surfaces Advertiser acquisition Direction & vision Mine 7 products · 4 designers Standing territory, not tickets
Standing areas, not tickets. Ownership was assigned by area and did not move week to week, which is what let four designers cover seven products. The overlaps are where two areas had to agree with each other.

I partnered with product and engineering by prototyping in Claude Code, driving PRD decisions and finessing scope before a design file existed. Then the prototype went to engineering with two questions. Where am I overdesigning, or adding something that costs you downstream? And what does the flow feel like? Only after both did anything move into an official file.

Review ran in three layers after that. A daily stand-up for pulse. A protected weekly project review, protected because it kept a shifting roadmap from becoming shifting work. And working sessions called against whatever was riskiest that week, where engineers, product, marketing and executives ended up in the same room.

I led the investor presentation and the investor site, and presented both to the CEO, board and executive team.

02 · Nine non-design reports and the support loop

I owned the design, and the team that lived with it.

Three of my twelve reports were designers. The other nine ran customer success, marketing, moderation, trust and safety, and compliance. Moderation and trust and safety set platform policy and kept the platform safe to use.

Day to day that was the knowledge base, the tech support flows and cutting the time those flows took with AI tooling, improving the design where support volume said it needed it, and partnering with product to keep it that way.

It closed a loop most design orgs never close. A design usually leaves the designer, goes to product, and whoever drew it never meets the result. Mine came back as tickets.

Lounges are the clearest case. Messages sent inside a lounge stayed inside it, which was deliberate: we had a reason to keep that conversation out of chat. What it did was bury them, because nobody goes looking inside a lounge for a message. It reached me through my own support and community team rather than through a research cycle, and the fix was to store lounge messages in chat as well. The separation had a purpose. It did not land, and the people who absorbed that reported to me. That is an unusual way to run design, and I would take it again.

03 · Two hires: the lead, and the one I let go

One became the lead. One I let go. I hired both the same way.

I hired five designers out of more than forty interviews, without a scorecard or a levelling doc. I kept three. These two are the ones I learned from.

The one who became the lead. He came in junior. He took very little direction and landed what was needed about eight times in ten, and the other two times he took the coaching and did it again, which is what made the eight repeatable. Communication was not a strength when he arrived and it became one. The hire I can take credit for is the judgment that it would. The rest was his.

The one I let go. Real vision, working remote, and about half the time what came back beat the brief. The other half missed real deadlines, and that is still not what ended it. When something slipped I did not hear it from them, I found out. Remote made that worse, but remote was not the cause: we had no route for bad news that did not depend on them volunteering it.

They bent the requirements routinely too, which is what made the call hard. Somebody whose instincts are wrong is an easy decision. It did not end quickly either: working sessions, written recommendations, a PIP, and a long stretch of trying to make it work. Then I ended it, and I lost someone talented.

Both outcomes ran through the same gap. I hired on instinct, and I waited on progress instead of checking in on it, so I found out how someone was doing at roughly the speed they chose to tell me. The fix sits upstream of both: more time one to one, and more often. With the one I lost, that is also where the career conversation belonged, aiming them at the part they were genuinely good at, which was arguing with the brief and winning.

04 · The onboarding I drew, then deleted

I designed a four-step onboarding, and then we deleted it.

Email or phone, verify, set up your profile, pick your interest tags. Four steps, each one defensible in review, and I drew them.

In use it failed three ways. The step count put a wall between a new user and the feed, which is the one thing that might have convinced them to stay. The combined sign-up and log-in screen was worse than long: returning users could not tell which mode they were in and created new accounts on top of their old ones, which quietly polluted identity across the platform. And the interest tags, the step we thought would power personalization, got tapped through to reach the app, so the data they produced was not worth the screen it cost.

So the doors got split, the middle came out entirely, the profile arrived prefilled with editing optional, and tags left the flow and got inferred from what people actually watched and followed. Duplicate-account complaints in the support queue dropped and install to feed got shorter. I never instrumented either one properly, so I can give you the direction and not the size of it, which is its own lesson.

Every step had passed review, including mine. That is the part worth keeping: the process I ran approved all four of them, and the thing that caught it was use.

05 · Consolidating five different apps

I did not choose this one. I delivered it anyway.

Five consumer apps that read as five different companies. Same business, same accounts, and nothing about opening one of them told you that you had used another. The decision to consolidate the brand came from above me.

The social mobile app had grown fast. When I audited what I inherited, I found eleven different search bars, five heights, five corner radii, and a shared component that already existed being used in exactly two of them. Not eleven searches. Eleven drawings of the same control.

What I inherited 11 implementations · 2 on system Global Search Search h40 · r12 · i18 Discover tab Search h40 · r10 · i16 Messages Search h36 · r10 · i16 Lounge members Search h38 · r10 · i16 Close Friends Search h40 · r12 · i18 Share sheet Search h40 · r20 · i16 User picker Search h40 · r12 · i18 GIF picker Search h38 · r8 · outlined Add moderator Search h38 · r10 · no icon Shop home Search h38 · r20 · 2nd theme Shop search Search h38 · r20 · 2nd theme What replaced them One component Search h44 · r22 · i18 5 heights · 5 radii · 4 icon sizes · 4 clear sizes · 3 placeholder tokens · 0 focus states
Eleven drawings of the same control. Measured from the build, not estimated: five container heights, five corner radii, four icon sizes, and three different placeholder color tokens. Two of the eleven used the shared component that already existed. None of the eleven had a focus, loading or error state.

Then it moved under itself twice. Consolidating the brand meant the design systems had to follow, and partway through the company rebranded outright, which moved a second system again. No runway: every product kept shipping the whole time.

What came out is one shared foundation instead of five apps pulling in five directions. Each product keeps the components its users need, and Triton Cloud keeps its own because it serves developers rather than consumers and should not pretend otherwise.

It was expensive and it was unpopular. Neither the engineers nor my own designers wanted to do it, and I could not fall back on the argument that it was my call, because it was not. I had to carry a decision I had not made to people who reported to me, without pretending I agreed with how we got there and without undercutting it. We delivered it.

What it bought was speed: engineers ship new screens against tokens and components that already exist instead of drawing them again. The brand consistency was never finished. It is more cohesive than it was.

06 · Turning the Triton acquisition into a product

Sovren bought Triton’s technology in 2024. I turned it into something people can buy.

Triton came to us as a repo of APIs. The platform could already make a machine, but nothing existed that a customer could use to ask it to. I set the pricing, designed the console and its design system, and shipped the first build with one of our engineers.

Today it’s Triton Cloud, rented at tritoncloud.io or run on a customer’s own racks. One on‑prem client has paid $600K+ for it. The full case.

07 · Design systems: what held, what was rebuilt

The foundation held. Everything above it was supposed to move.

Type, color and spacing have not changed since we set them. Every component standing on them has been rebuilt more than once, as the design language moved and as the industry did: tighter interfaces, shorter flows, patterns that were not obvious three years ago.

That split is the part I would defend. A design system earns its keep by being two things at once, a layer that is expensive to change and a layer that is cheap to change, and most of the work is deciding which is which. Put a value in the wrong one and you either freeze a product that needs to move or you re-litigate a hex code every quarter.

I still run the design systems, for the engineers and for the design team. I did not hand them off. I maintain them.