The concept of breaking companies and teams into smaller groups in order to progress with units of work relatively independently is by no means a new concept. Even with its recent growth in popularity as a way of scaling teams, Amazon have done it for years, and 3M have been at it for decades.
Nowadays, flat-hierarchy organisation structures are all the rage, especially in the Valley. The concept is appealing for a number of reasons: the right people on the right jobs, the promise of easy scaling of the business as it grows, and work happening closer to the customer to name but a few.
Following on from some fascinating discussions with those on the ground in companies with varying levels of adoption of these concepts, I would like to share import.io’s current approach to efficiently and effectively developing new features.
Our organisation is, fundamentally, structured as a typical hierarchy. As we are still reasonably small (less than 20 people) our teams max out at 7 people (dev is the largest) including a leader, who is part of the management team.
These teams are divided up much as you’d expect for a tech startup – Dev (including ops), Client Onboarding/Support (which we call User Success) and Sales & Marketing.
Due to the different nature and expertise that naturally comes with three independent departments, we have had to work through several methods of collaborating on the development of new features. We tried having product owned by Dev, User Success, Management, and even by the team member who proposed the feature; all with varying degrees of success. Usually, someone would propose a new feature, it would then be worked on and spec’d by whoever was running product at the time, and finally passed over to dev to be built and shipped.
The overwhelming internal feedback on these approaches was that, while we got things done – often reasonably quickly – we would frequently have to come back and make some changes (some not so significant, some pretty serious) after our first release (QA or production) because it didn’t align with the initial expectations of our team and/or our users. We may have been pushing out features, but they weren’t meeting the requirements of people using our product, internally or externally. We realized that if we couldn’t find a way to consistently meet internal requirements, there was no way we could hope to meet external ones.
Towards the end of 2013 we decided to experiment with pod-based feature development. As we have now completed a couple of major development cycles (encompassing several smaller ones) since the first, I thought it a good time to reflect on how we are doing.
Our pods have one crucial difference to Amazon’s teams or Holacracy’s “circles”. Where those methods feature permanent groups, our pods are formed specifically for the development of a particular feature, comprised only of key stakeholders within the business, which are then dissolved once that feature has been shipped to production and checked.
In fact, the name suggestion for our pods came not from the management definition of pods given earlier, but rather messaging startup Beluga, whose transient group chats were called “pods” until the company was acquired by Facebook and turned into Facebook Messenger.
The transient nature of our pods allows us to keep them lightweight and focused. There are no excess meetings: we try and reduce them where possible, deferring to tasks and group chats in Google Hangouts to discuss any questions that arise. But of course we still value sitting down face to face and scoping something out so we are all on the same page.
Starting a pod
A pod is formed once a new feature has been pitched by a member of our team at one of our regular all-hands pitching sessions. Ideas can be generated by anyone in the organisation for any reason, from thinking something would be cool, to scratching an itch they have had with the product themselves, or in response to feedback from external people using our product.
Pitched ideas, once commented on by the team, are sent to the product group (which is like a more permanent pod) who review, prioritise and schedule new feature development.
When the idea is ready to be started, a pod leader is chosen, and they are tasked with forming the pod and kicking off work on the feature specification. Usually a pod membership is formed of:
- Pod leader – this can be anyone in the organisation, though we find this is usually a developer at this early stage
- Developers – any engineers that need to put significant work in to the feature
- Subject matter experts – the person who proposed the feature, if not already in the pod as a developer, plus anyone else interested in the progression and deployment of the feature
Running a pod
The members of a pod are responsible for the end-to-end work of a feature, from its initial specification through to checking it works once in production.
The pod leader is responsible for administering the pod and ensuring work proceeds at a healthy pace. However, this isn’t usually a problem, because the rest of the team are just as enthusiastic as the pod leader about getting the feature specified, worked on, checked and shipped.
There are a number of key waypoints in the development of the feature that a pod must pass through before a feature can become a reality. The first, and most important of these, is the completion of a specification (spec) document. This must be signed off by someone from the product team before a single line of code can be written. An occasional exception to this rule is Proof of Concepts (PoCs), which are splintered off into their own mini-pod, with a main feature pod created once the PoC is completed. Other key milestones include the feature being pod-reviewed (to ensure it meets the specification), the feature being merged for QA, and the feature going to production.
To keep the development lifecycle from becoming a waterfall process, there are always many tiny feedback loops and iterative improvements built in to the work timeline of the feature. We have “lab” environments where new UI features can be shipped with a permanent URL so pod members – and sometimes external users – can validate the work that has happened so far. There are also times where other members of the organisation that aren’t specifically in the pod are brought in to give their feedback, opinion, experience or general thoughts on a particular problem or issue – anything from database schemas right through to the language in the UX.
Advantages and disadvantages of transient pods
The biggest advantage for us with pod-based feature development so far has been the inclusion of subject matter experts from the very beginning of the feature development process, all the way through to the end.
As a developer it is sometimes all too easy to get hung up on what you are working on, and lose focus of what the person who will be using the feature will be thinking or what context they will have as they use it. W
ith the subject matter experts on hand throughout development, those issues are ironed out much earlier in the process.
We are also finding that the features we are shipping are getting much better reactions from users for this.
The flexibility of being able to bring in other team members – such as Developer Experience when we propose a new or updated API that should be checked – as and when required allows us to keep the pods lightweight and very flexible.
There are some issues with the process that we are still working out. For example, management of a pod requires significant discipline to ensure that everything is in line and progressing nicely, and to check that there are no parts of the feature that slip through the cracks unnoticed.
In order to help us with this, we have created a structured checklist of things to think about when creating the initial specification for a feature. We have also introduced a process to ensure that at all times, everyone in the pod is aware of what is going on. At the moment, this involves predominantly Asana, whose projects are ideal for relatively short-lived project management. Additionally, tools such as Google Hangouts, group text and video chat allows the entire pod to be kept up to date and in sync as and when things change, questions need answers, or specs need clarification.
So, was it worth it?
The transition to pods for our feature work has been an adventure, and after some significant work – and a few learning curves – we are now beginning to reap the benefits of this approach.
The transition was not easy, and we are continuing this experiment while we ascertain whether it will be right for us as we continue to grow and scale our team in addition to our product. But for now, we are happy we are making good progress and making good headway in overcoming the shortfalls.
What does your team do differently and why does it work for you? Let us know on Twitter.