In our development department we’re currently working with two teams to build a new product. The platform team – as you might be able to guess – is working on the platform, the framework or architecture, however you want to call it. The other team, the one I am in, is working on the features, building on what the platform team provides us with.
Splitting responsibilities the way we do makes perfect sense. We do have those gray areas where it’s not that clear whether something belongs to platform or might be a feature, but in most cases it is pretty clear what task belongs in what team.
There’s one downside though, and that is that because each team is working on its own tasks, communication sometimes has to be pushed a little to happen. Although we’re not working on the same tasks, we’re still working on the same product and even if I can’t interfere with how the other team is doing their job, it’s interesting for me to know what they’re doing and why they’re doing it.
I want to compare that to my old version of Tetris on Nintendo’s GameBoy (yes, the very, very old one) where on one side of the screen the next tile to come would be displayed. I distinctly remember that I deactivated that option, thinking that it wouldn’t change my game. I didn’t think that I even bothered to glance at that tile.
So, I did turn it off and… oh my god… I got so much worse! Without realizing it, I always noticed the next tile and some part of my brain clicked and made me integrate that information in my gameplay.
Why the comparison? I think that sharing information between teams works the same way. When I know what the other team does, what they’re currently working on, what they plan to deliver and when they plan to deliver it, I can take that knowledge and have it in the back of my mind while I go about my own tasks.
Knowing what another team does might not directly affect my work. I think this is also one of the main reasons why communication between teams may be lacking a bit: Since our work is not directly affected, information about what happens outside of our little feature realm seems like a nice-to-know thing. I don’t necessarily need it and it probably doesn’t change how I should go about implementing my feature right now.
Nor do I have the power to do anything about it if I don’t like it. Whatever the other team is working on will sooner or later pop up in my code anyway. As long as I don’t have a say in that matter, why would I want to know any details? (I might be able to mention my concerns and ideas, though. So that’s a plus as well.)
However, developing with new tools and technology brings enough surprises as it is. Eliminating what other surprises – even little ones – there might be as best as I can means that I can work more comfortably and confidently on my own tasks. It gets me out of the little vacuum of my team and reminds me that there is a world outside of the feature set currently implemented. And whatever happens in the future I might at least have heard of it before.