A small succulent plant with the San Francisco skyline in the background

Crosspost: The Recompiler Magazine, Issue 8: Build Your Interviewing Strategy

I’m a huge fan of The Recompiler, and not just because they sometimes publish my work. I support anyone who spends the time and effort to publish articles that are useful, thoughtful, and frequently action-oriented.

Carol Smith (of OSI board fame) and I put together a workshop for people who are doing technical interviews for the first time. We called it “The Hardest Part of Tech(nical Interviewing) Is People”. We’ve given it a couple times, and we’re hoping to do a recorded version. This article is part of what we talk about in the workshop – how to look over your past experiences, even if they weren’t in technology, and make them relevant and applicable. We hope this helps you!

Build Your Interviewing Strategy

And in conclusion, support your local publications!

The Recompiler Magazine

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.

Slow is smooth, smooth is fast

If you recognize this mantra, you may know it comes from marksmanship training. The idea is that it is better to move slowly and not have any hitches or unexpected bumps, rather than to hurry and have a less predictable outcome.

Another way to phrase this is

You don’t have time to do it right, but you have time to do it twice?

There are lots of obvious applications for this philosophy in technology, but I’ve been dealing with it in a much more tactile realm – handwriting. I’m one of the cusp generation that got taught cursive and typing in school. I obviously type much more quickly than I handwrite – most people do, or we wouldn’t have invented typewriters. My kids got some very minimal cursive education, but mostly so they could read it, not write it. No one is grading their penmanship and most of their assignments are turned in on Google Docs. When I was learning cursive, my teacher told me, and I believed, that it was because it was faster than printing.

In the last month or so, I fell down a hobby rabbithole and took up fountain pens. The DevOpsDays Vancouver people gave out a lovely writing set as a speaker gift – proper fountain pen, ink, high-quality notebook. I found out that what the nerds on the internet have been saying is true – writing with a fountain pen is a significantly different experience than a ballpoint or even a rollerball. Fountain pens finally made the point of cursive writing make sense to me.

It turns out that some methods of communication are tuned to specific tools.

Who knew, right? So I spent all of my grade school cursive time frustrated because cursive didn’t feel any faster to me, and I would get lost in the middle of a letter or a word, and aaaaargh. Which has made it really funny to take up learning not just “how does a fountain pen even work”, but also “Spencerian Penmanship” (which, the purists would like to inform you, is not calligraphy). It turns out that 10 year old me had a few compounding problems:

  1. Not enough time/practice to gain mastery. I’m a notoriously slow learner of physical skills. It took me 3 years to learn to ride a bike. So learning time that was probably enough for my peers was not enough for me.
  2. Attention problems meant that I would literally lose focus in the middle of a word, or forget how to form letters, or try to move faster than my muscles were prepared to go.
  3. I did not find it intrinsically rewarding.

Now that I’m an adult, and I can afford not only the proper tools (relatively cheap), but tools that I find exciting and fun (less cheap), I feel more rewarded. I am not trying to turn in a homework assignment, I’m just learning a skill, so the time and accuracy penalties don’t apply. Unsurprisingly, I have better handwriting when I slow down. And as hobbies go, this one is really easy to pick up and put down, even more than knitting.

I also have learned years of skills in how to teach myself things, how to self-correct and do mindful improvement. Because I spent so many years as a solo writer, I had to learn to look at my own work, iterate, and improve. That basic skill now serves me for all sorts of things in my life. As a result, I now understand the value of drill and practice. Even if it’s not fun.

Handwriting practice sheet

The first thing to do is draw lines

I used to feel bad about my hobbies – sometimes I’ll get really into something, and get all the equipment to do it, and take Craftsy classes and and and… and then a few months later, I’ll drop it. I would punish myself when the next passion came around. “Remember embroidery? You have all the equipment and you only ever finished 2.5 projects. No, you don’t get to do the fun thing!”. I’ve been easing up on that attitude. I mean, I do try to start with a minimum viable kit for what I want to do, but if I enjoy it, I’ll dive in. Why not? I have an allowance for frivolities, I’m not hurting anyone, and it makes me happy to learn things.

