Background
Patterns is IBM’s product design training program for new hires. Back in 2015, I was a participant of this program and now, 5 years into my career at IBM, I had the opportunity to coach my own cohort of designers in the Winter 2021 session. As a coach, I acted somewhere between mentor and manager for 5 new designers, as they embarked on their very first assignment at IBM – designing an offboarding experience for employees transitioning to IBM’s new spinoff company, Kyndryl.
When I participated in this program, 60+ designers from all over the world were flown into Austin, Texas for the duration of the experience. But with COVID-19, this program had to transition to a virtual experience, which created unique challenges for all participants and volunteers involved. To add to the situation, my team of designers were scattered amongst timezones — 3 in US Central, 1 in US Eastern, and 1 in Central European time. Despite the challenges, I did everything in my power to set my Patternites up for future success at IBM, and learned some valuable lessons along the way.
My responsibilities
- Help to grow and nurture each participant’s design skills and design thinking practices
- Exemplify design leadership and foster quality collaboration skills
- Observe group interaction, specifically maintaining the psychological security of teammates and intervening when needed
- Be a “dot connector” by building helpful connections between and among activities, people, and organizations
Practices
I was part time on this project, while also contributing to my product team on IBM Security. I used the following practices to keep tabs on the team, supporting them as much as possible while following through with my product team commitments:
- Daily stand-ups
- Office hours ~3/week
- Weekly playbacks
- 1x1s biweekly
- Asynchonous feedback (commenting on prototypes, recording videos, sending messages before signing off, etc.)
Challenges
Managing stakeholders
My team of designers were expected deliver a solution to a real enterprise level problem, figure out how to work together virtually across different time zones in the midst of a pandemic, learn the ropes of IBM’s design system and design thinking practices all in 6 weeks.
To add to this pressure, while most Patterns projects are “concept cars”, this project had an actual due date just weeks after the program ended. You can imagine that this made stakeholders very focused on that final deliverable.
I had to play intermediary, making sure to protect my designers well being while also making sure the stakeholders were able to get what they needed to meet their own deadline. This was a delicate balance, but I used my communication skills to help each side empathize with the other.
Inevitably, in some areas, we had to compromise. For example, our project stakeholders wanted to bring the product team who’d be inhereting this work into the program so they could start building up prototypes. I had to remind them that this is first and foremost an onboarding program, and that was jumping the gun too much for the design team, who were still learning the ropes. The compromise was that the Design Lead could attend daily standups and sit in on our meetings, and therefore begin planning for their future work. This thankfully kept both designers and stakeholders happy!
Building trust and relationships with my team from afar
As a part time mentor with my whole team abroad, I only had a few hours overlapping with my team each day, compared to other coaches who were in the same time zone as their designers. I know from experience working with remote teammates that building relationships takes time and energy. The level of connection we make with colleagues face to face in an afternoon can take months with people we only know from working online. With the program lasting only 6 weeks, I needed to work to build trust with my designers as quickly as possible.
I tried different asynchronous ways of getting to know them — setting up an introductory workspace where we could all share a bit about ourselves, posting in slack each day asking icebreaker questions. But ultimately, feedback at the end of the program shows that I fell a bit short. The designers wished they’d gotten to know a bit more about me sooner.
Over time, the more we met, the closer I became with the team. It worked out in the end, as received top marks from the designers once they graduated from the program, but in hindsight, I wish I’d put in even more effort at the beginning.
Guiding without doing it for them
The day of an important playback, I opened my email to find a link to the team’s presentation with a request for feedback. I knew from my design thinking training and years at IBM that the stakeholders would be expecting more. My instinct was to fix it for them since there would only be one hour between when most of the team got online and the time of the playback. I didn’t want to see them fail, and in all honesty, feared what this would reflect back on me as their coach. But a wise mentor told me that doing it for them is the only way I could fail at being a coach.
So I spent the morning planning speedy activities to help them get to where they needed to be, and I scheduled an emergency meeting. I put their draft problem statements in our shared space and kept pressing them to dig deeper by asking “why”. I played faciliator, critic and note-taker. By the end of the session, the team was at a much better place and was able to make quick updates that drastically impacted the effectiveness of their presentation.
Because I didn’t “do it for them” the team was able to maintain ownership of that work and they learned by doing. And because I remained calm, firm and focused, the team could focus on the activity at hand without any unnecessary stress. I’ve taken this lesson with my back to my product teams, and do my best to support others and ask the right questions, without feeling the need to solve everyone’s problems for them.
Protecting the team during personal setbacks
Midway through the project, there was a massive snow storm that affected 3 out of 5 of my team members. I regretfully admit, I didn’t realize at the time how dire the situation was, both for the teammates affected and for those left to pick up the work. With the program’s leadership decision to keep the deadlines in place, I figured the best support I could offer would be to occasionally check in with the designers affected by the storm, and to offer the remaining teammates more of my time.
It didn’t occur to me at the time that the designers also needed my support when it came to their stakeholders. One of them approached me with the recommendation that I post a public message to let them know the situation and manage their expectations ahead of the next presentation. I wish I had the foresight to do this on my own without the designer’s suggestion, but I’m thankful that she felt comfortable enough to approach me with the team’s needs. In the future, I would like to better protect my team by being more aware of how personal setbacks are affecting their health as well as the team’s health, and make sure any stakeholders are aware of any impacts to the project.
Helping with time management and task ownership
I identified early on that my team needed help with time management and task ownership. There was a misconception that collaboration means everyone works on everything. Team members working late or during the weekends just to keep up. I knew I needed to step in and introduce more efficient ways of working.
While attending daily stand-ups and hosting office hour sessions, I encouraged each member to own a particular piece of work. In the final week, I led the team through an impromptu “sprint planning” exercise where we listed out everything that needed to be done, and assigned owners. Each standup leading to the final presentation, I referred back to this document to make sure the team was on track. Not only was the team more efficient in getting their work done, but giving each person a sense of ownership over work helped to build their confidence and pride in the final deliverable.
Lessons learned
To manage multiple projects, I must relinquish control and trust my teammates.
Juggling my product team work, staying up to date with my cohort’s progress and needs, managing stakeholders… these each could have easily been full time roles. In the first two weeks, I had a hard time accepting that I couldn’t be everywhere at once, but over time, I got more comfortable relinquishing control. Because I had multiple items on my plate, I learned that in order to get it all done, I can trust my instincts and depend on my talented teammates.
Healthy teams run on mutual respect.
No matter how stressful the situation felt, our team remained respectful of each other’s roles, expertise, and opinion. Whenever I had to push back, respect meant it was accepted without bruised egos. This led to a both successful outcome and a pleasant learning experience for everyone.
I can be an effective leader just as I am.
Going into this position, I was concerned that I wouldn’t be taken seriously as a leader. But my personal qualities that I thought didn’t align with a typical “leader” actually worked in my favor, and made me more approachable to my cohort. The feedback I received from my team at the end of the session really drives this home:
“Attentive, kind, humble, intentional, patient, constructive, gracious… mallory is a natural facilitator and was instrumental in helping us narrow our focus and maintain progress. could not have done the project without her guidance!” -Cohort teammate
“…you can tell that Mallory genuinely cared about our success throughout the program and always pushed us to new heights in a way that felt encouraging and supportive. In addition, from the get-go, she set a very conversational and casual tone and was always so great about promoting open and honest dialogue amongst the team.” -Cohort teammate
