So there are a few ways to answer this question.
- Should a small team even have formal reporting lines?
Here, the answer depends on how you understand formal reporting lines. If you understand them as the manager telling their reports “what to do”, then of course, this is incompatible with an agile, self-organized, autonomous team approach.
However, I view the role of the line manager as being responsible for growing and developing the team (through establishing growth plans, feedback, coaching, creating opportunities, etc.). This is best done by someone who knows the craft, e.g., a senior designer developing junior designers.
Side note: There are also organizational principles like Holacracy that eschew line management altogether. I have not experienced these and hence have no (informed) opinion on them.
2. Does a small team need dedicated managers for each function?
Of course not. This depends how large the team is and how it is composed (even “function” is ill-defined, on a big team you might have backend, frontend, infrastructure, and QA all as separate functions with their own managers, on a small team you maybe only have a handful of full-stack engineers). Do you need a dedicated manager for 2 PMs? Probably not. On smaller teams, you can group functions (e.g., designers and PMs reporting up to a VP Product), report directly to the CEO (often done with PMs in startups with a product-focused CEO), or have player-coaches (like GPMs (Group Product Managers), who also have operational responsibility but also manage some PMs).
To me, the key though is that the growth and development of the team members is anchored somewhere where it makes sense, because that shouldn’t come just from the cross-functional product team itself. Of course, a good product team should be continuously improving, holding retrospectives etc., which should make them more effective as a team but not necessarily better at their craft. It is unlikely that a designer learns better information architecture or better visual language from team retrospectives (unless he’s really lucky with his team members, but even then he probably could have learned that more effectively from a more experienced designer).
Hope that makes sense!
