Stickers, A Love Story

When I was in elementary school, I won a science fair, and travelled to the far-off land of Moscow, Idaho for the state competition. While there, I spent some of my food money on the most magical sticker ever. It was a gleaming metallic unicorn with rainbow colored mane and tail. It brought me joy every time I saw it, and reminded me how hard I had worked and how exciting it was to travel to show off my experiment.

When laptop stickers started appearing, I felt the same way about them, a bit. They are reminders to us of things that we have done or accomplished, and they are signals to others about what we care about.

When I started at LaunchDarkly, I had one day in the office, and the thing I spent the most time on was talking with our (genius) designer Melissa about stickers and what we should do with them. We have just done a refresh of our Toggle character, and now they look like this:

So cute! So space-tastic!

In the last year, I even built a sticker lightning talk to address why I care so much about this, and I’m always charmed to look out at the audience and see the smiles and nods as people feel seen and understood.

Why do we care?

Why do/should tech companies and other companies care? What makes it worthwhile for me to carry around a few pounds of stickers and experience the delights of confusing the TSA?

In-group markers and identity

It is so important to people to be represented and known for themselves. Whenever I have stickers that relate to pronouns or sexual orientation, people make a delighted face and pick them up and hold them close.

And it’s not just the things about personality – a Go programmer is happy to find a gopher. Someone who does DevSecOps loves to find a sticker that describes their job.

I can spot the networking people, for example. They are the ones who think the Fastly 418 (I’m a teapot) the Target Sweet sticker are hilarious. Because they are jokes that relate to HTTP return codes and IP addresses.

Then we have another layer of delight when we can put them on a laptop and be seen and found by others in our in-group. If I have a sticker from a conference you’ve been to, we can talk about our experiences. If you see a sticker that indicates we share something, it’s much less intimidating to start a conversation.

For example, if you see this sticker, there’s a pretty good chance that the person has actually met me.

Similarly, if you have a sticker showing in a video or on your laptop, it could be a lead to something that people want to know about. I get a lot of questions about my OSMI stickers, which is about Open Source Mental Illness.

Branding, I guess

The exposure you get from a sticker is a small increment, but small increments add up. They can add up pretty quickly if your sticker is a prompt for someone to act as an advocate when they are asked about the sticker.

Matt (Brender) Broberg did a talk that included an analysis of the return on investment of stickers.

