How switching to product-based work changed our corporate culture (for the better)

Change for the Canadian (Photo By: Richard Loa)

Today I’d like to share a story of cultural change. It’s about the iterations of failure CBC’s Digital Operations department (or DigiOps) had to go through to get to where we are now.

This is also a personal story about why I’ve stayed with the CBC for as long as I have, first as a web developer and now, nine years later, as a product owner.

Ask anyone who works in tech — it is not the norm to stay with the same employer for this long.

To start, I’m going tell you a bit about how we work.

The Department Mission

In DigiOps, our mission is to digitally distribute content produced by the CBC — news stories and podcasts and television programs — in ways that are both relevant and timely to Canadians from coast to coast to coast. This is my elevator pitch for the department:

We build digital experiences through mediums like PCs, tablets, mobile phones, Apple TVs, Chromecasts, Apple Watches and VR devices, which allows us to deliver content to Canadians in addition to analog mediums like radio and television.

This mission has not always been clear to me. Our team used to operate like an internal marketing agency — the client was always right, and there were times when it felt like our mission was to appease internal stakeholders.

Working like this was challenging. It felt too inward-facing and disconnected from the bigger picture: building digital experiences for Canadians.

Fast-forward to 2013, when the DigiOps leadership team made a decision: We were going to change the way we work, from a project-based focus to a product-based focus.

At the time, I really didn’t know what that meant, and that made me feel really uncomfortable.

A few years in, this is how I’ve come to understand the difference between these two ways of organizing work:

Project-Based Work (aka Waterfall)

Waterfalls make it hard to go back a step or two (Photo By: Richard Loa)

1. An internal stakeholder needs a digital product. For example, the Sports Department needs a website for the Olympics.
2. A project team is assembled from pools of people that perform functional roles: Project Manager, Designer, Developer, Quality Controller.
3. The team talks to the stakeholder at the beginning of the project and gathers the needs and requirements for the product.
4. The project teams builds the product. After months of work, the project team thinks they have satisfied all the needs and requirements of the internal stakeholder.
5. The project team reveals what they’ve built to the internal stakeholder. The internal stakeholder reacts: “But that’s not what I wanted!”
6. The project team repeats steps 3–5 until the stakeholder is satisfied.
7. When the project is “completed,” it goes live and is shared with the audience.
8. The project team disbands and goes to work on a completely new project with different team members.

Product-Based Work (aka Agile)

1. Cross-functional product teams are assembled, made up of a Product Owner, Designer(s), Developers, Quality Controller and an Agile Team Lead. Each team collaboratively fulfills a mission.
2. The mission is centred around continuous improvement — it doesn’t have a beginning or an end. An example of a team mission could be: We build the best website experience for Canadians who visit CBC.ca.
3. A product team builds and releases something slightly embarrassing to the public. This is known as the minimum viable product.
4. A product team tests a hypothesis about the next improvement by measuring and learning from Canadians’ behaviours on each iteration. Over time, the product gets better and better.

That’s a quick brief on how project-based versus product-based work is organized. Now that you have got some context, let’s get to the part I really want to share with you. The story of cultural change.

Today we are Agile! Now go!

In early 2013, I was having a really hard time adapting to this change.

Be okay with confusion while in a state of transition. (Photo By: Richard Loa)

We were working Agile — performing daily stand-ups, bi-weekly backlog grooming, planning and retrospective sessions — but it felt to me like nothing had really changed. The team was not on board. We were going through the motions of product-based work but we were still stuck in a project-based mindset.

Then, in late 2014, product teams started defining their missions. And that’s when I noticed a shift in both my own mindset and those of my colleagues.

If I could describe the change in one sentence, it would be:

It’s not about being “Agile” — it’s about helping people get results.

More specifically, the missions were bringing new meaning and usefulness to the product teams because we were asking ourselves one question:

What is the next thing we change to make our digital product offering better for Canadians?

Though we had come a long way, there was still a lot of work to do. Defining a mission for each product team was not enough.

Fail, learn and iterate

The next major struggle I faced in early 2014 came up around accountability and our willingness to fail.

In project-based work, a team typically gets one shot to complete a large chunk of work — that’s a lot of pressure to get it right! On top of that, if the project was considered a failure, the accountability fell mostly on the shoulders of the project manager. I saw the project manager as the person who was really committed, while the rest of the project team was simply involved.

In a team you are all accountable. (Photo By: Richard Loa)

In product-based work, the entire team is accountable. We’re all committed — eeek! When we first made the switch to product-based work, we imagined that teams would only get one shot at succeeding or failing — remember, all we knew was project-based work. We didn’t feel safe to fail and iterate.

This mentality of not feeling safe to fail and learn is ingrained in us at an early age. Looking back to my time in elementary school, high school and university, I only ever got one crack at completing an assignment or project. It was do or die.

Then in mid-2015, we held CBC Digital Day, an event for employees to discuss and understand our digital strategy. When Director of CBC Digital Richard Kanee shared his plan, there was one small part of it that stuck out at me:

In year two, we are going to learn and experiment because we know we are not going get it right at our first crack.

I was blown away by that statement, and I thought it was awesome! Hearing somebody in upper management set the stage up for product teams to fail, learn and iterate was just the thing I needed to get on board with a team mission and to take on the accountability that came with it.

Making Data-Driven Decisions

The idea of making decisions based on data seems logical. When I make a decision I like to be informed and have rationale behind the decision.

In the end we all move faster using data to make decisions. (Photo By: Richard Loa)

While data-driven decision making may be logical, building a product and using data to inform decisions had not always been that straightforward. Project-based work set a precedent that internal stakeholders were free to make decisions based on gut feeling or personal experience.

Sometimes, it felt like driving without a map or GPS and taking turns whenever the driver felt like it. Or, like the driver would buy the GPS and install it in the car but then would never look at it until hours of driving had passed.

When working in a project-based way, we only had the opportunity to receive audience feedback after about a year of work. This made it really hard for us to know if we were building something that would resonate with Canadians.

With the adoption of a product-based work style, this began to change. DigiOps and internal stakeholders renegotiated the process, and final product decisions became the domain of product-builders.

This shift committed us more fully to the Agile methodology: product teams started the cycle of build, measure and learn. Nowadays, there are six key steps that we are doing over and over again:

1. Have a hypothesis
2. Define a test and goals
3. Build a new feature
4. Collect data to inform the test
5. Analyze and learn
6. Repeat steps 1–5

Learnings From The Journey

Create the environment to push through the noise. (Photo By: Richard Loa)

In summary, there are three major learnings I can share:

1. Product teams without a mission just go through the motions.
2. Ownership and accountability come from creating a safe environment to build, measure and learn.
3. In order to learn, we need to measure what we build. That meant we needed to change how we were making decisions around building products for Canadians.

Hopefully I’ve given you a glance into what it used to be like working at the CBC in Digital Operations, and what it‘s like now. It has been quite a journey for me. DigiOps continues to be a place of collaboration, improvement and learning through iteration.

Being in the tech industry and working at one place for nine years is quite unusual. When I tell people how long I’ve worked at the CBC they always say something like, “Wow! That’s a really long time…What has kept you motivated to staying there for so long?”

That’s pretty easy to answer.

• The people I work with are some of the most talented minds in Canada.
• The opportunity to build products for Canadians in a mandate-oriented institution.
• I have a lot of fun at work!

Oh and did I mention that we are hiring? Yup in 2017–2018 the Digital Operations department is going to grow by 40 heads. Let us know if you are interested in working with us.