Bringing Adventure Teams to Life

55
Bringing Moz’s Adventure Teams to Life Adam Feldstein | November 2013
  • date post

    17-Oct-2014
  • Category

    Technology

  • view

    8.349
  • download

    1

description

Moz's internal slide deck on Adventure Teams and how they will change our internal processes.

Transcript of Bringing Adventure Teams to Life

Page 1: Bringing Adventure Teams to Life

Bringing Moz’s

Adventure Teams to Life

Adam Feldstein | November 2013

Page 2: Bringing Adventure Teams to Life

Topics:1. Problems we’re trying to solve with Adventure Teams

2. Proposal for a First Iteration of Adventure Teams

3. What Adventure Teams are Not

4. Starting the Rollout

5. Answers to not-yet-FAQs

Page 3: Bringing Adventure Teams to Life

Problems We’re Trying to

Solve with Adventure Teams

Page 4: Bringing Adventure Teams to Life

The 5 Problems ATs Want to Solve

#1: Cross Team Collaboration

#3: Clarity & Accountability

#2: Internal & External Transparency

#4: Consistency of High Level Process

#5: Continue to Enable Flexible Working Styles for Different People

Page 5: Bringing Adventure Teams to Life

Cross-Team Collaboration

How It Works Today

Page 6: Bringing Adventure Teams to Life

Cross-Team Collaboration

Product Team: Designs What to Build

Eng & TPM Teams: Build It

Marketing Team: Promotes It

Product Marketing Team: Measures,

Reports, Tries to Increase Engagement

Interlopers from All

Teams: Jump in and out of

process willy-nilly

Tech Ops, Engineering, & Help Teams: Support It

Page 7: Bringing Adventure Teams to Life

Cross-Team Collaboration

How It Could Work In the Future

Page 8: Bringing Adventure Teams to Life

Cross-Team Collaboration

Product Rep Eng & TPM Reps Marketing Rep

Product Marketing Rep

Together: These individuals identify the problems

they’re solving, the customers they’re targeting, design

the solution, and loop each other in on the planning,

progress, launch, iterations, and metrics.

Help Rep Tech Ops Rep

We Must Strike the Right Balance Between Missing Critical Input on a Project & Too Many Cooks in the Kitchen

Page 9: Bringing Adventure Teams to Life

"The most productive time in my career was on a

small team where everyone had complete respect for

the others. We all had strong opinions. Design

sessions in front of a whiteboard could be heated, but

they were engaging and rewarding. We'd sometimes

spend an entire day hashing out a problem. When we

finished, we almost always had a solution that was

better than any single team member could have

conceived on their own. Everyone left those sessions

happy with the solution. I miss that.”

- Marc Mims

Page 10: Bringing Adventure Teams to Life

"...my ideal medium-scale company functions as a giant,

nearly-flat bag of small teams of various flavors. One flavor

of team works directly for our (external) users: they build

services or features of services that generate revenue.

Another flavor works for internal users (other teams): they

create infrastructure to make serving our ultimate end users

as easy and pleasant as possible. Teams would have a max

size (not a uniform largest size, but a limit set by each team,

decided perhaps by perceived need, budget considerations,

etc.) Individual contributors are free to occasionally

request team transfers; open slots are filled on a first-come

first-served basis.“

–Thomas McElroy

Page 11: Bringing Adventure Teams to Life

"Communication within my team was always easy, but

communication with other team has been more difficult. It's

never bad and it's mostly because we all kind of work along

thinking everyone is on the same page, I think. But I would

like to see better communication within the engineering team

as well as from product and engineering. I think the teams

are fairly separated sometimes and if both the engineers and

product manager aren't proactively keeping the

communication channels open, there can be

miscommunications, lack of clarity on product design,

expectations and future road map plans.“

-Carin Overturf

Page 12: Bringing Adventure Teams to Life

Internal & External Transparency

How It Works Today

Page 13: Bringing Adventure Teams to Life

Internal & External Transparency

