In our first interview of the “Behind the Stack” series, we go behind the scenes with Cécile Ritte, Head of Engineering at Pigment, an AI business planning and performance management platform, to explore how they balance innovation and reliability, scale infrastructure for enterprise demands, and build a culture of high-velocity, high-quality development. Along the way, we dive into one of the most pressing topics shaping technology today: the rise of AI. From sandboxing experiments to integrating AI into workflows, Pigment’s leaders share how they’re embracing this transformation while staying grounded in long-term architectural thinking and customer value.

Section 1: Leadership & Vision

How do you align the engineering roadmap with the broader strategic vision of the company in a high-growth environment like Pigment?

At regular points throughout the year, leadership reviews our strategic product priorities and where we want to invest. These decisions guide both talent recruitment and the allocation of engineering resources. 

We then reconcile this top- down strategy with product, technical, and organizational inputs, which are collected on a quarterly basis from qualitative feedback and KPIs.

This is when we identify and arbitrate critical engineering projects, whether they’re directly customer-related (e.g. scale our infrastructure) or indirectly (e.g. team productivity, cost efficiency) against the company roadmap.

We strive to make this process as transparent as possible to engineering teams. We also try to find the right balance between being prescriptive and empowering teams to share feedback, propose their own projects and decide how they will structure their quarterly delivery. To support collaborative decision making, we expect clear rationale and justifications for proposed work, ideally including the expected quantifiable impacts on the business. 

What principles guide your decision-making when balancing innovation with operational reliability?

The best way not to break anything is to do nothing, but as an innovation-first company, that is obviously not our philosophy at all! Instead, our principle is to make it safe to fail, and to fail fast. For our engineering teams specifically, this means designing systems and processes that minimize the cost and impact of mistakes. Reversibility is also key. If something goes wrong, we should be able to unwind it quickly.

For example, engineers shouldn’t wonder whether or not to deploy a risky change. Instead they should be asking “how quickly can I revert it if needed?”, such as leveraging feature flags, observability, and lightning-fast rollback capabilities. 

Another example is around our engineers and scientists working with AI. They can deploy anything in their own sandbox within seconds, allowing them to test ideas quickly without going through a full CI/CD overhaul. 

What do you believe are the key qualities of a successful modern CTO today?

The role of the Chief Technology Officer has evolved significantly. Today, a successful CTO must combine deep technical expertise with strategic, human, and business acumen. I believe there are three core qualities that are essential:

• A mix of technical curiosity and pragmatism:

A great CTO can master technology trends while also understanding when to avoid hype-driven distractions and dead ends. This is especially critical in rapidly evolving spaces like AI. A great CTO can understand the full spectrum of what’s possible, while also making sharp choices about what’s going to bring value. 

• Business acumen and customer empathy: 

Technology doesn’t just exist in a vacuum. A great CTO must deeply understand the product, the market, and the users. This means being able to challenge project decisions, shape roadmaps, and design architectures that mean you’re building the best solution to solve the right problems. 

For instance, at Pigment, when designing infrastructure we need to have a strong understanding of the different use cases our customers use the platform for, if they’re data or calculation heavy, if they’re impacted by seasonality, and so on. 

• People proficiency: 

Modern technology leadership is as much about people as it is about tech . A CTO should be spending 20-30% of their time hiring, and should actively invest in building cross-functional relationships, mentoring, networking, and sharing and engaging people around a vision. 

Section 2: Scaling Infrastructure

What were the most critical decisions you made early on at Pigment when designing the infrastructure for scalability?

From the very beginning we made several critical architectural choices at Pigment to ensure the platform could scale seamlessly with enterprise-level demands. 