(the last bit is obscured, but it says “Sticker ROI is 5x to 76x”, I think.

People also have sentiment around stickers, in the technical marketing sense. Cute stickers make people feel like your product is fun or delightful to use. High-quality stickers make people feel like you have a high-quality product. Racist or sexist stickers? You’re alienating a lot of people silently.

Even people who don’t know what npm is will take npm stickers because they are SO DARN CUTE.


One of the interesting parts of carrying my sticker bag around is that I can get a sense of what technologies are important to a community. It’s not always a 1-1 relationship with the technologies you would expect. Sometimes it is. Either way, I can see the level of interest around a company or technology.

For example, I can tell you that the Kubernetes project is interesting and popular and has a good visual brand and is not doing enough to meet the market demand for their stickers. PHP and Drupal crossover, and that’s not surprising, but so do Verizon and Elastic. One conference may have people who don’t recognize a Chef sticker, and another might wipe out everything I have that relates to automation. I can tell from the stickers that Target developers take that they build a lot of internal tools instead of buying them. It’s interesting!

Developer honeypot

It’s not true that developers are universally shy and anti-social. Some of them are, some of them aren’t. What is true is that it’s hard for a lot of us to strike up conversations with strangers. When I spread out my stickers and invite people to browse and take them, it gives both of us a way to talk about technology in a way that is low-key, not intimidating, and doesn’t even require eye contact. We have time to talk or not talk as we wish.

Design patterns and anti-patterns

I’ve been carrying around The Sticker Bag for about three years now, and in that time I’ve spent a lot of time thinking about what makes a sticker attractive to someone. Some of it is identity and branding, but those feelings can be enhanced or reduced by the design and form-factor of the sticker.


Huge stickers are a mistake. I am almost never excited enough about about your product to dedicate 1/6th of my laptop space to it. I think 2 inches is about ideal – big enough to see and have impact, and small enough to fit in around other things.

Here’s what a set of huge stickers looks like:

But wait! You don’t have to think about it, because, my friends, there is a standard! Visit to read it. Interoperability is not just for software and hardware anymore.


I favor the standard hexagon, because the tiling looks really awesome, but I am not against die-cut stickers that have unique shapes. Hexagon stickers started as an “open source thing”, but have utility for everyone who wants to work together for maximizing laptop space.

I have previously questioned round stickers, because they are not an efficient way to use space, but I think they’re ok as long as they’re smallish. Big circles somehow seem even bigger than big rectangles.

My laptop has a combination of sticker styles, but I don’t put anything on there if I don’t know the people or use the product.

You can see how the Fastly 418 sticker is round, but fits ok with others, and the Spoonflower round sticker is too big to fit harmoniously.


If you like it, you should put your name on it. Visual branding is hard to do, but it doesn’t do you any good to print awesome-looking, high-quality stickers if no one can tell who the sticker represents.

For example, this sticker was adorable, but for the first year it was out, you couldn’t tell it was from InfluxDB.

The next run of stickers had their name on it, thankfully!

Not for everyone

Not everyone uses tabs, or spaces, or emacs, or vim. Not everyone wants to put stickers on their laptop. They find it cluttery or distracting or unprofessional. That’s fine. There are all sorts of people in the world. Don’t be judgy.

However! Some people would like to be able to represent themselves with stickers, but can’t, because they have a work laptop that they aren’t supposed to stick stuff on. In those cases, consider these sticker hacks:

Sticker hacks

  • Put a lightweight case on your laptop and either put the stickers on the outside, or leave them on their backing and put them UNDER the case. I do this with a bright pink case from Speck.
  • Get one of those vinyl laptop skins that goes on your computer, and then put the stickers on that. I heard of one guy who got a skin made of the stickers that he had on the previous computer, and then put even more stickers on top of that. Truly next level.
  • Don’t put them on your computer! Other destinations I have heard about include: notebooks, water bottles, white boards, and beer fridges.




Stickers may seem like child’s play to some folks, but it’s an interesting insight in to the cultures, self-representation, and identity of people we’re around. And it’s not just technology – miners and construction workers sticker their hardhats. Musicians sticker their instrument cases. If we have a flat surface, a lot of us feel like adorning it is a satisfying activity.

Delight for less than a dollar? Seems like a great deal.

Saying No, or If This Then Not That

I had to say no to a conference I would have loved to speak at today. I’ve had to say no to several conference speaking offers this year, because it turns out that time, space, and timezones can only be manipulated to a certain degree.

I thought about not blogging about this, because it’s a problem of privilege – “my diamond slippers don’t fit”. But it’s still a problem, and I’m not the only one who encounters it. I’ve talked to some conference organizers and other speakers, and I’ve tried to put together a set of guidelines for the least awkward way to handle this.

Here’s a quick flowchart of the process:

Breaking this down into guidelines, it goes like this:

  1. If you can’t stand the idea of telling an organizer you can’t give a talk, don’t apply to conferences that overlap or have very tight affordances.
  2. If you do apply for overlapping conferences, you may end up not having a problem because no one gets accepted to every conference. NO ONE. So the odds are pretty good that you’ll be fine.
  3. If you have a conflict, it is on you to sort it out and tell people what your response is as soon as humanly possible. Everyone has a different set of evaluation criteria, but they might include price to attend, value of exposure, who asked first, which you would rather attend, things like that. You can ask organizers questions that help clarify that, but it’s bad form to string them along or try to start some kind of weird bidding war. This is the speaker’s dilemma.
  4. You must be as prompt as possible in accepting or declining a conference speaking invitation. Organizers are juggling flaming chainsaws trying to put together a balanced schedule, and they just need to know.

Things it might help you to know:

  • Organizers always have a waitlist of speakers that just barely missed the cutoff.
  • It’s great if you can decline early, but sometimes shit happens and you, say, dislocate your shoulder or get stranded in a blizzard or something. Call the organizer ASAP and give them as much time as possible.
  • It’s far better if you can get this all settled before speakers are announced, but sometimes you can’t. Just as soon as possible.
  • Actually apologize to the organizer if you must decline. They are professionally disappointed, you can be professionally regretful.
  • If you, like me, are a person who always has a talk (or 8) “in their pocket” that you could give at a moment’s notice, it’s kind to tell organizers so. Don’t be a pest about it, but I’ve ended up filling in a couple times for last-minute problems.

This whole set of actions is predicated on you trusting the conference organizer and wanting to speak at the conference. There is a different, and more complicated set of problems if the conference itself is the problem, as outlined in Coraline’s post about OSCON. I’m still working on getting my head around that, and the stupid programming moves Worldcon 2018 attempted and then walked back.

Praise is a vitamin

I was thinking about how happy I am when I get the kind of praise I need. It doesn’t make me feel smug or complacent, it makes me feel strong and empowered and like what I’m doing matters and is seen. Which is kind of the opposite of burnout. I don’t think you can entirely stave off burnout with praise – it’s systemic and situational, but I think you can certainly help.

I mostly get enough vitamins in my daily diet, so I don’t take a multivitamin. I will take specific stuff if it seems called for – folic acid while pregnant, vitamin D in the dark northern winters, salts when I’m doing a lot of sweating. (Pro-tip: If Gatorade actually tastes good to you, keep drinking it until it returns to its normal grossness).

You would think that most work would also give us what we need to feel rewarded, but some people are just better at metabolizing vitamins from food than other people. Some people can eat all the right stuff and still be desperately short of magnesium, or whatever. Our jobs continue to pay us, our boss is not yelling at us, our coworkers speak to us, surely that’s enough? For some of us, yes. For others, not so much.

For some of us, it’s hard to store praise, just like it’s difficult to store some vitamins. You can take a massive dose, but the body will take what it needs and dump the rest, and you’ll be short again in a couple weeks. Some of us can store praise for a long time, but it’s difficult to replenish, or we can use it all up in a burst.

Some of us walk into work with a chronic deficiency and we’re just going to need the same type of reassurance and praise over and over again, and we can’t help it. We do believe you when you tell us nice things, but it wears out, and we can’t generate it ourselves, anymore than we can generate our own Vitamin C.

Lots of managers realize that we all need praise and attempt to address this with the compliment equivalent of multivitamins. They’ll pat us on the back and say “Good job, I like your work.”, and hope that suffices. It does, for lots of people. But those of us, like me, with specific deficiencies, need more than that. We need something targeted and specific, like a B12 shot, something that can’t be brushed off as lip service or a generality. I like praise about actions that I have taken, especially if they are tied to a goal. So, for example, “Hey, your talk on data privacy really affected people – I heard some guys walking out talking about what they could do to be better.” That’s going to keep me happy about writing talks and giving them for weeks! It’s one of my goals to change people’s thinking and behaviors. On the other hand, “We’re getting a lot of leads from conferences you go to,” is… sales leads are not really my goal? I mean, I’m happy about that, but I don’t know if they’re valuable leads, and I can’t see them, so I’m glad that the company is getting worth from that, but it’s not going to feed me when I sit down to write the next new talk.

As a manager, you’re going to deal with people who have scars from nutritional deficiencies. They may nervously expect that praise always has a dark side, or they may be praise-insecure and never sure that they are going to get it again so they guard it from others. It’s not really your job to diagnose what’s going on, just to figure out what it is that your report is lacking and supply it as best you can, honestly, realistically, and sustainably.I’m working on a new theory where I admit I am anxious and that in the absence of positive feedback, I start getting more and more nervous that there is nothing good to say, and my immanent firing will come soon. People who think they are about to get fired are terrible employees – no creativity, no joy, limited teamwork – for good reason. Rather than end up in that spot, I’d rather say directly, “I need this kind of praise to stay healthy.” Better for me, better for my manager and company.

What kind of praise feeds you? Have you asked for it?PS – Due to my odd childhood, I have a strangely inclusive knowledge of nutritional deficiency diseases. Because I am kind, though, I have not included any of those pictures.

PPS – Did you know that because we use Vitamin C to build collagen, people with severe scurvy can have old healed wounds reopen as the scars dissolve? There’s a metaphor to be had there.

Using Airtable to Manage Conference Submissions

I know, it’s not a very catchy title, but it is descriptive.

A large part of my current job is speaking at conferences and talking about feature flags, systems resiliency, and whatever else I can talk people into. And part of speaking at conferences is applying to lots and lots of conferences. But how do you keep track of it all?

At first I tried to use Google Calendar, but that did’t work. I tried Trello, but there weren’t enough dimensions. I wanted to track these elements:

  • Name
  • Location
  • Start date
  • End date
  • Talks submitted
  • Submitted/accepted/rejected/conflict
  • Speaker tasks
  • Tasks remaining

That’s a lot! I complained about the problem, and Thursday Bram suggested Airtable, as a beautiful mashup of a taskboard and a spreadsheet. Since then, I’ve suggested it to several other developer relations people and I know some of them are using it. I’m now paying for the full version, which gives me the calendar view, and that’s been my killer feature. It really helps me to be realistic about how conferences stack and overlap with each other.


Airtable main view

This is the main view. I have it sorted so that conferences that are over or that have not accepted any talks from me are not showing, because I really only need to know about what is coming or may be coming. I’ve grouped it by the Talk Accepted dimension and then the date. At a glance, I can tell what I have coming, and what talk I’m giving (if I remembered to enter it, because I’m sometimes not great at that, as you can see.


I can drill down into any talk title for a card that has a bunch of information on the talk. Frequently I include the proposal I submitted here, along with information about how far along in the process of creation the talk is, all configured by me. Have I drafted it? Made slides? Practiced it on my own or in front of other people?

Cards Pt. 2

Further down on the talk card, I can see all the conferences I submitted the talk to and whether it was accepted or not. That gives me a good overview of whether a talk is “wearing out” or less likely to be accepted than another kind of talk. It’s useful information.

All of those features are available at the free level, and it’s powerful enough for most people, but did I mention I apply to a lot of conferences? More than there are weeks. You probably don’t need the full version.

Calendar View

Airtable calendar view

This view right here is worth everything I spend on Airtable, and I’m certainly not a power user. But it tells me about conflicts in a way that has been very hard for me to predict from just looking at dates. (If we were all good at predicting conflicts from dates and times, we would not have Outlook Meetings Calendar, is what I’m saying) Now I can tell ahead of time that I can only accept one of those three conferences starting on the 24th, and that allows me to be a more polite speaker. Sometimes it’s possible to look at this and make better arrangements. For example, DevOpsDays Chicago is a great event, but it’s literally the day before I need to be in Dusseldorf. Rather than discombobulating myself or the conferences, I can ask now, months ahead of time, to speak on the first day of DevOpsDays Chicago and toward the end of SRECon. That gives me an error budget for weather/flights/etc. Most conference organizers are lovely about helping me out with these things.


Airtable is a super useful tool for being able to organize data when some parts of it are fixed and some parts change and you need to be able to keep the associations together. There are bigger, more heavyweight databases that can do that, of course, but this is a pretty, friendly, usable implementation of the theory.

If you’re interested in trying it yourself, here is a link to the original workspace I set up: Heidi’s Conferences. Feel free to give it a spin or fork it for your own needs.

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.

The sticker bag

I talked about this a little bit in Lady Speaker Small Talk , but let me expand.

I have a bag of stickers that I take to every conference I go to. This week, I leveled up my game from “gallon ziploc bag of significant antiquity” to “bespoke bag”. It only took me a little while to sew, but I’m super pleased with it, and it uses a fastener I got on my last trip to New York City’s garment district.

A black fabric envelope about the same size as a gallon ziploc bag of obvious age. Black envelope style bag with silver bias edging and a fancy silver buckle fastener.

I made the effort because the sticker bag is important to me — part personal brand, part conversation starter.

Array of various technology stickers More technology stickers spread on a table

I go to over 20 conferences a year, and at each one, I collect vendor and conference stickers, and I talk to the people who give them to me, and then I spread them out on a table at lunch or at the evening party and invite people to come poke through them and take away whatever they want.

This is the most genius spontaneous idea I’ve ever had, because what it gets me is:

  • Low-key, low-pressure opportunities to talk to even shy people
  • A way to talk about different technologies and what people are interested in and looking for
  • A way to gauge what a community of conference attendees is excited about
  • Memorability
  • An extremely keen understanding of the market demands and constraints around stickers

What stickers mean

I am the age to have been a Lisa Frank person growing up. I distinctly remember spending science fair reward money on freakin’ holographic unicorns. It turns out a lot of us have never entirely lost the joy of neat stickers. We put them on our computers, water bottles, notebooks, suitcases, beer fridges, whatever we can get to hold still.

We use them as affiliation identifiers. It may be an obscure sticker to everyone else, but if you care about Debian, you know when you see the Debian sticker on someone else’s gear. You know that they will probably talk to you about Debian. Now imagine leaving that kind of conversational hook twenty times over.

We use them as political statements. An EFF sticker means something, as does a sticker that says “Support your sisters, not just your cis-ters”. Rainbow/pride stickers fly out of my collection, because it’s so important to say “not everyone here is straight”.

Some people have rules about what kind of stickers they’ll use. “I only put stickers on for projects I pay money to.” or “I only use stickers from projects I use.” or “Only funny stickers” or “My laptop has a color theme.”

That all makes sense to me. In many ways, our laptops are a proxy for our faces, especially at conferences. We are hiding behind them physically or metaphorically. When we give a presentation, they peek up over the podium. When we are working in hallways, they identify our status.

Secret Sticker Rules

I think there are some generalizable rules about technology stickers. I feel so strongly about this that when I showed up for my one day in the LaunchDarkly office before I went out into the world, I spent 2 hours talking about stickers, and what I wanted to hand out.

My ideal stickers

  • Small – 2 inches is ideal. Unless you work for a company, you do not want to give them 1/6th of your available laptop space.
  • Tileable – circle stickers are selfish, because you can’t stack them or budge them against any other stickers. I prefer the hex shape, which is relatively standard, especially in open source projects, thanks to RedHat. PS – Heroku, right shape, slightly too big, and it breaks the tiling. I’m judging.
  • Funny – the Chef “sprinkle on some DevOps” stickers are hilarious, cute, and not insulting to anyone. They’re probably optimal. I also really like the Logstash stickers that were a log. With a mustache. And I begged a whole package of the “I ❤️ Pager 💩”. Because people find that hilarious. You don’t have to be funny. Other options are cute, completely straight, or your-logo-but-with-colors.
  • Have your name on them. I cannot tell you how sad it was for Influx Data when they had adorable animals with gems in them, but their name wasn’t anywhere on the stickers, and so I was like, uh, it’s a kiwi bird? From someone? Isn’t it cute? Put your name on the sticker unless you’re, like, Target or Apple.
  • Are not sexist, racist, or otherwise jerkish. I pulled out a bunch of stickers that said “UX-Men”, because while the pun was cute, the exclusion was not. I won’t put out Sumo Logic stickers, because I feel like it’s an ugly caricature. Basho was also right on that line.

I really loved the stickers the LaunchDarkly designer, Melissa came up with. Most of them are hexes, a couple are very small oblongs that fit almost anywhere, and the surprise best-moving sticker is unusually big, a representation of our astronaut, Toggle.

Parents love Toggle, love that Toggle is not gendered, and they take home a sticker for each of their kids.

Other handouts

As I’ve been going to conferences representing a company that isn’t just me, I have figured out some other things that work for me. Feature Management is a new enough market space that people don’t always know what I mean, or want something to take back to their team to explain it. Melissa and I worked together to create a small postcard that has some brand identity on the front and a couple paragraphs on the back explaining our business case. It’s small enough to shove in a pocket or conference bag, and when you get back to your desk, you may read it again to remember why you picked it up.

I also carry business cards, so that people have a way to contact me particularly. I serve as an information conduit between people thinking about how we could solve their problems, and the folks on my team who can definitively answer their questions. So if you say to me “Heidi, I’d love to do feature management, but does it respect semver?” I give you my card and you write me and then I find out yes, we have that coming in this quarter. Yay!

And, of course, I keep a few sets of LaunchDarkly stickers that are not mixed in with the general chaos of The Sticker Bag, so that I can hand them out to people as we are talking about LaunchDarkly in particular. For reasons that mystify me, while Moo has excellent card holders for their tiny cards and business cards, they don’t make ones for the postcards in either size, and looking on Amazon and Etsy was just a journey into despair and disambiguation.

So I expensed some materials and made my own, and as soon as I sort out my authentication with Instructables, I’ll post the process, but look, I made a card holder for all my cards!

Navy leather card holder in clutch size Card wallet interior, with postcards, stickers, and business cards.

The postcard side is gusseted so I can stack a few postcards in it, and the business card holder side can also hold stickers. And the whole thing is sized to fit in my hoodie pocket, because that’s what I’m wearing 95% of the time I’m on a conference floor.

What I Don’t Hand Out

T-shirts. Such a nightmare, because they’re bulky and sizing is variable, and I’m traveling light. If you want a t-shirt, write us and we will ship it to you. 😉

Socks. Because we don’t have any yet, but I continue to hope that we will get socks before the technology sock craze (Started by StitchFix, those cunning geniuses) dies out. I love tech socks. At last count, I have 22 pairs of tech socks, and my current favorite pair is from because they come in a version that has SCREAMING CORAL as the cuff color.

To Sum Up

When interacting with people, it’s nice to give them something tangible, but not burdensome, so they remember you fondly. Also, I’m glad I bought a sewing machine, even though it’s one of the three weeks a year a fat bike would be useful.

Well, that didn’t go like I imagined

The Toggle Talk

As a speaker, there are three things I count on to give a talk:

  • Slides
  • Narrative flow
  • Speaker notes

My dependence on these elements decreases as I give a talk multiple times, but I use the slides to help me remember where I am in the narrative even if I don’t refer to the speaker notes often.

This fall, I designed a new talk and built it in Twine, a game engine for choose-your-own-adventure games. Each slide was actually an HTML page rendered by the game engine, and the narrative was supplied by the audience choosing from several options. This was a radical departure from my usual method, but I’d practiced it, and tuned it, and wrestled with the CSS and I felt pretty confident I could make it work, even though I wouldn’t have speaker notes or a unified narrative through-line.

Because I hadn’t solved the hosting problem yet, I needed to “play” it from my laptop, but that was no problem – I had a USB-C to HDMI adapter. The talk before mine ran long, but I only have technical problems a tiny handful of times in my talks, so I didn’t think I’d need much time to get set up.

I had reckoned without the USB-C/USB-3/HDMI problem, because it had never happened before. I always present from my ipad, and it’s usually a rock-solid toolchain. So I get up there, I’m rushed for time because of the talk before, I’m nervous because it’s the first time I’m giving this talk, and because it’s so “weird”, and…. it failed. The combination of cable/laptop/projector failed so hard that my computer rebooted and came back looking weird, and I had to accept that I might have just bricked my brand-new work laptop, in front of an audience, in a talk that had already technically started.

I had no slides.

I had no notes.

I had no narrative.

I had practiced, but I had not practiced the complete failure scenario, because it had never occurred to me that it could fail this hard.

I still managed to pull a coherent technical talk out and I only ran 10 minutes short, and honestly, it’s one of the accomplishments I’m proudest of in the last year. Literally everything went wrong and I still delivered value.

Afterwards, when I was trying to quietly dump adrenaline, I could only think about how I had failed to achieve any part of my goals. My hands were shaking, my throat was tight, and I felt a little like crying.

That wasn’t how it was supposed to go!

Later, I got to talk to people who had been in the audience, and they asked questions that they could have had if they’d gotten the real talk. That was cheering. I joked that this was the worst this talk could possibly go, because there wasn’t anything left to fail!

Then I got the speaker evaluation cards, and people were universally complimentary about my poise under tough circumstances. It hadn’t felt like poise, it felt like literal flop-sweat, like a drip from my shoulderblades to my waist. But they couldn’t feel my sweat, they could only experience my description of a brand-new talk focused on something that they had to imagine.

The webinar

One of LaunchDarkly’s goals for the year is to nurture and encourage customers to feel comfortable telling their stories, whether on stage or in a blog post. To that end, we are offering some people speaker training. Remembering my fall experiences, I solicited nice people on Twitter to come to a beta of my talk. That would give me a chance to try out the tool, the content, the process, before we offered it as a finished product.

I learned so much! Almost all of it was a little painful.

  • I need to log in early because I’m a panelist, not a host, so we need to coordinate that so I can show my slides to the webinar.
  • I did test my A/V setup!
  • I didn’t realize how unnerving it would be for me to talk to dead air. For all of my teaching/preaching/tech talks, I’ve had an audience. I can make eye contact with them, hear them start to fidget if they are checking out, notice their grins and twinkles and coughs to stay connected to them. But obviously, none of that happens when I’m talking into a headset with the audience on mute.
  • I need to do some work on the content. Not too bad, but I always have to give a talk at least once to live humans to get the suck out.
  • The lack of response makes me so nervous I talk even faster than usual. SLOW DOWN, ME.
  • I have to figure out a better way to wrap up/end the webinar. I didn’t think about how to tie it up neatly, because talks work differently.

So this is all great. When I do the webinar “for reals”, those are all mistakes that I’m not going to need to make because I know where they are.

The meta-lessons

  • It is hard to predict how you’re going to fail, but it is possible to build in a reasonable degree of redundancy.
  • Tests in isolation are not going to catch systemic problems.
  • It is better to degrade what you provide rather than failing entirely.
  • Test with a subset of users so you can predict how your solution will scale.
  • Don’t get so distracted by your failures that you fail to notice surprising data or silver linings.*

* One of the most beautiful night skies I’ve ever seen was on a winter night in the middle of a widespread blackout. I was stomping across the yard to get firewood, and I happened to look up and see the stars without light pollution. A lot of things had gone wrong, but if they hadn’t, I would not have had that moment of starlight bright enough to reflect off the snow, and the milky way like a second snowy stripe in the sky.

Packing, optimizing, and satisficing

I’m off on a two-week trip that happens to be broken by an 18 hour stop at home. (Nodevember, North Bay Python, SpringOne Platform, LaunchDarkly writing sprint). Every couple months, I try to clean out my bags entirely, get rid of the trash that accumulates, make sure that I have room for all the new fidget spinners, that sort of thing. This time I thought I’d share what it is I take along.

In summary, if you are at a conference with me and need Imitrex, Immodium, condoms, period supplies, emergency protein, or stickers, I’m your gal.

Continue reading

Lady Conference Speaker Talk Wrap-Up

I was talking to Bridget Kromhout about her wrap-up process, and she inspired me to a) do a better job publishing my talk information right after I give it, b) talk about my end-of-talk process.

