Tag Archives: retrospective

Ed Catmull’s “Creativity Inc.” and one of the best work things I’ve ever done

41xs4vbcTPLI’m not alone in my love for the book Creativity Inc., written by Pixar President Ed Catmull. Others have called it “the best business book ever written” (Forbes) and “the most practical and deep book ever written by a practitioner on the topic of innovation” (Harvard Business School). I read the book several years ago and have returned to it lots of times, determined to figure out how to leverage more and more of Catmull’s thinking to make myself and my team not only more creative, but better in lots of ways. (I won’t, however, be incorporating all of Catmull’s past business practices.)

Of all the great ideas in the book, the one that struck me most immediately went I read it was something Catmull calls Notes Day, a day when all of Pixar’s projects stop, and all employees share their thoughts on how the company operates – and how they can do it more effectively. The need for this arose from what Catmull describes as an environment in which “more and more people had begun to feel that it was either not safe or not welcome to offer differing ideas.” He goes on:

Increasingly, we sensed that our people, having enjoyed years of success, were under a great deal of pressure not to fail […] As a company, our determination to avoid disappointments was also causing us to shy away from risk […] One of our greatest values – that solutions could come from anyone and that everyone should feel free to weigh in – was slowly being subverted under our watchful eyes. And only we could correct it. (p. 279 – 280)

Recently, I had the good fortune to attend a conference where Continuous Delivery expert Jez Humble was speaking. Jez said that, while we tend to copy the things successful groups are doing, it’s not the things themselves, but a team’s ability to problem solve that creates real change within an organization. When Catmull looked around, he saw teams of people who were suddenly afraid to problem solve. And so Notes Day was born.

I recognized my own team and situation in Catmull’s words. We were an organization that valued transparency, debate, creativity, and continuous improvement, and we’d incorporated lots of best practices into our normal operating rhythms, including daily standup meetings for each product team and retrospectives after each release. Still, it was inevitable that we’d have to find ways to revisit and reinforce these ideals – to get people talking about the things that weren’t working well. We were widely recognized throughout the organization as high performers, and nobody wanted to mess that up. To make matters worse, although I spent lots of my days working at a table with my team, I was still missing out on too many important things. People tend to “protect” the boss.

When I read about Notes Day, I wondered if it was something that could work for my team. When I approached key leaders in my area, they loved the idea – we hadn’t yet tried a Retrospective of Retrospectives with our team, but since we were all very comfortable with post-release retros, this felt like a great way to frame up the activity. In a Retrospective of Retrospectives, teams come together to share their successes and opportunities, focusing on how to improve performance across the entire team or overall program. It was exactly what I’d been looking for.

My cohorts and I started to frame up an offsite for our team (about 65 people at the time, including developers, product managers, system architects, BAs, QA analysts, project managers, and UX engineers), knowing that if we did it right, we’d both gather critically important information and give the team a shot in the arm. What we came up with was a two-day conference of sorts. It turned out to be one of the best work things I’ve ever done.

One of our two days was spent recapping the year, discussing new project ideas, hosting guest speakers, presenting “Lightning Talks” (5 minute presentations on anything the presenter chose), and participating in a Q&A session with our CEO. The goal of these sessions was to celebrate our successes, tie our work to company goals, learn new things, laugh together, and get pumped up for the new year. Our other day was dedicated to the Retrospective of Retrospectives.

The Retrospective of Retrospectives

Preparation for the Retrospective of Retrospectives started weeks before the event itself, with some pre-work – we asked each team member to bring a list of things that went well throughout the year and things that didn’t. On the day itself, we split the team into pre-determined groups of 8-10 people, ensuring that each functional area (devs, product managers, etc.) would be represented and that none of them would dominate the conversation. Then we asked each group to conduct their own, smaller retrospective, identifying successes and opportunities, voting on which opportunities were most pressing, and coming up with potential solutions. Finally, these solutions were presented to the larger group, and team members signed up for the opportunities they were most passionate about. We were careful not to gloss over the hard things – in order to be successful, this needed to be a warts-and-all conversation. We were looking for problems to solve and ways to be better. Over the course of the next year, each group was responsible for updating the entire team on their progress.

