Four big mistakes when building an IT team

So you are building a company, right now. You chose to do E-Commerce,  social media or something else. But no matter what you are founding: You’re gonna need an IT team for that. It doesn’t matter if you’re building a startup from the ground up or if you have entered an incubator or accelerator program: You’re most likely in desperate need of an engineering team to build your product.

I have been doing that for about three years now and here’s the top three mistakes that I saw people make in that process…

Hire experts that are divas, assholes or idiots

It is the single biggest mistake you can make and it is not even dependent on IT: If you hire top-down and there is an asshole on top, there will be assholes in the middle and at the bottom very soon. Your company will be poisoned by an ego-driven or unfriendly genius that will mainly hire the kind of employees that can be pushed around easily and  are insecure. He or she will not hire the best people for the company but the best people for the purpose of making him or her seem even smarter.

When I assemble teams, I go for the humble, smart guy with an insecure look on their face when I do trick-questioning in the interview (even if they know their answer is right). I avoid the person that is arrogantly trying to deny answering simple questions, because it is beneath their ’superior knowledge‘. I would much rather work with someone who still wants to learn than someone who thinks they know it all. Don’t confuse this with going for the B candidate instead of triple A: You want the best man for the job but keep the big picture in mind!

Sometimes you will have the situation, where you have the experienced and smart asshole and the humble, smart but inexperienced guy in front of you. If you can, get the asshole as a consultant and hire the humble guy fulltime. It is much easier to gain knowledge than to unlearn being an idiot.

Start with too inexperienced people

Some of the time that I have seen companie’s IT teams implode was when the point in time came when everybody realized: We do not have what it takes to build this product. This can actually happen due to many reasons:

  • Missing expertise
  • Missing knowledge of tools and the stuff that you work with
  • Missing teamleading skills

If you hit that point, you only have one option: Learn how to do it. But you can go about this in two different ways, either you can learn slowly by self-teaching or you can buy knowledge. Self teaching can lead to deep knowledge over time, because you will make painfull mistakes and you will never forget what you learned the hard way. It can also be what breaks your neck because you run out of time and your time to market was just too long in the end. Hiring / buying knowledge can be very expensive and you run the risk of loosing core competencies to external people. On the other hand, it can save you time and trouble.

Missing trust

When the shit hits the fan – and that will happen during your first weeks of development – everything will go down the drain if the managing directors have no trust in their team. That goes for all business units, but since product is the most important one in the first days (prototyping –> demoing –> $$$), the tension is huge here. In the first days, IT has such direct business impact that every little failure is prominent and annoying.

You will have arguments like ‚That is not what I wanted‘ – ‚Well, then you should have said so!!!‘ and the like. Those can be mind-numbing and they can bring you to the absolute edge. The understanding of IT and business are normally far from each other and in small companies there is no translator like a product manager.

These discussions can be settled quickly, easily and without any further damages to the companies startup-spirit if the stakeholders (MDs, VCs, angels…) can put their trust into the professionals that they hired and recognize that they may have done great work, even if it’s not visible to them. The way they can do that is usually to get a third partie’s opinion and most likely this will be either

  • One of your business angels
  • A mentor or and advisor from your acceleration / incubation program
  • Someone else you completely trust in regards to IT (make them become one of the above!)

The one advise I can give to you in this situation: Calm down and get good advise! Do not argue with your IT team because you have no common ground at this moment and it will end in not being productive.

Means to create trust inside the development process are very clear communication, detailed specs and requirements, a well-structured development process with well-defined milestones and constant feedback all the time.

Miss a chance to get information

When you find someone who you think could be a great match for your company and who you think has the technical knowledge to build your product, then you should not hire them right away. What you want to have is as much feedback as possible on the person as you can get. The best sources of information are:

  • The IT crowd: Google the shit out of that person
  • Former colleagues / bosses: Maybe you have a connection on Xing / LinkedIN to them?
  • Advisors & mentors: They usually know some names in the business and if not, then they can do interviews for you

You never ever leave a piece of information on the road here. Even information from idiots can be validating that the person you are about to hire is not one of them!

Go through several rounds of interviews, make them as informal as possible, i.e. have lunch dates, coffee breaks, quick calls to brainstorm or chat sessions. Make them provide small proof of concepts for you. Get work examples from previous projects. Whatever you can get will be helpful and will increase the foundation of your decision. There is no such thing as too much information when it comes to future employees of your IT team!


  1. Hire professionals that are able and willing to learn quickly, no assholes.
  2. If your team does not have expertise, get it from external experts and build knowledge inhouse.
  3. Trust your team, create means of trust and communicate well.
  4. Get all the information you can on people you’re about to hire.

2 Kommentare

  1. There seems to be one additional mistake you should not make: Hire anybody who tells you that PHP is a „good language“ without explaining why (which seems to be impossible anyways).
    Want to know why? go here:

    There’s a good quote summing it up (and yes, it’s quite mean 😉 ):

    „PHP is a community of amateurs. Very few people designing it, working on it, or writing code in it seem to know what they’re doing. […] Those who do grow a clue tend to drift away to other platforms, reducing the average competence of the whole. This, right here, is the biggest problem with PHP: it is absolutely the blind leading the blind.“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert