Notes

Why Leaving Design and Joining Systems at Subko Gave Me a New Career (That’s Here to Stay)

Read on Substack · 2025-02-25

Full article

Last day as a system designer at Subko Coffee. Not the one I applied for. A made-up role, I’d say. But until I find a better name, I’ll stick to it.

Year One: The Design Limbo

I joined Subko Coffee three years ago as a junior designer. Small print assets, animated bits, reels—if it involved visuals, I was on it. It felt forced. The only thrill? Those random After Effects experiments that produced wild results I’d try to replicate. Press a few buttons, watch a crazy render come out, then try to figure out how it happened and replicate it. A system within a system. That part made sense to me.

This carried on for a year. Way too long, honestly.

Subko was at a stage where everything was growing fast—too fast. Supply chain issues, team inefficiencies, operational gaps. If any team faced a problem, anyone in the company could jump in and offer ideas. No hierarchies, no strict ownership. Just problem-solving, wherever needed.

That’s how I got my shot.

A chance encounter with a problem bigger than design—something operational, something logical. I remember solving something, and I remember how it felt. It clicked. For the first time, I wasn’t just designing for the sake of it—I was applying logic, structure, efficiency. Solving these messes felt more natural than any design brief ever had.

The Role Evolves, and So Do I

At first, solving one problem led to another. Loose ends turned into projects. As Subko’s structure evolved, my work naturally found a place within it. More hierarchy meant clearer roles. More projects meant clearer direction. And with every problem I solved, it became more obvious—this worked for me. The fast-moving, dynamic nature of it all worked for me.

If any weird, messy problem didn’t fit elsewhere, it landed on my plate. But once the title of System Designer was thrown into the mix, those floating problems had a home. Whether or not the title was accurate didn’t matter. It gave me a way to frame the work I was doing, and a way for the team to slot in everything that didn’t fit neatly anywhere else.

Was that the right approach? Maybe, maybe not. What mattered was that I took ownership. The input became more important than the outcome. That sounds selfish, but it wasn’t. It was how I figured out what mattered to me.

Each new puzzle was a step away from the creative block I used to dread. I realized: this was what fueled me—making things work, not just making things look good.

Design Didn’t Reject Me—I Moved On

Here’s the thing: I wasn’t terrible at design (I’d like to think so). I’d already spent two years in other roles before Subko, both junior and senior. I gave it all I had (or at least, all the chances I had in me to give). But it never satisfied me.

As a designer, I could put in 200% effort, but the output was always at the mercy of subjectivity. The feedback loop was unpredictable. Inputs could be great, but the final outcome—whether a design was successful—was often decided by gut instinct, preference, or sheer randomness. There was no way to measure impact in a way that felt concrete. And that never sat right with me.

I realized that if I was going to give my absolute best, I needed a way to actually see and shape the results. So I started moving into planning and execution—not just coming up with ideas but structuring them, implementing them, and tracking what happened next. And that’s when everything clicked.

It was the first time I saw problems and their solutions take actual shape. Measurable shape.

That shift taught me the single greatest lesson of my career: Impact is significantly easier to measure in execution than in strategy.

All the “execution-first” quotes I’d once rolled my eyes at? They suddenly made sense. No matter how sharp or well-researched a strategy was, it meant nothing unless it played out in the real world. I learned that the best planning doesn’t just account for solutions—it accounts for failure points, for the unpredictability of real-world application.

And I made plenty of mistakes.

For a while, I fell into the trap of being the "PPT guy," the "SOP maker guy"—stuck in documentation mode instead of action mode. Luckily, I had the space to correct it. To move from abstract solutions into tangible ones. Once I made that shift, the quality of my mistakes improved. They weren’t careless errors anymore; they were advanced, second-level problems. The kind of mistakes that come from doing something real, not just talking about it.

That’s when I knew.

Looking back, I’m glad I gave design its fair shot. It taught me what I didn’t want, and it showed me that curiosity is transferable. This is what led me to it, and it’s the same curiosity that pushed me toward bigger, more concrete challenges.

So here I am, on my last day as a system designer at Subko, packing up both my lessons and my excitement for what’s next. I’m still not 100% sure what the final name of this role will be—maybe “System Designer” is just a stepping stone. But I’ve realized something crucial: measuring impact, owning the outcome, and shaping real-world solutions is where I thrive.

For now, I’m giving this path a shot. And that feels right.


Connected ideas

These links connect the published piece to working idea notes. The article text above retains its published wording.

Related