Six lessons from a bootstrapping startup founder (part II)

I launched Small Improvements as a bootstrapping startup founder in 2011, using $60,000 of my own savings. And came perilously close to losing it all.

Yet despite the ups and downs, I can proudly say we’ve been profitable since late 2012, have built a staff of 29 employees, and have over 750 customers around the globe.

As 2017 winds down and we’re crossing the $4m revenue mark, I’ve been reflecting on some of the lessons I’ve learned over the course of six years. Some good, some terrible. It’s those missteps I continually return to when I’m asked for advice from other entrepreneurs. I think of it as my own personal crash course in building a sustainable company. I’d be happy if someone reads this and avoids one or two of these beginner mistakes, too.

You might remember the first three lessons I learned from a post I did this summer. Now, here are the remaining three key learnings from my time leading Small Improvements.

No. 4: Give your teams early structure

I’ve never been a big believer in flat hierarchies. Teams should be able to work autonomously, and for that, it needs to be clear who is ultimately responsible. But when a startup slowly grows from two to four to six to eight people, it’s tricky to decide when to introduce subteams.

We only structured the engineering department once we had 10 staff members, and in hindsight, this was way too late.

Per Fragemann at SI's event with Reddit

If I could do it again, I would have nominated a team lead once we hit four developers. These days, we’re happy with cross-functional teams of three or four developers each.

On the customer side, we had a department of six generalists who could help each other out with anything from lead assessment and product demos to support and customer retention. I feared that splitting up such a small department would lead to mini-silos. But once the situation became too messy, we took the plunge and split them up into three sub-teams: Customer Success (2), Support & Sales (3), and Marketing (initially 1, but then growing quickly to 3).

The new feeling of ownership increased happiness immediately and resulted in process improvements as well. But the advantages of the “generalist approach” still live on; if needed, someone from customer success will help out in support, and vice versa.

The lack of early structure didn’t kill us, but a lot of discomfort could have been avoided.

No. 5: 1:1 Meetings are crucial

Everything works fine, until it suddenly doesn’t.

While I knew about the importance of regular 1:1s from my previous job at Atlassian, I couldn’t find the right time to implement 1:1s at my own company. At first, I didn’t feel I had to have 1:1s with the single student developer I employed because we were chatting every day anyway. Same for the next two students and our marketing director. If you talk on a daily basis anyway, a weekly 1:1 seems like overkill. And since I didn’t have 1:1s when we were four people, we still didn’t have 1:1s when we were six, and so on.

Per Fragemann at SI's Reddit event

After all, the company was thriving: initial growth rates of 200% year-over-year, new and shinier office once a year, company trips, cool new technology and so on.

Life was great … or so I thought.

But unknown to me, all the small complaints started growing into larger gripes, and then outright grudges and unrest. Not because the original problems were the worst in the world, but because I didn’t attend to them. Issues that might not have been so bad otherwise got lumped into existing grievances. Suddenly dissatisfaction started spreading from one person to another — even though, on the surface, the company was doing really well.

Had I conducted proper 1:1 Meetings right from the start (quite easy with only one employee!) I would have been able to identify most of those problems. This issue was compounded by the lack of initial structure: once I realized that I really had to get started, I had nine direct reports and was still so busy with day-to-day work that I couldn’t simply add nine new meetings to my calendar.

Today I still have nine direct reports, but the company is now 29 people and I’m far less hands-on, so I do find the time every week. Not every problem in the world is solved by 1:1s, but a lot of them can be caught really early on.

(By the way, check out some of our guidelines for conducting successful 1:1s. Hint: they’re not about day-to-day work)

No. 6: Don’t stick with prototyping in code

When I started SI, it was clear I’d do all the prototyping in code. I was fast at it, and back in 2011 visual prototyping wasn’t as easy as it is now. However, one of my biggest mistakes (and learnings) was to cling to this prototype-in-code approach for too long. I didn’t encourage visual prototyping enough in the team, nor did I do enough myself.

Per Fragemann during the SI company retreat in 2015.

I based this on the incorrect assumption that in an agile software team, change isn’t hard. This is unfortunately not true on several levels. Changing the placement of a button or form is easy, just as changing some paddings and margins is easy. But changing entire flows is hard when a whole team is working on it, as opposed to me as the sole founder.

Also, developers just don’t like throwing away (or radically changing) code they just built. As a founder, I had ditched many of my software craftsman principles in favor of speed, so change was no problem.

Once I hired highly capable developers, they obviously coded things properly. Agile, sure, but properly. This meant that large change not only cost time but also motivation.

As a founder, ditching crappy code is easy. As a very good developer, realizing that a brilliantly thought-out component will simply not be needed anymore due to a change of plans is not fun. It will happen occasionally, but it can’t be the norm.

So these days we still sketch things on paper at first, and we still experiment in the browser on the smaller scale. But when it comes to designing new flows and entire features, the overhead of setting up a clickable prototype is really worth it.

And in hindsight, I should have seen the potential far, far earlier, and it would have saved us months and months of coding of features that we kept changing. Agile is great and we live it every day, but not planning ahead has cost us dearly.

If you missed the first three lessons about what I’ve learned as a bootstrapping startup founder in six years, be sure to check it out here.

Was this post helpful?