Decisions. Decisions. Decisions.

Published about 1 month ago

A few years ago, I joined a fast-moving startup with a backend setup that made day-to-day work really hard. We couldn’t run the server locally, and every small change had to go through staging—adding a 5-minute delay to even the tiniest update. It slowed everyone down.

The root issue wasn’t just the code—it was the lack of clear technical direction. Teams were using different tools and practices, and without alignment, we struggled to build and scale together.

At first, I voiced my concerns pretty directly. I wanted fast change and pushed hard. But that approach didn’t work. I realized that driving technical change isn’t just about being right—it’s about how you show up and how you make others feel.

Over time, I adjusted. I started speaking to teammates one-on-one, listening to their challenges, and building consensus. Eventually, we agreed on using a shared framework. We broke up parts of the monolith, moved to microservices, and finally had the tools to test and iterate properly.

Looking back, here’s what I really learned:

1. Be kind.

Even if you're right, if you're not kind, you hit someone's ego. And when that happens, you're no longer speaking to an engineer—you're speaking to a hurt child. Language matters. Words like “force people to do X” make others defensive. I learned to replace urgency with empathy. It worked better, every time.

2. Never assume bad intentions.

Early on, I believed resistance to change came from stubbornness or laziness. But people aren’t bad—they’re shaped by experience. One engineer, who seemed stuck in the past, wasn’t resisting just to resist. He felt unseen, like his skills weren’t being acknowledged. What looked like opposition was actually fear of losing identity. That shifted how I approached every conversation.

3. Leadership means making decisions.

No decision is worse than a wrong decision. Even if 40% of the team disagrees, the other 60% will gain clarity and momentum. And good decisions, even if unpopular at first, usually prove themselves over time. Startups need motion. Leaders must decide, even when it’s hard.

4. Change takes time.

Big improvements don’t happen overnight. You need consistency and patience. Pushing too fast burns people out. Let progress happen gradually.

5. Strong systems need strong foundations.

If your dev workflow blocks progress, rethink it. You can’t build a scalable product if you’re working around your tools.

6. How you say things matters.

Diplomacy, respect, and listening go further than force. Change isn't something you push through people—it's something you build with them.

What started as a frustrating experience became one of the most important learning moments in my career:

Without the right decisions at the right time, you can't scale.

But this kind of understanding only comes from making mistakes, reflecting, and doing better next time.