Scaling an engineering organisation from five to thirty-five

GenXAI Softgrid (formerly SoftGrid Computers) · 2010–2026

5 → 35
Engineers, over fifteen years
4
Cross-functional teams
4
Promotions, one company
Engineering headcount, 2010 → 2026

Engineering headcount grew from five in 2010 to thirty-five in 2026, and from one team to four. Four role changes are marked: PHP Developer in 2010, Team Lead in 2011, Technical Manager in 2012, and Head of Development in 2017. Intermediate years are indicative of the growth curve rather than exact records.

Context

I joined SoftGrid Computers in 2010 as a PHP developer. The engineering function was five people with no formal structure, no hiring process, and no shared standards. Over fifteen years I grew it into a thirty-five person department organised into four cross-functional teams spanning backend, frontend and DevOps — and in December 2024 came through the GenXAI merger with that organisation intact.

Leadership & decisions

Structure over heroics. The early team scaled by working harder. That does not survive contact with concurrent client programmes, so I moved to four cross-functional squads, each able to ship independently rather than queueing behind a single senior engineer.

A hiring bar, deliberately set. Indore is a competitive market and the temptation is to hire for immediate availability. I chose to hire slower against a defined bar, and to invest in training juniors instead — which traded short-term capacity for retention and a bench.

Standards as leverage, not bureaucracy. I established shared coding guidelines, architecture patterns and deployment workflows across all squads, plus reusable core libraries. By our own estimate these cut development effort on new projects by roughly a third. The point was not uniformity — it was that a developer could move between squads without relearning how work is done.

Retention as the real metric. Traffic figures follow from good architecture. Whether people stay follows from whether the work is interesting and the progression is real. I treated attrition as the number that mattered most.

Approach

Line management across the full lifecycle: technical recruitment, onboarding, one-to-ones, performance reviews, identifying training needs, and career development. Agile ceremonies and sprint governance for delivery, with roadmap ownership across multiple concurrent programmes.

Outcome

A thirty-five person engineering department, four squads deep, with low attrition and the capacity to run several concurrent client programmes. The reusable-library and standards work reduced project setup effort by an estimated thirty per cent.

Last updated: August 2026