What makes a group of individual contributors a team?
You can look at today’s product development teams as an ensemble of craftspeople from different disciplines. Code builders, design artists, storytellers, and an orchestrator. Similar to an orchestra, their output is based on the ability of each and every one of them to work together in harmony, continuously and collaboratively.
Let’s dig a bit deeper into today’s development methodology to see what this means in a practical sense.
At a high level, we see three major steps: planning, development and release.
- Planning = Empower design craft
- Development = Empower code building craft
- Release = Optimize time-to-market (since there is no more time for nonsense!)
Despite the fact that teams are supposed to work together and be very in tune with each other, when we look at the reality, it’s very different. We actually work in silos, nurturing black-box thinking. Instead of collaboration, often there are three separate units that comprise a whole, solely with interfacing endpoints.
In such a configuration, it’s unavoidable that one unit’s priorities will be disruptive to another’s work, or flow. Without better integration of the actual collaborative parts of the work, in the form of frictionless and ongoing feedback throughout and during the end-to-end planning, development and release processes, eventually, your own unit’s priorities will take precedence over another’s.
Engineering IRL
A typical engineering process, whether it’s a new feature being developed, a bug fix or any other kind of collaborative work, usually looks like this:
- A developer receives a design handoff and, from that moment on, is expected to deliver a working manifestation of the design specifications.
- The developer gets to work (whether solo or on the dev team; independent of product or design, at this point) based on the specifications and starts writing the code.
- Once completed, the code is deployed to a pre-release staging environment, where the designer actually experiences the result of their craft for the very first time.
If you’ve been through similar processes, you’ll agree that, by this point, there is rarely time or tolerance in the process to iterate or provide feedback, nor correct much at all. More often than not, the mindset in fast-moving organizations is to stick with what we have ready to ship and just move forward. The actual “collaborative” part of the work is essentially bypassed. It’s really just a relay race of passing the baton downstream.
But this engineering paradigm has its consequences. Ever tried to dissuade an artist from providing their feedback? Expect a pretty bad vibe in the room (or virtual room in today’s hybrid and remote team structure).
This example, of course, is actually a virtual utopia of the development process. In reality, most organizations today have a far more destructive culture of continuous disruptions.
Now, let’s spice up the scenario with some real-world interruptions that often break the ongoing individual flow.
When a craftsperson is in the zone and creating, don’t interrupt! But what can you do when there are so many things happening in parallel? In small organizations that are just ramping up, most people are juggling much more work simultaneously.
What often happens looks a lot like this:
Jolene from sales requires a specific version for customizing a demo for a super important customer; Marko from support has opened 31 tickets you have yet to handle since it is a production issue that affects end users; your beloved single staging environment broke and you can’t review any new feature—oh, and don’t forget to attend the three meetings scheduled for today.
Frustration, anyone? I like to call it the ‘multi-context bad habit.’
Okay, I can already sense some eyebrows being raised, and I can almost hear you saying, “Yeah?! So what? We’ve always worked this way—what’s the issue??” Allow me to show you some numbers that may surprise you.
“Finding flow is key, and interruptions are a drag. Minimal or no interruptions give developers an 82% chance of having a good day, but interruptions throughout the day decrease the chance of a good day to just 7%.”
Eirini Kalliamvakou
“Meetings are both awesome and terrible. Collaboration improves our work, but too many meetings can be a blocker; going from two to three meetings per day lowered the chances of making progress toward their goals by 60%.”
Dr. Nicole Forsgren
To summarize, these data points basically indicate that disruptions, interruptions and the “multi-context bad habit” ultimately have a tangible, detrimental impact on results and outcomes. They diminish successful outcomes and delivery times by orders of magnitude.
Zero-Click Deployments as a Culture
Fortunately, there are multiple practices and tools today that can be leveraged to dissipate the friction, break down the silos and improve the flow.
This can be achieved by evolving from one-click deployment to zero-click deployments. Allow me to explain.
Today, we have enough working examples that could (and should) be replicated more widely in engineering practices. Here are some examples.
Preview Environments
Preview environments (sometimes referred to as ephemeral or PR environments) provide, well, the opportunity to preview products. By allowing multiple stakeholders to review and experience the product throughout the development process, you shift-left the way you manage your development processes and are able to provide the relevant feedback and fixes earlier in the process. This basically means that for any PR you get a live environment that is shareable and independent from your staging environment. (I like to call this an in-development feedback loop).
The JAMStack
Another good example can be taken from JAMstack. When JAMstacking, consider using Netlify, Vercel or AWS Amplify to gain this capability for your team.
Infrastructure-as-Code (IaC)
If your project is non-JAMstack, you can consider building a similar preview environment through IaC solutions like Terraform or Pulumi. The downside here is that this comes with quite a bit of hassle, as you have to build automation for every single PR to have a dedicated shareable URL of the environment for review.
This is great, though, because it democratizes the PR approval cycle by being more inclusive. Project managers, designers—practically anyone can review and approve the PR in development without having to wait until the end of the process to provide input. It’s easy to manage as it is isolated and independent of staging, which also provides always-on issue reproduction ability in the event that some kind of bug was discovered or tests need to be run during the development phase.
But it also isn’t all roses and sunshine.
There are some gaps and challenges that still need to be overcome for this to work. Some examples:
How do we streamline feedback?
Developers are used to getting comments from peers during code review in a language they can understand easily (for the most part) and quickly merge the input into their project. They don’t lose context by navigating away from the tool they’re working in (e.g. to Slack or Acme Corp. Task Manager), as it keeps them in their source code management environment (SCM). We need to think about how can we offer the same developer experience for everyone in the process to minimize PR turnover.
How do we provide actionable and quality feedback?
For example, UI and behavioral issue reporting are time-consuming, since you have to document and explain what, exactly, needs to be changed in order for it to be effective. Any wanted change likely involves the developer, which adds yet another disruption and interruption to their day.
Taking Zero-Click Deployments to Single-Click Feedback
If we want to optimize the developers’ flow, the next phase after simplifying the deployment aspects is to see how we add in the feedback layer in a way that isn’t intrusive.
We need to now take this mindset and empower what I like to call one-click feedback.
This isn’t a new concept, of course. Let’s take some inspiration from collaboration tools we all love like Figma, Miro and Notion.
What’s magical about each and every one of these tools is the ability to provide contextual feedback. This is important as it enables contextual collaboration. Any user is basically one click away from sharing their feedback while remaining in-context, increasing the potential for feedback to be dealt with frictionlessly.
This makes possible the following core values:
- Any person can easily point out something which requires the creator’s attention.
- The creator can instantly understand the feedback within the context of the project and what they are working on, and reply or tag another relevant peer for their point of view.
- The creator doesn’t leave their main work environment to prioritize the new task or give it the attention it requires. Just as designers do not leave Figma to apply feedback, PMs don’t need to leave Miro to apply theirs, and so on.
These tools welcome feedback in an inclusive manner while enforcing a frictionless workflow. No one is messing with the creator’s flow as it is also happening asynchronously—no need for meetings, syncs or coordination of multiple stakeholders. This is also much more inclusive and relevant for today’s remote work culture, which requires investment in team communication through asynchronous channels and processes to be effective. (Here’s a great talk to watch on this topic; yes, the irony of interrupting your flow to watch this video is not lost. No, Really, Don’t Chuck Everything in Slack: Communications for Distributed Teams – from Florian Haas)
Assuming you find some truth in this, I’d like to address the now apparent elephant in the room: Why don’t we introduce the same abilities for in-development collaboration?
One-Click Feedback-as-Code
We’re starting to see a trend where framework-coupled companies like Netlify and Vercel, for example, are adding collaboration aspects to their offering. Netlify, in fact, is acquiring a company, FeaturePeek, to embed collaboration features on top of their preview environments, and Next.js starting an early access rollout of their Next.js Live product.
Imagine developers getting inclusive feedback during the PR approval cycle; not only comments about their code from peers but also UI, design and behavior comments with all of the needed assets and context to move forward without leaving their work environment! Such a shift will have a measurable impact on time-to-market, quality and velocity when employing such a workflow.
The main premise here is that to achieve better metrics associated with flow (as noted above by Dr. Nicole Forsgren), we should not mess with the flow. The benefits of reducing the friction and interruptions in creators’ flow are exponential and will enable us to get closer to working in tune and in harmony (if we stick with the orchestral references) or simply more collaboratively, as a team where each individual is always maximizing the time they are able to be in creation mode, without silos or black boxes.
What do you think? What’s your view of how teams should work together? How do you handle flow within your organization?