After just two annual meetings, we’re still tweaking the formula for both the retro and the followup. For the retro, the challenges include creating a structure that allows for cross-team sharing and finding the right areas of focus. For the follow up, the challenges include trying to find the right balance between holding people accountable and giving them the freedom to change course as new, bigger opportunities arise.

I know we’ll be refining our Retrospective of Retrospectives this year – our team has grown, and we need to find new ways to engage and empower people across multiple capabilities. But it’s only September, and the team is already looking forward to the event. We’re gathering our thoughts, reflecting on this past year’s successes and challenges, refining our roadmaps, and lining up guest speakers. Best of all, we’re getting ready to have hard discussions about what’s not working well and how we can improve as a team, warts-and-all.

I can’t wait.

 

8 reasons my team is great (and keeps getting better)

quote-you-cannot-make-an-omelette-without-breaking-eggs-proverbs-309526

My current eCommerce team is among the best I’ve ever worked with. In the past year, we’ve launched four mobile apps, re-platformed three eCommerce sites without any downtime at all, made major strides towards continuous deployment, and much, much more. (Even if you don’t know what any of these things are, you’re impressed by now, right?) Much has been written about building great teams, of course, and this is in no way meant to be definitive. Still, I want to share a few of the reasons my team has succeed so far (in no particular order), and why we’ll continue to get better:

1: Everyone on the team is a business owner

It would be an exaggeration to say that everyone on the team is motivated by our KPIs in the same way, or that each developer, user experience engineer, and Product Owner feels the same passion for driving revenue. Still, we do a lot of work to make sure each person on our team understands what drives our business, and the items on our product roadmap can come from any person or team. We understand both what we have to do and why.

2: We define our own priorities

Continuing on the above theme, our product roadmap is largely driven by the team. Because we understand what drives the business, we have the flexibility to work on the projects that are most impactful, in the order that makes the most sense. There are times we have to justify our priorities – and we review them with our senior executives each month – but we own the roadmap, no question about it.

3: We like to solve hard problems

Being intellectually curious is a big deal. Our team is smart, and intensely focused when it comes to finding sustainable solutions to big, hairy business and/or technical problems. Sometimes this leads to frustration – we don’t always have time to do things right, and we all despise increasing technical debt – but, by and large, our team strives to do things right, and we’re up for any challenge that comes our way.

4: We persist!

We like solving hard problems, and we don’t give up. When we can’t figure something out, we keep at it. Sometimes we wrestle with a problem for weeks – or months – before finding the answer we were looking for. Sometimes we need to try a lot of things before getting something right.

5: Our leaders push us in the right ways

When we need a kick in the pants, we get one. When we need some space, we get that too. From top to bottom, our company and team leaders understand that empowering the teams to do our best work is critical to our success.

6: We test and measure everything we do

Measuring allows everyone to see where we meet expectations and where we don’t. New functionality is AB tested until it “wins” and we’re confident we haven’t introduced new problems into the system. We’ve got dedicated testing and analytics teams, and our Agile development teams wouldn’t even think of introducing new functionality without their involvement. Of course, we still make mistakes, but when we do…

7: We learn from our mistakes

You can’t make an omelette without breaking a few eggs. Building and running our own web platform is hard, and despite all the great testing and measuring we do, mistakes are inevitable. Because we encourage continuous improvement and innovation, we also favor blameless post-mortems and retrospectives during and after all projects. These allow us to truly understand where we’re most effective and where we still have opportunity to improve. We’re going to make mistakes, but we really don’t want to make the same ones twice.

8: We genuinely like each other

Who wants to spend all week, every week, with people they don’t know or like? Not me. Work is a big part of our lives, but it’s not everything. People go on vacations, have babies, experience loss, and root for baseball teams (they often do those last two at the same time). And people who like each other are there for each other when they need support – in their work and in their lives.

We’re not perfect

If some of this sounds a bit aspirational, it is. My team is far from perfect, and we don’t always get these things right. We get crabby, and frustrated, and annoyed by each other. We argue, we have egos, and we break more things than we’d like. Sometimes we focus on the wrong things, and we’ve been accused of moving too fast. But the foundation of our team is strong, and our core philosophies don’t change.

Do any of these ideas resonate with you? Are you part of a high performing team? If so, what makes your team great? If not, how can you get there? I’d love to hear from you.