DISQO’s engineering teams have gone through many phases of maturity, and one of the leading principles of our work as an organization is collaboration. While our numbers continue to grow, we’ve retained some of the qualities that make start-ups a powerhouse for learning.

In this article, we will talk about one of the main principles that drive our success - collaborative engineering. Collaborative engineering, covered in the International Journal of Collaborative Engineering, is not a new concept. Simply put, collaborative engineering brings together stakeholders for a given project and has them work together for their mutual benefit, regardless of their attachment to a specific team in the organization.

While we work within the context of teams at DISQO, we put the end goal ahead of any team distinctions. We often have individuals across multiple teams collaborating on a single shared goal. This flexibility combats the idea that only one’s team success matters and lets individuals focus on the organization’s health when it’s necessary.

Collaboration within and across our engineering teams builds:

  • Knowledge-sharing among tech, product, tech writing, and data collaborators.
  • Creative solutions, through honing in on each other’s expertise and experience. In turn, we build a better understanding of each individual’s abilities and propensity for learning.
  • Improved internal communication as individuals become better speakers and listeners.
  • A sense of product ownership and pride increases an individual’s charge for the success of a product.
  • Trust that we can rely on each other, rather than feeling pressured that a product’s success depends on a single individual.

Knowledge-Sharing

We break apart silos through knowledge-sharing and disburse critical information about our products to other team members whose work depends on knowing how specific systems operate. One of the essential ways we enable knowledge-sharing is by making guides and API documentation easily accessible to teams. Our internal documentation system democratizes access to information within our engineering organization. Read more about our approach in We Built an Internal Documentation System.

We also encourage any team member to participate in the decision-making process and learn more about the goals behind proposed new changes and products. One way we get everyone involved is through our RFC process, which we introduced last year. Learn about our introduction to RFCs in How Request for Comments (RFCs) Are Opening Discussion in Our Engineering Org.

Creative Solutions

Collaboration boosts the impact of creative solutions. While we work in autonomous teams, it’s a priority to share our successes and lessons with other teams so that we can all build better products in the future. While planning and building our Survey Junkie Pulse Desktop Application, my team worked with the Purple Electric Penguins (PEP) team, which manages the Survey Junkie web experience, to adopt an opt-in flow they’d already successfully implemented. They gave us a leg up by building a usable foundation. If we hadn’t engaged with the PEP team to collaborate, we would have had a lot more work to do, and the implementation would have potentially not worked as we wanted it to work.

While we work in autonomous teams, it’s a priority to share our successes and lessons with other teams so that we can all build better products in the future.

When we created our internal documentation tool, we researched ways to integrate with our SSO (single sign-on) solution. After the integration was complete, the approach taken to enable SSO integration became the de facto standard for our other products. With this collaboration style, we can also iterate on previous work rather than continuously starting from scratch since there’s no inherent competition between teams.

Improved Internal Communication

Collaborative engineering allows all members a voice. We practice an active open-door policy and open communication between individuals and their leaders by providing multiple communication channels. Each individual meets a minimum of once a week with their direct manager to discuss any topics. This way, each person does not have to seek out a listener actively, and potential issues live imminently within the scope of a predefined weekly session.

Along with allocating weekly time for individuals to formulate and share their work experience, we also prioritize acknowledgment of individual and team-level contributions. DISQO uses the tool 15Five, in which we record anything we want to bring up to our managers. But we also use a feature called a “high five,” where we can publicly send each other virtual high fives to thank others for their help in accomplishing weekly tasks.

More informally, we also have a channel dedicated in Slack called #shoutouts, where individuals frequently write praise for accomplishments. Recent shoutouts celebrated Platform Engineer Nagaraju Balusa for becoming an AWS Certified DevOps Engineer and Senior Software Engineer Jigar Shah for becoming an AWS Certified Solutions Architect.

Sense of Ownership

Throughout DISQO’s history, we’ve always clung to the idea that individuals should feel a sense of ownership over their work. We were able to promote a sense of ownership by Integrating Acceptance Testing into the Software Engineer Role. We found that by making roles more adaptable to changes in the organization, we were able to retain personal autonomy and pride in work.

We found that by making roles more adaptable to changes in the organization, we were able to retain personal autonomy and pride in work.

Sense of ownership is not just felt by those who built the first version of the product. One of our onboarding process’s main focuses is developing a sense of ownership in new employees working with the product by adding new features or performing maintenance. Cultivating ownership goes hand-in-hand with understanding the code itself. Plus, ownership makes for more vigorous advocates of the product and encourages people to speak up when they know we can be doing something in a better way.

Trust

We build trust through collaborative engineering by being open about decisions and changes to the company’s and products’ vision. Trust within the team comes through individuals understanding that they have the space to make decisions and promote their perspective on their products’ state.

One of the ways we practice trust is through our retros (retrospectives). We use retros to open up communication within our teams and improve team dynamics. Individuals in the team provide their honest opinions in a discussion at the end of a sprint. Learn more about our retros in A Look at DISQOTECH Retros. Trust levels the playing field because it requires respect among team members, thereby knocking down any pedestals that could impair the product’s focus.

When we see the team as a living organism, rather than separate and isolated parts, we can better view the roadmap to guide us to success.

When we see the team as a living organism, rather than separate and isolated parts, we can better view the roadmap to guide us to success. Collaboration in practice identifies the common goal and rejects the mentality of thinking solely about your own team’s success - we’re individuals who are not competing but rather complementing each other. One team’s benefit should not damage another, and thinking in such a way would damage our collaborative efforts. In our Collaborative engineering culture, ownership and responsibility lie in the individual’s ability to leverage their strengths and work with others in leveraging theirs.


Nej Kutcharian is a Staff Software Engineer at DISQO who likes to build cool stuff and help others to the best of his abilities throughout the organization. In his spare time, you can find him learning to cook new recipes, tinkering with open source projects, or playing video games with his wife.

See more articles by Nej Kutcharian.