TL;DR:
- Company values, or mantras, effect architectural decisions
- An architecture is not a company value
- Philosophy has a lot to do with resilience and architecture
“You are entirely correct but you’ve also horribly failed your task. You are way off track. These are not values”. Gal said after I showed him The Triangle, what would become the philosophical layer and guidelines of Silo’s architecture.
I’ve first met Gal, in a meetup group called R&D Leaders in Tel Aviv. We were both two guys who were way too early, two guys who decided to get some fresh air out on the porch. As there was no one there but us, it was only natural we’d start talking. He was an experienced engineering manager at an Israeli R&D Center of a major American company (not the one you’re thinking of, the other one). I’ve just recently joined Silo and I was nothing but a somewhat senior engineer and with less than two years of management experience as a team leader. He managed 20 people at the time. I managed exactly zero.
As I was managing no one, I felt out of place in this group. So when Gal asked “what are you doing in this group?” I thought he was being arrogant and condescending. He wasn’t. “I’m not entirely sure”, I said and paused for a second. “All I know is that today I have zero engineers. If my company is going to be successful, in two years I’ll be managing at least 20 people. I don’t know how to do that and if I will never learn, I would cause my company to fail. I joined this group to learn”. I guess he liked me and my answer, as a few months later he became my mentor.
A mentor helps you to get this job done, where you are now, and I needed help with that. Our talks never focused on anything technical or architectural in nature. I probably could have used his help deciding to go with Jira or Trello, Kanban or Scrum, AWS or GCP, but it was not worth our precious time together. We’ve mainly talked about career, people and people management. Resilience has a lot to do with people, or as software developers call them, humans. So does architecture.
One of the most important lessons he gave me had to do with trust, how to gain and maintain an employee’s trust in you, how to convey your trust in him. Let him make a mistake, or to be more exact not to correct him before he made one. Saying “don’t forget to do X” before an execution, may ensure he won’t forget to but also may cause a mistrust. That would be him hearing you say “I don’t trust you to remember”. Saying “you forgot to do X” prior to finishing an execution, like in a code review, is a lesson taught at the right time and in the right context, after he actually forgot.
To say that resilience and architecture has nothing to do with people, is wrong. The above was part of the reasons that we had CI/CD pipelines and TDD/BDD embedded in our culture. It acted on my behalf as the engineering manager, to let a developer make a mistake and tell him during execution that he did something wrong. Not in advance and not after, but during. Later it evolved to one of our mantras of “don’t be afraid to make a mistake”. The CI/CD is a system that lets you make mistakes and ensures they won’t reach production. Mantras, or company values, do have an effect on architectural needs and decisions and should be considered during design and execution [You’d see an actual case we had at part III of this series]
I’ll give another example that may sound very ridiculous, but in hindsight it makes sense. I hope you’d read the series of articles about Cloud Computing Evolution, but server utilization also has ecological consequences. If we’d use less servers, there would be less CO2 emissions. we’d be a more eco-friendly company. That is a part of Silo’s marketing company value, or what you may call a brand. As Silo is about food freshness and conservation it is a green/eco-friendly brand. Seriously, no one would ever attack our brand by saying we are using too many servers. But now that you’ve read it is possible, do you still think it will never happen?
A more concrete example of a marketing value would be related to security, or to be more exact privacy. That is a huge leap of faith a person has to take in order for him to put our device, that has microphones in it, in a most intimate room. You’d be amazed how many intimate moments occur in the kitchen, such as couples fighting. Nobody would ever want this to be recorded. So Silo’s architecture must consider privacy.
Company values, both internal and external, are things an architect should consider. That other way around is not true. Although they are somewhat connected, an architecture is not a company value, as Gal said in our second meeting when we talked about company values.
He gave me a task to write a document with company values. The company never ended up with one, but we did have our mantras which we kept repeating during 1:1s, during design meetings and even during code reviews. As this is a boog about architecture and not about management, this series of articles would not be a review of our mantras but a dissection of The Triangle, the one I showed Gal that day. Although it has nothing to do with company values it has evolved to be the architecture’s philosophical layer.
It has guided me through many architectural decisions towards understanding and gaining resilience, not to treat it as a mere buzzword. I’d recommend you read the following series to better understand the rest of the boog, to better understand where everything came from. If you’d carefully look, you’d see this philosophy intertwined into all the articles of this boog.