Sohan's Blog

Things I'm Learning

“You’re Unfrogettable”

card

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”?

A Tribute to Time Travel APIs in Ruby on Rails

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.

Tips for Great Developer Demos

Show and Tell

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.

Where to Learn: 10 Ways I Do

learning

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.

Learn to Get and Give Feedback

Feedback

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

My YouTube Playlist for Leadership

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!

Difference Between Managing One Team vs. Many

Orchestra

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.

Communication Hacks I Learned From Job Interview Feedback

Gift

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.

Context

Misfit

Image credits to NCinDC

Context is everything. Due to a context mismatch projects such as exporting democracy, agile transformations, building startups, losing weight, mindfulness or anything you can think of fail to repeat.

Context is formed by why / what / who / when / where / how, each of these being a critcial part. Most often it’s common to focus on the how alone - forgetting the rest of the context while adopting a recipe for success in business. Some get overly influenced by speakers and focus on only a subset of the context. Reality is, it’s almost impossible to find an excact duplicate of any one context. So, while copying solutions from one context, we must adapt to account for the uniqueness of our own context.

A lot of innovation lies in the context gap - where one can find clever ways to adapt solutions from one context into another. I’ll give you one such example, did you know Uber runs a motorcycle based rideshare in many countries?

Change

Manager’s Mind

As managers, we have the benefit of view because we have our eyes on longer term goals. To achieve those goals, we often have to introduce a change. For example, we may want to change how a team is formed or what product a team works on based on new business needs or opportunities. So, we put a lot of thought into it and propose our plan to the team hoping the following reaction:

1
$(team).on("change", excitement)

Before proposing such a change, we’ve analyzed various options, including the option of keeping everything as-is. We’re fully convinced that indeed the change we’re going to propose is the best option. We are excited with this new way that’ll make our teams more productive. As caring managers, we are thrilled because we believe this will make the team happier.

Team’s Mind

However, most of the team’s reaction is as follows:

1
$(team).on("change", panic)

Honestly, the team has a great chemistry going on, they have fun and work well together, they are already so productive shipping products using technology they use today. So, at best a change seems random, but more commonly perceived as a mindless act of “management BS”.

The Deadlock

At this stage, both the manager and the team are in a deadlock, each party fairly confident in their judgement, failing to appreciate the concerns of the other. At this point, it’s the manager’s job to not only break the deadlock but also to make sure s/he carefully listens to the team and motivates them. Ideally, we can data-drive these conversations while being mindful of individual emotions.

The Checklist

Here’s a checklist I’m following myself as a manager as I’m trying to orient my teams from technology driven teams to more full-stack product mission oriented teams:

  1. Motivate the team with a why. e.g. Go from tech-oriented teams to product mission teams so that all of you can deliver products to customers…
  2. Listen to the team. Multiple one on one sessions if needed. e.g. Let’s discuss about your concerns regarding tech debt with this change…
  3. Discuss changes to your plan based on the team’s feedback. e.g. You’ll have full ownership of the technology to serve your mission…
  4. Layout your evidence. e.g. We built an improved search feature that we couldn’t ship to customers for months because the UI team was busy…
  5. Discuss pros and cons of alternatives you thought about. e.g. Another option is to keep as-is, but that’d mean we must improve cross-team project management to reduce hand-off related delays…
  6. Present your metrics to achieve. e.g. Time from dev to customer, performance metrics,…
  7. Present an iterative and incremental plan with the option to change course based on metrics. e.g. Let’s do this with one team for one month…