What I Learned Leading a 10-Person Cross-Functional Team as a Tech Lead

At Kintry I led and managed a 10-member team spanning engineering, sales, and HR, while also being the person writing the architecture and a meaningful share of the code — full-stack across web, mobile, and backend, plus the WebRTC video platform and the ML models feeding operational decisions. That combination (tech lead and cross-functional team lead at once, at a small company) forces a specific kind of leadership that’s different from either pure engineering management or pure individual contribution.

Leading people outside your own function requires different judgment

Leading engineers you can review code with is one skill. Leading sales and HR functions when your own background is entirely technical is a different one — you can’t evaluate their work the way you evaluate a pull request. What worked: for functions outside my own expertise, my job shifted from “judge the quality of the work directly” to “make sure the right goals and feedback loops existed for that function to judge itself, and remove the obstacles they flagged.” Trying to micromanage sales tactics or HR process as an engineer with no real background there would have been actively harmful — the value I could add was clearing organizational obstacles and keeping the whole team pointed at the same outcomes, not second-guessing domain expertise I didn’t have.

Being both the architect and the lead has a real cost, worth naming honestly

Writing significant architecture and code myself while leading a 10-person team meant real tradeoffs, not a free combination. Time spent deep in WebRTC connection-reliability debugging was time not spent on 1:1s, planning, or removing blockers for the rest of the team — and the reverse was equally true. I didn’t solve this tension cleanly; I managed it by being explicit with the team about which mode I was in during a given week (heads-down building something specific vs. available for leadership needs) rather than pretending I could do both fully, simultaneously, indefinitely, which was the mistake I made early on before adjusting.

Cross-functional alignment mattered more than any single function’s execution

With engineering, sales, and HR under one team, the biggest recurring risk wasn’t any one function executing poorly — it was the functions optimizing for locally sensible goals that didn’t actually add up to the same outcome. Sales committing timelines engineering hadn’t validated. Engineering building features without input on what sales was actually hearing from prospects. The fix that helped most was a lightweight, regular cross-functional sync — not a status-update meeting, specifically a “what did you learn this week that the other functions need to know” conversation, structured to surface exactly the kind of misalignment that doesn’t show up in any single function’s own metrics.

Delegation had to be real, not nominal

At 10 people, it’s tempting for a tech lead to stay the bottleneck on every technical decision, because it’s genuinely faster in the moment to just decide things yourself than to explain enough context for someone else to decide well. This doesn’t scale even at 10 people, and it actively stunts the growth of engineers who could be making more decisions themselves. What actually worked: being explicit about which decisions needed my sign-off (architecture with long-term platform-wide implications) versus which were fully delegated (implementation approach within an agreed architecture) — the ambiguity of “sort of check with me on everything” was worse for both trust and velocity than a clear, if imperfect, line.

Managing HR as an engineer taught me the most, uncomfortably

HR was the function furthest from my background, and it’s where I made the most mistakes early — treating people processes with the same “find the efficient solution and implement it” mindset that works for engineering, when people processes often need more patience, more listening, and less optimization-for-speed than a technical problem does. The adjustment that helped: treating HR (and to a lesser extent sales) conversations as information-gathering first, decision-making second, rather than my default engineering instinct to move quickly from problem statement to solution.

What I’d tell someone about to lead a cross-functional team as a technical founder or lead

Don’t assume your engineering judgment transfers to functions you don’t have a background in — your job there is enabling and unblocking, not directing. Be honest with yourself and your team about the real cost of staying deeply hands-on technically while also leading people, because pretending that combination is free leads to under-delivering on both. And build an explicit cross-functional information-sharing habit early, because the failure mode that actually hurts a small team isn’t any one function underperforming — it’s functions quietly drifting out of alignment with each other while each looks fine in isolation.