A focus on standard developer collaboration practices and how they should be modified to better enable developer productivity.
Fahim ul Haq is the co-founder and CEO of Educative, the world's leading upskilling platform for and by developers. He is a former software engineer at Microsoft and Facebook with a deep passion for creating better, more efficient ways for developers to master in-demand skills.
I’m not the biggest fan of meetings (in fact one of Educative’s company values is “fewer meetings”). In my experience, a string of high-communication, yet low-collaboration meetings is the bane of any developer’s workweek. While it may seem obvious, I have found that creating structure to support and encourage collaboration – while better managing communication – can be immensely helpful for engineering teams.
First, let’s define what we mean by communication vs. collaboration.
“Communication is simply sharing or exchanging information.
Collaboration is working with others collectively toward a common goal to create something or solve a problem.”
Generally introduced during early onboarding, communication guidelines and technology set the foundation for all intra-team and cross-team collaboration practices at the company. As a developer, ill-timed or unaligned communication could interrupt flow or work rather than improve collaboration. With engineering enablement in mind, ensuring that developers are technically equipped requires a delicate balance: finding the right blend of communication technology and practices to enable collaboration without compromising productivity.
We can split developer collaboration into two different types:
Let’s start by explaining each term:
Ephemeral collaboration comprises short-term and ad-hoc communication used to sync with teammates. It usually happens in messaging apps like Slack or Teams and typically includes asking for help, checking in on a teammate, or providing updates.
Long-term collaboration comprises future-minded one-pagers and documents for posterity and the learning process of future teammates. Examples typically include documenting or recording collaboration around earlier discussions that are necessary for quick decision-making in the future.
Defined and done well, both forms of collaboration enhance productivity. But when lines are blurry, your team may suffer from unaddressed tribal knowledge, lost information, or repetitive communication. As knowledge evolves, so too, should your forms of collaboration.
A strong framework for collaboration is even more important for remote or geographically distributed teams. For example, asynchronous and synchronous collaboration tools and guidelines should allow for seamless collaboration, while ensuring that people aren’t blocked (more on this in another newsletter). For now, I want to focus on standard developer collaboration practices and how they should be modified to better enable developer productivity.
Let’s cover 5 common settings for collaboration, and share what tools and processes you can employ to get the most out of each:
Standups should never be just a reporting exercise. If it is, the meeting title or time should differ from meetings dedicated to quick collaboration with team members. The worst standups are ones where it’s a task or reporting exercise for each person to show up and have the manager ask about a task, why it’s not complete, and what you have done for it so far. While there’s room for these questions, I believe it should be a secondary function for standups or be left for other less frequent meetings.
For the most part, standups should live under the realm of ephemeral collaboration. These happen in-person or on video conferencing tools such as Zoom and Google Meets. This method of collaboration should only be used for quick syncs and as a space for developers to ask for help or provide awareness to blockers.
The point at which collaboration in standups crosses into long-term collaboration is when a specific and recurring problem frequently occurs during these meetings. At that point, your team should record these conversations in documentation for posterity. More on this in the next section on Documentation.
A Solution
From a developer’s perspective, the frequency of standups determines whether it’s a reporting exercise or not. Keeping a lower delta between standups removes the need to provide an update at each meeting to talk about the past week and increases focus on the collaboration needed in the present to stay productive.
During my time at Facebook, the best standups were casual, with people chiming in to help at different points of the meeting. Managers were always on the invite but would only show up two to three times a month — and even then, it was optional. When they did show up, it wasn’t to get a report from every team member but more to give an update for the team to stay in sync or “FYIs” for the team.
To summarize, keeping the delta low between standups, a casual atmosphere, a separation of reporting exercises, and a low managerial presence help enable developers to stay productive and happy in their work.
Isaac Newton famously said “If I have seen further, it is by standing on the shoulders of giants”. Software engineering is no different. Without proper documentation, you’re living in a pre-printing press world — where engineers have to absorb and internalize information from scratch.
Documentation is a form of long-term collaboration that communicates prior discussions and information to arrive at a solution or decision. The documentation should reflect the journey so that future decision-making happens faster.
You're less inclined to document if your codebase is a few hundred lines — but as it grows to more than a 1000 lines, your engineers will need documentation to understand the codebase quickly without having to read through the code. The knowledge you’re creating today is important for someone in the future.
For example, at Facebook, there’s a wiki page called “great debates.” People would argue about the same topics repetitively (even topics as mundane as: “Should we have plastic water bottles or not?”) Every few months, someone would have a “new idea,” but instead of restarting the conversation, people can link to a past debate.
A Solution
We can all agree that documentation is vital for any collaboration (collaboration without documentation is just communication). What’s most important is how to manage documentation – i.e., what to prioritize, how to document efficiently and effectively, where to host your knowledge base, what tools to use to capture long-term communication, etc. (I’ll later cover a tribal knowledge reduction framework to avoid loss of knowledge).
It’s not just about the code, your customers, or the company. It’s about empowering your team with practices and tools surrounding documentation. It’s a fundamental, non-negotiable need for a thriving and enabled team (also critical for cross-team collaboration).
Documents that were written a long time ago can be important to establish current designs and can exist as:
Whether the documentation exists on SharePoint, Google docs, or Notion, if new members can’t easily reference and search documents, it’s useless. For new members to catch up on previous issues or circumstances, it’s worth investing in a documentation platform and building a framework in which these documents can be indexed, filtered, and accessible. The easier new developers have access to organized documentation, the faster your team will move in the future.
Problem
Most project management happens asynchronously these days. Synchronous modes of project management should generally fall into status meetings. Many developers go to Jira, Trello, or Asana as their choice of asynchronous tools and attend status meetings to get a more high-fidelity status on items or tasks their team is working on. Tasks they are blocked on or have issues on can be brought up during synchronous collaboration for resolution.
No matter the platform of choice, there comes the point where structured project data has diminishing returns. For example, editing Jira templates can be cumbersome and tedious. But these earlier templates include a surplus of trackable objects, so it’s worth spending 1-2 hours as an initial cost to pare down unnecessary fields.
You can have multiple workflows, burnout charts, and sprint charts, and track sprint activity through these tools, but be cognizant of which structured data are most required to manage a task. If you notice something is rarely used, don’t use it.
A Solution
Your developers benefit from a simplified number of form fields to fill out. If you have 20 areas to complete for a task, developers would be less inclined to fill out a task or log multiple tasks because creating each task takes a lot of time. Instead of gaining more insight, you might lose some more useful data with broken-down tasks.
Along the line of simplifying task management, I advise that most tasks should be doable within 2-3 days. Bigger tasks should be split into smaller tasks, providing a granular view to track overall progress.
While some tracking elements are necessary and are good for granular structured tracking, they’re not as helpful for collaboration. There’s a nuance to gravitating towards collaboration-focused project management for your developers’ productivity. Think diligently about what insight or data it will provide you vs. the obstacle it would create for engineers.
I’ve seen many tracking boards with several iterations, days, and so many fields for overlapping data. While this can help the manager, there’s a cost in developer productivity.
Like with most tools, technically equipping your developers for engineering enablement also includes the more refined nuance of balancing vital metrics and their productivity.
Problem
“Are you there?” Can you check this real quick?” “Do you have time to jump into a quick huddle?”
Messages and emails fall under the category of ephemeral collaboration until an interaction is deemed essential to be recorded for posterity. Most developers prefer asynchronous messages (which also accounts for time zone differences) over email, but you can’t remove emails and automated emails in a developer’s workflow. While some emails are helpful for productivity, I preferred a model where emails were primarily used for scheduling and automatic status updates.
Every company defines their messaging culture, but more importantly, there should only be a handful of messaging tools at a developer’s disposal. Too many messaging tools grows the risk of repetitive conversations happening on different tools — with an amplified effect across several teams.
A Solution
Whether your organization uses Slack, email, Confluence, Jira, Asana, or Notion, choose the primary tools and stick with them. Your culture and tools will then shape messaging patterns. For example, during my time at Facebook, most conversations happened in Workplace, which kept communication and collaboration streamlined on one platform.
As for messaging frequency, there shouldn’t be a cadence for developer-developer messaging collaboration. More structured messaging might happen for managers to asynchronously message what’s happening across the team via weekly status updates. That keeps everyone in the know, and everyone knows what their team is working on.
Overall, developer-developer collaboration on messaging tools is highly technical. It’s when an idea is deemed necessary for posterity, should it be documented for long-term collaboration. Focus on providing your developers with just enough tools to collaborate on highly technical topics while limiting unnecessary or repeated communication within their daily work.
I’m passionate that meetings should only be anchored in Monthly or Quarterly planning meetings for engineering enablement. Weekly status report meetings feel like a hassle to most developers because some people derail the conversation, while others aren’t focused as managers show data.
(A general rule of thumb — if there are 15 people in a status meeting, likely nothing is getting done. People will zone out because it won’t feel relevant to their work.)
A Solution
On the other hand, Monthly & Quarterly planning meetings should be used for cross-team requests between teams like sales, marketing, and customer representatives. After product managers have prioritized requests in some order, developers can communicate which projects they want to take on. Some projects are mandatory, while some have leeway.
The idea of a collaborative meeting brings me back to a time when I’d spent hours coming up with a solution, yet it took one other brilliant developer who did their homework to bring our discussion to a better one. In other words, collaborative meetings require a group of people to do some preemptive “homework” to engage in valuable conversations.
If the manager is the only one communicating with the product managers, it’s probably not a good team culture. Developers should always be involved in these meetings. Even if managers represent the team, the manager should sit with the team after the meeting to finalize their team’s approach. This provides a collaborative approach for software engineers to feel ownership and motivation in committing to specific projects.
You’re not a team if you don’t have both ephemeral and long-term collaboration. Without basic communication and collaboration tools and guidelines, a team would not be functional in this age.
While collaboration can happen in various tools, formats, and processes, take the time to build platform guidelines around differentiating between ephemeral and long-term collaboration. You’ll find that this initial investment in time will help you and your team move even faster in the future.
I’ve had many conversations with developers of all levels about the downsides of poor collaboration. More often than not, a team without a dedicated collaboration framework will be full of unequipped new developers and overworked veteran developers. I have heard general frustrations that new people don’t have a way of learning and internalizing information independently – so they rely on veterans to understand information, which results in burnout.
Imagine if your new developers can quickly refer to well-indexed conversations or problem-solving discussions. Your veteran developers can keep their days free from having to respond to messages, while your new developers remain unblocked in ramping up with a new project.
Aside from internal team collaboration, the amount of overhead to collaborate with other teams is very large. If you designed an API and can’t share those learnings with other teams, you’re missing out on an important opportunity for transparency and collaboration with other teams. Furthermore, by investing in long-term collaboration documents, other teams can use your designs as a template for future projects.
Start developing consistent guidelines for your team or cross-team collaboration, and you’ll start to progress towards a thriving collaboration culture in the company.
I’ve only scratched the surface of how developer collaboration can improve in the various scenarios (I left out code reviews and repositories to touch on an upcoming newsletter). I’m curious to hear your thoughts on successful collaboration and solutions to difficult collaboration scenarios. Ultimately, I hope we can all agree that developer collaboration tools and practices should enable software engineers to be more productive and create incredible products.
As a software engineer turned founder, I am passionate about ensuring that developers are technically equipped. Here are the critical areas of focus...
Effective partnerships between product and engineering don't focus on shipping tickets. They focus on solving user pain.
Investing in a great build system is the lowest hanging fruit for developer productivity.