1. We developed a sparse engine, purpose-built for handling large, sparse datasets efficiently. This is particularly important for financial planning use cases, where many data points don’t apply to all dimension combinations. Our sparse engine excels in both calculations and visualization of high-dimensional datasets.
   
   
2. Rather than scaling vertically, we opted for a distributed architecture that allows for horizontal scaling. This means we can add more machines to handle increasingly large datasets, as opposed to being limited by a single machine’s capacity. In essence, it means we can grow alongside our customers’ evolving needs without rearchitecting the core. 
   
   
3. Finally, the system was designed to mean users can access and input data without interruptions, even during model recomputations. This enables true concurrent usage without blocking, which is essential for enterprise-level scaling.

How does Pigment approach architectural evolution as the product scales, from MVP to enterprise-ready?

As the product scales, we need to prioritize both scalability and enterprise-readiness. This means evolving the architecture to support enterprise grade capabilities including trust and governance (eg. version control and lifecycle management), enterprise-grade integrations, programmability through public APIs, and robust security features like granular access control and SSO integration.

Have there been any specific inflection points at Pigment where you had to rethink core technical assumptions?

Yes! We’ve encountered several key inflection points that pushed us to revisit and evolve our technical architecture. 

Initially, we complemented PostgreSQL with SingleStore to handle large analytics workloads, as PostgreSQL struggled with data sparsity and performance for large datasets. As usage grew, we invested in a multi-layer data engine that decouples compute from storage, allowing us to scale independently to accommodate seasonality and varying use cases. Doing so, we enable better data sharing between machines and virtually unlimited horizontal scaling. 

We also rethought our approach to processing calculations. Over time, we optimized our system to dynamically prioritize visible areas and use smart batching to combine changes. 

Section 3: Engineering Culture & Teams

What strategies do you use to maintain high engineering velocity without sacrificing code quality?

First, we avoid burdening our engineers with unnecessary processes. We don’t adopt frameworks just because they’re standard or work elsewhere. We keep a minimal process overhead so we can stay agile and responsive to change. 

We also encourage decisions to be as bottom-up as possible. We foster a mindset of collective accountability through transparent communication, collaboration and rotating responsibilities. For example, engineers take turns making sure our delivery pipeline is always green and that we keep releasing to production at least once a day, relying heavily on automated testing. 

To reinforce this sense of accountability and ownership, we make key KPIs publicly visible, such as the time taken for code to reach production, the duration of end to end tests, or our deployment success rate. 

How do you structure teams for scaling, do you favor platform teams, product squads, or another model?

When Pigment was a small team of just 15 engineers, we kept things fluid, reorganizing our teams each quarter to stay responsive to shifting priorities. 

As the company grew, so did the need for stability and specialization. Today, we now have 80 engineers and 12 teams that are a mix of product squads and platform teams. Platform teams expose services to product squads, abstracting the platform complexity for them so they can focus on delivering user-facing features. 

We designed the current team structure to match our software architecture, grouping teams together within “communities” where work is tightly coupled which helps optimize collaboration and also reduces unnecessary information overload.

How do you ensure technical excellence across a growing engineering org?

It obviously all starts with hiring great talent and never compromising. We’ve never lowered the entry bar at Pigment. Our engineers have formed a hiring guild where they work continuously with recruiters to refine our interview processes, improve our employer brand, and proactively reach out to top candidates. 

As we’ve scaled, we’ve also recognized the importance of proper onboarding, beyond just a welcome and up to date documentation. Pigment started with a tight-knit group of engineers who knew exactly what needed to be done. But as you grow, implicit culture has to become explicit, facts and figures preferred over intuition to inform a shared strategy, and expectations made specific. From the moment someone joins - or even before - they should have a clear understanding around why we do what we do, what good code looks like, what makes engineers successful, and so on. 

Finally, we pay close attention to retaining and growing top talent. Engineers should feel that Pigment is the best place to learn, solve hard problems, and grow alongside exceptional peers. 

How do you manage technical debt in a fast-paced startup environment?

Some companies may tackle legacy code and technical debt by allocating fixed resources every year. This is not our approach. We have no preconceived idea where our teams should spend their time. Instead, we look at the problems to solve, and we try to make the right decisions based on the value that the work will unlock, either now or later, for our customers. 