Practicing one letter over and over to refine what I want and learn the motion

All hobbies are fractal, when you start examining them. I’m not sure the same is true of work, or maybe it’s just that deep expertise is less easy to share. So for the top-level hobby fountain pens, the fractal might look like this:

  • Handwriting
    • Penmanship
    • Calligraphy
    • Hand-lettering
  • Ink
    • Purchased
    • Hand-created
    • Mixing
  • Pens/Hardware
    • Prestige collection
    • Hacking/fixing
    • Restoration
    • Design

Each of those could be pursued further and further into tiny corners of specialized interest. That’s amazing. Seriously, thank you, internet. Hobbies are fandoms, and we can all find a place that suits us somewhere. I figured out that I love road cycling, but I hate bike maintenance. I can pay a shop to do that. There are other people who love tinkering, tuning, and upgrading their bikes. I like piecing quilts, but consider hand-quilting tedious. That’s ok, I can be a machine-quilter.

Once I thought of hobbies as fractal, I realized that we could not only drill down into sub-hobbies, we can back out to get a bigger picture of why we want to do hobbies, and it gives us an insight into why we want to do anything.

I like learning things. It gives me a feeling of satisfaction and control in my life. I feel about new ideas like a magpie feels about shiny beads. This basic tendency really accounts for most of my career – I used to joke that technical writing is a lifetime of writing research papers, but it’s not far off. It’s more like journalism, but the reporter is still going to walk away knowing more about the story than ever makes it into the paper.

My hobbies are a way for me to nourish that passion in a way that is good for me, as well as an employer. Sometimes I want a tactile thing to do when I got back to a hotel room in another city, completely worn out from people. Sometimes I need to remind myself that the difference between art and craft, work and hobby, is about how much you get paid, not how valuable it is. Even magpies can only pick up so many shiny beads before they really just want a break and some tinfoil.

What does that have to do with marksmanship? Everything. Because slow is smooth, and sometimes we need to move slowly to appreciate and learn what we need. Because smooth is fast – it pays to think through what we want to say and write before we commit it to ink. Because everything we do to learn a hobby is itself a way to learn the skill of teaching ourself.

This job is undoing me

… in the best way possible.

My protective casing of hard-earned cynicism is being rubbed away by all this genuine kindness, cooperation, good culture, and all that jazz. It’s honestly kind of uncomfortable, like molting.

You need to understand – I have this hard-ass candy shell for a reason. My first job in technology was 1996. My first college boyfriend introduced me to BBSing through what we would now call a troll community. I have been “one of the guys”, and “that girl”, and “the writer, whats-her-name”. I have gotten my ass grabbed at work and gotten dirty texts and chats from co-workers and been propositioned in creepy ways at conferences. The technical writer is hired too late and fired early in the startup process, but I love startups. No company has ever previously make me feel like I have valuable things to contribute and they consider themselves lucky to have me.

I thought at first it was perhaps due to the change in my role, this exciting new job title that means I never have to write release notes, but today I realized that it wasn’t that. I was walking with the new person on my team, and trying to download to her what I’ve learned about the company and the things I asked about and can just tell her.

  1. You will not get fired because The Internet Hate Machine is angry about something. We know about the internet hate machine and don’t consider them valuable feedback.
  2. No one is going to yell at you if you mess up your expense accounting, especially at the beginning. We’re all working from a place of mutual respect and shared interested and assumed good intentions.
  3. You are not required to sacrifice quality of life to save company money. Be reasonable, stick to the budget outlines, but it is worth a hotel night to have you bright and functional instead of trying do do a conference after an early morning flight.
  4. You have time to learn your job. We’ll be happy as soon as you contribute, but you need time to ramp up and that’s expected and normal.
  5. It’s ok to ask questions. No one expects you to know everything, we hired you because we think you have the potential to learn. Very few of us knew about this technology or industry when we started. You don’t have to know it all when you start.
  6. Maintaining human relationships with your coworkers and other people in our ecosphere is important, and will be counted as work, not fluff.
  7. If something happens at home while you’re on a business trip and you need to leave, it’s ok to just leave. No single event is more important than your outside-of-work life.

