When I think about leadership, I'm not thinking about titles or authority. I'm thinking about the person who helps the team stay oriented toward the same goal. In a startup, that goal is usually building something that users actually want and can actually use. The challenge is that different disciplines approach that goal from different angles, and those angles don't always align.
My role has evolved into being the person who helps keep those angles aligned. I'm never the smartest person in the room, but because I've learned to think across disciplines, I can see where the gaps are, where the misalignments happen, and where the team needs to be reminded of what we're actually trying to build.
The biggest problem I've seen is siloed thinking. Engineers think like engineers, designers think like designers, product managers think like product managers. But users don't think that way. They don't care which team made a decision; they only care if the product makes sense.
This disconnect is where most product problems live. When engineers optimize for performance but ignore usability, when designers focus on aesthetics but miss technical constraints, when product managers chase metrics but lose sight of user value, that's when products fail. Not because people aren't smart enough, but because they're not aligned around the same goal.
I used to roll my eyes at "design thinking." It felt obvious: of course we should think about users. But over time, I've come to see the point. A problem can have thousands of solutions. Just solving it isn't the goal. The goal is finding the solution that actually works for users.
If the problem is "get from point A to point B," solutions include walking, running, cycling, driving, even riding on someone's back. They all technically solve the problem. But not equally well.
That's the mistake teams often make: assuming "a solution" is "a good solution." It isn't. A good solution is one that makes the product simpler, not more complex. It's one that reduces cognitive load, not increases it. It's one that helps users achieve their goals, not just satisfies the builder's preferences.
Designers sometimes see a usability problem and respond with tooltips, callouts, or alerts. But users rarely read them. Without testing, you don't know if it helps. You're solving the wrong problem: trying to make the interface more understandable instead of making it more intuitive.
This is a common pattern. When something is hard to use, the first instinct is to explain why it's hard to use. But the better solution is usually to make it easier to use. Instead of adding a tooltip to explain a confusing button, redesign the button so it doesn't need explanation.
Engineers sometimes ship prototypes without thinking about users at all. When they do, it's often the "If I were a user, I would..." logic. That's not user thinking, that's guesswork. The challenge is that thinking like a user requires empathy, not just imagination. It requires understanding the user's context, their constraints, their mental models.
But if an engineer truly thought like a user, even small choices would change. If they had to decide whether a button goes on the left or right, the effort is the same either way. But if the right is better UX, putting it there makes the designer's job easier, reduces changes, and speeds up shipping.
That's what I push for: orienting everyone toward one common goal, delivering value to users. When everyone thinks about the same goal, decisions become easier, conflicts become rarer, and the product becomes more coherent.
One reason I can step into this role is my background. I studied computer science, but I never wanted to be an engineer for engineering's sake. I use code as a tool, just like design.
That lets me translate. I can talk to engineers about constraints, talk to designers about patterns, and talk to business folks about goals, then tie those threads together into decisions the team can act on. I don't need to be an expert in everything, but I need to understand enough to spot the disconnects.
Sometimes that means jumping into Figma to refine a flow. Sometimes it means writing frontend code myself to fix a UI inconsistency. It's not that I'm the best at any of these things. It's that I can switch contexts enough to keep coherence across the product.
This isn't about being a jack-of-all-trades. It's about being able to see the connections between different disciplines. When an engineer says "this is technically difficult," I can help translate that into design implications. When a designer says "this doesn't feel right," I can help identify the technical constraints that might be causing it.
The goal isn't to eliminate the need for specialists. It's to help specialists work together more effectively. When everyone understands how their work connects to the bigger picture, they can make better decisions about trade-offs and priorities.
I often step in and overcommunicate. In the short term, this works. We make decisions quickly, nobody stays blocked.
But there are flaws. When I backstop every decision, my designers stop trusting themselves. They start looking to me instead of building their own instincts. And it leaves my biases unchecked. If I'm wrong, and everyone defers to me, then we all go wrong together.
This is something I'm still learning. Leadership isn't just filling the gaps yourself; it's helping others close those gaps independently. It's about creating conditions where people can make good decisions without needing constant guidance.
I don't want to be the bottleneck. I want the team to internalize user focus so they don't need me translating all the time. That's something I'm still struggling to make happen. The challenge is building a team that can think across these boundaries without needing to be experts in everything.
The goal is to create a team that can operate effectively even when I'm not in the room. That happens when people understand not just what to do, but why it matters and how to think through similar problems in the future. It happens when they have the tools and the confidence to make decisions that align with the team's goals.
One area where I don't compromise is team sanity. I don't want people working overtime, stressed, or carrying unnecessary deadlines. Startups are already messy enough; adding artificial pressure just burns people out.
This isn't about being soft or avoiding difficult conversations. It's about recognizing that good work comes from people who are well-rested, focused, and engaged. When people are stressed and exhausted, they make worse decisions, they're less creative, they're more likely to take shortcuts that create problems later.
That doesn't mean it's always calm. We still ship fast, make trade-offs, and deal with chaos. But I see it as part of my role to shield the team from noise so they can focus on solving real problems.
This means being realistic about what's possible. It means saying no to requests that would require unsustainable effort. It means creating buffers and contingency plans. It means recognizing when the team is at capacity and adjusting expectations accordingly.
It also means creating an environment where people feel safe to speak up when they're overwhelmed, when they need help, when they see problems that others might miss. When people are afraid to raise concerns, small problems become big problems, and the team's ability to work effectively gets compromised.
Anuj once said in a testimonial that I bridge the gaps. The truth is, I don't have any magical skill. I just keep trying to think like a user, and I keep pushing others to do the same.
Leadership, for me, isn't about having all the answers. It's about orientation: keeping design, engineering, and product pointed in the same direction, toward delivering value. Some days I succeed, some days I fail. But that's the work.
The work is never done. Every project brings new challenges, new opportunities to learn, new ways to improve. But the goal remains the same: help the team build products that actually help users. When everyone is oriented around that goal, the rest becomes easier.
It's not solved. It's hard. But that's what makes it worth doing.
