Coming Up to Speed

Teams working on projects generate a lot of information. Product directions, sketches, interviews with potential customers, roadmaps, schedules, competitive research, you name it… Team members have folders full of stuff, sometimes distributed in various computers. Some teams may keep it a shared folder, but even then there’s often a variety of files and formats to contend with. The faster the team moves, the less structured its information is. If you’re brought into the team as a new contributor, coming up to speed may be a challenge.

A few years ago I started work with a team on a new project. When I was “onboarding,” I was given a photograph of a wall covered in sticky notes. “That’s the project,” one of the people on the project told me. And then he left me to my own devices. There was some sense I could glean from the sticky notes; they’d been at least clustered into groups. But there were many gaps in my knowledge. Eventually, another team member met with me to explain what I was looking at, and I got the gist of what was happening with the project. But even then, it took a while for me to get a sense for what was happening and how the team was working. That was a very loosely documented project, one which relied more on relationships more than on explicitly articulated information.

I’ve also experienced the opposite: coming into a project in mid-stream to find highly structured, coherent descriptions of what was going on. The team had thought through — and captured in a shareable document — their objectives, target audiences, schedules, features, competitors, etc. There was a lot of information to process, but it was all there; I could go through it at my own pace. Although it required a bit more work on my end to go through all the documentation, onboarding into this team was easier than with the one that only had a photo of stickies on a wall.

You’d expect that more information is always better than less. However, it wasn’t immediately clear that this was a preferable way of going about things: some of the ideas in the highly structured document set were already outdated. That’s to expectable; the team adds the most value when they’re working on the product, not maintaining documentation about the project. Also, teams run the risk of developing some degree of inertia when they commit in writing to certain decisions. The fact that it’s in writing makes it more “official.” In this particular case, I felt the team had gone overboard in documenting what they were doing.

So there are two extremes here: very loose, with very little structure and upfront effort on one end, and highly structured, comprehensive documents on the other. Both extremes have benefits and tradeoffs. But there’s a middle ground: one where the process of doing the work itself creates the necessary documentation to bring new people into the fold. I’ve experienced this too: projects in which a brief conversation to review the team’s working documents gives you enough context to start contributing right away. This approach requires a bit of upfront planning, but it’s more effective than either of the extremes.