Hey! How are you doing?
In the previous Mektup, I talked about the role of a software architect and promised to explain the technical breadth, mentality, and knowledge styles that architects should seek. Now let's talk a bit about it.
Mark Richards and Neil Ford use the knowledge pyramid to explain the difference.
On the top layer, we have the stuff we know: our knowledge and expertise. In the mid-layer, we have the things we know that we don't know: the things we know exist, we've heard or used them, but we don't have any expertise. The last but the most significant portion of our knowledge is the stuff we even don't know exists; we simply are not aware of them.
Developers spend their life whetting their expert skills by growing their knowledge on the subject, a.k.a. the top layer in the pyramid—technical depth. The bigger the top layer, the more expert the developer is. For architects, the second layer is more important than the top. Here the technical breadth comes in; how much the middle layer expands into the bottom layer defines the breadth. Both top and mid-layers are essential for an architect, but architects sacrifice some parts of their expertise to expand their portfolio. They learn new skills but don't get any deep knowledge of them. For architects, it's more beneficial to have a broader understanding of various technologies than to have expertise in one or two.
The transition in knowledge acquirement is where most developers struggle while becoming architects because they don't want to leave their expertise behind. Having deep knowledge requires maintaining it, and architects have no time to both broaden their knowledge and keep their expertise. They can still have expertise in one or two languages or frameworks, but these technologies mostly stay at the hobby level. Architects need to acquire knowledge about system design, architectural characteristics, and architectural styles, but not how to implement user authentication in NodeJS. They might still learn it, though; it's okay to have deep knowledge of one or two topics. But it's not required.
The technical breadth vs. technical depth is only one small part of the architectural thinking and software architect's job. I'm preparing more detailed stuff for architectural thinking (either a podcast episode or a blog post). Before letting you wait for that, I want to share a sneak peek with you. Here you can find out the work-in-progress mind map I am using for the preparation of Architectural Thinking. You will see that technical breadth is only one part of it. (UPDATE after publishing the newsletter issue: here are the podcast episodes: 1, 2)
That's it. If you think I missed something in the mind map or would love to share your thoughts, you know how to reach me: just hit the reply button below (Twitter works too).
What I published over the last two weeks
"Whether it's up, down, or cross, you have to build relationships and trust in every direction." - Jim Allen
On the recent episode of the Software World, I welcomed Jim Allen, Head of Engineering at Jimdo. We talked about managing changes in organizations, the reasons for changes, and how to navigate difficult situations caused by the changes.
Listen to our conversation with him here.
I worked as the only remote employee on the team before the pandemic. I had not-so-good meeting experiences. These days, many companies discuss going back to the office and having a hybrid workforce; I decided to write down my experience and thoughts on hybrid meetings.
New Blog Post Format: 1 Idea 9 Questions
Before I publish some of my blog posts, I ask myself nine questions to clarify my thinking. I adapted the method from Luca and adjusted to myself. With this new format, I'm sharing some of my ideas and how some of the blog posts come to life.
Here are the three of them I published.
- 1 Idea 9 Questions: Timely Estimations are Underrated
- 1 Idea 9 Questions: Everyone Should Use Joint Meeting Documents for 1:1s
- 1 Idea 9 Questions: Hybrid Meetings are Terrible
The Best Thing I Read In the Last Two Weeks
"The availability heuristic explains why winning an award makes you more likely to win another award. It explains why we sometimes avoid one thing out of fear and end up doing something else that’s objectively riskier. ... It explains why the five people closest to you have a big impact on your worldview. ... And it explains why bad publicity can still be beneficial in the long run."
The article reminded me (and also mentions) of the availability heuristic that Daniel Kahneman mentions in Thinking, Fast and Slow. The book is fantastic, but it's hard-read. On the other hand, the article is excellent and full of explanations and recommendations.
P.S.: I'm a fan of Farnam Street.
As always, if you are enjoying Mektup, I would love it if you shared it with one or two of your friends. You can send them directly here to sign up. They will get this issue as a gift when they sign up. I try to make Mektup one of the best and most actionable emails that you get to grow your software engineering and leadership career.