How to build an accountability culture in software engineering

A great software engineering team is vital for the success of a company.

Therefore, many resources, time, and knowledge go into improving their performance, making them more productive and creative—and rightfully so.

However, the key ingredient in leveling up their performance is often accountability. Great software engineers hold themselves accountable for their actions and mistakes.

In this article, we’ll dig into the ways to build an accountability culture in software engineering.

Join us!

Repeat the importance of accountability

When a software engineer is wrapped up in their day-to-day work, there are so many things to keep in mind that it’s hard to focus on something as intangible as accountability.

However, nurturing an accountability culture is vital for building trust among software engineers.

When engineers explain their actions, thought processes, and decisions made during software development, the bond between the team members strengthens.

In other words, embracing accountability facilitates collaboration and openness among software engineers.

It’s important to establish a culture in which taking ownership and admitting to one’s mistakes is normal and necessary, and not a punishment, which is what 80% of people in research by Anne Loehr perceive it as.

You can remind your software engineers about the importance of accountability by providing them with the context of their work.

Why are they doing a particular project or task? What purpose will it serve when it’s completed?

Knowing that will help them focus and commit to their part in the project, as Karthik Sidhar explains.

A good company handbook can be an excellent tool for reminding your software engineers of their accountability.

Depending on the content of your handbook, you can provide them with specific instructions and strategies for practicing accountability, or you can build an accountability culture by, for example, ingraining company values in your employees.

For instance, GitLab has a very comprehensive employee handbook that, among other things, goes into detail about company values.

Their values help them to repeat the importance of accountability to their employees. For example, avoidance of accountability is one of five dysfunctions they want to avoid.

As you can see, they define that as avoiding calling out peers on counterproductive behavior.

How exactly you define accountability to your engineers isn’t the point; the important thing is to emphasize its importance, and you can do that efficiently by repeating to them why accountability is essential in their work.

Identify productivity blockers

Many practices associated with productive work are also signs of strong accountability.

Therefore, we need to identify and deal with productivity blockers to build an accountability culture.

Productive software engineers know how to meet goals. They also know how to prioritize their tasks and be efficient in completing them.

They are aware that collaboration with others can produce excellent results.

Accountability is taking ownership of those elements.

Software engineers who embrace it as a value know that they’re responsible for meeting goals, prioritizing, and collaborating—in short, their productivity.

To build a stronger accountability culture in your software engineering team, you should identify where the issues are with their productivity.

For starters, by using a software management tool, you can take the guesswork out of your engineers’ workflow.

They should update others about their progress with statuses, as you can see on the Jira board below.

To help you track their productivity, you should have at least these five statuses in your software:

• to-do
• in progress
• code review
• ready to deploy
• in production

If you identify any area where productivity is lacking, you can then take appropriate actions—investigate if the problem is with the technology, the engineers themselves, or something else.

Identifying productivity blockers can be easier with productivity tools like LinearB.

For example, their dev team shared the experience of how they used the tool to improve their productivity after starting to work remotely.

They needed to take responsibility for their reduced output and improve their performance, so they analyzed other metrics too.

Among other things, they noticed that pull requests are left for far too long, which was another sign of unproductive work.

After implementing some changes to their workflow, they managed to return to previous productivity levels.

Without holding themselves accountable for the results, they wouldn’t have been able to do that.

As we mentioned earlier, bad technological solutions can also reduce productivity. For example, dealing with bugs is a part of every app developer’s responsibilities.

If the process is inefficient and slow, that can considerably impact productivity. That’s where our own solution, Shake, proves useful.

With Shake, app developers get an automated bug report with every piece of information they need to fix it.

As you can see, Shake captures app build, network status, OS, location permission, a screenshot with a timeline of the user’s actions, etc.

With all that information, a software engineer is accountable for fixing the bug; inefficient bug reporting can’t be blamed for the lack of productivity.

Be transparent about the problem

Transparency is a core value of an accountable software engineering culture.

It’s straightforward—when a person is upfront and honest about their work, they embrace the responsibilities that come with it.

Managers should be transparent about the goals and values of the company.

However, it might be even more important for engineers that managers are transparent about how they assess the team’s work; engineers should always know what is expected of them and how to accomplish it.

As John Mackey, CEO of Whole Foods, explains, that kind of relationship strengthens trust between the manager and engineers.

Software engineers should also be transparent about the challenges they face in their work.

That means that even if something isn’t going right, an engineer should call attention to the problem so that the manager can take the appropriate actions before the issue blows up.

Sometimes that will still happen, and that’s to be expected in software engineering.

When it does, you should have practices in place to exercise transparency and accountability—like blameless post-mortem.

A blameless post-mortem is a meeting where the team reviews a problem, analyzes why and how it happened, and how to prevent similar issues in the future.

Above, you can see one model of what it can look like. The key is to ask the right questions and, as its name suggests, not to blame anyone.

The most important thing is to understand the issue and not point fingers. That way, it’s easier for engineers to be transparent about the problem.

One company that strongly supports blameless culture is Etsy. You can see their model below.

As John Allspaw, their former Chief Technology Officer, explains, failures in tech industries happen, and it’s better to take them as an opportunity to learn.

That doesn’t mean that an engineer is off the hook; they’re still accountable for the problem, but since they know that they’re in a safe space, it’s easier to be transparent about it.

“They are not only willing to be held accountable, they are also enthusiastic in helping the rest of the company avoid the same error in the future.”

