The virtuous thank-you cycle

We talk a lot about vicious cycles, and how it’s easy to end up in bad places because the incentives are all bad, but let me tell you a story.

It’s a pleasant Saturday, my family is watching Star Trek: TNG together, and I’m in my home office, working on a side project and slightly resenting it. It’s the collateral for a workshop Carol Smith and I are giving at LISA about the non-technical part of interviewing, and we think it’s really an important part of helping people get jobs. So the workshop will be great and important, but I’m currently wishing I was doing something else. And then this comes across my twitter:

Marie says she uses the principles I espoused in that talk even when she starts side projects, like Call My Congress. Because she set it up to be easily localized, anyone could come through and easily add instructions in Spanish or Somali, without having to fight the project to do it.

I gave that talk 17 times. I took it to a different continent. I got most of my expenses paid, and I got an honorarium exactly once. I figure I spent 60 hours researching and writing it, and and 3-5 hours in prep and rewriting each time I gave it. I was working for myself, so no one paid me for that time.

A thank you note like this makes that all worthwhile. I give technical talks for the same reasons that novelists say they have to write – because it’s something burning in me, and I need and want to share everything I have learned the hard way so that other people don’t have to. In my grandiose moments, I think of it as reducing the entropy of the technical world, giving people a boost up the ladder. Most of the time I think it’s funny that all of my teacher-mother’s children have found our own ways to teach, far from school classrooms.

Now I have a job that pays me for development time for talks, and means that travel and conferences are not lost productivity for me, and that means the world to me, but most of the technical speakers you see at conferences are like I was — working evenings and weekends and taking vacation time to battle entropy with education.

I’m going to try to remember to do better about saying thank you, and thus spread the cycle of appreciation further and wider. A virtuous cycle perpetuates because the rewards are so good. Thank your mentors, and the friends who want you to expand your horizons, and the organizers who make safer spaces to speak in, and the bosses who don’t make you take vacation days. Thank them publicly and specifically.

Think Globally, Sponsor Locally

Possibly the most exciting thing about my new job as Developer Advocate (there are so many!) is that I don’t have to scramble and ask conferences to fund me anymore. That means that speaker funds can go to the next generation of up-and-coming speakers, independents, and folks who don’t get paid to go to conferences.

It also means that the conferences I go to is not a set restricted by people who can afford speaker sponsorship. I have had to turn down acceptances I was excited about because the conference just couldn’t afford to make it happen, and we were all sad. They wanted to have a range of speakers, I wanted to talk to their audience, but the cash just wasn’t there.

What does it mean to sponsor a conference, as a company? Well, you get your name on slides and promotional materials. Sometimes you get a couple minutes to tell people at the conference what it is you do. You get intangible benefits in good will from conference organizers and attendees. That’s all pretty hard to quantify. But just because something is hard to quantify doesn’t mean it isn’t worthwhile. The conferences you choose to sponsor say a lot about your values as a company. Sponsoring small, inclusive conferences is a relatively meaningful statement. You’re saying you care about the community, and about having a code of conduct, and about nurturing emerging or niche technologies.

Think about sponsoring at a huge conference, like AWS re:Invent. 30,000 people showed up in 2016. Logistically, and in every other way, that’s massive, and sponsorship is expensive, and the impact your company will have is dilute. You’re trying to get the attention of the people in your demographic, in the middle of a vast sponsor hall, in Vegas. You may get enough people to make it worthwhile, but it’ll be hella expensive.

Now think about sponsoring a DevOpsDays conference. Minneapolis is huge, at ~1300. There is a vendor room you can walk in half an hour and the people at the tables have time to talk to you, and are maybe giving a relevant talk. It’s a regional event, so if you’re an employer looking to hire, it’s great to find people, because you know they are already invested in the tech, and are in the area. It’s a way to connect with your community, and I don’t have the numbers to prove it, but I’m going to bet it costs companies a lot less than schlepping enough people to represent at the table to Las Vegas. Target was there, and Merrill, and Optuum. They’re signalling that if you work for them, they care about devops and you might get to go to local conferences, and they’re engaged. That matters a lot! Target is still doing rehabilitation on their local reputation after a set of bad decisions around IT, so it doesn’t hurt to have them showing up and working to be better citizens.

