Last week, I spent the day out of the office with a colleague and the rest of the team, elaborating on what we’ve come to call our manifesto. At first, I wasn’t particularly supportive of the idea. The word manifesto often carries political overtones - a statement of ideology rather than a guide to practice. But I’ve come to see that the purpose of ours isn’t political at all. It’s about defining how we work together - how we align, make decisions, and deliver value as a unified team.
Our team is what I’d call stripey: a blend of three separate companies, each bringing its own culture and perspective. My current employer contributes younger engineers - open-minded, eager to explore new ideas and approaches. Another company represents the customer side, helping to steer our direction. The third brings a group of experienced engineers, often preferring tried-and-tested methods and wary of unnecessary change. Naturally, this mix produces friction.
What’s interesting, though, is that the friction isn’t inherently bad. The older engineers are cautious but receptive; the younger ones are more experimental. This contrast creates tension, but it also generates energy - the kind that can lead to meaningful innovation if channelled properly. Even if our overall throughput isn’t maximal, I’ve come to believe that true productivity lies in designing a working model that fits us as a team. Every team’s equilibrium is different, and our job is to find the version of “optimal” that we can all sustain.
For me, what matters most is that we express our opinions openly and debate with minimal politics - to reach a steady equilibrium where respect guides our collaboration, and the value we create stands above our individual preferences. That means allowing space for conceptualising and projecting the pros and cons of new ideas, even if we don’t end up adopting them. The process of thinking together is often more important than the outcome of any single discussion.
Of course, our success also depends on collaboration with the customer. In our case, they play a crucial role by providing sample data we need to develop and test features. When that data is missing, we’re forced to make assumptions - and those assumptions introduce risk: technical debt, uncertainty, and the possibility that the software won’t meet real-world needs. Those are not just technical problems; they erode confidence and morale.
Ultimately, I’ve come to see that morale and productivity are deeply linked to clarity and flow. When dependencies are clear, communication strong, and our shared framework well-understood, the team moves forward with confidence. We don’t need to eliminate all friction; we just need to ensure that our energy goes into the right kind of friction - the kind that polishes, not wears down.
In that sense, this manifesto isn’t a declaration of ideals. It’s a living reflection of how we learn to move together - across boundaries, across perspectives, and across generations of engineers.