Devs shouldn't be managing everyone's communication

There is a mind-blowing phenomenon felt almost universally amongst coders like you and me.

Although we are paid to code, we are spending the majority of our working hours doing anything but.

According to a recent Venture Beat study, a typical engineer will have only about 10 hours of deep work time available during a given week. If we assume that a standard work week is 40-50 hours, that means that we are spending 80% of our paid working time not doing what we were hired to do.

While the specific list of tasks pulling us away from our real work will vary per-company, the Venture Beat study found that in many cases, it was related to overly complicated and time-consuming “communication processes” that we developers are forced to adhere to, or even manage. Before we know it, unassuming engineers are transformed into overpaid and under-qualified administrators or project managers who have no interest in spending time on this stuff.

If we take a step back though, these numbers shouldn’t come as a surprise.

After all, we live in an era where everyone and their grandmother has a SaaS platform of choice for any given task. And this is a phenomenon we see pretty clearly in pretty much any cross-functional dev team on the planet.

Try randomly walking into any tech company in the world (assuming humans are actually still coming into the office). Everyone on the team has their own set of tools to manage their part of the action. As you walk around this random office space, you’ll probably see the design team working in Figma, the project and product managers hanging out in Miro or maybe even (wince) Jira. And you’ll likely see the code owners spending most of their (legit) work time in Github or whatever other SCM tool they prefer.

Ironically, each one of these platforms advertises as a “collaboration platform”. But the reality is that each of these tools is used in relative isolation.

By relying so heavily on these role-specific platforms, teams create SaaS-based, function-specific silos that don’t really include the entire team. Each of these tools creates a kind of “SaaS pollution” that slowly poisons the workflow for the other members of the team. Because the use of these platforms ultimately adds hours of additional work for cross-functional colleagues who, at some point, will need to climb into these foreign tools and access the information buried within.

And so, it’s no surprise that we developers waste so much freaking time on other things. The nature of these “collaboration tools” forces us to spend hours jumping between browser tabs and setting up SaaS accounts. We spend 80% of our precious coding time trying to locate, understand and address the endless mentions, comments and tickets that come in from everyone else on the team. And even when we’re successful in doing so, we then need to close the administrative loop by resolving, relaying and communicating what we’ve done to the rest of the team.

So let’s just say out loud what we’re all really thinking to ourselves - this reality sucks.

Developers don’t want to be involved in ops.

We don't want to be managing communication protocols.

We don’t want to be doing administrative tasks.

We don’t want to be sending emails and updating Jira tickets.

We just want to code. That’s it.

This was basically our motivation for starting Livecycle. We’re a group of coders who just want to code and build. We know firsthand how annoying it is to be spending 80% of our time with all this other stuff.

The solution we envisioned (and ultimately built) would take this unnecessary load off of the developer’s plate. It would harmonize and coordinate all the incoming reviews so that all of that feedback becomes a single collection of actionable, contextual comments.

Here’s how it works in a nutshell: By installing Livecycle on your frontend repository, your passive preview environments become active, collaborative playgrounds. Once Livecycle is installed, anyone who opens the preview environment will not only see your work, but they can also comment on it, in context, on top of the product UI. It works together with your preview environment pipeline to add a layer of built-in tools that keep all review comments for you in one place, per environment.

For example - the designers can leave you screenshots, QA can record a video of a problematic use case, and the folks in marketing can even edit the product copy and send it to you as a suggested change. Since everyone is working together in the same playground, you don’t have to go running around trying to piece together everyone’s feedback.

(Here's a quick video:)

Now, to be clear - Livecycle doesn’t aim to replace any of those other SaaS platforms, it actually enriches and enhances them. Because by integrating with those task management tools, we make sure that all the relevant review comments get synced to all the right places. And new tickets can include links back to Livecycle with a visual reference to the relevant issue.

We think we're on to something (more and more dev teams are trying it for themselves and telling us the same). So hopefully all the developers out there can finally stop worrying about ops and communication rules and Jira tickets and just focus on coding.