Principles

Purpose

These principles exists so the studio can produce great work predictably, calmly, and at high quality, without bottlenecks. If something feels unclear, the answer is: follow this doctrine.

What we do

The studio delivers end-to-end execution of edutainment-based marketing experiences:

Inputs that produce the above:

Where we work

Maintain the Production Cycle

The Production Cycle is: Strategy, Blueprint, Build, Repeat.

Strategy, defines the shape of the work, and how it fits into the big picture. Strategy keeps us clear on why we're doing what we're doing, how to know if what we're doing is working, and what to do about it if it isn't.

Blueprint, defines how we think the strategy will look, for this task, right now. A short description, coupled with a simple sketch, enables everyone to "see" the work before it even happens, directing both partners and our team with what we're going to build.

Build, is when we build what we defined in the blueprint. We combine the 'what' we see in the blueprint, with the 'why' from the strategy, with the 'how' from our processes and best practices, to produce excellent work we are proud of.

Repeat, is when we review the build, the blueprint, and the strategy, and define what should happen next as a result of what was built.

Projects over tasks

Partners don't want to-dos completed. They want their projects to succeed.

The difference between the two matters to every single person in the studio.

If there's a webpage to build, we don't just "build it and it's done". We use the Production Cycle to understand its importance and how it serves the project's strategic objective, build it to achieve that, then define the next steps we believe should take place in order to ensure the we continue moving toward that objective.

For example, if a partner requests a newsletter subscribe form, the request isn't really for a newsletter subscribe form. The request is to get people subscribing to their newsletter. The Production Cycle should unearth that goal, and build with that in mind. And once the form is built, that doesn't mean the objective has been achieved: does the form work? Does it send people to a thank-you page? Do they receive a confirmation email? Does the email look great? Do they have good email templates to send the newsletter? Do they need support with the newsletter? These are all natural questions that follow. We should get clear on the shape of the work around the task, and suggest ways to continue moving it forward once it's complete.

This is the difference between a marginalizing web partner who just checks boxes, and a valuable web partner who is invested in the relationship. We must be the latter, in every task, in every project.

Remember our superpower

Why should anyone work with us over anyone else? We have processes, we have great talent, we've been around since 2009, we're dependable, we're good value, but so what? While most teams cannot honestly claim half of these facts (a peek behind the curtain of most teams will reveal chaos and duct tape everywhere), they nevertheless claim to have these things. And so they are not distinctive, they don't stand out, they aren't our superpower.

So what is our superpower? Our mastery of 'edutainment': the ability to combine what people want, with how they enjoy receiving it. Installing feedback loops where we hear from customers, update our documents, and reflect new data into production. Building things that are 'remarkable' (meaning, worth making a remark about), where eyes sparkle, people lean in with enjoyment, and look forward to telling others about what they've found.

If a partner wants boring, ho-hum, average work, without interest in customer data nor making it enjoyable for those they serve… we're operating from a marginalized position, are vulnerable in our relationship, and are not serving the partner as fully as we can. It's our job to pursue the data, and propose builds that will bring our superpowers to bear, for the benefit of everyone the partner serves in the market.

Remember our superpower. Every project should ask, are we remembering our superpower? And everyone in the team should respond with a point of view.

Radiation

Communication is hard. When you know what you're doing, you assume everyone does.

Or that it'll be okay, because they'll know when you're done. It's not okay.

When you're about to start a task, comment that you're about to start the task. As you make progress in a task, comment showing the progress in the task. When you're ready for review, present the work, what you did, and what you want feedback on. When it's done, present the work, write up the finished result, and open a conversation for what should happen next, along with your suggestions, based on your understanding of the project. If a task seems like it might be stalling, comment saying so, and help get it moving again. Over and over, until it moves.

You might feel like you're oversharing. You might feel like you're being redundant, or even a bit annoying. You're not. Everyone around you will be deeply thankful for the clarity you're bringing.

And what about for partners? The same applies there. In each card we're working on, we should update it each time we have an update to share. Not just when it's done, or ready for review. Partners want to know their projects are in good hands, and this rightly calms nerves and quells undue concerns. The updates you share will serve as essential information for project managers as they radiate updates in this way.

We don't stall

'Stalled' is when a project or task is of interest to a partner but, it comes to a halt for some reason, and nobody does anything about it. Except it's still of interest to the partner, or it would have been discarded. So allowing it to stall is us saying to our partner, "We don't care enough about what you care about, to keep it moving when it's not on your watch." That carries more problems than I can list in this doctrine.

So work doesn't stall. Projects move with radiation, or they are actively re-engaged until they get going again, are deliberately paused until a specific date, or are discarded with partner approval.

