A research lab runs more things at once than you’d think.
There’s advanced research, there are government-funded projects, there are field demonstration sites out in the real world, there’s product development building something to sell, and behind that, preparation for mass production. That much is “our work.” Outside, there are industry trends, competitors’ moves, the regulations and certification standards that constrain our products, and a growing pile of patents. The problem is that all of this is scattered across different people’s heads and different files. Each piece had someone in charge of it, but no one saw the whole thing at a glance. So I decided to gather it onto one screen. Instead of picking up the pieces all over again every time we prepared for a meeting, a single status board that’s always on.
As I built it, the sidebar menu grew one item at a time, and at some point it looked like this.
- Eyes on the outside
- Industry trends · competitor comparison · relevant regulations. A zone made up entirely of other people’s bars. A lab that only looks inward gets blindsided from outside.
- Promises we’ve made
- Business plan · master schedule. A roadmap spanning several years fits on one page as horizontal bars.
- What’s happening now
- Project status · field pilot status · technology development · detailed design. Not the plan — today’s state.
- The organization’s memory
- Patent review · issue tracker · feedback. Mechanisms for not forgetting what we’ve been through.
The one that draws the most attention, naturally, is the master schedule. You can take in several years at a glance. But compression, the great virtue of a Gantt chart, comes at a price. Work of completely different kinds gets translated into the same grammar — start, finish, percent complete — and on screen, a field pilot’s bar and an advanced research bar end up looking exactly alike. Yet a pilot fails because “it doesn’t run as expected in the field,” research fails because “we spent two years digging and the direction was wrong,” and a product fails because “we built it and it didn’t sell.” The essay “Research is not engineering at a slower speed” puts its finger on exactly this: research, R&D, and product development are separate activities with different criteria for success.
A schedule is only a list of promises the lab has made to itself. The whole lab isn’t in it.
That’s also why field pilots have their own menu, separate from the schedule. What works in the lab and what works in the field are different sports. The field has things the lab doesn’t: seasons, the grid, operators, certification. You can’t read a pilot site’s status from a bar’s percent complete. You have to read it as “Is it running right now, or stopped, and why did it stop?” Product development is the same. Only when the design documents and the technology development status each have a place of their own can you see where things got stuck in the stretch where “the research worked, but no product came out.”
The issue tracker. There’s one thing you learn once you use it: issues don’t respect project boundaries. It’s common for the root of a problem that blew up in Project A to be the same as one in Project C. Same part, same supplier, same assumption. You’ll never see this in meetings split up by project, but pile all the issues in one place and you get, “Wait, aren’t these two the same problem?” The real function of a status board lies less in control than in chance discoveries like this. And the moment someone standing in front of the screen pointed at someone else’s bar and said, “We can’t start until this is done” — that was the most productive meeting I’ve ever seen.
This is a notebook of trial and error, so I’ll write down what didn’t work, too. At first I thought a schedule alone would make a status board. But a screen with nothing but a schedule soon becomes a tool for scolding. You end up reading every bar by a single metric: schedule adherence. By that metric, the research bars are chronically late, and so they get scolded chronically. Even though those bars were sentences that could never have been written in the grammar of a Gantt chart in the first place. Only once trends, pilots, issues, and feedback were attached alongside did the schedule step down to being one screen among many, and we started asking first, for each bar, “What does success look like for this work?”
Finally, I should talk about who fills this screen. With this many items, keeping it updated is labor in itself. Whether a file changed, how far a bar moved, how far an issue has gone. All of this tedious follow-up can be handed to AI, and in fact we do. But if you ask whether people can step out entirely, the answer is no. R&D is work where the moment the data and numbers are wrong, you have a problem, so the first review of anything that goes up on the screen is always done by a person. Judgments that could turn into big issues later — especially questions like “Does this patent infringe on us?” — must always get a second look from a person.
So we need criteria. Which updates can run automatically, and which judgments must be put in front of a person? Building the evaluation criteria and checklists to weigh this turned out to matter more than building the screen itself. We set the principle like this: anything high-priority, or anything that falls outside a feedback loop we’ve already built, a person goes in and checks. Everything else runs automatically once it’s been checked the first time. The more the earlier stages stabilize, the fewer places a person needs to stand, but the gate itself never goes away.
People stop filling the screen, and stay only to doubt it.
Putting everything on one page is a risky thing to do. Compression always erases something. Still, I think the opposite is riskier. An organization that has never once put everything on one page never really knows what it’s doing.
A researcher on a team that takes technology into mass production. Working where a handful of people weather a flood of requirements, I’m trying to set AI up not as a search tool but as hands and feet. I write more about what didn’t work than what did, and more about process than conclusions.