skip to main content

René Morency

Why is building an in-house dev team so hard?

A member of a development team looks at a website mockup on a wall

As the opportunities that technology offers continue to materialise, there’s an ever-growing need for traditional companies in the banking, retail and services sectors to maintain their market share, generate profit, and of course, keep customers happy. I regularly hear about traditional companies recruiting to build an in-house technology or dev team in order to help them maintain a competitive advantage. Of course, they need the staff to make this happen, and it’s at this point I see so many fail.

So why is building an in-house dev team so hard, and why do traditional companies get it so wrong? I’ve seen companies hire individuals only to see them leave within months or even weeks. The problem here lies within HR, and their approach to defining the roles and what’s required. Hiring for specific skills simply brings you experts in that field. Yes, skill sets are needed, however, in order to make a difference and initiate a successful in-house team, it’s the individual attributes such as the willingness to learn and share that will bring sustainable success, at least in the initial few months.

An in-house dev team often begins small, and within a small team, hiring for specific skill sets such as a Javascript developer or system architect is too overly focused on doing one thing, this is by far the biggest mistake traditional companies make when trying to build their in-house technology team.

A small dev team work at a table as part of our hackathon
We run two-day hackathons every six months, giving everyone the opportunity to learn new skills

If you’re in the early stages of building a dev team, it’s far better to hire what I like to call generalists – people who lean towards a defined skill set but understand how everything else works, and if they don’t, then they must have the appetite to learn how every part of the process works. You essentially need developers that understand interface design, interface designers that understand information architecture, and information architects that understand… well, everything.

It’s not that you need a ‘jack of all trades, master of none’ team per se, moreover, you need individuals that have the inclination to actively learn and share what they do. When you get this right, it’s easy to see the benefits of a well-rounded team of generalists. It’s often surprising how much a small team with the right approach can produce in a short amount of time.

People are inherently curious, we enjoy learning from one-another, understanding how each part of the process works, and it’s this kind of attribute that helps small in-house teams really perform. The generalist helps to maintain a healthy appetite for dialogue, ideas sharing and teamwork. Most importantly the generalist understands just enough of everything in order to get the job done.