As a company, you should also think about sponsoring really small conferences – the 200-400 range, or even local user groups and meetups around your technology stack. Don’t do it because there’s an immediate payoff, or because you can chart a rate of return, but because it’s the right thing to do to nurture the community you draw from. The goodwill, expertise, community engagement, and candidate leads you get will be so much more valuable, dollar-for-dollar. It’s not always the decision-makers who go to these conferences, but they will be decision-makers eventually, because they are displaying exactly the go-getter values that you want by going to conferences. Think of this as contributing back open source code that you refined in house, only instead of features, it’s cash. Sponsoring these small conferences gives people who can’t travel a chance to meet and aspire and network and connect, and that’s immensely valuable to the circle of practitioners in an area and to the development of the technology as a whole. Working for a big company should not be the only way a brilliant Python developer can make connections with her peers.

I was inspired to write this because North Bay Python is looking for sponsors, and because Alterconf has been an astonishingly effective incubator for speakers, and is ending soon (but you can still say you helped!). I wrote it because I’m going to SeaGL, and they aren’t charging attendees at all. So many of my meaningful conference experiences have happened at conferences that are accessible to everyone, not just people with corporate budgets. Also, if you think about it, conference organizers are like the definition of social superconnectors, and they have Quite Strong positive associations with people who give them money to make the magic happen.

So what can you, a technical writer/developer/ordinary person do about this?

  • Talk to your marketing team about what matters to you. They are very smart, but not psychic, and they would love to hear about ways their sponsorship dollar could go further.
  • Volunteer for local conferences if you can. It takes a village to fold t-shirts.
  • Ask if you can spend recruiting money to sponsor conferences that specialize in the skills you’re looking to hire for. Looking for a functional programmer? Sponsor moonconf.

If you’re running a small-to-medium conference, reply here and I’ll try to put together a link roundup of conferences people could consider sponsoring. Don’t @ me if you don’t have a Code of Conduct, though. It’s 2017, people.

Also? Vote for your local school bonds and levies, while I’m advocating for spending money on systems thinking.

Also also? AWS Re:Invent? You’re charging $1600/ticket and you can’t provide childcare? Really? I mean, it’s not as bad as Grace Hopper. Don’t even get me started on Grace Hopper, but still.

Writing exercise

As a developer advocate for LaunchDarkly, I need to understand the product in a bunch of different ways – at a technical level to give summaries of how to make integrations work, at a business level to explain how feature flags can save time and money, and at a rhetorical level, so I can quickly gauge my audience and explain it to them in the most efficient way possible. Usually when I start a new project, I’m elbow-deep in documenting how it works and I have to work backward to why people want it to work one way or another. But this time I have the luxury of learning why a product adds value first.

I wanted to make sure I was grasping it, and as my friend Laura’s dad use to say to doctoral chemistry candidates, “If you can’t explain it to this ten-year old, you need to go back and work on it until you understand it yourself.” There is an apocryphal Einstein quote to the same effect. I think the modern version of making sure you really understand something by explaining it derives from Randall Munroe’s brilliant XKCD comic, Up Goer Five. Theo Sanderson built a little text editor with a linter that rejects all the words you can’t use, which is, um, almost all the words. But if you can conceptualize something really clearly, you may be able to describe it with the extremely constrained set of words. Here is my attempt to do so for feature flags:

Computers think in lines. Sometimes we want computers to think in a new line, but it’s hard to change lines all at once. We have to build the new line before we can change to it.

When we build the new line, we give it a cool name and hide it from the computer thinking. When we are ready, we change to the new line and lose the old one. The computer thinks the new line with the cool name is the only line. We can make the computer think with the cool name line or the old line any time. Cool/old, back and forward, when we want.

Sometimes, we want only some people to see the cool-name line. We put them in a cool-name group. Every time the computer gives them a thing, they get the cool-name thing from the cool-name line. Other people still get the thing from the old line. Who is happier? Cool-name group or old-line group?

We try to keep our computers happy and not too busy. Sometimes a new line of thinking takes more work for computers. Instead of making all the computers think the new line at once, which makes them slow and sad, we only tell some of the computers to think the new line. Then we add more and more computers thinking the new line, a few at a time. Soon, all the computers are thinking the new line, but none of them got too busy.

When we are finished with the old line, we make it go away. Now cool-name line doesn’t need a cool name anymore, it is just Line. We change its name to Line. When we want to write a new cool-line, we start over!

I’d love to see the results of some of you explaining your product using a thousand words. It’s not really useful as a way to explain things to people, since we want to teach customers our words and tune our language to their needs, but it’s very useful to show us if we understand something.

