Leading for Growth: The Department, and the Humans Who Built It

The trickiest part of taking over the department wasn't the work. It was the morning I began a meeting as a peer then introduced as the team's new leader. It was important to understand that it could be difficult for my previous co-workers who were now my direct reports. I led with curiosity instead of authority. For the first couple months I stayed in a support role: weekly one-on-ones where each designer showed me work they were proud of and walked me through their tickets and work. I wasn't evaluating them. I took the time to try and learn them.

That time paid off. I built individual roadmaps based on where each person was strong and where they needed a push. I told them straight: if I do my job right, I will teach and challenge you until you run out of problems this company can give you. I wanted them fluent in design and process, but more than that, confident enough to defend their decisions in any room.

I tend to believe that if leadership is done right, it can be almost invisible. In hopes that it would be noticed by what is missing; no roadblocks, no repeat work, no Groundhog Day meetings on the same topic. And of course, a lead that doesn't have to micromanage. That's the environment I try to build, one team at a time: Lyons Consulting Group, Siteworx, Maestro, and eventually VelocityEHS. Each stop building upon the same idea: get everyone working with the same system, routing information through one spot, and deliver once.

I'm not here to say this is revolutionary. I'm sure some form of it is taught or written about. But my leadership comes from years in small agencies, departments with non-existent information flow, and seeing rework forced by a lack of details. I tried to pay attention to where good ideas broke down between the whiteboard and the deliverable, and every fix became part of how I informed the next team.

The speed with which a team adopts a process is very much influenced by the quality of the relationships. I use those 1:1 hangouts and work reviews to guide them through how and where information should be shared, and how that shared spot governs approvals. As for teammates outside UX, that too was built on relationships. Build trust with product managers and guide them to use a single source for requests, just like we usually do with standard scrum. The user stories and acceptance criteria, with real context, give a designer everything they need to own their product (the ask, the constraints, the history), and let them look out for the user not only by solving one ticket, but by understanding what the user needs across the whole product.

That's really what the organization bought them: ownership. Once information stopped being scattered across tools and people, each UXD could run their product like it was actually theirs. No longer waiting on someone else to translate a request, no longer guessing what a stakeholder meant. They had what they needed to lead, in one spot, and the relationships to make sure it stayed that way.

Here is the caveat, or the secret as I see it, that matters more than the process itself: a process exists as something a team can aspire to, but is rarely executed 100% exactly. This approach is simply based on the idea of understanding what you, as the UXD, are solving for, then asking for help from those who know.

Every department sees UX differently, and most have never been told why it matters. So I went on a tour: one deck, adapted for whoever was in the room. Customer Support, Solution Consulting, Onboarding, and eventually VP-level R&D leadership.

I did my homework before every stop: what a team was frustrated about, who was skeptical of change, what they'd already heard and stopped believing. One ally in leadership used to brief me beforehand, who I'd be talking to and what to know about them, so I never walked in blind.

What I didn't do was change the substance for the room's seniority. Same laws, same heuristics, same honest walkthrough of how we built things, for a support team lead and a VP alike. People can tell when you're talking down to them or up to them. I just talked to them, about what UX actually brings to the table.

I give my designers ownership, not tasks. At VelocityEHS, an entire application was theirs: supporting it, extending it, rebuilding pieces from scratch. They ran their own daily meetings and their own one-on-ones with the product managers who brought them strategy and schedule directly, not filtered through me.

If I don't give people ownership, what pride can they take in the hours they spend at work? I teach balance, not life balance, just balance: can you be proud of what you do at a company you spend most of your week at? That means giving people the authority and the grounding to be in a room by themselves, and trusting them to handle it.

We still had our one-on-ones, more hangouts than meetings, and talked through the real challenges. If something uncomfortable was coming, they knew they could call me in. When they did, I'd ask how they wanted me there: on camera, off mute, or just quietly listening in the background. The point was never to take the room back. It was to keep the authority visibly theirs, even with me sitting right there.

The people I built this department with have moved on to new companies, new titles, new cities. I gave them every challenge and lesson I could while still serving the end user at VelocityEHS, until I ran out of challenges to put in front of them. Then it was time for them to learn from other systems, other approaches, other leaders.

Ultimately I think that is the impact of a good mentor. Not the deck I gave a room of VPs, not the design system, not the process diagram. The real measure is whether the people I taught still want to explore, learn, design, create, all the while ensuring they keep their own balance.