Leading a UI Overhaul With a Tight Deadline

Problem

Recently, I was assigned to lead a cross-team overhaul project. Our CTO gave us a direction and a quite tight deadline of three months -- which is our general release cycle -- to overhaul the UI of our application. The task involved designing, UX designing, automation, testing, and most importantly, frictionless cross-functional collaboration.

It was a rather difficult task, which, when announced, left many across the company doubtful. I was leading the QA effort along with making sure that development, product management, and QA were all in sync and aligned on the vision that our leaders had.

Actions taken

We were given three months, and almost two months were spent on UI and UX design. During that time, I worked with the automation team to come up with a plan that would allow us to revert if something would go wrong. Our strategy was to be able to put everything behind a flag, so we could switch a flag on and off if some customers wouldn’t want/like it or if something would go bad on our end. It was a huge undertaking from the automation side: we provided infrastructure, and I provided technical guidance. I myself did a PLC on them as someone who loves hands-on work and then handed it off to engineers who productize it. That made us ready to go from the automation side.

From the QA side, I came up with a detailed, step-by-step QA plan, working with managers from different functions. Development came up with a similar plan, which helped us align from the start. We presented the plan company-wide, inviting leaders from different teams to chime in with suggestions. I wanted to make the whole process inclusive and invite all stakeholders to provide constructive feedback.

After solid planning, we were confident we could move forward with execution. When tickets started to come in, my manager stepped in to ensure our tickets were a priority. Other developers from other teams had to prioritize the code we were rolling out, so I had regular meetings with them, ensuring no one was blocked on anything. I was talking on a frequent cadence to their PMs, their managers -- prioritizing and deprioritizing.

 

I had daily standups with the QA and automation teams, both being offshore, meaning that I was spending my mornings and evenings in standups. I also had daily standups with leaders from other teams, ensuring that we were all on the same page. I wanted everyone to be fully informed about what was going on at any given time. I made sure to uphold full transparency and clarity throughout the process, which meant frequent communication either through meetings or reports that were going out.

I also wanted everyone to be clear on execution. I had multiple meetings with different teams to guide them and handhold them through different steps of the process if needed. No one should feel unprepared or uncomfortable for not knowing what was expected of them. We set up a Slack channel and Google Chat specifically for this purpose so that everyone was updated and could ask questions. Moreover, everyone knew what person in which team they should reach out to for particular information or if they were blocked on anything. We, as three leaders, were meeting the entire time, checking where we were and assessing if we could meet the deadline.

Finally, the day came to roll out the project. It was a great success from the onset. Indeed there was some firefighting toward the end, but we managed to anticipate most issues. Everyone was immensely pleased, and customer feedback is fantastic. That didn’t go unnoticed internally. Our GM sent out an email congratulating the team and commending the leadership we provided. My name was specifically called out in the company meetings, given that I provided inspiring leadership from the QA side.

Lessons learned

• With large cross-team projects, communication and planning are crucial. We had to come up with a detailed plan and then stick to it. If we had decided to change anything in the plan, it would have to be well communicated.
• Question your plan. Having a good plan doesn’t mean it is set in stone. Things will change, and you will have to adjust accordingly. As the project progressed, we also learned a lot and embedded those learnings into the revised project plan. The same applies to processes. If the QA process needed to be changed, we shouldn’t be rigid about it.
• Make sure to create a feedback loop. Whether it is a daily standup or any other venue, make sure to introduce an opportunity for people to deliver/receive regular feedback.
• Stay focused. Many opinions will be thrown your way. Listen to them, but you are that central person that knows what is going on, in and out. Take input from everyone, but do what you feel is right based on the data points you have.
• As a leader, you have to be confident that things will work out. If you, as a leader, show any sign of weakness, your team will feel it, and it will impact their performance. But if you are confident that you can deliver it, the team will sense it and deliver. While you need to have a plan B and be prepared for a worst-case scenario, no one but leaders needs to know about this.