In early 2022, the Atlas engineering team faced a significant challenge of loneliness within their work environment. As a team focused on developing a new product and operating with a fast-paced approach, they frequently divided into small workstreams consisting of one or two individuals. However, they experienced a lot of isolation and loneliness resulting from this approach.

With the impending general availability milestone on the horizon, the team made a bold decision to implement an innovative solution known as the Uber Stream. This article delves into the team’s unique journey of delivering three projects simultaneously, to transform their work dynamics and overcome the loneliness problem.

Watch the video or read on for more ⤵️

Task loneliness is a unique form of loneliness, that can appear in any high-performing team regardless of function, however in this case - we’re focusing on software engineering teams. It arises when team members feel isolated and unsupported in their work. This is particularly common in high-performing teams juggling multiple responsibilities.

Task loneliness manifests as individuals feeling isolated in their work, unable to understand the progress of their teammates, and easily getting blocked without access to the necessary support due to communication barriers. At Atlassian, we recognized this issue and developed a solution called Atlas. Atlas is a teamwork directory that connects teams, work, and goals across an organization.

We embraced a startup mentality as we embarked on the journey of building Atlas. With a focus on moving fast and adapting to find product-market fit, we operated with small, agile teams to rapidly deliver new features. However, this approach had its drawbacks, resulting in the team spreading themselves too thin.

In a typical project squad at Atlas, engineering feature leads, developers, as well as a fraction of a product manager, designer, and product marketing manager, would come together to ship a single Atlas project. While this structure seemed promising and aligned with agile principles, it posed challenges and limitations.

We weren’t just dealing with one isolated case of task loneliness. We had over 20 developers on our team, each working in their own stream of work. In fact, in one of our sprint planning sessions back in May 2022, we had seven different streams with their own sprint goals happening simultaneously.

With so many streams running at once, we found ourselves moving in multiple directions, trying to keep up with the fast pace. However, despite our efforts, a common theme emerged in our retros: team members were feeling isolated from the rest of the team.

This wasn't your typical social loneliness that can be attributed to remote work, as we had embraced a remote-first approach even before the pandemic. This was something different. We conducted retrospectives and had one-on-one conversations to uncover the root cause.

And there it was: task loneliness. It was a new manifestation of the monster, with each stream becoming its own isolated world of work, leaving team members feeling stranded and disconnected.

Even when things were going well and there were two people on a stream, the lack of shared context and limited collaboration made victories feel hollow. There was only one other person who truly understood the intricacies of what you were working on. So, when we shared our accomplishments in team demos, it often felt like we were met with just a simple clapping hands emoji on Zoom, rather than the genuine excitement and recognition we craved.

We identified three key elements at play.

Recognizing the detrimental impact of task loneliness on our team, we knew it was time for a change. We agreed to tackle this issue head-on and transform our team dynamics to create a more connected and collaborative environment.

Our management team, being '80s kids and still finding the word "Uber" cool, introduced the concept of the Uber stream. The idea was simple yet powerful: instead of spreading ourselves thin, we would concentrate our efforts and resources to create a more cohesive and supportive environment.

Under this new setup, an Atlas team underwent a transformation while still maintaining engineering feature leads as part of the structure.

We decided to experiment with the Uber stream concept on three interconnected projects. The timing was perfect as we were preparing to transition from our beta phase and establish Atlas as a fully-fledged product.

These three key projects were crucial for our growth:

Each project had its own set of tasks and requirements, but they were all interrelated, sharing a common context and dependencies. To tackle this challenge, we assembled a team with more designers, product managers, product marketers, and, of course, engineers. However, the critical difference was that our engineering team would be working on multiple projects simultaneously.

By adopting the Uber stream approach, we aimed to use the shared context and synergy among the projects. While each project had distinct components and tasks, they were connected through their dependencies and overall goals. This experiment would test the effectiveness of concentrating our efforts on related projects and maximizing collaboration and knowledge sharing within the team.

