5 Steps for Better Interdepartment Communication
Pivotal sponsored this post.
A customer-facing team was feeling pain with Pivotal’s developers — it didn’t take long before we realized this was not a software problem, but instead, was a communication issue.
We since put out that fire, but the incident also drove home how software usually solves problems, while sometimes solutions could be as simple as changing people’s mindset. This adjustment can impact greatly and result in a significantly positive outcome. You may already have what you need to make a huge impact, while the cultural transformation is a critical element for digital transformation. Everyone’s ultimate goal is to ensure that Pivotal provides recognizable value to customers through a positive customer experience.
An example is how we rely on Cloud Foundry to provide technical solutions to make the developer experience more predictable and scalable. At the same time, we’ve also worked on making our customer experience more predictable and scalable by improving communication channels within Pivotal.
In this article, some of the approaches Pivotal is taking to improve communication and build empathy between their R&D and customer-facing teams in order to deliver a better experience and value is discussed.
1. How do you eat an elephant?… one bite at a time. Start small, then scale… collect your evidence and acknowledge the wins.
To put it frankly, Pivotal (like any company of its size) is a complex network of people, each with numerous communication touch points. As previously established, there are many teams that must collaborate to deliver a given success. And “pivoting” an entire organization or even just a subset of departments does not happen in accidentally and in a single step. So we start small and refine as we go to improve upon the way in which we solve for customer concerns one case at a time. Each learning contributes to the overall shift to improved communication and more acute empathy for the customer’s needs. This leads to the next point I’d like to share with you:
2. Experiment, Experiment, Experiment
An experiment is not a true experiment unless the results mean something. The results can be positive or negative, but there needs to be a finding — or a learning. To take this concept one step further, if learnings are not applied to the original process, the experience is wasted. So as we work towards improving on the ways in which our teams work together to deliver customer value, we are aware of the fact that if our learnings are not directly incorporated back into our practices, there was no point running the experiment in the first place.
Additionally, one experiment is not enough, there must a series that are revisited and not left to go stale.
Pivotal is always running experiments, constant iterations. What can we learn from this experience described above to make it more sustainable and scalable across teams?” and we want to think about and promote running experiments on more than just directly on the software or products we happen to build.
3. Understand Roles and Responsibilities
Revisit your org structure and think about if it’s truly helping or actually hindering. Something that we realized within our org is that Conway’s Law doesn’t only describe how the software you build looks like your organizational structure. It’s true of the overall customer experience as well — they can feel how you structure your departments if that structure is hindering collaborative efforts to move towards effective solutions. This is something that is surprisingly similar to software development and product delivery. Our R&D, support, and balanced account teams are arranged across independent departments, so it is important for us to be intentional about the way in which we enable communication… which leads to my next point.
4. Clear Communication around Deliverables
When collaborating, it can be very easy to assume that information has been expressed and understood clearly. This, however, in practice is something that should not be taken for granted, as a miscommunication can result in costly consequences. It is worth the effort to spend some time thinking about all the touch points between people and information to discover bottlenecks.
One example that we have recently come across is via release notes. Release notes describe feature changes and bug fixes, which is generally what to expect from the most recent release for a given product upgrade. Inconcise/incomplete/vague/ill-expressed information in said notes results in customer confusion, as well as inter-team confusion. It is easy to assume that what you know, everyone knows. In a couple of recent instances, we discovered that a miscommunication meant a change to the way information was logged. There was a miss in one case because the team doing the development did not realize that someone would care about the changes made.
A change to BOSH resulted in an update to a feature that we had not explicitly agreed to deliver. This change was detected by a test set up by our customers, who assumed that the feature was guaranteed. The resulting change meant that logging functionality was removed. It turned out that the customer was depending on these logs for audit reasons. Their tests caught the change before we did and it could have put both them and ourselves in an undesirable position.
While this change is reasonable, it’s important that communication is explicit so that from the change occurring in the code to the information captured in release notes to the business team is made aware of potentially sensitive changes that can be shared with the customers, there is no break down of communication along these lines.
5. It’s a relay race… Shared understanding of who is holding the baton in the delivery process at any given time.
Product development is not only software engineering but also the handovers. With a complex product like Cloud Foundry, where microservices are built by many interlocking small development teams, the pathways for communication are also complex. Having checks and balances in your product’s path to value delivered to the customer is integral to successfully meet customer needs. When information changes hands so many times, important details can get lost.
Similar to the responsibility of multiple runners in a relay race to carry the baton; in software delivery, the responsibility to carry the baton is handed from team to team. This means that every runner must understand the terrain of the race and explicitly where those handoffs are happening. The entire team is aware of the full map even if they are only responsible for and hone in (effectively own) a short part of the journey.
When processing information such as business value, delivery dates, quality, changes to existing functionality made, etc., it can be difficult to know who is actually owns the current state of the solution at any given time. We had to reassess the way we communicated by looking at our feature pipelines and also the way in which information around release updates was managed.
After developing a shared communication contract, we found it exponentially easier to increase confidence and visibility into what product teams were working on, as well as decrease the number of stressors placed on the various characters in the path to value to the customer.
These five steps are by no means a comprehensive solution to fixing all communication problems. However, they are a good place to start as you work towards assessing the current state of how your company communicates between departmental teams and externally to the customer. We are in the middle of this journey and realize there is still a great deal of work to be done. When it comes to improving communication and building empathy, our belief is that there is always room to grow.
Hopefully, this article leaves you with a different angle for considering your approach in identifying and delivering customer value.
Feature image via Pixabay.