Identifying the Real Problem
16 August, 2021
When I arrived at the company, the operation of engineering was not optimal, with many consequences on product quality and also timely delivery of software. We needed to bring some different ways on how to do the work.
One thing is to identify problems, but the more challenging part is to sell the transformation need both internally in engineering and externally to senior leadership. Both groups look for different things in transformation. Engineers want to do the job easier, with less mistakes and sustainably. Senior leadership wants to get quality software for the lowest possible cost. It was obvious that just changing engineering operations won’t help. We had to change the narrative of how we work with customers, how we identify the problem and develop feature scope. All this was leading towards the idea of agile transformation.
The good part is that we were able to perform transformation in a way that we could constantly show benefits of the changes and keep the support from senior leadership as well as maintain engineering teams motivated to continue.
The first important step was to perform proper SWOT analysis at the beginning, focusing on the state of the processes, teams, code quality, test automation and many other engineering operational parameters. I had many discussions with the managers, engineers, and architects. I was genuinely trying to map precisely how the process was going on and what was happening, while avoiding any finger pointing and judgement. Then I identified the weak points and the root causes and eventually consolidated improvements into the areas of focus.
On top of this, I was also asked to transform the product portfolio into modern architecture. At that time most of our products had legacy monolithic architecture and were deployed on prem. therefore I added into SWOT analysis also sections about our products, identifying what is their state and what should be the right direction. Eventually I ended up in running two parallel transformational activities:
- Agile transformation of Engineering
- Building a completely new product portfolio
First and foremost, to make such a transformation, I needed to convince critical stakeholders. Transformation was linked with significant cost and also with missed opportunity cost. For instance, someone could argue that if we won’t transform, we could deliver new features instead. The benefits of all changes had to be clearly formulated and had to be measurable. I had to be effective in persuading stakeholders that we have a perfect direction and it all made sense.
We started transformation with the introduction of agile operation - we adopted scrum process, introduced all necessary ceremonies, started to build a true product backlog. It also required restructuring the teams. Set up teams around components or products, make them self-sufficient from a skills perspective and also empower them.
That was already a bit change internally and naturally I had to overcome certain teams’ inertia and manage the change properly. During transformation, it is easy to lose track where we are going and why. It requires constant reinforcement of benefits, focus on low hanging fruits, so that teams are supportive of the changes.
We also had to completely change the way of working with customers. Introduction of product managers and product owners is one thing, but we need to initiate regular conversations with our users, gain insight and understand problems they are facing.
Apart from introducing regular touchpoints with customers, we had to start tracking the actions of our users, so that we constantly know how they use the products. We automated the possibility to provide feedback directly from applications.
As I mentioned at the beginning, alongside the transformation plan, we defined measures that will in the end indicate success of our effort. It is critical to have KPI’s in place, so that you can see whether you achieved real improvements. At the same time, improved customer satisfaction of customers is another great measure of your success.
- The most critical part is that you will fail in executing the change if you do not convince people to change. People have to understand the benefits of the change, otherwise they won’t be supportive.
- Do not take things as given. Always analyze what is the motivation behind people's behavior. There must be a different language tone that needs to be maintained to speak to the different stakeholders in the company about transformation.
- The leadership team wanted to see the savings and wanted quicker delivery. If you go to your team and start talking about faster delivery, you can probably imagine what engineers will say. Therefore, you need to understand you have a different auditorium for different stories, so you cannot sell the same benefits everywhere.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Internal Hackathons invite team spirit and collaboration which are critical whether an engineering org is co-located or operating remotely spread across 20 times zones. Hackathons give employees the opportunity to connect and network while they solve fun & relevant challenges.
Senior Director of Engineering at SupportLogic
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.
Google Cloud Practice lead at Contino
Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.
Director of Engineering at Inspire Energy
Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.
Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.
Senior Vice President of Engineering at Usergems