On Leaving Alfresco

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.

Getting better feedback

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.