How Seating Plans Can Kickstart — Or Hold Back — Product Development
When we’re building products we often overlook how simple, day-to-day details like where we sit can help or hinder development. Here’s how to structure your team’s seating plan for the best results.
By Alexander Grosse, VP of Engineering at BCG Digital Ventures
Whenever I visit another office, I pay attention to where people sit. Sometimes I’ll ask where teams are placed in relation to one another, where the backend team are, who’s working on what and other questions. It might seem strange, but there’s a good reason for this: By seeing where people sit, I can start to get an idea of how they work.
There are a few warning signs that are easy to spot. If teams are split between floors, siloed off from one another, that’s a red flag. Teams that sit together based on their job function rather than what they’re building? Another red flag.
It might seem like a basic or unimportant factor, but choosing where teams sit has a great effect on how they collaborate, how versatile and creative they are and how well they are able to build what they’ve been briefed.
According to Conway’s Law, “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” Seating plans greatly affect team communication structures, and when you’re building software, the end product will mirror the manner in which it’s been built. A product produced by a strained or siloed communication system will reflect these issues. A seating plan that encourages efficient and cohesive communication should lead to a development process that reflects these values.
I want to give you an idea of what I’ve learned about encouraging better and more efficient product development through optimizing seating plans. The right seating plan can enable teams to build better products at a greater speed; a bad seating plan can lead to substandard products and slower development.
It’s About Space
Often when startups get going they move incredibly fast before growing to a stage where progress slows down. This is to be expected: When you have more people interacting, more organization is required and development time therefore increases. The trick is to minimize this problem by making sure people are located in the right place in relation to one another.
When mapping how the development process works on a team level, it’s useful to use value stream diagrams for visualization. This value stream illustrates a standard development process from ideation to deployment when teams work independently and are organized by function rather than business goal:
As you can see, there’s a lot of lag time between teams. The reason for this is the time it takes for teams to communicate with one another:
Feedback cycles grow as the team gets larger, and friction slows things down.
When you start a company or project and have just a few employees it’s possible for you to all sit together in the same room, which means you can talk to one another, explaining exactly what you need and quickly exchanging ideas across disciplines.
As companies grow, they often sacrifice this advantage. Development happens through a series of tickets, and product managers and developers sit in separate rooms or even floors, isolated from one another. Teams are split by function, with product teams in one place and engineering teams in another. Progress slows down, tickets are slightly misunderstood or not adequately explained and accountability slides. Creativity also suffers, as the development process becomes a mechanized, non-collaborative cycle of brief, build, deploy, repeat.
Work like this and you’ll still manage to build products, but it will take you a long time, you’ll miss out on the creativity of close collaboration and it’s likely the product you end up with won’t be what you’d hoped.
Luckily, there’s a way around this issue.
Create ‘Delivery Teams’ Arranged by Focus, Avoid Silos
Imagine you’re an iOS developer starting at a new company. The company isn’t a brand-new startup, but it is relatively small, and you’ll be the second iOS developer in the team. Where should you sit?
It would be natural for you to go and sit with the only other iOS developer. But a better choice would be to sit with those working on the same feature as you, regardless of their role. By doing this, you can build smaller elements faster. You can work with a product manager, an Android developer and a backend engineer and get a comprehensive version of a single feature out far quicker than you would if you were sitting with someone doing the same role as you, siloed off from the other functions and communicating through tickets. The proximity of teams should be dictated by business role rather than specialism. We might call teams organized in this way as ‘delivery teams’.
This diagram illustrates how to move from teams of specialists to delivery teams. If you imagine that each team sits in one room or on one floor and that all communication between teams therefore happens through tools and tickets, you start to see why seating plays such an important role in optimizing productivity.
Seating teams together by delivery goal leads to a more lightweight process and helps them deliver faster. As a rule of thumb, delivery teams are truly self-sufficient if they can deliver the vast majority (~95%) of their backlog items to production without depending on other teams. This 95% can happen quickly, free of dependency and supported by the close proximity of the team to one another. They can simply take off their headphones and ask questions, getting a resolution to issues in seconds rather than assigning a ticket to another team. The feedback cycle is reduced, and tools don’t get in the way.
This is something my colleague Matthew Sinclair refers to as Zero-Latency Communication. Products can be built at break-neck pace, with greater collaboration. This point isn’t a secret in software development. In fact, it’s part of the Agile Manifesto:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Isolating functions also makes it difficult to grow all departments in balance. It’s hard to get a holistic view of everyone’s needs, so headcount is often distributed to the managers with the best negotiation skills. The resulting imbalance in size between teams can lead to inefficiency, requiring time and effort to correct. By orienting teams by goal rather than role, it’s possible to get a more accurate sense of what’s happening.
Getting the Balance Right
Of course, this approach isn’t without its drawbacks. For some developers, getting drawn out of their Deep Work mindset in order to answer a question from a product manager is their worst nightmare. But there are techniques to mitigate this, such as specified quiet times. If teams find that they’re spending too much time talking face-to-face and not enough time building product, there’s clearly a problem. The key is being flexible and thinking proactively about the best solution for each situation.
On too many occasions I’ve seen teams put little thought into their seating organization. You can have the best team in the world, but if you don’t pay attention to how they’re organized you’re wasting a huge proportion of their value and making their lives more difficult.
Here at BCGDV, this is something we think about at every step in the product build. It helps us collaborate, create and build products that solve problems in innovative ways.
So, managers: next time you’re setting up a team, think about how they’ll sit. It may sound simple— but you’ll thank yourself later.
Interested in working with us at BCGDV? Want to find out more? See our current vacancies.
Find us on Twitter @DV_Engineering.