Email Updates: These have varying

degrees of comprehensiveness and clarity,

and are sent by some teams but not others.

Some go to allstaff, some to smaller

groups, none are public.

PMS Meeting: While it covers only

engineering, this meeting gives regular

status updates, and those who attend can

get much more detail. Communication is

then relayed to other teams by

representatives who attend. There’s no

public accessibility.

Page 14: Bringing Adventure Teams to Life

Internal & External Transparency

How It Could Work in the Future

Page 15: Bringing Adventure Teams to Life

Internal & External Transparency

Email Updates: Internal to the adventure teams on specific topics

that need discussion/decisions/input, external to allstaff as major

milestones are accomplished/planned.

PMS Meeting: Amy and her team have some plans on how to

improve these and avoid some telephone game issues.

Public Webpage: Showing the project’s goals, team members,

progress, and upcoming plans for anyone inside or outside of Moz

to see.

Page 16: Bringing Adventure Teams to Life

Clarity & Accountability

What’s Been Committed To? Hard for anyone not on the team to

discover what any given team in planning, and what they’ve agreed to

accomplish in the next X weeks.

Challenges that Exist Today:

How Has a Team Performed Historically to Commitments? No one

at Moz currently tracks historical performance against commitments in

a structured, transparent way. This makes it hard to know if we’re

regularly over/under-committing, and makes it hard to improve at taking

on the right amounts.

Planning: Without clarity into historical performance or current

commitments, planning is hard for many teams (including eteam).

Page 17: Bringing Adventure Teams to Life

Regarding Accountability

#1: People can only be accountable for

tasks fully under their control.

#2: Only those who will be doing the

work should craft the timetables for

delivery.

#3: For many functions, setting a

completion date is foolish (software in

particular). Instead, let’s set delivery

expectations for very small pieces of

the final project, then iteratively

measure progress and deadline

feasibility.

Page 18: Bringing Adventure Teams to Life

Consistency of (High-Level) Process Across Moz

How It Works Today

How It Could Work in the Future

Product Eng & TPM Marketing

Product Marketing Help Tech Ops

No shared process: this

makes it hard for anyone to

move across teams, understand

how another team works, or fit

in smoothly with their process.

Adventure Teams: While every team will maintain lots of unique attributes

about how they work, tools, style, process of details, etc. there will be a

similar framework that makes anyone at Moz capable of understanding

others’ work & assisting effectively if/when needed.

Page 19: Bringing Adventure Teams to Life

Enabling Flexibility of Working Styles

This Works Today: And it must continue to work with the new

processes we adopt.

The Future: We need a structure that creates consistency of

process and enables us to scale without having hundreds of tiny,

independent companies inside a larger shell. But, we can’t do it at

the price of authenticity. Whatever Adventure Teams become, they

must have enough flexibility to let people and teams work how they

work best. Thus, ATs, as envisioned here, will not try to get into the

guts of how teams or individuals get their work done.

Page 20: Bringing Adventure Teams to Life

A Proposal for the First Iteration

of Adventure Teams

Page 21: Bringing Adventure Teams to Life

The 5 Elements of an Adventure Team

#1: A Project Tied to Goals & Metrics

#3: Assembling the Right Team

#2: Three Kinds of Adventurers

#4: Making Progress Transparent

#5: Kickoff, Sprints, & Shared Commitments

Page 22: Bringing Adventure Teams to Life

A Project Tied to Goals & Metrics

Strategic Initiative

Tied to Moz’s core purpose, these only change every 1-

3 years (usually upon completion).

Adventure Team X

Working on project X tied to

the strategic initiative

Adventure Team Y

Working on project Y tied to

the strategic initiative

Goal

Feature-centric to solve a

customer problem.

Goal

Marketing-centric to spread the

word about the problem & our

solution.

Page 23: Bringing Adventure Teams to Life

A Project Tied to Goals & Metrics

Goal

Feature-centric to solve a

customer problem.

Goal

Marketing-centric to spread the

word about the problem & our

solution.

Measurable Results

Amplification, engagement,

traffic, & recognition metrics from

analytics, social data, content

analysis, etc.

Measurable Results

Completion of launch in

timely fashion, usage,

engagement, recency,

frequency, retention, and

amplification metrics. Further

launch metrics around

iterations to improve the

feature.

Page 24: Bringing Adventure Teams to Life

An Example of This in Action

Strategic Initiative

Broaden Moz’s reach beyond the pure SEO world

Moz Analytics Social Team

Launch regular new features &

refinements in MA’s social tab.

Content Team

Launch content that appeals

to/attracts social marketers.

Goal: Achieve parity w/ social

analytics competitors & increase

use of MA social tab.

Goal: Attract new social-focused

marketers to Moz’s website

content.

Measurable Results: Grow

weekly use of social tab from

20% of users to 40% in 6 mos.

Measurable Results: 100K

social marketers registered on

Moz over the next 6 months.

Page 25: Bringing Adventure Teams to Life

Three Kinds of Adventurers

NOTE: These are just examples of potential adventurers.

Anyone, from any team, could be a full-time, part-time, or

consultant depending on the project.

Page 26: Bringing Adventure Teams to Life

Assembling the Right Team

An Adventure Team should contain:• As many full-time adventurers as are critical to the completion of the

goals/projects.

• Part-time and consultant adventurers as needed to add critical skills, input, or subject-matter expertise (ATs are not about forcing every project to have a representative from every team – some teams will be almost entirely made up of adventurers from one functional area and that’s OK).

• An executive sponsor who can assist in getting budget, people, approvals, and whatever else the team may need.

• No unnecessary folks. It’s always possible to realize part-way through a project that a new team member is important and invite them to be a consultant (or part-time). Let’s aim for minimal teams to start .

Page 27: Bringing Adventure Teams to Life

Making Progress Transparent

To Your Team Members: Your co-adventurers should know, in detail, how you’re

progressing against commitments and what might be holding you back currently

(especially if they can help). An email alias for each Adventure Team and some form of

internal communication system (likely 15Five + standups+ other tools suggested by Amy’s

crew on a per team basis) can help.

To Other Teams: Anyone at

Moz should be able to quickly

and easily see what any

Adventure Team is working on,

and how they’re progressing

against commitments, goals, &

measurable results.

To the Moz Community: Historically (pre-Moz

Analytics), we used to write about every Moz

project– sometimes in a roadmap format, and often

via blog posts. We want to return to that level of

transparency both because it fits with our core

values and because it’s a great way to keep our

customers engaged. But, we want to create better

structure, so our community knows where they can

find information and doesn’t need to dig through old

posts.

Page 28: Bringing Adventure Teams to Life

Example of this in Action:

NOTE: This is just me making stuff up (none of

these people are actually on this team, nor does it

even exist).

Page 29: Bringing Adventure Teams to Life

Example of this in Action:

I’m sure our design/UX team can

work to make something far sexier to

convey this data in a compelling way.

Also, this may not be the format or

precise data every team wants to

share – just an early concept. ATs

should own the details of what to

publish.

Page 30: Bringing Adventure Teams to Life

Kickoff, Sprints, & Shared Commitments

Every Adventure Team will have some shared process:• A kickoff where the entire team (FTs, PTs, & Consultants) gathers to run

through the purpose, goals, and plans initial work/tools/schedules/etc.

• Intervals of a regular length where work is committed to by individuals & as a team, then continuously measured/refined.

• Interval reports that are published in such a way that anyone can see what the team’s been working on.

• Measurable results tied to the goals, made visible to everyone on the team and in the company (and possibly, for some projects, externally as well).

• Full-Time AT members will generally sit together at the new Mozplex (those on multiple ATs will work w/ their managers/teams/Team Happy to figure out seating)

Page 31: Bringing Adventure Teams to Life

What Adventure Teams

are Not

Page 32: Bringing Adventure Teams to Life

