My MBA Story: The importance of lifelong learning and how it supports career growth in the tech industry

It's been over 8 years since I started working as a software engineer. Throughout my career, one thing that's become clear is how rapidly the Software Engineering field evolves. What was cutting-edge technology back then can become tech debt pretty quickly.

While most of the skills I use day-to-day were learned on the job (I don't code in C++ anymore), the foundational knowledge of computer science I gained at university has been instrumental in getting me where I am today.

I’ve realized I learn best through a structured curriculum—quick TikTok videos and YouTube Shorts just don’t cut it for me.

For technical learning, I've turned to platforms like Udemy and Coursera, which have helped me pick up new skills like gRPC and Kubernetes.

Over time, I’ve grown more interested in the business side of things. Understanding how a company operates helps me find more meaning in my role as an engineer. I've dived into annual reports and learned about accounting and operations through various online resources. This exploration made me realize I want to move into engineering management rather than staying on the Individual Contributor (IC) path.

While technical skills are key, leadership roles demand a different set of abilities—something I'm working on through my MBA in IT Management.

In this blog, I want to share my MBA journey and how it's complementing my professional experience, preparing me for engineering leadership roles.

Decision-Making

As an Engineering Tech Lead, responsibilities are often filled with ambiguities. You must align multiple stakeholders, manage conflicting expectations, and provide mentorship and guidance to junior members while also working full-time on technical deliverables. Navigating these complexities requires a balance between technical skills and business acumen, a balance I've been able to achieve through my MBA studies.

When I started my career, I was very attached to my work. My code was sacred. Not anymore.

One of the key lessons from my MBA is understanding that coding is merely a tool to solve larger business problems, not an end in itself. This shift in perspective has taught me that business priorities always take precedence. For example, while I would prefer to maintain a codebase free of tech debt, it is more important to deliver features that our customers need to avoid losing market share. This shift in perspective influences my daily decision-making, allowing me to prioritize tasks that align with business goals, even if it means compromising on technical perfection.

Such delicate insights are often missed when you're solely focused on your technical craft. Attending formal classroom courses and understanding the theory behind business decisions have made me more pragmatic in my decision-making process. My MBA has provided me with frameworks for risk assessment and stakeholder management, which are crucial when navigating these ambiguities.

Strategic Thinking

Strategic thinking is another area where my MBA program has significantly contributed to my growth. Courses in strategic management have given me tools to align engineering goals with broader business objectives. I’ve used this knowledge at Mercari to drive our long-term roadmap and ensure our engineering work supports our business vision.

For instance, by improving our hiring and onboarding processes, I’ve helped expand our team and increase offer acceptance rates, directly supporting our strategic goals. My decisions are now more aligned with our business strategy, benefiting both my team and the company.

Communication and Collaboration

Communication and collaboration are crucial for any leader, and my MBA program has been instrumental in honing these skills. The emphasis on teamwork and leadership courses has allowed me to become a more effective communicator. At Mercari, I've had the opportunity to mentor team members and engage in initiatives like Build@Mercari, fostering a supportive community and encouraging top talent. Additionally, my role has involved strengthening global team bonds through invaluable team-building activities, enhancing our collaboration efforts across borders.

Practical Applications

The integration of technical expertise with the skills I've gained from my MBA has profoundly impacted my approach to problem-solving and leadership. At Mercari, I've been able to lead with confidence, knowing that my decisions are backed by both practical experience and academic insights. This combination has not only enhanced my current role but has also prepared me for future engineering leadership positions. By continually adapting and growing, I am positioning myself for long-term success in leadership roles that require a balance of technical and strategic skills.

Innovation and Talent Development

My MBA has really highlighted the importance of innovation and talent development. Through courses in Human Resources and Organizational Behavior, I’ve learned how to create a culture of creativity within a team. This approach has helped us build a high-performing group at Mercari. I've been able to lead projects that not only focus on engineering excellence but also set us up for future growth. Plus, mentoring my team and improving our hiring processes have been key in bringing in and keeping top talent, making sure we stay competitive and ready for whatever comes next.

Future Benefits

Looking ahead, my MBA is setting the foundation for my career goals in engineering leadership. The skills and knowledge I'm acquiring are not just applicable to my current role but are vital for long-term success in senior leadership positions. My vision for the future is to continue leveraging these skills to drive innovation, lead successful teams, and contribute to organisation's growth and success. By embracing continuous learning and development, I am confident that I will be well-equipped to take on the challenges and opportunities that lie ahead.

Using multiple SSH keys for multiple GitHub accounts

Why do you need multiple SSH Keys?

So you just started setting up your new work laptop. You figured out that your company uses GitHub for hosting its source code. Great!. But you also contribute to open-source that is also hosted on GitHub. A lot of organisations recommend creating a new GitHub account to access the repos hosted by the company.

Now GitHub doesn't allow you to use two different private keys on the same laptop. By default, the Git config is stored in .gitconfig directory. Every time you try to clone a repo which is private, Git client on your laptop uses the configuration defined in this directory to authenticate and authorise with GitHub. For security purposes, you should always keep the private keys separate for work related code and anything that you contribute on the open-source side. 

This blog aims to help you setup multiple SSH keys for different GitHub accounts on a single laptop

Setting up multiple SSH Keys

ssh-keygen -t rsa -b 4096 -C "personalemail@gmail.com"

Save the file as sanusatyadarshi

ssh-keygen -t rsa -b 4096 -C "work-email@work.com"

Save the file as sanu-work

Add both the public keys to respective GitHub accounts

vi /Users/sanu/.ssh/config

Add the following lines:

# Personal account

Host github.com-sanusatyadarshi

    HostName github.com

    User git

    IdentityFile ~/.ssh/sanusatyadarshi

    IdentitiesOnly yes

    

 # Work account # This will be the default account

 Host github.com

    HostName github.com

    User git

    IdentityFile ~/.ssh/sanu-work

    IdentitiesOnly yes

vi ~/.gitconfig

Add the following lines

[user]

        name = Sanu Satyadarshi

        email = work-email@work.com

For personal Repos

Change the hostName from github.com to github.com-sanusatyadarshi(whatever your put in config file)

git clone git@github.com-sanusatyadarshi:sanusatyadarshi/xyz.git

cd into the repo and run the following command

git config --local -e

Add this  line

[user]

    name = sanusatyadarshi

    email = personalemail@gmail.com

 

Why the on-call?

Almost everyone who is a software engineer in a consumer product company goes for on-call.

At some companies, it's mandatory, at some it's voluntary. Also, some companies pay extra allowance for being on-call while some consider it part of the job.

Last month, I went on-call again after joining a new company. It has quite a comprehensive on-call onboarding process. I was shadowing primary members(the on-call person) for almost 4 weeks before graduating to a primary on-call.

I was nervous. Heck! I was scared. I work with the Platform team and the sheer number of components our team manages can be overwhelming. Although as part of my team onboarding, I went through all the documents and CodeLabs that help you get the feel of the system, nothing can prepare you for an actual on-call.

Luckily the first day was very uneventful. No alerts :). I mostly spent my time re-reading the playbooks that we have for common scenarios. 