Encouraging engineers to own their mistakes and embrace problems is crucial for building an accountability culture; ensure that you provide them with opportunities to do so.

Don’t reassign projects too often

If you want your software engineer to take ownership of a project, don’t reassign it to someone else.

Doing that too often will gradually eliminate every connection to projects that you engineers might otherwise develop; they simply won’t care from the beginning and, therefore, won’t feel like its success is their responsibility.

And that can lead to subpar work—it’s hard to give it your best if you know that the projects are constantly passed around.

As Mete Atamel puts it, a sense of ownership ensures that a software engineer cares about the end result of a project. If they form an “ain’t my problem” attitude, that isn’t healthy for any team.

Engineers who are leaving the project also feel like they aren’t accountable because they have a new project; likewise, engineers who take over don’t feel accountable because they weren’t in it from the beginning. In the end, the quality suffers.

Managers at Netflix are well aware of that, so they give their engineers a lot of freedom, as well as responsibility.

At Netflix, engineers run what they write, fix any problems, write technical documentation, and, in short, are accountable for the good and the bad of a project they work on—from start to finish.

“Each development team owns deployment issues, performance bugs, capacity planning, alerting gaps, partner support, and so on.”

If you decide not to reassign projects and build an accountability culture that way, you might need some useful tools to further ingrain a sense of ownership in your engineers.

For example, you can use a RACI chart, which details the responsibilities of every team member.

RACI stands for:

• Responsible (does the work)
• Accountable (reviews the work)
• Consulted (provide feedback)
• Informed (kept in the loop)

Each designation is in the chart, like the one below.

For example, you can see that the senior analyst is accountable (A) for the strategic framework and consulted on the delivery roadmap, etc.

Tools like the RACI chart can help with the sense of ownership in an engineering team and help you not to reassign projects too often. That way, an accountability culture will thrive.

Estimate tasks properly

Estimating the costs and the schedule of a software development task is challenging. However, the practice of predicting those elements promotes an accountability culture.

Accurate estimation takes skill, and managers should use their experience and expertise to estimate them properly. By doing that, they become accountable for the further process.

According to research by McKinsey, projects still often overrun the budget and schedule despite the effort.

For instance, 66% of large software projects end up more expensive than estimated, and 33% of them take longer to complete.

Inaccurate estimations often occur because of disregarding the three constraints of every software project—budget, scope, and schedule.

If the length of one side of the triangle changes, so must the others.

On the other hand, if they don’t, the shape of the triangle will be compromised—in other words, so will the quality of the product.

How to approach estimations, then? There are several ways, and probably the most popular is a top-down approach.

With that method, you first consider a broad scope of a project and then break it into smaller pieces.

Estimating by a top-down approach is a go-to for many managers, but lately, the opposite method has been picking up steam—a bottom-down estimation.

Using that method, the team estimates the details of a project and builds to a broader scope from there.

It’s more time-consuming, but it allows them to go deeper into the time and cost estimates of every particular project element.

IBM, a giant technology corporation, took this approach in building a knowledge management system.

As they explain, they chose not to estimate and then build a large-scale project but rather to give more power to contributors.

They use a system of user-suggested tags for categorizing web content, effectively capturing collective knowledge from the bottom instead of working their way to it from the broadly defined project.

There are more ways to estimate tasks properly; no matter which one you choose, implementing them puts accountability at the forefront, and that can trickle down to your engineering team.

Practice progress check-ins

When your software engineers know that you expect them to update you on their progress regularly, they get used to being accountable for their work.

Furthermore, by practicing progress check-ins, you show them that you care about the work and how well it’s going, boosting their motivation.

You can practice progress check-ins by organizing daily meetings.

As William Chin, Senior Product Manager at TELUS Digital, says, those meetings are supposed to cover three questions:

• What did you accomplish yesterday?
• What are you working on today?
• Did you run into any issues?

However, that can become a tedious routine after some time, so it’s best to engage engineers by providing them with valuable information during meetings.

Courtney Hemphill, Partner and Technical Lead at Carbon Five, suggests informing them of the business side of their work.

“When you give developers more context of what their impact is — for customers, for the product and for the business — they just make better decisions.”

One popular way to practice regular progress check-ins with your team is during the daily scrum.

It’s practiced as an element of the Agile framework, and, in short, it’s a daily meeting where the team plans the work for the day and identifies possible obstacles.

By mapping out tasks like that, every team member is accountable for their part of the work.

If face-to-face meetings aren’t possible because your team, for example, works remotely, progress check-ins are still very much possible with the aid of technology.

Software solutions like Range have efficient check-in features and take even less time than daily meetings.

As you can see, it has components titled Plan and What happened, which correspond to the first two questions William Chin mentions—what are you working on, and what did you do yesterday.

Also, there is a Connect with your team section. It serves as a way to build relationships, celebrate success, and reflect on the day. That way, checking in is less of a repetitive chore.

Regular check-ins allow your software engineers to connect with the rest of the team and be accountable for their day-to-day work. That’s a sure way to build a strong accountability culture.

Conclusion

Building an accountability culture is hard work, but it is worth it.

It can change the whole mindset of your software engineers and their attitude towards their tasks.

When you foster productivity, transparency, ownership of their work, careful estimations, and regular communication, things begin to change for the better.

Your software engineers will be more responsible and focused on their work since their name is attached to it. Use tips from this article, and you’ll undoubtedly notice a performance boost.