NOT: A Dramatic Departure from What Works Today

Page 33: Bringing Adventure Teams to Life

NOT: A One-Size-Fits-All Solution for How We Work

Page 34: Bringing Adventure Teams to Life

NOT: A Change to the Current Reporting Structure

Page 35: Bringing Adventure Teams to Life

NOT: A Panacea that Will Solve Every Problem

Page 36: Bringing Adventure Teams to Life

NOT: Going to Be Perfect Right from the Start

Unlike this bottle (though, to be fair, it

took 16 years to get that way).

Page 37: Bringing Adventure Teams to Life

Starting the Rollout of

Adventure Teams

Page 38: Bringing Adventure Teams to Life

Many Teams are Already in Adventure Format

We just need to make them explicit!

Mozscape has representatives from many teams, works in sprints, has goals tied to metrics, and regularly tracks progress

Fresh Web Explorer had an AT-style kickoff, has representatives from many teams, works in sprints, has goals tied to metrics, and regularly tracks progress

Moz Local had an AT-style kickoff, has representatives from many teams, works in sprints, has goals tied to metrics, and regularly tracks progress

Inbound Engineering has multiple projects with reps from different teams, works in sprints, has goals tied to (primarily launch) metrics, and tracks progress

Content (inside marketing) functions a lot like an Adventure Team, lacking only the express sprints & explicit cross-team representation (though some of it already exists)

Page 39: Bringing Adventure Teams to Life

Stage 1: Making Current ATs More Explicit

Who: Define the current adventure teams, create the public pages, email aliases (if they don’t already exist), and start the AT reporting system.

What: Lay out the explicit goals and measurable results for each AT.

Share: Get ATs publicized to our community through pages they can follow.

Avoid: Redundancy or overlap in work/reporting. ATs should create minimal overhead.

Page 40: Bringing Adventure Teams to Life

Stage 2: Any Team that Wants to

Volunteer Can Adopt the Adventure Format

We may be able to start this right now, or we can choose to test with a few ATs first.

Page 41: Bringing Adventure Teams to Life

Stage 3: Learn & Refine Based on Feedback

There will undoubtedly be some challenges in starting ATs. Change is hard, and I know there will be resistance until we get it running more smoothly.

Page 42: Bringing Adventure Teams to Life

January is the Current Target for a More

Comprehensive Rollout of Adventure Teams

Page 43: Bringing Adventure Teams to Life

Answers to Not-Yet-Frequently

Asked Questions

Page 44: Bringing Adventure Teams to Life

Who Gets to Be on an Adventure Team?

Today: Anyone who’s needed on the initial teams that form (or volunteer) to test the Adventure Team format.

January: Everyone (possibly with a few exceptions) who works in product, TPM, & engineering, and many who are in marketing and operations, too.

The Future: Hopefully, if ATs work the way we’re envisioning, everyone at the company will likely participate on 1+ Adventure Team. The basic concept is designed to be an architecture we can all use to make Moz more scalable, more transparent, and more familiar.

Page 45: Bringing Adventure Teams to Life

How is a New Adventure Team Created?

Today: Eteam sponsors will work with the functional teams to create

an initial set, and anyone who’d like to volunteer to make their current

projects/work/team follow AT format can do so.

The Future: We hope to build a process whereby a group of

individuals can volunteer to create their own ATs.

Page 46: Bringing Adventure Teams to Life

Is Every Team an Adventure Team?

Yes! If They Want: Anyone who’s needed on the initial teams that form (or volunteer) to test the Adventure Team format.

No. You Don’t Have To Now: Unless your team is specifically part of the Adventure Team kickoff now, you don’t need to follow the AT format. We do hope to roll this out universally at Moz eventually, though.

But How Could a Team Like Finance, Help or Bizdev be an AT? ATs don’t have to be tied to just a feature we build in our software. Any group of people can conceivably follow the format for ATs – adopt goals, measurable results, have a kickoff, define intervals, report on them publicly, etc. In fact, the hope is that everyone, one day, will, and ATs will simply be how things get done at Moz.

Page 47: Bringing Adventure Teams to Life

How Many People Are Required to Create an AT?

Technically, Just One: There may indeed be ongoing projects that

need only a single person’s contributions (though this will be very rare,

and probably only happen early in a project – like Dr. Pete kicking off

Mozcast). Most of the time, it’s at least 2, and often more, but the idea

behind Adventure Teams is not to force cross-department collaboration

if it’s not needed nor to make a team where a single person can do the

work. The idea is to craft a goal, a way to measure it, a way to

internally + externally share, and show progress all the way through to

completion and iteration.

Page 48: Bringing Adventure Teams to Life

Who Makes Decisions on Adventure Teams?

Ideally, the Team Themselves: Just like how today, most decisions/debates/discussions are hashed out between the people working on the problem, in an AT, it should work exactly the same way. The email aliases for teams can be used for discussion, or two relevant parties can chat in person, or whatever works best. ATs are not meant to provide dispute resolution mechanisms – that’s for teams to decide.

If We Can’t Agree: Again, just like we do today, we’ll escalate to the relevant eteam sponsor of the AT.

Page 49: Bringing Adventure Teams to Life

How Do Performance Reviews Work w/ ATs?

Just Like They Do Today! ATs shouldn’t interfere with our current semi-annual review process, or with our weekly 1:1s, or with 15Five. In fact, today, we all work on multiple projects, some of which are more/less visible to our managers, and it works out pretty well. There are no plans to change this with ATs, though the AT format’s measurable results may provide an additional data point, and your fellow AT members may be good candidates for 360 evaluations.

Page 50: Bringing Adventure Teams to Life

How Do ATs Do Sprint Planning, Choose Tools, Determine Division of Work, etc?

I’m gonna stop you right there. ATs are NOT designed to dictate,

force, or even encourage a specific methodology for this stuff. That’s

the job of the teams and the (T)PMs to determine the right way to go

about getting work done.

Page 51: Bringing Adventure Teams to Life

How Much Interval Detail Do ATs Need to Provide on their Public Pages?

Enough So That Someone External Can Get a Good Grasp on What

the Team’s Doing. But not necessarily more. It’s great if teams want to

be even more transparent about their commitments for each interval,

and their measurable results, but that stuff doesn’t always need to go

on the public page.

Minimum Great! Overkill

Example from Fresh Web Explorer Team:

This interval, we’re testing some methods for a larger index.

This interval, we’ve committed to adding the news feeds from 250K sites to the index while maintaining performance. This will be visible in FWE and Alerts for subscribers the week of 9/30.

Here’s what every person on the team is doing exactly, and you should expect that we’ll meet 100% of these targets on this precise day.

Page 52: Bringing Adventure Teams to Life

When Do We Disband an Adventure Team?

When the mission is accomplished, or when other things take clear priority (which might result in a temporary

pause & restart)

Page 53: Bringing Adventure Teams to Life

How Will This Change My Day-to-Day Work at Moz?

Full-Time Adventurers

Part-Time Adventurers

Consultant Adventurers

If you already work full-time on projects/ products, ATs won’t change much, though you’ll likely have more cross-team participation in your email aliases, in sprint/ interval meetings, and in kickoffs. You may also be asked (or volunteer) to be a consultant to projects where you have expertise or passion.

Your work may be more about context-switching in a formal way than the informal and non-outlined methods we use today. You’ll also be asked to be part of the definition, kickoff, and interval planning of those adventures, rather than simply being asked to contribute work alone.

As you advise other projects and teams, your input will be critical to helping make sure there’s shared knowledge, and shared process between teams without reinventing wheels or missing key communication.

For most Mozzers, this will put some structure on

things we do today, but won’t massively change our

ways.

Page 54: Bringing Adventure Teams to Life

Q+AAsk Me Anything!

Page 55: Bringing Adventure Teams to Life

Adam Feldstein | November 2013