Is your engineering team working efficiently?

Is your engineering team working efficiently?

One of the most common concerns I hear from directors and business owners is that their engineering team isn’t delivering at the pace required. They’re wondering whether they need to restructure, or recruit certain specialists, or change their methodology to increase efficiency.

But efficiency isn’t the true goal here – or at least, it shouldn’t be. Success is not just a case of building things right, it’s more important to be building the right things.

In fact, perhaps we shouldn’t even be talking about an ‘engineering team’ (or a ‘dev team’ or ‘scrum team’). This suggests the team is just a coding conduit for turning the vision into a reality, which probably means they are operating in a silo – often with responsibility for prioritising, planning and delivering features, without having been involved in the process of deciding on the features to actually build.

Instead, I’d suggest we should be talking about the ‘product team’, which is made up of everybody who has an input into the final outcome in some way (which might be everyone in the business, if the company is small). And there’s the crux of it: to build the right things there needs to be an integrated team effort – and in this case the word ‘team’ has to be given a broader definition than a departmental division through common skillset.

But how does that work in practice? Probably the best way to explain is to answer some of the questions that I hear most often:

What makes a high-performing team?

In a word, leadership. In traditional top-down hierarchies there’s a lot of focus on managers, but this approach has significant failings – managers deal with the important and urgent, and ‘process’ often takes precedent over everything else. Leaders, however, focus solely on the most important stuff. They look further ahead, creating the environment in which teams can succeed (and then they get out of the way, allowing the specialists to do what they do best).

So, the obvious question that follows is, what’s the right environment? It’s sometimes easier to identify the wrong environment first, then flip it. Teams fail when they have no vision, no goal, and no feedback. They fail when they put process ahead of delivering real value. And they fail when they don’t set a measure to benchmark success (everyone needs to know what ‘good’ looks like, right?). It’s a leader’s job to right these wrongs and put the necessary culture in place.

How can I motivate my team?

Contrary to popular belief, it’s not about bonuses and free food (or performance reviews); carrot and stick just don’t work in the way you might think. I usually tell people they’re asking the wrong question here. Most employees will start a job motivated, and only get demotivated because of poor leaders who are too heavy-handed with ‘management’.

What’s the solution? It’s all about giving people what they really want in their jobs – what Dan Pink calls ‘autonomy, mastery and purpose’. Put simply, once we are paid fairly and sufficiently, to ensure that money is not a concern, these three elements are what drives us to do our best work. We thrive when we are able to self-direct our working efforts, we excel when we are able to apply ourselves to mastering our specialist skills, and we are inspired to go the extra mile when we care about the outcome. Again, setting the right environment through good leadership is the answer.

My team never hits their targets, how can I make sure they deliver?

When I ask team members the question ‘do you have a clear vision and goal?’, the answer is often ‘no’, so that’s something fundamental to fix right off the bat. It’s also worth considering whether the team members in question have the autonomy (back to Pink again) they need to carry out their work unhindered – do they make decisions for themselves, or does the culture mean that they need to ask others for permission or answers?

If permission must be sought, then there’s a fair chance that failure is not considered an option. This creates a culture of fear, and nobody does their best work under that kind of pressure. Failure is in fact a good thing, when done right, as it shows that experimentation is taking place, and positive lessons can be learned. However, it’s important to fail cheap and fast, so that not too much resource has been taken up in doing so (it’s also key to keep the scope of experiments small, so that any failure can be within a ‘contained blast radius’).

How can I get more value from my team?

Firstly, it’s fundamental to realise that ‘value’ can only be achieved when the team is building the right thing, and not just building things right.

But how is ‘the right thing’ decided upon? Well, it might go without saying that the release plan shouldn’t be built according to whichever department has shouted the loudest, or what the next sales opportunity requires, but it’s surprising how often this is exactly how teams are asked to prioritise their work. And the ‘magpie effect’ can come into play here too, if you’re not careful – it’s easy to get carried away by the newest shiny bauble and put too much emphasis on features which have novelty value.

