To be an architect, you’ll have to be a leader. And, to be a leader, you’ll have to be able to understand people and create an influence on them. So, focusing on the people involved with a system is a pre-requisite for designing systems that delight them.

Photo credits to Alan O’Rourke

For this topic, I want you to read and internalize the ideas from the book How to Win Friends and Influence People by Dale Carnegie. Honestly, it’s a fun read for anyone, not just for the aspiring architect. But an architect must be able to listen with empathy and clearly share her ideas. She needs to truly appreciate diverse opinion because it’s common that a delightful system can be designed in many ways, and she’s likely to have her blind spots. Moreover, she needs exceptional conflict-resolution skills to create a safe space so the best ideas win irrespective of where it comes from.

I know some of you may be getting impatient because you want to learn hardcore software architecture and I’m not talking anything technical yet. If you can hold your patience and bear with me, we’ll get there soon enough. I have what I think an exciting curriculum where I’ll be teaching hardcore software design topics using many well-known open-source products. My goal is to set you up for success as an architect, and these softcore topics are of the highest priority in my curriculum. The small number of great architects I’ve enjoyed working with have won me over by their people skills. All the other architects may have been technically genius, but lacked people skills to appreciate the essence of a delightful system, let alone designing one.

“I want to be an architect” - is a common career goal I hear during one:one meetings and annual reviews with my team members. Honestly, I’m writing this series of blog posts to bring some clarity and structure into my own thoughts, and hopefully to scale my time. You can even say, I’m open-sourcing my mentorship on the topic of software archtecture. My sincere hope is, this series helps my team or anyone who wants to systematically learn and improve their software design skills.

My mental model of a software architect as a system is as follows:

                 _________
                |         |
Requirements -> |         |
                |         |
 Environment -> |Architect| -> "Delightful" System Design
                |         |
      People -> |         |
                |_________|

That is, they produce the most delightful system design as the output from three inputs: business requirements, the environment that surrounds the system, and the people that are involved with the system. The main phrase to remember is “the most delightful” - because this is what makes the architect’s job so much fun and appealing.

First, I recommend reading the book The Design of Everyday Things to learn how design impacts us everyday. It’s a fun and must read for anyone involved in any kind of design.

Next, I recommend reading the book Don’t Make Me Think to learn about how to know if your design is delightful.

I prefer the word delightfulness over usability or customer obsession because the former sets a high bar. I hope you also internalize the goal of designing the most delightful systems and settle for nothing less, why should you?

This card is a parting gift from my beloved team. (Catherine, I know you made it)

This post is dedicated to my team at Cisco. I put a lot of my passion and care into building and being part of a great team during my time at Cisco, eight amazing years between 2012 to 2020. It was the privilege of a lifetime to be able to learn from and mentor an amazing group of people while building a product together.

Our memories work in a fascinating way. At Cisco, I put most of my working hours on actual work such as understanding and sharing project scope, designing and building solutions, responding to customer support requests, interviewing, presenting, etc. But just after four months, now that I think about my time at Cisco, none of the actual work takes the centre stage in my memory. Instead, the memory is filled with incredible life stories I heard during the short walks I took at the park for one:one meetings, or relaxed and often-long Friday lunches, or giving someone a safe space when they felt vulnerable. It’s a reminder that when it’s all done and dusted - what remains is the people and relationships we build with them. I’m so glad to get this card in the mail after I left and I’ll forever remember this kind gesture.

What better can a man wish for than being “unfrogettable”?

Good design is obvious. Great design is transparent. — Joe Sparano

Ruby on Rails delighted me all through my career. The community is one with a taste for art, thanks to DHH’s ability to write well. He set a high bar and the community also lives up to it. One API that absolutely blows my mind is how delightful it is to work with date and time in Ruby on Rails. Here are a few example use cases:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# Schedule a report to run at the beginning of next week
report.run_at = 1.week.from_now.beginning_of_week

#.. or first Friday of next month
report.run_at = report.run_at.next_occurring(:friday) unless report.run_at.friday?

#.. or beginning of next month
report.run_at = 1.month.from_now.beginning_of_month

#.. or mid-day tomorrow
report.run_at = 1.day.from_now.at_midday

# Is today a weekday?
Time.now.on_weekday?

#.. or a weekend?
Time.now.on_weekend?

# Book a calendar event for a whole day
time_off.duration = Time.now.all_day

#.. or find sales in the current quarter
Sale.where(created_at: Time.now.all_quarter)...

A lot of time related code I’ve seen in real projects is finding a point in time relative to now. Ruby on Rails makes it an absolute joy traveling time by adding time related methods straight into the Integer class, where the code looks just like how we think about time. Sure, Rails uses complex classes such as TimeWithZone, Duration, etc. under the hood, but I’ve almost never seen those used directly. This is such a stark contrast with many other platforms where you have to use pedantic concepts such as TimeSpan, Calendar, GregorianCalendar, etc. The true elegance of time travel API in Ruby on Rails lies in how invisible it is.

Image source: Show and tell - explaining the rain game

I started my developer career 15 years ago at the onset of agile and Scrum. From my early career, I worked on short sprints where we demoed our work to collect feedback towards the end of each sprint. So, after thousands of demos, I’ve seen enough great ones that I developed a taste for it. I can no longer go back to soulless demos. This post is about a few observations I have about great demos.

Presenters of great demos always tell a story. The presenter herself had a lot of fun and she has to share her excitement with everyone. It’s contagious, we can’t help but listen. She shows what her team had done and why it matters. She fondly shares what was fun and what was a pain the butt. Her passion drives us to pay attention and take part actively.

Great demos have a memorable punchline. The presenter lays out the demo in a way that neatly converges to her punchline we can’t forget.

Great demos allow everyone to immerse into the demo. The presenter takes a pause so the audience can focus on the work of art, and shares her narrative when the audience can truly focus on listening.

Great demos are inclusive. The presenter remains humble, acknowledges her team’s effort, and curiously seeks feedback from everyone.

Great demos feel short.

Now, treat yourself with this captivating storytelling of Nick Means even if you don’t have 40 minutes of free time. You’ll thank me. I know sprint demos are only 5-10 mins, but you can still put your soul into it. We’ll surely care.

When talking to people, I’m always interested to know how they learn. This image above shows a view of how I personally learn. Here’s some context about the items on the diagram:

1. Online-courses: I love O’Reilly learning. Their video courses are split into 5 minute lectures. For example, I took their Kotlin course to learn the language.
2. Books: Books are great for curated content, but it takes dedicated time. Most of the time, I have one book that I read. Current interest is on leadership and business.
3. Hands-on: A lot of people learn by doing. I do the same, but mostly at a hello world level instead of going too deep into new things.
4. Podcasts: This is my most passive form of learning, mostly when I’m walking or driving.
5. People: I keep in touch with people and ask them about what they are learning.
6. Twitter: I admit, I spend too much time on Twitter. But occasionally, people share interesting things.
7. YouTube videos: I watch conference talks such as InfoQ, DotNet, Rails, Ruby, Goto, and AWS.
8. News: I follow Hacker News mostly for tech and business news. And then there’s following stock market news about new business innovations.
9. Interviews: I watch inteview shows on YouTube as I’m a big fan of biographical content.
10. Open-source: I follow a bunch of open-source projects or just read code from time to time to learn about how the passionate and expert developers craft code.

Photo credits to GotCredit

Here’s a personal story about getting a feedback. For context, English is my second language. I grew up speaking Bangla as my primary language. I learned reading and writing English in school - grammar first. I had only started speaking English much later in my life, in my mid-twenties. So, I often struggle with the informal form of the language. With this context, here’s an excerpt of a one:one chat conversation at work (from memory):

Catherine: Sohan, I have a question when you have time.
Me: Shoot me.
Catherine: Haha. It’s not “shoot me”. I think you mean just “shoot”. When you say “shoot me” it means…

In this case, Catherine genuinely cared and had the courage to share this feedback about my improper use of English. I love getting such direct and timely feedback.

Here, I’m sharing links to some content that I found to be high quality resources to learn about feedback. Hope you’ll enjoy.

1. Radical Candor Talk - The Surprising Secret to Being a Good Boss
2. Podcast: How to Get Feedback From Your Boss
3. Podcast: Take Feedback Like A Boss
4. Podcast: How to Give Feedback To Your Boss
5. Book chapter: Max up Candor: A Circle of Feedback

