Engineering Management in the Trenches: Lessons from the Frontlines of Product Delivery

Engineering management is often discussed in abstract terms. Topics such as processes, productivity frameworks, and agile practices tend to dominate the conversation. Yet, very little is said about the raw, behind-the-scenes challenges of managing developers in real-world conditions. Even more so, when those developers are not your employees, but external professionals working on behalf of clients, as in our experience.

From missed timelines to unmet expectations, every engineering manager eventually confronts the reality that delivering software is not just about writing code. It is about managing people and complexity as well as aligning expectations. This article offers a candid reflection on the pain points we've faced, the lessons we've learned, and one particular delivery method we’ve found effective in specific contexts, not as a universal replacement, but as a complementary model within a broader engineering strategy.

‍

The Pain Behind the Process

In our journey, we have managed projects that delivered smoothly end-to-end. But we’ve also had encounters that taught us hard lessons. One such experience involved managing software projects in the conventional way: scope the full product, agree on a lump-sum budget, and assign the work to an external team, either sourced by us or provided by the client. We assumed that with regular check-ins, clear documentation, and goodwill, things would progress as expected.

But sometimes, they didn’t.

In some cases, we faced issues familiar to many tech leaders: developer disengagement, missed timelines, or unclear communication. Deliverables came back incomplete or buggy, and expectations were misaligned. What began as a straightforward engagement could suddenly feel like a recovery mission. These weren’t the norm, but they were costly enough to prompt a rethink.

‍

The Turning Point: Modularised Payment and Delivery

We realised that we needed a system that rewarded delivery, not promises. So, we introduced modularised payments. Every product is now broken down into specific, clearly defined feature modules such as onboarding, user management, roles, and permissions. Developers are paid only when a module is completed and accepted. This approach protects our clients from financial loss, motivates developers to complete work in a timely fashion, and gives us the flexibility to offboard or replace a developer mid-project without burning through budgets.

‍

Competence, Character, and Commitment

‍

As we evolved our model, we learnt that technical ability alone was not enough. Some of our most technically brilliant developers struggled with communication or consistency. Others were reliable but needed structured support to perform effectively.

To bridge this gap, we refined our internal processes.

• We began providing detailed task definitions with context and specific outcomes, avoiding vague requests like “fix login bug” or “update dashboard”.
• We added supplementary video walkthroughs using tools like Jam.dev, giving developers a visual and contextual understanding of what was expected.
• We stopped assuming that developers would “just figure it out”. That assumption had cost us too much time and money.
  
  

Managing Turnover With Systems, Not Sentiment

‍

Developer turnover is a given in today’s global tech ecosystem. People leave. Some disappear mid-sprint. Some underdeliver. Instead of reacting emotionally, we designed for the inevitability.

• Our modular approach meant that when a developer left mid-project, we did not lose the entire thread.
• Work was compartmentalised, so a new developer could step into a defined module without needing to understand the entire codebase.
• Compensation was tied strictly to completed work. No module completed, no payment processed. This removed awkward conversations and replaced them with systemised fairness.
• We built a flexible resource pool of vetted developers. When gaps appeared, we filled them quickly with the right talent.

‍

Lessons We Have Learnt

‍

Over time, our pain points shaped the core of our engineering philosophy. Here are the six principles we now follow at Assurdly:

1. Break Work into Modules, Not Monoliths:  Avoid lump-sum contracts for entire product builds. They seem simple but often conceal risk. With no tangible milestones, developers may lose momentum, and issues are noticed too late. Modular work packages, defined by features or user flows, keep the team aligned and performance measurable.
   
   
2. Pay for Progress, Not Promises:  Tie payments to completed and approved work. Each module should be a self-contained unit with clear scope, outcome, and review criteria. This model drives results, builds mutual trust, and eliminates ambiguity around compensation and quality.
   
   
3. Redefine Developer Competence Beyond Code:  Brilliant code is not enough. A developer’s ability to communicate clearly, understand context, ask good questions, and follow through consistently matters just as much. Our evaluations now focus on reliability and soft skills, not just technical output.
   
   
4. Use Visuals to Make Documentation Real:  Traditional tickets and user stories often miss the mark. Developers thrive on clarity. That’s why we include user context, detailed notes, and screen-recorded walkthroughs. These richer inputs reduce misunderstanding and improve speed and quality of delivery.
   
   
5. Design for Turnover, Not Against It:  Turnover is inevitable. Our system is built to withstand it. Modular work means a new developer can take over without starting from scratch. We also maintain a vetted pool of contributors, enabling us to match the right developer to the right module at the right time.
   
   
6. Track Everything, Share Progress Visibly:  Transparency is critical. We use tools that allow real-time tracking of every module: what’s in progress, what’s complete, and what’s stuck. This gives our team and our clients a shared view of progress and risk. When things go off course, we catch it early and adjust.

‍

A New Standard for Delivery

No system is foolproof. There are still challenges and trade-offs. But the transformation we have seen is undeniable. This modular system is one tool among many. Our broader practice remains context-driven, flexing to fit the unique dynamics of each project. At Assurdly, we believe in sharing what works. We are not protective about processes. We know that the challenges our teams face are not unique. Developer management is hard. However, it becomes manageable when you treat delivery as a system, rather than an event. Engineering management will always involve a degree of uncertainty. But when you design for that uncertainty, you do not just survive it. You build better software and stronger teams.