Pros and Cons of Trimming Your Development Team

You might be shocked to find out that maintaining the software after it is developed is even more expensive. But you have an idea for a solution to a major industry problem, and you need to find a way to reduce the cost to get it to market.

At Very, our standard project team composition is one part-time Product Manager, two full-time software engineers, and one full-time designer who is also a front-end engineer. Are all of these people needed to build your project? After all, it is expensive to cover the necessary rates for all of these people. What happens if we change the team composition?

What is a Full Team?

Before discussing making changes to the team composition, let’s go over each of these roles and how they fit into your software project.

Product Manager

Everyone on your software development team is a critical member of the team. However, this person has a unique role. While they are not actively writing code, it is their job to constantly survey the project. They evaluate every feature request and help prioritize the feature backlog to ensure the features you need are built in the leanest possible manner. The Product Manager ensures that only the features that are needed to support the user experience are built. This allows you to define the critical workflows of the software and develop those first. You can then get feedback from stakeholders and potential users sooner so changes can be made if necessary.

In addition to this, the Product Manager will work with you to define project goals, ensure the team has all of the information they need so they are not blocked, manage the budget and timeline, and be your first point of contact. All of this is necessary as it enables the team to be focused on a microscopic level while the Product Manager is able to take a step back and ensure that important milestones are reached on time and within budget.

Software Engineers

The name of this role is pretty self-explanatory. Software Engineers build the software. But this is a gross oversimplification. Not only do the Software Engineers write the code for your software, but they also help design the workflows of your software.

They give insight on process improvement to help reduce cost and complexity. They design and build the software system’s architecture. They are deeply focused on solving your problems. It is their full-time job. This is a lot of responsibility to place on one person as decisions on work this imperative to the success of your software should not be handled in a vacuum. That’s why our teams typically consist of a pair of software engineers who work closely together.

Product Designer

Not only does your software need to be functional, but it also needs to be visually appealing and intuitive. Each software project needs a designer to define the User Experience (UX) but also bring the User Interface (UI) to life. The Product Designer implements the design as code. They are focused on providing value and intuitive software to your users. They evaluate your project like a puzzle and treat each feature as a piece of that puzzle fitting perfectly into place. At Very, the Product Designer is also the front-end engineer, so you can rest assured that the designs and prototypes you receive can be feasibly built and will be intuitive to use.

What Happens when the Team Composition is Changed?

Dropping Software Engineers

One of the first places you may look to reduce your weekly burn rate is by only having one Software Engineer on your project instead of two. You may ask, “why do I need two Software Engineers building my software?” That is a perfectly reasonable question.

Our standard team composition consists of two Software Engineers for many reasons. One of them is that you cannot pair program with only one Software Engineer. This role carries an enormous responsibility on your project because they have to ensure the architecture can support the software and the demand of your users. They have to ensure your users’ data is secure. They have to ensure your workflows are correct and properly address error states. When a project drops down to one Software Engineer, there are a few side effects that I always notice.

• It takes longer for features to be developed. This is because if a Software Engineer is spinning their wheels on a problem, there isn’t someone there to help them gain traction and stay focused on the problem. Not only will the Software Engineer need to focus on the code they are currently typing, but they will also need to focus on how it will impact the entire system. Pair programming helps with this because the navigator is able to take a step back to ensure all of the requirements are being fulfilled, but also change course for negative impacts before they occur.
• The architecture has holes in it. There may be missing pieces of architecture your software needs to meet your users’ demands. You may need a caching strategy so the database isn’t overburdened with requests. You may need to integrate with a data warehouse to store all of your analytics events. You may need to integrate with a service that lets you integrate tech support chat into your software. All of these scenarios and more are more easily addressed when multiple people are trying to solve the problem.
• Code quality suffers. At Very, all of our code goes through a code review process before it is delivered to you. Code reviews catch more bugs and negative impacts on the system if they are done by a Software Engineer that is currently allocated to the project. This is because they will have domain knowledge of the system being built and how changes impact the system.
• More bugs creep into the software. This goes back to not having a pair to communicate with. If the Software Engineer cannot communicate their implementation to someone else then they are in an echo chamber. Everything they implement will feel correct. There is no one to question their authority. When this happens, there are more bugs.

