How to become a more effective team
November 2024
As a leader, you want your team to be as effective as it can be. But, what does it mean for a team to be effective? it means doing the things that matter. In fact, it means doing only the things that matter. It means stop wasting time.
While there are many ways to tackle this problem, it’s always better to back your proposals with data. This article explores four of the topics covered in the 2024 DevOps Research and Assessment (DORA) report to help you improve your team:
- Stabilise priorities
- Improve the developer experience (DevEx)
- Adopt a user-centric mindset
- Measure what matters
It also offers specific actions to get you started.
With that in mind, let’s get on with it!
Stabilise priorities
Your job is to get your team to focus on one thing, from start to finish. If your team is constantly interrupted, or if you’re not able to finish the things you start before new ones come in, you have a big problem.
Unstable priorities decrease productivity and increases burnout.
This is a red alert and you have to fix this first. If your team priorities are unstable, having any of the other positive traits described in this article won’t help your team to get more effective.
Focus on one thing
Your team needs to have a clear next goal, and you have to work only on that until it’s done. This means three things:
- You have to make your team understand that you need to focus on whatever you all agreed until it’s done, or until it’s abandoned. It’s important to decide if a feature is going nowhere, since not every project is successful.
- You have to make the stakeholders understand that interrupting the team is not allowed, except if it’s related to the things you’re currently working on. The team is always open for feedback and clarifications on their current objective, but meetings about new work have to wait.
- Your next goal needs to be small. Due to the nature of the previous two points, you want to focus on small iterations that, one by one, get you closer to a bigger goal. Small feedback loops help you delivering the right thing.
- Timebox your effort. Pick a deadline and focus on reducing scope so work doesn’t expand further than that deadline. This is important because you are only working on one thing, but you can’t work on one thing forever. That’s stagnation. Timeboxing work helps defining how much time is worth devoting to that particular line of work, and you can re-evaluate later if the project needs to be abandoned if not completed after the scheduled time.
Saying no
Because you want to work on one thing at a time, the most important thing you need to do is to have the courage to say no.
Say no to that 5 minutes catch-up, say no to that bug ticket that just came in, say no to that urgent feature that someone just came up with.
Saying no is liberating and helps you and your team in the long run.
Improve DevEx
Providing a good DevEx is a smart business move, as it enables developers to solve complex tasks, collaborate with peers, and unleash their creativity
Treating DevEx as a first class citizen in your team is very important. It’s right there after focusing on one thing at a time. Teams with better development experience create better products for their customers and are less prone to burnout.
There are many things you can do to improve DevEx. Frameworks like DORA or SPACE are a good start, and this article covers a bit more of those in the metrics section. Still, if you need to start somewhere, start by reducing the cognitive load of your team.
Reducing cognitive load
The most effective way of reducing cognitive load is to simplify tasks, where a task is anything a person does at work. In a software development team, those tasks can be deploying new code, writing documentation, defining the scope of new features, etc.
Usually, the way to solve most of those issues is by focusing in automation and documentation.
Automate, automate, automate
Automate your deployment pipeline, automate your local environment setup, automate your tests, automate your API documentation, automate your alerts. Automate as much as you can as long as there is a benefit from doing it.
This is now an industry standard, so it shouldn’t be a surprise. It’s still important enough to keep mentioning it, though.
The more you automate, the more time your team can spend focusing on the problems that matter. So, automate.
Document when you don’t automate
Automation isn’t always possible. Sometimes you don’t know how to automate certain tasks yet, and sometimes it’s not cost effective. If that’s the case, document it.
Some examples are a runbook, or issue trackers, or high level details on why you are doing what you are doing. Having this documentation helps your team to move faster when it’s time to make a decision. It also makes onboarding easier, since you can point new members to a document for them to learn at their own pace. You can also delegate certain bits to other teams easily, which stop your team from being a bottleneck or having to be on call 24/7/365.
As soon as you understand how to automate the documented process, or if the cost of the automation becomes affordable, go for it and remove the process.
Adopt a user-centric mindset
User centric teams have a 40% higher level of organisational performance compared to those that did not.
Doing what your users want, and need, increases productivity and team DevEx. This seems logical, and the new DORA report confirms it with data.
To get better at this, you need to be humble. You have to stop making assumptions about your users. Instead of coming up with what you think your users need, talk to them and understand the real problem they need you to solve.
Adopt the theory of jobs and focus your user research in understanding what job are your users hiring your product for. The article on theory of jobs is a must read, or even better, read the book. It’s eye-opening.
Measure what matters
After all this work, how do you know if you are getting better? You need metrics, but not any metric, you need the right ones.
DORA already has a set of technical metrics that are important:
- Deployment Frequency: How often an organization successfully releases to production
- Lead Time for Changes: The amount of time it takes a commit to get into production
- Change Failure Rate: The percentage of deployments causing a failure in production
- Time to Restore Service: How long it takes an organization to recover from a failure in production
They’re now also insisting on having business metrics as well, where Objectives and Key Results (OKRs) are mentioned. This article is not going to talk about OKRs, but whatever you choose, your technical goals need to align with the organisation goals.
Metrics can help with the decision making, which helps with doing the right thing and with stabilising priorities. A recommendation is to create dashboards that combine the technical metrics with the business metrics.
When a measure becomes a target, it ceases to be a good measure
However, don’t use metrics to evaluate performance. Metrics are only useful if they help you to get better. If you start using them as a performance evaluator, it’s likely that the team will focus too much on them and learn how to game the system, which won’t help your team to get better.
Summary
Stop wasting time and start focusing on the right things. Get your team to do what matters and ignored the rest. Do less, but do it with a purpose.
That’s all!