Nurturing a Collaborative Engineering Culture: Active Strategies and Best Practices

There’s an old proverb that goes: “If you want to go fast, go alone. If you want to go far, go together.”

In the realm of software engineering, I’ve found the same to be true. And the real-world manifestation of this proverb can only be achieved by fostering a culture of collaboration. Collaboration between Engineering, Product, Design, and the revenue organization, is paramount for success. As a tech lead manager, I've found that implementing robust engineering processes significantly contributes to cultivating such a culture. In this post, I'll delve deeper into our engineering processes, emphasizing active collaboration practices like pair programming, mob programming, agile methodologies, task grooming, sprint and project planning, and how they've shaped our team's culture of innovation and growth.

1. Establishing Clear Communication Channels

We prioritize establishing clear communication channels within our team. On my team, we conduct stand-ups via Zoom, and use Slack for asynchronous communication to ensure that information flows freely. Additionally, we encourage team members to reach out for clarification or assistance whenever needed fostering an environment of openness and accessibility.

Our preferred method of asking questions or for support from Engineering, Product, or Design, is through public Slack channels. Both to reach a broader audience but also to serve as a source for others to find, should they run into similar issues or have the same question. Doing so in public channels greatly increases transparency across the organization as a whole.

Additionally, many of the engineering teams here at OneSignal host open office hours on a weekly basis. These meetings serve to not only spread context and knowledge on the engineering front, but they are open to all departments, as well. This helps foster cross-collaborative communication and relationships, which makes for faster and better decision-making across the organization. When everyone is on the same page, it leads to less thrash and happier teams.

2. Cultivating Trust and Psychological Safety

Trust is the cornerstone of effective collaboration. To cultivate trust within our team, we prioritize transparency and honesty in our interactions. Team members are encouraged to voice their opinions, share their thoughts, and take risks without fear of judgment or reprisal. This active sense of psychological safety encourages creativity, fosters innovation, and strengthens our bonds as a team.

Knowing Your Team Beyond Work

In my experience, starting 1:1 meetings with a personal conversation sets the tone for open and honest communication. By taking the time to inquire about a team member's well-being, interests, or recent experiences outside of work, I demonstrate that I value them not just as contributors to the project but as individuals with unique lives and experiences.

This simple gesture helps break down barriers and creates a more relaxed and comfortable atmosphere for the rest of the conversation. To the previous point, while you don't need to be best friends with everyone on your team, having some surface-level knowledge about each team member goes a long way in building trust and rapport. Whether it's remembering their favorite hobby, a recent vacation, or an upcoming milestone, demonstrating genuine interest in their lives outside of work shows that you see them as whole human beings, not just resources to be utilized.

When individuals feel seen, heard, and valued by their lead, they are more likely to open up, share their ideas and concerns, and actively participate in team decision-making processes. This increased willingness to collaborate leads to better problem-solving, greater innovation, and ultimately, higher team performance.

One way to create opportunities for team members to get to know each other more is through team lunches. On the Journeys team, we host an optional, bi-weekly  lunch via Zoom, which is open to all team members. Other organizational processes to strengthen a team’s bond here at OneSignal also include our annual company-wide on-sites and offsites, as well as annual team on-sites, which are coordinated by individual team managers.

This recognition fosters a sense of belonging and appreciation within the team strengthening the bond between teammates and leading to happier teams. Happy teams are easy to work with and more productive. Now, I’m not saying that a happy team automatically makes for a productive team, because you can certainly have a dysfunctional team that reports a high degree of satisfaction, and that’s where team processes come into play.

3. Active Task Sizing and Grooming

Before embarking on any new project, we ensure that the tasks contained within said project are well-defined and properly sized. Task grooming sessions which involve the entire team’s input, enable us to discuss requirements, dependencies, and potential challenges, ensuring that everyone has an active and clear understanding of the work ahead.

By t-shirt sizing tasks, we establish a common language for estimating complexity and prioritizing work, contributing to smoother execution and better alignment of efforts within the team. And by sizing all tasks in a given project, we can gain a better understanding of the overall complexity, scope and risk of the project as a whole. Which then enables us to give more accurate estimates on capacity, time to complete, etc. This is, of course, something that can change over time, as we discover more unknowns, etc.

