Team Allocation. A Confusing Task

The realization

Recently, I had an amazing discussion with one of my coworkers (kudos to him). It starts as a casual, random discussion. But, along the way, we started to talk more deeply about product and team management.

He throws a question to me, in general like: “Sam, how’s your opinion about the team/people allocation in our company right now?“. I just replied straight-forwardly like: “I think it’s okay. Why?”, I asked curiously.

He replies: “It’s good. But in my previous company, we took a different approach to how we allocate team members”. “Really, how?” I asked again.

If you can see my eyes at that moment, you’ll see the eye of a person who’s curious, confused, and all other curious-like emotions combined.

The options

”While here, [especially the engineering team] we allocate people to a project based off of the availability, the other counter option is we allocate people based off of the assignment to product/feature itself” he explains.

If I am being honest with you, my dear reader, that moment has stuck in my mind for quite a while now. Why?

Digging

Let me take you to dig a little deeper into both options first.

• Allocation based on availability: This is the approach that most of the startups/small companies take. Everyone in the team has no dedicated product/feature that they own. Everyone owns every product. As long as they’re available to work on it, they can take it.

• Allocation based on assignment: On the contrary, this approach was taken by most of the established companies. Everyone has their own dedicated product they owned that has been assigned in the beginning.

Which one to choose/the best option? It depends.

To find out, we might need to ask why big and small teams/companies took different approaches.

The Bargain

It all boils down to one word: RESOURCES. It includes time, manpower, capital, and many others.

The allocation based on the assignment approach promises that a product will always have some team/people that have a great depth of understanding of the product itself. From there, great development, issue resolution, and product ownership are highly likely guaranteed.

On the other hand, allocation based on availability promises that everyone (at least) knows the inner work of the product. This approach is an oasis for small companies/startups whose small/limited amount of product line, manpower, and time.

The Risks

Up to this point, you might have figured out the disadvantages of the approach itself. The assignment approach poses a huge risk when a huge task when an important team member leaves the company. The knowledge transfer MUST be smooth.

The availability approach is not the best either. Since everyone has a “not-so-deep” understanding of the inner work (unless all of your team is A++ people in terms of skills), development and issue resolution can become a challenge if the communication between team members is not done right.

So my dear reader, which one did you choose?