Skip to content

Atoms and Bits

Atom

I found this post by Fred Wilson about atoms and bits to be a nice counterpoint to this post from a few years back by Chris Dixon. There are so many advantages that a software product has over a business that delivers physical goods, whether that is inventory, startup costs, or distribution. (Yes, if you build a mobile app, you have to pay the vig to Apple/Google, but you also can distribute at zero incremental cost to hundreds of millions of people.) From Fred’s post:

we should … understand that the timelines [for working on businesses that focus on atoms] will be longer and the road to adoption will be more challenging.

The fact is that atoms are just harder to work with than bits. However, that very difficulty can provide a moat around your business (“where there’s muck there’s brass”). If your business is bits, find another moat (branding, network effects, niche domination).

Startup COOs: What do they do?

I really enjoyed this post about what startupo COOs do. It was interesting because it wasn’t just opinion, there was also data. I particularly enjoyed the evolution of the author’s role over time, and the percentage of COOs that owned various responsibilities. To be fair, it was a small set of respondents in one geographic area, but still interesting.

However, the money quote was:

I actually have [simple way] of explaining what I do, and I would sum it up this way: taking things off my CEO’s plate, and figuring out how to thoughtfully scale the company.

Of course every company’s different, but I’ve seen the pattern of a visionary and an operator in a couple of companies, and it’s powerful.

(Links To) Advice For Someone Selling a SaaS Business

Sold signI ran into someone at a meetup recently who’d built a SaaS that had a pretty decent MRR. Enough to support one person. Which is a huge achievement!

He was wondering what options he had to either grow or exit the business. This is something I’ve been reading about for a number of years, so I had some advice. I thought I’d write it down so that others could benefit (or chime in). These are resources I’ve found insightful.

This is a great first hand account by patio11 of selling a software business (it wasn’t SaaS, rather a one time digital product sale, but I think there are a number of common themes). He mentions the broker he uses, the due diligence process, and what you can do now to set yourself up for success (have separate accounts, for one).

I can’t even talk about SaaS without telling folks to raise their prices. It’s a reflex now. Amy Hoy has two great posts on this: grandfathering and new features (with a lot of communication mixed in). I experienced this myself at a previous startup, where we almost doubled our monthly subscription price in 18 months.

Finally, here’s an interesting post from a venture capitalist about how private equity is a new exit option for SaaS companies. In that vein, I chatted briefly with one such PE firm, SureSwift Capital, about part time work a year or so ago. I don’t know how they are to work with (the position wasn’t a fit) but at the time they were focused on acquiring SaaS companies with good MRR and helping them grow.

Big hammer or small hammer?

HammerI was talking to a friend the other day about startup vs big company life and he used an analogy so good I’m going to steal it (and expand upon it).

If you think about the problem you are trying to solve as a rock, and the business you are in that is trying to solve as a hammer with which to chisel or otherwise transform said rock, you can choose a brick hammer (which is a small hammer) or a sledge hammer (a large, heavy hammer), or anything in between.

The smaller the hammer, the more effort you have to put into the swing. However, it’s fairly easy to pick up, to manipulate and to re-orient if you decide you need to approach the rock from a different viewpoint.

If you, on the other hand, choose the sledgehammer, then when you swing you are wielding a lot of force. It becomes easier to make progress on your initial approach, but if you need to switch up your emphasis, it’s going to take some time, because of the weight of the hammer.

The larger the business, the more leverage and power you have to attack a single problem. I’ve worked at large companies in the past, and I can tell you the size and scope of problems they were able to work on, often in parallel, were amazing. However, there was a lot of time and effort spent on coordinating those efforts, and and a lot of bureaucracy and red tape if there was a process improvement needed. (There was also dead weight at some of these companies.)

At a smaller company or a startup, as I’ve worked at in the past, I didn’t have the bandwidth to take on multiple large projects. Doing more than one or two major projects was a recipe for distraction and impotence. However, when focusing on one effort, it was easy to try different approaches, work really hard and be super flexible when incorporating feedback from customers and iterating.

There are strengths in both the small and big hammer approaches. The important thing is to choose what is a good fit for both the problem you are trying to solve and your working style (which may change over time).

