The Art of Booth

I originally wrote this up as an internal blog post, but I think it may be useful for other people, too, so I’ve cleaned it up a bit and taken out most of the proprietary stuff, and added some explanations. I had never in my life done boothwork before this job, so I was surprised to find I had so many opinions, but if you’re going to do something, you might as well do it well.


I wanted to start a place where we could keep resources about how to be the best booth person you can be for Your Company, and what that means. 

Rules

  1. Be there for your shift. You have a calendar page that shows you when we expect you to be on-duty, and we need you there. If you have a conflicting meeting, let the booth manager know so we can get coverage.
  2. Be present. There are slow times when we all check our email, but if your laptop is open, you are more likely to seem unavailable to answer questions or chat with someone who comes up.

Guidelines

Saying hello

I like to wait until people slow down and make eye contact with either me or the booth. Then I say, “Hi, can I answer any questions for you?”. Usually you’ll get one of the following:

  • What is <your product>? A: You need a one-sentence answer here. A catchphrase. Way shorter than an elevator pitch. The great thing about a conference is that you have lots of chances for experimentation and iterative improvement.
  • How does that work? A: Again, super short. People are filtering at this point to see if you have any relevance to them.
  • Can you tell me more? A: Sure! What’s your job role? Tailoring the answer to the job role saves you a lot of time answering the wrong question, and also lets you practice understanding the personas that someone hopefully briefed you on.
  • Can I get a t-shirt? A: Sure! What size would you like? Saying that way avoids asking people what size they ARE. Also, t-shirts are the bane of my existence. Have some lovely socks.

Two men face away from the camera and toward a banner for LaunchDarkly. One is pointing to something on a demo screen

If you’re bored, and it’s slow, you can leave one person on the booth and the other person can go take a tour of other people’s booths and listen to their pitches. It’s remarkably educational. Just keep an eye on your partner and be sure to be back by the next scheduled rush. When you introduce yourself to another sponsor, make it clear that you’re not anyone worth pitching to, and if they want to scan you, you can ask that they mark you no-contact. Odds are, if you’re working a booth, you’re probably not buying software for your company – different roles.

Remember to make eye contact and talk to women. They are often overlooked or elbowed out in conference crowds, and they can be very influential in purchasing decisions. If someone shows up with several co-workers to show off the booth, remember to speak to all of them, not just the champion.

When someone comes up to say they’re a customer, or were a customer, thank them! They’re making the effort to say we make their lives enough better that they’ll stop and talk to us. You don’t have to scan them, but you can, or you can keep a tally sheet of who does this, just because it’s such a great feeling, and we should share it with other people at the company. I think a tally sheet might have a row for Company name, and columns for “Love the product” “Love the design” “Miss using you” “Changed my life”. Or maybe that’s too much.

HOWEVER, if they’re a current customer and they have a question – tell them they can write support, but also either scan them or make a note. There’s some reason they haven’t contacted support already – they didn’t know it was there, or they don’t know how to frame their question, or they think it’s their fault for not understanding something. If it’s something you can answer right away, like a UI question, answer it! Otherwise, make sure support knows how to find them.

Scanning

I try not to scan someone until they’ve made it past the first question and asked me a follow-up question. Number of leads is important, but it’s more important that they be leads with actual value. If it’s just someone who has no interest, why put them in the funnel?

Ask before you scan. It’s a bad experience to have your personal data taken without permission.

Scan everyone in a group, if they come together. You can never tell who the champion is going to be.

If you have any time at all, rate the lead on warmth or add any pertinent info. That can include where they’ve heard of us before (Edith’s podcast, Heidi’s talks, blogpost, etc) if they happen to offer it.

Make sure the scanner is charged overnight and at slow times.

If we have to use our phones as scanners, try not to leave it lying on the table. No one wants their phone stolen, especially since it probably has a bunch of proprietary information on it.

Clothes

I covered clothes for conferences in this post.

Setup

Your booth manager will take care of most of the initial setup, including making sure there’s a monitor. Double-check that the monitor and the computer don’t look grungy. A clean monitor makes us look better.

Until we have a computer that exists just to go to shows, the demo is usually run off the computer of someone working the booth. I suggest you open the following tabs:

  • LaunchDarkly-specific tabs, but it’s good to have an idea of what you want to pull up. Don’t have anything else in that window.

You’ll also have a bunch of stickers and material, which is covered in Stuff.