In contrast, effective product teams, made up of a variety of stakeholders from across the business, analyse the value of potential features to create a well-considered release plan – try the RICE framework, which can help with the comparison of ideas, and the prioritising of requirements. It’s also important to agree how effectiveness of a feature will be measured, and how you will know if you should continue with this experiment or try something different.

I often ask team members what is ‘the one thing’ they’re working on for the next release. Answers vary, but usually fall into one of two categories: I don’t know (in which case I know there is a lack of vision, goal, and autonomy), or a big list of features (betraying a lack of focus and therefore effectiveness).

With the former, it’s a case of shifting the culture to one which encompasses autonomy, mastery and purpose, while with the latter it’s more about identifying priorities – remember the Pareto principle, where 20% of the time is spent delivering 80% of the value, and 80% of the time is spent delivering 20% of the value. It’s worth also bearing in mind that only 20% of software is used ‘always’ or ‘often’, with 45% used ‘never’ and 19% ‘rarely’ (Standish Group study, reported at XP2002 by Jim Johnson, Chairman), which means there have been a lot of teams out there wasting time creating features that are not proving useful to customers.

If focus on the right thing has already been achieved, it’s worth discovering whether methodologies are being used properly. I’ve lost count of the number of times I’m told ‘we’re doing Agile, but…’ and then hear all about how they are leaving out aspects or adding things into the process. For example, they might be using a monolithic Waterfall project methodology but have a daily meeting with the engineering team alone, or even – as with the worst example I ever saw – a kind of “Scrumfall” (a strange mishmash of Scrum and Waterfall).

With people from different functions involved in the process, it’s also important to make a distinction between a roadmap (strategic, high-level, long-term, about the ‘why’) and a release plan (specific, actionable, a working document, about the ‘what’). Additionally, it can be helpful to use the DACI framework to make sure that everybody in the product team understands their role in delivering the outcome – it’s important for people to be adaptable, but if they step outside their remit by demanding changes to product priorities, then it can be a significant barrier to the team working effectively.

Can’t I just manage the team carefully rather than change the way we do things?

Not really. When a system is complicated, it can be analysed and optimised through scientific management, but when it is complex, you cannot fully analyse and optimise for all situations as there are too many factors and they change too frequently. There’s a great discussion about ‘complicated vs complex’ in General Stanley McChrystal’s book Team of Teams, if you’d like to delve into this topic more.

Software development is definitely in the latter camp – complex – and in this situation you want to build a team that is adaptable and who can make decisions for themselves, at team level, rather than waiting for things to be decided at management level (if you’re interested, Mark Logan, ex-COO of Skyscanner, talked in more detail about decision latency in his presentation at Turing Fest 2018).

This kind of effective decision-making at team level can only happen when the whole team has an understanding of both goal and vision, has a way of measuring the effect of the changes that they make, is fearless and understands the value of a fail (within the context of the contained blast radius that I mentioned earlier), and has the autonomy to change the way they work. The aim is to reach a point where alignment (AKA accountability) and autonomy are well balanced, so that independence does not mean a lack of organisation or integrated effort.

What’s the bite-sized takeaway here?

In summary, it’s all about effectiveness not efficiency – building the right thing, not just building things right. And this is often best achieved by going back to basics and figuring out:

What the right thing is

Are you focusing on value? How did you decide what has the greatest value?

Whether the process is effective and well-understood

Is the team made up of the right people across the business, and do they understand their part in building the right thing? Are they all focused on the common vision and goal?

If the team can feasibly do their best work, and deliver the right thing

Do people have the autonomy and resources to build it?

If you’d like to talk about how you can scale faster, bigger and better with a product team that is working effectively to build the right thing, send an email to [email protected]. 

Originally posted on the Blue Ocean Website: https://www.blueoceaninsight.com/insights/is-your-engineering-team-working-efficiently