What To Expect From Your SaaS Development Team

Project management is an entire profession, and we can’t cover that body of knowledge in this book. However, as noted previously multiple times, I highly recommend taking a course on Project Management with a focus on Agile Development Methodology if you are going to be a part of the management team or if you are an entrepreneur wanting to build a SaaS. If you go forward on this, you will have to learn it one way or another. Better to learn it up front than to waste money making mistakes.

All that said, there are some things that you should know about SaaS development and development in general.

Developers are optimists

They just are. Even the ones who say they aren’t. So make it easy on yourself and your team. Whatever time they give you, at the very minimum, increase it by 20% in your head and on your projections at the very minimum. If you can, take whatever they gave you and double it in your projections. If you do this, you will almost always make your deadlines. Never go below a 20% increase in your projects, ever. Don’t tell them that you’re doing this, just do it and keep it to yourself, then smile when they make the deadline you thought they would make in the first place or beat your expectations.

Communication

So much is going to change in the build of your system. Hopefully, I have hammered into you by this point how important it is to plan as much up front as possible. But things are still going to change. There will be things you didn’t consider. The landscape will change, you may pivot, you will learn things you didn’t know previously, and the system will change. It always happens.

So a key aspect of this entire process is making sure that everyone knows what’s going on as it changes.

Team meetings

I recommend doing meetings with your team at least three times per week, and potentially much more than that. For SaaS systems I am managing, I generally meet with each team lead DAILY. A study of Agile Methodology will help you streamline this tremendously.

Brooks’s Law

This is another area of the Mythical Man Month by Brooks.

What this says is that adding another developer to any substantially complicated project (as SaaS systems often are) halfway or later in the build of that project does not decrease the build time, it increases it. This is because the amount of time it takes to gain the ‘tribal knowledge’ gathered in the first portion of the build of a system is greater than the amount of time it takes to build the rest of the system.

This applies more or less to different systems in different ways. Sometimes it doesn’t apply these days at all. But the important thing to remember is that very often, just throwing more people and money at something won’t make it go any faster, especially after a certain point. This is very similar to the “Law of Diminishing Returns” you may recall from your Economics class in college or high school.

Here is what the Wikipedia has to say about Brooks’s Law:

“According to Brooks himself, the law is an "outrageous oversimplification", but it captures the general rule.

Brooks points to the main factors that explain why it works this way:

It takes some time for the people added to a project to become productive.

Brooks calls this the "ramp up" time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.

Communication overheads increase as the number of people increases.

Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people.[3] Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.

Limited divisibility of tasks.

Adding more people to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration (up to the point where additional workers get in each other's way). Some tasks are less divisible; Brooks points out that while it takes one woman nine months to make one baby, "nine women can't make a baby in one month".”

Please keep this in mind as you build your SaaS as it applies in most cases.