Nitpicky

  • Try not to set your food or Starbucks cups on the table. We are sometimes paying $10k for this dinky table, and putting other stuff on it diminishes our brand value. It’s fine to drink at the booth, but keep it to an unbranded bottle or keep it off the main table. Hopefully we provide enough breaks that you don’t need to eat at the table. It looks super untidy.
  • Try to keep the table and area around the booth tidy. It’s almost never enough space, and if we leave our backpacks on the floor, someone will trip on them.
  • If you are using your own adapter to connect to the booth video, please just order a new one. Eventually we will get enough, but I’ve already lost 3.
  • Dress for standing all day. There are usually chairs, but it’s not always engaging to be sitting down. Also, there’s a lot of walking and standing in line.

Stuff

NOTE: This is very LaunchDarkly-specific, but I’m leaving it in as an example of how to write about the things that you want to happen at your table.

We have sent you a bunch of stuff in the Pelikan cases that hold the booth supplies. Depending on how big the conference is, and how many we have going on, you’re going to have:

  • Main brochures. These go in the clear acrylic holder and a few of them can go in a stack on the table. It’s nice to have at least one upside down so you can point out the supported SDKs and marquee customers.
  • Accordion brochures. Set one of each color out, standing up and telescoped out. When people pick that one up, replace it from under the table. Do not attempt to stack these, it will just end up all over creation. If you have one of the little blocks with a gripper on it, you can put one in that, or you can use it for stickers.
  • T-shirts: None! T-shirts cost $12 each to print, and then they have to get shipped and size sorted, and they take up table room. I love our t-shirts, and I think they should go to everyone who makes an affirmative effort to get one, by visiting our trial or conference website.

  • Stickers! There are three types of stickers: 
    • Die-cut – these are the ones that are irregular shapes, like Toggle and the rocketship logo. Put out 10 or so at a time of each type, and either stack them neatly or fan them out.
    • Hexes – Put out one of each type abutting each other to show that they work together, and then have stacks of ~20 or so spaced out behind that display. Don’t try to stack stickers more than 20 high, they’ll just get knocked over all the time, but people need to be able to get their fingers around each one, so you can’t stack them up touching.
    • Minis – these are tiny 1-inch circles. It is impossible to get them stacked neatly, so I usually just have them in individual piles. NOTE: Each of the flags means something different and it is helpful for all of us, and for re-ordering if you keep the types separate as much as possible – don’t just sweep them all off the table at the end, put them back into individual baggies. The minis come in the following types:
      • Dark blue – regular LaunchDarkly. You will go through the most of these.
      • Rainbow – Gay/queer pride. If anyone asks, you can point out that the brown and black stripes represent queer people of color who are often left out of the story of queer politics.
      • Pink/white/blue – Trans pride. Leave them out, but never comment on anyone taking them. Some people think they look like they’re for little kids, some people have little kids who are trans. Who are we to say?
      • Pink/purple/blue – Bi pride. Bisexuals also have a pride flag. So do lesbians, but it’s not well-standardized yet.

The thing with all of this stuff that we send along to the conference is that it costs money. The stickers cost up to 50 cents apiece. So if we don’t give it out, we want to make sure that it survives to the next show. If we toss everything back into the case, and the case gets treated in the way of all luggage, we’re going to waste a lot of money on stickers and brochures that end up damaged and unusable. So I know you are so ready to get out of there once the show is over, but please make an effort to stow things safely.

tl;dr

This may seem like overthinking, but the money, time, and opportunity cost that a booth represents is pretty immense, so it’s worth it to think through what you want to have happen before you get there. Talk to your peers about what has worked for them. Walk the show floor and see what seems like a good idea. I have a whole album of pictures that I share with my design and marketing team so we keep up with what’s current and trending. If you don’t do that, you end up with a booth design that makes people strangely nostalgic for grunge music and clove cigarettes and AOL CDs, and that’s not the goal.

Mostly, though, you’re here at a booth because you have an awesome product that can actually improve people’s day, and if they want to hear about it, you want to tell them, and honestly, that feels pretty great. Go, do good work, and hide your coffee cups!

Documentation for DevOps: A DevOpsDays Open Space Writeup

I’m borrowing this image from my friends at Chef, because it’s really funny to pretend that it’s possible to just sprinkle on “devops”, something that is about cultural change at every level.

At every DevOpsDays I go to (and that’s quite a few), I propose/wrangle/run two open spaces. One is about feature flags/canary launches/hypothesis-driven development, and the other is this one, which I usually refer to as “Docs for DevOps”.

DevOps documentation is difficult because it’s not intended for external audiences, so it’s hard to make a case for hiring a writer, but it’s also mission-critical, which means that it can’t be ignored or neglected.

