❯cat ./projects/redcarbon.md
RedCarbon
I joined RedCarbon as one of its first engineers when the company was barely formed. Over four years, the team has grown from 3 to 10+ people, the platform now processes 500k+ alerts monthly, and the company has reached Series A funding. I'm Tech Lead of a team I helped build from scratch — in a domain I had to teach myself, on a codebase I helped design.
//The context
RedCarbon had just been founded when I joined. The team was three people: one Engineering Manager handling the backend, two frontend engineers. I was hired to help the EM scale up the backend side — a Go microservices platform powering an AI-driven Security Operations Center product.
It looked like a natural next step. It wasn't.
//The challenge
My background was DevOps — infrastructure, pipelines, containers. I knew how systems run. What I didn't know was how a product is built: how to read a business requirement, how to model a domain, how to make tradeoffs that matter to a customer.
The domain made this harder. Cybersecurity at the SOC level is a complex, specialized field. Threat detection, alert correlation, incident response workflows — I had to learn the theory and the practice simultaneously while shipping production code.
I had to stop thinking in infrastructure terms and start thinking in product and domain terms. That shift took time and it was uncomfortable. I wouldn't trade it.
//What I built
The team had no structured workflow. I introduced Jira and Linear for task management, standups and sprint planning, and a shared understanding of what 'done' means. Small changes with outsized impact on predictability.
I brought my DevOps background to bear on the cloud layer. Migrated infrastructure management to Pulumi on GCP — code-first, version-controlled, reproducible. No more manual configuration drift.
Kubernetes and GitOps were already part of the stack when I joined. I took ownership of that layer, deepened it, and brought the same expertise I'd been developing independently — eventually speaking about it at KCD Italy, Incontro DevOps, and other conferences.
The platform had no monitoring. I built the full Grafana + Prometheus stack — dashboards, alerts, service-level indicators. For the first time the team could see what was actually happening in production.
I grew into Go microservices development and became one of the primary contributors to the backend platform. As the team needed to grow, I helped the EM with interviews and hiring — learning to build a team, not just join one.
//From engineer to Tech Lead
As the product matured, we split into two teams with distinct contexts. I took technical ownership of one team and the overall engineering direction of the department. The role came with a different kind of responsibility: not just what to build, but how the whole team builds it.
I work closely with the PM on roadmap and planning, and interface directly with C-level stakeholders — translating business requirements into technical decisions, and translating technical constraints back into product language. Domain-Driven Design became my foundation for this: having a shared ubiquitous language between engineers and business stakeholders is not a luxury, it's what prevents costly misunderstandings.
My approach to leadership is deliberate: I avoid micromanagement. Senior engineers own their architectural decisions — I set direction and remove blockers. Where I focus is on mentorship: helping juniors grow and, over time, positioning senior engineers to become future team leaders themselves. If I do my job right, I make myself replaceable.
//What I learned
Engineering skills get you in the door. Domain understanding keeps you relevant. Knowing how a business makes money — and what it needs to stay alive — changes how you write every line of code.
The hardest part of being a tech lead is not the technical decisions. It's learning when to decide and when to trust the people on your team to decide. I'm still learning that balance.
Want to talk about this? Get in touch →
← All projects