Engineering Teams Need Craftsmen, Not Just Artists or Scientists

When I'm hiring developers at Full Scale or building teams for my own ventures, I always face the same question: what kind of people truly build exceptional software?

Is it the brilliant "artists" who write elegant, creative code but march to their own drummer?

Or is it the methodical "scientists" who approach every problem with rigorous analysis but might get lost in the details?

After 20+ years of building and scaling software teams (and three successful tech companies later), I've realized something important: neither approach is quite right.

Software development isn't purely art or science. And despite what our job titles might suggest, it's not exactly traditional engineering either.

It's a craft.

The Problem with the "Art vs. Science" Debate

When I started my career around 2000, we called it "software development" - not engineering. Computer Science was the degree, but what we actually did daily didn't match either label perfectly.

If you're leading a tech team, you've probably seen this disconnect play out in problematic ways:

  • The "artists" on your team create beautiful, clever code that's often difficult to maintain and doesn't always solve the actual business problem

  • The "scientists" get caught in analysis paralysis, overengineering solutions while business needs shift underneath them

  • The strict "engineers" follow processes so rigidly that innovation gets stifled

These misalignments cost you time, money, and competitive advantage.

Why Software Development is Truly a Craft

Think about commissioning kitchen cabinets for your home. You explain what you need - the utility, dimensions, and requirements. Then craftsmen take those requirements and build what you need.

They have freedom in how they architect those cabinets - what materials to use, whether to use dovetail joints, what hidden details to include. There's expertise and judgment involved, but ultimately, they're building something to solve YOUR problem.

Software development works the same way.

When we acknowledge software as a craft, several important truths emerge:

1. The outcome matters more than the code

As a CTO or technology leader, you understand that customers don't care about your elegant architecture or clean code - they care about what the software DOES for them.

As I tell my teams: The end result of what we do is not our code. The end result is the product - the outcome we deliver to somebody else.

2. There is rarely one "right" answer

Ten different developers will solve the same problem ten different ways. Unlike traditional engineering where physics dictates specific solutions, software development offers endless possibilities.

This is why rigid development methodologies often fail. The craft requires judgment and adaptability.

3. It's inherently collaborative

Unlike pure art (think a painter at an easel), software development is team-oriented. As I've built teams of 100+ developers, I've learned that successful software requires people working together with shared standards and approaches, while still allowing for craftsmanship in implementation.

Building a Team of Craftspeople

So what does this mean for you as a technology leader trying to build high-performing teams?

First, recognize what you're really looking for. You don't want pure artists or scientists - you want craftspeople who:

  • Take pride in their work but understand it serves a purpose beyond itself

  • Balance creativity with practicality

  • Value both individual expertise and team collaboration

  • Understand that requirements and constraints are part of the craft, not limitations to it

At Stackify (my previous company that we successfully exited in 2021), we built a hybrid team of local and offshore developers using this craftsperson model. We paid our local employees extremely well but dollar-cost averaged our overall development expenses by leveraging offshore resources who shared our craftsman mindset.

The Danger of Over-Engineering

One lesson I've learned repeatedly as a startup founder: too much "engineering" can be as dangerous as too little.

Early-stage companies need to move quickly. Many developers coming from large enterprises want to over-complicate and over-engineer everything, which becomes a significant liability when you're trying to find product-market fit.

The best craftspeople understand context. They know when to build for scale and when to optimize for speed. They can shift between these modes as business needs change.

Finding Your Balance

As a tech leader, your job isn't to decide whether software is art or science - it's to create an environment where the craft can flourish.

This means:

  1. Hiring for craftsmanship - Look for people who take pride in their work but understand they're building solutions for others, not monuments to themselves.

  2. Balancing standards with flexibility - Establish enough structure to ensure quality and consistency, but leave room for creativity and innovation where it matters.

  3. Focusing on outcomes - Judge work by how well it solves the problem, not by how clever the code looks or how rigorously it follows a methodology.

  4. Embracing the team aspect - Foster collaboration and knowledge sharing to elevate the overall craftsmanship of your organization.

The Craftsman Approach in Action

At Full Scale, we've built a team of over 300 developers using this craftsman philosophy. We've found that developers who embrace this mindset:

  • Produce more reliable, maintainable code

  • Adapt better to changing requirements

  • Collaborate more effectively with product and business teams

  • Find greater satisfaction in their work

This isn't just theory - it's how we've helped over 200 companies scale their development efforts successfully.

Championing the Craft

Software development's power comes from being neither pure art nor rigid science. It's not even traditional engineering. It's a craft that balances creativity, technical expertise, and practical problem-solving.

When you build teams that respect the craft nature of software development, you create an environment where people can do their best work - work that actually solves business problems and delivers value.

That's what makes a truly exceptional engineering team.

Want the full story? This article is based on my latest Product Driven episode.

🎥 Watch the full episode: Why Software Engineering Is Neither Art Nor Science

Join 57,938 others, follow me on LinkedIn.

Matt Watson is the host of Product Driven and co-founder of Full Scale, a global staffing company that helps businesses build and scale their engineering, finance, marketing, and admin teams. A three-time founder, he grew VinSolutions to $30M ARR before a $150M exit, later sold Stackify in 2021, and continues to share insights from his entrepreneurial journey through his podcast and this newsletter.

Did someone forward this email to you? Sign up here!

Reply

or to participate.