Our ability to manage this well hinges on a strong partnership between engineers and product managers who all operate as one team, working closely to frame trade-offs, assess impact, and ensure that technical investments are always grounded in customer value.

Section 4: Legacy Systems & Long-Term Thinking

What are the key architectural choices you make early on to avoid legacy challenges down the road?

We made several deliberate architectural choices early, including:

• A single code repository. In our experience, splitting codebases tends to create defensiveness and conflicts between teams, which gets in the way of collaboration and fast growth
  
  
• Using standard cloud components and as little proprietary technology as much as possible to avoid vendor lock-in
  
  
• Leveraging Infrastructure as Code early on to prevent error-prone manual setup, reduce toil, and make developers autonomous with common infrastructure needs

What’s your take on “rewrite vs. refactor” when dealing with aging systems?

There’s no universal rule. What matters most is correctly framing the problem and particularly whether we are facing a fundamental flaw or a messy implementation. At an early stage, a correct assessment is critical. Going for small, incremental changes to deliver faster and with less risk may be tempting, but overlooking structure issues may be costly over the long-run; for example, if we’re unable to scale our system due to the wrong structural choices. 

In a start-up environment, the challenge is to strike the right balance between tactics, while also staying aware of long-term risks. 

Section 5: Looking Ahead

What are the biggest challenges you anticipate for Pigment’s tech stack in the next 12–18 months?

Beyond continuing to scale performance, one of the biggest challenges will come from advancing our agentic vision to solve real use cases for our customers. 

One of the key challenges with AI is that it’s not deterministic, which poses many questions:

• Where should deterministic vs. non-deterministic functionality be used to best serve user needs? And as a result, what still holds true in our product and what do we need to revisit?
  
  
• How can we package this functionality with the best possible user experience 
  
  
• And how can we deliver this consistently, reliably and with the minimum latency possible as we iterate and combine multiple use cases and models together

The latter aren’t necessarily traditional engineering problems. It demands new approaches to testing, benchmarking and orchestration, as well as a growing collaboration with data scientists and machine learning engineers. It’s going to be a very interesting challenge for us to solve!

What technologies or architectural patterns are you most excited about right now?

Probably how AI is entirely reshaping the way we work. 

At Pigment we’re committed to staying at the forefront of this transformation. We’re already embedding AI across our operational processes, whether it’s helping engineers write better code, detecting and resolving production issues, scaling knowledge documentation across the team and so on. And that’s just the beginning!

The rise of autonomous agents and copilots could redefine entire workflows. It’s so exciting but it’s also a little bit scary and daunting! As we embrace AI we also need to think about the impact, for example, on how they might shape our ability to think critically, interact with one another and so on, which I think is a little overlooked at the moment.

What advice would you give to a first-time CTO scaling a company from Series A to Series D?

1. Understand the business deeply, and always know what’s most important for your company at any given point in time. Is it product market fit, time to value, profitability, and arbitrate accordingly 
   
   
2. Think ahead to what breaks next. Regularly ask yourself and your team: if we 10x this - users, data, developers - what happens? This mindset will help you work towards a long term vision while making pragmatic decisions along the way. Don’t aim for perfection but take decisions that will work for long enough and be ready to undo them later.
   
   
3. Trust your team and encourage bottom up accountability early on, by sharing clear expectations and giving people ownership of both problems and solutions. Learn when to step in and when to let go. And beware of the hero culture. You don’t want to let the organization overgrow your team, or it will overgrow you. 
   
   

Whether it’s rethinking infrastructure, fostering a safe-to-fail environment, or preparing for an agentic future, Cecile’s perspective underscores a common theme: the best engineering organizations are those that can adapt, scale, and continuously learn. For aspiring leaders, the lessons here serve as both a practical guide and an invitation to think bigger about what it means to build enduring technology in a rapidly changing world. 

See you for the next interview with…🤫you’ll have to wait!