Feeding the beast – writing tasty dev tasks

Is your task backlog getting packed? Is it getting hard to manage priorities? Maybe the problem is with how well your development tasks are being “cooked”!

This blog post is about “feeding the beast”. Yes you read that right:)

In early stage product-led startups, the largest department in size and in cost is the engineering team. Often referred to internally at Swimm as “the beast”. The way we feed the beast will directly affect the product, the progress of the product, and the company. Therefore, it’s important to keep them fully utilized.

Just talking about feeding the beast to keep them busy is overly simplistic. Maximizing the utilization of this team is not enough. We don’t just need to keep them busy. We need to talk about maximizing results, which means working on making development more efficient and producing a successful product.

This is what we learned from our growing dev team at Swimm and cooking up or prioritizing delicious development tasks for our sprints (internally called heats).

Developers – this blog post can be shared with stakeholders who feed the beast in your organizations, including sales, product, marketing and DevRel, as well as the people who translate user feedback and customer requests into development tasks. You can use it to improve the way they feed the beast at your company.

Meet the chefs 🧑🏼‍🍳👨🏼‍🍳

Where is the food coming from? Everywhere across the board from Sales to product roadmap, user feedback or Marketing.

When the different departments supply feedback, they generate grocery items, not the actual food. And the beast, it doesn’t like to cook, so to speak. We need to take the pile of groceries and cook for the beast, to ensure it will be utilized in the best way.

So meet the chefs – the product team! The product team slices, dices and creates meals for the beast from all the groceries. Here at Swimm we are still working on the best recipe and cooking methods, but first, let’s understand how to detect the symptoms.

Detecting when the food is bad 🤢

So what are the signals that the food is bad?

• Procrastination –  A “well fed” developer will happily jump into implementing it’s pending tasks. The first signal for untasty food is when it stays on the plate (or in the task management tool you use) for too long. Dev’s might touch it sometimes, but don’t eat it.
  Procrastination causes task hoarding and makes it hard to understand what is finished and what needs more attention.
• Pushbacks – A “well fed” developer is an enabler, a one that believes that everything is possible. When you start getting push backs like “We can’t do that in the current framework” or  “it will take a lot of time” or “it requires a massive refactoring” often it means that the beast is upset and there is something wrong with the food.
  Pushbacks create friction and energy is lost for the wrong cause.
• Alienation – Us vs. Them – A “well fed” developer understands the joint effort and usually talks using the word “we”. When the beast starts to use the term “the product team” or “you” or “Them” it is a good sign for poisoned food. Alienation causes delegation loops and breaks collaboration.

It’s all about the title

All of the symptoms above are wasting your team’s energy, tasks repeatedly overspill from one sprint to another and eventually causing you to miss the deadlines. Some of them can be avoided by the way we write our tasks.

A good task starts with a good title, good titles help developers understand and estimate the task better, managers to decide who to assign the task to and product managers to prioritize more easily and get a clear picture of a sprint’s contents.

Let’s look at some practical tips on writing good task titles.

Tip #1: Don’t delegate work

No one likes to do other people’s work, so don’t delegate yours to the engineer. Specify all the details so the developer can go straight to fixing the problem, instead of trying to figure out what needs to be done. If an issue needs more product work, do it before assigning a task to a version. If you’re cutting corners, the devs will feel it.

Tip #2: Be explicit

If it is too ambiguous and requires a meeting with someone it will be postponed.
When you open the fridge hungry you just wanna grab something…

Tip #3: Be concise

A very long title makes it hard to understand the problem, it will usually cause confusion. This is where we need to balance, making it too short might break the previous tip and make it ambiguous.

Tip #4: Avoid internal terms

Terms change. In time things that we know now will be forgotten, and requires onboarding.

Tip #5: Delete generic tasks

Delete tasks that are always true, like “Make performance better”. It’s obvious…. Unless you are making a specific effort (that needs to be explained) this task will just linger in your backlog forever, making it hard to see other tasks.

Priorities and development tasks

There are two main things I’d like to emphasize about prioritization.

Small t-shirts first

Sometimes it’s hard to get the easy stuff done, and it gets postponed from version to version. This is why we created the  “small t-shirt 👕” label , which is what we call small dev tasks. At the beginning of sprints we all sit together for two hours and each developer fixes two small t-shirt labeled tasks.

The boy who cried wolf

It is not uncommon to use the label “urgent” too many times as a means to indicate priority. It quickly loses its meaning. That’s why there are a lot of urgent tasks that just get postponed to the next version. So we force ourselves to be mindful and think hard about what is really “urgent” in priority.

A better way to frame this could be thinking about the impact on the product, and not the deadline. We need to differentiate between urgency and impact. Another name for this is actually “blocking” — meaning, questioning if a version cannot go live without this tasks.

Conclusions on upgrading your task recipe:

Many times a dev tasks needs another round of cooking before it can be served as food to the R&D team.

All in all, the secret ingredients boil down to a detailed account of the task, its area in the code or product, the action it requires (fix/create/redirect) the logic and its importance. It starts with a good compelling title that the team might want to open to begin with.

By writing clear and concise tasks’ titles, you can ensure the engineering team will manage and resolve your tasks quickly and efficiently.

…

If you want to see Swimm’s knowledge management tool for code, sign up for a 1:1 Swimm demo.