Product, not project development
Why everyone in the team should think about the product?
One might say that software development is difficult to master. While there are many online courses and resources, which aim to train users in this industry, there is a huge lack of qualified developers across just about every country.
Working with different types of companies, from early stage startups till large corporations, I was always wondering why there is a need for so many people involved in the formal process of development. I specifically remember the case when one bank had ~200 software developers that were working (all of them) on one mobile app.
While I might agree that you need some extra resources for a well established product, especially in the FinTech area, I can appreciate the responsibilities of 10-20 of them, I have no idea what the others do. Taking into account that for each group of 5-10 people you need a manager, and for a group of 5-10 managers, you need a supermanager, it looks like a Ponzi scheme.
When I am thinking about such an inconsistency, I always remember one of my favourite companies, 37signals that has built a BaseCamp with a few people. Why were they able to manage such a complex product, while others needed to keep increasing their team and adding more and more resources but getting less and less results?
Firstly, math does not work here. When you add more people to the team, it does not increase the efficacy. On the contrary, it might dramatically decrease it because of “additional expenses” that grow for each new member. Especially, if some people do not meet the overall culture of the company. As a psychologist, I was talking a lot with other colleagues in the field of organisational psychology about some experiments (which are not reproduced but who cares…) that demonstrate that one demotivated employee can actually destroy the team in a few weeks. When you have hundreds of employees, it becomes difficult to manage all situations.
37signals in their Manifesto wrote:
You can do big things with small teams, but it’s hard to do small things with big teams. And small is often plenty. That’s the power of small — you do what needs to be done rather than overdoing it.
Secondly, not every software developer is actually a developer. I differentiate here two possible categories: developers and coders. While the latter do their job and just code something assigned to them by managers (and this is the usual folk representation of a programmer), the former develop some code but also, they resolve problems.
This is an absolutely different story. Sometimes, you don’t need to code at all because there are other solutions. Sometimes, you need to talk with other guys and find a better way. Sometimes, you need to play a role of business analyst and decide whether or not this feature should be implemented. Business needs problems to be solved, not the code to be developed.
Thirdly, one should always remember The Pareto principle: you don’t need 80% of your features because users do not use them. 80% of time spent for feature development is actually useless. Here I also remember 37signals with Basecamp that have a standard and generic reply to their clients that they (37signals) know better what are their clients’ needs. While it is not always true, one should not underestimate the power of simplicity.
People like simplicity and do not like complexity. Psychologists Iyengar and Lepper have shown that one feels good when one has an option to choose between a few alternatives, not when one has too many or too few options. You do not need to cover all possible scenarios, especially when you can deal with them manually.
The crucial and essential skills for any team member in any product are problem solving and critical thinking. The former helps to focus on solutions, not on tasks, the latter allows to prioritise important things and deprioritise (and actually throw away) garbage. Also, one should shift the paradigm from doing tasks to product thinking. The goal of everyone is to resolve problems raised by the business and clients and do this effectively in a quick, effective, and lean way.
When you build a strong team focused on the product you do not need hundreds of people. A small motivated team will be more productive and efficient.