As the feature lead of the Uber stream, my primary objectives were clear: beat the loneliness and ship the product's general availability (GA). Surprisingly, the order of priority was intentional. While completing the projects was essential for achieving GA, tackling the loneliness issue required a different approach and dedicated focus.

We implemented the three key rituals and practices within the Uber stream to overcome task loneliness. These strategies were instrumental in fostering collaboration and creating a supportive team environment, as well as helping us deliver exceptional results.

As the feature lead, I worked closely with designers, engineers, and an engineering manager who acted as our protective shield, allowing us the freedom to focus on our tasks. We also had two product managers, and while it may seem like a small wrinkle, it served a significant purpose.

To effectively manage the three separate Atlas projects, we recognized that stakeholder communication varied based on the project. Rather than trying to consolidate everything, we embraced the idea that different projects require different approaches. We developed well-defined engineering plans to provide clarity and ensure that team members didn't feel lost at sea. These plans were shared with the entire Uber stream, fostering a shared understanding of the deliverables and maintaining a high level of context.

Additionally, we created a sequence diagram, similar to a Gantt chart but simplified. This diagram focused on two fundamental questions: what's first and what's next? It provided a clear roadmap for each team member, allowing them to know their own tasks, stay informed about others' progress, and understand their next steps. This aligned with our core principle of flexibility, encouraging team members to lend support and hop between projects when needed, trusting that their contributions would ultimately drive value.

By embracing our team structure across multiple projects, we fostered a collaborative environment where everyone could flex and assist one another. No one was left to face the metaphorical saber-toothed tigers alone. We focused on helping each other, leveraging our collective expertise, and ensuring that the team's success took precedence over individual tasks. This was the first ritual we established within the Uber stream, harnessing the power of our team structure and promoting a culture of trust and mutual support

The second ritual we implemented was focused on communication. Since we worked on a communication product, it was only natural that we emphasized effective communication within the Uber stream. We knew that loneliness often stems from a lack of communication, so we took deliberate steps to address this.

First, we leveraged async communication through Slack channels. For every project we worked on, we created dedicated open Slack channels. These channels were accessible to anyone in the company, encouraging drive-by support. It was incredible how often someone would wander into our channel and offer assistance, keeping us unblocked and moving forward. We also fostered a culture of honest and fun communication, recognizing that these projects would be challenging. We embraced playful banter and encouraged asking questions, creating a pressure valve for the team.

One crucial aspect of our communication ritual was banning project-related conversations in direct messages (DMs). Instead, we insisted that all project discussions should happen in the channel threads. This decision was driven by the desire to keep context high and avoid information getting lost in private conversations.

By keeping everything public, the rest of the team could learn, contribute, and help one another. After all, what's more isolating than an unanswered DM? We believed that breaking down context silos and maintaining transparency within the channel would foster a stronger sense of collaboration.

In addition to async communication, we established two main communication cadences. These regular communication checkpoints provided a clear structure for team members to ask for help, realign their understanding, and stay updated on project progress.

​

We deliberately thought of this as a connectedness ritual - not a task-tracking one. Our asynchronous stand-up prompt was simple yet effective: a good morning and sharing our plans for the day. We deliberately kept it open-ended, allowing people to use that question however they wished. Whether it was venting about a sleepless night or requesting assistance for a challenging task, we encouraged open and honest communication.

We adopted async stand-ups not only for the Uber stream but across the entire Atlas team, forgoing synchronous stand-ups entirely.

​

Every week, we gathered as a group to write our status updates in Atlas. These meetings quickly turned into demo parties, where we squeezed in all the demos and shipped features into the limited character count of an Atlas update. These meetings were an absolute joy, filled with excitement as we celebrated our accomplishments.

We made a conscious effort to highlight and recognize contributors, expressing gratitude for their efforts. Writing Atlas updates could sometimes be intimidating, but by sharing them openly, even those who were simply lurking in our Slack channel could witness our progress and lend a hand if they wished. Our emphasis on open communication and asking around ensured that everyone felt comfortable interacting with one another, maintaining a sense of unity within the team.