So, you have pitched a talk, gotten it accepted, written it, gotten on stage and given it, and answered any questions. You are about to come down off the adrenaline high and start second-guessing what it is you said. It is totally normal not to be able to remember exactly what came out of your mouth. Depending on how nervous a speaker you are, you may not have formed any particular memories, because we are terrible at forming coherent memories when we’re scared.

The slot after your talk, or the evening after, or the flight home, you want to publish your talk wrap-up. I think the ideal wrap-up consists of the following elements:

  • Your slides
  • Twitter reactions
  • Follow-up answers
  • Research sources/bibliography/image sources
  • Video

I do almost all my slides in Google Slides, with Slides Carnival. I do a new set for each talk, since I’ll end up adjusting length and emphasis for each conference. Immediately after I give the talk, I tweet out the public link to them. My slides also have extensive speaker notes.

The next few steps are much easier if you use Storify, an app that plugs into your browser. When I am researching a talk and have a reasonable belief that I’ll be using a page as reference, I click the Storify button to add it to my potential elements. I can also use it to capture tweets that will be relevant. After my talk, I’ll open Storify and look for tweets about the talk, whether with my Twitter handle, the conference hashtag, or the talk hashtag. I drag all the relevant tweets into the story about this talk at this conference, organize them, and then add the link to the slides at the top and the reference elements at the bottom. Then I click publish. I can always go back and edit that Storify to add the video when and if it’s ready.

