Engineering Org Structures— The QRF Team Model | by Joseph Gefroh | Feb, 2022

The reason QRF works is that the other commonly adopted “agile” approaches have fundamental drawbacks that limit their effectiveness in certain cases.

These approaches include:

  • Working only on the valuable items
  • Putting it in the next sprint
  • Setting aside a set capacity/timebox per sprint

What will win a prioritization argument:

  • Setting up a user account
  • An idea that can generate $1,000,000,000

The next billion-dollar idea will always win any prioritization argument, because it’s an unknown, idealized, easily manipulated projection. However, focusing exclusively on innovating with new product ideas means your current customers are not being served.

This is the delta between innovation and operation: you need both to thrive in the market, but most product prioritization arguments devalue operations. Few product managers want to work on an incrementally valuable item when the option is an exponentially valuable one.

This means the incremental things: internal tooling, bug fixes, automation, tech debt, etc. all fail to be prioritized when viewed exclusively from the lens of “value”. This is because they often have some known, smaller quantifiable value, and these pale in comparison to the idealized unverified projections.

At the end of the day, prioritization is an art, not a science, no matter how many structured frameworks we use.

Some teams try to solve this problem by sticking rigidly to the sprint commitment. Whenever an interruption request comes in, they say “we’ve already planned this sprint, so we’ll put it in the next sprint”.

Unfortunately, by the time the next sprint comes along, there’s an additional 15 items in the backlog, all needing to get done.

Rinse and repeat until there’s a large list of items, most of which never end up being completed. The team starts being viewed as inflexible by customers, others in the company, and by executive sponsors.

Why does this approach fail?
The approach assumes that things can wait until the sprint is over.

The truth is, some things can’t wait. Compliance demands, a new employee onboarding, a large customer’s tiny configuration change — these are activity-generated work that just needs to get done with some sort of time-sensitive cadence.

Not fulfilling these requests within a short amount of time can cause reputation damage or operational risks.

Another approach teams take is to dedicate a certain amount of time, such as 10% of a sprint, or a single day a week, to solve these issues.

Why does this approach fail?
For low-volume interruptions, it works, but for organizations with a high volume of interruptions, it doesn’t — the rate of intake just gets too overwhelming.

Additionally, by making it a “10%” thing, it causes a belief that the work is unimportant and a distraction. This means engineers aren’t as motivated to complete it, which results in a certain level of ineffectiveness when executing on these tasks.

There’s also an implicit assumption that you can actually get enough of the items done within that time-box.

In many circumstances, you won’t, and then you’re back at square one.

The real problem here is that the team is operating at a tempo that is slower than the environment demands.

If you get five urgent requests every day, but you only pick up new work every 2 weeks, that means customers can potentially wait up to 4 weeks just to get something resolved. In the startup world, 4 weeks can be an unacceptably long time. That assumes it manages to find prioritization against the planned roadmap (which is often not the case).

This ultimately causes things to pile up, customers to get unhappy: “Why does it take a week to set up a single configuration?” Perception is impacted negatively.

This is why the QRF solution works well — it forces an operation at a faster tempo.

Leave a Comment