Leadership

As an engineering leader, I’ve contributed in varying degrees to small, medium and large projects, and I have had multiple successes and failures - all of which have been great learning opportunities. From the past few years, I’ve been focused on understanding people better, and helping groups of people solve complex problems.

The largest team that I've managed has been around 30 people, including 3 engineering managers, a software architect, and a program manager. I have not directly managed teams outside of India, but I have had dotted line reports in the US and Singapore in the past. Apart from my team, I've helped grow my division in Pune from around 5-6 employees to around 100+ by building a support system that helped leaders outside of India hire in Pune.

Building high performance teams and ensuring impactful collaboration is challenging, especially with remote working environments. The most important part was to build psychological safety within teams at first, and then within larger groups. To expand this to teams that worked across the globe was done in parts by having key people travel and build relationships across teams, and also by having shared goals that were celebrated publicly. I won't say that everything always worked out exactly as planned and there are still ongoing efforts to increase performance and collaboration, but understanding the psychology of large groups of diverse people, and how they function, is probably the most important requirement.

For products that are customer facing, there is a much deeper collaboration with the product management, security, technical sales, developer advocacy, legal and marketing teams. For internal products or solutions, there is a deeper collaboration with operations (SOC), developer enablement and other product teams.

A common example that is prevalent across multiple products and services is on finding a balance between current customer needs and focus on building a scalable and resilient solution. It is important to establish a strong relationship with these key functional groups so that they feel comfortable to disagree, but commit. Using a structured decision making framework helps drive this more effectively.

Data Exchange

A complex platform solution that I'm leading involves data interoperability. There is a platform and connectors that provide integration of application data into that platform. The key challenges, from a technical perspective, have been around lack of industry standards, and integration of applications and services that were not built to support such solutions. Also, building a team while continuing to deliver value to customers was a challenge as well.

In order to make the platform and all the connectors scalable and reliable, I chose to focus on the strengths of the team and our existing systems (monitoring, SLO/SLI dashboards, automation, etc.). In order to get critical and early feedback, there were alpha and beta programs where the teams partnered with the developer advocacy group to seek customer inputs. This provided clarity about areas to prioritise and make visible incremental progress towards our goals. However, the most important part was to ensure that the right people were in the right place, and that communication across different teams and stakeholders was clear.

Enterprise Cloud Infrastructure Automation and Compliance

In a platform solution that I was leading, and also wearing the architect hat for, suffered from performance related concerns. This was an internal enterprise-wide solution that I had inherited from another team. The impact was directly internal to the organisation, but had indirect impact on multiple external solutions.

I would be lying if I said that getting the development team to be enthusiastic about this engagement was easy. While some of my other teams were building a highly visible solution for the organisation, which provided a much-needed standard observability pipeline + visualisation tools for more than 500 internal microservices, this team had to painstakingly learn complex ServiceNow customisations done by past teams. There were limited opportunities to build cutting-edge solutions but instead they had to hit the ground running and prioritise fixing problems that showed up regularly.

One of the first steps I took was to get involved in this team as a technical architect. Apart from a need to have a technical architect to understand the system at a deeper level, this also helped me understand the challenges faced by the customers and the development team. I identified areas of concerns and roped in the assistance of a seasoned agile coach, who was actually able to help the team simplify some of their processes. From a technical leadership point of view, I was able to help simplify some of the complexities, and from a people leadership point of view, I ensured that the challenges were clearly surfaced, and wins were celebrated.

Since this was an important enterprise service (I called it plumbing, since these are systems that people expect to work, and only notice when something goes wrong), it was imperative that it continued operating well. My strategy was a 6 month plan where a set of team worked on identifying areas of concern. Since this was used by multiple teams, not all problems were the same, and getting insights from these affected teams was important. In the meantime, the other part of the team continued providing support and unblocking internal teams.