In WordPress, Medium, LinkedIn, and several other platforms, you can embed Storify stories as part of the post, to raise the visibility and make sure it’s part of your platform as well as Storify’s.

Keep an eye out on your email. Conference organizers are quite likely to ask for your slides so they can sync them to video or publish them on the conference site.

There are a couple places that I want to improve my process — I have seen webpages that have two columns – one for the text of the talk and one for the slide. I feel like that would improve my web presentation and make it more accessible, but I have yet to find the WordPress/CSS magic to make it happen. Everyone I know who does it has hacked their own, and I want a turnkey solution.

I also want to start dedicating some money to getting talks professionally transcribed. What I write out and what I actually deliver are similar, but not identical, and again, I want to improve access for people who can’t or don’t want to watch video.

Here’s an example of one of my talk writeups:

Our tools shape our worldview, or Least-bad Confluence techniques

If you have been in a conference open space with me, you know that I make a terrible yuck face whenever you ask me to talk about working with Confluence. I have yet to work with an instance of Confluence that didn’t make my soul hurt. But it’s not really the technology’s fault if I hate it, is it? Isn’t it about implementation? Aren’t tools essentially neutral?

Yes and no. We talk about opinionated programming languages, but every tool has an opinion about how it should be used, a happy path. For example, the WordPress mobile app is great, and I love it for composing blog posts on the go – that’s what it was made for. But I would find it really irritating as a progress tracker if I tried to use it to replace Trello. Trello thinks in tasks and it’s hard to get it to show you the overall picture of a project. We can go through our whole toolchain like that — each piece of software we build or buy has a way it wants to be used, and although we can hack our way around that, it’s always going to be. more friction than using tools as they were intended.