“Do you know anyone with 18 years of React experience?”

I often give referrals to folks looking for help (typically software development, but it could be any other area where I feel I know someone that could help another person or company out). It’s a great way to help out both parties.

However, a referral is not a referral is not a referral. Here are the seven types of referrals I have made.

  1. I have worked with this person/company directly, would do so again, and they’ve solved your problem before. I’d hire them if I could, you should.
  2. I have worked with this person/company directly, would do so again, and believe they can solve your problem. I’d hire them if I could, you should.
  3. I have interacted with this person/company in the real world in a non professional capacity and they seemed like “good people”, and might be able to help with your problem. Probably a good idea to talk to them.
  4. I have interacted with this person/company (online/offline) and they seem to know what they are doing. You may want to put them into your decision matrix.
  5. This person responded to a post I put up somewhere (maybe HN) and I like the fact they read it and responded. It’s worth looking at their resume.
  6. I have seen this person’s/company’s blog post or marketing material. They seem like they’d be worth a look.
  7. I do not know this person but they have been recommended by another person that falls into one of the above categories. May be worth a shot?

Obviously the closer to category one a referral is, the more I feel I can stake my reputation on a successful interaction. Lower down, it is less a referral and more of an informational service.

The important part in all this is being clear at what level you are interacting. You don’t want to hand someone a referral of level two and have them think it is a level five. Or vice versa.

 

“Choose boring technology”

Reading a boring bookThis article on choosing boring technology is so good. It’s from 2015 so some of the tech it references is more mature, but the thesis is that the technology underlying a business should be well known and boring to implement. It also discusses how important cohesive technology can be (I love the final footnote).

I think this is an interesting contrast to microservices, which is essentially solving repeatedly for local optimizations and then relying on the API or message boundary to allow scaling. Microservices, in my experience, often get a bit hand wavey when it comes to operationalization (“just put it on Kubernetes, it’ll be fine”).

I have definitely dealt with this in previous companies where I had to put the kibosh on new technologies being introduced (“nope, we’re going to do it in java”). This meant that as a small team we had a standard deployment stack and process and could leverage our logging knowledge and debugging tools.

Here are some arguments I hear for using the latest and greatest technologies:

  • “Our developers will get bored and we’ll have a hard time recruiting”
    • This is a great reason to have regular hackfests and or support developers working on open source or side projects.
  • “New tech will help us do things faster”
    • It’s definitely worth evaluating new technology periodically and adding it to your stack (especially if it is outsourced, a la RDS, or boring, a la memcached). As the original post mentions, if you get substantial benefits from the new technology, then use it full bore and plan for a migration. Don’t end up in a state where you are half in/half out. Also consider tooling and processes to get things done faster–these may have quicker iteration times with lower operational risk.
  • “Choose the right tool for the job”
    • Most turing complete languages can be used for any purpose. And you shouldn’t be optimizing for the right tool for the job, but rather the right tool for the business for the job.

Really, you should just go read the post. It’s good.

 

Management Debt

This post by Ben Horowitz is well worth the read as he discusses a few types of management debt, where a short term decision has long term consequences that you’ll have to expend energy to repay.

This quote stuck out:

Companies execute well when everybody is on the same page and everybody is constantly improving. In a vacuum of feedback, there is almost no chance that your company will perform optimally across either dimension. Directions with no corrections will seem fuzzy and obtuse. People rarely improve weakness that they are unaware of. The ultimate price you will pay for not giving feedback: systematically crappy company performance.

If you’ve read “The Hard Thing About Hard Things”, you’ll remember he talks about giving feedback all the time so that when you have to give feedback it’s not exceptional (he also talks about how this is not a normal human capacity). When you don’t set up systems for this feedback eventually you end up with a rudderless ship. There’s a reason that systematized feedback methods (the dreaded yearly review, among others) exist in almost every organization.

Book Review: Working With Coders

