I started my last company when I was 30.
I actually thought I was 31 when I started writing this, but then I went back and looked at the dates and realized I didn't turn 31 until a couple of months later. Apparently, I've reached the age where I'm compressing entire years of my life together, which probably isn't going to get better from here. Yay. So, 30.
I'm 47 now and building another company, and I've been thinking a lot lately about how differently I'm approaching it this time around.
This isn't going to be one of those "if I knew then what I know now" posts, mostly because that’s really not my jam, but also because 30-year-old me wasn't a complete idiot. He did some things very well. He also made some choices that 47-year-old me looks at and thinks, “huh, that was super dumb, Jeremy”. I’m pretty sure 64-year-old me will feel exactly the same way about what I'm doing right now, but I digress.
One of the biggest differences I've noticed this time around is that I don't feel nearly as compelled to prove how many things the company can do. See, I used to really like being able to say yes.
Can you support this?
Yep.
Can you build that?
Sure.
Have you ever done this extremely specific and overly complex thing before, knowing that failure will have massive impacts on hundreds or thousands of people?
Well, no, but I'm reasonably confident I can figure it out, so sure let’s give it a shot.
That last one, to be fair, has served me pretty well throughout both my career and life in general. I genuinely like figuring things out, and I am genuinely good at it. Drop me into a broken migration, a weird identity problem, some Microsoft issue that makes absolutely no sense, or an environment held together by undocumented decisions made by six people who no longer work there and I'm probably going to have a good time. This likely indicates something is wrong with me, but I've accepted that, and think it’s probably for the best in the end.
However, the problem is that being good at figuring things out can create some really bad incentives when you're running a company.
You solve a weird problem for a customer and shazam, everybody is happy. Then you solve another weird problem. Then somebody needs something that isn't really what you do, but it's close enough and you know how to do it, so sure, why not?
None of these decisions look particularly dangerous while you're making them. They are, in fact, usually completely reasonable, especially when there's revenue attached.
Eventually, though, you can look around and realize you've accumulated a business model rather than designed one. Looking back, I knew what was happening at the time, at least academically. I'm positive somebody older and more experienced told me some nuanced version of it. I'm equally positive I nodded along, agreed wholeheartedly, and then went right back to doing whatever I was going to do anyway, absolutely certain that Future Jeremy would be able to fix it down the road. (This is a recurring experience in my life, but that’s a separate topic.)
The way I think about complexity has changed quite a bit since then. For a long time, I thought being good at handling complexity was one of the things that made me valuable, and frankly I still think it is. I can hold a lot of moving parts in my head, make connections quickly by identifying patterns in large datasets without giving it much thought, and generally function pretty well when things are chaotic.
What I didn't appreciate as much was that this can also make you tolerant of systems that shouldn't be that complicated in the first place. Think about it: if you're good at carrying weight, another ten pounds doesn't seem like a big deal. But if you slowly add ten pounds at a time for any length of time, eventually you’re going to feel it. If you’re building a business, you eventually have a company where half the procedures include some variation of "Jeremy knows how this works."
That's not expertise. That's a problem I created for Future Jeremy. I have in fact been known to say “That will definitely be a problem for Future Jeremy.” every now and then.
I have indeed historically been very generous with Future Jeremy's time.
Future Jeremy can document it.
Future Jeremy can clean it up.
Future Jeremy will eventually automate that.
Future Jeremy will remember why this customer is configured differently.
Future Jeremy can train somebody else on it.
The guy has apparently had nothing else to do for most of his life.
I'm trying to be considerably nicer to him this time, so with Athencia I'm finding myself asking different questions earlier. Not revolutionary questions either, which seems appropriate for a newsletter called Boring on Purpose.
Do I want to support this five years from now?
If we make this exception for one customer, what does that actually create for us?
Could somebody come in behind me and understand why this works the way it does?
Are we adding something because it makes the company better or because somebody offered to pay us to do it?
That last one is harder than it sounds, because revenue is very persuasive at any size, but when you're small and just starting out - or even feel like you’re small and just starting out - revenue is extremely persuasive.
If you’re not pretty strict with it, there are very few customer requests that can't be made to sound reasonable if you stare at the dollar amount long enough but over time I've become much more interested in what happens after the sale.
Say a customer wants to use a different firewall than the one you normally support. No problem, right? You know firewalls, and you can train your team on firewalls. It is, after all, one customer, right?
Except now somebody has to maintain the documentation for it, figure out how to monitor it, understand the licensing, <insert a dozen other tasks here>, and ultimately account for it every time you make a process that assumed everybody had the same firewall.
That one little exception has children, followed by grandchildren, and those grandchildren sometimes invite their friends over to play paintball in the back yard.
In the end, that’s a long-winded way of saying some of those decisions will still be living with you long after you've forgotten why you said yes in the first place.
There are obviously times when exceptions make sense. I'm not turning into the Soup Nazi of IT standards over here, and when I advertise Athencia as a boutique firm, I mean it. Customers are different, businesses are messy, and sometimes the unusual answer really is the right answer. I'm just trying to make myself acknowledge the full cost of the decision before I make it. This is definitely a new thing for me.
Another thing I'm doing differently is worrying much less about looking like a larger company. Small businesses do some funny things when they’re insecure about being small. We invent departments. We give things enterprise-sounding names. We build a service catalog that suggests a team of 150 people is waiting somewhere behind the curtain when the actual organizational chart could comfortably fit in a group text. I have absolutely participated in this behavior before.
I don't feel much need to do it now.
Athencia is small, and that's fine. There are things I can do precisely because it's small that would become vastly more difficult with 500 employees. I can change something in an afternoon. I can know every customer. I can personally see where our processes are stupid. I don't need any committees, for anything. Ever.
I want the company to grow, obviously. I did not start a business because I needed another hobby. I have plenty of those and most of them are far cheaper. I have a general idea of how big we’re going to get, I know the steps needed to get there, and I have a concept of a plan for what not to do along the way. In the end, it’s never going to be huge, by design.
What I do want to do is avoid is adding complexity ahead of the actual need for it and calling that scale.
I've done enough work inside large organizations to know they generally have plenty of complexity already and I don't feel the need to pre-install it. This also changes how I think about people.
At 30 I put a lot of value on people who could figure things out, and I still do. Give me someone curious, technically strong, willing to poke at a problem until it makes sense, and I'm a happy camper. That said, I'm now much more interested in whether the company itself requires people to operate that way all day. In the end, there is a sizable difference between having smart people available for difficult problems and designing a business where every routine problem requires a smart person to improvise.
The first is useful, and the second is exhausting. It’s also expensive, but that’s not the point I’m trying to make here. If you operate in the manner of solely hiring smart, curious, technically strong people, eventually somebody leaves and you discover that the process wasn't actually a process. It was Greg, and hopefully Greg left notes.
I've apparently stumbled into a theme here, because this connects pretty directly to what I wrote in the first issue of Boring on Purpose about everything eventually becoming a Tuesday.
The last time I started a company I spent a lot of time thinking about what we were capable of doing.
Can we win this customer? Can we deliver this project? Can we learn this technology? Can we solve this problem?
Those questions still matter to me, and I'm not planning to spend the rest of my career avoiding difficult things. That would be both boring in the wrong way and wildly out of character for me. This time, I’m just asking the follow up questions: What does next Wednesday look like, and what about next month, and then two years from now when nobody - including yours truly - remembers the meeting where we agreed to do this?
A heroic weekend migration can be great fun if you're wired a certain way. Weird problems appear, people solve them, somebody gets to be a genius for fifteen minutes, and eventually you stumble across the finish line. I’m man enough to admit I did a minor version of this last weekend.
Then Monday comes and everybody talks about what a great job the team did, but I'm interested in Tuesday, because Tuesday is when someone has to add a user. Tuesday is when a backup job fails. Tuesday is when somebody is on vacation and the other person needs to know how something works. Tuesday is when no one is especially motivated or heroic because they're doing their normal job and would like to finish it at a reasonable hour this time around.
The older I get, the more I think a well-built company should be mostly designed for Tuesday.
I'm still figuring out what that means in practice. Athencia is young enough that I can see plenty of places where I'm not there yet, and I have indeed made a few pivots just under a year in. There are things in my head that need to become processes. There are decisions I've made because they're expedient.
There are also absolutely things Future Jeremy is going to loudly curse Present Jeremy for, because some traditions are worth preserving. (But at least I’m big on documentation this time around!)
That said, I don't think the goal is to eliminate all of that anyway. A company with no improvisation, no weird problems, and no room for somebody to come up with a better way of doing something sounds awful, and I didn’t choose to play life on hard mode just to do something that sounds awful.
Instead, I'm trying to be more deliberate about where we spend that energy, because I want the interesting problems to actually be interesting and I don't want a talented person burning an afternoon reconstructing some bit of institutional history because three years earlier, we couldn't be bothered to write down why something was different.
That isn't creativity, it’s just laziness, plain and simple.
There's probably a broader age thing buried in all of this, although I'm hesitant to lean too hard on that because there are plenty of 30-year-olds who are more disciplined operators than I was and plenty of 47-year-olds making an absolute mess of things. Plus I don’t think of myself as old (let alone wise) so there’s that.
At this point I can look back and realize that, for me, 17 more years gave me the chance to mature in my decision making quite a bit. In 2018 I sold the business I started in 2010 and I ended up in a handful of leadership roles at companies ranging in size from 10-300+ people in between then and now. I learned how small compromises tended to show up a couple years down the road in a less than entertaining manner, I watched “temporary” processes become permanent, and I watched people become indispensable and then leave. I was in fact lucky enough to see one company grow from ~10 to ~50 people in a few short years.
After enough repetitions, you start developing opinions, and one of mine is that boring is underrated.
Boring systems. Boring standards. Boring documentation. Boring Tuesdays where things work, customers are happy, and nobody has a good war story at the end of the day.
At 30, I think I viewed the ability to handle chaos as evidence that we were good.
At 47, I'd rather need that ability less often, and I don't think that's any less ambitious. If anything, what I'm trying to build now is harder; I'm trying to build a company that gets better without accumulating an equal amount of useless crap alongside the growth. One where people can use their brains on things that deserve brains instead of using them to compensate for yesterday's shortcuts.
I'm sure I'll get some of it wrong. Check back when I'm 64. I'll probably have notes.