If you needed to get a small car across a river, would you hire someone who has never built a bridge before? If you get a really good engineer, with bridge building experience, who makes great trade-offs, you get there faster. Sure, there is some risk that people who build huge bridges will want to build more bridge than you need. You should manage that. Also, if he was a great engineer, he would recognize the unique requirements of this situation and adapt.
Architecting products can deliver a variety of benefits, typically referred to as the “ilities”. The ilities that I have traditionally valued most, along with the architects that I have typically enjoyed working with, given that the work we are typically focused on is pretty early stage technology, tend to be things like “flexibility”.
Sometimes I see a blog post like this one. And my reaction is, “sounds like you are working with the wrong engineers”, not that working with senior architects is bad.
Let’s be real. The most widely agreed upon truth in software development is that there is a 10x difference between awesome engineers and average engineers. A critical goal, in building a company, is to get as many of those 10x engineers as you can. He who gets the most typically wins.
I have found that a senior guy that is also a 10x guy, builds a product that is easier to adjust, designed for extensibility, and all that other good stuff. And many of the design decisions are decisions he makes subconsciously. He simply works in a way that generates better outcomes. Some of the decisions that young engineers make is not a road to shipping the product faster, it is simply the path of least resistance that they understand best.
For me, the sign of a great engineer is not an instinct to over-architect. It is the intuitive ability to sense how much architecture is appropriate and when that architecture should be introduced. What abstractions are appropriate and will accelerate time to market and accelerate our ability to add new functionality to the system and which ones are inappropriate when you are still testing market feasibility. I have seen multiple instances where it was implied to me that Minimum Viable Product mean “seat of the pants coding so we can get to learning faster”. Anyone that has been around the block can tell you that this is probably not a path to take you where you want to go.
There are only a few Joe Stump‘s or Dimitrij Denissenko‘s out there. You should hire one. I see architects all the time that are hand-waving preachers of building big systems. I hate that. Let’s ship a product and then scale. Good architects can do it. Bad architects could be inexperienced or they can be people that over-architect.
Minimum Viable Product is, to me, an approach to Product Management. Gold-plating requirements makes development tough. Over-architecting products makes development tough. Engineers love the idea of Minimum Viable Products because it emphasizes frequent iteration and maps well to Agile, but it should not be used to justify taking inappropriate shortcuts in product development. Hire the most senior, most awesome developers you can justify. Been there, done that means a lot in engineering.