Trade-offs: product teams vs project teams and funding model impacts
This tests funding impact on architecture. Contrast temporary project teams funded by scope versus product teams funded by problems; tie rolling budgets to ownership and refactoring. Red flag: claiming agile ceremonies fix org design while ignoring funding.
What's really being asked
Your grasp of organizational design and funding incentives. Interviewers want to know if you understand that how a team is funded and staffed shapes code quality, architectural decisions, and ownership more profoundly than process frameworks do. The question probes whether you can articulate why temporary project structures systematically undermine continuous improvement and what trade-offs durable product teams introduce.
The full answer
First, define project-mode versus product-mode clearly. Project-mode funds predefined scope through temporary build-only teams drawn from a fungible talent pool, and the team disbands after delivery. Product-mode funds a durable team on a rolling basis to own a persistent business problem through ideation, build, run, and iteration. Second, tie funding directly to technical health. Project funding incentivizes hitting scope and deadlines because the team will not live with the consequences, which erodes architectural integrity and discourages refactoring. Product funding makes the team responsible for running what they build, creating natural incentives for clean architecture, monitoring, and continuous improvement. Third, cite specific benefits from product-mode: knowledge retention because the same people maintain the system, reduced end-to-end cycle time due to accumulated domain familiarity, and the ability to pivot quickly when a solution is not working. Fourth, acknowledge the challenges. Product-mode can reduce staff utilization, create insularity, and spawn new silos if boundaries are drawn poorly.
The mistakes people make
Claiming that agile ceremonies or DevOps tooling alone solve the problem while ignoring the structural mismatch of temporary teams and long-term systems. Asserting that product-mode is universally superior without mentioning utilization concerns or silo risks. Confusing the funding model with team naming conventions, such as calling a project team a squad without changing how money or ownership flows.
What usually comes next
How would you transition a project-based IT organization to product-mode without disrupting delivery? How do you prevent product teams from becoming isolated silos? Where do platform or shared infrastructure teams fit in a product-mode model? How do you justify product-mode funding to finance stakeholders who demand a business case with projected benefits?
A concrete example
The retirement calculator from Sriram Narayan's article illustrates the difference. A project team would deliver the requested calculator features and disband, leaving another team to handle changes. A product-mode team owns the retirement savings problem continuously. If user data shows the calculator is not helping people save more, the team can iterate or pivot the solution entirely because they retain the knowledge and the funding is tied to solving the problem, not delivering a fixed scope.
Interview question
Why does scope-based funding for temporary project teams typically erode architectural integrity more than rolling budgets for durable product teams?
- a.Because rolling budgets provide more predictable capacity for scheduled refactoring sprints than fixed project timelines allow.
- b.Because durable product teams retain deep domain knowledge, which naturally produces cleaner architecture than rotating project staff.
- c.Because project teams are rewarded for delivering predefined scope by a deadline without remaining accountable for the long-term operational consequences.Correct
- d.Because temporary teams typically lack agile ceremonies and integrated DevOps tooling that enforce architectural standards.
Why? this is the answer
Project funding incentivizes teams to hit scope and deadlines because they disband afterward and never live with the consequences, which erodes architecture. Distractor A reflects the common misconception that agile ceremonies or tooling alone can fix organizational design without changing the underlying funding and ownership model.
Just read this? Test yourself on what you have been reading.
Read the original → martinfowler.com
- #agile
- #org-design
- #team-topologies
- #funding
- #architecture
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles