Round 3! I’m now just a few weeks into my third co-op term and excited to share what I’ve been doing and learning. What new challenges have I faced? How am I learning, connecting, and growing? What have been my key takeaways?
In the month of January, I joined a huge new project. I got to meet many amazing people and learned a lot from each of them. Through exposure to senior leadership at our client, I started to build a new skill. And finally, I learned a lesson in building software at scale. Let’s dive in!
Baptism by Fire
That’s how my first project was described. On my first day, I was offered the opportunity to join the most complex project in our practice, working on a key business area for one of the largest companies in Canada. My role in PMO would be to oversee the project plan to help move things forward and keep a team of over 100 people on track.
The “fire” part of Baptism by Fire became clear quickly. Our project plan was hugely out of date and no one knew exactly how we were progressing. This was leading to lots of worry and frustration, both on our own team, but also with the client’s senior leadership. It was my first task to get this under control, and I quickly did just that.
Managing and wrapping my mind around a project with 20,000+ tasks and 7,000+ dependencies wasn’t easy either. But I took advantage of my first week to connect with each of our stream leads and learn about their work on a human level. I might never fully explore the plan, but knowing the names and faces behind each section gives me confidence that I can capture the information I need, even when the scope of the project limits my chances to get deep into the details.
Avid readers of these blogs know that coffee chats have been a favourite pastime of mine at both previous co-ops, and this time is no different. In fact, “40 coffees in 4 months” has made it onto my list of goals for the term, so it’s no surprise I’m off to a strong start towards that. And I’ve chosen to write about them again because the people I meet continue to amaze me.
Take for example our Global Alliance Lead, who shared with me his story of coming to Canada as an immigrant, building a business, and eventually joining this firm. He spoke about the importance of being curious, building experience, and asking “Why?”. The latter point particularly stuck with me. By asking “Why is that?” a few times over, you can quickly get at a person’s motivation and perspectives. Maybe they’re talking about this because they’re genuinely curious, maybe they feel they need to, maybe they don’t even know why this is important. Each situation is handled very differently, and understanding which, simply by asking “Why?”, gives you the opportunity to provide answers that truly matter to the person.
My chats have also shown me the power of a strong network. The last question I ask on every call is “Who should I chat with next?”. It’s a great way to grow my list, and meet people who are relevant to the interests I’ve shared so far. But it’s also been an important avenue to meeting some busy people who otherwise might not have made the time for a chat with me. I’ve gotten to connect with Senior Managers and Partners in a completely different area of the firm just because someone was willing to make an introduction for me. I’ve had calls completely turn my favour once we found a mutual connection; “Oh your coach is X? I did my MBA with X, they’re great! If you’re a friend of X, I’m sure I could see what I can do!”. Strong networks have opened doors I couldn’t have imagined otherwise!
Effective communication can mean a lot of different things, depending on the audience. Or so my SPCOM prof would say. But it’s become more and more true in the various roles I’ve taken on in the past. Tailoring communication to your audience, putting yourself in their shoes, and practicing empathy can make a big difference.
However, this new role has pushed me to take this to a whole new level. Part of my responsibilities includes sending status updates and preparing slides for executives at our client, including the CEO, CFO, CIO, and various SVPs. It sure isn’t trivial to put myself in their shoes, but it’s been an interesting challenge to try.
In my experience, these stakeholders care about hitting our project targets, and ensuring the right resources are available to reach them. When there’s a risk to our timelines, they care more about how we can fix it (our “path to green”), than the details on what caused it. In a way, it’s a refreshing results-driven mindset. To me, Executive-Level Communication means embracing that mindset.
Software at Scale
If you’ve taken a glance through my LinkedIn, it might be easy at first to miss that alongside my interest in business strategy, I also have a passion for tech. I first learned how to code in middle school, and it’s a skill I’m come to find handy every since. Especially as I pursue my degree in Computer Science.
Often when I’m learning in the classroom, I’m looking for the applications of each lesson. Last semester, I took my first algorithms course, where we explored how to architect software solutions that were the most optimal solutions for a given problem. In particular, we focused on designing code that would run quickly and efficiently at scale.
But as I learned more about this, I struggled with how it would apply to my life. After all, I wouldn’t be writing code meant for massive systems where this speed was necessary. And if I ever did, I could learn then, right? Moreover, did any undergraduate computer science student really need to know the absolute most optimal approach this early in their career, especially when cloud compute power is so readily available these days?
It took coming to this co-op to learn why anyone who writes code should know their way around algorithm design. In the first few weeks of my term, I was onboarded onto a project management platform that was horrendously slow. It took less than a day to see that this was a major bottleneck in our project’s success. In fact, soon after I joined we switched to a new tool since even our client saw the impact this was having.
This tool worked great for other projects. Our teams and our clients loved it. But as soon as our project plan grew and grew and grew, it started to break down to unusable speeds. Somewhere out there, there’s a software developer who built a part of this tool and chose a slightly less-than-optimal solution with the assumption that it’d never be used at such a large scale. As someone who builds software myself, it’s a lesson that’s stuck with me. You never fully know where and how your code will be used, and choosing to go the easy way instead of the right way can cause trouble later that you couldn’t foresee now.