Life is weird right now. It’s like nothing I’ve ever experienced before and everyone reading this is likely to have undergone significant changes to the way they live, work and play.
I started at Stash a week before the UK lockdown was announced. Stash took the decision the week before to move all their staff to remote work, so for the first time I’ve been through a remote onboarding process. This has continued, and as I write this, I’m half-way through my fifth week of working 100% remote. Once again, something new to me. New skills to learn, new ways to work.
For folks that know me, you’ll understand that I’m not the most socially active person. As an introvert, the idea of self-isolation seems to be designed for people like me. Yet, it’s hard. It’s hard not sharing a physical space with co-workers, friends and family. It’s hard looking at the same four walls. It’s hard having your freedoms removed. All these changes result in a higher cognitive load as we try to adapt to the new normality.
News broadcasts, social media and conversations with others cover a single topic – the virus. Rarely are these conversations positive. This induces higher stress levels as our concerns grow about not just our own health, wealth, and well-being, but also that of others.
Undoubtedly, it’s a difficult time (understatement).
Trying to adapt to the new normal, while at the same time dealing with the higher stress of just being will put emotional, mental pressure on yourself. I feel it, and make no mistake, others around you are experiencing this too.
At this time, we need to look out for each other. Take the time to talk to people, and ask one question – “Are you ok?”. Then shut-up and listen. Don’t offer solutions or advice, just listen to what they say. Let them know you care and let them know that you’re there if they need help. Let them know that there are people there who can help.
We may be self-isolating, yet with Twitter, Facebook, WhatsApp, Skype, Zoom, etc. we have better technology than ever to stay connected. So, jump on a call with someone you know and check-in – “Are you ok?”.
This week, after over 3 and a half years, I left Alfresco. The decision to leave was a difficult one, but ultimately, it’s the right move for both the company and me.
My connection with Alfresco goes back further than the recent years working for the company. Back in 2010, while working at Yell, I was part of a team tasked with creating a knowledge base based on (the now deprecated) Alfresco Web Content Management. It’s fair to say that 10 years ago, I wasn’t exactly enamoured with the software.
Although we made it to production, the project wasn’t a success. Eventually, we dropped the feature from Yell.com and shut down the services.
Fast forward to August 2011, and I’d obviously felt that I had something to give to the Alfresco team. I applied and interviewed with Gavin Cornwell (not sure he remembers this though) for a Senior Engineering position. I made it through the phone interview; however, things didn’t work out, and I didn’t end up joining.
Instead, I joined eBay and then moved onto Marks and Spencer. By this time, I’d stepped away from coding day-to-day and was forging a career as an Engineering Manager. In May 2016, I made the decision that M&S wasn’t going to be the right place for me long-term and started to look for my next role.
I’d been following Alfresco throughout the previous 5 years – as an open-source software product company on my doorstep, it was always interesting to see where they were headed. To my surprise and joy, I found that they were recruiting for Engineering Managers. I interviewed, got an offer and then joined in July 2016.
The next three years were a whirlwind of development and learning. I attempted to move my thinking from delivery of evergreen e-commerce websites to enterprise on-premise application software. It was a steep learning curve and I’m grateful to all those on the team that helped me along the way.
Over this time, I moved from Engineering Manager to VP of Engineering for the Platform Engineering team. I worked with this team to increase the cadence of releases, increasing automation and reducing the amount of time spent on manual release validation.
I was also present through many changes of leadership at the company, this included the sale to Thomas H. Lee Partners and a couple of changes of CEO. Throughout all these changes, the team I worked with remained focused on improving the Alfresco Content Service and Governance Services products.
I want to thank everyone who supported me throughout this journey – particular Brian Remmington – the ultimate in positivity and deep thinking, John Newton – founder and true visionary, Mario Romano – a driven leader always pushing for excellence. Latterly, Tony Grout joined the team as CPO and helped me develop new insights and understandings of running Engineering teams.
Over my time at Alfresco, I’ve also worked with many of the founding engineers, and I am grateful for the education they gave me.
But most of all, I want to thank the Alfresco Engineering team. The team I was part of is made up of many incredible developers, testers, ops engineers, agile coaches and managers. As well as those employed directly by Alfresco, I was fortunate to work with an excellent team of engineers in Iași, Romania.
So, what’s next?
First, I’m taking a month off. After 13 years of continuous work, I need to an extended break before heading into my next role. I plan to do some coding (for fun!), running and reading, and hopefully meet up with some of the people I’ve not spoken to in a while.
Once I’m fully recharged, I’ll be joining Stash as an Engineering Manager, helping them build out their UK Engineering team. It’s an exciting opportunity to join an already successful team on a new venture, and I’m looking forward to the challenge of kick-starting Engineering in Reading for the company.
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!