Problem space

I’ve been to many DevOps Days in the last couple years, and I keep seeing the same pattern of problem.

  1. Documentation exists…somewhere, but no one can find it.
  2. People write documentation and no one can find it.
  3. Documentation is scattered across many locations and no one can find the parts they want.
  4. Standardizing or consolidating the documentation seems impossible because there’s so much of it, in so many places.

This is almost always in a Confluence shop — some people are using other wikis, some people have Word files, but the problem is really recurrent in the Confluence-using places.

Possible solutions

I have some suggestions for how you can make this better in your organization.

  1. Install a better search engine. The one that comes with Confluence is remarkably unhelpful at surfacing current, relevant data. It says it’s searching on relevance, but the returns are difficult to read and frequently so outdated as to be unhelpful.
  2. Break your silos. One of the ways that Confluence is opinionated is that it’s designed to work in silos. Development doesn’t automatically see marketing. Sometimes, this is intentional access control and sometimes it’s just an artifact of thinking in organization charts. Either way, it keeps people from being able to efficiently share information within a company. If you are setting up a wiki or CMS, make it as flat and open as possible. Separate items by task, not job title.
  3. Delete about half of what you have. If you do an analysis, I bet you’ll. find that there is a lot of outdated information. I don’t know what it is about wikis, but they are amazing as graveyards of information that has expired. I think it may be because web pages get refreshed periodically, but it’s been true of every wiki I’ve worked with that there is a bunch of old, wrong data.
  4. Put in analytics. See what people are actually using, and what they’re looking for and not finding. That’s how you know where you should focus your first efforts.
  5. Have one clear purpose for each document: Is it to help tech support answer questions? Is it to document the deployment process to increase pager duty depth? Setting a clear goal for you documentation lets you check everything against that standard.


Of course you can’t implement all of those solutions. Not now and maybe not ever. But you can do some of them whether or not you have buy-in from the rest of the company. Define the purpose of your company and your job and your documentation. Once you know that, you can start working toward it. Next, let the analytics run for a while, and put together a report on them.

When you realize people are trying to search on something that exists and they can’t find it, upgrade your search engine. Once your team is actually using search, you can use the same analytics to strip out low-value or never-used data to make room for more.

What do you think? What tool have you noticed changing your thinking and process? This is one of the reasons I love Monument Valley – while it has predictable rules, it also plays with the dimensions of 2D and 3D space, and it surprises us with optical illusions based on the way we portray dimensional things on a flat screen.

Let’s think about how our viewpoint is constrained by our software, and whether we can spin our point of view.