How am I supposed to maintain a cheerful cynicism about people who genuinely like working together and also sometimes hanging out at tea parlors with a kid in tow? How is my cool detachment going to go when I get raises and positive feedback without even asking for it? What if it doesn’t feel like high-stakes gambling to be able to bring my whole self to work, even the wacky futurist parts and the parts that can’t code and the parts that are noisy feminist politics? What if “being me” is not high stakes, but table stakes, for everyone?

This job is breaking me because all of that shielding and cynicism were adaptive for other companies, but not actually very useful at this one, and in order to succeed here, I need to take all that armor off and be real, and vulnerable, and let people help me. It’s terrifying, and I wouldn’t have it any other way.

@wiredferret is so composed, informative, and present as a speaker

I Have Something To Say

That was the tagline for the late lamented Technically Speaking organization, and I really like it because it captures one of the really important parts of speaking – all of us have unique insights and perspectives, and even if you say something, I still have something to say that will be different.

As I learn and grow in the craft of speaking and giving talks, I have been thinking about what it is that I’m trying to achieve, what I would consider growth and leveling up. It’s important to not rest on our previous accomplishments – that leads to stagnation and that miserable stuck feeling.

I want to improve my delivery. I want to improve my slide construction. I want to branch out into different types of conferences. And I want to give a keynote.

When I told my manager this, he challenged me to identify what it is about a keynote that I want to have, that makes it different from the talks I’ve been doing already. After a bit of thought, I realized that the nature of a keynote means that you have a chance to talk to an audience who would not normally select your talk in a multi-track conference. No matter how good my documentation talk is, only people who care about documentation will choose to attend it, even though the people who need a documentation talk may not. I want to reach that reluctant audience, the people who don’t think they need to be in my talk.

What is a keynote?

In a technical conference, a keynote is addressed to the entire conference, and usually happens at the beginning or end of the day. Keynotes are thematically linked to the conference, or are presented by “big names”. They are the one experience you can expect everyone at a conference to share. Even single-track conferences have keynotes – they might be longer than the rest of the talk, or include a special introduction, or the speaker might be a promotional pull.

By content, a keynote either has something relevant to the community, like Matz’s Ruby updates at RubyConf; or it’s something that is broader than any one kind of technology, like Carina Zona’s “Consequences of an Insightful Algorithm”.

Organizationally, keynotes are almost always invited, rather than being part of the CFP/application process. The organizers select speakers and reach out to them with a specific invitation. The topic may be negotiated, but keynote speakers traditionally have a lot of latitude in their topic choice.

How might I get one?

Keynote elements

I think there are three elements involved in being invited to give a keynote:

  • Professional reputation
  • Proven speaking and delivery ability
  • Timely, relevant topics

I feel like I can work on all of those points, in different ways.

My professional reputation will depend on me continuing to do what I do as well as I can – speaking, teaching, mentoring, coaching, being available to help people with their needs whenever I can.

Speaking ability – I only have a smidgen of training in this. My high school didn’t have speech and debate, I didn’t participate in college, I’ve been pretty much getting along with a lot of self-education. I am thinking it might be time to get some real training and coaching. This is probably the aspect that scares me most — it’s really hard to get coached on something, especially if you think you’re pretty good at it. But it’s a way to get better, just like watching the talks I’ve done helps me get better, even though I really hate doing it. If you watch yourself speak enough times, you sort of burn past the shame and get to the place where you can improve by watching.

Timely topics — You always have to lead your target, and I want to put together a couple proposals for general-interest topics that haven’t been extensively covered yet. More on that later.

What I’m going to do

So my plan is multi-part. It all is underpinned by me doing a lot of work to remind myself that it is ok to publicly want a thing and publicly talk about wanting it. That’s hard to do.

Ask

I am trying to talk to all the people I meet in my conference rounds about wanting a chance to keynote. This has three effects:

  • It gets people to think of the possibility of inviting me
  • It normalizes people asking about keynoting, especially if they aren’t in the normal demographic of CEO/powerful person/known famous coder
  • It teaches me more about how to ask for big things, and gives me more experience in doing slightly anxiety-inducing things.

