Building a Culture of Collective Ownership
Building a Culture of Collective Ownership
In an Agile environment, getting everyone to buy in and believe they have a stake in the product is key. We discuss a few ways to build such a culture.
Join the DZone community and get the full member experience.Join For Free
About a year ago, I realized that we had a communication problem between product, development, and QA. We were going through some internal changes, which had our teams shifting a bit. Our developer and QA teams were growing, we had some new managers and team leaders, and we were all working intently on an upcoming release. After some discussion with various groups, we set our gold build date. When it arrived, we were informed by our QA team that they needed another week to finish their testing. The rest of us were struggling to understand why it was going to take them an additional week, and more importantly, why no one spoke up sooner. Due to the fact that we were experiencing team growth and realignment, we had not yet built a culture of collaboration or collective ownership with our new team members and managers.
We have been working very diligently since then to build communication and collective ownership back into our teams. As a general rule, we have always had great communication, but with the increase in members, we found a gap that needed to be addressed. It was necessary to ensure that our new team members understood that they could speak openly about our processes, make suggestions or encourage changes to our release dates without penalty. Through the years, we have built strong relationships throughout our different organizational teams by encouraging communication. Like in every other organization, SmartBear strives to make sure that sales, marketing, product management, support, QA, and development are all on the same page, working together and aware of any changes that might be taking place. There are several keys to making sure that the communication channels are working effectively, including being positive, using the appropriate tools and building a culture of collective ownership.
The old saying, ‘if you don’t have something nice to say, don’t say anything at all,’ is partially true. The reality is that issues need to be pointed out, honest conversations need to happen, and problems must be addressed. It is not always easy but can be done in a manner that encourages open communication and doesn’t offend co-workers. In the software business, people should review one another’s work. Work products from requirements to design documents, source code to test cases all need to be looked at and reviewed. Reviews are a great way to ensure that everyone is on the same page regarding changes that are taking place. If a design document is updated and the appropriate people are on the review, everyone will know what is going on. Additionally, those reviews help train new employees and ensure that multiple people understand core components.
One of the challenges faced in today’s world is the increasing amount of communication that does not take place face-to-face. It is important to remember that a person, with feelings, is on the receiving end of any communication. As a rule, people have a tendency to be harsher and say things in written communication that they would not say if they were standing in front of another human being. Many do not realize that there is a negative bias in communication via email, texts, and chat. The reader’s natural response is to think that the writer is being negative. In his article, 3 Ways Your Brain’s Negativity Bias Affects How You Communicate, Ellis Friedman states “...our brains are built to react more strongly to negative perceptions. This means we’re more influenced by comments, experiences or interactions we (correctly or incorrectly) perceive as negative which can adversely affect our performance.”
It is important to avoid using phrases which imply one is smarter or that one’s way is better. If something needs to be done a certain way, ask the author of the document or code what their thoughts are on doing things differently. Stating ‘change this to that’ could easily be softened to ‘if we were to change this to that, would it be more effective?’ A small alteration can aid in removing the opportunity for the receiver to experience said negative bias.
Distance and time zones present distinct challenges to global companies with global cross-functional teams. At SmartBear, we use a lot of different tools to assist us with overcoming those challenges. Collaborator, a peer code and document review tool that we develop, is used every day by many of the different SmartBear departments. We utilize a number of other tools as well. A large part of our successful communication is due to our daily standups. These standups do not just include development and QA. Our sales engineers, support, marketing, and customer success teams also attend. It is not that members of these teams are on every peer review or in every meeting, but they are always welcome. Because we are separated by location, our video based standups have allowed us to have face-to-face time. When conversations get heated, remember that humor translates across cultures and is a great way to diffuse the situation.
If you’re not utilizing a video based conferencing platform, I highly recommend that you start. Consider looking at tools similar to Skype and Slack. Our messaging platform channels are always buzzing with conversation and every peer review automatically shows as a link within the channel. If someone is curious about a change, they can click the link and read or participate in the review. We try very hard not to be siloed and encourage anyone to jump in and ask questions. Seeing our developers and QA team members willingly participate in answering questions for our sales team is an awesome thing to witness. It is normal to occasionally encounter a team member who is reluctant to participate in reviews or do video conferencing. Many people are shy or feel like they will be put under the microscope and judged. Encourage them to participate without their webcam or join peer reviews as observers until they are more comfortable. However, set some level of expectation that they should engage more fully in a few weeks or a month's time. They will begin to see and experience the benefits of improved communication.
Ultimately, the goal is to build a culture of collective ownership. To accomplish that task requires intentionality. Managers should aim to give people the power to make their own decisions. Providing people with the flexibility to make mistakes and not be chastised gives them an opportunity to not only learn but encourages them to own solutions to both new features and problems. Organizations are typically “top down” which creates a leader-follower culture. The problem faced in this culture is that people do what they are told regardless of the outcome. It also encourages employees to keep silent when they recognize situations that could be problematic. Instead, encourage your teams to have a leader-leader culture. This allows everyone to work together for the good of the team and the organization.
In his book, Turn the Ship Around, Captain David Marquet describes a scenario where he issued a command aboard the USS Santa Fe that was physically impossible to fulfill and because of the leader-follower culture, no one spoke up. Thankfully, it was during a training exercise, but it could have been disastrous otherwise. Though most of us are not developing safety critical applications, it is important for collaborators to be empowered to share their concerns and provide solutions. When they do, they take ownership, which results in happier employees, better products, and ultimately more satisfied customers. Creating a leader-leader culture comes down to having open communication across functional teams where people feel safe to freely share ideas and respectively question decisions.
Most of us take pride in the work that we produce, and we want our products and fellow employees to be successful. Take the time to encourage positive communication between team members, remembering that there is a negative bias in written language. Offset that by having face-to-face time, so that people can better read one another. Encourage co-workers to share ideas and openly discuss designs, requirements, and source code. This type of communication encourages collective ownership across functional teams. It is not just about communication - it is about allowing people to be leaders.
Opinions expressed by DZone contributors are their own.