Member-only story
Engineering Org Structures— The QRF Team Model
Take control of engineering team interruptions and prevent them from happening ever again
As an engineering leader, I’ve found many products and engineering teams at startups struggle with being agile.
The shortcuts the startup took early on getting to the point where they could grow had benefits, but also costs. At some point, enough technical, capability, knowledge, and organizational debt has been created such that there is a constant stream of bugs, internal asks, interruptions that only the engineering team can handle.
These ask come in at a rapid pace, sometimes several days, greatly disrupting the work of an engineer. Even if each interruption only takes a few minutes, the context switch alone can destroy any hope of productivity for that afternoon.
How can an organization handle these in a way that makes sense?
Enter the QRF Team
The QRF model works incredibly well in certain contexts without the negative drawbacks of other approaches.
What is it?
You split your engineering organizational unit into two discrete, independent teams:
- Team 1, designated as the Main Effort
- Team 2, designated as the QRF
Team 1’s charter is simple: build what’s on the roadmap. They act as a typical product development team does, working on high-value, high-priority items at a road mapped, predictable tempo, using whatever framework or methodology is appropriate — eg. Scrum or Kanban.
In short — they work on the main effort of the company.
Team 2’s mission is to tackle any item that would cause an interruption to Team 1. They act as the QRF, the Quick Reaction Force, to jump in front of any problems that would otherwise interrupt the sprint. In short — they prevent interruptions and act as a supporting effort.
QRF solves problems found in other approaches
The reason QRF works is that the other commonly adopted “agile” approaches have fundamental drawbacks that limit their effectiveness in certain cases.
