surdist. Obviously, they did not have
the benefit of reading this article.
I thought for a moment. What was
the most recently controversy? Well,
facial-recognition software was becoming good enough and computationally inexpensive enough that it
was making the news and starting a
lot of ethical debates.
I blurted out, “Hey, didn’t we just pur-
chase a company that makes facial-rec-
ognition software? You’d think a smart
bunch of people like that would be able
to accurately place mustaches on all the
photos in the corporate directory.”
There was a short pause in the con-
versation. Then one manager said, “We
just moved those people into my build-
ing. They sit down the hall from me.”
Another manager chimed in that he
manages the team that runs the cor-
porate directory. Another manages the
operations people for it. Another man-
ages the helpdesk most likely to receive
Soon, we had a plan.
We started meeting weekly. We wrote
a design doc that spelled out how the
AFP would work, how we would shut it
off after 24 hours, and, most importantly, how individual people could opt out
if they complained. A project manager
was assigned to coordinate people on
three different continents to make it all
happen as expected. HR and executive
management signed off on the project.
This was long before social media
apps were doing this kind of thing, so
the primary question we kept getting
was, “Is this really possible?”
Was it technically feasible? Yes. It
turns out the free software develop-
ment kit that the company provided
included a mustache-placement API.
“Mustaching a person” was the demo
they used to sell the company.
By the time April 1 rolled around, a
new set of photos was prepared and
ready to be swapped in. The helpdesk was trained on how to revert
The prank was a huge success. Everyone thought it was hilarious, except
for one person who complained and
Afterward, we wrote up a retrospective and thanked everyone involved.
In such a highly distributed company,
this was the best way to let everyone involved “take a bow.”
The prank should be easy to enable
and disable. Hide the feature behind
a “feature flag.” With the flag off, the
feature is in the code but dormant.
Enabling the prank in production is a
matter of turning the flag on. Disabling
it is a simple matter of turning the flag
off. Developers can test the feature by
enabling the flag in the development
and test environments. Some flag systems can automatically be on for certain user segments.
Some companies can launch or disable a feature only by rolling out new
code into production. This is bad for
many reasons. It is riskier than feature flags: if the release that removes
a prank is broken, do you revert to
the previous release (with the prank)
or the prior release (which may be
too old to deploy into production)?
Code pushes are difficult to coordinate with PR, blog posts, and so on:
they might take minutes or hours, not
seconds, like flipping a feature flag.
Code pushes require more skill: in
many environments, code pushes are
done by specific people, who might
be asleep. In an emergency you want
to empower anyone to shut off the
prank. The process should be quick
and easy. Lastly, if the prank has overloaded the network, it may also affect
the systems that push new code. Meanwhile, a feature “flag flip” is simpler
and more likely to just plain work.
The way you structure an AFP project
is unusual in that the deadline cannot
change. There are three levers available
to managers: deadline, budget, and
features. If a project is going to be late,
management must adjust one of those
three. An AFP, however, cannot adjust
the deadline and usually has a limited
budget. Therefore, it is important to
segment the features of the prank.
First implement the basic prank, then
add “would be nice” features. As you
get closer to the deadline, throw away
the less important features. When a
badly structured prank is late, all features will be 80% done, which means
0% of them can be launched. You blew
it. When a well-structured prank is late,
80% of the features are ready to launch,
and the customers will be no wiser
about the missing 20%. Structuring
a project in this way requires skillful
planning up front.
During the prank, plausible deni-ability is important. Act like it is real, or
act like you don’t see it, or act like you
were not involved. Do, however, include
a link to a page that explains that this
is just a joke. They say a joke isn’t funny if you have to explain it; if someone
doesn’t realize it is a joke, it can lead to
unfunny situations and hurt feelings.
This is the Internet, not Mensa.
Perform a project retrospective. 5 After the prank, sit down with everyone
involved and reflect on what went well,
what didn’t go well, what should be
done the same way next time, and what
should have been done differently. Publish this throughout the organization. It
not only makes everyone feel included,
but it also educates people about how to
do better next time. Yes, you may have
overloaded the network and created an
outage, but if everyone in the organization learned from this experience, your
organization is now smarter. Every outage that results in organizational learning is a blessing. If you hide information, the organization stays ignorant.
Case Study: The Mustache Prank
One of the most successful AFPs I was
involved with was at a previous employer. Managers had been on a teleconfer-ence for an hour brainstorming ideas
for an AFP. They wanted one that would
be visible only to employees. There is
nothing less funny than managers trying to write a joke, so they turned to me.
I was a half-manager so they assumed
I’d have a half-funny suggestion.
After listening to the ideas they had
so far, I was not impressed. They were
irrelevant, not topical; silly, not ab-