Back to resources

Moving From Cowboy to Agile Delivery

Scaling Team
Team Processes
Career Path
Agile / Scrum

15 July, 2021

Catalin Stoiovici
Catalin Stoiovici

Head of Scaled Engineering Delivery at Capco

Catalin Stoiovici, Head of Engineering Delivery at Capco, shares how he helped his team transition to a more mature operational practice and replace their ad hoc, cowboy style of delivery with Agile.

Problem

Years ago, I joined a team that I felt was entangled in a number of problems. Three that stood out from the start were:

  • There was no career development plan for engineers on the team. For engineers to be happy, they need to have clear expectations on how they could grow and how their employers could help. Moreover, time-crunched as most engineering teams are, we were not spending enough time discussing with engineers what they wanted to do next and what their goals and aspirations were.
  • The structure I encountered was not matching our needs. It was evident that the reorg was long overdue. Most of the team leads neither wanted to manage people nor had the skills to do that. In addition, I noticed some personal animosities among people on the team, which is not uncommon for a team of any kind but should be dealt with before it escalates.
  • There were no metrics for team success or team health. Without metrics in place, it was hard to tell if the team was doing a good job or not. In most cases, without reliable data, people tend to resort to pointing fingers and blaming others. Also, we didn’t have sprint goals and were not tracking delivery speed by keeping tabs on velocity or lead time and product alignment by keeping tabs on OKRs.

Actions taken

I addressed each of those problems separately. I understood that they were manifestations of a deeper structural problem: a lack of a proper development process. By introducing Agile and being more responsive to the team’s needs, I managed to move the needle in the right direction.

I allocated ample time to understand the career goals of every individual on the team and then assess if those were aligned with organisational objectives. I would help engineers draft a document on what their career development plan should look like and have them identify how I could help them move faster toward their career goals.

I decided to do a complete overhaul of the organisational structure. I made everyone report to me because I didn’t want to force team leads to do anything they didn’t want to do. We were lucky that I had the bandwidth to cover for them and take on myself managing all the team.

Also, I had to figure out how to re-shuffle people and minimise the impact of those intra-team animosities. If all senior people would be kept on the same team, the tension between them would likely appear. As seniors, they would have strong opinions about decisions and pick up a fight over minor matters. By mixing up seniors and juniors, I created a more balanced team and healthier atmosphere. I encouraged mentoring, good practice exchanges, brainstorms on technical solutions, intensive technical discussions, etc.

I managed to visualise our success from one sprint to another and ensure the alignment of priorities by creating the right metrics and dashboards. I also introduced metrics that could help us improve the quality of our work. In the past, all of our incident management was handled over email, and we were not tracking our production incidents diligently. I introduced level one to three production support that allowed us to visualise incident metrics.

Finally, I had to introduce some metrics that would measure the health of the team. The team did annual 360 reviews, but that felt like coaching someone tennis and giving them feedback on their serve once per month. The team needed more frequent feedback to be able to act on it. I introduced Officevibe, a team engagement platform that helped me track and improve the team’s health. My team members could fill in anonymous surveys and share their thoughts, and I would make sure to convey their feedback to the leadership.

Lessons learned

  • People need to be supported. Allocate enough time to the different types of support they need. Career development is massively important for every engineer, so you need to dedicate time to career development discussions. One of my primary responsibilities would be to help my team identify their Ps (Purpose). According to Daniel Pink, the purpose is one of the three main components of motivation, a prerequisite for one’s growth. If the only reason why your engineers come to work is to deliver code, they will not be happy. But if they feel that they are part of a bigger picture or a greater purpose, they will find their work more enjoyable.
  • I always encourage people to do better and continuously improve their skills by understanding the impact of continuous improvement (kaizen). For a team to be truly agile, it needs to consist of individual minds that embrace the growth mindset.
  • You have to choose the team structure that will not impose the responsibility of managing people on those who are unwilling to do it. In general, I would always try to replace imposing with encouraging.
  • Differences of opinion are normal and even healthy. People should feel free to disagree, vent off, and even decide with whom they want to work. That will make them more productive.
  • Having metrics in place is a precondition for understanding if someone is doing a good job. Metrics are like a compass that helps you understand in which direction you should be going. They allow you to make the right business or personal decisions, and one can’t be agile without being committed to measuring things.

Discover Plato

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


Related stories

The Importance of Culture and Values When Building Teams

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

How to Streamline Your Recruitment Process for Quick and Effective Hiring

26 May

Philip Gollucci, Director of Cloud Engineering at CareRev, describes a new method for hiring in a market climate that favors candidates instead of recruiters.

Scaling Team
Building A Team
Hiring
Philip Gollucci

Philip Gollucci

CEO/Founder at P6M7G8 Inc.

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.

Managing Culturally Diverse Remote Teams

11 May

Tom Hill, Engineering Manager at Globality, Inc., shares how he works with a culturally diverse team based within a thirteen-hour time gap.

Scaling Team
Handling Promotion
Remote
Onboarding
Hiring
Cultural Differences
Tom Hill

Tom Hill

Engineering Manager at Torii

Growing Through Different Engineering Lead Roles

8 May

Weiyuan Liu describes his experience moving up from an individual contributor, tech lead, and engineering manager.

Leadership
Coaching / Training / Mentorship
Career Path
Weiyuan Liu

Weiyuan Liu

Director of Engineering at Zillearn

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.