Module 3 · Lesson 3.3

Under-engineered and over-engineered

Why more structure is not better, and how to tell when an interface has too little or too much.

Lesson 3 of 6About 8 minutes

Key idea

Maturity is not distance towards C6. It is whether each interface has the structure that matches what it carries, moved deliberately when that changes.

In this lesson

  • Why C6 is not the goal
  • The signs of an under-engineered interface
  • The signs of an over-engineered one
  • Two questions for any interface

More is not better

It is tempting to treat the continuum as a ladder and C6 as the goal. It isn’t. Each stage costs more effort to build and maintain than the one before. Spending that effort where it isn’t needed is waste, just as failing to spend it where it is needed is risk.

What indicates maturity is not how far towards C6 an organisation sits. It is whether each interface has the level of structure that matches what it carries.

Under-engineered

An interface is under-engineered when it is important and recurring, but still runs at simple information exchange. It is carrying more weight than an ad hoc arrangement can reliably bear.

At Harbourline, the release notes from the Kraków Salesforce practice to the Pune Service Desk are under-engineered. Every release changes what Northlight Financial’s 3,000 service-desk users see, and releases happen every month. Yet the information travels by email, when someone remembers, and the Service Desk rates what it receives at about 40% of what it needs.

The signs of an under-engineered interface are familiar:

  • Recurring surprises at the same handoff.
  • People keeping private lists of who to ring.
  • Work that depends on one or two individuals staying in place.
  • Problems raised repeatedly without being resolved.

Over-engineered

An interface is over-engineered when trivial or one-off interactions have been given a designed, maintained arrangement they don’t need.

Imagine Harbourline gave every routine password-reset request a formal agreement: a canvas entry, a negotiated definition of “reset complete”, and a quarterly review between the Service Desk and the client. Password resets are frequent, but each one is simple, low-risk and already handled perfectly well by the Service Desk’s standard process. All that structure would cost time and add nothing.

The signs of an over-engineered interface are just as recognisable:

  • Forms, sign-offs and reviews that nobody can explain the purpose of.
  • Simple requests taking longer than the work itself.
  • People routing around the official process because it is slower than asking directly.

Try it

Under, over or about right?

Judge each Harbourline arrangement. Then check.

Release notes from Kraków reach the Pune Service Desk by email, when someone remembers. Releases go out every month.

Important and recurring, yet it runs as simple information exchange. The Service Desk rates what it receives at about 40% of what it needs.

Imagine every password-reset request had a canvas entry, a negotiated definition of “reset complete” and a quarterly review.

Frequent, but each reset is simple, low-risk and already handled well by the Service Desk’s standard process.

Run-books for each new service pass from Service Transition to Pune under “Run-book ready for go-live”, signed off by the Service Desk.

Important and recurring, and designed to match. Making it more elaborate would add cost, not value.

A colleague in another office is asked by message to cover one meeting next week.

It happens once and little rides on it. A conversation is the right level.

Matching, and moving

The skill is matching the level of structure to what the interface carries, and moving it deliberately when what it carries changes.

A low-volume interface can become important when a new client, service or system arrives. An interface that once needed close coordination can become routine once it is well understood. Neither should stay where it is out of habit.

Try it

Two questions for any interface

Think of an interface and answer both questions.

1. Is it important? If it goes wrong, does it cost real time, money or client trust?

2. Is it recurring? Does it come up often enough that settling it once would pay back?

What it deservesAnswer both questions.

Pause and think · your notes

Pick one interface in your own work and judge it against the two questions.

1. Which interface?
2. Is it under-engineered, over-engineered or about right?
3. Which sign convinces you most?
Your notes save automatically as you type.See all my notes
How Alex would answer

If you chose an under-engineered interface, it is a strong candidate for the one you will work on in Module 6. Over-engineered ones are worth raising too: removing structure nobody needs frees time for the interfaces that do.

What to take away

  • Under-engineered: important and recurring, but running on simple information exchange.
  • Over-engineered: trivial or one-off, but given structure it doesn’t need.
  • Ask two questions: is it important, and is it recurring? Revisit the answers when circumstances change.

Your progress

Course contents · This is the open version of the course. Your notes, progress and check scores are saved on this device, and in your account when you are signed in.