I have led R&D teams while remaining close to the code. That combination is not a personality quirk — it is how institutional software stays honest.
Roadmaps are not a substitute for judgment
As VP of Research and Development, roadmaps, tenders, and team health mattered. So did knowing whether a microservices migration was actually zero-downtime, whether SPA and mobile fronts would hold under multilingual load, and whether “open platform” meant extensible or merely marketed as such.
Technical evaluations for large contracts are where leadership gets tested. Buyers do not fund vibes. They fund architecture that can be explained, demonstrated, and operated.
What hands-on leadership looks like
- Reviewing the hard paths yourself before asking a team to own them
- Setting standards for accessibility, privacy, and delivery quality
- Protecting deep work while still unblocking cross-team delivery
- Mentoring without turning into a pure status aggregator
The research thread
Co-authoring work on semantic harvesting and micrometadata (SMESE / MLM lines) reinforced the same lesson: R&D leadership includes publishing the thinking, not only shipping the backlog. Platforms that federate knowledge need people who can reason about rights, provenance, and structure — not only about tickets.
Titles change. The craft is the through-line.