What Makes an Effective Tech Team

What makes an effective team and how do you build one from ground zero?

My personal view on what makes an effective team include the following:

  • They communicate well, internally amongst each other and externally to the business;
  • They are balanced and mixed in terms of ability, i.e. senior, mid-level etc…;
  • They are multi-disciplinary — frontend, backend engineers, dev-ops engineers, QA, product;
  • They are continually improving, not just in their ability to solve problems by writing code, but in other areas — product/testing/site-reliability/effective meetings/communication;
  • They can participate in product thinking — pushback on half-baked ideas and provide the other side of the coin in terms of solutions and tradeoffs — hell they can come up with good product features as well;
  • They can understand and rationalise around trade-offs to achieve a deadline or pushback if it’s totally unrealistic.

I hear opinions from a wide array of people on this subject — investors, founders and teams themselves. I’m always inclined to listen to the people who truly feel the pain here — the teams coupled with the experience of working with and leading 20+ teams over my career.

These are common “opinions” that come up. You should strive understand the counterpoint to rather than following opinions of others. Do your own research here and come up with a balanced viewpoint on this. Listen to people from engineering backgrounds as well as people from similar backgrounds. Beware founders who have built successful teams — talk to their CTO’s, VP/Director/Head of engineering and understand their viewpoint. Remember they’re a few steps ahead of you — they may well not have started with the company from day 1 also!

Opinion 1. Hire based on strong academic backgrounds — Oxbridge all the way!

I mean this makes sense on the surface right? Clever people = highly effective people in the workplace, they can do anything they turn their hand to and adapt to a whole variety of situations. Undergraduate degree schemes are focused on teaching you breadth (Computer Science, Software Engineering) and covering a wide array of subjects (not just programming either) from Computational Science, Discrete Mathematics to Robotics, AI etc… You barely have time to master a single subject. Taught programming amounts for a subset of that. If you’ve had the opportunity to do a year out that changes things massively since you gain industry experience and focus on programming for one year solely. Great — that really helps when starting your first job.

Postgraduate research degrees help (in a different way) — they teach you critical analysis and how to breakdown and explore a fuzzy problem presenting three key points (for a PhD) or one (for an MPhil). Many people in industry don’t respect or understand this, it counts for very little in terms of initial salary. I personally, as an employer and exec, see this as a massive bonus, but only in a specific area and role. As a candidate here, you should be looking at job offers here carefully. I personally would avoid early stage startups, tech-enabled companies and focus on true tech companies. They understand you and can guide you.

I’ve seen first class degree (and post-graduate) students fail hard here for two reasons:

  • The perception that industry software development is trivial — the hard part is in the thinking. Bear in mind, it’s a big big space now compared to ten, let alone twenty years ago. Focusing on being good on devops is a full-time role, same with mobile-development, same with data-science/engineering, same with building teams and fixing people. It takes time to learn this space. Be patient.
  • They can tend to over-complicate solutions and lack pragmatism and commercial awareness. “Yes, it’s an interesting solution, but we can’t do it right now — it’ll take two years to build, we need to find a quick-win”. Hackers rule in some situations and their key area is pre-seed and seed funded startups where speed is of the essence. Strike a balance between “good-enough” and have a clear plan for “great” and you’re winning.

As an employer, you can already see this is way more nuanced already in terms of hiring graduates. Hiring people with strong academic backgrounds into roles where they have little support will end in failure. The expectations from an early stage startup employer will be focused around you’re super clever, we expect 10x (fuck 10x) and all kinds of magic out of you. However, remember they’re learning as well on this path, and have no practical experience themselves other than an MBA — ask them what kind of support they can provide you? Respect is due on both sides, but pick a founder who is candid, respects engineering and is humble as well as tenacious.

When you’re building a team, you are focusing on diversity:

Academic backgrounds, apprenticeship and self-taught backgrounds are part of diversity.

You want that because the pool is larger to select from — why would you limit it. You also want that because you need hackers as well as thinkers — too much of each will cause you problems.

With majority hackers you’ll end up with an Austin Allegro to run the Dakar Rally in. With majority thinkers, you’ll end up with a Rolls Royce and never make it to the start of the rally… Which one do you think strong academics will favour? I’ll let you decide : )

Getting a fractional CTO who knows when to go fast and what to future-proof helps me. Hint hint.

