Recently, I came across the following post on Twitter.
The post resonated with me as it demonstrated a regularly encountered problem when collecting feedback for individuals, or looking for feedback for yourself.
In many organisations, the request for feedback comes as part of a performance review cycle. During this process, an individual will review their goals, assess their career development plan and reflect on feedback from their peers.
As humans, we have a bias to want to be near people that look and work as we do. This bias means that we tend to notice when people act or behave differently from the way we do. We also have a preference for assuming that people ascribe success in the same way we do and want to follow the same path we are on.
When asked to provide feedback for a peer, I’ve found that we rarely give enough context around the goals the person was hoping to achieve, let alone their longer-term career aspirations.
As a good team member, we want to help this person improve, so we want to provide them with actionable feedback that can help. However, lacking the context, our internal biases, start their work, and we fall back to making a comparison against something we know well. Typically, this will be the path we’ve taken or against our career aspirations.
Feedback based around these assumptions leads to statements such as that in the original tweet – “be more like me”.
So, what can we do to improve the feedback we give? Or to help those we’re asking for feedback?
To get actionable feedback, we need to provide context to dampen the internal assumptions. Provide the person you’re asking feedback from with:
High-level information about the career plan or aspirations your working on, for example, “I’m working towards being able to take the role of a Software Architect in the future”
Context around the specific areas you’d like feedback on – “To achieve this, I’m looking for feedback on how I can improve the way I communicate our technical choices.”
Details about the goals you’re working on – “This quarter, I wanted to reduce our technical debt by 25%.”
In these recommendations I’m making the assumptions you’re asking for your own feedback, you should modify as necessary if you’re asking on behalf of someone else.
By providing this framing, the person being asked for feedback is more likely to give you precise, actionable feedback based on your goals and aspirations rather than their own ideas of what you should be aiming for.
Furthermore, by adding a constraint, I’ve found that it becomes easier for people to give critical or constructive feedback, as you’ve invited them to comment on an area you’ve probably already identified that you want to improve.
Recently I got into a conversation about measuring the performance of Engineering teams. The teams in question are following the Scrum framework and have decided to use story points for estimating the complexity of the work.
In the conversation, we were talking about the validity of measuring individual team performance and whether one should use this data to compare the performance across teams.
Now, for anyone that’s even taken more than a passing glance of any of the literature surrounding agile development, Scrum or estimation, the idea of measuring team performance and comparing performance between teams is a clear anti-pattern. Specifically, we’re told, “don’t compare velocity between teams”.
And I broadly agree. In most cases when this topic is raised, the drivers for comparing team performance are dangerous – to discover which teams are delivering as expected and which aren’t, which teams are good and which aren’t, and inevitably, to performance manage those teams and individuals in bad teams.
However, as with all arguments, there’s nuance, and I think there are some excellent reasons why understanding the performance of teams and comparing between them can be useful.
My approach to managing teams of teams has evolved over the past couple of years to consider more greatly the way the system as a whole is operating. I’ve been inspired to change by reading and development in the areas of system thinking. The rest of this post will pull on some ideas from system thinking.
No matter how hard we work to eliminate cross-team dependencies, a group of engineering teams working towards a common goal operate in the same system of delivery. Therefore, it can be said that the performance of this broader system (the Engineering team) will be directly related to the performance of its constituent parts (a Scrum team, for example).
Furthermore, systems theory tells us that the performance of a system will be directly correlated with the performance of that system’s bottleneck. To improve overall system performance, we need to focus our attention on the bottleneck. Improvements elsewhere in the system are likely only to have negligible effects on the overall performance of the system and in the worst cases, some local enhancements will make the system performance worse.
With these thoughts in mind, our attention needs to be drawn to discovering the bottlenecks in our system and applying maximum leverage to these areas.
Although the system is more than the composite of the individual teams, the teams should be one place we look for our bottleneck. Measuring and comparing the performance of teams helps us understand if one of them is a bottleneck in the system of delivery.
Additionally, we can also learn whether there’s a local (team) issue that needs addressing, or whether there’s a systemic issue affecting more than one team needing our attention.
Let’s look at some examples to demonstrate these points. In these examples, I’m going to use throughput as a measure of performance. Throughput is the count of the number of tickets a Scrum team completes in a week. Increasing throughput is one of the goals of improving this system.
Below is an example chart plotting throughput for a team over 10 weeks. In this chart, we can see that this team has a steadily increasing throughput over this time.
Now we add a second team to this chart.
What conclusions can we draw from this? We could say that the blue team is better than the orange team because their throughput is higher. Yet, is this really true? Perhaps the orange team isn’t splitting their tickets down as aggressively as the blue team?
We also see that both teams are improving – so using these two teams as a sample set for the overall system, we may be able to say that the performance of the system as a whole is improving.
So far, comparing teams hasn’t really shown us anything more useful than not doing so.
Let’s add a third team. In this example, the green team has a higher throughput than both the blue and orange teams. We can also see that unlike blue and orange, the green team throughput is decreasing. As two of the three teams are continuing to improve, we might conclude that we have a local issue with the green team that we should look into.
To be more responsible with our charting, we can remove the axis and normalise the throughput counts. Doing this helps us to draw attention to critical differences and focus on the right conversations (it’s also why I used dotted lines for the actual throughput lines). If we look at the revised chart, it’s clear that we need to spend time with one team seeking improvements.
Looking at one more example, we see that every team in this system has decreasing throughput. Seeing this, rather than starting to work with individual teams to improve their throughput, we should focus our energies on developing a better understanding of the system they are operating in.
In this example, efforts to improve a single team’s performance is likely to have limited impact on overall performance. Had we not compared teams, we would not have seen this, and each one would likely have focused on locally optimising their own throughput.
In conclusion, making comparisons between teams isn’t inherently wrong. It can be done in a way which develops insight about the broader system and better understanding within teams about the issues that can and can’t be solved locally.
I have to pass a tremendous amount of credit onto Troy Magennis of Focused Objective for inspiring my thinking on this article. In 2019 he visited the company I worked at to teach us about statistics, estimation, forecasting and reporting. His work inspired my further discovery into this area and my thoughts on team comparisons are built upon the insights and ideas he shared with us.
Training is well underway for this challenge, and I’m encouraged by my progress so far. I have no specific times in mind for the runs. That said, judging by the longer training runs I completed at the end of 2019 (approximately 11 miles), I think that with proper training a sub-2 hour time in one of them could be a real possibility.
Run a 10km race under 45 minutes
Alongside my half-marathon challenge, I want to try and get my 10km time down. My fastest race is 3 minutes above the three-quarter hour mark, and I think with the right training plan, I can push it down to a sub-45 minute finish.
I’ve got two 10km races booked for the year so far – the London Winter Run 10k in February as part of my spring half-marathon training plans and the summer Bracknell Samaritans 10k. The first is likely to come too soon, and the summer run is likely to be impeded by the heat (although it’s Britain so you can never quite predict this). My best chance will therefore probably a late autumn run, so I just need to pick the race to go for this PB.
2000km for the year?
My final running goal for 2020 is to run consistently and regularly. I’d love to break the 2000km barrier for the year. I don’t really know how possible this one is going to be, yet with the race training I like to do, I’d like to think I can give it a good shot!
It’s been almost nine months since my last blog entry. I’ve never been a prolific writer as you can see this in the gaps between posts. I think I’ve found the reason why.
Recently I came across the article Speed Matters by James Somers. Right there, in the second paragraph of the article, Somers summed up exactly my relationship with this blog:
“If every time you write a blog post it takes you six months, and you’re sitting around your apartment on a Sunday afternoon thinking of stuff to do, you’re probably not going to think of starting a blog post, because it’ll feel too expensive.”
I feel seen.
Each time I’ve thought about writing a post, the idea comes into my head, I make a start and then… well then it doesn’t get finished. Or in the rare case it does get published it takes me hours or weeks of refinement and editing.
Each time I go round this loop, turning my next idea into text becomes harder to do.
I’m not about to say I’m a changed man and that you can expect daily posts. However, I will aim to work more quickly, worrying less about getting the content just right before hitting publish.
And as case in point, this post only took me 10 minutes from idea to publishing. Start as you mean to go on.
Late in 2018, our thoughts turned to what we’d do to celebrate the end of 2018. Having had a couple of recent New Years Eve’s wiped out through illness, myself and Jo were ready to do a little more for the upcoming New Year celebrations.
Rather than spend time in the UK, we decided to book a last minute short break to Iceland. We booked through TUI, taking advantage of their pre-arranged Iceland tour packages to give us a view of the island.