A deal platform for an Australian investment bank
Deal-processing platform for one of Australia's largest investment banks. Grew the delivery organisation from 3 engineers to 30 across six teams in four countries, then handed it over and went back to engineering.
At a glance
- Role
- Lead Front-End Developer / Team Lead, and de facto project manager: client relationship, hiring, Scrum, environments and CI
- Engagement
- Employee of Luxoft, delivering for the bank
- Timeframe
- Dec 2016 – Jul 2018
- Team
- 3 → 30 engineers in six co-located frontend teams; QA in India, backend in the US, client in Australia
- Stack
- React · Redux · Angular · Jest · Protractor · Jenkins
- ◆3 → 30 engineers in a year (3 → 15 in six months), across six teams
- ◆6 teams across 4 countries and 4 time zones
- ◆The client's test-coverage bar went from 85% → 100%, and we held it
- ◆Top contributor by commits while leading, until the team passed six or seven engineers
Context
The platform handled deal processing for one of Australia's largest investment banks, under strict security and compliance requirements. My organisation built its front end in React and Redux, alongside Angular, tested with Jest and Protractor and shipped through Jenkins. In this domain a defect is a financial event, not a bug report.
The work was split by function across four countries: my frontend teams co-located with me, QA in India, backend in the United States, and the client and my own management in Australia. Nobody else sat at the intersection of all four.
I inherited three developers who were not delivering and not willing to. That is not a process problem, and no amount of Scrum fixes it.
Constraints
- ›Compliance: strict security and compliance requirements, and a client who set and enforced the test-coverage bar.
- ›Distance: four countries and four time zones, with integration points owned by other groups.
- ›Growth under delivery: the team grew tenfold in a year while releases every two weeks kept shipping.
- ›Hardware: memory-starved machines, fixed in a day once I escalated to the head of the local office.
Architecture
Six frontend teams of five, each with a lead, developers and its own QA, so each team took its features from build to test itself. They integrated with the backend group in the US and the QA group in India through shared environments and a CI/CD pipeline I owned. One documented, automated setup brought up the whole project and connected it to the VMs, so onboarding did not depend on a senior engineer's afternoon.
Key decisions
| Decision | Why | Trade-off |
|---|---|---|
| Replace the team before building on it | The three developers I inherited were not delivering and not willing to. I made the case, got approval and let two go; the third was talented, stayed, and we worked well together. | Slower on paper at the start; faster in practice. |
| Take the throughput gap to the client as a business case | At six or seven engineers I had stopped writing meaningful code, and the client had far more demand than we had throughput. Growing to 15, then 30, served the client, the vendor and the project. | I gave up most of my own coding time. |
| Self-contained teams, each with its own QA | Work moves from build to test inside one team instead of being passed sideways across time zones. | Six leads to grow and align instead of one. |
| Delegate hiring as strong leads emerged | I interviewed every early hire myself, then brought team leads into interviews so hiring could scale past me. | Less direct control over who joined. |
| Make onboarding a solved problem early | With engineers arriving constantly, each day lost to environment setup was lost throughput. I wrote the docs and the automated setup myself. | My own time spent on tooling instead of features. |
Outcome
- ◆3 → 15 engineers in six months, 15 → 30 in the next six, across six teams.
- ◆Releases every two weeks, each on schedule, across two years of structural change.
- ◆Coverage bar raised from 85% to 100% on business logic, and held.
- ◆New engineers opened their first pull request within a few days of finishing mandatory training.
- ◆The client flew from Australia to visit the teams in person and thank them for the results.
- ◆Handed over fully to a manager I hired and onboarded, then went back to engineering.
What I'd do differently
- ›An engineer I hired early clashed with the client's team and emailed, in effect, that he knew better and did not need his pull requests commented on. Within a day the client's coverage bar went from 85% to 100%. I negotiated directly, apologised, took him off the project, and the relationship recovered quickly.
- ›The lesson was about access, not the hire: interviewing well is not evidence of composure with a customer in the thread. I now grant direct client access deliberately, to specific people at a specific time, rather than letting it arrive with a seat on the team.