Mektup #8: Technical Depth vs Technical Breadth

Hey! How are you doing?

In the previous Mektup, I talked about the role of software architect and promised to explain the technical breadth, the mentality, and the knowledge styles that architects should seek. Now let's talk a bit of 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 them 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 they sacrifice some parts of their expertise to expand their portfolio. They learn new things but don't get any deep knowledge of them. Because in the architect role, 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. The case is that the stuff you know is also the stuff you maintain, and architects have no time to 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 around system design, architectural characteristics, architectural styles, but not how to implement user authentication in NodeJS. They might still learn it; 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 the 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.

That's it. If you think I miss 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 last two weeks

Podcast: Managing Organizational Changes with Jim Allen

"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 the organizations, the reasons for changes, and how to navigate difficult situations caused by the changes.

Listen to our conversation with him here.

Why are Hybrid Meetings Terrible? Remote vs. On-site Meetings

I've worked as the only remote employee in 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.

The Best Thing I Read In Last Two Weeks

The Availability Bias: How to Overcome a Common Cognitive Distortion

"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.

End Note

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 actionable emails that you get to grow your software engineering and leadership career.


Jun 24, 2021
Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.