As organizations adopt Agile, they are faced with few challenges. One such challenge is around re-defining some of the traditional roles, like that of a People Manager. We have lived through an agile adoption journey in Capital One (one of the leading banks in the U.S.) and have taken active roles in shaping the roles and responsibilities of people managers in our respective areas. In this experience report, we will share from our experience, how the role of the People Manager can and must evolve as teams move towards Agile. Not only have we led and witnessed the Agile transformation at our organization, but also we have transformed ourselves as people leaders and transformed our leadership styles. We have made mistakes and learnt from those mistakes, which is also documented in this experience report.
1. INTRODUCTION
When we joined Capital One a few years back, the challenge that we had upon ourselves as people leaders was to find ways to be impactful and meaningfully contribute to the agile organization besides just managing teams in the conventional way.
Capital One was already into its agile journey, but yet some of the leadership roles were not very well defined. This environment allowed leaders like us to infuse best practices from our prior experiences and experiment with the status quo, while simultaneously learning from the organization. Over the last several years both of us have accumulated a broad range of leadership experiences and best practices that we will be sharing in this experience report.
2. Background
Capital One is the fifth largest consumer bank and the eighth largest bank overall in the U.S. As a company, Capital One specializes in credit cards, auto loans, and banking and savings products. Over the years, Capital One has developed a reputation for being a technology-focused bank. It was the first U.S. bank to go all in on the cloud. The company also has international operations, mainly in the UK and Canada.
Capital One has been an early adopter of Agile and SAFe [SAFe]. Starting in the early 2010s, Capital One has made huge investments in advancing agile practices within the organization. Though it started out slow, the company was able to gain momentum in the later years by leveraging organic agile adoptions and also through key acquisitions. Over the years, teams in Capital One have matured significantly and the company is now known across the industry for its matured agile practices.
Capital One leverages SAFe across the organization, with some specific customizations. Within the Capital One technology organization, each agile team consists of 5 or 6 software engineers, a Product Owner (also known as PO), an ADL (Agile Delivery Lead, or Scrum Master as widely known) and a Team Lead. While the engineers are dedicated to a given team, it is not uncommon for PO and ADL roles to support multiple teams simultaneously. Similarly a Team Lead usually leads multiple teams. A Team Lead is responsible for people management and is accountable for team’s delivery.
Though there is a great deal of clarity with respect to the roles and responsibilities of people/team leaders now in our organization, the same was not well defined during the early stages of agile adoption. Part of the challenge was that, until recently, SAFe did not have much guidance around the team leader role for agile teams. As a result each organization had to find its own way of rationalizing this role within their respective teams.
Coming from a waterfall methodology of managing deliveries, we were not only new to the agile world, but we also had to figure out how best we can support our teams within the agile structure. We had to rethink pretty much every aspect of people and delivery management. As it stands now, after several years of journey to agile maturity, team leads are responsible for the following:
- People leadership including coaching, performance management, compensation decisions etc.
- Accountable for the team’s deliveries
- Collaboration with other agile roles to remove impediments
- Staffing
- Accountable for platform/application health
- Culture and people engagement
3. Our Story
3.1 Be a pragmatic agile champion for your team
Many leaders incorrectly assume that as long as their teams are adhering to the SAFe framework, there is probably nothing more to do to improve from an Agile implementation point of view. However the truth is that SAFe is just a generalized framework for organizations that want to adopt Agile and hence will likely require some adjustments depending on the specific business needs, culture of the organization and various other factors. Instead of keeping “sustainable business value” as their goal, sometimes teams wrongly assume that their goal is to adhere to the SAFe framework with little regard to the business value.
We experienced this with one of our team during the early days of SAFe adoption at our organizations, when things were still being defined and understood. We were leading a team that was asked to deliver very technical intents (features) that had little to do with any product features. But as always, going by SAFe guidelines, we had a dedicated Product Owner (PO), an Agile Delivery Lead (ADL) and 5 engineers within the team to deliver these intents (features). As the intents were very technical in nature, the PO did not have detailed understanding of the technical intricacies. The tech team was mostly driving the grooming discussions and prioritizing the intents by considering the technical dependencies, without any significant inputs from the PO.
This was not the best arrangement for anyone within the team. The tech team already knew the dependencies and priorities, yet they had to explain everything to the PO so that the PO could provide the prioritization, which the team was already aware of. This went on for a few weeks. We were too new to challenge this arrangement. This started to take a toll on the team and on the PO as well.
Out of our respect for the team’s autonomy, we did not want to disrupt the arrangement immediately. However, when we pulled up with individual team members, everyone had very strong feedback about how things were going. We encouraged the team members to raise this up in the retrospective and requested the ADL to schedule an ad-hoc retro to hear the team out. When the team raised this as an impediment in the retrospective meeting, we got an opportunity to discuss this openly and finally concluded that there is no need to have a dedicated PO for teams working on technical intents. Post this discussion, we changed the practice to share one PO across multiple teams, which worked really well for everyone.
Every time a new team member joined the team, they brought with them new perspectives and experiences on agile best practices. While the infusion of fresh perspectives makes the team stronger most of the time, there is a risk that one might end up adopting a practice that might have worked elsewhere, but is not suitable to Capital One. As the team lead, we had to very closely evaluate any proposed change and make sure the team was fully bought-in to the change before we introduced it to the team. We also instilled a norm that every change introduced will be monitored for its effectiveness for a PI (6 weeks) and if required, further amendments would be made. This allowed us to welcome new ideas, try those out and discard those if they did not work.
As an example, one of our new hires, who joined us from a competitor and had a solid agile background, suggested that we keep the stand ups duration to 15 minutes (which was 30 minutes before) and limit the discussions to updates from team members only.
After getting the buy-in from the team members that this proposal could lead to better outcomes, we took these suggestions to the Scrum Master, who helped us implement it. The Scrum Master also continuously monitored the effectiveness of these changes and did a retrospective after 6 weeks.
Here is what we found out:
Though the suggestion was intended to avoid problem solving during the stand ups and to keep the discussions focused on updates, we realized that team members were rushing through the updates. Updates were very quick and unless someone knew the tasks closely, it was very hard to follow the conversation. Teams were not bringing up potential impediments early on as there was more focus to complete the stand up on time. Before this suggestion was implemented, we (Team lead and PO) would take 5-10 minutes every day to share the ever changing big picture, external updates and the overall contexts with the teams. Because of the reduced time, the Team Lead/PO updates were taken out from the stand up. After reviewing the feedback from the team and stakeholders, we (in partnership with the SM) decided to go back to the 30 minute stand up, but collectively agreed that the team would not problem solve during the stand ups. If a problem solving session was required, a separate meeting would be called in with just the relevant stakeholders.
3.2 Be a talent magnet and build a culture where talent can thrive
At Capital One, we use a standardized and centralized recruiting process for all our software engineering positions across the organization. To ensure a seamless candidate experience, all our interviewers are trained and certified to conduct specific interviews. Interviewing is considered a voluntary activity and hence individual hiring managers are not mandated to participate in the interviews.
To pursue our goal of building solid talent pools within our teams, we became very active in recruiting by volunteering to conduct the interviews. Not just ourselves, but we also encouraged our existing engineers to actively participate in interviewing candidates. By striving for the best talent, we pushed the talent bar higher not just within our teams, but across the organization. We empowered our interviewers to be bold in their hiring recommendations and hold the ground when they saw red flags with the candidates.
As an example, one of the candidates did extremely well in most of the interviews, but one of our interviewers (team member) was not pleased with the candidate because of lack of practical experience and inconsistent behaviors during the interview. Though the interviewer was one of the junior interviewers, we valued his opinion and did not extend an offer to the candidate. By involving the team in interviews and conducting separate behavioral interviews, we got more meaningful feedback on whether a particular candidate was best suited to fit our team culture and whether he/she can deliver against the intellectual demand of the team.
In our decades of tech career, we had seen several dysfunctional teams in various organizations. Pretty much all these teams had one problem— “Culture”. We knew very well the importance of building a culture of trust, collaboration and psychological safety by the time we joined Capital One. That’s exactly what we had set out to build as we started our careers with Capital One.
As an example, some of our teams were focused on supporting a legacy application that was scheduled to be demised after a couple of years. Team members who had specialized in that application and had done a great job thus far, were fearful of their future career with the company, because of the skill set gaps that existed (to be successful elsewhere within the company). This sense of psychological fear was manifesting in other challenges within the team, e.g lack of collaborations, trust, etc.
As the Team Leads, we took this issue head on. We had very detailed conversations with the specific team members to understand the rationale behind. We assured each of the members that if they were willing to cross-skill, they had nothing to fear. We worked with those members to come up with a realistic cross-skilling plan. Each of the team members were allocated dedicated time and support structure to be able to acquire new skills. Team members were provided access to enroll in classroom trainings, access to Capital One’s own portal for learning new technical languages/concepts, access to thousands of curated learning contents from multiple vendors and individual mentoring from other skilled members of the team. We tracked progress and provided required support/feedback to get most of those team members to the finish line. This had a major impact on those members and overall team dynamics. Successful cross-skilling boosted confidence and morale of those team members. For those who had difficulties completing the cross-skilling plan, we offered them to take on other non-engineering roles depending on their competencies and preferences. By the end of this journey, the teams were completely transformed and were much happier and productive overall.
3.3 Be a Servant first, then a Leader
At its core, servant leadership is about putting the team first. We grew into this style over time and adopted practices that allowed us to always put our teams before us. We learned from our mistakes and from experience and wisdom of those we work with.
At the beginning of our tenure, one of our teams was tasked with designing and implementing a customer facing online application on a new platform. The team started off with building a prototype as a way to evaluate the platform and tools involved, and with the goal of making those key design decisions upfront that would guide the overall architecture of the application. Given our accountability of the delivery, we sat through and led several design discussions with the team.
The system design seemed to progress at a slower that expected pace, and that started to concern us. In an effort to figure out what was going wrong, we took a step back and analyzed how those design sessions were being run. We realized that most of the time we were asking design questions of the engineers and they were answering them. It became a process where we were influencing the design decisions significantly and the team was basically accepting our direction without much debate. Since this was not working, we changed the approach. We started to take a back seat in these discussions and let the team play a more active role. We almost became observers and our questions became more along the lines of “How can I help you with testing this concept that you just proposed?” or “Do you need another team’s help on this tool?” We saw an immediate effect of the changed approach.
The team started to bring more ideas onto the table and began formulating better solutions. They validated their decisions with us but we were not making those decisions for them anymore. They sought our help where needed, and when that happened, we were there to help out. For example, if they needed to know if a certain pattern would be compatible with our security policies, we would help by bringing experts from the security team into the discussions. In another instance, they asked if a new vendor tool could be evaluated, and we took that up with our vendor management team. We began serving the team’s needs instead of prescribing how they should operate.
We work in a fast-paced environment with audacious organizational goals. The organization employs thorough planning and ability to react to change in order to achieve its set goals. As team leaders, we act as coaches who are there to help the team develop skills that they need to be successful, and we let them utilize those skills to deliver on the goals. Most importantly, we take ownership when our teams make an occasional mistake and work with them to recover from the same.
During one of the projects that a team was assigned, they needed to choose an execution environment for the application they were building. The team was given few constraints around speed and resiliency and they came up with a proposal that involved an execution environment that was only recently approved for use. There was a bit of risk involved but we let them proceed with it. The solution worked great during testing but as the team got closer to rollout, they realized that they had used incorrect data to determine production load and the solution would not work for the actual load. This set the team back but we stepped in to take ownership and re-negotiated the timelines with internal clients so the team could rework and deliver the solution.
3.4 Empower the Teams for Success
One of the tenets of Agile transformation at Capital One is the structure of our teams. Most teams are “full-stack” and we expect each team to have expertise in all layers of our technology stack. However, the concept extends beyond just technical skills and into the ability of teams to make several of the key decisions on the project that they are assigned.
To enable the teams to make right decisions, we need to create the right environment, where teams feel psychologically safe to make decisions, knowing very well that sometimes those decisions may go wrong. We need to ensure that teams have all the information and context available to them to be able to make the right decisions. Finally, we need to set clear boundaries and expectations. Those are the key ingredients to empowering a team.
One of our guiding principles when it comes to empowerment is that we delegate outcomes, and not actions. In other words, we set the goal and provide the context and let the team create a path toward the goals. A while back we had a situation at our hand where an older system needed remediation for some issues identified by the information security team. In similar situations, the course of action almost always used to be to fix code where needed, update libraries and run thorough regression testing. However, in this instance we decided to let the team know that the application needed to be brought to the latest standards and did not prescribe how they did it. The team got together and analyzed the situation and came back with a proposal to re-write the application with a newer framework that would get rid of all issues and at the same time improve the application’s performance. This was certainly an unusual approach and seemed risky at first. However, the team made a strong case that a rewrite would not take any longer than updating the existing code, given how old the application was and the time it would take to investigate each reported issue. We let the team proceed with their proposed solution and they completed the same well within the stipulated timeline. Not only were the security issues fixed, but we also had a brand new and shiny system at our hands. Had we prescribed the steps and actions to the team instead of just telling them the expected outcome, we would still be dealing with an old and creaky system!
4. Conclusions
In this report, we have shared a few key principles and practices that we follow while leading our teams. We have come a long way in the 5 years that we have spent at Capital One and our experiences have made us stronger Team Leads. Our personal transformation has been a direct result of our teams’ transformation and adoption of Agile. There is never a “one size fit all” solution when it comes to effective leadership but it is our hope that the ideas we have shared will help the readers build a better understanding of expectations of a people leader in an agile environment.
The biggest lesson that we have taken away from our experience is that Agile transformation is a continuous journey. It’s all about the drive and determination to learn and get better. This is true no matter the role one plays. We, as Team Leads, have certainly found that we need to often reinvest ourselves, drop old ways to lead and adopt new ones, if we want our teams to stay motivated and produce awesome results.
We want to leave you, the reader, with these four pillars, shown in Figure 1, that are the result of our evolution as Team Leads. These pillars continue to provide us the strength to build high performing teams that maximize the value delivered to our organization.
Figure 1. The four pillars of building high performing teams
Ours has been a great journey of learning and knowing the culture at Capital One, we can confidently say that we will continue to learn and evolve. Capital One’s mission is to “change banking for good” and that change starts at the team level and people managers like us are the impatient change agents.
5. Acknowledgements
There are so many people we want to acknowledge and thank for this report. To our teams at Capital One, who have given us the motivation and strength to strive to be better leaders each day. To our colleagues and managers who have coached and mentored us in so many ways and helped us overcome our challenges. To our families who have sacrificed valuable time so we could focus on writing this. To the Agile Alliance community for giving us the opportunity to share our experience. Last but not the least, to Frank Olsen, our guide and shepherd for his valuable feedback throughout the writing process. This report would not have seen the day of light but for the support and wishes from everyone we mentioned above and others who we may have unintentionally omitted.
REFERENCES
[SAFe] SAFe Case Study: Capital One Capital One: Reimagining Product and Delivery through Agile [ONLINE] Available at https://www.scaledagileframework.com/capital-one-case-study/. [Accessed 17 May 2021].
