Module 6 · Lesson 6.1

Choosing the interface and the structure it needs

Confirm the interface you will work on, and decide what structure it needs.

Lesson 1 of 4About 10 minutes

Key idea

Give your interface the structure that matches what it carries, not the most structure possible, and build it with the other side.

Your notes so far

Lessons 1.4 and 3.6

Only you can see these. They come from this device, and from your account if you are signed in.

See all my notes

Confirm the interface

Before you build anything, check that the interface you named is still the right one. A good choice for this exercise is:

Try it

Is it the right interface?

Think of the interface you named in lesson 1.4.

Important: when it goes wrong, it costs real time, money or client trust.Recurring: it comes up often enough that settling it once will pay back.Within reach: you are one of the two sides, or you lead one of them, so you can start the conversation yourself.Specific: it is one handoff between two named teams or people, not “communication with IT” in general.

Your readingTick each one that is true.

If your interface fails one of these, pick another before the next lesson. An important interface you can’t influence is better raised with whoever can. A trivial one isn’t worth the effort, as Module 3 showed.

Decide what structure it needs

Your note from lesson 3.6 says how this interface habitually works today and whether it is under-engineered, over-engineered or about right. The aim is not to push it to C6. It is to give it the level of structure that matches what it carries.

Try it

Which way does the work run?

Choose what your lesson 3.6 note said about the interface.

The next step	Add structure, as Harbourline did with its run-books: the four steps below.

Record the interface on both sides: a deliverable on the supplying team’s canvas, and an input on the receiving team’s canvas.
Specify the input: what exactly the receiving team needs, how, and when.
Agree an operational definition for the item that causes the most trouble, with an owner and a test.
Note in the parking lot anything that can’t be settled between the two teams.

If your interface is over-engineered, the work runs the other way: find the structure nobody can explain, and agree what can be dropped.

Build it with the other side

The canvas you build in the next lesson is a first draft, not an agreement. An input you specify alone is still one-sided. The value comes from the conversation with the other team, and you will plan that conversation in lesson 6.3.

So build the draft from your side as honestly as you can, and mark what you don’t know about the other side. That makes a better starting point for the conversation than a polished canvas presented as finished.

What you will need for lesson 6.2

About 45 minutes for lesson 6.2. Note the rest here, so it is ready when you open the canvas.

Pause and think · your notes

Gather what you will need for lesson 6.2.

1. The two teams, their leads, and the task on each side the interface belongs to

2. One or two recent examples of the interface going wrong

3. How often does it happen?

Your notes save automatically as you type.See all my notes

How Alex would answer

Build the draft from your side as honestly as you can, and mark what you don’t know about the other side. That is a better start for the conversation than a polished canvas presented as finished.

What to take away

Choose an interface that is important, recurring, within reach and specific.
Match the structure to what it carries: add it where under-engineered, remove it where over-engineered.
Your canvas is a first draft for a conversation, not an agreement.

Your progress

Back: Module 6 overview

Next: Build the canvas for your own interface

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.