Outcomes, tradeoffs, and lessons from working differently.
In the first two posts, I described why we moved away from a traditional Product–Engineering split at comundo, and how we make our collaboration work day-to-day.
In this final post, I want to focus on the outcomes. What changed when we started working this way? What improved, what didn’t, and what we had to adjust along the way.
From Principles to Reality
The approach that I have described in the first two parts of this series was not implemented in one go. We have grown and iterated toward it over the last 12 to 15 months. In a way, we treated process changes the same way we treat product changes: as hypotheses to test, not decisions to enforce.
There was always a specific challenge that we were solving. We took a reasonable scope - a single aspect of our ways of working - and solved for what we want to have. The key with this approach was to always hold the overall philosophy in mind - do our tests adhere to the principles we all believe in? Is this a local or global optimization?
Another key was that all the changes we made to our process were tests. If we didn’t see positive results, we discarded the change. Or we adjusted the practice based on what we observed and ran another test. This is crucial because everyone on the team needs to be sure that new behaviors aren’t just mandated. These are genuine attempts at making work better — with a real chance of failure. Everyone needs to know that if the change doesn’t work, we’ll revert, run a retro, and adapt.
Outcomes
I will share three outcomes that we experienced.
Outcome 1: Speed
The first thing we noticed was speed. The kind of speed that is most valuable to us - time to market. We ship projects much faster than 18 months ago. The median time for a project delivery from investigation to shipping in Q4 this year was 4 weeks and we shipped 6 projects in that quarter.
The metric that I think represents engineering impact better is how much Business Potential we have shipped in any given quarter. As you probably remember, Business Potential is a number that Product (together with Sales and CS) assigns to a project based on the value this project can potentially have on the business. The goal of Engineering is to ship as much Business Potential as possible in a given time frame with the goal of increasing shipping velocity over time.
Graph above represents the change well. I want to emphasize two things from it:
- Change takes time and
- The major value unlock is in deciding what to do and only then how to do it.
Let’s discuss them in turn.
Change Takes Time
We have introduced Engineering Pods (with project ownership) and Just-in-Time (JIT) project planning at the end of Q1 2025. As can be seen from the graph it initially had little to no impact. This is not entirely true, as we have experienced unusually high operational load during Q2 (we had more than usual issues with data integrations and CS related requests). Having delivered the same amount of Business Potential during that time is a win in my book. We then increased value delivered by around 10% in Q3, which is also mostly summer, vacation period. The signs were there all along that the new way of working was indeed effective.
The Most Value Is In What we Ship
No matter how powerful and optimized the engine is, it can only take you from A to B quickly if the direction is right. And that’s why the most potent change we made was the way we select the projects we ship. With Product and Engineering aligning on Business Potential and Complexity of the projects, we were able to supercharge our delivery by selecting impactful projects that can be delivered quickly with no or minimal impact to our ability to deliver value over time. That’s the change from 225 to 450 - a 100% increase. Even if we exclude one big project (worth 100 points) that we worked on for more than 6 months, we still increased our Business Potential delivery by 56%.
The speed is the first order effect. However it is not possible to improve speed without some second order effects. Let’s discuss those next.
Outcome 2: Ownership
The most important second-order effect was increased ownership and engagement. Ownership not only of the code, but of the project delivery - at the end of the day our work impacts the company and our clients only when it’s shipped. Even if we cannot control all the parts of shipping a product - ideal translations, marketing copy, slides for prospective clients. But we can make the code available in production for our users.
The way we enabled ownership is twofold. For one, engineers design the solution themselves. Second, every pod works on a single project, until it’s done. And only then they take another one, making sure that we do not leave projects in the ”Blocked” column. These two simple adjustments made a lot of difference for a simple reason that first and foremost engineers are problem solvers. And by enabling them to find solutions to client challenges, we are tapping into this vast potential that in a different setting sits dormant.
Just a year ago, we had a quarter with zero shipped projects. We were working as hard as we have ever worked, however due to several reasons we did not ship anything. This is unacceptable for any company, but for a company of our size and stage doubly so. Because we have a good suspicion of what has happened - multiple WIP projects and full-team ownership of projects - the whole team resolved to change course. And this post is about the results of that effort.
Outcome 3: Quality & System Integrity
Another second order effect shows up because engineers craft solutions that fit existing system - the system as a whole is much more reliable. To illustrate that I looked into how our bug count changed over time. You can see that in the graph below.
I will not get into all the interesting patterns captured in this graph. The point I wanted to illustrate is that after we introduced Engineering Pods and other changes described in the previous two posts we have seen a sharp decrease in bug count. We haven’t changed our testing or bug reporting practices during this time. We also have a zero-bug policy - we address bugs no later than the next sprint and it’s not unusual to fix them immediately.
Bonus Outcome 4: Team Satisfaction
This might be a bonus, but maybe the most important outcome. Everyone knows that a happy team delivers better software. The changes we made have made the team happier. I don’t have any numbers to back this up except the feeling after one-on-ones or Retro meetings as well as the topics we usually discuss.
So what has changed? Retros have been much more positive lately. I view this with suspicion - is the team really happier or are they just unwilling to bring issues up? However it seems that the challenges we have experienced in the past, where we felt blocked by waiting on feedback and unable to finalize a project are a thing of the past now. Some challenges still come up, challenges that I will discuss in the tradeoffs part below, but our sprints become boringly predictable. I like this type of boring.
My one-on-one meetings changed similarly. Where previously we had quite a few discussions around frustrations of not being able to ship software (being blocked), we now mostly talk about context around comundo - how the things we are working contribute to the vision we have for comundo.
Tradeoffs
All the good things discussed above do not come without some tradeoffs. And we had to make a few of those to get where we are.
Less Alignment
Having Engineering Pod defining and implementing projects, means that other engineers have only a surface understanding of the project implementation. The whole engineering team owns the system, so we need to have some alignment, but we also need independence if we want to move fast.
We have recently had a discussion triggered by this exact tradeoff - engineers trying to move fast skipped internal alignment on a project that had direct impact on another piece of work. The approaches diverged, confusion briefly ensued. A few conversations later we agreed that even though we do not want to block each other, as we trust each other to make decisions, keeping tabs on what’s happening around us is important for good decisions.
Product Engineering
This is a tradeoff and a requirement. Engineers need to be comfortable making product decisions and working in ambiguity. Specifying project deliverables is work for engineers to do and align with stakeholders. This is quite a shift from a “regular” approach where Product specifies, sometimes in excruciating detail, what needs to be built. This different approach is not for all engineers. I have worked before with great people who refused to take ownership of the entire project and waited until it was “ready for development”.
I am lucky that I have great Product Engineers working with me. Engineers who, instead of being hindered by ambiguity, thrive in it and deliver their best work.
Outwardly Focused Product Function
Shipping involves more than Engineering. It’s a collaboration between Engineering, Product, Marketing and others. Fast shipping involves everyone smoothly working together and therefore changing how Engineering works impacts others. Especially Product. When engineers take ownership of defining solutions, Product can - and needs to - shift their focus even more toward customers. Understanding their workflows and needs. From experience, this is not always the major area of contribution for Product, especially in the B2B space, where access to users can be difficult. That’s why explicit alignment with Product about shifting roles is necessary.
When Product shifts towards customers more, Engineering leadership needs to fill the void to help chart the path through the ambiguity for engineers. We do not shy away from getting in touch and talking with each other, but just like engineers need to be Product Engineers instead of Software Engineers, Engineering Managers need to be tuned in to customers to guide ongoing projects on a day-to-day basis.
Applicability
The obvious question - how is this applicable outside my own context? Just to remind you about the context - I am working with a small team (6 engineers) in an early-stage startup where speed is paramount.
However, this approach can be easily scaled, with some thought, to at least tens of engineers. From the Engineering, the main consideration is how many surfaces we have - if we always work on web and mobile, this easily becomes your standard cross-functional team. And how work is usually distributed among different areas - do we usually work on cross-functional projects or do we have some more specialized work, where backend or frontend engineers work mostly independently. The key idea is to fit your existing team (capabilities and size) into the work you need to do and do not try to apply practices that work for large organizations to a small team.
Closing
The aim of this series was first to celebrate the team, and second to share what we learned. With a clear goal and conscious tradeoffs, we arrived at a set of working principles where, instead of fighting our reality, we lean into it — achieving not only better results, but also higher team satisfaction.