Consequences of Ineffective Communication in iOS Teams

In the software industry, it’s not uncommon to encounter the following behavior in teams: developers are excited and productive at the beginning of a new project or building a new feature, but as the development progresses and time goes on, their enthusiasm decreases.

I believe one of the reasons behind this change is the ineffective communication between team members. As software developers, we sometimes fail to understand the needs of our peers, and at the same time, we fail to effectively communicate our own needs. Let me illustrate this with a story.

Some time ago, I was working on the iOS team at a company that developed products deployed on Apple’s platforms. One Monday morning, the product manager (let’s call him Mark), announced during our daily stand-up meeting that a priority-one feature had come up and a small team of three developers needed to be formed to start working on it right away. He explained that crashes had been reported in some edge cases, and as a result, the iOS app needed to fetch some data from a server and map that data natively to some settings before the app showed any UI. After further discussion, we agreed the requirements seemed simple enough, so we started development right away.

Myself and the other two developers who volunteered for the task got together, studied the requirements Mark had given us, and began coding independently. I worked on fetching and parsing the data, and the other two developers worked on persisting and updating the UI, respectively.

The next two stand-up meetings went smoothly. When Mark asked about our progress, we assured him we were doing great and planned to complete the task by the end of the week. Our response was honest, as we truly believed the time leading up to Friday was all we’d need. Then Friday came and we realized that although we had individually checked off the different requirements, we couldn’t make the parts work together. Many of our components ended up being incompatible, and some of them ended up with duplicate implementations.

As a result, we had to tell Mark we wouldn't be releasing a new version that week after all, as we needed more time to finish the feature. This was frustrating to say the least, and it directly impacted our enthusiasm for the project in a negative way.

There were numerous things we did wrong that week. Now I can confidently tell you that almost everything that went wrong was due to inaccurate assumptions. In other words, we didn’t communicate effectively. For instance, we failed to obtain a valid response from the server team that we could use as a blueprint. This lead to having to edit our mapping layer because we incorrectly assumed the values and format of the server response. Additionally, we failed to establish boundaries between the areas each team member was covering individually, which resulted in providing incorrect inputs and outputs and duplicating parts of the system.

After experiencing plenty of similar situations in other projects and teams, I realized that in many cases, we thought we were doing independent development but we certainly weren’t. Sure, each of us was working on a separate requirement independently. However, before we started coding, we didn't communicate with one another about what we were each going to deliver and we failed to establish a contract between our components and to agree on their input and output.

This gap in communication resulted in us failing to meet the deadline, which resulted in the company's continuous loss of value because we weren’t able to address and fix the aforementioned crashes on time.

Looking back, it seems to me that most inexperienced developers would have had the same reaction. As soon as Mark said the words "priority one" and "caused crashes," I remember everyone becoming alarmed. These words created a sense of urgency. We valued our work, so naturally we wanted to ship a crash-free iOS app. Moreover, we thought that because the business was losing value, the feature had to be built as soon as possible.

However, this logic was flawed. The truth is that the business would regain value long term if and only if its product delivered a great user experience. To deliver such a promise, it was paramount to develop high-quality systems, on time.

We thought the key to independent development was only coding individually, but that alone didn’t help us at all. We didn’t reach our goal faster and in a more efficient manner. In fact, the result was the exact opposite. In this way, we learned that the key to independent development is communicating effectively with all team members through all phases of development.

Furthermore, a team that can successfully convey its needs among its members and across other teams in the company will not only find itself more satisfied working on projects, but it will increase its value dramatically, allowing the business to reduce its current and future costs. This is essential to succeeding in the software industry.