An overview of engineering at GoCardless

Hello, my name is Neil and I am the CTO at GoCardless. Here at GoCardless we provide a new way for businesses of all sizes to take control of their domestic and international recurring payments

You may have seen some of the recent news about our latest funding round (see here if you missed it). We’re still working through what this means for us but one thing we do know is that we will be hiring in engineering and all across Product Development this year.

I thought I’d write up some of my thoughts about engineering and product development that may prove useful. Hopefully you will find them interesting whether or not you are thinking of joining us.

I’m going to cover how we are structured from an overall point of view, how teams are organised, what we work on and how we execute on that work. Finally I’ll talk a little about the people side, covering diversity and growth.

How are we structured?

Product Development as a whole comprise Security, Banking Operations, Engineering, Product Management, Design and Data. Each of these areas has a functional leader. For engineering this is me. Together these functional leaders ensure we are set up for success and delivering as an organisation.

Teams

Our atomic unit of execution, planning and delivery is a ‘team’. We work together in teams to deliver customer impact and value. Teams are multi-disciplinary and include engineers, product managers, design, data science etc as needed to address the problem space they own.

Teams containing engineers have an engineering manager and a technical lead to help them. Engineering managers are responsible for overall delivery, team health and well-being. Technical leads are the individuals responsible for ensuring we are architecting and building our systems in a way that is scalable, secure and reliable. They also often manage the day-to-day work of the team.

Product managers, like engineering managers, are part of one or more teams and are responsible for the ‘what’ and ensure that we are prioritising both the customer facing features along with the non functional requirements we have to address.

Groups

We are growing fast and have been for the last number of years. The whole department is now more than 150 people with Engineering alone more than 80. Up until the end of 2019 all engineering teams reported directly to me. This started to be an impediment to both individual and team growth as I didn’t (and still don’t!) have the bandwidth to give everyone the time they deserve.

For this and other organisational scale challenges, we therefore moved to a group structure where a group comprises multiple teams. For instance, we have all the teams related to ‘moving money’ now in one group. This allows for consistency and autonomy within that group. It also promotes ownership and gives us the opportunity to build deep domain experience. As part of that creation of groups we have also replicated the role of engineering manager, tech lead and product manager. There is a group equivalent for each of these with a group product manager, group engineering leader and Principal Engineer.

What do we work on?

We set company OKRs on a yearly basis. We try to stick to a maximum of 3 to ensure we are focused on ‘getting to done’ on them. This will inform much of what engineering work on. However, we also have product, group and team goals as well as investment work that we need to prioritise. That prioritisation is led by Product Management but informed by engineering managers and tech leads.

Additionally, we have engineers taking on department wide initiatives such as increasing our observability of the product. A current one we are working on as an example is understanding our scalability models and increasing our “runway” as we grow.

Having said all of that, the real world sometimes does not align with our plans. External factors (covid for instance) sometimes require us to pivot and work on new things or work in a different order. As a high growth company in a fast changing environment I do not expect this to change. Balancing long-term building with shorter-term initiatives is one of the challenges faced by most scale-ups, and while we may not yet have found the perfect balance we’ve built the decision-making processes to tackle this as effectively as possible.

How do we execute?

By execution I mean every stage from project inception to code delivery to general availability and product marketing. It’s done when it’s being used, not when we ship the code.

Ownership

Autonomy is something we value highly as we want decisions to be made and owned closest to the problem space.

We not only allow but expect the team and group to make the hard trade offs and decisions needed to optimise for impact and long term customer and company value. We hold leaders in all roles (managers and individual contributors) accountable for the outcomes of their teams and groups the same way that Duncan as Chief Product Officer (CPO) and myself as CTO are accountable to the rest of the Exec and the board.

Decision Making

We think decisions fall into 2 categories: one-way door and two-way door, a concept popularised by amazon (here).

One-way doors are big, high impact decisions that are very costly or impossible to reverse. Two-way doors are small, low impact decisions that are easily reversible. For one way doors, we optimise for quality and “getting it right”. We expect these decisions to require involvement of a much larger group (including relevant executives when appropriate) and a much more structured decision making process, including written proposals with discussion of the various options.

For two way doors, we optimise for speed. We expect those decisions to be made by the people as close to the action as possible, with a process that is as lightweight as possible. The fact that we optimise for speed doesn’t mean that we don’t collaborate with other stakeholders when needed or disseminate information as required. It doesn’t mean that we are reckless or don’t care about doing a good job.

Where are we on diversity?

We have strived to increase diversity in all forms across the entire company and Product Development. Engineering diversity as measured by gender has been a focus and we now measure how our ‘funnel’ performs. We have specific targets in terms of candidates that get to a face to face interview before we make an offer BUT we do not bias offers for successful candidates based on their education, race, gender or other protected characteristic.

As of the time of this post, across Product Development women make up 23%, within engineering it is 14% and within engineering management it is 33%.

How do we think about people’s growth?

Promotion

We promote based on impact. So it could be said that working on larger, more visible deliverables gives an increased opportunity to show this and be promoted. However, there are other deliverables that have a different impact and cadence that also result in promotions. Removing technical debt or cruft from our software can mean that we increase the velocity of everyone by a small percentage, which has a cumulative, continual impact. So working on the shiny, new, visible deliverables is not the only way to be promoted. (For reference, see Lisa’s post on this as an example of that type of work)

We promote when we believe the ‘centre of gravity’ for the person is at the next level, not when they are completely meeting all our competencies at that level. Promotions are run on a strict process. Promotion committees are facilitated by someone outside of the management chain for that function, and include more senior individual contributors and managers from across all of Product Development. We assess reasons for and against promotion and promote only when there is a unanimous view. This is supported by a full document that shows the performance of the promotee against the next level.

We promote twice a year and in the latest round we promoted 20 in PD overall and 8 within engineering. This included promotions to all levels from SDEI to SDEII and promotion for some to VP level. It also included 2 promotions to Principal Engineer.

Rotation

One other thing to mention is that we have a formal policy for engineers moving between teams. There is an internal jobs board where anyone can apply for a new open role as long as they meet the criteria on tenure and are in good standing with respect to their performance. If successful, they can move within a short period. This applies even across internal disciplines so an SDE can move to be an SRE for instance.

What to do if you want to know more?

Find out more about Life at GoCardless via Twitter, Instagram and LinkedIn.

We are hiring see all of our open roles here; https://gocardless.com/about/jobs/