Why Small Engineering Teams Are Best for Collaboration
Organizing an engineering team to tackle a tough product or software development project can be a daunting task. It sounds easy—gather one or more engineers, align on a common goal, delegate the specific tasks, and wait. Right? It’s actually much more complicated and there are numerous times during projects where things can go awry. It’s important to form a team that’s set up for success from the beginning so the team can work together to overcome the inevitable onslaught of challenges.
Engineering and development teams complete projects using different approaches, which we’ll refer to throughout this article as:
- Solo Approach
- Small Team Approach
- Large Group Approach
A “solo” approach can be necessary when a project is exceedingly brief and your surrounding team would gain no benefit in having a second person in the loop. A “small team” approach is effective when projects are broken down into independent tasks that can be simultaneously completed, while a “large group” approach is useful when the project can be separated into enough work streams that are conducive to collaboration. However, like any approach, there’s a tipping point where these approaches become unproductive in certain situations.
Small Teams are More Likely to Succeed in the Long-Run
We’ve been on product development projects that have used each approach and not always come out on the other side with success. Failing is an important part of the learning process which takes reflection to understand how and why a project may have failed in the first place. Sometimes, it feels right to throw as many engineers on a project to try and “cut the time in half.” Other times, it makes sense to have one engineer figure out the problem and report when the task is completed. However, our engineering team has found that neither of these approaches produce as many benefits as a small team does to tackle one project at a time.
While small engineering teams aren’t a mind-blowing new concept, it is the road less traveled for many in the product and software development industries. Simply put, small team collaboration includes two or more members (we usually cap at four to five in one functional unit) involved in a single project. It focuses on communication, teamwork, and trust. Punch Through uses this approach in all projects because it increases communication and transparency between our teammates and our clients. In turn, it helps make things run more smoothly. We can accomplish more while improving our working relationships and knowledge.
It proves successful for our engineering firm, and we’ve even had clients convert to our style of team organization and project processes after we implemented it into projects because of the positive results and finished product. It’s not just a process; it’s a cultural adjustment that we’re happy we made.
4 Benefits of Small Team Collaboration
Collaboration within appropriately sized engineering teams offers many benefits. Here are some of the most advantageous for our projects.
High-Quality Products
Collective brainstorming with a few engineering team members allows the group to generate more ideas and better refine them. Working with a team necessitates more agile approaches, which can lead to more results in a shorter amount of time. This allows for more refinement and iterative processes, leading to a better end-product. Quality is increased through shared accountability and collaborating with others enables team members to think a bit differently and challenge each other.
Each team member has the same goal and full context of the project. This increases the frequency of check-ins to keep the project moving on pace in an effective manner. It also helps with tougher decisions because more members can effectively contribute to the final decisions.
Scalability of Resources
The project is more flexible when a collaborating team is involved. This means that the project doesn’t just rest on one person’s shoulders. Missed time (for vacations, sick time, and other projects) isn’t an issue because there are more people to make up for the potentially missed time. The continuity and project flow is maintained because more people have full context of the entire project. Time isn’t wasted having to “fill in” project details when the project changes direction or more resources are needed. Helpful resources are just a “desk” away, which increases productivity, helps maintain the work/life balance of engineering teams, and fosters a community of support, as opposed to isolated workers.
Team Satisfaction and Growth
Perhaps the most important cultural benefit to collaborating as a small team is the overall team satisfaction. We as humans are social beings. Our natural instinct is to want to interact with others and this includes project work. We aren’t robots that can flip a switch and walk into work everyday ready to “crush it.” When organized appropriately, the team helps us to stay focused, motivated, and enjoy the work. We also share what we’ve learned, and learn together. This increases comradery and accelerates individual and team growth. Growing in such a way has a snowball effect, which enables us to perform even better the next time around.
Efficiency
Choosing the appropriately sized team leads to more efficient progress. Think of “Goldy Locks and the Three Bears.” Finding the porridge that is “just right” applies to engineering teams. A solo effort often leads to “spinning wheels” and getting nowhere, while too large of a team leads to unclear delineation of tasks and responsibilities. Contribution from team members dwindles as it reaches the end of the project development process. A small team can easily split workstreams between each other to make progress simultaneously, and still work closely enough to provide valuable input for each other.
How Small Team Project Processes are Different—What to Expect
The way that project processes are affected when using small team collaboration varies depending on project requirements and the project objectives. However, there are some consistencies.
Project Kickoff
Instead of the kickoff including only the key members of the project, in small team collaboration, the entire engineering team is present. This meeting is to determine what processes are needed, the nature of the project, establish owners of each task, and preparation to communicate effectively as a team (client and engineers.) Including all members of the project, even if not all are actively working on the project right away, ensures that the full context of the project is had by all from the very beginning.
Recurring Meetings
We use recurring meetings to stay aligned, help keep team members accountable, identify and address risks, and inform key decisions that require input from multiple parties. It’s recommended to have more than one team member able to speak to the status of each facet of the project, ensuring things keep moving if any individual can’t attend. These recurring meetings can be short and follow a simple agenda to ensure each member is up to speed.
Many teams avoid meetings or decrease the number of attendees, “to avoid wasting time.” Instead of cutting meetings or team members from an invite list, we recommend cleaning up meeting agendas and requiring pre-preparation by the appropriate parties to ensure the time is spent effectively.
Peer Reviews
The release process for projects requires a peer-review to be performed by members of the project who didn’t create the original work. By ensuring that there are multiple team members who have full context of the project, this gives you a bigger pool to choose from for valuable peer reviews. It helps keep the project on time and schedule by providing more members to review during each phase of release. The quality of review increases because not only do the peers have an understanding of what, but also “why”.
A more classical review process would be to pull in an uninformed third party and have them review a ton of content at once. We do reviews frequently, and in bite-size chunks, so the reviews are highly productive.
Retrospectives
Retrospectives are an important aspect of any project. The goal of retrospectives is to improve the way the team (and the surrounding organization(s)) functions by honestly reflecting on what has gone well and what hasn’t. Through that reflection, the team will discover ways to improve, and can carry that forward for the remainder of the project and for future projects. A retrospective is most effective with a high-functioning team, and is nearly impossible to benefit from in a solo environment.
Building the Team
In order to be successful in building a small team, you need to have at least two people that fully understand each role. One of these team members should be the “lead” and serve as the main point of communication. It’s important that all team members are aligned on the roles of each individual, and that an alternate is assigned to cover for a teammate, when needed.
Another key factor is to have a defined process that incorporates collaboration into each step. Understand which tasks can be performed in parallel by different team members, which tasks are dependent on each other, and ensure each path has an accountable owner and a partner in crime. Keep in mind that while adding more team members can theoretically shorten a project timeline, there is a point of diminishing returns or even a negative impact. Remember, it takes 9 months to make a baby no matter how many people are helping to deliver. Work with the team to create a vision for how everyone will split work streams and collaborate between them, and you’ll be well on your way.
So, there you have it: Small-team organization in a nutshell. We take this approach on all of our product and software development projects at Punch Through, and have left numerous clients pleased with the outcomes. It’s also left us proud of our work and excited to leave a positive impact on more products and people in the future.
Want to See Small Engineering Work?
To learn more about our product development process within the medical device industry, check out this blog post: