Unmaking Boxes: How Technical Teams Can Protect Structure Without Killing Innovation

Engineering organisations need boxes.

We divide work into disciplines, subsystems, departments and levels of responsibility. We define interfaces, assign owners and establish design boundaries. Without this structure, developing an aircraft, spacecraft, software platform or safety-critical system would quickly become unmanageable.

But boxes create a risk: we may begin treating people as if they are identical to the roles assigned to them.

The controls engineer becomes “the controls person.” The verification engineer is invited only when testing begins. The junior engineer is expected to execute rather than question. The manager is assumed to have the best answer.

In a recent MoloMolo Tech Talk conversation with Veronica Lewis, founder of Unmaking Boxes, we explored how these invisible boundaries affect creativity, collaboration and technical decision-making.

The lesson is not that engineering teams should eliminate structure. It is that they must distinguish between a useful system boundary and a limiting human label.

A role is an allocation, not a complete description

In systems engineering, functions are allocated to logical or physical components. This allocation establishes responsibility, but it does not mean the component exists independently of the wider system.

The same principle applies to people.

A job description allocates responsibilities. It should not define the full capability of the person occupying the role. When organisations confuse allocation with identity, familiar behaviours emerge:

• “That is not my subsystem.”

• “Verification will deal with it later.”

• “Only the architect can challenge the architecture.”

• “They are too junior to understand the wider problem.”

• “I should not speak until I have the complete solution.”

These assumptions create organisational interfaces that are far more rigid than the technical architecture requires. Important information remains trapped within disciplines. Problems are discovered late, and engineers hesitate to raise weak signals because they fall outside their perceived authority.

Technical leaders should therefore examine not only the formal architecture of work, but also its informal boundaries: Who is allowed to ask questions? Who can challenge an assumption? Where does information stop?

Create sandboxes, not boundaryless systems

“Unmaking boxes” does not mean allowing everyone to change everything.

In safety-critical development, uncontrolled creativity can become dangerous. Requirements, configuration control, independence and design authority exist for good reasons. An engineer working beyond agreed parameters can introduce hidden dependencies or invalidate safety evidence.

The practical alternative is a sandbox: a controlled environment in which people can experiment without modifying the operational baseline.

A sandbox could be:

• A simulation branch for testing an alternative control strategy.

• A digital twin used to explore abnormal operating conditions.

• A prototype workflow outside the production environment.

• A time-boxed architecture challenge involving several disciplines.

• A pre-mortem in which engineers identify how the proposed design could fail.

  
  

A good sandbox has four elements: a clear question, known constraints, rapid feedback and no uncontrolled path into production.

This gives teams freedom within defined limits. It also exposes emergent behaviour. A small experimental change may reveal an interface dependency, an incorrect assumption or a capability within the team that was previously invisible.

Build confidence through small technical wins

Complex systems are fertile ground for imposter syndrome. No individual understands the complete system, yet technical cultures often reward people who appear certain.

The result is a destructive loop: uncertainty produces silence; silence reduces participation; reduced participation prevents learning; and the lack of learning reinforces uncertainty.

One way to interrupt this loop is to treat competence as a verb rather than a label.

Instead of asking, “Am I really a systems architect?”, ask, “What architectural problem can I help clarify today?”

Teams can support this through small, observable assignments:

1. Select a bounded problem with a clear outcome.

2. Give one person ownership, with access to appropriate support.

3. Review the reasoning—not only the result.

4. Record what was learned and where it affects the wider system.

5. Increase the scope of the next assignment.

Low-hanging fruit is still fruit. A sequence of small technical wins creates evidence of capability. Over time, engineers become more willing to approach ambiguous and cross-disciplinary problems.

Use AI to challenge boxes, not reinforce them

AI introduces another invisible box. People may be classified by how quickly they adopt it, how efficiently they prompt it or how much knowledge they appear to possess with its support.

But the greater risk is confirmation bias.

AI can help us polish an existing assumption until it sounds convincing. It can also challenge that assumption—but only if we deliberately ask it to.

For technical work, prompts should include requests such as:

• What assumptions am I treating as facts?

• Which stakeholders or disciplines are missing?

• Under what operating conditions would this recommendation fail?

• What evidence would contradict this conclusion?

• Which interface effects have I ignored?

• Separate verified information, inference and uncertainty.

AI output should then be checked against models, requirements, test evidence and experienced human judgement. It is a thinking aid, not design authority.

The more we use AI, the more deliberately we must develop self-awareness. Otherwise, we risk automating our existing mental models—including the limiting ones.

A practical question for your next review

At your next design, planning or problem-solving meeting, ask: Which boundaries are necessary for safety and accountability, and which exist only because we have stopped questioning them?

Strong technical organisations do not remove every box. They make boundaries visible, test whether they remain useful and create safe spaces for people to work beyond the labels assigned to them.

That is how structure becomes an enabler of innovation rather than its constraint.