I also have a talk that I give on this topic. You can find recordings from DevOpsDays Minneapolis and NDC Minnesota here. but this is specifically about the open space. I am indebted to a number of people in the last year who have come to open spaces, shared their experiences, asked questions, and challenged my thinking and assumptions.

I’ve grouped the questions I hear most often into these categories:

  • How can I find anything?
  • How do I get people to read the docs?
  • How do I get people to write the docs?
  • My team is small, do you have particular advice?
  • My team is very large, what should we do?
  • Distributed team best practices?
  • Why is sharepoint?
  • What tools are most useful?

How can I find anything?

Frequently, the first problem that people have is not that nothing is written down, but that lots of things are, and the problem is discoverability and accuracy. It’s one thing to have instructions, and quite another to have instructions that you can find when you need them. Many people have their operations documents spread across one or many wikis, ticketing systems, and document storage platforms.

The short answer to this problem is “search”. That is also most of the long answer. The thing I think we overlook is that we don’t have to use the search engine that came with our wiki. We could put something else in front of it. With the demise of the physical Google Search Appliance, you still have a number of service options. Most of them will give you the option to index and search multiple sites.

As a consultant who helped companies structure documentation so it was usable, I have a lot of specific advice on how to change the architecture and the culture, but honestly, if you could get your company to hire someone to help with that, you could probably get them to hire a writer and solve the problem another way.

The last part of this answer is that you could get some consulting dollars and hire an archivist/librarian to help you come up with tags that help identify the types of data and make it easier to search for. When we’re trying to recall data, we frequently do so by keyword or tag, and an archivist can help you make a canonical list of what people should use for that.

How do I get people to read what we have?

First, see above, make it easy to find.

Second, make it as easy as possible to read. Sit down in a group and hash out what type of information has to be included to make a topic/article/page useful to others. Once you know what you need to have included, you can make a template so that people remember to include it all.

The next problem is to figure out how to point people to the documentation without being dismissive or making them feel like you are too good to answer their questions. This might be a good place for a chatbot, or a single web page full of resources.

Many people would rather be able to find an answer themselves than bug a coworker to get it, so if they’re not reading the documentation, there’s probably a systemic problem blocking them.

How do you get people to write the docs?

Do you know any sysadmin or SRE who has ever been fired for lack of documentation?

Do you know of anyone who has gotten promoted solely on their ability to write internal documentation?

Most of us don’t. No matter how much organizations say they care about documentation, they are not putting anything of meaning behind those words. It’s not malicious, but it does tell you that documentation is not actually something they care about.

One of the ways to fix this is by using a reward system. Buy a package of Starbucks cards, or awesome stickers, or ice cream certificates, and give them out every time someone completes a documentation task, immediately. Adding a tally mark for their eventual review is much less motivational than immediate rewards for work. You don’t have to be a manager to do this – anyone can motivate their co-workers. The reward doesn’t have to have cash value, but I do think it’s the easiest way to indicate your appreciation.

Another thing to pay attention to is how easy or hard it is to write the documentation. If it’s a complicated system, the barrier to entry is high. If it’s in a tool the team already uses, in a language they already know, it’s much easier to persuade them to drop in a few lines. if there is a form for them to fill in so they don’t have to figure out what they are supposed to include, that’s even better. Lowering the cognitive barrier to entry is as important as the tool barrier to entry. After all, we’d have a lot more trouble writing bug reports if we had to write them out by longhand without any fields to fill in. Documentation is the same way.

My team is small

Consider using just one single page of truth. No, seriously. If you’re working with a team under 8, and especially if they’re distributed, consider just putting everything on one single web page and searching it when you need to find something. The overhead of managing a documentation system or wiki is not something you need when your team is that small. As you write new things, they go at the top and older stuff gets pushed down to the bottom and becomes obviously less important or relevant. If you need to find something, you can easily search the page. No one has a secret pile of documents that the rest of the team doesn’t know about. It’s not an elegant solution, but it’s hella utilitarian.

My team is large

Hire a writer. And/or a librarian. I was talking to someone whose IT organization was over seven thousand people. They obviously do need some structure, some tooling, some information architecture. Rather than spend internal IT cycles on it, I suggest hiring experts. There are thousands of people in this world who are trained to manage, collate, write, and wrangle large sets of documents, and it’s wasteful to try to do it by yourself.

What are the best practices for distributed teams?

Pretty much the only effective way to have a distributed team is to change the team culture to one where you write down questions and answers, instead of popping by to share them. It’s important to make sure that key data is always written down and not passed on by word of mouth, because as soon as you have an oral culture, you are leaving remote members out.

