The Monk and The Rockstar

I have been doing practical and real software architecture for more than 20+ years. Software architecture is a great passion of mine, close to my heart and even to my identity or just id function if we think about functional programming :-). I have mentored and coached many architects during the last two decades. Today, I want to share some thoughts on something that represents the complexity and duality of the software architect role. Being an architect is not easy, it requires a lot of sound judgment, trade-offs analysis, design skills, research, requirements extraction, trend prediction, futurology, and lots of non-obvious skills. Architects must code, be practical, and make very good calls, resulting in better positioning for the future. Doing such a task is not easy and requires a lot of hard work; it’s demanding and requires constant improvement and attention to detail. What is essential to extrapolate an architect’s non-obvious antagonistic skill set, which the architect must master? Let’s dive into it!

The Monk and the Rockstar

A software architect, it’s a Monk? Or is it a Rockstart? Actually, it needs to be both. It needs to operate under a very different and antagonistic spectrum of skills and non-obvious activities.

The Monk and The Rockstar — 2 Personas in 1 Person

The Monk: The monk is the slow and solitary persona of a software architect. The monk is slow, reflexive, and thinks deeply about things, you need to be a monk to do:

• Software Design
• Tradeoffs
• Deep Research (I’m not talking about LLM Reasonbing, but Deep Work book).
• Make complex and important decisions.

The Rockstar: The Rockstar has a lot of charisma, can drive people, can influence and flock engineering to go in a specific direction, solution, framework, or even avoid some direction, i.e., clean code. The Rockstar is the opposite of the Monk; he is dynamic, fast, and collaborative. It’s a salesman, and such a persona is needed for the following:

• Requirements Extraction: Requirements are decisions, but nowadays, most decisions are made via UX in a Figma board; a good rockstar needs to translate that into frontend and backend decisions, but before it must extract needs from UI mockups. Rockstar simplifies requirements, challenges decisions, does pushbacks and proposes better solutions.
• Tech Leadership: The Rockstar needs to influence, teach, and lead developers; to do that, it must be a salesman who can have good arguments but make momentum a tool to deliver constant value. In order to do so, it needs to sell, communicate, and drive teams and people.

How to Get Started

You can start with any persona but must develop both skillsets. Some people are monks, and others are rock stars. Some are good with code, and others are good with relationships. Here is some guidance for each persona to get started.

The Monk

• Make multiple Drawings: Instead of one solution, draw 6–8 solutions and compare the pros and cons. Drawing is cheaper than coding and even implementing it.
• Make Wiki pages: Create a simple wiki page with a simple overall diagram and steps explaining what the code does. Do a second diagram on how it could be and list the new steps. This is simple but enables thinking and better comunication.
• Do multiple POCs: Instead of one person, do three to five and play with different options and flavors. This exploration will help you consider the pros and cons of different approaches.

In order to enable the monk you need solitude, make book 2–3 hours in your agenda where you will not goto meetings and you will have time to think? Another option is to do this before/after work in your alone/study time.

How to Get Better

Now, going over more advanced concepts of how we can further grow the two personas, here are some more advanced ideas to play with:

The Monk

• Read the Source Code: Go read Linux kernel code, go read Java JDK code, and Go read NodeJs source code. Go Read React code; when you read hardcode codebases, you learn a lot.
• Hardcore Debugging: Don’t stop reading code; debug hardcore components like the JVM, Chrome source code, React source code, etc.
• Seek for Arguments: Read advanced forums to see what the arguments are, and ask people’s opinions to learn from their arguments and ways of thinking. I bet you a beer you dont take 1% out of your workmates; go extract knowledge from them.

The Rockstar

• Go look at Figma. The more you look at Figma, the more you talk to UX and the business, and the more you learn about needs. Don’t take needs as “AS-IS.” Remember the five whys; needs are often hidden, and you need to extract them. Nobody will tell you the requirements nowadays, so you need to learn how to extract them.
• Do Pitch parties: Try to sell ideas or proposals to your workmates. This could even be an internal event. This helps to improve your selling and influencing skills.
• Socialize: Ask for others’ opinions. Seeking views does not mean you must do everything people tell you, but knowing perspectives always adds value. Socialize designs and PRs and ask for feedback.

People often think they can only learn to be architects by being architects with proper titles, but that’s not true; you can learn even without the title. Any engineer can develop such skills. Lack of experience can always be supplemented with study, and when you have experience and study, you become solid and seasoned.

IF you like what you read here, pls give it a shot to my last book, Continuous Modernization, which covers the mindset, practices, and shift to better work data with teams dealing with feedback and other soft skills in complex, distributed systems at scale.

Originally published at https://diego-pacheco.blogspot.com on February 26, 2025.