Pods & Individual Contributors
Traditionally, staffing has been thought of in terms of individuals; a company would come to a staff augmentation firm to fill a hole in their team roughly the size of a full-time developer or two and distribute them throughout their engineering organization. But in our experience, that’s not always the best way to go.
Traditional Individual Contributors
Traditional contributors provide a lot of value: they’re flexible and cost effective, allowing you to fill some specific need in your organization. And they work best in situations that compliment those strengths. You should consider using individuals when:
You have a team or teams that need a little help to meet a deadline.
Your stack is tightly intertwined – anyone wanting to work on it will need help onboarding to understand its conventions.
Your needs are unpredictable – you just can’t tell where the next place you need help is going to be.
The biggest weakness of individual contributors crops up when you have a long-term engagement with them. If you’ve been working with one person or a few over time, they’ll naturally come to know your stack well. But if your needs change and your engagement with those individuals end, that knowledge they’ve gained doesn’t provide any value to you anymore. The context is lost. That’s where pods come in.
Pods
Our pod offering is in my view the best we provide value to modern engineering orgs. Pods are pre-assembled groups of developers, designers, test engineers, data analysts… full flexible product teams off the shelf. This immediately solves the problem of long-term engagements and context. Even if your needs shift a little – maybe your team needs one fewer engineer and an extra data analyst – there is built-in institutional memory. You don’t lose the time investment and you don’t need to onboard someone from scratch. Further, pods let you scale up quickly. You’re not adding a person here or there – you’re increasing the size of your engineering team in bulk.
Pods don’t work for everyone, but they’ll work especially well if:
Your codebase is pretty modular such that a team can work on one feature space without having to be familiar with the whole thing. This lets you take advantage of the inherent autonomy of the pod.
You need to scale quickly and ship features without choking your onboarding process.
You know you need help over time but your needs aren’t always identical – some quarters you’ll need more data engineering, others you’ll need designers. But there is always a core need there.
Looking to see what will work best for you? Book a call with me below and let’s talk!