Cross-functional agility to the rescue! Organizing the chaos
Cross-functional teams operating with the Agile methodology are often touted as the ultimate in organizational effectiveness, but for those at the start of the journey it can seem like for every hill crested, another, bigger hurdle is just over the horizon. It’s not until dynamic circumstances come along that one can begin dismantling the hype and experience what these types of teams are truly capable of.
I was four months into my role as the Product Manager for People and Integrations since our company had set out on its journey of transforming the Product and Engineering area into agile, cross-functional teams. We had always had very low-friction methods for users to access our platform, but international growth, global security, and new privacy laws were strong indicators that we needed to improve what we were doing. As one of our key priorities in our area, we were working through understanding the problem space and domain boundaries.
Recently, our team had planned out a large, phased initiative that would begin to slowly evolve our methods of account security and authentication at a pace that would be as palatable to our users as possible. Obviously our users not being able to login = bad time, and so we knew we had to be careful. The classic product itinerary of risk assessments, feasibility, viability, and desirability checks were run and our team had the necessary buy-in from leadership and relevant stakeholders during quarterly guidance. The first piece needed to be completed and tested for the bulk of our users to begin their yearly cycle of using the platform in Q1. The team was feeling good about how closely we were following account security best practice and excited for the new year.
Enter our first major disruption. We had to reprioritize the roadmap to account for market developments around user provisioning, engaging a key vendor in the process. Normally that would be fine; it’s all part of being responsive and putting resources where they need to be, but it did mean that we were delaying the account security work and losing our window for Q1. Any work we were to do after this new user provisioning initiative on account security would bleed into Q1 and into the busiest part of our users’ year — the start of the academic year for ANZ.
I learned that even though you can have the ideal roadmap and staggered approach to work if the business need is high enough, you have to be okay with parking things and then work with leadership to have a shared understanding of the impact of a delay.
That decision was locked in and prioritized and our team took it like champs. It wasn’t ideal as we were effectively deferring a risk that would need to be revisited, but I communicated the business’s growth needs so we all understood the ‘why’. After several planning sessions and stakeholder sign-off, we began work on our user provisioning integration with the new vendor. About a sprint and a half in during the company’s end-of-year celebration week, we got the second, larger disruption. One of our regional Business Development teams had been in the final stages of a government tender process and after passing initial privacy, security, and user provisioning screens, the final layer included several very specific items that we needed to address in order to fully satisfy the tender requirements. We had three major pieces of work to complete and it all needed to be done in four weeks. And we were moving into the Christmas holidays in one week. The task ahead was effectively condensing our original planned account security changes into just under half the time and with no time for an incremental rollout. In all honesty, it felt like an impossible task, but there wasn’t really any time to feel too dejected or frustrated.
I learned to take a moment and breathe. Absorb the information. Accept that this was an exceptional request that would require a huge amount of effort from both my team and the wider engineering team to actually realize in the given timeframe. Also to reflect on the achievement of winning the government tender in the first place.
As a Product Manager I needed to speak to the value and business rationale for the work that had just been outlined as necessary, and then the urgency it entailed to the team. There aren’t too many instances, at least in my ~5 years of experience working at the company, where there are really immovable and concrete deadlines that can’t be pushed for technical considerations, but these tender requirements were just that.
We had emergency run-throughs with leadership and then the relevant government department to understand the problem space and generate a list of needs we were to meet. Then, the team and I took a couple of days to map out the affected areas and rapidly architect a solution using Miro boards and what ended up being a MoSCoW process on steroids.
I learned that when it came down to it, cross-functional teams are at heart, a group of professional problem-solvers. Yeah, it was a challenging scenario, but that didn’t stop the team from going above and beyond, especially our tech lead who went straight into wartime engineer mode and pulled everyone together.
With the timeframes we had, we knew our solution would have to rely on several assumptions and work for the majority of our 1 million+ users. We also knew that it was imperative that we follow up the release with a stream of refinements based on feedback. Our solution incorporated industry standards of password management and account security, with the focus of empowering our users to oversee their own settings.
During this process, I learned that visually mapping out slices of a codebase and distinct user flows is absolutely essential to building a shared understanding of a domain and the problems you are solving. I also learned pretty quickly to be okay with asking a LOT of questions to make sure I was on the same page as our engineers. Since I’m not from a technical background it was crucial that I could both ‘get’ what we were doing from an albeit ‘beginner’s level’ and also communicate to all of the people I needed to with confidence and consistency. This was easier said than done, as the multitude of user flexibility we had built over the years made things look like fractal geometry.
The next step was to chunk up the work and communicate to Product & Engineering leadership that we would need to borrow additional resourcing from the other teams. It wasn’t a matter of “we’d like additional resources” but more of “If we don’t have at least 2–3 more engineers over the next four weeks, then the goal will not be met.” After I articulated this to our leadership team, our CTO made it happen and we managed to secure the help of several VERY generous engineers and began building the solution in the days up to and over Christmas, to culminate in two solid weeks in the New Year before releasing it to our users. This was a great, practical example of our company’s One Team value, and it was definitely not lost on our team.
Release and Customer/Internal Feedback
Upon our offices opening back up in the new year it was time to get communications out to our users and prepare them for our changes. Because our work was a global alteration for our teachers it was important to clearly explain the what and why of what we had done. Time pressures meant we weren’t able to progressively roll out our changes to a subset of users and then expand from there. Upon our communications being drafted and prepped to hand over for email campaign automation, it became clear that our marketing operative responsible wasn’t due back for another week. In the end, we could only give our users about 1.5 weeks of warning before the start of enrolment season as to some of the changes to their provisioning workflows.
I directed internal communications of our new system first at a company-wide announcement level, followed by targeted updates to our Support team (they were the ones most at risk of customer difficulty), then at the regional level of our various company departments in order to allow the information to filter to the required individuals. It was clear from initial reactions that people were concerned with a perceived lack of consultation and worried about the impact it would have on the already hectic yearly onboarding.
Once we went live we quickly became aware of the limitations arising from our few days of solution designing.
I was about to be given a refresher on the idiom ‘the best-laid plans’.
One of our core assumptions was around our users’ access to email addresses. It proved to be one of those ‘gotcha’ moments as there was a segment of our users that through school policy, data security, and age restrictions, were unable to use their supplied email addresses. Our solution had planned for the above use case, but it wasn’t as smooth as it could have been. As a result, customer feedback began to flood in both directly and through our external-facing staff to communicate their difficulties and frustrations at such a critical time in the year. This part of the work was one of the trickiest, as we had to design for the majority, whilst catering just enough for the minority; at the same time, it had to be straightforward for all users.
A key learning here was that while it may be difficult to get input from users on ideas, they’re immediately vocal when something isn’t working for them: acknowledge, listen and triage based on criticality. When working on a large-scale feature, try and get any user feedback you can before a solution goes live, even if you have extremely limited time. A single user can help steer you in the right direction.
Within the first days of our changes going live, we knew that informing customers of where we were at and how we were managing their feedback would be essential. Our Head of Product released an email to all our customers on the changes we had enacted and how we were triaging their feedback and issues raised. Two weeks later we had a follow-up email sent from our CEO to further acknowledge customer frustrations and offer an apology to all of those that had had a disrupted start to their year.
I learned that despite external pressures being placed on the team, our leadership group had our backs and were more than ready to jump into the fray and help where they could.
We had a number of positive customer responses as a result of our executive members’ personally reaching out, which helped give us a bit of breathing room to make changes. We set up an open feedback collection spreadsheet and tracked the inbound responses in Jira to identify the biggest pain points. I began arranging multiple times with our regional teams to speak through concerns, issues, and pain points and patrolled our relevant Slack channels so that I could readily respond to questions. It quickly became clear that we needed to make changes to how we generate temporary passwords and look at multiple user selections for a password reset. We also found that our new temporary password duration wasn’t adequate for our users’ needs.
The automatic provisioning feature that we built was working as intended, but we soon ran into a legacy configuration issue. New users joining the platform wanted to maintain their existing setups, which caused issues when we needed to split them out from a part of our new solution. Following this discovery, we had to isolate these users and make manual changes until we could build the functionality in our admin tools.
All of the work was scoped, planned, refined, and added into our next Sprint for the team to tackle as stage one of our continuous improvement rollout. We had about 4–5 key pieces of work that would solve the majority of our users’ issues both internally and externally, with additional work planned moving forwards to address edge cases.
This period of the crisis taught me that Product Managers have to stay visible and are more effective when we make ourselves available for any and all questions, as people get nervous and can lose confidence in the face of uncertainty. It was my job to absorb all of the frustrations, dismay, and outrage that was flying around and be the calm voice that employed empathy and listened to people without getting defensive or simply saying ‘we had no choice’ and believe me I was tempted.
Iterative Improvements and the Communication Game
Once our sprint was completed and our updates went live, we had fixed the core problems that had reared their heads after the initial launch, but there were still things we needed to do. Two of our big company values are continuous improvement and being open and straightforward, but it wasn’t really until this period in our team’s tenure that I felt we truly lived and breathed these ideals. I’ve read a lot of Product books and articles that talk about iterative improvement and agile delivery, but the truth I’ve found is that it’s not always possible to take enough time and evolve a feature set or functional area; sometimes an MVP needs to be launched and then a shift is made to the next priority on the roadmap. In this instance though, we were listening to the feedback coming from the fresh changes and tweaking the follow-up work to best cater to our users’ needs. We started on the quality of life improvements around user creation and then moved to bigger features that we’d never had before like print-friendly passwords, a simplified temporary password system, and a way to distinguish expired passwords. Alongside these iterative improvements based on feedback, I needed to decide where we could draw a line and move on to other work. The tension between user agency, flexibility, and user data security requirements both government client-specific and internally gave me a decent baseline to check against what remained from users and our customer-facing staff.
Managing the tail end of this account security initiative required constant communication of the direction of work our team was doing. I set up a new internal Miro board to map out the entire matrix of journeys that our users could go through when resetting passwords and/or creating users, and specifically call out the latest releases, work in progress, and coming up next. Then I went through this board with our regional teams and embedded the link into our Slack communications in an effort to normalize referring to this new source of truth. As we reached the end of the work our team had decided to take on I asked key stakeholders and the wider company again explicitly: “Is there anything else we could be doing here?”. Responses varied, but nobody had anything major that wasn’t excluded as being untenable from a security standpoint. Our users had minor tweaks that they were feeding through, but it was finally clear that we were okay to finish up the initiative.
I learned there is no such thing as over-communication, especially when it affects customer experience and the ability of other teams to do their jobs. I’d heard this and had my initial doubts but I found it to be true. Post updates, write emails, create flowcharts, video call different teams, and make sure that multiple people around you can also explain what is happening in case you’re unavailable. Upon reflection, I think I could have done a better job here because if I wasn’t clear at times on who was doing what, then it was pretty likely that my counterparts in the company and government department were struggling with the exact same thing. I should have taken the initiative.
Closing out the Work
Finally getting to an end state that all involved parties were happy with took around 5–6 sprints to complete where at least one of our team’s developers was actively working on a piece of account security work. Months later, we are in a much better position and in a way, it forced us to act faster on crucial platform issues. We still keep a close eye on user feedback for all things account management and security, in addition to knowing where we want to change things in the future for our primary school users.
Being on the team that controls whether or not your entire user base can get into your product is a big responsibility, but the things I learned throughout that account madness gave me valuable experience and made me more effective as a Product Manager:
- You can have the ideal roadmap and staggered approach to work, if the business need is high enough, you have to be okay with parking things and communicate the impact to leadership.
- Take a moment, breathe, and try not to react. Absorb the information. Accept that this was an exceptional request that would require a huge amount of effort from both my team and the wider engineering team to actually realize in the given timeframe.
- Cross-functional teams are professional problem-solvers. Trust them and give them as much space as you can to do their thing.
- While it may be difficult to get input from users on ideas, they’re immediately vocal when something isn’t working for them: acknowledge, listen and organize.
- When external pressures are placed on the team, it makes a massive difference to have a leadership group that has your back and is ready to help.
- Product Managers have to stay visible and are more effective when we make ourselves available for any and all questions, as people get nervous and can lose confidence in the face of uncertainty.
- There is no such thing as over-communication, especially when it affects customer experience and the ability of other teams to do their jobs. I’d heard this and had my initial doubts but I found it to be true. Post updates, write emails, create flowcharts, video call different teams, and make sure that multiple people around you can also explain what is happening in case you’re unavailable.
- Take the initiative. Chances are that you’re not the only one uncertain of roles and responsibilities in a fast-moving crisis.
