Should I hire 10 Software Engineers or one x10 Software Engineer?

Should I hire 10 Software Engineers or one x10 Software Engineer?

Neither!

Well that was quick… on to the next subject!

Seriously though when I hear a startup/scaleup asking how to hire many Engineers quickly it’s usually symptomatic of a business whose current Engineers are swamped or a business that’s trying to tackle a founder/investor wish list of many targets at once.

What problem are you solving?

The first question I’d ask is why do you think you need 10 more engineers or an engineer superstar?

Often the answer is either;

• We have x many features we have to deliver, promised to investors/customers
• Our current engineering team is swamped with issues/bugs/rework

Or even both.

So if you have either or both these issues your problem is your team is context switching (what I less politely call “thrashing”). Context switching is highly inefficient so you’re not using your current engineering capacity effectively.

In general, doing something productive in software engineering takes concentrated focus and unbroken time for at least 2-3 hours, or about half a day. This is different from a manager who can gather information or make a decision in a 30 minute meeting. Engineers work on a different schedule to managers.

You don’t need to hire more engineers unless you’re hiring a consultant or senior engineer to coach your existing team to be more effective.

Stop thrashing

How can you stop context switching?

1. Identify the highest priority feature and focus an entire team of engineers on just that one feature to deliver something of value in 1-2 week, measure it’s effect, rinse and repeat until it’s not the highest priority then move on to the now highest priority.
2. If bugs and rework are sucking time from your team, be brutal about what bugs to address, only those losing you customers today! Carve out half of each day for addressing bugs. The other half should be looking to increase engineering efficiency. How? This requires another post to answer but the one liner is, start introducing practices that focus on continuous integration and deployment (not just tooling but culture and architectural decisions).
3. Reduce the number of meetings you pull engineers into. Schedule them to allow blocks of at least two hours between meetings.

I have a lot more detail on these subjects and if these are issues you struggle with let me know and I’ll write more.

PS

You never want to hire a so-called x10 Engineer, or at least the usual definition of a x10 Engineer, i.e someone who churns out loads of code and fast, is usually disruptive to a team and often produces code that’s hard to grok and harder to change. What you want is an engineer who multiplies your teams effectiveness by 5! I.e. not necessarily the best engineer technically but someone who identifies opportunities to communicate better and promotes quality and changability as first class concepts.