Two Team Projects

Introduction

This post is my answer to the following question: "Reflect on your most positive and negative participation in a team project. What specific strategies could have been utilized to improve the experience?"

Best Participation in a Team Project

While working at AOL I was part of several excellent teams. My best experience, however, was working for a small start-up company located about fifteen miles south of me. The start-up company had recently purchased the naming rights to a formerly popular software product designed to protect children while online. The software hadn’t been updated in years, and the team was charged with recreating the software from scratch.

The team consisted of eleven individuals:

Description/Specialty	Count
CTO	1
Backend developer	1 (me)
QA testers	2
iOS developers	2
Android developers	2
Web developer	1
DevOps engineers	2

We were able to create a minimal viable product in approximately six weeks and a public product in an additional two months.

In many ways, we operated much like an R&D team in that we were applying innovative technologies in very novel manners. Georgiou et al (2025) differentiates between what they call “visionary R&D Leaders and operationally focused R&D Managers,” with the latter providing the “human element” (Scott, 2019). The distinction did not apply to this team, however.

Several factors made this team extremely successful. First, we were all extremely enthusiastic about the project, and while not all the members were “rockstar” coders, there were enough of us in the right positions to make a difference. Further, there was little overlap between the team members. Even in cases where there were two people with the same description or specialty, like iOS developers, their part of the project was sufficiently large to require two developers. Communication between the relevant people was frequent. Finally, there was an absolute minimum amount of bureaucracy.

Worst Participation in a Team Project

I have also worked on several unsuccessful teams. The worst was at an established building automation company. The team was comprised of the following people:

Description/Specialty	Count
CTO	1
Project manager	1
Backend developers	2 (me plus one other)
Embedded developers	0
Web developer	1
QA tester	1

The only overlap was with the backend developers. It soon became clear that the original backend engineer (not me) was extremely competent and well-able to manage his responsibilities, and I had little to offer that was different. We soon figured out that we needed an embedded developer (a person who writes code for small electronic devices like the Raspberry Pi), so I moved into that role.

Description/Specialty	Count
CTO	1
Project manager	1
Backend developers	1
Embedded developer	1 (me)
Web developer	1
QA tester	1

We maintained the overall system with absolutely no problems. The CTO, however, decided that our team was too small, and he hired several contractors that doubled the size of our team. Problems soon began. Even after six months, the contractors made no appreciable additions or improvements to the project.

Improving the Worst Project Team

Improving this worst team requires first identifying the underlying problems. In this case, the problems were directly caused by the CTO.

He was the son of the owner and CEO and believed that he had something to prove. This led him to rent an office space despite the team working remotely and getting to that office either required a three-hour one-way drive, or a flight from out of state.

It also led him to hire contractors to double the size of our team with no plan for what they were to accomplish. The project manager was not involved in this decision, and this was interpreted as a vote of no confidence. He soon left and was replaced with a much less competent individual.

The CTO was equating physical office space and subordinate count with actual accomplishments – he was equating the appearance of success with actual success. No thought was put into expanding our customer base, and the actions he took would not bring this about.

If a psychological explanation is required, it may lie in the CTO’s age. Except for the web developer, he was the youngest member of the team by a wide margin. He did not earn the position, and his only qualification was being the son of the owner/CEO. I don’t think nepotism explains everything, and I believe that his poor decision making can be explained as “daddy issues.”

None of the resolution strategies for team conflicts listed in Goetsch & Davis (2021, p. 154-156) would apply to this situation. There are few solutions to this situation, none of them easy because of the element of nepotism. One way would be to completely replace the existing team with contractors, but this solution would not work for long. Another solution would involve the owner/CEO providing some parental guidance or even removing his son from the CTO position. In the end, that is what happened.

References

Goetsch, D. L., & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9^th ed.). Pearson.

Georgiou, O., Maksymenko, M., & Russo, S. (2025). Leading an R&D Team. In: R&D Management and Technology Commercialization. Management for Professionals. Springer, Cham. https://doi.org/10.1007/978-3-031-86789-7_7

Scott, K. (2019). Radical candor: Be a kick-ass boss without losing your humanity. St Martin’s Press.