Why is it so important for architects to be connected to the engine room? In short, to validate (or invalidate) their assumptions. Architects make decision based on mental models and heuristics. However, the systems we deal with evolve and change rapidly, forcing us to revisit our past assumptions. For example, many architects still aim to eliminate any duplication in their systems. However, modern development, testing, and automation approaches have made it much easier for us to handle duplication while Economies of Speed highlight the cost of de-duplication. That’s why many organizations now tolerate duplication and some even favor it (consider the famous Amazon “2 > 0” mantra).
Visiting the engine room keeps architects from the proverbial ivory tower: making decisions and passing them down via a one-way command-and-control setup, ignoring downstream costs and challenges. In the past, assumptions and heuristics held longer thanks to slower evolution of the underlying technologies, allowing architects to get away with some amount of ivory tower-ness. At the current pace of technical evolution and the rate at which disruptive technologies arrive, not visiting the engine room regularly would be considered gross negligence for architects.
“Y'all keep telling us AGI is around the corner but can't even have a single consistent definition of it on your own damn website,” tweeted Timnit Gebru, a computer scientist who was fired from Google for publishing a groundbreaking paper about the risks of large language models, which includes its dangerous biases and the potential to deceive people with them.
Emily M. Bender, a professor of linguistics at the University of Washington and the co-author of that paper, tweeted: “They don't want to address actual problems in the actual world (which would require ceding power). They want to believe themselves gods who can not only create a ‘superintelligence’ but have the beneficence to do so in a way that is ‘aligned’ with humanity.”
To make matters worse, unless we manage well, tougher projects tend to dimish congruence–because stress tends to rise when the expectation of quality rises. We are not always utterly logical creatures, but have feelings as well as thoughts in response to tougher assignments. When these inner feelings are strong enough, they translate into characteristic styles of coping with the stress. If our characteristic style is incongruent, communications become less effective and the job becomes even more difficult, creating a viscious cycle.
Congruence, of course, is but one of the factors in effective communication–other factors include such things as timeliness, memory, proper audience, and accuracy of data. But without congruence, your efforts to improve these more “logical” factors will always be seriously undermined, along with your ability to build bigger, more complex, or more reliable systems.
When the money flows freely, and there's a strong cachet to having tons of open positions, you can be forgiven to think that the individual productivity on a product team just doesn't matter. So much time is spent coordinating the work anyway. Who cares if the stack you're using takes twice the number of people to ship meaningful updates? You can just hire four times as many heads!
Those days seem to be over, at least for most SaaS startups. Entrepreneurs everywhere are suddenly having to count each hire as a cost rather than a trophy. Getting to profitability is no longer a distant, post-IPO nice-to-have, but a short-term necessity for survival. But how to do that without cutting off the legs of the product team? By using better tools and techniques, that's how.
I've been talking to a lot of SaaS entrepreneurs lately. Here are the three pieces of advice that I've given them all
