View
8.351
Download
1
Embed Size (px)
DESCRIPTION
Moz's internal slide deck on Adventure Teams and how they will change our internal processes.
Citation preview
Bringing Moz’s
Adventure Teams to Life
Adam Feldstein | November 2013
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
Problems We’re Trying to
Solve with Adventure Teams
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
Cross-Team Collaboration
How It Works Today
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
Cross-Team Collaboration
How It Could Work In the Future
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
"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
"...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
"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
Internal & External Transparency
How It Works Today
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.
Internal & External Transparency
How It Could Work in the Future
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.
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).
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.
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.
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.
A Proposal for the First Iteration
of Adventure Teams
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
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.
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.
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.
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.
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 .
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.
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).
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.
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)
What Adventure Teams
are Not
NOT: A Dramatic Departure from What Works Today
NOT: A One-Size-Fits-All Solution for How We Work
NOT: A Change to the Current Reporting Structure
NOT: A Panacea that Will Solve Every Problem
NOT: Going to Be Perfect Right from the Start
Unlike this bottle (though, to be fair, it
took 16 years to get that way).
Starting the Rollout of
Adventure Teams
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)
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.
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.
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.
January is the Current Target for a More
Comprehensive Rollout of Adventure Teams
Answers to Not-Yet-Frequently
Asked Questions
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
Q+AAsk Me Anything!
Adam Feldstein | November 2013