ustwo is all about building products. A few years ago we realised that one of the things that would make us better at it would be sitting whole teams together. No more designers over there, developers over here, project managers on the other floor.
We moved everyone around and started sitting people by project instead. Everyone together at the same table: UI, UX, dev, QA, project manager… a whole functional team. This enabled a much richer set of interactions amongst team members, from knowledge sharing to team building (piss taking). When you walk by one of the product tables or rooms it looks like someone’s brain has exploded all over the walls. It’s funny because it looks like a total mess from the outside, but makes perfect sense for the people involved.
Anyway. The content on those walls didn’t get there on its own, it’s a team effort: sketching sessions, quick explanations, roadmaps, inspiration boards… where am I getting at? Producing that content took time… and the time spent collaborating is time spent away from the keyboard.
You might not notice it at the beginning, but over time you start feeling like you are not being productive, that you are spending a lot of time in meetings, “distracted”, it’s difficult to focus. There seems to always be a meeting coming, or a hangout with the client… it’s hard to get a few solid hours coding.
This bit from the Lean Startup book nails it:
”As was indicated earlier, functional specialists are accustomed to measuring their efficiency by looking at the proportion of time they are busy doing their work. A programmer expects to be coding all day long […] the constant interruption of meetings, cross-functional handoffs, and explanations […] all act as a drag on efficiency. However, the individual efficiency of these specialists is not the goal. Instead, we want to force teams to work cross-functionally to achieve validated learning. Many of the techniques for doing this —actionable metrics, continuous deployment, and the overall Build- Measure-Learn feedback loop— necessarily cause teams to suboptimize for their individual functions. It does not matter how fast we can build. It does not matter how fast we can measure. What matters is how fast we can get through the entire loop.”
There you have it, product teams must optimise for team’s performance, not each individual’s performance. And if you think performing individually leads to group performance you would be… incomplete:
Embedded content: https://www.youtube.com/watch?time_continue=37&v=2d_dtTZQyUM
But even when you know the theory and you see it coming dealing with it is harder than someone might think. I clearly remember one project that after a week of collaboration I was so literally desperate to code that when I was back home I would find anything to code. Anything! Why? It feels good. Doing what you are good at feels good. And we’ve been trained all our lives to measure ourselves based on the amount of things we produce, but collaboration and learning are very hard to measure. Yet extremely valuable for product teams.
Please note that the irony of assuming that collaborating is better than not collaborating is not lost on us. What’s wrong with coding heads down, headphones on? Put like that, obviously nothing, we all need quality time to do our thing. It’s more about the mindset, but we’ll tackle that in a future post.