Now, I fully acknowledge that entire-team meetings are expensive, and overdoing them often leads to lesser quality and quantity of participation. With this in mind, for full-team grooming sessions, I prefer to keep the areas of concern for grooming limited in scope. We groom our backlog and our bug lists together as a team during sprint planning, but for individual projects, I leave the grooming up to the designated project lead and the project’s builders. This means that we need to have a standard process for grooming and sizing tasks across the team, which is expanded on further below:

Do’s and Don’ts of T-Shirt Sizing

DO

• Break down L and XL-sized tasks into M, S, and XS
• Reassess the t-shirt size of a task if it is taking longer than expected or uncovered other unknowns
• Be aware of scope-creep. If something else comes up during your task, question: should this go in the same task, or should I create another one?

DON’T

• Bring L and XL-sized tasks into a sprint. L and XL typically indicate that the task needs to be broken down more to be digestible or actionable
• Treat t-shirt-sizing on a per-engineer basis. Sizing should help standardize tickets across the team, no matter the skill level of the engineer who picks it up

Keep in mind, that it will be entirely team-dependent on how you go about sizing your tasks and the standard your team adopts, but here is a look into how the Journeys team here at OneSignal sets the standard:

Story Pointing is a key practice in Agile development that helps us in estimating the effort for different tasks or user stories. Instead of fixed time units, we assign a relative measure based on complexity, effort, and risks. This approach enhances our planning and resource allocation.

Story Points

1 Story Point / XS (Extra Small): A few hours of engineering effort. Typically involves quick and straightforward tasks.

2 Story Points / S (Small): Up to one day of engineering effort. Involves relatively low complexity tasks.

3 Story Points / M (Medium): Up to half a week of engineering effort. Involves moderate complexity tasks.

5 Story Points / L (Large): Up to one week of engineering effort. We want to break down tasks of this size into smaller, more manageable tasks.

8 Story Points / XL (Extra Large): Up to a full sprint's worth of engineering effort (2 weeks). Similar to "large," tasks in this category should ideally be further broken down into smaller tasks to ensure efficient progress.

Note: When determining the engineering effort, we should take into account the time needed for analysis, development, testing, and getting it into review, along with task complexity and the level of risk or uncertainty associated with the task.

4. Embracing Agile Methodologies

The adoption of agile methodologies has accelerated and matured our approach to project management and developing software.

Two-Week Sprints

By embracing two-week sprints, we establish a cadence that keeps us focused and accountable. Two weeks feels long enough to make good headway on projects and tasks, without being so long that the team starts to lose focus. We also set goals for each sprint, which are set on a per-project level and aim to capture a summary of what we want to accomplish over the two weeks.

Sprint planning

Sprint planning sessions ensure that tasks are well-defined and prioritized, and give other engineers insight into work going on outside of their own queue. It serves as a good process to help engineers prioritize what to work on and determine what will have the most impact. The two-week cadence ensures that we are reevaluating what the best thing to work on may be. Not to say that we are often switching projects because that only happens if interruption-worthy work comes up, but it’s a good exercise to be intentional about what work the team is pulling in and investing time into.

Sprint Retrospectives

Sprint retrospectives provide an active forum for reflection and continuous improvement. This active, iterative approach to development fosters adaptability, agility, and a shared sense of purpose among team members. Sprint retrospectives also serve to prompt our teammates to think about the way the team operates, and whether or not it’s working out for them as an individual, but also for the team as a whole. Having open discussions around whichever topics individuals on the team write down at the end of the two-week sprint provides members a real stake in how the team operates, and where we go next.

5. Pair Programming and Mob Programming

Pair programming and mob programming are integral parts of our development process. Pair programming allows team members to collaborate closely, share knowledge, and catch errors early in the development cycle. It also provides active opportunities for mentorship and skill-building. Similarly, mob programming sessions involve the entire team working together on a single task, promoting collective ownership of code and fostering an active sense of camaraderie and shared responsibility.

While pair programming is often ad hoc, there’s also value in having scheduled pair programming between individuals, as well. Being explicit about time-to-pair can make the engineers feel more comfortable about pairing, as there is “official” time to pair on something with their coworker, rather than feeling guilty about not getting their “own” tasks in their queue worked on. On the Journeys team, we host weekly mob programming sessions, where any engineer on the team can bring a task, project, or investigation to work on together. Whether it’s because they’re working on a particularly difficult implementation detail, or they’re trying to debug and track down a bug, anything is fair game to bring to the meeting. Additionally, I encourage the engineers on the team to schedule pair programming sessions between themselves on an as-needed basis, when working on projects together or venturing into uncharted territory.

