Team growth by an order of magnitude

Alexander starts with context. Acquisition is a service line inside the company: it must bring in many new customers cheaply, build convenient interfaces and run scalable processes across channels — contextual advertising, real time bidding, e-mail, SEO and the company's own media projects. Technically that means flexible control over page content, split, A/B and multivariate tests whose results differ by segment and so call for personalisation, and statistics to measure the effect. The company never had branches, so the web is a primary channel and the customers are all business lines at once, with unsynchronised requirements. Alexander owns the unauthenticated part: the main page, product pages and landings. When he joined in late 2016, all the code sat in a monorepo as a monolithic application with an odd decomposition: to ship a change you merged it into a shared release branch, crossed your fingers and waited out a long regression, by which time the change could be stale.

The development team was literally four people, and the customers came straight to the lead: he talked to them, estimated every task, did the reviews and put out fires during the regression. The first step fixed the two sorest points: rare releases and the stream of requests hitting the lead. The team ordered its own infrastructure: a separate application served only its pages, landings at that point, and shipped from its own release branch. A project manager appeared beside the lead, shielding him from incoming requests and settling matters with neighbouring departments, operations and testing. The backlog was reprioritised, stale tasks closed, and the team agreed how it estimates work and plans a sprint. Not everyone dropped the old habits: while Alexander was on holiday for four days, a particularly persistent customer took a task straight to a developer, and the developers printed his photograph on A4 and held it up in reply.

The faster-shipping team was given more tasks and people, grew quickly — and at a certain size, in Alexander's phrase, the lead runs out. The application was split into banking and insurance products with two separate releases, and a new team lead took over the second team. The leads gained a horizontal link they had lacked, while the project manager partly stepped out of internal processes, keeping basic protection and planning. The teams could tune their own process: one of them, to wait less for review, agreed on a quorum of two likes before a task could go to a tester. The leads set up a knowledge base on a simple rule: when a newcomer cannot solve a problem, the lead explains and the person then writes the story down. That is how a list of instructions for hard cases accumulated and the Groundhog Day of repeating questions ended.

A separate storyline: where a new lead comes from. Inside the company is the better option, so the department introduced performance review for the first time: they talked to developers about their plans and spotted potential team and tech leads, while opening an external vacancy too. Alexander recaps the growth track: a junior learns to solve tasks without pulling the team in over trifles and grows through middle into a senior — a strong specialist who works out almost any area alone, teaches others and can be handed a new direction. The leadership conversation makes sense with a senior, and the key question is whether he wants soft skills and responsibility for the team's work or further technical growth; out of that answer a team lead or a tech lead hatches. Safety matters too: without a promised way back to senior, people are afraid to try. A strong developer agreed to try, took the insurance products and grew them, and a year later moved to tech lead: he had tired of the role.

Step three optimises effort: there were clearly more than five teams — Alexander cannot say exactly how many — solving similar problems in different ways. The basic parts of the applications left the monolith for separate repositories, wired in as dependencies. Product managers appeared, owning business content and the roadmap, and communications were routed through a release manager: he tunes the process, is the single point where no product manager exists yet, answers for the content of releases and helps leads who grew out of engineers. What a scrum master answers for and how to measure him, Alexander notes, are both unclear: you can get every ceremony and no result. Metrics arrived too: the volume of functionality, the speed of launching it and quality must not be lost, so issue-tracker statistics went into a relational database with a BI layer, and one of the team leads helped build the charts. They showed releases growing in number with the teams while tasks per release fell, and the regression-time curve peaking twice — at a team of around twelve before the split, and when many teams began getting in each other's way. Missed defects seem to be trending down, and he hopes automated checks will keep them there.

Step four delegates responsibility to the leads. The remaining monorepo with the shared skeleton was in the way: a lead could say his team performed excellently, yet someone else's changes landed in his release branch with no alternative, and the effect of editing shared code on neighbours was unknowable. The applications moved into separate repositories, while the shared toolkit — a page engine, a forms engine, a tracking library — became dependencies developed like internal open source: a proper README, an architecture description, a usage example and plugin extension points that keep product-specific logic out of the engine. The engines are run by a core team with an architect and tech leads, which also assembled a small business application on them: an A/B test gave, in his words, a ten or fifteen per cent lift in conversion over the old solution. The step is unfinished: some products' forms still have to move onto the new engine. Metaphorically the lead grows from a kindergarten, where the teacher carries the craftwork away, through school homework-sized releases and university courses of shared tools, into an adult life of your own dependencies and decisions. What keeps you sane is clear business goals, an agreed architecture vision and knowing the lead's remit at the current step.