Posted by RuthBurrReedy
[Estimated read time: 16 minutes]
On February 17th, sports news and opinion blog SB Nation posted a longform story titled “Who is Daniel Holtzclaw?” The story, which took a sympathetic viewpoint on convicted rapist Daniel Holtzclaw, sparked a huge amount of controversy among SB Nation readers and garnered the blog a great deal of media attention. It took less than 24 hours for SB Nation to pull the piece, calling it “a complete failure.”
In the aftermath, SB Nation’s parent company, Vox Media, convened a panel of editors and journalists to investigate how a piece taking such a controversial stance on such a sensitive topic could have been published on the site without anyone saying “Hang on, is this a good idea?”
What does this have to do with digital marketing?
When I read the peer review report, I was expecting a fascinating glimpse into the inner workings of a very popular media site. What I wasn’t expecting was how many of the review’s findings were exactly the kinds of struggles, missteps, and roadblocks I’ve seen at my and my friends’ workplaces over the years. If you’re a startup, a rapidly growing business, or a company that relies heavily on technology for communication, chances are you have or will run into many of the same pitfalls that plagued SB Nation.
Regardless of your feelings about the case itself or SB Nation’s coverage of it, the Vox peer review has some valuable lessons on how a business can avoid inadvertently launching a product (or website, or piece of content) it’s not proud of. The entire peer review is worth a read, but I’ve pulled out the biggest lessons for businesses here.
Realistic production schedules
The Longform blog was publishing one longform piece of content every week, a pace that the peer review called “…a furious rate of output that’s not conducive to consistently excellent reporting and editing.”
In the tech world, there’s enormous pressure to ship and keep shipping. For content creators, there is often a quota of pieces per week or per month to be met. An environment that stresses pressure to consistently produce over pressure to do excellent work is one that is ultimately going to result in some inferior products getting pushed out there. Taking shortcuts in the name of speed also results in technical debt that can take a business years to catch up with.
“Done is better than perfect” is a common mantra at tech companies, and there’s a lot of value in not sweating the small stuff. Scope creep is a real problem that can bog a project down inevitably. Still, it’s important to make sure that your organization isn’t encouraging a breakneck pace at the expense of quality.
Encourage your team to be honest about how long a project might take, and then build in some squish time to handle the unforeseen (more on that next). Recognize that not all product updates (blog posts, ad campaigns) are created equal, and some will take more time than others. If your team is constantly in “crunch mode” trying to get things out the door, that’s a big clue that your pace is too fast and mistakes are going to be missed.
Build in time for Quality Assurance
This is one I’ve seen time and again around a new website launch. As delays are almost unavoidable when building a new site, the “final product” often isn’t ready for review until a day or two before launch is scheduled to happen. It certainly can be possible to test and review a site in that amount of time, but only if everything is actually ready to go. If the QA review finds any major problems, there’s no time to fix them before the launch deadline.
At SB Nation, editors and reviewers had between two and four days to turn a longform piece around for publishing before it was slated to go live. This meant heavy revisions were out of the question without pushing back the timeline to publish. Furthermore, the peer review discovered that many pieces were being published with only one other person having reviewed them — and then only from a copy-editing perspective, not for content.
Even if your team are all geniuses who consistently do a dynamite job, any writer will tell you that it’s impossible to proofread your own work. An outside perspective is absolutely vital to finding and fixing the problems any project might have; the person who built it is just going to be too close to the work to do it themselves.
Say it with me: a QA process is meaningless without a strategy to fix the problems it uncovers. Do not expect that your projects will just need a quick review-and-polish before they’re ready to go live. Instead, make sure that you’ve budgeted enough time both thoroughly test and review, and assume that the QA process will uncover at least one major issue that you’ll need to build in time to fix. In order to do that, you’ll have to make sure you:
Don’t get married to your deadlines
There are occasions where a hard deadline is unavoidable. You need the new website to be built before your major trade show event, or your blog post is responding to a developing news situation that won’t be as relevant tomorrow. There are plenty of situations, however, when deadlines are more malleable than you might think. Sometimes, the cost of launching something that’s not fully ready to go is much higher than the cost of pushing back a deadline by a week or two.
As a leader, one thing you can do is build in internal deadlines throughout the life of a project, so as each deadline approaches you’re checking in regularly about whether or not it’s realistic. This can mean saying things like “We will need two weeks for QA, so all work on the product will need to be completed by June 15th to launch on July 1st.” “The blue widget team will need 3 weeks to complete their portion of the project, so if it’s not handed off to them by May 25th, we are jeopardizing the launch date.” By setting these internal deadlines, you’re building in an early warning system for yourself so you have plenty of time to plan and manage expectations. You’ll also set a precedent for treating QA time as sacred, instead of cutting into it when other portions of the project overrun.
You should also decide ahead of time what you do and don’t need in order to launch something. This is commonly referred to as defining the MVP, or Minimum Viable Product. If you have to sacrifice a few bells and whistles to hit your deadline, it may be worth it — but make sure you don’t get so focused on “done” that you lose sight of what you’re trying to do with this project in the first place.
Be clear about roles and responsibilities
Vox uncovered a problem at SB Nation that is so, so typical at companies that have undergone a period of fast growth: their internal leadership structure had not grown to scale with their increased numbers. The result was confusion about who was responsible for what, and who had the power to say “No” to whom.
This type of problem can be especially insidious at an organization with a “flat” org chart, where there aren’t a ton of pre-defined internal hierarchies. Too much middle management does run the risk of turning your business into the company from Office Space — but too little oversight can be just as dangerous. A clearly-defined org chart can help your employees figure out who they need to contact in a crisis, and make sure that everyone’s in the loop who needs to be.
Taking the time to build some internal structure, define roles and responsibilities, and have a clear process to escalate problems as needed might sound unbearably stuffy for your hip young tech business. You may feel that “everyone knows” who’s responsible for what because you’re such a tight-knit bunch. I’m sure I’m not the only one who felt an unpleasant shiver of recognition when I read this quote from the peer review, though:
“Asked why he thought senior staffers felt they couldn’t overrule Stout, Hall told us, “I think people didn’t know how…We have a very tight, personality-based workplace. And I think sometimes if you don’t know that person — people didn’t feel like there was a formal way to do it.”
Make sure there is a formal way to do it. Believe me, you will be so happy that you got these things in place before you needed them, instead of waiting until you have a huge, public, embarrassing incident to make you realize you need them.
Empower feedback at a cultural level
There were multiple people within the SB Nation organization that were concerned about the Holtzclaw piece, but most of them felt like it was not their job, or their place, to give feedback. The copy editor who was the first to review the piece specifically said he thought sharing his concerns was “above his pay grade.”
It can be difficult to know whether or not criticism or raising concerns is appropriate in a given situation, especially for less-experienced team members who may not be familiar with workplace etiquette. This is exacerbated when decisions are made via email chains — a given observer may not want to derail the thread with their concerns, or risk looking foolish or overstepping their bounds in front of their colleagues.
As a leader in your organization, pay attention to decision-making processes and make sure that you are creating a space to actively solicit and encourage feedback from the people involved, regardless of their pay grade. You need to pay attention to the “unwritten rules” of your workplace, too — what happens when someone voices a critique? Are they listened to? Taken seriously? Dismissed? Ridiculed? Does change ever come out of it? It won’t matter if you ask for feedback if you’re not taking the time to support it culturally.
This is one of many instances in which defining and living by a set of company values can be so important. At UpBuild, two of our values are transparency and integrity, so creating a culture where feedback is warmly encouraged fits right in with what we’ve said we want to do. Knowing that they’re taking an action that’s supported by the company’s core values can encourage someone to risk speaking up when they otherwise might not have.
Avoid isolation and concentration of power
Most startups have that one person. They’ve been there for a while, maybe since the beginning, and since the business started out lean and mean, they’ve worn a lot of hats while they’re there. Maybe they helped build some of the systems the company runs on. At any rate, they’ve got one product, or one area, that is “theirs” alone — nobody else really touches it, and in some cases nobody else really knows exactly what they do with it. What people do know is they have to stay on this person’s good side, because any time their work intersects with this person’s individual fiefdom within the company, they’ll need their cooperation to get it done. In the case of SB Nation’s Longform blog, even people who were ostensibly editor Glenn Stout’s peers didn’t feel empowered to kill a piece he’d championed, because it was “his” blog.
Additionally, the team was distributed across the country, which means they used a combination of email and Slack to communicate. According to Stout, “When I first started hearing about Slack, I had no idea even what it was. And then the edict came down that we have to go on Slack. And I had to find out what it was. And I would use it occasionally, but I’m just much more comfortable with emails.”
What I found so fascinating about this portion of the report was that not only did Stout’s non-participation in Slack distance him from his co-workers, giving them less of a sense of what he was working on, it also created the impression that he was exempt from the rules and expectations that governed much of the rest of the organization.
If you recognize an internal fiefdom forming (or know of one that’s already there), break it up by building in some redundancies — there should be no one person who holds so much exclusive knowledge about an area of your business that it wouldn’t be able to continue if they were to leave. Get other people involved in the project, emphasize cross-team collaboration and information sharing, and make it a requirement for everyone. Even your top performers shouldn’t be exempt from the policies and procedures laid out for your organization.
Building in redundancies can also help guard against another contributing factor to the SB Nation debacle: the one person who would usually dictate whether or not a piece would be published, the editorial director, was on vacation. Two other editors were meant to be taking on his work in his absence, but neither was sure if they had the power to kill the article. If a core decision-maker is on vacation, there should be other team members conversant enough with his or her work to step in, and everyone should be on the same page about their power to make decisions in his or her absence.
To combat isolation, be consistent in setting and reinforcing expectations for communication and collaboration. Don’t just let everyone use communication tools to whatever extent they prefer; figure out which conversations need to be happening in which channel, and then nudge your team to make sure information is being communicated in the right way/place.
The informality and high interruption factor of a tool like Slack can turn people off, and it’s easy to see participation as voluntary, but if important discussions are happening there, everyone needs to be using it. Set the expectation with your direct reports: “You don’t have to look at it constantly, but I expect you to be checking Slack (x) times per day, participating in discussions that concern you, and responding promptly to direct messages.”
Speaking of tools:
Pick a project management solution and stick with it
Growing companies tend to leave a trail of discarded project management systems in their wake. It can be difficult to get a whole team to fully adopt a new tool, and when you’re small, it’s pretty easy to keep track of everything that’s going on. The challenge comes, once again, with growth — sooner or later a company gets big enough for things to start falling through the cracks. Finding the next new shiny project management tool and rolling it out to great fanfare are easy; getting your team to actually use it is the hard part.
Adoption of a new tool or process has to be set at a cultural level. Build use of the new tool into existing processes in an explicit way, and then reinforce that that’s how you expect them to be done from now on. I’ve found it helpful to structure touch-base meetings about a given project around the project management tool (we use Trello); that gives the people working on the project incentive to make sure everything’s up-to-date before our meeting.
Prioritize empathy
When you’re spending all your time thinking about and making something, it can be really hard to think about it in any different way. Most SEOs have encountered this with our clients; people get so used to industry terminology or niche product descriptions that they have a hard time taking a step back and asking, “What are our customers really looking for? What problems are they trying to solve?”
Empathy can come into play at many points during the marketing process — user testing, focus groups, persona building, user experience, accessibility concerns, etc. — but is of particular importance when dealing with sensitive subjects. There are countless examples of businesses who have, for example, tried to take an “edgy” tone on social media and wound up in a media firestorm. Empathy should be a required skill and consideration for anyone who is going to be communicating on behalf of your business.
As with empowering feedback, prioritizing empathy is something that can be best done at a cultural level. You may decide you want to make empathy part of your core values, but even if you don’t, you should clearly define your company’s stance on addressing sensitive topics — and the tone and brand voice you’ve defined as part of your overall brand strategy should reflect that as well. Make empathy part of the training and onboarding process for anyone who will be communicating about your brand, and for all higher-up and senior staff, and you’ll start to see the cultural shift.
Fail fast, apologize faster
The peer review covered a lot of “what went wrong,” but let’s close on what went right. It took SB Nation less than 24 hours to realize their mistake, take down the piece, and issue an apology — not a “we’re sorry if you were offended” apology, but a real, honest-to-goodness, “this was a mistake and we are heartily sorry” apology.
It would have been easy to beat a hasty retreat, engage in some quick and public firings, and sweep the whole thing under the rug. Instead, SB Nation and parent company Vox Media proved that their apology was sincere by taking concrete steps to figure out what had happened and how they could prevent it from happening again.
If you take nothing else away from this, learn from this master class in public apology. The rules are simple, and you probably learned them in elementary school: 1.) Say you’re sorry. 2.) Show you understand why what you did was wrong or hurt somebody. 3.) Don’t do it again.
What lessons did you take away from this peer review? In addition to everything I’ve outlined above, it also served as an important reminder for me that there are many places to find lessons to be learned, and that they’re often outside the tech bubble we so often find ourselves in.
Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don’t have time to hunt down but want to read!
from The Moz Blog http://ift.tt/1ZT3Bx6
via IFTTT