Now let's dive into the third ritual - the vibe check. This was a net-new addition to our project and consistently hailed as one of the best things we did, so let's explore it further.

The vibe check is like a mid-project retro, a “mid-mortem”, and a group therapy session all rolled into one. It's a synchronous meeting we hold around the midpoint of a project to realign ourselves on three key vibes: the team vibe, the user experience vibe, and the delivery vibe.

During the team vibe portion, we take the time to check in with each other and see how everyone is feeling about the project. We can gather all sorts of metrics and data from our task-tracking tools, but ultimately, it's the human element that drives the project forward.

We recognized that humans are driven by emotions, and sometimes work gets blocked by people who are blocked by their own feelings. By creating a safe space for open discussions, we uncovered hidden concerns and dependencies that were silently weighing on all of us. Once we brought them to light, we could take decisive actions to address them. So, by asking how everyone was feeling and what was going on, we were able to tackle the loneliness and isolation from support head-on.

By openly discussing and resolving challenges, no one felt like they were the only ones noticing a particular issue. Everything was out in the open. We then went through each deliverable listed in the initial engineering plan and discussed its progress. How far along was it? Any roadblocks?

Most importantly, we asked, "What imminent catastrophes do you foresee? What dragons have you encountered on the road that we need to slay?"

This part was incredibly valuable. It allowed us to highlight potential crises before they become full-blown emergencies. It's like a “mid-mortem”, far superior to a pre-mortem where everything is hypothetical. The fears and challenges discussed in the vibe check were real, happening to our team in the here and now. By addressing them promptly, we could take action and prevent future pitfalls when starting new projects.

We designed the vibe check as a synchronous meeting to remind everyone that their teammates are there with them. We're all pulling together, moving in the same direction.

Now, let's revisit the initial problems we identified with task loneliness. The small fragile teams? Well, we tackled that by fostering open communication, ensuring that no one is left alone in the path of the tiger. The vibe check helps us realign and ensure we're all on the same page.

Context barriers? We break them down through our team structure. Everyone flexes where they're needed, sharing knowledge and support. When it comes to being easily blocked, our team structure allows us to jump in and help each other across projects. Once again, the vibe check plays a crucial role. It helps us identify what we might be missing, refocus our efforts, and ensure we deliver on time.

In October 2022, we successfully launch Atlas to all customers. It happened exactly as planned, and on the same day, our first paid trial began. As someone who has been involved in product launches before, this one felt truly special. The greatest compliment we received about the rollout was when it was called "boring", i.e. there were no issues with it whatsoever.

However, the real question was: did we defeat task loneliness? Being an engineering team, we did what we typically do when we're unsure about something - we ran retrospectives. We invested several hours in this, writing extensively and engaging in valuable discussions.

Many positive aspects emerged, including the camaraderie within the team and the early alignment established through engineering plans. The shared language, and the unique conversations we had, all contributed to our team culture. Additionally, the flexibility we had in moving between different work streams proved to be a significant advantage.

Of course, it wasn't all smooth sailing. Loneliness is a polymorphic monster that can sneak in even when you're actively watching for it. Unfortunately, one of our engineers ended up feeling isolated for longer than she should have. This served as a reminder that we must remain vigilant in combating loneliness, even when we think we have it under control.

Nevertheless, looking back at our initial problem statement, we can confidently say that we tackled these challenges quite effectively. The retrospectives and feedback provided us with a sense of accomplishment, confirming that we had successfully addressed the fragility, minimized context barriers and maintained a healthy workflow.

Having a larger pool of people who can flex between projects is an absolute game-changer. The smooth movement and collaboration are simply fantastic.

And here's a not-so-surprising revelation: team culture trumps everything else. We put in the effort to cultivate a strong bond within our group, and it paid off when things got tough. It helped us come together, push through challenges, and move forward as a united team.

When you strip it down to its essence, the Uber stream was nothing more than an ideal sprint team. We were a small, tightly-knit group with a clear focus, a sense of ownership, and the space to form strong connections and deliver exceptional results.