On software engineering management

There is are lots of approaches to managing software engineers. I want to dispense my view.

Image for post
Image for post
Photo by S O C I A L . C U T on Unsplash

Do you see the above meeting room are empty? Why? Because the software engineering team is building a product!

You don’t need to manage engineers. Let them build things!

  • Build and refine the backlog together.

Scrum Framework tries to address a lot of this, so I will reuse common concepts from it in this document.

Image for post
Image for post
Scrum framework

Build the backlog

The backlog is the most crucial thing your team has. It should contain all the tasks the team needs to do to build the product. If you are using Scrum, it is a good idea to separate Product backlog (features and stories to be implemented) and Sprint Backlog (development tasks to be done) but keep them linked.

One of the ways to do it is using Epic task type for Product backlog and regular tasks Sprint Backlog.

Refine the backlog

Both product backlog and sprint backlog should be frequently visited to refine and add detail to the tasks. Both the product owner and engineering team should participate in this because they both contribute their experience and feedback to understand the scope of the task.

Make the priorities clear

Keep the most important tasks in the backlog at the top. But make no mistake, if you would like it to be done, it should contain enough detail to make it actionable.

Add enough detail to the most important tasks

For example, “Create a registration and login page flows” seems simple and easy to do, right? But, depending on the product, a lot of things can be done differently. Here are example questions the team might ask:

  • Should we create a social login?

Depending on the answers, the same product feature can take 2x or 3x time to deliver.

Scope and estimation

It is sometimes desirable to understand how much time it will take to implement a product feature from the Product backlog. There are two options:

  • Best guess from previous experience

Best guess from previous experience

If you and a team have experience implementing similar tasks before, you can together try to estimate the new tasks based on this experience. But remember, it will be rough, and it will be rough.

Ask every team member and ask why

It is important if everybody on the team shares their opinion and explains why they think it will take this time.

Estimate from Sprint Backlog

The best way to estimate is to refine product features in enough detail so it will be a list of actionable, independent development tasks on Sprint Backlog. This way it is easy to give an estimation for every task, and the product feature delivery schedule will be easy to understand.

Define together and understand the definition of done

You need to have a coherent view on that team means the task is done? Is it developed? Is it locally tested? Is it delivered to the testing environment? Is it live in production?

Often, the product owner view and development team view are different. It is vital to synchronize views and make a definition of done (DoD) a clear guide on how the team approaches to refining the backlog and defining Sprint backlog tasks.

It is common to revisit and change the definition of done as the product progresses.

When you start building a product, there is no live version. So DoD does not contain the “Deploy to production item”. Once you launch the product, you need to decide who owns the “Deploy to production” item in your company? Which team? In which team’s DoD it should be listed?

Help teams self-organize

Help does not mean steering the team. Discuss and explain why the priorities and delivery are essential. Help the team understand scrum practices. Establish and maintain the cadence of short daily meetings, sprint reviews, and retrospective sessions.

Understand comfortable for the team communication overhead!

Not every team would like to be interrupted every 5 minutes. In fact, I have never seen a team which likes it! Understand how the team would like to be consulted with, every day? Every week? Morning? Evening? It is good to communicate this across the company so people will respect the development sprint and focus of other people.

Make them accountable and reflecting

Communicate success to the team. Show how the features they implement are used and liked by users.

Retrospective sessions are one of the most important events your team can have

Use retrospective sessions to improve how the team works in a constructive way. Always develop an action plan after retrospective and discuss how it was executed on the next retrospective session.

Tech Lead & Software engineer with a passion for #DevRel, Serverless, Java, and Javascript. https://ruslan.org

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store