Dropping the Product Designer

As you are looking for ways to reduce your burn rate and budget you may think, “If they have all of the design done, why do they still need a designer?” This is a perfectly valid question. At Very, Product Designers are also front-end engineers, which means they’re able to implement their design as code. This ensures the UX is intuitive and the UI is appealing. Without fail, I have noticed several scenarios that occur when the Designer is removed from the project.

• No one owns the user experience. Features are still being developed, and now that you have received feedback from stakeholders, a change needs to be made. So the Software Engineers implement the change at a slower pace because they are also implementing the front-end. This process continues to repeat itself. After a while, the software doesn’t feel as polished. Those changes that were needed aren’t as intuitive as those that were implemented before the designer rolled off. The software is functional, but it doesn’t feel special. You and your stakeholders are left feeling underwhelmed.
• Many features need to be reworked. The Product Designer is responsible for building prototypes of the features and workflows to be built. While they may not cover 100% of every use case, they allow you to put your hands on the product and try it out before the Software Engineers spend time building it. It is much cheaper to build a prototype than to build working software. Without the prototype, the Software Engineers will build the feature, then will you will able to use it, and then you’ll ask for some tweaks. Then they will spend time building the feature again, then you will be able to use it again, and then you’ll ask for some more tweaks. This is a never-ending process and ends up costing more than having a Product Designer on the project. It costs more because instead of one person designing it, you now have two people designing it, and they aren’t able to deliver a better-defined feature, but rather continue working on the same one.
• There is no voice of the users. The Product Designer is the voice of the users during the development process. They give you feedback on what features are needed, which they are indifferent about, and those they do not want. This slack has to be picked up by someone, and that is usually the Product Manager. However, the Product Manager is only a part-time team member. The voice of your users is a full-time job.

Dropping the Product Manager

You may wonder, “If this person isn’t shipping code, why am I paying for them?” Once again, this is a perfectly valid question. Without a Product Manager, the team has no leader. They don’t have someone who can drive direction, manage the budget, set the roadmap, track down information, organize the project, etc… When a Product Manager is dropped from the team, all of this slack has to be picked up. Even though the Product Manager is only a part-time member of your team, the remainder of the team will be unable to fill this gap and deliver on the work they are tasked with.

Is There Ever a Case for Changing the Team Composition?

Certainly, there are cases for changing team composition. No matter what, you will always need a Product Manager because they enable the team to stay focused. However, when your software goes into maintenance, you may not need a designer. Maintenance and support contracts focus on fixing bugs, improving performance, quality, and reliability. Generally, new features are not being developed so, in theory, you shouldn’t need a designer. The rule of thumb here is if you are building new features, you need a full team.

If you haven’t started building software yet and need prototypes to review with stakeholders, then you don’t need Software Engineers. A Designer and Product Manager are fine to handle this workload on their own and may consult a Software Engineer to check the prototype for feasibility.

Beware that if you have your own designer, it is still best to have one of our Product Designers on the project. This is because our Product Designer will also be the front-end engineer on the project in addition to building prototypes and being the voice of your users.

Parting Thoughts

We know that software development is expensive, but there are better ways to reduce the budget than changing team composition. The scope can be reduced or better defined, we can integrate with another software solution that provides the functionality you need without needing to rebuild it, or we can focus on only the features your users need.

I will leave you with one parting thought. If you were to buy a self-driving car, would you want the team building the self-driving algorithm to be just one Software Engineer? Would you feel safe? Would you rather have the appropriate team build it and find other non-important features to cut to reduce cost?