The 5 Problems ATs Want
to Solve #1: Cross Team Collaboration #2: Internal & External Transparency #3: Clarity & Accountability #4: Consistency of High Level Process #5: Continue to Enable Flexible Working Styles for Different People
Cross-Team Collaboration Product Team: Designs
What to Build Eng & TPM Teams: Build It Marketing Team: Promotes It Interlopers from All Teams: Jump in and out of process willy-nilly Product Marketing Team: Measures, Reports, Tries to Increase Engagement Tech Ops, Engineering, & Help Teams: Support It
Cross-Team Collaboration Product Rep Eng
& TPM Reps Product Marketing Rep Help Rep Marketing Rep Tech Ops 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. 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 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 Public
Webpage: Showing the project’s goals, team members, progress, and upcoming plans for anyone inside or outside of Moz to see. 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.
Clarity & Accountability Challenges that
Exist Today: 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. 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 Product Eng & TPM Product Marketing Help Marketing 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. How It Could Work in the Future 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.
The 5 Elements of an
Adventure Team #1: A Project Tied to Goals & Metrics #2: Three Kinds of Adventurers #3: Assembling the Right Team #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 13 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. 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. 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.
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)
Many Teams are Already in
Adventure Format 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) We just need to make them explicit!
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.
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. Example from Fresh Web Explorer Team: Minimum This interval, we’re testing some methods for a larger index. Great! 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. Overkill 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 fullYour work may be more about As you advise other time on projects/ context-switching in a formal projects and products, ATs won’t way than the informal and nonteams, your input will change much, though outlined methods we use today. be critical to helping you’ll likely have more You’ll also be asked to be part of make sure there’s cross-team the definition, kickoff, and shared knowledge, and participation in your interval planning of those shared process email aliases, in sprint/ adventures, rather than simply between teams without interval meetings, and being asked to contribute work reinventing wheels or in kickoffs. You may alone. missing key also be asked (or communication. volunteer) to be a consultant to projects For most Mozzers, this will put some structure on where you have things we do today, but won’t massively change our expertise or passion. ways.