Planning an Onsite Was Harder Than I Expected

Somebody had to plan our company onsite, and I said I would. The job, as I understood it, was to find out who was coming, decide where each team would sit and which meeting room they would use, and send the result around. I put it down as an admin task and expected it to take a few hours.

It took most of my week, and the schedule went through many more versions than I had imagined a seating plan could need. By the end, every team had a place to sit, every group that needed a room had one, and nobody was booked to be in two places at once.

Before sending it to everyone, I showed it to a few people. Their questions were all the same kind. Where do I look for my team? Which column is the afternoon? One person asked whether the room on the second tab was the same room as the one on the first. Nobody disputed a single decision in the plan. They could not work out how to read it.

So the plan was right, it had taken far longer than budgeted, and it still did not work.

Collecting headcounts was the easy part

The reason I filed it as admin was that the first steps really are trivial. Ask each team lead how many people are coming. Ask which teams want to meet together, and for how long. Collect the answers in a sheet. Every one of those steps is a message and a wait, and none of them asks anything of the person doing it beyond persistence. If a job is made of steps like that, what it costs is time, and time was the only thing I planned for.

That is also how coordination looks from the outside. Someone sends messages, someone chases replies, and eventually a document appears. The part that happens between the replies arriving and the document appearing leaves no trace, so it looks as if nothing happened there.

I planned for the messages. I did not plan for anything between them.

The meeting rooms did not fit

The headcounts came in quickly, and I sat down to place teams in the office. That was where the job changed shape.

The office had an open area and a handful of meeting rooms, and no meeting room could hold a team all day without locking everyone else out. So the rooms had to be shared, which meant each team needed a slot, which meant the day had to be cut into slots. That was the first constraint, and it was not in any of the answers I had collected. It appeared the moment I tried to give two teams the same room.

Then the second one. Some people belong to more than one team. If two of their teams were given the same slot, they would miss one of the sessions, so those slots could not overlap. That constraint came from looking at names, and only after the first constraint had already produced a draft with the overlap in it.

It went on like that. Each version of the plan surfaced a condition the previous version had violated, and I fixed it and found the next. I could not have listed these conditions at the start, because I did not know they existed until a draft broke against them. Nothing in the answers I had collected pointed at them. They came out of the act of arranging.

I did try handing everything I had collected to a model, on the theory that a plan is a document and models are good at documents. It gave me back a tidy version of what I had handed it. The constraints I needed were exactly what the pile did not contain, and I had nothing to give it until I had already done the arranging myself.

The finished table was correct and nobody could read it

By the last version, the plan was a table with every team and every hour of the onsite in it. Teams down the side, time across the top, rooms in the cells, and a second view for seating. That was the shape the problem demanded. To be sure no two teams shared a room in the same slot, I had to see every team and every slot at once. To keep a person out of two sessions, every session they were in needed to be visible at the same time. The table was global because the constraints were global, and each round of fixing had made it more complete.

Then I showed it to a few people, and that completeness was the problem.

None of them needed the onsite laid out end to end. Each of them needed a seat and a sequence of rooms, for one person, for one day. To find that in the table, they had to know which team I had put them under, find the row, read across the columns, translate the room codes, and switch to the seating view to do it again. Every column that made the table correct for me was one more thing they had to read past to find their own line.

I had been treating clarity as a matter of layout, as though the same table, tidied up, would be clear to them too. The table was already tidy. The trouble was that a shape built for satisfying every constraint at once is the wrong shape for someone who needs one answer. The better I had solved the first problem, the more thoroughly I had produced the second one.

A page that shows one person their day

Once I saw it that way, the fix was obvious, and it involved no further work on the table. I made a single page with a search box. Type your name, and it shows you where you are sitting and what your day looks like, in order, with the rooms named as they are named on the doors. Every constraint and every round of rearranging that produced those answers stayed out of it. Nobody needed to know that a slot had moved to keep one person out of two rooms. They needed to know which room to walk to.

The page is small and I built it in a sitting. What I had spent far longer on was arriving at the idea that the plan needed two forms at all: the table, for me, that holds the whole problem and proves it is solved, and the page, for everyone else, that shows one result and hides the proof. I had assumed one artifact could do both jobs, because for as long as I was making it, I was its only reader.

Most things I have written for myself have had that property, and Audience of One was about how much it simplifies. The author and the reader are the same person, so the form that is right for making the thing is also right for using it. A plan for a few dozen people breaks that in the most ordinary way possible. The person who needs the global view and the people who need one line are different people, and no amount of tidying makes one form serve both.

I have spent years reading design advice that says exactly this, that the interface should make sense on first sight instead of coming with instructions, and I had nodded along while assuming it was a discipline for people who build screens. It turned out to be a discipline for anyone who sends something to more than one reader. The table came with instructions. The page did not need any.

Why I underestimated it

Both halves of the job were hard, and both took far longer than I expected, and the second half took more. Now I think I can see why I had underestimated both of them in the same direction.

Neither half leaves anything visible. The constraints I worked out over many rounds exist only in the final table, and the table does not say which cells were hard. The page hides the table on purpose, so a person who opens it sees one line and closes it. The better either half is done, the less there is to see. A plan that came together easily and a plan that took a week of rearranging look identical once they are finished, and a page that everyone understands instantly looks like nothing at all.

So when I looked at this kind of work from the outside, and saw messages going back and forth and a document coming out the other end, I was seeing the only parts of it that leave a trace. Admin was the word I had for that residue. The word was accurate about what I could see, and it had nothing to say about the rest.

The next one gets a different first hour. Before any headcount comes in, I will ask the question I asked last this time: when one person opens this, what should they see?