CTOs & Scaling Teams; The Good, The Bad and The Agile

​La Fosse were delighted to host “CTOs & Founders: Scaling & Politics” in collaboration with Octopus Labs. Attendees had the opportunity to learn from leading senior executives who have scaled some of the most impactful businesses of recent times; David Townsend, CTO at FreeUp.io (former VP Engineering at Funding Circle), Tony Hollyhurst, VP Engineering at American Express, former Director of Engineering at Anaplan, with a foreword from Sam Handfield-Jones, CPO at Octopus Labs.

So, whether you’ve just received funding, and are sat in the corner of a shared office working out where to fit 100 more developers, or you’re about to enter a large organisation and you don’t know how to politely talk trash about their legacy systems, read on for a few key takeaways from the experts.

You’re not steering a ship

Who wouldn’t want to envisage themselves at the helm; swinging the steering wheel onto their own course, leading their team’s journey bravely onwards?

And in fairness, it can be like that when you’re small. However, scaling means new metaphors are needed. Larger organisations might have more in common with a pack of horses; while everyone might look like they’re moving as one, underneath there are many shifting relationships affecting the structure of the whole. If as a leader you’re not up to date with these, your decisions might not be the right ones.

At a team level, this means making sure you understand working dynamics – who the peacemakers and the blockers are, whether the tech lead and product manager are always screaming at each other around deployment time – either by being visible yourself, or by making your management your eyes and ears. This isn’t just to increase your depth of understanding: being at the back of a meeting means the team knows you care about that project – and about them.

The other key component of this is – surprise surprise – communication. ‘As you grow, communication and collaboration become the vehicles of change,’ pointed out David. ‘If you make a change and the whole organisation doesn’t understand what you’re trying to achieve, you have chaos.’

Building a management layer

You don’t grow a whole tech organisation – you grow lots of little teams. This brings challenges, but also opportunities – good managers allow you to keep au fait with the politics, whilst keeping political structures as small as possible.

However, just because managers are your eyes and ears in a team, doesn’t mean they’re your mouthpiece. ‘You have the choice between hiring yourself and hiring someone else.’ Observes David. ‘If you’ve hire someone else, you wanted those skills for a reason, and you have to adapt your own management style to theirs.’

Management also gives more experienced engineers the chance to shine by leading a mini-organisation. It’s for this reason that, when Tony was initially scaling Anaplan, he preferred organic growth from his own developers. ‘I didn’t want to hire a scrum-master in. I wanted to see who naturally showed the authority.’

However, this approach is not without its challenges. ‘Early on, we kept having to swap out the experienced engineers to lead new teams which were being created. This was tricky for the stability of the team’s unit, but also meant every engineer could see the real opportunities for growth as achievable.’

Scaling in a large organisation: lessons from AmEx

Of course, the challenges faced when hiring at pace in an already large organisation are extremely different, because the aims are different. When Tony joined American Express, they were seeking to bring more agile methodology into their practices, against the backdrop of FinTech disruption.

‘We weren’t in the position of saying: three years down the line, we want to have an organisation which is bigger. It was more like – three years down the line, we want to have an organisation which is better.’ This meant building a start-up within the organisation to act as its own disruptor, then working out how to allow this agility to spread.

The key to driving this was good communication with the people – many of whom had been using the existing systems for years. ‘Our key message was: we’re here to teach and upskill you about the new ways of working. People were generally onboard with that.’

Don’t run, it scares the crew: adapting to a more senior role

Senior tech and engineering roles are a cocktail of technical and soft skills. The more senior you become, the more you’ll need to add of the softer qualities – and adapting to your changing role in the team is crucial.

David remembers the first point he realised his skillset needed to change. Something went wrong at a crucial deployment, which meant everything died: no logs, no nothing. He had no idea what the solution was, so he panicked. But he also learnt a valuable lesson. ‘The thing is, it wasn’t my role as the CTO to provide a technical solution. It was to tell my team “it’s going to be alright” and give them the headspace to work towards a technical solution.’

Giving the team headspace is also absolutely crucial for Tony. He didn’t mind being cut out of his team’s Slack channel, as it gave them the technical breathing space to get on with the job. This kind of trust is also crucial when working with offshore teams. ‘We have a scrum team in Dubai, and one of the best things I did was to give them the autonomy to just crack on.’ His organisation also has Guilds to give people who are passionate about technology a space to speak and freely problem-solve. ‘To a certain extent, it’s an investment which you don’t know will pay off. But also there’s a chance that a ML test will come up, and the Guild will already have solved the problem the previous week.’

Change as a seed: plant it and see if it spreads

Change isn’t a finite act; it’s borne of iteration, iteration, iteration. As Sam Handfield-Jones of Octopus observed, ‘driving agile isn’t just applying Google pods and declaring you’re finished.’ You need to adopt an attitude of constant improvement across all areas, from your product roadmap to your communication channels.

This means change needs to be introduced with an exceptional amount of care, and to begin with, on a small-scale. If your first move is to introduce new methodology across the whole organisation, you face losing a lack of control. Problems will come up quicker than you can solve them, ultimately leading to a loss of faith in the individuals who need to be bought-in.

David advises beginning by identifying one team who you trust, and importantly, who trusts you. ‘You can’t make mistakes organisation-wide. Give one team the chance to make the mistakes on a small level, and then iterate, iterate, iterate.’ When you get to a point where things are working well, then the changes can be encouraged to spread across the organisation, with a team ready to lead by example.