On the second day, someone reached out to me about a query related to infrastructure provisioning. Honestly, I was clueless I had not worked on that component at my current company. The first thing that I did was search for similar queries in our Slack thread and GitHub issue. Incidentally, the same issue was faced by two engineers in the last 6 months. I spent close to 2 hours reading the past issue, PRs, and Slack threads to understand the issue in detail. 

What happened?

First, I learned about a completely new part of the system that I would have never interacted with in my daily tasks.

Second, I found out the points of contact and other resources to look for in case of such issues.

Third, it increased my confidence to explore and understand a completely new issue.

The "Good" on-call

A good on-call is where you work with the systems close enough to understand the weaknesses and areas of improvement in a system. Most of the organizations (at least the ones I have worked with) have many sub-teams within the Platform division. 

One of the major benefits of good on-call is the ability to touch cross-team systems. E.g. during an incident, a faulty HA Proxy config was causing requests to fail while reaching the Kubernetes cluster.

Usually, I care only about the traffic once it reaches the boundary of the cluster network. But I got on a call with the network team, raised a PR for the HA Proxy config, changed the Route53 entry, and updated the Istio Destination rule all within 1 hour. 

In another instance, the Kafka consumers were not able to reach the Kafka endpoint from selected pods. I spent almost 2 days working with the Data Platform team and not only fixed the issue but ended up learning so many other details about Kafka configurations, client optimization, etc.

The "Bad" on-call

This one is so obvious. 30 non-actionable alerts. People are asking you to join random calls all day. You are firefighting similar issues without fixing the underlying root cause. There is too much focus on "operational excellence" and not so much on engineering health. I have been part of bad on-call processes and by the end of the week, I was so frustrated that I used to take 1-2 days off just to calm down.

How to improve your company's on-call culture?

Pay them extra for being on-call!!! Waking up at 2 AM to respond to a PagerDuty alert is not fun. Not for me, not for anyone else. Recognising the fact that waking up at 2 AM is not "part of the job" and compensating the engineers is the first step in motivating your team to be on-call. 

The other way to improve on-call culture is to regularly filter out actionable and non-actionable alerts. When teams get started, they usually set alerts for everything. Most of it ends up becoming noise. Such alerts are called non-actionable as there is not much you can do to alleviate them. You can either reconfigure the threshold or just remove them. I mean who needs an alert if your service's request per second increases from 650k RPS to 700k RPS? Is your system not scalable enough? Maybe it's time to revisit the architecture. 

The third important way to improve the on-call culture is to allow other teams to be self-sufficient. This is more relevant to Platform teams where every service is dependent on the underlying Platform. Having playbooks for most common use cases allows product teams to self-serve the majority of the issues without involving multiple teams.

Disclaimer: All the views/opinions on this blog are personal and do not represent those of my employer(s), past or present.