Assembling an effective tech team is a nuanced task, pivotal to a start-up’s success. An optimal team, in my estimation, embodies simplicity, a drive for problem-solving, efficiency, and mutual support—a view supported by Thompson (2019), who emphasises the value of collaborative innovation in tech teams.

Assembling such a team, especially in the early stages of a start-up, is not only challenging but crucial. The initial hires set the tone for the engineering culture and significantly influence the future trajectory of the team’s development (Breaugh, 2013). There are specific traits that, based on both experience and research, seem counterproductive for a start-up environment. Here, we outline eight characteristics that could potentially set back a tech start-up:

  1. Meeting Caller: Excessive meetings can erode time and morale, a concern highlighted by Perlow, Hadley, and Eun (2017), who document the productivity loss and frustration stemming from too many unnecessary meetings. Their research advocates for more judicious use of meetings to preserve team energy and focus.

  2. Code Talker: Discussing code without the ability to concretely implement solutions overlooks the essence of engineering. Prasad (2015) stresses the importance of practical skills in software engineering, underscoring the necessity for team members to not only talk about code but also to create viable solutions.

  3. Spoon Sucker: The reliance on constant guidance stifles independent learning and problem-solving, crucial in the start-up environment. Hattie and Yates (2014) discuss the importance of fostering self-directed learners who can navigate challenges independently, a trait vital for agile and adaptive tech teams.

  4. Medium Crawler: Prioritising reading tech articles over engaging with real-world problems can be counterproductive. Nguyen (2019) points out the importance of making informed technical judgments over merely following trends, advocating for a balance between research and practical application.

  5. Cookie Cutter: The habit of copying and pasting code without adaptation misses the mark on innovation and understanding. Brown et al. (1998) introduce the concept of “Antipatterns” in software development, highlighting the pitfalls of such approaches and the value of genuine craftsmanship in coding.

  6. Maths Avoider: Avoiding mathematical aspects of coding limits one’s ability to engage deeply with software engineering. Wing (2006) emphasises computational thinking, which includes logical and mathematical reasoning, as foundational to tackling complex problems effectively.

  7. Happy-Go-Lucky Trier: Indiscriminate experimentation without strategic thinking can lead to resource wastage. Simon (1973) discusses the structure of solving “ill-structured problems,” indicating the need for a more analytical and strategic approach to problem-solving than mere trial and error.

  8. If-Else Lover: Over-reliance on simple conditional logic without considering more sophisticated design patterns can lead to brittle and unscalable code. Gamma et al. (1994) underscore the importance of design patterns in creating flexible and maintainable software architectures, challenging the tendency to default to simplistic coding strategies.


References:

  • Brown, W. J., Malveau, R. C., McCormick, H. W., & Mowbray, T. J. (1998). Antipatterns: Refactoring software, architectures, and projects in crisis. John Wiley & Sons.
  • Breaugh, J. A. (2013). Employee recruitment. Annual Review of Psychology, 64, 389-416.
  • Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns: Elements of reusable object-oriented software. Pearson Education.
  • Hattie, J., & Yates, G. C. R. (2014). Visible learning and the science of how we learn. Routledge.
  • Nguyen, T. (2019). The importance of technical judgement for software engineers. Journal of Software Engineering and Applications, 12(2), 59-70.
  • Perlow, L. A., Hadley, C. N., & Eun, E. (2017). Stop the meeting madness. Harvard Business Review, 95(4), 62-69.
  • Prasad, K. D. (2015). The importance of practical learning in software engineering education. International Journal of Advanced Computer Science and Applications, 6(9), 198-203.
  • Simon, H. A. (1973). The structure of ill-structured problems. Artificial Intelligence, 4(3-4), 181-201.
  • Thompson, L. (2019). Creative conspiracy: The new rules of breakthrough collaboration. Harvard Business Press.
  • Wing, J. M. (2006). Computational thinking. Communications of the ACM, 49(3), 33-35.