For most of my career, my value came from speed. I worked in environments where shipping fast was the norm. If a developer needed a component by the end of the week, you built it, tested it just enough, maybe left a TODO or two, and moved on. That was the job.
I've also worked on design system teams before, but those systems supported small groups of developers. Roughly a dozen or so people. The pace was still quick, and the stakes were lower. If something needed to be hacked together to meet a release, we made it work.
Now I'm contributing to a system that supports thousands of developers across hundreds of teams. The work is more methodical. The expectations are different. There's a stronger focus on stability, clarity, accessibility, and long-term reliability. And I'm realizing that the way I've worked in the past does not fit as well as I thought it might.
I came into this role with the mindset and muscle memory of someone who could work fast. That's where I've found success before. But I'm learning that speed isn't always useful here. In some cases, it's not even valued. That's not a criticism of the team or the system. It's a reflection of the kind of problems we're solving. And that shift in value has taken me by surprise.
Building for Scale Requires a Different Approach
This work is no longer just about whether a component works in one spot or meets the needs of a single team. It is about whether it holds up across a wide range of use cases. It is about how it behaves in unpredictable combinations. It is about whether other teams can trust it, build on it, and not worry that it will change out from under them.
There's more emphasis on testing. Significantly more emphasis on accessibility. More conversation about the long-term impact of small decisions. More investment in writing crystal clear documentation that will still make sense to someone years from now.
I'm not being asked to slow down. No one pulled me aside and told me to pump the brakes (well, not officially). But I can feel it. The things that made me effective in other environments are not as effective here. And that's on me to adjust.
Advice That's Helping Me Adjust
Years ago, my friend and fellow developer James Cori told me something I've never forgotten:
It takes at least six months just to find the bathroom when you start a new job.
Of course, he didn't mean that literally. He meant that you have to take time to understand the landscape. Every team has its own way of working. Its own codebase history. Its own pace and politics. When you come into a new environment, it helps to observe. Learn the culture. Understand the decisions that have already been made. Let your opinions and instincts develop slowly.
I've always valued that advice, and it is helping me now. I didn't show up here with a plan to overhaul anything. I've just been watching. Listening. Trying to understand how this system fits together. And giving myself the time and space to notice what's different about how things work here. And more importantly, giving myself the grace to adjust my approach.
Just Because You Can Go Fast Doesn't Mean You Can Go Slow
There's another lesson I've been thinking about lately. One I learned through music.
When attempting to learn new musical ideas or techniques, going fast often covers up problems. The tempo masks imperfections. But when you slow things down, every detail is exposed. Time feels stretched. Groove becomes harder to hold. You have to listen more. You have to be more intentional.
Miles Davis used to hire young drummers who had incredible speed and technical ability. Then he would make them play ballads. Many of them struggled. They would rush, or feel stiff, or bring the wrong energy. Playing slowly requires restraint and sensitivity. It reveals what is really going on. I've written about how I believe slow is fast, and how this could be applied to other aspects of life.
That same lesson applies to code. When I work quickly, I can sometimes get by on instinct and habit. But slowing down shows me where I'm making assumptions. Where I've skipped context. Where I don't fully understand the problem I'm solving. It's uncomfortable to change pace and face those things. But that's what will help me grow.
I'm Not Abandoning Speed. I'm Learning When to Use It.
I still believe speed has value. There are moments when quick thinking and fast problem solving are exactly what the situation needs. But I'm learning that the ability to slow down, ask questions, and work deliberately is just as important. Maybe more important in this role.
Speed is not the problem. But relying on it as my primary strength no longer serves me here. I'm learning how to change gears. How to recognize when a situation calls for patience. How to contribute to a system that needs to be dependable, not just efficient.
That shift is not something I figured out before I got here. I'm figuring it out while I'm here.
I'm Still Figuring It Out
I've been with my new team for about six weeks now. This is all a new process. I'm still adjusting. I'm still feeling out the edges of where I move too fast. I'm still noticing old habits kick in and trying to replace them with better ones.
But I'm starting to reframe my definition of value. I'm not trying to prove how quickly I can build something. I'm trying to build things that are solid. Things that others can rely on. Things that make the system better for everyone. That shift takes time. But I'm learning that time is part of the investment.