Learning The Hard Way

November 2, 2007 | 3 Comments

When my role changed from developing to architecting I put a fair amount of thought into what I thought would make a good architect. My goal was instead of saying something was impossible to explain to the business folk what it would cost them in terms of money, people, and trade-offs. The philosophy is that technology should not be a barrier to the products and experiences that the business wants to create.

I’ve now come to a point where either I am completely incapable of articulating costs, or the business folks just don’t care or believe me. It is not a fun position to be in to explain to someone “doing X means horrible thing Y occurs” and they choose X anyway. If Y has no direct impact on the individual’s goals then it is understandable why they might want to proceed anyway. The typical case for this is when the technology is not designed to deliver the experience the product needs, which leaves me in a tough spot. We either:

  1. pay the (often prohibitive) cost of doing it correctly
  2. cram the square peg in the round hole
  3. come to a compromise
  4. don’t do it

The first two are (by the philosophy) successes, while options 2 and 3 are the more popular choices. Option 2 has costs as well, but they are the external types of costs I described above: the code becomes unmaintainable; the ability to deliver features will slow to a crawl; the complexity will eat us alive.

On the other hand, is there a practical difference between saying “that’s impossible” and proposing consequences of proceeding so dire that no reasonable person would proceed? It seems like the former would be significantly less frustrating and yield better results, but shameful at the same time.

This post is brought to you by late night rambling and sleep deprivation


  1. [...] Read about Pablo’s move from developer to architect roles.. [...]

    Pingback by Vlad Mazek - Vladville Blog » Blog Archive » Three great posts to read while I’m remodeling — November 11, 2007 #

  2. You’re talking about a different problem than I think you realize. It’s not a problem of the business people not understanding; it’s that they don’t care. An architect position is a good place to be in, but only if you have the authority to push it forward.

    In other words, the right idea is not worth much if a business wonk can say “no, thanks, we’d rather fuck ourselves over.”

    My first goal in these positions is to very clearly define what my responsibility and authority is. Where there is a divergence of the two, aim to divest yourself of the responsibility you have no authority to implement. Otherwise, it’s a waste of everyone’s time.

    In general, business people will DTRT when forced to pay for the right solution. They don’t want to sabotage the company/mission/project, but they don’t want to be seen as the person who caves to rampant technologisation. So take that decision out of their hands, and instead let them work within a framework of good decisions. Later on, if you find you have a surplus of resources (let’s be frank, often choice 1 can lead to this), you can reapportion as necessary to other projects.

    However, it’s a very dangerous place to be in, being the bearer of bad news (your square peg costs too much) and being overridden by people who fundamentally don’t understand the process or components (my square peg sure as hell *does* fit into that round hole). You’re both marginalized and portrayed as the bad guy. It doesn’t take a genius to figure out where that leads.

    Comment by Alex J. Avriette — November 27, 2007 #

  3. Hi Pablo,

    I was just happily googling away, and decided to check on my good friend Pablo Averbuj… imagine my confusion when I found out there was another, with a partner called Leigha… My Pablo is an Argentine Jew, currently residing with his Aussie wife Sophia in Stuttgart. I just thought I’d say hi to you, his namesake, as he is such a good guy and sharing a name may mean sharing those good characteristics. Take care X

    Comment by Ayla — April 8, 2008 #

Sorry, the comment form is closed at this time.