Write

I need a couple topics to tease people with – things that are interesting, timely, and appropriate for a larger audience. Here are the two I’m thinking about, in CFP pitch format

Master Builder and the Growth Mindset

A lot of us got told we were smart growing up, and looking around at our pretty nice lives, it’s easy to believe that. But what if I told you that you are successful despite this compliment, not because of it? It’s bad for our sense of experimentation and willingness to fail to be told that we’re smart. We tend to gravitate to learning and doing things we’re good at with less effort. We avoid things that we won’t be good at instantly because we don’t know how to be mediocre.

Getting into technology is like being able to assemble a Lego set – there are easy instructions, you assemble the modules, and you end up with what you saw on the box. But not all of us are issued a box. Some of us have had to learn to be master builders, able to design and construct new and weird things that are not part of the kit. This experimentation and improvisation can provide us with flexibility and insight in a rapidly-changing industry.

This talk is intended for people who are interested in designing and working on teams full of people who value experimentation as well as execution.

Everything Is A Little Bit Broken
-OR-
The Illusion of Control

Humankind is extremely superstitious and we are operating systems way above our actual level of comprehension. To keep our limbic systems from freaking out, we have a set of beliefs that makes us feel like we have control over things that happen around us – but are we right? Let’s talk about how error budgets, layered access, and function over form are the building blocks of the ability to get on with work without decision paralysis.

This talk is about how we shift risk around with both process changes and magical thinking, and how we can use our tendency to be fearful to actually make things safer, instead of just feeling safer.

This talk is intended to challenge and shake up people who think that failure is a single state or that doing everything right will lead to predictable results.

Study and Learn

I’m going to find myself a speaking coach, or maybe a course. Something to take what I already have and polish and refine it. No one knows how to do a triple lutz on their own, and coaching is the difference between talent and success. Like I said, this is really hard for me. Like a lot of gifted kids, I’ve gotten a long way on sheer talent without having to be bad at something. Luckily for me, I also have spent sometime sucking at things, being coached, and getting better. It took me 6 years to learn to serve a volleyball overhand, but I got there. I want to level up my speaking from “good enough/pretty good” to “reliably excellent”.


It’s a big goal, but I think I have a good plan in place, and I’ll let you know how it goes.

Welcome!

Teaching and learning

At LaunchDarkly, we’ve been hiring really aggressively, because we’re doing amazing things. (Come work with me!)

That means that we are also doing a bunch of training, and I’ve been working on doing the training for our non-technical employees, folks like marketing, design, outbound sales. They’re important to our success and they have a TON of domain knowledge that I don’t have, but we’re all going to work together more successfully if they know what they’re selling. Also, selfishly, the more people who can help work a table at a conference, the easier it is for everyone working at the conference.

Me, I’ve been doing tech for 20 years, at all levels, including hardware through to cloud. I bring a ton of domain knowledge with me every time I start a new job. But for this training, we need to explain enough about the software lifecycle to be able to talk about the problems that LaunchDarkly solves. That gave me a chance to really dig in and figure out how to explain the basics in a way that’s useful to people who haven’t been accidentally drinking from the devops firehose.

  • What are developers trying to do? What does their work life look like?
  • What is deployment and how is it hard?
  • How does software get to the user?
  • What are waterfall and agile and how does that relate to us?
  • What are APIs, SDKs, CDNs, CI/CD, devops, feature flags, polling and streaming updates?
  • What’s a monolith vs a microservice?
  • Why wouldn’t everyone just build their own software?
  • What is Software as a Service?

It was satisfying to realize that I can define and describe all of that in pithy and accessible terms for people. It’s the same thrill I get from writing a really solid document. I know that I am helping actual humans by describing something they need at the moment they need it.

I hadn’t thought about internal training as being part of my job duties, but when we realized we needed it, it seemed logical and easy to do it. After all, my whole purpose is explaining the product to people, and understanding and explaining people’s pain points to my company. This is a natural fit. Plus it was super fun!

