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?


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

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?

Published on: