Leaders are made, not born. It's also true for software Engineering Leaders across the world. This is what we believe we are depicting through our Q&As with some great Engineering Managers, Directors, VPs and CTOs: Sergio, Swarup, Vevek, Will, Glenn, and many more!

Their diverse professional journeys & personal backgrounds point to the importance of self-reflection and perseverance.

Of course, each Engineering Leader has its own interpretation of what key factors can help you become a good manager. But most of them will share how empathy is important, and how it can inspire your team(s) of software engineers.

In today’s interview, we’re particularly happy to share with you our conversation with Prashant Lodaya, currently Engineering Manger at Cuelogic. Enjoy!

Could you tell us a bit about yourself and your professional journey?

I have been working as an Engineering Manager at Cuelogic for about 2 years now. I am fortunate for being trusted with leading several engineering teams in building niche and complex products for customers ranging from startups to large enterprises.

My innate introvert behavior empowers me with critical thinking and enables me and my team towards making correct decisions. At the same time, I also strongly believe in failing fast and improving continuously to achieve success.

I have around 15 years of IT experience in varied domains, roles, geographies and technologies. The lessons I have learnt along the way while collaborating effectively with peers, managers and reportees have become the building blocks of my leadership abilities. Nevertheless, I am always honing my skills!

What made you decide to become an Engineering Manager?

I learnt very early in my career that the whole point of getting things done is knowing what to leave undone. Moreover, when we do what we choose to do, we are committed.

When we do what we have to do, we are compliant, hence being an Engineering Manager has been an organic decision!

What is the role of an Engineering Manager?

An Engineering Manager is responsible to make sure that the below items are taken care of:

  • Concept of MVP does not belittle scalability and other non functional requirements
  • A product is being built around problem and not around features
  • Inversion of Control - find problems and take them to the user instead of waiting for them to come to you
  • Experience of engineers is superlative in terms of
  • Ease of initial collaboration with team
  • Continuous learning and training
  • Stable infrastructure especially in current circumstances
  • Clarity of product/platform and role/responsibilities of engineers

Eventually, the absolute Nirvana for a great Engineering Manager is when the team does not need him/her to organize them or help them make decisions.

What advice(s) would you give to a software engineer considering to become an Engineering Manager?

  • Excellence is not about achieving great heights once and dwelling on it, but it is in perseverance
  • Value your opinions strongly and portray them softly during conversations
  • Respect opinions of others and gracefully disagree (if you need to) to demonstrate your stance
  • Do not avoid conflicts (avoiding conflict shows you are timid and allows others to undervalue you)
  • Do not undermine people during their absence in conversations (to avoid the same during your absence)
  • Avoid getting stressed over opinions of others (that will undermine your core strength)
  • Lighten the conversation with funny anecdotes but never make yourself a laughing stock in such conversations

What is the hardest lesson you have learned as an engineering manager?

Success is not long lasting. You need to prove yourself constantly.

However, there is no need to opine on everything or every proposal that you hear; opinions do not lead you towards success. As mentioned in the book "What got you here, won't get you there", you can always say "Thank you" when you hear an idea and not indulge into sharing your opinion or adding value by sharing your past experience.

You are not the only or the most intelligent person around. You need to grow and that is possible by listening to others and appreciating them and sharing your thoughts if asked for. You will lose your value if you constantly try adding value. Try not to add value and you will create value for yourself!

What are your best practices to ensure your engineers and leaders keep continuously learning and self-improving?

Commitment is the key in most cases. Leaders can rely on the below questionnaire to determine if their teams are committed enough; albeit this is not a silver bullet.

  1. Do you stretch beyond normal working hours even when no one has asked you to?
  2. Do you strive to improve processes even when the processes are working just fine?
  3. Do you take initiatives in inspiring your team to innovate mundane tasks?
  4. Do you rely on and trust your team to take ownership of delivery during your absence?
  5. Do you let your direct reports figure out minute details instead of asking them to do things?
  6. Do you feel the need to appreciate your direct reports for their efforts?
  7. Do you feel satisfied at the end of a long tiring day?
  8. Do you spend most of the time actually doing work instead of thinking how to act given a situation?
  9. Do you feel the need to help others even when not asked to?
  10. Do you feel the need to keep going even when not appreciated?

If one can influence and manage to get their teams to answer most of the above questions as “Yes”, one can be certain to have built self organized and self improving team!

Would you encourage teams to include tech debt in their backlogs and make it visible to POs, etc.?

Technical debt is either:
(a) incurred intentionally to avoid over-engineering,
(b) to realize value of commitment to the market in time, or
(c) is incurred unintentionally due to a lack of knowledge of the original system design while applying enhancements.

Hence adding technical debt items in the backlog is an important step towards creating business value by bridging the gap between product and engineering teams.

This is necessary to not only eliminate the stigma of shying away from highlighting issues in the system, but also to empower teams to organically work towards continuous improvement through introspection and retrospection.

What metrics have you found most useful for teams to measure their performance?

They say “what gets measured gets managed”, but it is far from being the golden truth as organizations and teams could easily fudge the data just to meet the metrics.

Enforcing metrics may be a scientific way to prove a point but it is not always effective. At the core of performance lies the deeply emotional attributes of being engaged, creative and accountable.

A more scientific and tangible perspective of looking at these attributes is to follow this simple process:

  1. Create correct cross-functional teams (leading to more engagement)
  2. Get out of the way :) and let the teams do their magic (make teams accountable)
  3. Evaluate performance based on the impact created (enable teams to be creative)
  4. Impact could be both positive and negative
  5. Impact could be created at several phases - discovery, design, solution
  6. Facilitate continuous training and coaching
  7. Facilitate consulting through a specialized task force for specific problems
  8. Anticipate failure and enforce quick “Inspect and Adapt” cycles to pivot towards better decision making

About our Q&As with Engineering Leaders
We are lucky to have a vibrant and dynamic community and it would be a shame not to share these experiences and insights with the growing world of Software Engineers and Engineering leaders! Every two weeks we will be sharing a personal interview with some great Engineering Managers, Directors, VPs, and CTOs.

If you’re looking to join our weekly intimate roundtables, or if you’re interested in sharing your perspective on the topics we’re covering, click here. See you soon!