It’s useful to have at least one team member working remotely who has distributed team experience. You can ask them for what has worked for them in the past and enlist their help in iterating your practices. For example, is it hard for the team to remember to set up the call-in for meetings? Change the meeting template to include a shared meeting room automatically. No one gets a distributed team right immediately, anymore than we do a colocated team. It’s just that it’s easier for distributed teams to end up in a broken state before someone notices.

Why is SharePoint?

Because the paradigm and core analogy is filing cabinets. “What if I could see inside the Operations filing cabinet?” Because it thinks of itself as a way to organize pieces of paper, it’s not very good at documents that need to be shared and altered simultaneously across organizational boundaries. It was a marvel for its time, a way for non-technical users to get their documents out of shared drives and file cabinets and give other people regulated access, but it is fundamentally hostile to searching.

What tools are most useful?

It depends, right? Tools exist on a sliding scale between absolutely zero barrier to entry on one end and and taxanomic usefulness on the other. Every team must find their own best place, which may not be the same across the company. But if a team dislikes a tool or finds it burdensome, they just won’t use it.

The best tool is the one you can get people to adopt. If your team is 100% people who know how to use LateX and created their resumes and gaming character sheets in it, then it would be a fine tool. If you had a team composed entirely of people under 20, maybe a a youtube channel would be the way to go. Since none of us have completely uniform teams, the best thing we can do is to find a tool that everyone can grudgingly agree only sucks a little bit.

In conclusion

  • Use a better search engine
  • Hire experts whenever possible
  • Make it easier to write things by using templates
  • Iterate and keep improving your devops docs process. There’s no solution, just a fix for now.

Why on earth would developers WANT to write documentation?

This week I was at DevOpsDays Minneapolis, which was an amazing, warm, and inclusive event. There were at least three open spaces on documentation, communication, and related problems, and I didn’t propose any of them!

Minneapolis DevOpsDays 2017 logo

The question the devops world keeps asking, over and over again is,

How do I get developers to write anything?

There aren’t a lot of easy answers for this.

The first one is that if you care about developer-produced documentation, you should hire for it. But almost always, the people hiring are not the same as the people feeling the pain of missing documentation, so that may not happen.

The second is that you should hire someone other than the developers to write, if that’s important to you. I’m going to mention that all the times I’ve interviewed at Google, it was to be as an internal systems writer, documenting how things in the company work for other people in the company. Big, smart, companies hire writers for internal documents. But that is a tough budgetary sell.

The third, partial, answer, is that you make it significantly easier for developers to write. You give them forms and templates to fill in instead of expecting them to invent documentation theory. You specifically allocate writing time that can’t be budged for “one more tweak to the feature”.

Here’s the key problem though:

No developer has ever been fired for lack of documentation.

No developer I know of has gotten a bonus for documentation.

There is no stick. There is no carrot. There are a lot of competing demands on a developer’s time. Why on earth would they go do something that is not in their core competency just because you want it?

My instinctive response, whenever my kids want something, is to say, “It’s good to want things.” I think that is the instinctive response of most developers who are asked to do extra work. It’s not malicious, it’s just true. There is no reason they should do it – they won’t lose their jobs, the way they might if they prioritized writing over code. They won’t derive any benefit except the long-term and intangible one of being asked fewer questions. If they like being the source of knowledge, they’d be giving that away. If they like coding, you’re asking them to do something other than what they want. There is no upside.

So knowing that, how can we encourage developers to write documentation that we need?

First, reward it. Give people prizes for writing docs, or for throwing away or revising old docs. This needs to be something outside their usual compensation structure. Gift cards, time off, merit badges, whatever would be meaningful to that person. Ask them. They know what rewards them, because they use it to reward themselves.

A variety of rewards

Second, require it. I don’t mean “You have to write some docs or I will, uh, be disappointed in you.” I mean “The presence of documentation is a quality gate and you cannot release without it.” I mean “QA is using your docs as the test story.”.

Companies are never altruistic, humans are never purely motivated. We need to accept this and stop expecting people to do extra work because it’s the right thing to do, and start making the work not-extra, and the reward tangible.

The Seven Righteous Fights: Affordance

This is the fifth fight in my series The Seven Righteous Fights. For an introduction, see The Seven Righteous Fights: Overview.

Affordance is what the interface makes easy and obvious. Affordances tell us all sorts of things about the tiny interactions we have with the world, and with software.

Most people talk about the affordances of hardware, which way your USB plug goes, things like that. But software interfaces also offer us affordances, with a big green yes button and a small grey more information button.

Affordance is making the world encourage the behavior you want

