Back to resources

Identifying the Real Problem

Team Processes
Agile / Scrum

16 August, 2021

Jan Macek
Jan Macek

VP of Engineering at Vendavo

Jan Macek, VP of Engineering at Vendavo, shares his experience of identifying weaknesses of engineering operation and bringing an agile mindset alongside.

Problem

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.

Actions taken

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.

Lessons learned

  • 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

Why Documentation Is the Key to Success

6 April

Henning Muszynski, Head of Frontend at Doist, promotes his ideas on how documentation ensures consistency, efficiency, and standardization.

Alignment
Collaboration
Productivity
Hiring
Team Processes
Henning Muszynski

Henning Muszynski

Head of Frontend at Doist

It's Time to Say 'No' to Manual Business Processes

6 April

Henning Muszynski, Head of Frontend at Doist, talks about the cost of slow and arduous processes that add up over time and how to bring the changes systematically.

Changing A Company
Conflict Solving
Internal Communication
Feedback
Team Processes
Henning Muszynski

Henning Muszynski

Head of Frontend at Doist

Typical Challenge of Scaling Teams: What to Do When Your Process Doesn’t Scale

30 March

Christophe Broult, Director of Test Engineering at diconium, focuses on how he scaled his team while building organization and management teams in place.

Scaling Team
Building A Team
Reorganization
Team Processes
Christophe Broult

Christophe Broult

Director Test Engineering at diconium

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.