DEV Community

Cover image for Devs shouldn't be managing everyone's communication
Zevi Reinitz
Zevi Reinitz

Posted on

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.

Top comments (5)

joelbonetr profile image
JoelBonetR 🥇 • Edited

That seems a good base project to me! 😍

I've some initial feedback (some better some worse) and a couple of questions though.

Disclaimer: For anyone reading this: I didn't tested the product (for now at least) so my feedback is just about the text above and a bit of information from livecycle website, hence I may be right or completely wrong.

Some things to clarify:

  1. That's not a study, it's a report (a cooked data output from one or more surveys), not done by venture beat but by Retool and Wakefield. They asked to ~600 -allegedly- software engineers (then they proceed to say "including both ICs and managers", hence I'm wondering how many of those 600 are Software Engineers in truth), in conclusion, it may not be close to the reality.

  2. As a Software Engineer your main job is not to code but to analyze, define and design. To ensure a good design you need a good definition, and to reach a good definition you need a god analysis, and a good analysis requires iterative communication. That's the reason for separating the terms software developer and software engineer. Every software engineer can act as developer but not every developer can act as engineer.

  3. Of course devs don't want to involve in "Ops", it's fun to do it in your free time (maybe) for your side projects and so but those are tasks for sysadmins and not for developers, hence sysadmins are the ones acting as "DevOPS" in the major part of companies but that's an un-related topic with the rest.

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.

You'll face some sort of bureaucracy in every possible job.
Administrative tasks? That's a nope as response on my side.

Managing communication protocols? That's for management, not for devs. Sometimes software architects, Tech Leads and Team Leads need to jump into that side as well, someone need to act as "glue" or to ensure certain information reaches every corner of the people involved in a project and that everyone is aligned.

Sending emails and updating Jira tickets, in the other hand is part of the job, and it's an important and necessary part of the development project, like it or not and I assume that we're all adults hence we can understand the needs of our own job without cries and tantrums.

Some questions

While this seems a good idea

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.

I don't really know how I feel reading it 😂😂
Will that means that people will annoy constantly in develop environment (which is NEVER an environment for people to test, neither a stable one)? Or will that be placed only in QA/UAT/Preprod environment? Which is a later stage and therefore the "catch things in an early stage" will became blurred and less useful.

What happens then with this feedback? Will it need to be copy-pasted into the project issues tracker hence increasing the bureaucracy? Or will livecycle act as issue tracker as well? If so, which integrations and capabilities does it have?

Good parts

I visited the website of livecycle and I feel that the most powerful features are those two:

If understood it properly, it will generate a preview per-commit or per PR. I'm wondering how many resources does it consume to do so but leaving this aside, I would love to have a preview for branch so, as you state in the text, other related departments can verify the developments.

Also, to toy around and maybe self-answer some of the questions above, does livecycle provide any free tier? Is there a way to self-host it or..? I didn't find a pricing in the navbar but the website does look like the product has a pricing 🤣

fyodorio profile image

Will that means that people will annoy constantly in develop environment

My worry as well 😅 this way we don’t get rid of the described problems at all, we only generate an additional set of 😫

palalet profile image
RadekHavelka • Edited

So if it is not aiming to replace them it is actually yet another platform to switch between ...

zevireinitz profile image
Zevi Reinitz

No need to switch between, because Livecycle is not an independent "platform". It's a layer that gets built on top of your preview environments that lets everyone mark up their review comments in context. There is integration with other platforms to sync info, but the idea is that developers can spend more time in context, without jumping to a bunch of other platforms

joelbonetr profile image
JoelBonetR 🥇

Hi @yaarahendel 10/10 response! Thank you so much, everything's more clear now 😁

I don't know what Linear and ClickUp are but ping me when Livecycle supports Jira, GitHub and/or GitLab!

Also while I collaborate with some OSS, I work mostly in private repos being on clients of mine or from the multi-national I work in daily as TL.

At this point I feel it has potential to overcome certain projects issues (You know what kind of projects I mean).

Maybe a YouTube video to showcase the features would be nice, so I can send it to the super duper senior architects and sales directors along Livecycle's homepage, this way they can check if this product could suit in any project 😊
(as I'm not the one managing project budgets, contracts and so 😂)