The personal lessons I’ve learned in business

They say “it’s not personal, it’s just business.” But, when you’re a small business, everything is personal. Here are four personal lessons I’m grateful for having learned as a company founder.

Separate strong opinions from weak ones

In school, we’re taught to have a point-of-view about everything — every subject, every story, every problem. We’re conditioned to come up with an opinion, raise our hands, and tell the teacher what we think (the dreaded “participation grade”). But, we aren’t conditioned to have an opinion about that opinion. In fact, anything less than a strong opinion is, well, no opinion at all. And, come see the teacher after class.

In business, I’ve learned to evaluate how much I care about my opinion. The truth is, I don’t care all that much about plenty of decisions. Don’t mistake that for not caring about a problem — rather, I’m not strongly tied to what to do about that problem. In these instances, I’d rather someone with a much stronger opinion decide for me. They’re far more likely to carry that decision through better than I would.

Why does this matter? Too many strong opinions on too many things stifle progress. In business, you can be profitable in two ways: Make more money or use less. Progress is much the same. You can progress by making more decisions, or by counting yourself out of one. A weak opinion, strongly-held, is like a poorly-returning financial expense. Just get rid of it, and progress happens faster.

Culture is never fixed

For years, I could never get over the recurring feeling that we’d been “doing it wrong all along.” (I still can’t). Every so often, we’d go through a dramatic shift in our corporate culture. At first, there really wasn’t much of a culture at all — three dudes in a 600-square foot space is more like a luxurious college dorm room than an office. Then, we hired our first person that wasn’t a personal friend of someone’s. Adjustments were made. Then, we moved offices. Adjustments were made, again. Since then, we’ve introduced daily stand-up meetings, quarterly reviews, yearly summits, policies for remote working, two new companies (DoneDone and Kin), paid vacation time, an equity plan, and a company handbook. People came. People succeeded. People failed. People left.

Each step along the way, the culture adjusted. The things we value today, as a largely-remote staff, are so very different than the things we valued a few years ago. And, this, as I’ve come to terms with, is the way all good cultures go. A culture is progressing if it’s changing. The only time a culture doesn’t need to change is if the components of a business don’t change. We’re not close to that just yet.

As an engineer and designer at heart, shooting for this always-moving target is frustrating — I like having a known quantity, a known problem to solve. But, culture doesn’t work that way. It is never fixed. Then again, I suppose this is true of modern-day software as well.

A process is always a trade-off

The really tricky thing about developing a good culture is figuring out how best to implement the ideas. Sure, some things are simple. People want to eat healthier lunches? Let’s use some of our budget on providing the staff with healthy snacks. People need structure around taking time off work? Develop a time-off policy for your team. But, most of the good parts of culture are much harder to quantify. Where’s the process for making someone feel like they’re doing fulfilling work? What’s the process to make sure our customers are happy?

Initially, adding process feels like making progress. The thought-process (pun intended) goes something like:

• Realize we’re doing this same kind of thing every so often. Let’s give it a name and define what it is.
• Define and name this thing. Now, let’s schedule this process to happen X times per day/week/year.
• Let the process repeat as planned, focus our attention onto other things, and forget about why we’re doing it. After all, that’s why we’ve made it a process!

And, therein lies the rub. Applying a repeatable process to solving a problem is always a trade-off. Look at it this way: You actively decide to trade away the time and energy spent thinking about how to solve something in exchange for a blanket solution that might not work quite as well as your business grows. Even further, not every person is going to like a blanket solution equally. The key is to monitor it, and know when the trade-off isn’t working in your favor.

Last year, we made changes to the way our daily remote “standup” meetings work. The process of going around the entire team to give their “things done, things to-do, things needed from other people” list was a bit too burdensome by the time we got to 20+ employees. Even further, we don’t work on the same things. So, we broke this up into a few standup meetings by team.

At the same time, we decided to keep Friday standups the same as they’ve always been. It seemed like the right trade-off between a process that was becoming too inefficient and ensuring that our entire team felt connected to each other. After all, these 15 minute sessions are the only time in any given day we’re guaranteed to see, hear, and talk to everyone.

After a few months, this too began feeling cumbersome. The relative inefficiency outweighed the benefits of disparate teams seeing each other. As we dug further, the real problem was that the time spent together didn’t feel all that connected. People were still talking about projects that had little relevance to other people.

So, we iterated again. Friday group standups are now no longer about work. We go around and talk about something personal — what we’re doing this weekend, or what’s been happening outside of work. They usually take longer now, and I can’t say everyone enjoys it equally, but the time we spend feels more worthwhile as a collective.

Will we iterate this again down the road? Probably. Yes.

My biggest fears and joys live in other people

I’m a rather obsessive programmer. I agonize over all the subjective aspects of code — intent, readability, naming, architecture. Why do I care so much?

There’s a part of me that says I just get a kick out of really good design. But, would I care as much if the code I wrote was just sitting there collecting dust, like my childhood baseball card collection? Probably not.

I like writing good code because I know someone else will have to read it (and that someone else might be me, six months from now). I’d like that person to know what — exactly — I was thinking, at the time (Not in the “What were you thinking?!?!” sense. Rather, in the “Oh, I see what you’re trying to tell me!” sense). I’d like that person to be pleasantly surprised by the clarity of my reasoning. I absolutely cringe at the thought that they’d feel frustration in code written by uncaring hands. I strive for good code because it’s going to help a person do their job better in the future. In fact, whether it’s building software, writing blog posts, fixing bugs, pushing new releases, managing a team — all the meaning in these tasks live in the people they affect.

We work in a medium where our relationship with people is masked behind something. It might be code, a support desk, email, any number of social networks, or a Stack Overflow page. As Craig has often said to us, if you’re having trouble with someone over email or some other masking line of communication, walk over and talk to them. Pick the phone up and call them. Hear their voice. A lot of the fear erodes when we see the person on the other side of the machine. As Derek Sivers wrote, it’s likely a person a lot like you.

In the end, my biggest triumphs and failures come from the response I get from the person on the other side. The reason a “job well done” matters to me isn’t because of the job unto itself, but because it makes someone else’s job easier.