Jigyasa Mathur

Hello! What's your background and what do you do?

I am a Computer Science graduate. I started as a Software Engineer ten years ago. Focussed on writing code and learning the ins and outs of Software craftsmanship for four years, rising through the ranks and then pivoted to co-founding two startups in the CTO role. After working on my startups for the next four years, I joined the workforce back as a Senior full stack developer again. Soon after, I got promoted to Lead positions until I finally made my way to being an Engineering Manager leading cross functional teams.

In my current role, I help engineering teams deliver software. I ensure that my teams can focus on delivery by supporting them with aspects of software development that are not inherently related to coding - liaising with Product Managers, interfacing with stakeholders, ironing out interpersonal issues, removing roadblocks, professional and personal development and mentorship of engineers.

How was your transition from software development to management like?

My first transition was a bit unusual and abrupt since I went from being a Senior software Engineer to assuming multi-faceted responsibilities of a CTO of a tiny startup. Although being a small team meant I didn't have the usual management responsibilities yet (eg: people management, cross team interfacing etc). Instead, I had to learn a lot of other skills like product management, business development, business communication, public speaking, networking etc. However, most importantly it taught me how to truly do pragmatic software development. It taught me to ultimately be obsessively driven for building for the end-user, since the fate of my startups depended on it on a day to day basis and I internalized it for good.

Eventually, when I returned to day jobs and had a team of eight to lead in a conventional large company setup, it took me a while to come to terms with the organized framework of management. I had always depended on the quality of my code and architecture skills as a software engineer do my bidding, and I felt vulnerable and uneasy in a role that put me in a room full of engineers with no direct contribution to the software to show for. I struggled to find the right balance with time I spent actively coding and soon it felt like the people I was leading were farther down the curve with their core engineering skills and I was lagging behind. It took me a few months to settle into my new role as I exploited everything I had internalized as a struggling entrepreneur into my style of management and mentorship. It shaped my outlook towards software development on the whole and I found a great niche as a great liaison between engineers and stakeholders, having personally spent time on both sides of the table in my career. It took almost a year to start feeling fulfilled by it as I learned the ins and out of effective engineering management and the endless opportunities to hone what turned to be a craft in itself.

What does your day-to-day work look like, and what motivates you to do it every day?

My day to day work comprises of mentoring, coaching, troubleshooting, fire-fighting, anticipating bottlenecks and getting a head-start on product and engineering collaboration. My work is all about people, understanding the various kinds of personalities and motivations at play, tailoring my management style to each one yet balancing the dynamics of the team and helping them stay focussed on what they do best.

The effectiveness of my team motivates me. Getting great output from a motivated and well coordinated team of engineers for our stakeholders is something that drives me. Addressing communication gaps and de-escalating challenging situations make me feel like I am learning and getting better at my job. Mentoring engineers to be more product driven and pragmatic makes me happy to share some of my own learnings.

What are the biggest challenges you've faced so far? What did you do to overcome them?

The biggest challenge has always been the lack of tangible output from my personal contribution to feel fulfilled. As an engineer, I always found joy and fulfilment in the delivery of products, all the while trying to follow impeccable software practices, writing great code and seeing your work go live. I always relished the feeling of ideating something and building it out from scratch and then see users interact with it and give me feedback. At heart I am a builder and Engineering management is a "behind the scenes" job wherein satisfaction is to be derived from enabling other engineers to be successful at delivering products. It is a constant challenge to find it rewarding enough.

What has been the biggest surprise so far? Something you didn't expect?

Management changes your perspective. It feels like breaking out of the individual contributor mindset and getting an up close and personal view of how and where software development fits in the framework of a running business. To me technology has always been an enabler towards a rewarding end product, rather than the reward itself and that gets reinforced everyday as you move up the ranks of management. The great news is how the objectivity and pragmatism can stay with you in other aspects of your life as well.

What's the best advice you've received about being a manager?

One of the things to learn during transition to engineering management is to try and curb the instinct to try and solve a problem yourself if you know better. Instead to focus on trying to enable your engineers to solve it.

What do you tell developers who are considering making the switch or new to the role?

For those considering the switch, I tell them to really focus on what drives them today and what they imagine will drive them ten years down the line when it comes to software development. If for example, the business or product aspect of software development is something that bothers you as an impediment today, there is a slim chance you may learn to love it in your path to engineering management while you move away from active code. If the pure rush of writing code and the beauty of tech architecture are something you hold sacrosanct then the management path may not be a great natural fit. If the prospects of interacting with a lot of people on a daily basis, being able to take risks, leading initiatives and invariably putting yourself in confrontational situations every now and then doesn’t go well with your persona, it may be an uncomfortable path to go down.

However, If you feel even somewhat keen on learning how software empowers a business and you want to learn more and contribute, you may be someone who would enjoy moving towards engineering management. If you feel like you could get involved and offer more to the stakeholders with your software experience, this might be great way to go. If you are good with people, this would be a great path as well.

Management is not for everyone and that’s completely alright. Tons of engineers choose to go down the technical leadership path and afford the same growth. I advice every EM to be to think long and hard about making the switch and the motivation behind it. Always start small - a team lead, tech lead, chapter lead. Get a sense of what being a manager entails before switching gears completely.

I think there is plenty of help available if you really have the right motivations. But with engineering management, the biggest blunders I've seen are the people who shouldn't have been or never really wanted to be EMs. Don’t do it just for the growth.

Advice for the new EMs - Be patient. It gets much easier and clearer. And there is way more to learn than you imagine when you begin.

Final call to action! Where can we go to learn more about you?

Reach out to me on Twitter (https://twitter.com/killedthecat) or LinkedIn (https://www.linkedin.com/in/jigyasamakkar/)