Easier Recruiting and Team Scaling With Radical Simplicity

Hiring is always a challenge. For a development department with many roles and many open positions, every role needs to be recruited separately, which means many different jobs ads, descriptions for headhunters and many different pipelines.

Radical Simplicity means building software with as few moving parts as possible. This enables developers to move faster and to turn faster. But it doesn’t only help with developing, it also helps with hiring. If a technology department has fewer moving parts, fewer different databases, fewer systems, fewer programming languages and fewer frameworks, it also has fewer roles to hire. Instead of frontend and backend developers with a myriad of different skills, you only need to hire mostly one role of developer.

With fewer roles and smaller skill sets CTOs need less job ads. The saved money can be used for different job ads for the same role, targeting different audiences and doing A/B job testing on titles and content. Fewer roles means better positioning as a company and employer brand.

Interviews get easier with Radical Simplicity. When interviewing candidates you need to know what the role you want to hire needs to do and what skills you want. Often recruiters don’t have the time to research the skill set or in a startup you might not know the skills needed for the role, as you haven’t done the job yourself. With fewer roles recruiting gets easier. You become a specialist for recruiting that one role you need and the few skills needed, very fast. Each candidate can be checked faster and easier if she has the skill set needed for the role.

Small startups have many developers with a bus factor of one. If that one developer “is hit by a bus” which usually means he leaves the company, those precious skills are lost. The knowledge of that developer is gone and because it takes time to hire a replacement, the startup suffers. With Radical Simplicity there are much fewer developers with a bus factor of one. Everyone knows the same so if one developer leaves, there is no big impact.

This also means more flexibility. If you have fewer roles, those people are more flexible moving around and working on different things. Classical departments try to handle this with “Fullstack Developers”. But as the stack has been growing and growing, this breaks down and “Fullstack Developers” have thin skills in each of the parts of a stack. With Radical Simplicity you gain the same flexibility as with “Fullsack Developers”, but with developers that are expert in every part of the much smaller stack.

Skill Matrix

If we compare the skill matrix of a development team with a wide range of systems, languages and databases to a team that practices Radical Simplicity, we see how much more skills are needed and how much more roles are needed.

Example Radical Simplicity Skill Matrix

With a simpler skill matrix ist easier to build cross-functional teams. Cross-functional teams reduce communication overhead and decision overhead and speed things up. If you need less skills to develop a feature end to end, you need fewer people in your cross-functional teams. CTOs need to fill less skill holes in those teams because there are fewer gaps. When it is sometimes difficult to get all the people and budget for cross-functional teams, it becomes easy with Radical Simplicity.

Scaling organisations with radical simplicity becomes also easier. Because you have cross-functional teams and need less skills and no special teams with special knowledge, you can easily add more teams by forming them new, splitting up existing teams and grow them or grow existing teams and then split them.

When scaling a development department you many new developers. After hiring them they need to be onboarded. With a complex architecture with many different technologies onboarding is a challenge, take a lot of time and many companies skip this important part and implement “learning by doing” and “move fast and break things”. So even when you find developers fast and hire them, because of complex systems their impact takes time. It is much easier to onboard new developers with Radical Simplicity. The number of different systems is small, the number of languages is small and the number of frameworks is small. Everything is as simple as possible. New employees get up to speed very fast and have impact early on. Which makes scaling the technology department easier and faster.

Recruiting tech talent is hard. Use Radical Simplicity to make it easier.

About Stephan

As a CTO, Interim CTO, CTO Coach - and developer - Stephan has seen many technology departments in fast-growing startups. This is where the idea of Radical Simplicity comes from, because he has seen too many complex setups that costed money and had their problems. He taught himself coding in a department store around 1981 with VIC20 Basic and went on to write code - and was paid for many of them - in C64 BASIC, 6502 machine code, CPC BASIC, Z80 machine code, 68000 machine code, Amiga BASIC, GFA BASIC, Blitz Basic, QBasic, Turbo Pascal, Modula-2, Oberon, Delphi, C, C++, Lisp, Prolog, Perl, Python, Java, Javascript, Scala, Erlang, Haskell, TypeScript, Go and Rust amongst others - using VIC20s, Sinclairs, C64s, Sharp Pocketcomputers, CPCs, Amigas, Beboxes, Atari STs, MSDOS machines, Windows machines, Linux - pre distro - machines, SUNs, SGIs, NextCubes, and many Quadras|iMacs|MacCubes|MacBooks|MacBookPros|iMacPros. Stephan has founded several startups and worked in small and large companies as CTO. After he sold his latest startup he took up CTO coaching. You can find him on LinkedIn

Stephan also wrote a CTO Book