If something is unclear: PM seeks clarification from either the team or the partner. If unresolved, the team proceeds using the blueprint, processes, or partner direction. Any assumptions are stated clearly as such in Basecamp, so it's always clear what is fact vs assumption. When in doubt, and as a last resort, PM escalates to Adam with specific questions while staying in control of the task, rather than handing it over.

Done vs Done-Done

Completed work is always in one of two states:

'Done' means a task is complete. Perhaps a page was developed, or a design was created. There's a thing to do, and it's been done. 'Done'. But that's not the end of the story, something else must follow the work. The design must be built, the build must be tested. It goes on.

'Done-done' means a task is completed in context: fully integrated, tested, approved by the partner, deployed, with next steps clearly defined so whatever needs to (or may need to) happen next has been made totally clear.

If something is Done-Done, we can tell the partner it is done, close it out, and turn our attention to the strategic objective.

If something is Done, but not Done-Done, we clearly communicate what has been completed, what remains, and the next steps we think are required to reach Done-Done.

What 'done' looks like

These lists are a work in progress, and should be added to as we uncover things that deserve to be here, for the purpose of making everything we produce more methodical, more predictable, more dependable, and calmer to run.

Web page or Product UI changes

Design Systems

How we do tasks

Projects consist mostly of tasks: little bits of work that contribute to the larger project. If you're assigned to a task, that means you're responsible for two things:

  1. The task itself: Whatever the the task is, you're not just assigned, you're responsible.

  2. What happens next: When it's done, something else must happen next. You're responsible for ensuring that next thing commences, and that whoever is responsible for that next thing, takes responsibility for it.

Each task gets a Card, on the project's Card Table. The title represents the work, the notes field describes what must be achieved, and the due-date defines when it will be completed. If the partner is in Basecamp, the comments section is used to communicate with the partner, and to-do lists are created privately (using the same name as the card its associated with) to divvy up assignments and discuss progress. If the partner is not in Basecamp, the comments section is used for the team to communicate internally, with partner communication relayed into the comments section for record.

Cards are assigned to the team members working on them (be it for production or PM), just like the associated to-dos are, so everyone's Basecamp schedule represents each moving part of interest to them.

Every card and to-do always has an assignee and a due-date. Without an assignee, no one is responsible, and Basecamp has no one to alert, thus it risks going forgotten. Without a due-date, there are still no alerts, and it will remain low priority forever. If a card has a client-facing due-date, its internal due-date must be set at least one day prior, so there is room to catch and correct before the deadline is reached.

Tasks do not go past-due. If a due-date will be missed, the reason should always be clearly defined in a comment, and the due-date must be moved reasonably, with partners made aware alongside radiation. If a due-date cannot be changed, don't miss the date.

For every task, the assignee owns the decision of how to complete it within the blueprint and doctrine. But they may need decisions from others to help them move their task to done-done. So while the success of the task still ultimately relies on the assignee, and it's their responsibility to chase down the decisions they need, here is who to involve as needed:

If you are responsible for a task, but are for some reason unable to satisfy its conditions for whatever reason (e.g. you need to go unexpectedly OOO) it is still your responsibility:

Heartbeats

At the end of each week, we all answer an automated check-in that asks what we did on a project. We always answer these, if we've done anything at all on that project. Our answers are written in a way that is thorough, intended to be partner-ready for the most part, with parts that highlight the need for support clearly marked, so that help can be forthcoming.

Those check-ins are what PM uses to write 'Heartbeats': a short message board post to each partner that summarizes what we did that week. They should already know everything that has been written, thanks to radiating information throughout the week, but the summary can be really helpful in remembering the progress we've made, and being able to look back across weeks passed for a sense of momentum.

Forecasts

Heartbeats are for looking back over a week. Forecasts are for looking ahead over a month. At the start of each month, we kick off a message board post in each active project, to discuss what we believe are the most important focuses for that month. This is not to say we must stick to only these things, or to forgo things not mentioned. Rather, this is to help us keep a big picture focus of each project, how we're progressing, and what needs our focus and attention, so that no one finds themselves in a situation where they can't see the wood for the trees.

How to fail

People hesitate when they’re afraid of being wrong. But failure is not wrong, it's data.

We don't learn, or grow, by hesitating. We learn, and grow, by taking responsibility for our work, finding the answers we need, and remembering if a task we're responsible for fails, it's our responsibility to work out why, and improve the system so it doesn't happen again.

If something ships and needs revision, we fix it, we update blueprints and checklists as needed, and we move on stronger as a result. This is a celebrate-able event, not one to be ashamed of.

Everyone has the authority to push work forward, request clarity, reopen tasks, and escalate issues when needed, without asking for permission. The PM is ultimately responsible for these things, but everyone has the ability to be a team-player and take initiative on these things, to prevent unnecessary failure.