Today
42m 33s
In this BONUS episode, we explore the critical differences between building software as a consultant versus inside a product company. Jakob Wolman contributed an insightful article to the Global Agile Summit book examining how third-party software development operates under entirely different constraints than in-house product development. Joined by Wilko Nienhaus, CTO of Vaimo, a consulting company in Estonia, we dive into ownership dynamics, misaligned incentives, contracting challenges, and the business pressures that shape consulting—along with practical stories from the field about what really works.
"I come back to the office from this workshop, and suddenly, with these eyes on looking for improvements in process, I just suddenly am hit by this revelation of why things are so slow here? Why are we working so inefficiently?"
Jakob describes the striking paradox many consultancies face: they excel at helping clients improve their processes while their own internal operations remain inefficient. This "shoemaker's children" phenomenon reflects a fundamental challenge in consulting—the difficulty of investing in your own improvements when all energy flows toward billable client work. Digital agencies often have outdated or poorly implemented websites despite building sophisticated solutions for others, illustrating how consultancies struggle to apply their own expertise internally.
"It's almost as if the clients are actually paying us to be slow, because our incentive is to spend more time on achieving what the client wants, because we get paid by the hour."
The incentive structures in consulting create inherent conflicts that don't exist in product companies. Consultants typically bill by the hour, creating a perverse incentive to spend more time rather than deliver efficiently. Meanwhile, clients pursue business outcomes and want results as quickly and cheaply as possible. This fundamental misalignment leads to:
Clients adopting a procurement mindset, treating software development like ordering from a catalog
A "wall" between stakeholders and development teams that's even stronger than in product companies
Antagonistic relationships where scope changes feel like financial traps rather than necessary learning
Contracting processes that reinforce waterfall thinking even when both parties claim to want agility
Wilko emphasizes that contracting has a huge impact on these dynamics, and companies must deliberately change their engagement models to break free from these patterns.
"Because of this budgeting process where you now need to motivate what this budget does, or you need to spend that budget, you essentially create this necessity to define everything."
Consulting projects often suffer from the same problem that plagued waterfall development: annual budgeting cycles that force stakeholders to cram everything into a single specification. When there's only one chance per year to secure funding, everyone stuffs the requirements document with every conceivable feature, leading to:
Massive specifications that attempt to predict all needs upfront
Endless discovery meetings and documentation that add cost without improving outcomes
Developers working from outdated assumptions with delayed feedback
Clients who don't really know what they want but feel pressured to specify everything
Jakob points out the frustration that "we've already fixed this problem" in product development through iterative approaches, yet it keeps reappearing in consulting because of the separation between entities.
"Skilled engineers will be frustrated if they're not allowed to do a proper job. People that have spent a lot of time in an environment where they're never allowed to do a proper job, or maybe even punished for doing a proper job, they will have given up, and not care."
The difference in ownership between product and consulting development profoundly affects how engineers think about quality, technical debt, and long-term design. In product companies, developers know they'll maintain their code, creating natural incentives for quality. In consulting, the transient nature of engagements can erode quality standards.
Key challenges include:
Engineers knowing they won't return to the codebase, reducing long-term thinking
Clients who lack technical expertise dictating approaches they don't understand
Pressure to complete fixed-scope contracts regardless of quality trade-offs
The role of estimates in forcing teams to "just complete this thing" even when learning suggests changes
Wilko notes that teams controlled by clients versus teams managed as stable units by the consultancy show markedly different levels of ownership and engagement. Engineers want to do great work, but without real-world feedback loops, they may either overengineer based on theoretical ideals or give up on quality entirely.
"We said to them, what if we try to actually go live in a single sprint, which in most companies is 2 weeks. And they were like, nah, we're not so sure. And we said, don't worry, you're going to get everything you want in your scope by the end. But just let's try these first 2 weeks."
Wilko shares a transformative story about an e-commerce project where his team convinced a client to abandon their two-year roadmap and instead focus on going live with something—anything—in two weeks. The goal: enable one existing customer to place one order for one product they already knew.
This constraint forced radical prioritization. The team didn't need images, extensive product catalogs, or elaborate descriptions. They delivered a minimal but functioning system, and the results were revelatory:
The client's internal discussion shifted from "we need everything" to "what should we prioritize next?"
Real customer interaction revealed unexpected problems, like internal incentive conflicts where salespeople wouldn't direct customers to the website because it threatened their commissions
Senior leadership embraced the iterative approach more readily than middle management
The faster feedback cycle enabled genuine agility even in a consulting context
This story demonstrates that iterative approaches are more likely to lead to success in consulting, and that senior leadership is often more receptive to faster feedback cycles than people expect. The key is changing the dynamic from "deliver a complete spec" to "let's go live quickly and learn."
"The groundbreaking thing that's happening right now is AI, and it really feeds into this direction. Because instead of speaking, you can actually be building, you can see things, you can do stuff that you can really test in a much more real way than you could just a few years ago."
Both Jakob and Wilko see artificial intelligence as a potential solution to many consulting challenges. AI tools enable rapid prototyping and visualization, allowing teams to show rather than tell. This addresses the fundamental problem that clients don't know what they want until they see it, by dramatically reducing the cost of creating tangible demonstrations that generate meaningful feedback.
If you want to know more about how AI is reshaping programming, check out our AI Assisted Coding series of episodes.
"I just simply think it shouldn't be a choice. We have to be very firm on this is how we work. We are the experts you are paying us."
When clients ask to skip testing, reduce code reviews, or cut corners on infrastructure, Jakob argues consultancies must stand firm. Quality practices shouldn't be line items that clients can negotiate away. One consulting company that works strictly with Extreme Programming principles demonstrates this approach—they don't explain every detail to clients, but they clearly establish that "this is how we do all our projects. It's not a choice."
Wilko adds that testing often saves time rather than adding cost, serving as a development tool that eliminates repetitive manual verification. The challenge comes during estimation, where padding for testing can make consultancies less competitive, creating pressure to compromise on quality.
Jakob emphasizes that some responsibility lies with consultancies themselves, which sometimes over-promise and underbid to win business, then struggle to deliver quality within unrealistic constraints. This "race to the bottom" hurts the entire industry.
"It is fixable in a consultancy setting as well. I've seen it. I've been part of it. But you have to be very deliberate in your collaboration with the customer."
Success in consulting requires deliberately designing the engagement model to support iterative development:
Working backward from customer needs, not forward from specifications
Establishing short feedback loops with both client stakeholders and end users
Creating stable teams rather than assembling ad-hoc groups based on client requests
Changing contracting models to align incentives (as explored in Sven Ditz's article in the Global Agile Summit book on delivering incrementally)
Being firm about quality practices while remaining flexible about features
Using AI and rapid prototyping to generate early, concrete feedback
The consulting model doesn't have to default to waterfall, but it requires conscious effort to overcome the structural forces pushing in that direction.
In this episode, we refer to multiple resources for further reading. Here’s a list of those resources:
About Jakob Wolman and Wilko Nienhaus
Jakob Wolman is an experienced engineering leader who knows how to build great software, and how to mess it up. He has worked in both product companies and consulting environments, giving him unique insight into the contrasts between these models.
You can connect with Jakob Wolman on LinkedIn.
Wilko Nienhaus is CTO of Vaimo, a consulting company in Estonia, where he focuses on the challenges of delivering software in a consulting environment. He concentrates on delivery mechanisms and technical solutions for challenging projects.
You can connect with Wilko Nienhaus on LinkedIn.