Is this the gate you want to keep?

Today on Twitter, I said:

Guarded by succulents

That’s a lot of response for me. Like “Livetweeting @kelseyhightower” levels of reaction. So let’s stop and talk about that for a bit.

Honestly, I wrote the tweet because a group I respect put out a call for coders to help under-indexed coders do something that is entirely unrelated to coding, and I was frustrated.

Developers are not automatically the smartest people in any room, and I wish we would stop treating them like they were. It leads to all sorts of workplace toxicity. Yes, this is about the Google thing. And the Uber thing, and the thousand and one other sexist and racist things we could rattle off.

Certainly, deifying coding is a contributing part of coders acting like they’re little tin gods. Why wouldn’t they be cocky, if everyone they work with acts like their skill is all that keeps the company afloat? Heck, sometimes entire companies are “acqui-hired” just to get a functional team of coders – the supporting cast and the product are jettisoned, as if they had no value.

I’ve worked with several startups, and at a certain stage, investors stop asking about your coders and developers, and start making noises like maybe there should be a manager, or a financial officer, or a CTO who thinks strategically and not tactically. That’s because at some point, coders are people who exist to execute a vision, but somebody had better have a vision.

A vision isn’t just a rosy sales plan – it comes with understanding the industry, the problem space, the user experience, the way other people will see and use and touch the product. It comes with sales and marketing and QA and tech docs and support. If you are not actively courting the best support staff money can buy and paying them enough to show you respect them, you are, flatly, a fool. A good support person can make or break customer retention.

I know a lot of developers, and I mostly like them. They’re smart, and they sometimes have an amazing array of interests and passions, within and outside work. But they’re not magical. You can’t actually multiply productivity with them, and they won’t save your company. They can execute. The really good ones can execute and anticipate your strategy and build toward it. But developers don’t end up leading companies because they’re really good at Javascript. They end up in leadership because they didn’t let their coding skills be their entire definition. They worked on getting better at people, and meetings, and product, and even more people.

So every time you talk about teaching girls to code, or asking coders to help other coders with non-code stuff, or putting on a code school with no exploration of other aspects of software development, you’re saying that there is only one right way to be in technology. That is a narrow gate you’re setting up. I don’t like it. It makes me angry, and not just because I don’t code, but because it devalues the contributions of all the other people who make the magic happen.

It takes so much more than code to make a product happen.

Here’s to the PM who works hard to balance conflicting priorities and goes to dozens of meetings, to make sure things turn out as well as possible.

To the QA tester, who designs and runs endless tests in permutations you would swear no human would try, because there is no one more cynical about human intelligence than a tester, and they’re always right.

To the UX designer, who is so often dismissed as “making things pretty”, when they’re actually “making your product usable”. They run hours of human tests, watching and iterating until your product is almost invisible to the user.

To the writers, both technical and marketing, who spend all their time trying to figure out how to make the product real and relevant and useful to the people at the sharp end of the stick.

To the sales and marketing teams, who really do sweat the small stuff, who are actually kind of sick of fancy dinners and travel and airport seats, but who keep at it because they believe in this product and its ability to solve problems. Also sometimes they make us stickers.

To security, who may actually be the smartest people in the room, but have harnessed it all to righteous paranoia so that we don’t have to sit up every night worrying the way they do.

To support, who spend all damn day talking to people who are angry that something is broken, and still pick up the phone and say “How can I help you?” at the next call. They get everything from eyerollingly stupid user errors to actual arcane and intermittent bugs, and we expect them to know their way around our entire stack to troubleshoot. They know so much about the product and the customers, if only we ever asked.

To sysadmins, operations, cable pullers, and the invisible backbone of our infrastructure. We only notice you when things go wrong, but they go right so much more often, and we never notice the rough spots you sanded over already.

To finance and accounting and accounts payable and HR and company operations, who keep the lights on, and the fridge stocked, and who do get paged at 2 in the morning if the cleaning crew sets off the burglar alarm. I’m looking forward to the day I see an office manager tweet an #oncallselfie. They are amazing, attentive, organized, detail-oriented people, and I’m in awe.

To everyone who brings us food, cleans our toilets, vacuums at 2 in the morning, and otherwise lets us live like petty royalty – we owe you so much, and we are too self-conscious to even say thank you sometimes.

