CBC Digital Labs
Published in

CBC Digital Labs

When it Comes to Technical Leadership, Communication is Key (and Knowing Everything is Not)

The Digital Strategy & Product department of CBC is committed to providing their people with the support they need to build their development plans to foster career growth and progression. By taking on exciting new roles, individuals are able to experience and learn other aspects of the business, broaden their perspectives, acquire new skills and competencies, while increasing breadth and depth in their areas of specialty. This series about Technical Leadership at CBC invites people to take a courageous step and tell the story of their journey, highlighting the support they received and opportunities discovered along the way.

Phil Moreira — Solutions Architect

Phil Moreira is a Solutions Architect at CBC within Digital Strategy & Products. He joined the organization in 2017 as a Senior Developer, became a Technical Architect in 2018 and took on his most recent role in 2021.

  • As a young person, when asked “what do you want to be when you grow up”, how did you answer this question? How would you answer this question today?

I think I remember telling people I wanted to be a soccer player, which I laugh about now because I was never really super athletic.

Today, I still sometimes feel that I’m still not a grown up! But, in the future, I’d like to lead a team or company’s digital group — perhaps as a director or CTO. When I started in this field, 15 to 20 years ago, I thought I’d be building computer applications that would be shipped on a disk and had to be installed (remember the days?) but the web changed things. One of the things I love about the technology sector is how much opportunity exists for pivoting to something else. I’ve been happy with my journey so far.

  • Tell us about your journey to technical leadership. What has helped you get to where you are now?

When starting out at CBC as a senior developer on the Analytics & Search team, I got to lead the work for our search product. I was able to explain the approach we could take and get buy-in from the team. With that came lots of documentation and reviews with my peers to ensure I wasn’t just building something that only I understood and worked only for me. It’s very easy to fall into a trap and you can inadvertently alienate your peers who also need to work on the same things.

When the opportunity came to become a technical architect for our Web Platform team, I felt I had a lot of the tools and techniques to succeed. But I went from being on primarily front-end focused teams to being firmly planted in the middle of both front and backend (as much as you can be for javascript applications).

I also needed to be a leader for my team — I helped guide the product to where it needed to go to support the business; supported my teammates when they needed guidance; worked closely with other teams to ensure we had everything we needed to succeed and asked the right questions to help move things along. I learned so much and have to give a ton of credit to my teammates.

Now, as a solutions architect for web, I’m looking to take a lot of what has worked well for the Web Platform team and try to scale that to our other web applications and teams.

  • What kind of support was most effective as you transitioned into your current role?

I was given the freedom to make mistakes and figure things out. My manager has pushed me to think about solutions and tackle problems in ways I hadn’t considered before. It feels a little like a super power now — when I hear people talk, I’m more aware of the different ways we can accomplish things.

  • What surprised you as you started your current role?

Working across teams involves a lot of relationship building and managing those relationships. Technical people are some of the most passionate and opinionated people when it comes to their craft. Unfortunately, we can’t always implement all the ideas put forward. There are a lot of factors that go into picking one technical solution over another and answering the “what” and “why” is fundamental in my approach to helping developers understand how decisions are made. This approach builds trust and mutual respect.

  • Which is more important for the technical leadership role you hold — technical breadth or depth?

Things change so frequently in the tech space. If you decide to focus and put all your effort into one thing, you’ll likely miss out on a whole bunch of other stuff! I think breadth is important, so you’re able to consider all options and factors when making decisions. Depth is also important because you need to be able to speak about things in your domain — luckily, I work with some of the smartest developers around who can help with the depth piece, which gives me time to focus on breadth.

  • How do you lead technically if you do not manage any people as direct reports?

I don’t think leading technically necessarily means just leading technical people. Leading people is one part of it but I’m also leading the evolution of our web products. I find it’s important to bring people on the journey with you. You have to tell the story of where we are and where we’re going. The “what” and the “why” are important — helping people understand why a decision was made helps get the buy-in you need from technical teams. I think it’s also important to share past failures — I’m able to help teams learn from what I’ve learned.

  • What advice would you give to your colleagues who are considering moving into a technical leadership role?

Communication is key. You’ll have a broader audience — people who are very technical, somewhat technical and not technical at all. Be prepared to explain concepts and ideas to those different audiences. If you’re talking about if statements and while loops, think about how that will be received by your non-technical audience.

No one expects you to have all the answers to everything — don’t put pressure on yourself to live up to that false expectation. The expectation is on finding the answer and you’ll have a team of people — managers, engineers, leadership — who are there to support you.

  • What was the best career advice you have ever received?

Coming into the role, I had this expectation of myself that I had to know all the answers to everything. I had to be prepared in case someone came to me asking for an opinion or for some direction on something. I stressed myself out. I was being asked about things I hadn’t heard of and felt inadequate because I didn’t have the answers.

It wasn’t until someone asking me about one of our internal systems said “… I don’t need an answer now as I know you’re still getting acquainted with everything” that it clicked. I don’t even know if they knew that those few words they said would play such a pivotal point in how I saw myself and how others saw me.

From then on, I’ve been honest with myself about what I know and don’t know. I’ve communicated what I know and don’t know when talking to others. Do I have the answers to everything? Nope! But you can be sure that I’ll find them!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store