Woman with 1s and 0sSoftware is so integral to business processes and relatively inexpensive compared to labor that I believe every company is going to be a custom software company, in the same way that every company is an accounting company or every company uses paper. I happened on an interesting blog post and saw the author had written a book, “Working With Coders”. How non technical folks interact with coders is a topic of perennial interest to me, so I picked it up after reading the first few pages on Amazon. The book is written for clients, CEOs or project managers who are going to be working with developers to deliver applications that will provide business value.

Frankly, I couldn’t put it down.

The author, Patrick, is an engaging, opinionated writer. He breaks down complicated concepts into easily digestible pieces. Where there’s more to the story, there’s a footnote with a snarky comment or a link to more information. Patrick also provides nuts and bolts examples to show why something that seems simple to change is not (scaling text in a browser, for example). He also covers how big decisions like language, frameworks and library choices at the beginning of a project constrain freedom and choices further down.

Patrick covers what developers do, how they think, and why projects often fail. I thought his explanation of the benefits of agile development was darn good, and his explanation that even agile projects fail more often then they succeed was pretty depressing. He also discusses how the house construction metaphor for building software is just a big fat untruth.

I also enjoyed the section about testing in general, the various types of testing, and where they make sense. There’s also a section on finding coders, including a good explanation of why not to hire them as employees (you might be better off just hiring a development shop, depending on your needs). The chapter on how to deal with common issues (“the team hates each other”, “we’re behind schedule”) was worthwhile. His solutions won’t work for everyone. Maybe you’ll want to deal with these issues differently, but considering them before they happen will only help you prepare.

Of course, I also enjoyed the chapter on how to keep coders happy (continuous learning, quiet, a fast computer). In general the author is careful to avoid stereotypes, but does do a good job of covering common themes. I haven’t met too many developers who love working in bullpen environments.

I am definitely not the target audience. Neither is someone who is an experienced manager of developers. However, I am a subject of the book, so it resonated with me and I definitely found myself nodding along. There aren’t too many books I have wanted to distribute copies of (the two others are “The Hard Thing About Hard Things” and “Climate Wars”), but this is one.

If you work in a consulting practice with inexperienced clients or if you work in a product company with an owner or higher up that isn’t technical, reading this book will give you insights into their questions and thought processes. And if you can find a way to give them this book without being condescending (“hey, I found this book fascinating for helping facilitate conversation, maybe you will too”), both they and you will benefit.

Are you working on the business or in the business?

Dog in a suitAs a business owner, it’s important to realize that the engine of the business (the people and processes that allow you to make the product or service, whatever that is) is as important, if not more so, than the product of the business. This changes over time, of course. When you are just starting out, the product needs to be made, otherwise you won’t have anything to sell. But over time, the other aspect, the business structure, will come to the fore. This is because as a business scales, you need to be able to recruit new talent, market your product, and spread knowledge throughout your company.

I was reminded of these facts by this post, “My Biggest Regret”, from Marty Haught, of Haught Codeworks. He’s kind of a big deal in the Ruby community, but reveals that he was a bit … lazy when it came to business development. From the post:

Apparently, I’m not the only one with this impression. You commonly hear that business owners need to work on the business, not in the business. I loved building software so much that I just wanted to stick with that.

That’s the perennial issue with building a business to give you freedom. Be aware that the bigger the business you build (the more successful) the more you’ll be taken away from building the product and the more you’ll be pushed toward building the business. (There are exceptions, but they require a certain scale. I’m aware of a couple of technical founders who stepped away from business management and focused on development/new initiatives, but that’s rare enough that it is worth commenting on and it also requires a team of about double digit size and margins to allow that to happen.)

The business principles of the solo consultant apply to big companies too. Doing the work is only part of building a business. Ignore that fact at your peril.

Podcast Pick: A16z

I have been enjoying the A16z podcast for the last couple of years. It’s regular, dense content on a wildly varying set of technical subjects. I love hearing Benedict Evans talk about, well, anything–I find him quite insightful. But the podcast is not so dense I can’t listen to it on 1.4x speed.

I tend to listen to the more software specific episodes on APIs and on B2B2C business models (which seems to have been deleted). But every so often it’s nice to be jarred out of my world and listen to an episode about product or space or investing.

You can listen to past episodes here and get the RSS feed here.