HACKER Q&A
📣 kcpravin

Has anyone tried floating pools for engineering?


Our organisation has 4 different products and a platform component to support these. It is likely that some of the products would need higher engineering capacity at some point while other products might be running lean. In order to have optimal productivity, we are considering having a floater engineering pool which can be moved across different teams based on the increase in demand for the respective products.

Not sure if this is a good idea. We are obviously concerned about the context switch for the developers. But, I would like to hear from any of you have tried this approach and would like to know if that worked.


  👤 subradios Accepted Answer ✓
That depends on your future goals for the company, as a manager.

If you have a few products that are themselves products with their own associated organization and, (and this is critical) entirely separate tool chains etc, you could get awU with it.

The problem you tend to run into is that any break from ownership is a wedge thar creates a business side dependency hell.

How do you stop developer A from being tasked to maintain team Bs code, because they became a subject matter expert on some subsystem in team Bs purview?

More importantly, how do you stop it in a way that the incentives of the individuals involved don't drive them to break?

PMs want features, engineers want to have impact for their perf review.


👤 Hatrix
Being a floater engineer was frustrating. Less experienced engineers were able to stay on projects and move into lead positions while I was moved around fixing their code. You eventually end up in a job review with a manager who is clueless about your contributions.