I joined StaffVertex, a time tracking and workforce management SaaS, in July 2025 as one of the developers building it from scratch. By early 2026 I was leading the team, and on 5 October 2026 we officially launched. I still write code most days. But the job I do now is not the job I was hired for, and nobody hands you a manual for the switch.
This is what actually changed for me, written while it's still fresh.
Before: my ticket, my code, my problem
As a developer my world was a ticket. Understand it, build it, test it, open a PR, move to the next one. If my feature worked and the review passed, I'd done my job.
That mindset is great for shipping. It's also narrow. I didn't think much about why a feature was next on the list, what marketing was promising customers, or what would happen to the desktop users still on last month's build. Someone else was thinking about that. Then that someone was me.
The first thing that changed: my output stopped being code
We're a small team, three to five developers depending on the month. With a team that size the lead can't disappear into meetings. I still pick up real work, like the migration of the whole permission system to a scoped model, and the desktop app's time handling.
But my most valuable output is now things that aren't commits:
- A plan for the sprint that everybody understands the same way.
- A task broken down well enough that a teammate can finish it without five follow-up questions.
- A review comment that prevents a bug in production next month.
- A decision made early, so three people don't build three versions of the same thing.
It took me a while to stop feeling guilty on days when my own commit count was low. A day where I unblocked two people is usually worth more than a day where I wrote a feature alone.
Planning: every flow, not just every feature
As a lead I got pulled into planning every part of StaffVertex: each user flow, how the web app and the desktop tracker fit together, what we ship first, and what we leave for later. I also sit in on marketing and strategy discussions, which I didn't expect at all.
That turned out to be useful for engineering. When you know what the landing page is going to promise, you know which flows absolutely cannot break on launch day. When you know which customers are trialling which plan, you know where billing edge cases will show up first.
The way I plan now is simple:
- Start from the user's flow, end to end, before talking about screens or endpoints.
- Find the parts that touch money, time or permissions. Those get the most careful design and the most careful review.
- Split the rest into tasks small enough to review in one sitting.
- Write down the decisions, not just the tasks, so we don't argue about them again in two weeks.
Code reviews: from "does it work" to "will it survive"
Reviews are where I spend the most leadership energy. When I was a developer I read a PR to see if it worked. Now I read it asking whether it will survive contact with real users.
A few questions I ask almost every time:
- Is this scoped to the right organization? In a multi-tenant app, a missing filter is a data leak, not a bug.
- Does it change anything an installed desktop build depends on? Our rule is that the desktop API only grows. Old fields stay, new ones are optional.
- What happens when it fails? An error that shows an empty list looks exactly like "no data" to a user.
- Will the next person understand why this is written this way?
I try hard to keep reviews about the code and not the person. I also try to approve fast when something is good. Slow reviews are a hidden tax on a small team, and nothing kills momentum like a PR sitting for two days.
Talking to stakeholders
This was the biggest change. I now talk to management and, at times, clients about scope and deadlines. The engineer in me wants to give exact answers. Real conversations rarely allow that.
What has worked for me:
- Say what you know, what you don't, and when you'll know. "This part is two days. The billing part depends on how Stripe handles this case, I'll confirm by Thursday" is better than a confident guess.
- Offer options instead of a no. "We can ship it this week without the export, or next week with it" lets the other side make a business decision.
- Translate risk into their language. Nobody outside the team cares about a race condition. Everyone cares that two people could be billed for the same hour.
Mistakes I made
Some honest ones.
I held on to too much. Early on I kept the trickiest tasks for myself because it felt faster. It was faster that week, and slower every week after, because nobody else learned those parts of the system.
I sometimes explained the "what" and skipped the "why". Then I was surprised when a teammate made a different trade-off than I would have. They weren't wrong. They just didn't have the context I had in my head.
And I underestimated how much launch work isn't code. Pricing pages, onboarding emails, help articles, the order things roll out. Launch day made it very clear that a product is a lot more than its repository.
What I'd tell a developer about to become a lead
- Your job is now the team's output, not yours.
- Protect the dangerous parts of the system with design and review, and let people own the rest.
- Write decisions down. Memory is not documentation.
- Keep coding, but pick work that teaches you about the system, not work that makes you a bottleneck.
- Learn to talk about trade-offs in plain language. It's a skill, and it can be practised like any other.
We just launched, so in a way the real test starts now. Real customers, real support tickets, real pressure on every decision we made in the last year. I'll write a follow-up once we've lived with it for a few months.