Getting cross-team collaboration right by creating more predictability around inevitable stressors
Ever made a roadmap that nobody bothered to keep tabs on? Maybe keeping it updated became a chore? I’ve seen this happen more often than not, and it’s usually an indicator that the roadmap isn’t emphasizing the right information
Most engineering roadmaps simply indicate what work is being done, when it’s expected to happen, and maybe whether or not it’s on track with the stated timeline. This might be plenty of information for an exec audience that’s just trying to get a high-level view of all that’s happening, but I’ve found it’s not nearly enough for the audience whose priorities and day-to-day might be impacted by that work.
Leading teams that collaborate across an entire department (or more) requires serious attention to getting cross-team collaboration right. A large factor in doing this is making sure everyone is prepared for what’s to come, in every way possible. With respect to roadmapping, this means we have to visualize what matters most to our stakeholders; simply answering “What’s happening?” isn’t going to cut it. Instead we want to focus on answering questions like:
- Who needs to care about this work and why?
- What side-effects can you expect from this work being done?
- How might this work impact your priorities and the decisions you make for your team?
These would be difficult questions to answer in an “at-a-glance” manner, but they can be used as a starting point to further uncover the tangible data points that are most important, informative, and easily visualized. For example:
- What is the likelihood of incidents during this work?
- What is the expected level of required cross-team involvement?
- What flexibility exists in the timeline for when this work can happen?
Here’s an example of what a roadmap focused on this information might look like:
In the above roadmap, a stakeholder can toggle between different views that give them a visual representation of what to expect for that data point. Currently focused on “Level of Involvement”, this visualization would denote to a stakeholder what projects require a low / medium / high level of collaboration from the teams listed, and how that might vary over the course of a project. (Internally, you must collectively agree on and document some standard definitions for what each of these values means to your organization. Teams leading these projects must also standardize on how they are going to estimate these data points.)
Imagine you are an engineering leader for a team focused on feature work for your organization’s main SaaS offering, and none of the projects on this roadmap are your team’s top priority or responsibility — rather, they need to be woven into your team’s already busy workload. If you look at the ChatOps V2 project, you would notice it requires every team’s involvement – but that it’s quite light to begin with, and picks up towards the end of Q2. Based on this information, you might choose to delay the start of a particularly complex feature in order to designate the proper resources to ChatOps when the time comes. Or maybe you dedicate more engineers to current feature work so it can ship before that uptick in required collaboration. Either way, being able to make an informed decision early on is going to create the best opportunities for collective success.
Getting an understanding of this information allows teams to better plan their own roadmaps, and prepares everyone for times that may be more stressful or pressed for bandwidth. On-call engineers might be more vigilant of what’s going on across the org when there is high-risk work in progress so they can feel more prepared for their shift. Likewise, customer support teams might know to brace themselves for increased support tickets. Engineering managers might know to pad deadlines for engineers who are in a phase of heavy collaboration on a project outside their normal priorities. All of this preparation allows for a more predictable workplace, which greatly softens the blow of any unexpected stressors that might arise. This makes engineers more resilient against burnout and prevents leaders from making decisions that might strain their employees in the first place. The better we can brace ourselves for challenging times, the less likely they are to have a detrimental effect on our well-being and success.