This picture is where I crossed the street to go to work. As you can see, the place that the sidewalk goes does not correspond to either the crosswalk button or the crosswalk itself. This is bad for the grass, bad for the mobility impaired, and a nightmare when the snow gets plowed off the sidewalk and in front of the button. I live in Minneapolis, we measure our snow in feet. In the winter, the crossing button can be literally covered by a plow drift.

This is a bad affordance, but sometimes you are doing this with software design, where you are putting the sidewalk “where it belongs” and not where users need it.

The righteous fight in affordance is to figure out how to make it easier to do the right thing than the wrong thing. Sometimes the wrong thing is depositing your check to the wrong account because the app has tiny buttons on your phone. Sometimes the wrong thing is that it’s easy to harass other users without consequence.  Whatever your intentions for the thing you’re building, users will see it a different way.

Privileges

One of the things that I classify as affordance is the privilege level it takes to do something. To test this, perform one of your user’s daily tasks.

Now step your permissions down to the level of ordinary mortals. Oh, is that less fun? Are there more hoops and confirmations and things you need to do? Can you even do the job without advanced permissions? Setting excessive security or blocking on ordinary tasks is an affordance and security anti-pattern. It means that people demand elevated access, and makes them and your organization more vulnerable to accidents and malice.

Task frequency

This is a homunculus. It is a weirdly shaped human because the size of the body parts represents nerve density and sensation, instead of physical appearance.

As developers, we often look at things in terms of the architecture, or where the data is. But the user has a really different idea of what is important, what gets used most. Our software needs to reflect what they are actually doing, not what is most logical to us.

Summary

Affordance is our opportunity to nudge users into patterns that they will find useful, rewarding, and not hideously irritating. We can only take advantage of that opportunity if we are thinking about their needs as well as our own.


This blog post is part 5 of my Seven Fights series. You can hear me give this talk at SpringOne Platform (August 1-4) or Abstractions (August 18-20).

The Seven Righteous Fights: Overview

This is a series derived from my popular talk “The Seven Righteous Fights”. It’s not an exact transcript, but I think having a written form to refer people to greatly increases accessibility and gives me room to expand my thoughts in a way that is not compatible with speaking.

There are seven fights that I have over and over again, whenever I start at a company. The more software you build, the more it’s obvious that there are seven fights that it will alway pay to have.

My background as a writer means that I am trained to perform a lot of analysis and synthesis. If I don’t understand the product from value proposition through implementation, it means that I am not the writer I want to be. I call it being a full-stack writer. The problem with having all this training in analysis is that you can’t exactly turn it off. I don’t stay in my lane well, I can’t notice problem that only fall into the narrow category of “documentation”. They’re all documentation problems, they’re all software problems, they’re all design and usability problems.

I’ve worked for roughly 15 companies and my conclusion is that when we create something new, we tend to make similar mistakes every time. This is probably because we all tend to settle in a comfortable stage of product development. Some people prefer mature products, some people like the very beginning and hate the mature product maintenance. But that preference means we don’t understand pain points that happen at other stages.

I’m an early-stage person. I love writing the first version of documentation. I love that green field and that new product smell. But I have done enough mid-stage stuff to know the emergent consequences of early-stage decisions. And like everything you’ve ever read about compound interest, early mistakes compound until they are enormous.

I was working with a startup that was pushing super hard to get their product ready to demo at a big industry conference. They were stripping off every feature they didn’t absolutely need in order to make sure they made their deadline, and I was helping. We made the deadline, there was documentation, and they got a POC contract… with a company in Brazil.

In the process of rushing to get ready, we had stripped out all of the plans to make the interface labels link to a file we could localize, and we had hand-coded all the labels. Now instead of handing off a single file to be translated into Portuguese (and having standard labels that could have been done with Google Translate, in a pinch), we either had to branch and hand-code Portuguese labels or spend twice as long digging into the original code and fixing what we had hacked. I’d love to tell you we decided to do it right, but you all know too much about software to believe that happened, don’t you?

The compounded interest from not using a best practice of referred labels when we built the user interface cost us five days of developer time to fix the wrong way, and two weeks to fix and rebuild the right way. That’s a relatively common example of things people skip and pay for later.

Leaving important considerations “until we get a working prototype” means that it’s going to be harder and more expensive to retrofit. Having these fights early prevents you from doing the software equivalent of poking chocolate chips into already-baked cookies.

cookies

Next: The Seven Righteous Fights: Localization

If you’d prefer to watch the talk as I delivered it:
Shortest recorded version: At The Lead Developer 2016

Longest recorded version: At SpringOne Platform 2016