It seems to be a generally acknowledged truth (often bolstered by Reverse Conway’s Law) that decisions regarding the software systems you build should take your team size into consideration. That often leads to the belief that there is a fitting system architecture for small, medium-sized and big teams. That’s wrong.
Team Size and Software System Design
Sam: So we need an overview of the truck fleet, we need to plan tours, log repairs, track inventory, do payroll, write invoices, we need access control for both garages and trucks, we need to ping drivers on the road about changes, oh did I mention the driver management system? We need that as well…
Max: Wow, impressive! This means we need to build at least seven different software systems.
Sam: Sounds like it. But wait, we have only three developers. How are they supposed to maintain seven systems? That’s impossible!
Max: You’re right. Let’s build ONE BIG system instead, a giant monolith that does everything you mentioned.
This is certainly set up to fail. The three developers still won’t be able to maintain all the functionalities and capabilities of the big system. They will probably not even gain the necessary domain knowledge to implement it somewhere near correctly.
Another issue is that tying technical decisions to team size does not take into consideration that the team size changes much more frequently than the tech foundations. Hiring and firing happens all the time, switching the Oracle database to Postgres and back again not so much.
Team Size and In-House vs. External
Sam: So we need an overview of the truck fleet, we need to plan tours, log repairs, track inventory, do payroll, write invoices, we need access control for both garages and trucks, we need to ping drivers on the road about changes, oh did I mention the driver management system? We need that as well…
Max: Wow, impressive! This means we need to build at least seven different software systems.
Sam: Sounds like it. But wait, we only have the manpower to fulfill three of the requirements. I’d suggest the truck fleet overview, the tour planning and the driver management. How do we solve the other problems?
Max: We can get licenses for external accounting software and buy an off-the-shelve access control system!
Problem solved? Almost. Often the amount of work to use external systems is not taken into account. Someone needs to setup and configure these, report tickets in case they don’t work, connect their APIs and Webhooks to the in-house systems, document how it all works together and train people. While not all of this is necessarily responsibility of a tech team, a considerable amount of time will still be spent by IT to work on external products.
Team Size and Scope
Sam: So we need an overview of the truck fleet, we need to plan tours, log repairs, track inventory, do payroll, write invoices, we need access control for both garages and trucks, we need to ping drivers on the road about changes, oh did I mention the driver management system? We need that as well…
Max: Do we really need all that? We can get licenses for external accounting software and buy an off-the-shelve access control system, but still this is a lot of work…
Sam: Most value for our core business will be brought by the tour planning. But what about the truck fleet overview and the driver management?
Max: For now, we’ll use Post-Its on the wall for the trucks and an Excel sheet for the driver management. After the MVP for the tour planning went live, we’ll start working on replacing the Post-Its by a proper system.
Finally we are getting somewhere. Tying scope to team size is totally legitimate.
In the real world, what happens instead is sacrificing quality over scope: Usually a decision is made to rather go for low quality systems that can do a little bit of all requested capabilities – they can be improved in the future! This decision is hard to revise as the team is bound to maintain the mess for years, add on features or fix bugs, without of course being allowed to remove parts from it.
What do you think? Let me know in the comments!
Photos:
- Photo by 🇨🇭 Claudio Schwarz | @purzlbaum on Unsplash
- Photo by Dale Staton on Unsplash
- Photo by You X Ventures on Unsplash