Mob programming is done in a way where we have a “driver” and the rest of the team operates as the “brain.” That’s not to say the driver in this case is not participating in discussion with the brain (the rest of the group), but more that the pressure to think on the spot while everyone else is watching is limited, because the brain should be participating and directing the driver. This concept of mob programming also lends itself nicely to mob debugging, where the team takes a look at an investigation or bug together. It’s a great way to spread context about ongoing issues, spurs collaboration around a solution, and encourages the team to take ownership of bugs and investigations, rather than all of the pressure falling on to one engineer.

That’s not to say that we spend all of our time pairing or mobbing. In fact, too much of a good thing can have negative consequences, and we still reserve a majority of the work week to individual work. The amount of time spent pairing or mobbing will vary based on the team’s composition, complexity of projects, and level of expertise in the tech stack, so use these processes with discretion.

6. Operational Reviews

Operational reviews are a part of vital processes for mature engineering teams, especially for teams that have an on-call rotation and own systems that need to always be up. They provide a structured platform to assess past incidents, evaluate alerting systems, and scrutinize key metrics vital for service health. As a tech lead/manager, I've seen how operational reviews not only enhance our understanding of system performance but also foster collaboration and proactive problem-solving within the team. Below, I'll delve into the significance of operational reviews and how they contribute to optimizing service reliability and team effectiveness.

Incident Post-Mortems

Operational reviews serve as a space to conduct thorough post-mortems of past incidents. By analyzing the root causes, identifying areas for improvement, and documenting lessons learned, we establish a culture of accountability and continuous improvement. Through open discussions, we uncover insights that help prevent similar incidents in the future, ultimately enhancing our service resilience and reliability. We also identify patterns or incidents where we can create runbooks, to make the response to repeat events predictable and standardized.

Evaluation of Alerting Systems

Effective alerting systems are essential for timely detection and mitigation of issues. During operational reviews, we assess the performance of our alerting mechanisms, evaluating their sensitivity, specificity, and relevance. By identifying false positives, tuning thresholds, and refining notification channels, we optimize our alerting systems to ensure that critical issues are promptly addressed while minimizing alert fatigue among team members.

Analysis of Key Metrics

Central to operational reviews is the analysis of key performance indicators (KPIs) and operational metrics. We scrutinize metrics related to system performance, resource utilization, user experience, and error rates to gauge service health and identify areas of concern. By tracking these metrics over time, we gain valuable insights into system behavior, detect anomalies, and proactively address potential issues before they escalate into major incidents.

Collaboration and Knowledge Sharing

Operational reviews serve as collaborative forums where team members from different disciplines come together to share insights, perspectives, and expertise. By fostering cross-functional collaboration, we leverage diverse skill sets and experiences to tackle complex challenges more effectively. Through open discussions and knowledge sharing, we strengthen the collective intelligence of the team and empower individuals to contribute meaningfully to problem-solving efforts.

Iterative Improvement

Operational reviews are not one-time events but iterative processes aimed at continuous improvement. By incorporating feedback from each review cycle, we refine our processes, update our alerting strategies, and fine-tune our monitoring infrastructure. This iterative approach enables us to adapt to evolving requirements, mitigate emerging risks, and enhance our overall operational resilience.

Engineering Teams, Empowered

Fostering a collaborative engineering culture requires an active multifaceted approach that encompasses clear communication, inclusion, trust and psychological safety, agile methodologies, and active collaborative development practices. By prioritizing these practices, TLMs can create an environment where team members feel empowered, supported, and motivated to work together effectively towards common goals. As we continue to evolve and innovate in the ever-changing landscape of software engineering, let's remember that our greatest strength lies in our ability to work together as a cohesive team.

Looking to make a meaningful change in both your day-to-day and long-term professional fulfillment? OneSignal fosters a culture of team-based success and workplace flexibility, backed by an already industry-leading product that continues to grow rapidly (we’re approaching 2 million users!)

We are currently hiring for multiple engineering roles — we encourage you to explore our job openings and join our growing team!