mishnit.github.io

My Engineering Manager README

What is this?

This is inspired by Manager README, a document that helps introduce you to my management style, philosophy, and expectations. The intended audience is primarily anyone who reports in to me, though anyone is free to read it — or even provide feedback on it! This is a living, incomplete (we never stop growing) and concise document. So, Let’s get to know me.

Note: ‘You’ in this document is my direct/indirect reportee.

TL;DR:

My name is Nitin Mishra. I am currently working as Engineering Manager in phonepe. I am leading a group of talented people to build great product end to end using effective processes (3Ps). One of my top priorities is to ensure you stay motivated and stay challenged. My goal is to work with you to find the right amount of stretch so you don’t get bored and you don’t get too stressed. You would have freedom and responsibilty at the same time. I would keep Transparency, Effective Communication and expectations setting back and forth at the highest priority. I love to code in python and Golang :)

My Background

Hi! My name is Nitin Mishra. I am a technology enthusiast with business acumen, a wisdom seeker, influencer, author and TEDx speaker. I’m an engineer turned manager and have worked with a lot of early/late stage startups and MNCs for last 10 years. I have been leading a strong squad which built habit-forming, end to end tech products with great customer experience at scale. This gives me the unique experience of learning what works and what doesn’t at both ends of the scale spectrum. I have a passion for using technology to build products that solve real world problems. What I am most passionate though is managing engineers and building great high performing but empathetic teams. I spend most of my weekends learning new stuff on medium, reddit, dzone, github, slack, firstround, infoQ and highscalability.

My Leadership Style

Key points that define my Leadership style are as follows:

• I value people over everything else
• I value actions over words
• I value pragmatism over correctness
• I value realism over (extreme-)optimism
• I value autonomy over micro-management
• I value over-communication over under-communication
• I value problem solving skills over engineering skills
• I value working smarter over working harder
• I value being straight-up over being political
• I value giving info early over giving info at last-minute
• I value taking risks over not making mistakes
• I believe if you cannot measure something, you cannot improve it

My Working Style: C R A F T S M A N S H I P

C - Customer Issues need to be handled via on-call folks on the highest priority (P0 Adhoc)

R - Review System Health and Performance issues monthly to keep an eye on current system level bottlenecks and plan their fixes

A - Automate Everything Possible to save bandwidth and speedup releases i.e. linting, testcases, alerts

F - Frequent and smaller release cycles

T - Test plans, health check audits and alerts

S - Set why, what, how, priority and success criteria for each task before efforts estimation

M - Monitor, improve and scale system performance KPIs periodically

A - Allocate additional time for code reviews, architectural discussion and documentation

N - Negotiate scope with product manager but before that deep dive into problem and possible solutions with edge cases

S - Story owners to be created during sprint planning. Daily standup to unblock dependencies, descope and/or update dev/QA/stage/prod timelines

H - Hire top notch engineers, do 1:1 fortnightly, draft individual career roadmap, give feedback, track progress, reward and recognize

I - Incremental controlled rollout for each release with killswitch and fallback options, ensuring backward and forward compatibility

P - Plan 6 sprints per quarter in advance and get it reviewed. Breakdown story points for each sprint in 3 buckets product, tech optimizations and adhoc in 4:1:1 proportion. Breakdown multi sprint stories in 2-3 phase releases.

An EM should keep an eye on the following:

(a) Tech System Health Metrics - Latency/ Availability/Single point of failures

(b) Delivery - PRD/TRD review, Sprint planning, Standup notes, Delivery status, Retrospection

(c) Post production bugs and No. of dev-qa cycles

(d) code quality - code review practices

(e) code coverage - unit test cases quality

(f) support tickets volume, frequency and impact, on-call effort reduction

(g) team health (every 2 week 1:1 with teammates, hear more talk less)

(h) high performers and weak performers for every sprint

(i) Tech Mentorship - Teammates should learn and use some new skill in tech

(j) Hiring and attrition metrics

(k) Tech debts analysis

(l) Publish RCA for recent outages, sev-1 issues

TIP: Try to keep capitalizable efforts (planned product/tech releases) >= 70% at team level, while non-capitalizable efforts (optimizations, bug fixes, tech debt, Adhoc) and overhead (onboarding, KT, planning, 1:1, meetings) at team level <= 30%.

My Job

As an Engineering Manager, it is my job to:

1. Attract and Retain world-class talent (that’s you). This means doing a lot of interviews, talking to a lot of people.
2. Give engineers and managers a sense of purpose and direction. This means focusing on building high performance teams, helping you understand where you stand and how you can measurably grow in your career, building a deeply value focused engineering org.
3. Help with planning and delivering on goals. This means setting context on roadmaps and product direction so that you, always know why are you doing what you are doing and reporting back state of the world higher up the chain.
4. Develop and improve my own abilities as a leader.
5. Improve Processes and bring new strategies to deliver faster with no compromise in quality.

How I approach my job

Your success is ultimately my success, so I will go out of my way to try and make you successful without micro-managing. I believe that regardless of the complexity of the problem you are trying to tackle, you already have the answer in you, my role is to help you find it. I rely heavily on open questions, rather than jumping straight to advice, but if you explicitly ask for advice I am more than happy to provide it. If you need to chat, come grab me, anytime.

I follow this strategy: deep dive -> Set goal -> plan -> engineering -> measure

How I expect you to approach your job

1. Engineers: Our organisation has hired you because of your experience and skills, and I am not here to tell you how to do your job. I believe you are able to operate as a professional adult, and make smart decisions. This does not mean that I expect you to do everything on your own , I am here to provide you guidance and mentorship (either through me, or by finding the people you should be getting it from). When you need help, I expect you to not hesitate and ask for it. If you feel you made a mistake, own up to it, as will I.

2. Managers: Please routinely reach out to your team’s stakeholders, keep an ear to the ground about what they’re launching, and be proactive about responding to them when they reach out. Please continue to educate yourself on leadership: use the tech budget to go learn from of the best leaders in the industry. It goes without saying, but please have weekly 1:1s with your direct reports.

If I succeed at my job:

• You feel empowered as a leader to figure out what you need to do and how you think it should be done and then to get it done.
• You have enough context to understand your priority and focus over upcoming waves.
• You have built effective relationships with others in the company.
• You know where you stand in your career within and outside of our organisation and understand how to move up.
• You are motivated, focused, having fun, & not burning out
• If I fail at any of these — especially anything that puts retaining you at risk — you would be doing me a huge favor by letting me know as soon as possible. I want you to reflect back 10 years from now at your time spent at our organisation and consider it to be the best work you’ve ever done. If you’re still here then, I’ve done my job well.

My Role

I am a firm believer in People, Product, Profit, in that order. My role is empowerment. I want you to get out of bed excited coming to office. I also want to ensure the company is doing great because you are doing great and delivering great value. One of my top priorities is to ensure people stay motivated and stay challenged. My goal is to work with you to find the right amount of stretch so you don’t get bored and you don’t get too stressed. That said, with the help of others, I would like:

For Software Engineers

• to ensure you work on the right things
• to ensure you talk to the right people
• to ensure you feel it’s a safe and supportive workplace
• to ensure you upskill yourself

For Tech & QA Leads

• to ensure you get the coaching and mentorship you need to succeed in your role
• to ensure you lead instead of manage your team
• to ensure you have the autonomy to lead and drive your team
• to ensure you have enough information and context to prioritise tasks for your team
• to ensure you feel safe to be honest with me

For Product Managers

• to ensure you know how easy or difficult it is to perform a given task
• to ensure you always get our confidence level on our own estimation
• to ensure you get presented with alternative solutions we believe could achieve similar goals with less effort
• to ensure you are provided with enough technical guidance for your product roadmap

For the Rest of Leadership Team

• to ensure you gain the confidence that we would deliver
• to ensure you know why we do or don’t do certain things for you
• to ensure you understand how we work as an engineering group
• to ensure you are consulted before we begin a major piece of work that affects your team
• to ensure you know we work together as one team and not as individual functional groups

Effective Communication with Me

I am generally a well organised person. In order to communicate effectively with me, please:

• be straight-up and cut the bullshit
• be explicit rathar than assume I already have the knowledge of something
• grab me if it’s urgent, or requires back and forth
• call me if it’s urgent and I’m out of office/away/unavaialble
• Slack me if it’s short and don’t require back and forth
• email me if it’s long and don’t require back and forth
• being interrupted is part of my role, come talk to me even if I have headphones on
• be patient, and if you don’t hear back from me within a day, nudge me
• think about the outcome and actionable items before you schedule a meeting with me
• if it’s more personal or more private, let’s go grab a coffee or tea
• hard truth: your requests are important to you, but may not be as important compared to others

My Daily Weekly Monthly Checklist

Software Development Principles

As an engineering manager I strongly believed in putting people over process and changing process to accommodate our needs and goals. As an engineering manager I will stay out of the planning loop where possible while guiding tech leads, principals and managers distill what I believe are values that are important to me, which are:

1. Customer focus: Are we obsessed about customer needs and working towards the ‘wow’ in our organisation’s values?. Are we being empathetic towards our customers.?

2. Transparency: Are we clearly and transparently oversharing information within and across teams.?

3. Curiosity: Are we constantly learning? Are we finding ways to improve processes/people/products?

4. Bias for Action: Do we see opportunities where other’s see roadblocks? Are we actively biased for taking action? Are we open to calculated risk taking and not slowing down cycles?

5. Ownership: Are we acting as owners? Are we thinking long term enough and challenging ourselves to think big? Are we ensuring that we never say “That’s not my job”?

1-on-1’s

I’m big on 1-on-1’s. Mostly this time is about you. Yes, I am the reason why 1–1’s will now be weekly. My role will be to listen to you. I will also use this time for us to to work through your career goals and use it for feedback on my own performance as a manager. While skeptical of some parts, I have adopted a version of Radical Candor (HHIPP) for feedback. I’ve been guilty of being over empathetic in the past while missing the point of giving feedback, but I’ve pivoted that to caring personally but challenging directly when I see an opportunity for improvement. While I understand it may be hard for everyone to be on board with this, I expect the same from my team and my managers.

Skill and Will checks

I would be doing a regular checks on skill-will matrix for you and based on that would be empowering you in an appropriate manner.

Trust Bank

I will always fill up the trust bank to the fullest and work backwards. What that means is that I will place my trust in you blindly, but if you repeatedly make the same mistakes again and again after being given feedback then you will slowly drain that trust bank.

The “No Surprises” Rule

Finally, there should be no surprises in the up direction (to your leader), down direction (to your team) and sideway direction (to your peers). Please:

• if there are issues, surface them as quickly as possible.
• if you suspect something might become an issue, do some analysis and surface them as quickly as possible.
• if you are told about something vague, ask for more information then do some analysis and surface them as quickly as possible.

Receiving and Providing Feedback

Feedback should be provided and received as soon as possible. Instead of waiting for our next 1:1, or the next internal survey, or the next watercooler conversation, grab me and let’s talk it out.

Every person is different, and therefore every project and every team are different. There is always room for improvement, for everyone. So, if you have any feedback for me, please come talk to me, I promise I won’t bite! These meetings can go by the Chatham House Rule ;)

Personality Quirks

Here are some things that I am both aware of, and that may or may not impact how you work with me:

• Based on personality tests I classify as ENFP.
• I have strong opinions on product and UX but I know my boundaries.
• I love data and I will trust you but will always try and go on to verify the data, do not take this personally.
• I don’t take life too seriously and very open to feedback regardless of how critical.

Hope this helps you to understand my role, my philosophies and helps us work together to build rewarding careers for both you and me while building a solid international technology product and brand.

Known Failure modes

I am not perfect. I’ve learnt more from failures than I have from success, so I believe while I will have all the right intentions, these are some of the things I am guilty of having done before that I would personally liked to be called out on.

1. Exploring too deeply during meetings/conversations: I love to explore important topics to death and sometimes will prioritise doing that over my next meeting/conversation.

2. Rambling: My conversation style is to work off of visual cues from my audience and sometimes when I don’t get a cue, I can continue to elaborate my point which can come off as rambling. I am actively learning to correct this.

Engg. Growth Framework

Performance Evaluation

No README is Perfect

If you have suggestions on things I should cover or clarify in this README, please come and have a chat!

More

More stuff for best practices on OKR setting, High Deliverability, Engg. Team Appraisal Framework, System Design Best Practices, Leadership and Personality types can be found here