My philosophy
Counterintuitively, for me leadership is mostly about getting out of the way. My goal is to give people the tools, support, and direction they need and then have them get to work. This means that I’m willing to let my people make a real mistake instead of always stepping in to save them. I’d rather someone own a decision and the consequences instead of having me hover over their shoulder and get it ‘right’. It can be hard to give up that control, but I have to trust that I hired the right people and they’re going to do the job well.
There are exceptions of course. I’ll always step in if something will ship that will hurt the user, but I’ll also step in before someone burns political capital they’ll need later. Picking our battles and deliberately choosing when to burn that capital to make the right decisions for our users is a really important part of what we do.
How I structure a team
In my current role I’ve made a deliberate decision to have my team own specific surfaces. For instance, I’ve been the owner of Docusign CLM’s content design for 7+ years. That kind of tenure allows me to own the whole domain and help design the content experience instead of just writing the copy and that deep expertise is where I want all of my team members to get to. It’s my “space to fail” idea applied: long-term ownership only works if people are trusted to make real calls about the content design in their area. One of my content designers owns our AI voice, tone, and content patterns end-to-end. I haven’t always agreed with every call she’s made, but that’s the point. I can give my opinion, but ultimately it’s her decision to own.
The IA role on my team happened a little bit by accident (there was an internal restructuring) but it was an excellent bit of luck. My team had been crying out for some expertise in taxonomy and structural thinking. Of course, it immediately raised new questions, specifically what do we do with this single point of failure. That kind of expertise can’t exist in one person’s head. So this year I’ve been working on making that kind of thinking something any content designer on the team can do by designing new tools and processes. While having deep expertise in an area is important, we have to be agile and able to do lots of different kinds of work. That’s why I’ve had folks on the team train each other in Figma, GitHub, and other tools that make our lives easy-ish.
It’s also important for us to stay on top of our work and be flexible in our processes. A few years ago, the team was working on so many things in so many surfaces and with so many disparate teams that I was missing vital information. There was no way to tell who was overworked, what was in flight, or even what was being built by the various product teams we support; more than once we saw functionally identical features being built in complete siloed isolation. So, in order to get on top of that, I built a Jira-based scrum process from scratch before Design Ops made Jira and Agile the org-wide standard. We were one of the earlier teams on the wider design process because I had built out this process and our feedback helped shape the broader process.
How I make the work legible
One of the eternal problems at Docusign (and generally in the world of content design) is how do you move from saying stuff like “I feel like X” to being able to point to something objective. Brand had published a copy rubric to score content and make sure it met Docusign’s standards, but there was no way to actually check whether we were meeting it. The rubric was sort of just sitting there, ignored in a Confluence page.
The lightbulb moment for me happened when I was arguing with a PM about content and I realized that we were both just arguing about ‘tone’ with nothing to back it up, even though we had this Brand rubric we could be referring back to. And this was a team-wide problem, basically everyone told me stories about hitting a similar wall. So I decided to do something about it.
My response was to build a Figma plugin that scores copy against Brand’s rubric using an LLM. I’m not a coder (in fact, I brought in a member of my team with a computer science background and some previous dev experience to help clean up my messy code and help build new features), but I was able to vibe-code my way to a functional plugin that spits out a numerical ranking.
This has completely changed the way we have these arguments. We’re no longer stuck saying “In my opinion, this reads a bit better”; instead we are able to say “this doesn’t meet our brand standards, but here’s something that does.” That’s a much more powerful place to be arguing from and it’s much harder to dismiss as “just a difference of opinion”.
Before: In my opinion, this reads a bit better
After: This doesn’t meet our brand standards, but here’s something that does
How I develop people
Because I believe in letting people own things fully, I don’t ease new content designers in slowly. After a short ramp-up period where they can get familiar with Docusign, I hand them something small to own right away. This lets them immediately have an actual surface with their name on it. I really believe that ownership tends to compound, even if you start small.
I think that philosophy shows up when I need to make the case for someone’s growth too. One of the strongest content designers I’ve worked with – now sort of the face of Content Design at Docusign – made her promotion case basically effortless on my end. She took the ownership I gave her, jumped in and made an immediate impact which I could point to. Not every promo case is that easy. But giving someone ownership over a domain lets them make a real impact that’s felt org-wide.
What I’m still building towards
I’ve spent my time as a manager leading individual contributors (and, if I’m honest, still doing a lot of IC work myself). The next real stretch for me is managing managers. That will pose different problems with a lot less direct visibility into the work. I don’t think I’ll fully understand the challenges until I’m in them, which is a little uncomfortable to admit. That’s the direction I’m headed though and it feels important to mention rather than minimizing it.
What to see next
If any of this resonates, take a look at the Figma plugin in more detail or how I apply systems thinking to tough problems.