To management. Yes, management. Who go to so many meetings, you don’t even know. They’re out there making tradeoffs and calculations and doing the best they can with what they have and when you think about it, they have zero ability to make any difference in the product. All the responsibility, none of the power, at least in that direction.


The next time you hear someone talk about tech jobs as if they were all coding, stop and think a moment. I don’t want to devalue coding – it’s pretty cool. But I do want to pull all these other positions into the limelight of tech, and say,

“All of us make the product, and that’s awesome.”

Retrograde tooling

We've reached a tipping point in technical writing, and we need to deal with it.

The future is not going to involve producing documents, it's going to be producing seamlessly integrated content in and around products, and that means we need to change our expectations around tooling. This is going to hurt, but hopefully in the good way.

When I started writing, I learned FrameMaker. It was amazing. It had 20 years of history even at that point, and you could do anything with it. Equations, printer's crop marks, swapping text blocks in and out automatically, producing print, PDF, and help files from the same file, complete with changing cross-references. Using Frame was as much art and science, and there were key commands that were transmitted through the mailing list, by word of mouth, because they were no longer in the official documentation. It had a learning curve like a brick wall, but once you got through it, you were driving an unstoppable tank that could roll over any problem.

After 15 years, including occasional painful exposures to trying to do professional documentation in Microsoft Word, we got a new, hot product called MadCap Flare. It was like FrameMaker had been reincarnated for the web. It was easier to use, had integrations for localization, CSS, HTML5. It was shiny and beautiful and powerful. I could still do conditional text, referenced text blocks, and single-sourcing.

I haven't used a technical writing tool like that in 18 months, and I think it will happen less and less often.

The rise of Software as a Service and app culture is driving us away from a world of User Guides and Admin Guides and Installation Guides. Instead of CDs with instructions, we expect pop-up help bubbles and interfaces that guide us through what we should be doing. This makes a lot of sense, since we are all experiencing individualized experiences based on our bandwidth, app collisions, needs, and licensing structures. Writing a document that includes all that would be extremely difficult with the old tools, and we don't have the old tools anymore.

We don't have them because without the need to produce Official Documentation, we've reduced and eliminated technical writing departments and jobs. We're moving a lot of that work into User Experience, and we are asking the writers that remain to serve as a clearinghouse for content produced by developers. Instead of a journalism model, where we interviewed developers or were embedded on the team, we are now working as aggregators, taking content from many sources and getting it ready to distribute. Or there just isn't a writer, and publishing is much more ad hoc.

FrameMaker and Madcap Flare cost between $1000 and $2000 per seat license. That's not something you're going to buy for someone who is doing it part time. And it's hard to port data in and out of them, because of all the metatext and compiled information that's attached to them in the tools. It's a database, not a set of flat files. Or more accurately, it's a compiled binary – not the program, the document. So a writer using one of these tools would be a hard gating function on a team's ability to publish their own writing. It would look great, but you'd have a single point of failure.

Instead, we've been moving toward having technical writers use tools that are freely accessible to developers. Markdown that is compiled with readthedocs or readme.io or some other blunt-force tool to create a page with a table of contents and some minimal linking. The advantage of this is that everyone can read, write, and access the docs. The downside, which is mostly only visible to technical writers, is that we have lost enormous richness in treating our documentation as an object-oriented compiled object.

Here are some examples of things that I either can't do or are very difficult:

  • Conditional text – different output text based on flags set on the whole document.
  • White-labeling – configuring my documents so secondary organizations could brand them themselves
  • Smart localization – Doing bulk localization based on common words and phrases, reducing translation time and cost
  • Write once/publish many – having a master document that can produce help, web pages, print, and in-product assistance
  • Context-sensitive help tied to the page the user is on
  • Tables – Markdown, why are you so bad at this?
  • Sophisticated layouts – headers, footers, breadcrumbs, inset images and text blocks
  • Automatic ingestion and formatting of other file formats
  • Includes, referenced text, inserted files – think libraries

That's a lot to lose! Sometimes I feel like writing in Markdown is like making Gutenberg to give up on the printing press and presenting him with and angry goose and a curly sheepskin.

However, it's not going to do me any good to bemoan the lost glories of the tech writing tools Roman Age, because we are in the Dark Ages now, and we just have to move forward to the Enlightenment as soon as we can.

….I was going to make a comparison table for you here in WordPress, but that's not a thing. My point exactly.

