What I've learned in my first month as a manager, and why having been in the trenches matters

Reflections on a new role and early changes.

A few weeks ago, I stepped into a new role at BoostDraft: lead software engineer. It wasn't something I had spent years planning for. It happened because of the work I was already doing, and the recognition of a senior engineer and higher management who believed in what they saw. I'm grateful for that trust, and I want to be honest about what this transition has actually looked like in practice.

Here’s what I’ve been focused on, and what I’ve learned along the way.

Start with the mess everyone's been ignoring

One of the first things I did was tackle the mess everyone had been quietly ignoring: the accumulated disorder in how the team tracked its work on GitHub. It's still early, but cleaning that up has made prioritization easier and given everyone better visibility. Sometimes the highest-leverage thing a new manager can do is just remove the friction that's been quietly slowing the team down.

I was the bottleneck

Previously, code reviews tended to flow through the manager, which created a natural bottleneck. I'm making a deliberate effort to change this by encouraging the team to review each other's work directly, and to loop me in on specific critical areas. The aim is to spread knowledge and trust across the team without losing oversight, so delivery doesn't get stuck behind one person. Fewer things waiting in one queue means faster cycles for everyone.

New teammates need real work from day one

When someone new joins a team, it's tempting to give them only the "beginner" tasks: isolated, well-defined, low-stakes. I've taken a different approach. I've been using some of our older, lower-priority issues as onboarding vehicles, because they often touch multiple parts of the codebase and offer real learning, even when they aren't the simplest.

At the same time, I've made a point of giving our newest teammate occasional higher-priority tasks too. It matters enormously that everyone on a team feels like their work is meaningful. Being handed only the scraps — tasks that seem like they don't really count — chips away at motivation in ways that are hard to recover from. I know this firsthand; I've been the most junior person in a room where that was simply how things worked, and I promised myself I'd do it differently if I ever had the chance

Delegation doesn’t just help your team. It changes how you think

I still love writing code. That hasn't changed. But as a manager, I've been deliberately stepping back from taking on too many individual coding tasks, delegating more to the team instead, and I've noticed something as a result: it frees up mental space. When I'm less focused on implementation details, I find myself thinking more at the product and business level. In the past few weeks, I've been able to put forward ideas around our product direction and architecture that I don't think I would have seen if my head had been buried in a pull request. Delegation isn't just good for the team. It's good for the quality of your thinking.

The part of managing you can't learn from a book

The two things I think about most as a manager are workload and morale. They're deeply connected, and both matter equally.

I've spent years as an individual contributor — through the stretches that felt genuinely rewarding and the ones that quietly ground me down. That experience shapes how I manage, not because it makes me automatically better at it, but because it builds a kind of empathy that's hard to develop any other way. When someone on my team seems disengaged or stretched thin, I have a reference point for what that actually feels like, including what it feels like to be in roles where no one took the time to understand what you were actually good at, or what energized you. That kind of mismanagement is quiet and slow, but it's real.

I can't promise to always get the balance right. But I can promise to keep paying attention, and to care about whether the people on my team are genuinely engaged with what they're doing. That feels like a reasonable place to start.

About Sid:

Hi, I'm Sid, a software engineer and team lead at BoostDraft, and a lifelong learner. I started coding at 10, studied Computer Science at IIT Indore, and have spent the past 7+ years building systems in high-stakes environments, including critical trading systems at Goldman Sachs in Tokyo. I made the leap to BoostDraft because I wanted work that was genuinely challenging, impactful and close to the product, and I haven't looked back. Here, I lead the team behind our redlining tools, with a lot more in the pipeline, while also collaborating closely with our AI team, having helped lay much of its early technical foundation. Whether it's a new technology, a sport, a board game, or just getting better at something I care about, my biggest motivation has always been the same: keep learning, keep growing.

LinkedIn: www.linkedin.com/in/sidsprasad/