Who owns the space between design intent and built reality?

04 May 2026

Matthias writes about design and engineering as one, (it's a great read) and how in 1898, Frederick Winslow Taylor's answer to inefficiency was to separate the work that people did. Those who did the work would be separate from those who decided how it should be done.

His solution was to separate thinking from doing, cleanly and completely. Management would plan the work – the optimal method, the optimal pace, the correct tool for each task. Workers would execute it. He called it scientific management, and over the following decades, it became the template for how industrial organisations structured almost everything they did. — Matthias Ott

He then compared it to Gropius, who advocated for the opposite, where everyone is expected to get involved and know the material.

He mentions how the designer and engineer see things differently.

  • A designer looks at a screen and sees composition, hierarchy, and intention...
  • An engineer looks at the same screen and sees structure, state, logic, and constraints...

It's interesting, but I personally struggle with the focus on design + engineer. It feels like it misses out too many people and roles and that this has been the story of my life where design + engineering get all the attention and other roles get pushed to the side.

  • A quality engineer looks at the screens for problems, risks and interesting pathways
  • An engineering manager looks at the screen and thinks about the people and constraints
  • A customer support representative looks at the screen and thinks about the lack of documentation problems users will raise
  • A security engineer will look at the screens and think worse case scenario
  • A community builder will look at the screen and explore that it means for the business, customer and ecosystem

Where it feels like the world is heading is one of increased collaboration, less hierarchy, one where all the people are responsible. The tech world feels far too complex to have the Gropius angle that expects everyone to know how to ship all the parts. And hopefully, Taylor's way of separating doing and deciding will increasingly become a thing of the past. 

There is the suggestion that a 'design engineer' is best suited to be able to see things from different lenses. I'm not convinced. We do need to be more interdisciplinary, which is what the (I believe) 'design engineer' role is being suggested as. But expecting people to spread themselves thin still feels unreasonable to me. Our human value is our knowledge, experience and the ability to make decisions. The cognitive load of being able to build and design for all the possibilities becomes too hard for just onerole.

Going back to one of the questions Matthias poses:

Who owns the space between design intent and built reality? I wanted to scream QUALITY ENGINEERS! 

But really, that's falling into a trap of seeing ourselves as the solution. The reality is it is the glue work and the system we build. Quality Engineers do a ton of it, perhaps more than most. But so do product people. Engineering managers. Customer support. Community. And marketing. We all get stuck in. All perspectives matter.

If I were to take a bit of a community perspective, I'd be tempted to say it is conversations that owns the space between design and built reality. We have to ensure we gather, converse, explore and decide. Who has the conversations, will depend, yup, on the context.

Conversations are the friction we need.
Conversations are guardrails.
Conversations are quality in the loop.
Conversations create understanding.
Conversations create the helpful friction we need.

We're all figuring out how to exist in this world. Roles are important. But conversations are more so.

Rosie Sherry
CEO & Founder at Ministry of Testing
She/Her

I've been working in the software testing and quality engineering space since the year 2000 whilst also combining it with my love for education and community. It turns out quality, community and education go nicely hand in hand.

🎓 MoT-STEC qualified

Team Account Member
MoTaverse Team
Chapter Lead
Sign in to comment
Explore MoT
AI Builders Workshop: A smart way to run AI-driven QA image
AI in QA shouldn’t mean more work to manage. Join us for this hands-on workshop where we show how to maximize the AI capabilities in QMetry and Reflect.
Introduction to Software Development and Testing image
Start your journey into software development and testing by learning what it's all about
This Week in Quality image
Debrief the week in Quality via a community radio show hosted by Simon Tomes and members of the community
Subscribe to our newsletter