- If it’s shipped, that goes in the title (along with the launch post link).
- Who is the DRI? For the overall project, and for design.
- What are we doing and why are we doing it?
- What have we accomplished?
- What does “done” look like and where are we tracking what’s required to get there?
- When do we expect to be done?
- How are we doing relative to our expectations last time?
At the end of last year, I somehow found myself as the lead of a team that was 4x as big as my previous one. Many things were different, but one of the big ones was changing from having one person on each platform who really knew everything that was going on… to having some unknown set of projects with unknown combinations of people involved. My first task, then, was to figure out what our multi-month multi-engineer projects were, what had happened on them so far, and what we were aiming for – in terms of scope and time. And that is how I accidentally implemented deadlines. Which I think is an example of what can go wrong when you arrive in a culture where something that is core to you is not thought about. I asked “when do you think this will be done?” because it’s impossible to me to be involved in anything and not have thought about this. But, that wasn’t the culture of the team – some people hadn’t. I think a sense of time is important, but if I knew it wasn’t there, I wouldn’t accidentally implement deadlines – I would very deliberately encourage setting goals. Which is where we ended up… eventually. Aside from that small SNAFU, this became a useful enough process that we repeat it every other month as an internal post we call “The State of All the Things”. The timeframes in the first one were very wrong. The second one – also very wrong. But over time, they’ve gotten less wrong. They allow us to see how we’re doing relative to where we thought we would be. As we no longer do lone wolf projects (we theme work so that everyone can be part of a “team”), it captures closer to the work of the entire team. They also provide a helpful high-level insight into what the team is doing that it’s easier for people outside the team to process. One of the things I find in a company that focuses very much on written communication is that it’s easy to communicate an overwhelming volume of low-value information. Selectively communicating a smaller amount of high-value information goes a long way. If someone really wanted to find out the state of one of our projects, they could using other means – but this is where the high level summary is. It moves the bar on finding that information from “dedicated investigator” to “passive interest”. For each project we include: