_edited.png){kind=logo}
Early last year, I transitioned into an "Engineering Manager" role from the SDE-3 role in AgroStar. I had many questions about this role, expectations, and responsibilities when I started. Still, like many other things, I took it as a challenge to explore this path and vowed to become "one of the good engineering managers" in the industry!
I did apply my usual learning mechanism -- that is,
To begin with, learn as much as possible about philosophical aspects and "why" questions (i.e. first principle thinking)
Apply learnings to the strategic as well as activities
Retrospect, iterate, learn, re-apply.
So I began the journey --
To understand what an engineering manager is, why such a role is needed, and what is the single most valuable thing an EM can do to add value to the organization. To understand this, I started reading some good quality books on the topic, namely Will Larson's "Elegant Puzzle: Systems of Engineering Management" - this is a relatively high-level handbook, mostly geared towards VPs & CTOs, which was very helpful but less directly applicable to day-to-day responsibilities as an EM, followed by Sarah Drasner's "Engineering Management for the Rest of Us", which was directly helpful for my daily activities as an EM.
I also started attending conferences like React India, where I could meet and interact with industry veteran EMs and ask them questions like "What is the most challenging part of being an EM."
And here were my takeaways -
An Engineering Manager's most important quality is an innate passion for helping people grow! Coincidentally, I was already super involved in it (which may have been part of the reason my mentor recommended I transition to the role)
As an EM, the activity that leads to the highest value added to the org is contributing towards growing the individuals to the capability and values you demonstrate (or exceed you!). Along with this, the critical "implicit" role you play is being a product owner, owning delivery, deepening the understanding of the product and users, and ensuring optimum and efficient investment in products that you build.
Further, especially in small organizations like mine, EM also plays the technical architect and coach/leader role, building and making critical technology decisions.
Sounds like too many things, no?
With all this, I started the second part: applying learning by execution in daily activities. As part of the growing team, I got the opportunity to build a fantastic team of UI engineers and could involve in many of the hiring decisions. The key philosophy was around figuring out the right individuals with team fitness and culture match (I am planning to expand this further in another article)
Once the team was hired, it was time for actually "building" the team. I began by defining a clear vision and mission for the team (which revolves around growing strong product-driven engineering culture, valuing customer experience, and sustainability of processes and practices). Still, I need more than writing and explaining the mission and vision! As I started exploring further, I found many opportunities to initiate interesting programs & activities for our hybrid work environment. These being -
Goal Setting - Setting clear, concise, individualized goals for every team member, taking individual aspirations into account, and setting the base for further activities.
Periodic Team Catchups - where we started doing general catchup meetings, talking about work, challenges, life in general, and strategic directions at times. This is also a session where I could instil some of the core values in the team.
Peer Connect - Especially in the early part of the year, when everyone was remote, I actively encouraged team members to connect with every "new" colleague once for half an hour weekly. Team members liked the idea, which transformed into a stronger, well-bonded team. And when we transformed into a hybrid work model, everyone knew each other, and the relationships deepened!
Learning & Development - This is where I identified some core "domains of expertise" for UI engineers, figure out aspirations, strengths, and weaknesses for each team member, and assign them areas and topics for learning, ensuring that they could invest some time and helping them with resources/materials. The primarily young UI engineers could build deeper UX and system design expertise with this. It could actively contribute to making the right product decisions as part of the journey of building products.
Offline collaboration week activities, like "values connect" and "Lifeline", further created an environment of strong empathy and collaboration. (more about this here - https://www.linkedin.com/pulse/conducting-meaningful-in-person-collaboration-week-small-vatharkar/ ) (this was before we transitioned to the hybrid model)
Soon after, I extended "peer connect" for myself to "peer and stakeholder connect", where I would periodically connect for 1:1 with most other tech leaders, product managers, and other stakeholders in the org, where I could ask an important question - "Can you share my team or me ANY feedback in general" answers to which did help me and my team grow a lot!
I streamlined my 1:1s with team members further. As part of a hybrid environment, I ensure that all 1:1s happen in person, sometimes without being time-bound, and spend the time building lasting relationships with the team members. Periodically, this is also a platform for sharing key performance reviews, which ensures feedback is a continuous process, not an annual one. This helped provide a building strong foundation for the team.
Now, as the team's foundation is set, I started analyzing key strengths and limitations of the team; I started taking some initiatives to streamline the value add further -
Building fluidity in the team - Considering the scope of the projects in the org, our team was still small. However, we did notice a pattern where, because of the "single person product ownership" mindset that the org had traditionally followed, some team members ended up with disproportionally different amounts of workloads than others. To solve this, while we still ensure and respect the single-person product ownership model, we defined secondary owners, had a deeper understanding of actively changing projects among all the team members, and arranged knowledge sessions considering the same. Once that was done, we started doing "pre-planning" meetings in the org with the entire product management group, where we could figure out org-wide highest impact items that the UI team could pick across the projects and ensure that the proper allocation happening for those, while still balancing the workload among the team.
Adding Capability / Capacity without hiring further - when there is a need for the engineering bandwidth. I started by writing clear, high-level guidelines for building frontend projects across the org, which is simple enough for any engineer (with ReactJS understanding) to refer to build products. Further, I talked with many engineers in the org. I ensured that if they have passion and interest in building User Interfaces for products, they can have a path to contribute in the same, irrespective of what they do as part of the daily job (whether it is backend engineer or QA or Android engineer etc.). Building user interfaces is the most satisfying part of being an engineer. There were many UI engineering enthusiasts across the org, some of whom could transition into building user interfaces (without changing teams etc.). We could do something like this because of the strong engineering culture that AgroStar has!
Improving predictability & quality, execution, recognize, celebrate! - We improved predictability by investing in helping individuals estimate better, giving individual ownership of the task (rather than the leader coming up with an estimate, it is the individual who estimates and the leader who reviews). Emphasis is given to instilling the value of quality as a team responsibility. We have sometimes made some processes much leaner, with a razor-sharp focus on adding customer value. Proud to have created one of the fastest-moving project groups following the 80:20 principle in the org! I have been part of some exemplary project retrospectives too! Once executed, we make recognition and celebration a habit rather than a "one-off" activity! Each major release should be celebrated with the entire engineering team being together, and individuals who worked on it would talk about what they built! This gives a nice mental closure, especially after complex projects, further boosting the sense of achievement. We include product managers in these celebrations to share the customer impact! This is something we are encouraging across the entire engineering org! The important part is enjoying the journey!
These execution tactics led to highly streamlined product deliveries for UI projects across the org. This also leads to our team being a solid customer-centric, product-driven engineering team, with good predictability and setting the right examples across the org.
As part of technical leadership, where I built major customer-facing products across the year before, I could delegate and add owners among the team for these projects. Having built those myself, to begin with, it did help me be a good technical leader. (As I keep saying, the foundation to being a good technical leader is a good individual contributor). As part of the journey, I continue personally building critical new components and parts of the system, which are highly complex and rapidly changing. Still, it is more than just building the product now. At times, I "write code for mentoring", some of which the team members can refer to as a good example of critical thinking, decision-making, refactoring, etc. Delegating some of the building activities helped me think further into the bigger picture, including investing in the right set of technologies and frameworks for observability, application performance, experimentation capabilities etc., doing it in such a way that it creates foundational abstractions & infrastructure, and enable capabilities for most of the existing and future projects. Further, I am getting deeper involved in contributing to the entire technology stack in the org, including the backend and infrastructure (which I also consider a way to build empathy for other teams in the org and help me execute better cross-functionally). And I am also known to be fanatic about the readability and usability of API contracts!
As I retrospect, I have learned much about the team and being an EM in general! This is already leading to key program changes this year.
There is a lot more to talk about! I can't stop thinking about what more I can do to help the team grow further! There are a ton of things which I could not write here!
This could be executed because of guidance, support, and strong value alignment with my mentors, Sunil Jain, Priyanjali Kharbas, and peers, Priyesh Raj, Priyesh Verma, Shantanu Mahajan, from whom I could constantly keep learning! Further, my team members like Pratiksha Pimple, Anubhav Kandiyal, Laxmi Dutta, Prashant Kumar Sharma could internalize the philosophy behind all this and enjoy the journey! The fantastic engineering culture of AgroStar has played an important role!
In the long term, with this role, and as I grow, I intend to create a positive cycle of "paying it forward" in the industry. All the guidance and support I have received from my mentors in my career helped me grow and take this responsibility. Now, it's my time to do the same for the team I mentor, and I am confident that the team members will grow into creating more such environments in the industry!
A rather long article! Please share what you felt while reading, along with thoughts, ideas, suggestions, etc., in the comments!
Here is the link to the original blog on LinkedIn: https://www.linkedin.com/pulse/year-engineering-management-vishwajeet-vatharkar/