This summer I was interviewing for a new job. This was the first time I was interviewing for an engineering manager role. Soon I realized these interviews were wildly different from interviews for developer roles. During typical developer interviews, I solved coding and system design problems and discussed personal aspirations in behavioral interviews. In contrast, leadership interview qeustions were really open-ended. Honestly, I found it very hard to answer these questions concisely. Often I could form a crisp answer to these questions only after the interview had finished :-( Here are some example questions:

1. What is your management philosophy?
2. Tell me when you had to deal with uncertainty.
3. Tell me about when you had to motivate a team even though you personally disagreed with the project.
4. Tell me when you innovated as a manager.

I did poorly in my first few interviews because how unprepared I was to answer these questions. I got truly frustrated. So, I started looking at YouTube to see how today’s inspiring leaders answer these questions. Here’s a list of YouTube channels that I found to be very resourceful.

1. David Rubnstein Show: 25 minute very high quality interviews with present and former leaders in business and technology.
2. View From the Top - Stanford: Hour long interview sessions with renowned leaders.
3. Technology Enabled Blitzscaling: Hour long interview sessions focusing on technology and startup leadership.

Watching these videos I developed some strategies for concisely answering leadership related questions with authenticity. I’d so love to do a formal research and write up on this topic some time. But for now, here’s the raw data for your enjoyment.

Go ahead and watch!

Photo credits: Bradley Griffin

The conductor of an orchestra doesn’t make a sound. He depends for his power on his ability to make others powerful. My job was to awaken possibility in other people. And you know how you find out? You look at their eyes. If their eyes are shining you know you’re doing it. - Benjamin Zander

Recently, I’ve talked to a few companies as I was going through a job search process after a long time. One of my interviewers asked me this question: “What’s the difference between managing one team vs. multiple teams?”

I’ve been leading multiple teams for a few years. But, I realized I didn’t have a crisp answer to this question. Now with the benefit of time to think about it, here’s how I see the difference.

My mental model to answer this question is best described around the concept of a team’s mission - the reason for a team to exist in the first place.

A line manager builds and inspires her team to deliver the team’s mission. A great manager understands and fully commits to the team’s mission herself. She inspires individuals on the team’s mission so that the team creates more impact than the sum of individuals. She also works with her peer line managers on a larger mission.

A manager of multiple teams designs empowered teams to deliver a larger mission. She hires and leads line managers such that each team takes ownership of a part of the larger mission. Additionally, she creates a team of line managers to foster cross-team innovation.

There are other ways the two jobs differ, such as, one:one with only direct reports vs. skip levels, being strategic vs. tactical, growing leaders vs. individuals, etc. But the main difference is running a team vs. designing teams on more specific missions.

If you organically grew into a manager of multiple teams, you may want to think about how your job is different than before. Even if you aren’t looking for a new job, this exercise will get you clarity about your current job.

Photo credits to UnknownNet Photography

I’ve been in search of a new job for the past few months. Thanks to my recruiters and interviewers, I’ve received some useful feedback. Many thanks to them for this gift.

“Needs more energy” - This was the most memorable feedback I got. It was from the VP of a company. My interview with him was the last of the five on the same day. My day went well until then. But I was also drained from 4 hours of back to back video interviews on the same day before meeting him. Honestly, when I received this feedback, I felt heartbroken and defensive. It took me some time to digest it and take actions based on this feedback. But eventually I developed some communication hacks to remain energetic. I’m now mindful about staying energetic, often taking body breaks and keeping a water bottle or coffee on my desk. I am taking handwritten notes while listening on video calls. Also, when I’m on video for hours, I proactively tell people about being camera fatigued.

Another feedback I received was, “some answers could be more direct and crisp”. With remote communication, sometimes I find it hard to read audience reaction. Based on this feedback, I’ve adopted a communication hack where I do a short and direct answer first and then ask if I should elaborate further.

I was somewhat surprised with one feedback from a system design interview. The feedback was “needs to discuss design trade-offs”. After some time had passed, I realized what happened there. While I mentioned some design trade-offs, I didn’t put a lot of emphasis on discussing design trade-offs. Moreover, apart from designing the system, I did’t ask about any secondary design topics that were of interest to the interviewer. I’m now more mindful about eliciting these secondary goals.

When I interviewed for an individual contributor (IC) role at a company I deeply admire, the feedback I got was “needs to clearly know if he wants to be an IC or a manager”. This was bang on. I was attracted to the company a lot but they only had IC roles open at that time. I consider myself a capable enough engineer and technical contributor still. But during that interview, I fumbled to honestly answer how my career aspirations at this time would be fulfilled by going from management into an IC role. Thinking about this feedback gave me the clarity that I indeed want to remain a people leader at this stage in my career.

A few interviewers asked me to talk about my management philosophy. Even the very best leaders differ in their philosophy. So, after I answered this question, I asked one of my interviewers immediately if he had any feedback about my philosophy. He shared this: “Thanks for your answer. Creating accountability is a big part of my leadership philosophy…”. This is one feedback where I decided not to take any action. I like what he said and I value accountability. But my leadership philosophy is what I truly and strongly believe in, and at present, I find accountability to be a by-product instead of a key philosophy.

There were many positive feedback shared as well. I find that positive feedback has the same effect as that of a good massage; it feels nice to receive one from time to time, but the feeling tappers down soon after. On the other hand an actionable feedback where I can improve is a gift that keeps giving. Whenever an interviewer gave me the opportunity to ask questions, I always asked if they had any feedback for me. Most didn’t share any actionable feedback citing company policy as a reason. But the ones that did, I’ll be forever grateful to them.

When I interview candidates as an interviewer, I ask them to share feedback about the interview. I have deep respect for candidates who are brave enough to suggest specific changes. If they get hired, they become value multiplier employees. However, as an interviewee, I didn’t have a single interviewer who asked me to provide feedback :-( I’m sure company policies don’t limit it.

So, when you get a chance, share some feedback. It’s a gift. Give generously. Also, seek feedback and appreciate when you get it. If you have feedback about this post or any, I’m @smsohan on Twitter.