Anyway, here's what I think we could start using to regain some of our lost abilities:
CSS – Might be able to help with layouts, HTML5 support, tables, and white-labeling
Feature flags – conditional text, write once/publish many, and ingestion
HTML – (stop laughing. HTML is much more fully featured than Markdown) tables, context-sensitive help, includes
De-duplication – smart localization, includes
Javascript, PHP, etc – ingestion and formatting, menuing, navigation, breadcrumbs

Wow, that's a lot to learn. On the other hand, I heard a talk last week that included a 5 minute list of everything you "needed" to know to become a useful devops engineer, so I guess it's not bad compared to that. It is a pretty intimidating list for people who got into technical writing because they like writing, rather than because they like technology. It's not that writers can't learn tech – obviously we can, because we learned those old tools. It's that there is only the beginning of a community around this new renaissance writing, and no one tool that we can teach juniors.

I fell into tech writing because I took an English literature class with a very avant-garde professor who taught us hand-coded HTML (because 1995). That was the key that opened the door for me. But what key is out there now?

I hope Corilla continues to learn and grow and thrive – they could add in many of these features or already have them.

I hope Read the Docs gets enough funding to hire someone who is a technical writer as well as a coder, because they are missing some significant use cases, but they are also an industry standard.

I hope the OpenAPI standard and Swagger make it more possible and easier to expand their powerful use of code snippets into non-API documentation, because they are coming at the problem a new way and it involves a lot of the hypertextuality I'm looking for.

I hope Confluence realizes that they are setting people up to create unusable wikis because they default to an older, siloed world.

And honestly, I hope SharePoint spontaneously combusts, because that is TERRIBLE.

New employment: LaunchDarkly

Last week I told you about my exciting new job title, Developer Advocate.

This week, let me tell you about my exciting new employer! On Monday I started a job with LaunchDarkly, a startup that does feature flags as a service.

Feature flags are a way to distribute software with reduced risk. For example, if you had a holiday-themed CSS page that you wanted to activate after Thanksgiving, but you didn’t want the risk of deploying something that might break your holiday shopping experience, you could wrap the CSS in a feature flag. Using the feature flag, you can decide when to turn on the stylesheet. You can set the percentage of people who see the stylesheet. You can even hit the emergency kill switch for the stylesheet if it does cause problems.

Feature flags can also be used to test new features for part of your audience, or to replace conditional text, or to control which customers can access premium or paid features.

There are a bunch of implications that spin off from the ability to turn features on and off quickly and reliably – it changes some core thinking about what deployment is, how we think about a product, and what we do when something goes wrong. I’m really especially looking forward to working with customers to make sure that we are using and respecting their use cases. For example, while I was at DevOpsDays, I ran into someone who asked me how LaunchDarkly worked with HIPPA standards. I get to either find or write a white paper that gives them coverage for their needs.

It’s exciting to be an an inflection point in how we think about things. It’s happened to me a couple times — full disk encryption, multi-cloud management. I think this one may be another one. Ask me about it!

Why on earth would developers WANT to write documentation?

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

Minneapolis DevOpsDays 2017 logo

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

How do I get developers to write anything?

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

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

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

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

Here’s the key problem though:

No developer has ever been fired for lack of documentation.

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

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

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

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

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

A variety of rewards

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

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

New job title: Developer Advocate

I've had a lot of job titles in my career:

  • Technical Writing Intern
  • Queen of Documentation (It was 2000, OK?)
  • Technical Writer I, II, III
  • Technical Communicator
  • Senior Technical Writer
  • Technical Writing Consultant
  • Documentation Architect
  • Documentation Mercenary

You might notice a theme there. I've been a technical writer for a lot of different companies, because that's been my career, my expertise, and my passion. I want to take everything that's great about technology and make it easier to use, more transparent, more thoughtful, more humane.

Lately, I've been having trouble describing what I am doing in terms of writing alone. Two job interviews in a row, my interviewer stopped asking me questions about my qualifications so they could take notes on my ideas for their product. My conference talks are sort of nominally about writing, but actually about patterns I'm noticing in the world and in technology. I love writing, and I'm never going to give it up, but it's also…not quite a good fit anymore.

Through the power of All-Women-In-Tech-Are-Connected, I got an interview for a Developer Advocate position. I would never have applied for this position on my own – it's so far beyond what I think of as my skill set. But in the discussions and interviews, I really came to believe it was not just a company I could work for happily, and a product that I think is useful and not toxic, but a position that lets me get out there and do the kind of thinking and helping and problem-solving that I love.

