After my initial brush, I was back to development in other organisations. I spent a couple of more years in this role and getting a few promotion to the next possible level. Then, I got another opportunity to join an enterprise. The enterprise was struggling though one of its products. The product had performance issues, it was very difficult to deploy and release. They were making only couple of releases a year. The hiring manager came and explained the challenges. It looked to be an opportunity to test my knowledge and experience for an enterprise scale. I went through the process and finally joined the journey of an Engineering Manager.

The Ask

The ask was to improved the product in-terms of process and performance. The product had all the required functions. There was a 30 people team implementing the upcoming requirements. But the performance and time-to-market was pathetic. I found out that the product was too big to fit in one’s mind , unless he had been there for ages. There were many flows in one application. I filled out a complete notebook with so called knowledge transfer, yet I understood nothing.

It takes time to absorb things. Pour water on a sponge, it will stop absorbing after a while.

But the organisation had the culture of KT for the entire product. So went through it. In my current role I was not supposed to fix these problems. I was asked to build a few Squads to deliver it.

Rolling Sleeves

I started building my first Squad. I called it the Release team. Till that point I had experience of working with under 10 people teams. SO I made a cross functional team of 7 people (2 senior folks, 3 junior folks, 1 testing and Me). To me the experience and structure was right. The senior folks knew the processes of the enterprise, while the junior folks saw this as technical learning.

I started building an initial roadmap. The first ask for multiple to have frequent releases. I gave an overview of different ways for automation and they told me about the bottlenecks in the organisation way-of-working. I assigned them the task of getting some automation things in places for the different needs. I took the task to understand the culture and communications with the enterprise.

Impediments

Initially the spirits were high as the developers were getting exposure to a number of tools and processes. But soon we were bogged down, but the practice of production stability.

Prove that the provided solution works as expected. Get this validated by its users.

But how do you validate that the practice works ? and there comes the reconciliation.

Basically now you do the same work twice one using the old way and one using the way and validate.

Instead of moving fast we were slow. It was horrible ! I realised that these org behaviours are in places as the different teams do not work as a single unit of operation. They were thinking of throwing the ball from one court to another. I had to put a lot of effort, in convincing people and rolling it out.

After the initial reputation was established it was easier for me to roll out a mongo squad and another ansible squad. All these squads were small with 5 to 7 people each.

Learnings

There have been many leanings while I served the position. The teams performed fine. I realised Communication at different levels must be handled very differently

Investment

I got this advice from a financial-philosopher friend.

People and Mutual funds are alike. Invest in them regularly before reaping benefits.

I had the benefits of this advice at many levels. First, since I was telling my team what to so this created a reputation which helped me in difficult conversations. I had to tell them often that I can provide knowledge if they stick to the course.

Secondly, I invested in building connects through the organisation different. I would often sed some time to understand their way of working. This helped me to cut across the culture. It got quick support for the subordinate rather making escalation requests from the top.

Thirdly, since there was less noise from the subordinates so I got the agreement from senior stakeholders.

Proof-Of-Concepts

When we started my team jumped to pick tools. They all were doing POCs and integrating them with the projects. The senior folks presented various benefits of one approach over another. There were debates on the different approaches. After 4 sprints, I was having uneasiness of the way of working. There were a bunch of slightly more than hello_world programs but no one was pushing further. A senior manager in the enterprise quoted the behaviour as :

Technique over Purpose

We spent more time in figuring our more ways than required. It is fine to have a comparison but there is no point in doing it over 10 items. The next step was to pick one of the tools and address the project issues. The project was still struggling. We needed to address actual project issues.

Feedback

This was a must have and I missed it many levels. As a developer we are not inn habit of capturing feedback. Even the demo feedback is often captured by the Scrum Master or the Product Owner. As a manager, we need to be capturing feedback from stakeholders and delivering feedback to the subordinates. I was bad at providing feedback to the subordinates, so I had hard time during the appraisal cycles. During my first appraisal cycle, I still had the excuse of being new to the system. But at the second time, there was no such excuse. At one time one of the subordinate threatened to quit, I had take a hard stand even though I did not provided the timely feedback. But since I did investment in them previously so I reaped it during the appraisal cycle.