Opinion 2. Keep the team flat for now

I love this one and it has a striking relationship with the issues associated in the former point.

Flat Founders = Flat-teams ~ Flat-earthers

I believe the whole thought process around keeping the team flat is reducing hierarchical structure, reducing control and fostering creativity.


Well sure, that sounds great when you have two people, but when you have five, six, seven people who have been hired at speed you need to have people set the direction in terms technical leadership — front-end, back-end, data etc.. otherwise you’ll end up with a massive great stinky hodge-podge mess of different approaches. It’s simple:

  • Product Manager/Startup CEO or CTPO— sets direction on what to build based on qualitative, quantitative research and gut-feel (hopefully based on experience and talking to others);
  • Technical Lead/Startup CTO — sets direction on how to build the product in terms of infrastructure and technical architecture with the rest of the team feeding into this.

The latter point is crucial here. You need to involve the team in what you’re building and the lead needs to facilitate discussion and ensure people are contributing, but ultimately makes the final decision. There’s plenty of ways to do this:

  • Weekly tech meeting where you discuss technical architecture;
  • Cross-functional meetings to discuss front-end, back-end, data etc… if your team is big enough.

Why is this one level hierarchy my preferred approach?

  • You get a chance for others to kick the tyres on your straw person architecture and possibly improve it;
  • You get a chance to learn the process and become better engineers;
  • You provide everybody with the key architectural requirements needed to ensure they are successful and considering the whole.

At some point, normally around 5–7 engineers you’re going to want to think about starting another team (and focusing around something — mission, product area or something else). Some people still keep the team flat at this point, which leads to other problems. Think in terms of 5–7 pods with a lead in each and you’ll be fine.

If you have a flat team, you’re putting off the inevitable until another point in time. Some people do this to leave gaps in the organisation so someone can step up so they reserve the technical lead, head of engineering, even CTO title for that time. That’s just stupid, and usually because they don’t understand progression and growth in terms of career path. An engineer spends a minimum of 5 years progressing through the following:

  • Graduate;
  • Engineer;
  • Senior Engineer;
  • Lead Engineer;
  • Principal Engineer;

There’s plenty of room for growth in there.

If the decision has been made to “not hire a CTO” and reserve the C-level title then I’d be worried as an engineer. I absolutely will not join a company with this mindset, because it shows they don’t take “tech” seriously and think it’s factory or industrial side-arm of the business.

Opinion 3. Hire ONLY A-Players, ex Facebook, Google, Amazon etc…

I mean, seriously? Where do you think A-players came from? They didn’t start that way. They also didn’t necessarily inherit all the attributes of their mentors. I pitch people here at earning £130k — £160k a year on average at these companies, as engineers. Think about that for a minute — that’s £800k for five engineers. If you believe the whole 10x bullshit then that’s five megaflops of development power and speed — we can finish the the Dhakar rally in half the time (if we actually start it).

I do agree people with this background are highly effective in specific areas, but a WHOLE team of them? Good luck trying to manage the fall-out there and sorting out the complexity of the system you’ve inherited afterwards.

Again diversity is incredibly important here, you need to ensure you have a healthy mix of experienced senior engineers and early to mid-level engineers in your team. I typically find for the first five hires it’s tough hiring juniors and supporting them throughout the process. Aim for people with three to five years experience and that’s fine for now.

If you hire five seasoned veterans then that’s expensive and you could end up with turf wars over direction (especially if you’ve chosen a flat team). That means it has an impact on your pace to develop efficiently as an organisation and the individual members of the team. It’s not a nice place to be!

If you hire five early-stage engineers, because you’re optimising for minimum cost spend then good luck with the product (internally mostly) that emerges as a result of this. You’ll also find that they don’t tend to hire anyone more senior than the most senior person in the team. That’s another reason to avoid flat-teams and a reason to hire an experienced lead in the beginning.

In Conclusion

Be careful what your investors and fellow founders tell you about building teams. If they’re speaking from a point of experience and can provide the counter-point argument than great, but test them on that. If they can’t provide the counter-point argument take it with a pinch of salt and ask someone who understands.

I’m a fractional and interim CTO working for HWIntegral.com helping product and engineering teams to be successful and get to their next funding round. You can find out more here:

Consulting CTO (Interim/Fractional) — https://www.hwintegral.com