There are two engineerings.

The two engineering. And the software trap.

Engineering is the art of crafting artifacts and machines to solve humanity's challenges.

To build something new that works, you need science, experimentation, curiosity, ingenuity, physics, calculus, electronics, and much more. But in our society, building something is not enough, so we created production systems that help us replicate and scale the solutions we build. Those systems require engineering as well. But a different one, less based on experimentation and more on replication, standardization, and following the command chain.

So there you have one Engineering focused on the domains of our needs, and the other is focused on the engineering domain.

The previous distinction is super important when you are building software.

Software came late in the era of industrialization, and many authors have tried to fit it into the industrial age and create production systems for software based on domains like construction or manufacturing, causing more damage than good.

Building software has nothing in common with a production line or the job of an architect, but still, we have inherited concepts like architecture or time tracking in our industry. However, when the Agile manifesto appeared, the revolution began, and software started fighting for its own identity as an independent industry.

But the fight is not easy and is far from being won, and the ghost of certifications and standardization still haunts thousand of dev shops worldwide.

Don't get me wrong, those concepts are good when you are a monster in headcount and responsibilities, but avoid falling into the trap when you are a start-up.

Do not waste time implementing software development "good practices"; instead, define principles, design small software pieces, build them and validate them as fast as possible.

Start-Ups are not in the domain of software engineering. They are in the domain of human needs.

So when you select your technical co-founder, choose someone other than the guy who speaks about holy architectures, sacred methodologies, secret industry insights, or trendy technologies. That other is a different person, he or she must be aligned with your purpose, understands your and your customer's needs, and they will not hesitate to code something to validate fast.

Only in the US 75% of the software projects never meet the market. So if the industry is that inefficient, do you think an "expert" is the solution? I Don't.

The one is an Engineer who knows he doesn't know everything and needs to experiment. There are no shortcuts to creating a successful digital product. You start solving one challenge, then the other, and then following as many as they come, and if you solve enough, you will succeed.

Will.