Transitioning into NatureTech has introduced me to a range of new and complex challenges, but I find an interesting symmetry between my past industries and the present one. Amidst the myriad complexities, one common thread has emerged - the deep need among domain experts to do things “the right way”, and our need as leaders to manage this desire.
The Fear
Congratulations, you’ve hired an incredible team of motivated domain experts. You’ve built an environment of aligned autonomy around them, enabling them to channel this motivation into transformational work that’s going to change the world. Now they’re all intrinsically motivated to do incredible work, but the “problem” with highly skilled and motivated individuals, is that they have a habit of optimising for excellence.
Why is this a problem? Well, we have a runway, and it’s running out. We can’t afford for every person to pursue their dream of a 99.9% uptime distributed system, a 99.9% confident machine learning model, or the optimal biomass burial methodology that takes 2 years to develop and peer review.
We, as leaders, are optimising to crack a business model that enables the work to continue; our domain experts are optimising to produce work they are proud of. These two can align, but by default, they often don’t.
The Cost of a High Bar
Our team at Revalue is deeply multidisciplinary, spanning software engineering, geospatial analysis, ecology, social science, and economics. Many of our domain experts, often from top-tier professional backgrounds, have cultivated a culture of craftsmanship and rigour over the years. They set a very high bar for themselves, and hitting this bar comes at a cost.
The drive to hit this bar comes from a good place. They know from experience that cutting corners leads to regretful mistakes, maintenance burdens, and professional criticism. Doing things the wrong way leads to real pain, which they have felt in the past, and now optimise to avoid.
But as any engineering leader with some experience under their belt will tell you - the obsessive pursuit of perfection often spirals into waste and inaction. As a result, companies miss their window for impact, spending precious runway chasing an elusive ideal.
As engineering managers, we’ve all seen teams spend months gold-plating features no one wants and polish products that fail to solve a real need. Similarly, moving from academia to industry, many scientists are dismayed to find their role has changed. Unlike in a research post, invalidating a method is no longer considered a success - either it works, or it doesn’t, and if it doesn’t, your job is to pivot away from this line of research and find one that does.
This is not a particularly insightful observation. Entire books have been written about why it’s better to build the right thing the wrong way than the wrong thing the right way. But as an engineering-focused leader, I never quite appreciated just how universal this challenge is across disciplines—nor the method for addressing it.
Optimising for Lean Sufficiency
Our vision At Revalue, to see nature regenerated at a planetary scale, is predicated on successfully preventing deforestation where it happens and restoring as many natural ecosystems as possible. Achieving this requires us to efficiently validate project ideas, and kill the unrealistic ones as soon as possible, so we can focus our precious capacity on those with real potential. How many dead ends we hit doesn’t matter - what counts is how many viable projects we steward into being and the cost of getting there.
This is where the power of sufficiency comes in. Sufficiency means defining the minimum level of confidence needed to make the next strategic decision—no more, no less.
Lean Sufficiency in Engineering
As leaders, our role is to help domain experts identify the minimum viable level of effort necessary to validate an idea and reach the next phase. To achieve this in product engineering, we cultivate lean principles in the team, as popularised by The Lean Startup back when I had far less white hair than I do today. In simple terms, this means we constantly encourage our engineers to find the bare minimum level of effort necessary to deliver value that validates our current understanding of what we need.
The mistake many leaders make, myself included, is neglecting to clarify the difference between “lean code” and the more important concept of a “lean solution”. Lean code eschews documentation and testing - and inevitably creates technical debt. But a lean solution tightly scopes our work to what’s needed to validate an idea and guide the next iteration. This requires engineers to collaborate closely with stakeholders to identify the key decision points where the team determines whether to stay the course or pivot.
In my experience, the former triggers “the fear” domain experts, while the latter inspired them into pursuing impact at a cost that they can manage themselves.
Lean Sufficiency in Science
We found scientists face a similar challenge when pushed to streamline their assessments of potential nature projects. The pressure to be leaner, led to them feeling pressured to compromise their standards and lower the integrity of their research. Our intent, though, was to ask the same of them as we do of our product engineers—to constantly ask themselves what is the point at which additional rigour becomes over-analysis?—and adjust accordingly.
The key, we found, is in asking them define sufficiency differently at each project stage. What level of analysis is adequate to validate the fundamental potential of a project? What’s adequate when validating viability? What about feasibility?
The mental model we push for is simple: Each phase requires incrementally deeper analysis and higher costs, but lower-stage assessments aren’t less rigorous - they just provide a lower confidence level in the project’s ultimate success. By mapping out these tiers of sufficiency, scientists can optimise their efforts while maintaining integrity, a sense of rigour and transparency about how likely they are to change their recommendation further down the line.
Lean Thinking is a Transferrable Multidisciplinary Skill
In both cases, we hand control to the domain experts. They get to manage the confidence they are comfortable with.
For the engineers it’s confidence in the limits of the system’s scalability, resilience and viability; and for the scientists it’s confidence in the limits of their assessment, method or model’s accuracy and uncertainty. Either way, we push the teams to define the goals they are pursuing, attach a level of sufficient confidence to each one and optimise for that—nor more, no less.
What this Looks Like at Revalue
Over the past year, our multidisciplinary team has focused on developing a robust methodology and supporting technology to efficiently assess carbon projects’ viability, feasibility, and path to commercialisation. By defining clear decision points on the level of confidence produce by the analyses necessary for each validation phase, we can quickly filter out low-potential projects and strategically allocate resources.
To support our cross-functional assessment team, our engineering team has developed a platform that not only facilitates the necessary analyses but also provides a level of transparency and interactivity that traditional tools and practices in our industry often lack. This platform allows stakeholders to explore project data and insights more flexibly. It enables them to ask probing questions and gain valuable perspectives without requiring scientists to repeatedly redo analyses.
Achieving this while maintaining scientific and commercial integrity required a strong focus on multidisciplinary collaboration. Crafted along agile and lean principles, we run an iterative multidiscipline product discovery process, bringing together engineering, product, landscape analytics, ecological assessment, scientific, and commercial stakeholders. Each week, these stakeholders gather to realign on the current state of our technology, discuss the next set of product requirements and agree on the level of sufficiency necessary to keep things as lean—yet high integrity—as possible. The product engineering team then spends the week learning through delivery of the next slice, and the process repeats.
As a tech leader, I’m struck by the parallels in how scientists and product engineers approach their work. Even more exciting is seeing how many hard-won lessons in managing engineering teams translate powerfully to other domains. While the details may differ, the core challenge is the same - harnessing expertise to rapidly deliver real-world impact through structured cycles of validation.
By relentlessly asking ourselves, ‘What is sufficient?’, we discover that the sweet spot between rigour and velocity isn’t a compromise—it’s where real breakthroughs happen.