Photo credit: Women of Color in Tech Chat

Developer Advocate is a super broad range of positions, actually, but our interpretation of it is basically me continuing to do all the things I'm doing now: conference speaking, blogging, listening, and noticing. It's just that now I'll be doing all that and getting paid for it, instead of using it as a loss leader for my consulting. I get to go out in the world, find out where developers and users need help, and figure out how to make it happen for them. We're seriously at "pinch me, I must be dreaming" levels of exciting here. I even get to keep writing a little, although I may have reached my personal career goal: not writing the release notes.

Yes, I'm being deliberately coy about my new employer. That deserves its own post. I'll just say that I think we're going to get along well, they say I get to continue to be a pink-haired weirdo, and I will feel proud of the product.

I honestly feel like changing my job title is like the day you get new shoes and you realize you'd outgrown the old ones without noticing.

Oh! This is so comfy.

Consulting retropsective

I’ve been doing Agile for too many years to feel like I’ve learned something unless I identify it with a proper retrospective. I’m about to start an FTE job, and my consulting will obviously drop way off (but not entirely). So here we go:

What went well

  • I passionately loved the independence. I could fire a client when I thought they were doing something that was stupid/unethical. I didn’t have to account to anyone for my time at conferences. I made it to all the weird middle-of-the-day school stuff. My spouse was in the hospital for 11 days, and I could absorb that without talking about it.
  • It really forced me to get better at negotiation, scoping, planning, and self-management. No one was going to save me by telling me the priorities of projects — that was on me.
  • I learned a lot about building a personal and professional reputation. It matters that I blog. It’s important to follow up on business cards and connections. I never advertised my services except by telling people they were available, and I had stages where I turned away work.
  • I discovered moxie as a selling point. Not unreasonable bragging, but people are happier when they spend a lot of money on someone who seems confident about themselves and what needs to happen. I would have guessed that would be a turn-off, but no, that mostly applies to earlier stages in a career.
  • I got to work on some kick-ass projects and refine what parts of writing and projects I’m good at.
  • I got to go to so many conferences and learn so much stuff about things that I never would have thought I cared about, but it all feeds into the hopper and then a week or a month or six months later, it turns out that data was valuable.

A smattering of the stickers I carry around with me

What needed improvement

  • Cashflow. Sweet fancy moses, cashflow. This year to date, I have pulled in about $30k and gone $10k into debt. I had two contracts die on me after I had turned down other work to take them, and a client that paid Net-45….ish. If I reminded them. As a sole earner for a family of four, including two teenagers, this is not super. If I knew I was going to make that persistently, I would adjust our style of living, but I kept optimistically thinking that the universe would not screw me over again, right? And this was just a little bump. It wasn’t.
  • Relatedly: taxes. I did not get that set up as soon as I should have and I will spend some time untangling it.
  • I needed some things in my contracts that weren’t there: a kill fee/clause. A late fee. I racked up about $700 in late/overdraft fees because I thought people were going to pay me when they said they were. This is not a malicious problem, it’s a problem because I had already exhausted my buffer cash.
  • I need to keep working on how I track time. There is a lot of my job that is basically talking to people, wandering around thinking, and staring at the ceiling. It’s legit work, but I feel weird charging people for ‘I mowed my lawn and also thought about your data structure problem for two hours’.
  • I need to figure out how to pay myself for loss-leader/reputation building stuff, like blogging and mentoring. If I classify it as “not-work”, it eats the leisure time I need to recharge, interact with my family, and sew nifty dresses. If I classify it as work, then it’s unpaid work, which has a lot of emotional stuff going on.
Empty wallet in male hands. Isolated on white. Studio shot.

Empty wallet

Action items

If I do consulting full-time again, here are some things that make it more likely to work out for me.

  • Start with 6 months of cash buffer instead of 3. This is because I don’t have any other income stream
  • Write my own contract (well, hire a lawyer to do it), and make sure my clauses about kill fees, late fees, and payment schedule get into whatever contract I sign.
  • Hire a tax accountant sooner rather than later.
  • Work on adding passive income to smooth out bumps.
  • Factor in equipment costs and less-obvious travel costs in my calculations (if you take 50 flights a year, you wear out luggage, even the nice stuff) (I’m using a 3-year old laptop, and software costs money.)
Purple spinner suitcase

My next suitcase – a slightly smaller TravelPro in PURPLE