Creating a Platform function
We’ve started a new area of the business: Platform. Its purpose is to support and enable our product teams and other parts of the business, and I thought I’d share a bit about creating it.
Since Farewill started, we’ve worked on creating beautiful, empathetic digital products to help people deal with death. To do this we’ve typically worked in what we’d describe as “multidisciplinary product teams”. These are teams made up of people with different skill sets (for example, a user researcher, product manager, insights analyst, visual designer, software engineer) all working on a shared problem. Like creating products such as our online wills, or a system that helps us manage funerals.
Over time we’ve built more things, released more products, and grown as a company. We’ve started to see some challenges, particularly from an engineering perspective, so we decided to bring in a new function: Platform.
Our Platform teams work as enablers
Our Product teams will continue to build software to support the overall products that Farewill offers our customers. This will stay the same, but the teams will now also become clients for our first Platform team: Platform Engineering.
As with so much in tech, the term “Platform” tends to have slightly different interpretations in different businesses, but for us the remit is currently “to build and maintain the platform that other teams build on”.
Platform Engineering isn’t focused on directly making customer-centric products (either internal or external customers) like Product teams are. Instead we’d describe it as an enabling team. Our vision is that the Platform function is eventually made up of a collection of teams that focus on more cross-cutting technology concerns. They’ll enable other product or feature teams to work and build digital products as effectively, securely, and robustly as possible.
Part of the reason for creating Platform was about solving problems
As we developed and matured as a business, we started having some growing pains. Particularly within the realm of product and engineering:
We did not have clear ownership of things like our hosting, or deployment pipeline. With nobody owning them we were worried we wouldn’t be planning for the future as effectively as we could be.
We were growing, and with more product teams we were seeing fragmentation when it came to things like payment systems and other pieces of our architecture.
We were finding that some kinds of technology-led initiatives and improvements could be hard to prioritise within product teams unless they were directly related to the team problem space and goals. This meant some more general work never making it up the prioritisation ranking.
We’ve started to think about more specialist hires in the shape of roles like Security or Site Reliability engineers. We realised it wouldn’t make sense to wedge them into individual product teams as they wouldn’t always be working to the team’s goals.
...and part of it was about seeing opportunities
But it wasn’t all doom and gloom. Part of creating a Platform function would be to help us focus on cross-cutting technology projects like payments.
But beyond that it’d also house projects designed to improve the way our engineers work. This can bring us exciting opportunities for engineering to really contribute to Farewill’s overall success, and help us hit our strategic goals.
There’s a range of research and precedents that informed our thinking
As a couple of examples:
the 2020 McKinsey report 'Developer Velocity: How software excellence fuels business performance' states that companies
with a higher Developer Velocity Index score (a term they use to refer to empowering developers and removing points of friction) outperform revenue growth up to five times that of their competitors and they score 55 percent higher on innovation.
Books like Accelerate (Forsgren, Humble, Kim, 2018) are well-respected in the industry, and discuss significant research that talks about the business impact, as well as cultural benefits that this kind of work and team can drive.
We believe that developer experience can be both an enabler and a differentiator for us
As above, whilst we believed part of the benefits could directly benefit Farewill through engineering velocity, efficiencies, and cost savings, we also believed in the important role a function like this could play in employee satisfaction and retention.
A lot of companies declare that developer experience and related work is important. For example, almost 80% of the 65,000 respondents to Stack Overflow’s 2020 survey believed that DevOps is at least somewhat important). Despite this, the reality is not all companies actively work to invest in this area. I want Farewill to be one of the companies that does.
Platform helps us to minimise risk, and think in a joined-up way
By having a set of people whose remit is to build strong foundations, we believe this ultimately helps:
our quality, stability, and resilience (making sure that we don’t lose revenue through downtime)
keep our customer reputation high (we have a 4.9 score with almost 10k reviews on Trustpilot!)
us focus on complying with increasing levels of regulation, and builds an all-round stronger tech platform.
We kicked off the journey in Q2 this year
We originally started by seeding the idea of a future Platform team into a product team whose goal was to think about making our product experience a bit more seamless. Their work evolved into two main streams –some people thought about the front-end user interface, and the rest focused on architectural and data changes to our services, data storage and data transfer.
In Q3 we formalised the split, creating a new “Platform Engineering” team, currently consisting just of Helena, Emma, and Kaitlyn. Initially they’re focusing on foundational application pieces including shared customer accounts and payment provider-related work.
The team are working in sprints of 5 weeks on chunky projects, with 1 week “off” in between to work on other things in the backlog, including developer experience improvements.
We’re not keen to keep it small forever, and are hiring a Technical Program Manager to lead pieces of work and help to grow this function, so if you’re interested in working with some fantastic people and having a challenge to own in this space please get in touch!
Some things that we’re mindful of at the moment
The team have done some brilliant work so far, and we’re very excited for the future, but we’re also mindful of some watch-outs.
The remit is very broad for such a small team, and won’t work long term. With just three people we need to be focused right now, but in the future we’ll grow and be able to form dedicated teams around things like infrastructure, developer experience, security etc.
There’s a danger that the team could be seen as a ‘catch-all’ team, and too much could be pushed to Platform Engineering. We’re trying to be really clear on the team remit, and what does and doesn’t constitute a Platform project.
Likewise, we’re mindful that the Platform team shouldn’t become the constant gardeners/janitors that clean up after everyone else!
We want to avoid creating a knowledge or skill divide between Platform/Product teams, and making it harder to problem solve or fix issues that fall somewhere close to the divide. Our Engineering Guild already has fantastic knowledge sharing, and we’ll continue to work hard on this.
Onwards into the future!
From here our short term plan is to find the right Technical Program Manager to support the team, and help us to continue growing out the function. We’re also continuing to think about our metrics and measurement, helping us to gauge the impact the team’s having, and tell stories about how they’ve made a real difference. If you'd like to join us for that let us know!