In my infinite free time, I’m thinking about recording these explanations with a couple slides, so we have bite-sized concepts when people want to look them up.

 

Screaming in the Cloud with Corey Quinn

Corey Quinn, slasher of AWS bills and frequent conference speaker, had me as the first guest on his brand-new podcast, Screaming in the Cloud. We had a great time talking about feature flags, the all-iPad conference setup, testing in production, and how I feel about technical documentation.

And if you’re like me and don’t always have time to listen to podcasts, there’s also a transcript!

(This is the third time I’ve been asked to help kick off a podcast. Feel free to ask me for your own podcast!)

Guest post: UX Booth

I wrote a 2018 User Experience Prediction at UX Booth. Amy Grace Wells asked me what I thought was going to be a leading theme in UX in the next year, and I said, “better accessibility”. I think that’s both a serious prediction and a hope, because there is never enough accessibility, but I also think we are getting better.

So many things that are designed for accessibility, but that we don’t always understand that way when they happen, and frequently we mock them as lazy or luxurious. Backup cameras on cars seem silly – why not just turn around? Until you physically can’t turn around, and then you realize how much they matter. Pre-chopped vegetables, electric can-openers, and velcro shoes seem laughable – unless you’ve ever been unable to hold something in both hands at once. In the same way, building web and mobile apps to respond to a variety of command styles may not occur to us if our fingers are nimble or our voices clear, but will matter immensely to people who are not in that category.

Since before I was employed at LaunchDarkly, I’ve been fascinated by the ability that feature flags offer designers to customize user experience. We haven’t had a good test case yet that I know of, but it will come, and I’m looking forward to it.

Peeled oranges in plastic containers

Pre-peeled oranges for accessibility

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 Sentry.io 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.

When the cat’s away….

…the mice will self-organize?

My manager is on vacation. Like really a lot on vacation. Logged out of Slack, not on email or phone, not showing up for meetings, none of that. This appears to be what he’s doing:

Hawaiian beach

And he’s been gone, like weeks. OK, I think it’s 2 weeks. But it is significant and meaningful, even during the weird holiday bit at the end of the year.

I have several observations about that:

  • I would like to keep working places where management gets significant breaks and takes them as breaks. It means that I also feel ok taking time off, even though it’s sometimes a little harder for my co-workers when I’m gone. Culture does come from the top, and when your culture involves actually having a life outside of work, it shows.
  • When the person you usually get your answers from is not around, you’re forced to develop alternative sources of information. This is great in a lot of ways. You don’t get rigid about your information, and the organization practices redundancy.

When you think about it, real vacations are chaos engineering for teams.

  • We did find a few little glitches in the system, things that we can either fix ahead of time or work around for next time. For example, he’s the one who schedules our retrospective, it’s not on a set day. None of us know what the parameters are. But we just didn’t have it, and next time we can set it up so it’s not a deal. Iterate.
  • On a psychologically safe team, it’s ok to make decisions without your manager around. I pushed a deadline. A coworker told me her priorities for my work. I worked with a team mate to decide where to allocate money in the coming year. It felt safe to do that, because we can trust that when our manager comes back, he’ll be glad we did our jobs instead of waiting for him.
  • The last email he sent before he left reminded us that he trusted us to do our jobs, that we could ask each other for help, and that it was ok to go to the management team if we had a need. What more could a person ask for? Autonomy and trust go so far toward making us the best and happiest we can be.
  • He’ll be a better manager for having taken time to stare at the sun and the sand without looking at a computer screen or performing work emotional labor. It is exhausting to do hiring at our current pace, because hiring is hugely emotionally intensive, if you’re doing it right. Him taking care of himself means that those of us on his team can trust that he will be available to us when we need him. That’s good planning.

So many of these observations can be summed up as trust. Leaving your team takes trust. It’s important to be trusted to do your job without close supervision. It’s really really important to feel valued without feeling like you’re trapped or obligated.

Being essential is not the same as being valued.

Have a great vacation, boss! We’ll catch you on the flip side.