For more than a year I've worked (with an awesome team) on taking Travis CI from an continuous integration platform for open source projects into a small business with a profitable product.

While this hasn't been my first venture, it has so far been the one where I focused more on the business side of things than anything else. There was some code, there was infrastructure, there was monitoring.

But the important bits aren't about any of these three. They're about a ton of other things, some of them being a big surprise for developers in particular. They deserve to be talked about, good and bad.

Running a small business is...

All About the Customer

The only thing that matters for a small business (for any business, really) is a happy customer. It helps to be happy yourself, but in the end, it's happy customers who pay the bills, and who continue to pay the bills as long as you can keep them happy.

There are a ton of ways to achieve this, and most importantly, you should have a product that they need, that they're willing to pay for.

Whatever you do during your every day, it needs to have the customer in mind. Which means one thing: you need to talk to your customers.

Even in the age of running businesses online, your biggest and greatest asset is still to be in personal touch with your customers. You need to pull your head away from code, and you need to spend time either visiting them, talking to them on Skype or at least sending them emails.

There are means to automate this, in particular emails over the lifecycle and on-boarding of a customer, but I can promise you that putting in this effort yourself is worth it. If you automate it, for instance by utilizing a platform like customer.io, make sure that a reply reaches a human (hey, that's you!)

The great part about talking to customers is that it's the best way to find out what they want, what they'd like to see improved in your product.

Most importantly, it's the only way you'll hear them say how much they love your product. Time spent with your customers is time well spent.

Not About Code

When all you do is interact with the customer, when will you finally get to write all that precious code?

The simple truth is, and this depends on the size of your initial team, writing code is not what makes you money. It sure helps to build a great product, but if you don't put in the time to market and sell it, to hold your customers' hands when they need you the most, no one will buy it.

The fact that you need to pull yourself away from code is one of the harsh realities of running a business, in particular if you're a developer by trade.

But it's the part that constantly pushes you out of your comfort zone. It forces you to talk to people, it encourages you to continuously improve your sales and marketing materials, to write blog posts regularly, to interact with your customers.

Best example is finding your price. You have to move out of your comfort zone from two perspectives. You need to put a value on your own product, and you need to find ways of showing that value to your (potential) customers, in particular when they come to you to heckle on price.

It's worth repeating: Running a small business is about anything but writing code.

It took me a long time to accept this, so it's okay to take your time, but the sooner you come around to the idea, the earlier you can work towards a thriving business.

All-Consuming

The dangerous part of running a business is that it's to easy to be excessive about every aspect of it, be it customer support, customer metrics, customer happiness, new features, marketing, blog posts, your product's availability.

It's easy to give in and not let go other than when you go to sleep. Just one more customer support email, just one more tweak on your landing page, just one more code change before you finally drag yourself away from the computer to have dinner.

From the last year's worth of running Travis CI as a business, this has been a dangerous trap for me, for all of us. It's too easy to just put in a few more hours at night instead of doing something entirely different, like reading or spending time with your spouse or your family.

It's too easy to get sucked in to working more on the weekend, neglecting your friends along the way.

This is a dangerous road, and it took me an unfortunately long amount of time to realize it. In hindsight I'm glad that I at least made sure I can spend quality time with my daughter.

Take care of yourself, of your family and of your friends. They're very supportive in what you're doing, so don't neglect them in return.

It's a noble cause to try and provide the best and fastest customer support you possibly can. But sometimes, and this may sound very heretic given all of the above, sometimes it's okay to let the customer wait until tomorrow.

Now go out, stare at clouds, have a drink or dinner with your friends or your family. Personally, I get the best ideas and fresh insight when I'm not in front of your computer, when I'm in the shower, or when I'm spending time with my daughter.

Exhilarating

As soon as the first customer hits the "pay" button, everything is starting to pay off. As soon as you get 10 or 20 more customers to pay for using your product, you will be the happiest person in the world.

There's room for a comparison to having kids, but that may be a bit of a stretch. Though sometimes, running your own business and selling a product successfully feels just like that.

Allan Branch compared the relationship to his co-founder to being married, so in that view, your product is your child, a labor of true love.

There are times when it's exhausting, when you struggle to find new customers, when you struggle to fix annoying bugs, when you struggle with customer support. But those times are offset by knowing that people are happily using something you've built, and they're even paying you money for it.

It's exhilarating.

Now keep going, make your product even better, get more customers, write another blog post.

Tags: smallbiz

I used to have this beautiful dream that I'd some day open my own coffee shop.

It sounds simple enough. All you need is an espresso machine and you're good to go.

Except you need to rent a shop, buy a giant grinder, or two, buy coffee beans, hire a barista or two, buy cups, take away paper cups, a water filter, and buy a freakishly expensive espresso machine.

Add some interior for the shop, and you're easily in the several tens of thousands to start your business.

Compare that to what you need to start selling products on the internet. You need to spend some time to find an audience, to find your market, and then, all you need is a laptop and an internet connection.

I have to keep reminding myself how little you need to start a business and to actually run it.

Beyond your computer, you don't even have to buy anything. You can rent (even pay by the hour) anything you need to serve your application, and you can utilize other services and products to help build yours. Heck, you can build on a ton of open source tools and libraries as well to help you get the job done.

You don't even need an office. All it takes is a itch you want to scratch. Whether you want to build and sell a product, build a business around it, or you just want to open source something.

I love that about what I do, and it's hard to understate how lucky and privileged we are being able to take something off the ground like that and to tell other people about it.

All it takes is a laptop.

What's keeping you?

Tags: smallbiz

We love grand ideas. As engineers in particular, we like the idea of building something big that solves an idea we've had. We love sweating the details, we love refining architecture, we love building the right tools for the job.

When you start a business, this approach can foil your grand idea before you even hit a market. This ignores that ideas alone are worth nothing without a market for them.

What if, instead of working on your grand idea right away, you start working on something small?

When you've found a market you don't instantly need to build a big product to serve it, you can start much smaller than that. Starting small has the benefit that you can gauge out the market and its interests and that you keep risk lower than with building something big right away. Products are shrouded in uncertainty, keeping the risk low means keeping your losses low, which is rather beneficial when you're bootstrapping.

Building something small initially and slowly increasing the scope of what you build has another benefit. Your initial products start feeding into the work for the subsequent products. The money made from your first products helps you to build more products.

Smaller Products can beget more, slightly bigger products. I love this idea, also called "stacking bricks."

The Riak Handbook turned out to be such a product for me. Working on it took the better of three months, a big part of that spent full time on writing, editing, creating the publishing workflow (I wouldn't recommend building the publishing chain yourself), and the marketing site.

While the book's most sales happened in the first days of going public, it continued to sell for now more than two years, both on the site and on the Kindle store.

It helped a lot in getting Travis CI off the ground as a product. It wasn't a lot of money that came in, but for the following twelve months after publishing the book, it brough in up to $1000 per month extra. Quite handy as passive income when you're working on bootstrapping another product.

How can you build something small before building something bigger? Here are a few ideas.

Build an audience with writing

The Riak Handbook started out by way of this very site, if you will. Early on in the craze of NoSQL databases, I started writing about the fun and silliness I had playing with some of them.

That in turn led to the idea of the NoSQL Handbook, which, after more thought, distilled into the Riak Handbook.

I unknowingly built up interest for the technology, just by sharing what I discovered playing with them. The joys of new technologies.

Sell what you learn (and what you know)

A book or even a series of screencasts is a great means to start stacking the bricks. It's a nice next step from building up an audience, and it doesn't even require you to be an expert at something right away.

Rather than dump your entire knowledge into a book, write about what you learn, or learn as you write.

Here's a little secret: the Riak Handbook was my personal Riak learning experience.

Sure, I've had exposure with it before, working for Basho and with their customers, but my deepest exposure with all facets of Riak was writing the book.

It turned out to be a great learning experience for distributed systems and for Riak itself, even picked up some Erlang along the way.

Sell something that doesn't yet exist

Here's a crazy idea, before you actually build something, sell it. Put up a landing page for your product, start marketing it, see if someone bites.

If they do, you have all the more incentive to actually build it.

I'm a big fan of grand ideas myself. But the Riak Handbook, as small as it is, was a convincing exercise that it pays to start small. It pays off slowly, and revenue will start trickling in, but as you add more products, you add more revenue.

Heck, if you enjoy writing and selling books, keep doing it. Build more, sell more of them.

For some more inspiration on starting small and building your way up, I'd highly recommend these books:

Tags: smallbiz

For a startup or a small biz in its infancy, every opportunity looks like a pot of gold.

Every opportunity that comes across looks like something you can turn into monetary value or use it to grow your product. It's really hard to say no to any of them.

It's your customer suggesting a new feature, it's a company that would like to do a partnership with you, it's a bunch of VCs that are courting you to give you a nice sum of money in return for some shares of your company.

Clearly, this new feature must be relevant to other customers and will allow you to get even more customers because you can advertise it. There are tons of reasons why you'd say yes to a new feature.

The partnership must be good for your business because it'll drive more traffic, it'll get you more customers, and two businesses benefit from it.

The VCs must be loving you, why else would they be courting you? Their offer is generous, and their demands sound reasonable. It's hard to say no, in particular because they tend to keep coming back when you do.

Saying no to any of the above seems like such a harsh thing to do.

You're afraid to lose a customer because you're saying no to them.

You're afraid to miss out on a deal that could help grow your business.

You're afraid of closing the door on future funding, even though you neither want nor need it. The offers are tempting, and VCs are full of nice words for your product.

How can you say no to any of them? How can you say no to a shiny pot of gold? Your gut says it's okay to say yes.

Science has an answer.

If you're a man, it turns out you'll be a lot more likely to take on risk because they may have strategic value. Getting more customers, making customers happy, and growing your product and company sounds pretty great as strategies.

As a woman, you're more likely to consider the empathic side of taking a risk (which all of the above involve). You're more likely to consider the effect a decision has on the people involved.

Note that these differences tend to be more noteable when you're under stress, a common state in early startups and small businesses. Doug Sundheim has a good summary on this topic.

Every decision you're making has a strategic effect, but it also affects people. It affects your employees, your co-founders, your spouse, your entire company.

In "Small Giants", a book on companies that chose to be great instead of big, there were a few examples of this, on both extremes.

One company held off their IPO because it'd mean that suddenly they'd have to answer to shareholders. Another made their decisions amongst a triad of three CEOs that would take days to consider the possible outcomes and effects of a major decision.

Or take Norm Brodsky, who, in the 80s, grew an empire of a bike courier business to big proportions, buying other messenger companies along the way. The last company he bought had much worse numbers than he was originally made aware of. He had to sacrifice his own money, he had to sacrifice his company's war chest to try and make it work.

In the end, he sacrificed his own company, as it filed for Chapter 11.

Norm wrote a great book called "The Knack", full of great advice and stories on how he's running a business, and on how he ran one of his companies into bankruptcy.

When it comes to a business, it's easy to say yes to say something without taking the time to consider the possible outcomes, putting aside the fact that you can't know all of them. There's usually a pressure to do so. VCs want to invest in you, customers want to see this feature they suggested, partnerships need to be signed off yesterday.

There's another side to the coin when you can't say no. You're wasting precious time dwelling on things that in the end may not be relevant to you. Time and attention is your most precious asset, protect it well.

You can start by saying no to things that distract you. It's okay to not listen to your gut for once and to stop letting outside pressures influence your decisions.

Use the little trick that Norm Brodsky started using after he realized that he's been taking more risk than he can chew: take a shower and think things through.

Learning to say no might be your biggest asset in finding focus for your product. Start saying it sooner rather than later.

Tags: smallbiz

There's a prevailing idea when it comes to startups and building and running your own business.

The idea that to be successful, you need to work hard, put in long hours, and push your team to the limit as well.

Keeping up with the competition, trying to make your customers happy, your investors too, and trying everything you can to turn your business venture into a success, however that is defined.

Some companies even go as far as advertising it as normal that you can just take your work everywhere you go, to the park, to your kids' soccer game, maybe even to the pub?

I've fallen into this trap, I've been putting in 10-12 hours per day, working from home, with my family around. The family is understanding, but that doesn't justify these kinds of working hours.

As someone working on a product that's used around the globe and at every hour of the day, I can relate to this idea. When production is broken, it's handy to have something around to respond. When a customer is having troubles, I want to help them. I'm used to taking my computer with me, even during the weekends.

Adding to that, with customers only coming online when it's the end of the business day in Europe, our support usually ramps up in the later hours, where customers come into our live chat and expect someone to help them with their problem.

Helping customers succeed is one of the most important purposes of a business, and we're trying as best as we can to help them out.

But that thought drove me into a habit that's hard to break free from. It's the fear that there could be a new customer support issue every day, that there could be a new customer in the live chat that needs help.

This very habit has driven me to being on the computer from the morning to the evening hours, always waiting for someone to approach us with an issue.

It's a habit that's been having a very destructive effect on my work and my life, and the two are not the same.

A few weeks back, as our team grew more and more, I've come to the realization that working longer hours gives a bad example, not just for myself, but it sets an implicit expectation that others on the team work just as long. It's poison for a team for even one person, in particular a manager, to work longer hours. It gives the impression that it's normal and expected to work longer than what your contract says.

It wears people out, it's worn me out, on multiple occasions.

We recently started doing support rotation, where everyone gets a dedicated day of doing customer support, escalating to others on the team where necessary. That gives the support person the freedom to only focus on customers for the entire day, and it gives the rest of the team the ability to focus on getting other work done.

It's been effective for us, and it's already improved our own tooling, our user interface and our documentation.

But I still can't shake the habit of always wanting to help. You can say that it's a noble habit to have, but its downsides are starting to show.

There's a quote from Small Giants that stuck with me:

For all the extraordinary service and enlightened hospitality that the small giants offer, what really sets them apart is their belief that the customer comes second.

A company's team is what sets it apart. That team needs to be well rested to make for happy customer.

The only way to get them to do that is to discourage long working hours.

In our company, that starts with me.

Success doesn't depend on how much you work, it depends on where you focus your time in the best way possible.

Don't work too hard.

Tags: work, smallbiz

There's a curious assumption out there, and it's time to put that assumption to rest for good.

It's the assumption that things should be free while they're in beta.

That assumption is made on both ends, your customers think it should be free, and you think your product should be free too.

It's bollocks. You're hurting your business by following down this path, and, while they have good intentions, so are your customers.

Free customers don't validate a business, they don't validate a product. Only when customers are willing to open their wallet for your product will you start to have validation that you might be on to something.

Offering a product for free while it's in beta implies the assumption that the product doesn't provide any value while it's in beta. If your product doesn't provide any value while it's in beta, stop what you're working on right now.

You think your product doesn't provide any value while it's in beta, and neither do your customers. At least that's how the assumption goes.

Are you sure that you've verified that there's a market, an audience, for your product that needs this problem solved? Is there more research you can do? Could you talk to one of the folks trying out your product?

If you can be sure that your product provides value, and this is why serving businesses is a much better idea than serving consumers, why are you not charging for it?

Does the label beta keep you from charging money? Remove it.

The sooner you start charging, the sooner two things will happen:

  • You know that your product has value to the customers that are willing to pay you for it.
  • Your business has a much higher likelihood of succeeding. Early validation gives you confidence that it's worth continuing with the product.

When we started out with our product version of Travis CI, we took a few months to develop what we considered to be the minimum features we could ship and throw at potential customers.

We launched our initial private beta in July 2012. We started charging in September 2012. But, and this is where we could've done better, we didn't enforce charging. If people didn't want to sign up, they could continue using the product for free.

Meanwhile, we manually emailed dozens of customers, asking them to sign up for a subscription and for feedback at the same time. This was a long process, and I wish we'd have automated sooner.

But it gave us a chance to see what people liked, what they didn't like. At the end of the manual process we had 100 paying customers. More than enough to validate that we were on to something.

A beta product doesn't make a product, let alone a business, yet.

But when you start charging early, and you find customers paying for it, you have a tiny validation that it's valuable to some. That can be a much more powerful realization and boost than trying to crank out new features to make free users happy.

The best way to validate a product is to get a customer to pay for it, then 10 customers, 100 customers.

Tags: smallbiz

Things that have been on my mind lately:

  • Implement lifecycle emails for our product to get new customers more to work with, using customer.io.

  • How do I best write the copy for these emails?

  • How can I increase customer retention?

  • How can I reduce customer churn?

  • How to get everyone on the team doing customer support?

  • How can we actively approach customers to get more insight into their problems?

  • What kind of better and more insightful content can I produce for this and our company blog?

  • What blogs can I run guest posts on?

  • How can I funnel more visitors from our blog to our product?

  • How can I make sure that everyone on our team is happy?

  • How can I adopt selling bacon as part of our business model?

These are only a few things that keep my brain busy.

So many things in my head, so little time to do all of them.

Life running a small business is never boring.

I'm a newbie, every single day.

Tags: smallbiz

When we set out to build our first product (Scalarium, now better known as Amazon OpsWorks, we started off with a rookie mistake.

Initially, we played with some ideas to test if we can fit them together. This was mostly focussing on orchestration of servers and their provisioning. We tried out a mix of RabbitMQ, Nanite and Chef (early adopters, yay!)

Back then, NoSQL databases just started appearing, and we thought, screw MySQL, we're going to use something new and shiny. We started out using Amazon's SimpleDB, but were soon hindered by its limitations.

We built Scalarium on Rails, so it was only natural that we started writing our own ActiveRecord-like persistence layer. First, we wrote it to work with SimpleDB, and it was aptly called SimplyStored.

Later, after some first exposure to CouchDB, we decided to use it instead. It was gaining some traction, and we had good access to local community support.

After we hit a wall with our first attempt at using a custom storage layer, we rewrote it to support CouchDB. Slightly different semantics made some things harder to rewrite, and some things were quite awkward to handle, in particular when trying to map an ActiveRecord-like query model on top of a database that requires you to define your data queries upfront and store them as JavaScript or Erlang views.

We spent a lot of time on SimplyStored, and for no good reason other than the technical fascination with the idea of not using MySQL, a proven and fast database, which would've been very sufficient for our purposes.

In the end, we still managed to build a good product, but shipping it was extended unnecessary amounts of time by trying to start building our own stack rather than use what's there and what's proven.

It's tempting to use new technologies when you're building something new. After all, you've got a clean slate and can just play around.

But when you build a new product as a new company, getting something up and running, something to throw at users, is even more important.

It's okay to build up some technical debt along the way. Yes, you will spend time later cleaning it up, but at least you can do that knowing that what you've built initially was successful enough.

With a proven product that's bringing in revenue, you have more freedom to gradually remove the technical debt built up in the beginning. Of course you'll be adding new debt along the way, but that's just the circle of software engineering life, isn't it?

At Travis CI, we also made some mistakes of where we focused our attention while building a product. Some things were more focused on building something that's technically sound rather than make sure we get a working product in front of customers quickly.

Early on, Travis CI started out as a test balloon if you will, with a few simple components to prove its technical viability as a continuous integration system. Leaving some challenges aside, we were able to scale it out quite nicely. We're still working on removing the technical debt that we built up, but given that our customer base allows us to do so, that's just fine.

With Scalarium, it took us almost a year to get something in front of customers, an insanely long time. Looking back, the thing I would've done differently is not building our own persistence layer, which has no relation at all to what we were trying to build. It just took away precious time from building our first version that could be used by customers.

When building something new, be careful to not fall into the trap of shiny new technologies. They can be blessing and a burden, but the latter is all the more likely when you step into the unknown.

Using proven technology can be incredibly boring, but they give you the room to make sure that what you're trying to build and sell is sound as a product, rather than a technical masterpiece.

When building something new, simple and proven technology wins. You can always add more bells and whistles later.

This is the essay version of a talk I gave at Jimdo.

Out of Business

Travis CI started out as a small platform for Ruby projects to run their tests on. Back in 2010 and 2011, there was a distinct lack of hosted continuous integration platforms.

It was launched close to the day, three years ago, with a small announcement.

Some Ruby projects quickly adopted it, Rails started officially moving their tests to Travis CI.

Later, in 2011, more language communities discovered the platform. We added official support for PHP, for languages running on the JVM, for Erlang and for Python.

We now also support Perl, Haskell, and anything you'd possibly want to run on a Linux platform. Plus, you can build projects on OS X and for iOS.

Unfinished Business

Initially, Travis CI only supported open source projects. But people and companies kept asking us to use our platform for their private projects as well.

The idea was floated to found a company and turn this into a business, work on Travis CI full time and get paid to do it.

By the end of 2011, a company was founded, and two more people joined the team. We were five people trying to build a business, four of them developers.

In early 2012, we started a crowd-funding campaign to bootstrap our business and allow some folks on the team to be paid for by the company. It allowed us to keep the open source platform running and to improve our feature set.

One of the features coming out of that was pull request testing, which initially was done by having a bot comment on pull requests, annoying the heck out of some people.

We Mean Business

We started working on our product, and we tried to figure out the hardest part about a product, the pricing.

We started thinking about revenue, all the crazy things you have to do when building and running a business.

We launched our product into private beta in July 2012 and started charging in September 2012.

It was all rather hack-ish, and we didn't yet force everyone to sign up for a paid subscription. All the work involved in getting people to sign up was manual. We picked out a few customers and emailed them, encouraging them to sign up and to give us feedback.

Back in Business

This worked surprisingly well and by the end of 2012, we had more than 100 paying customers, allowing us to pay two on our team some sort of wage. Plus, we could pay for our infrastructure.

While that didn't imply a raging success, the signs looked right.

Whilst trying to build up our business, we had to solve scaling puzzles already on our open source platform. This was both blessing and curse.

We were running 7000 builds per day in 2012, compared to 700 in 2011.

In comparison, by the end of 2013, we were running a total of 65000 builds per day.

Solving these issues upfront on the open source would mean we'd know how to solve them when they'd come up on our commercial platform. On the downside, we'd been distracted by these things, rather than being able to focus on the business.

We were able to break Travis CI early on and see the potential affects of any fixes before they'd become critical to our business.

As a challenge to ourselves, there's one special ticket that was opened in early 2013. When our business was in a stable state, we'll be shaving off Sven's mustache.

Business Never Personal

For developers, though, business is tough. Figuring out how much to charge, how to approach customers, how to do customer support (and to understand how important it is), is something entirely new for most.

It posed a big challenge for us, and it took a while to get everyone behind the idea that customer support is essential to our business. When it comes to code, every customers' project is a unique snowflake.

Every project has its own interesting dependencies that can break in the most curious ways. Complex test suites pose challenges for our platform and for our infrastructure.

Solving these can be a tough challenge, but talking to customers about them upfront is what makes them less painful to them.

We spent some time thinking about how we can make Travis CI, how we can surprise our customers. A friend floated the idea of using coffee as an inspiration.

Initially, we wanted to send thank you notes. But we wanted to add an extra twist. A friend suggested we could send out bags of coffees to our customers, combining our passions, and doing something completely unexpected for our customers.

So far, we only shipped some 300 bags, as we had to take a break to tackle some issues, but we intend to pick this idea up again.

Strictly Business

Rather than do strictly business, we wanted to run an open company.

When we have problems that affect our customers and users, we try to be as open as possible about them. They're annoying, but when explained, people do understand that scaling issues can pose unforeseen challenges that aren't easy to solve.

Open operations an unintended marketing channel, if you will. Based on the openness, people can decide whether they want to buy into the fact that we do have outages, that we do have issues, or not.

Marketing is an interesting topic, as we technically didn't do any. None that is directly measurable or where customer growth can be attributed to. Whether that's a good thing or not, I don't know.

The one business-changing thing we did in 2013 was to finally put up a landing page for our product and to actively let people try out our platform and allow them to pay for it.

That's our secret to strictly business.

If you don't give people the opportunity to try out and pay for your product, how and why would they?

Business as Usual

When we finally solved our bigger technical challenges to scale out the platform, we were faced with new challenges: people.

Something every company experiences at some point in its lifetime is to hire people.

We started hiring a few more people in 2013, people working remotely from the start.

We wanted them to feel like they're a part of the team, like their happiness is what's most important to us.

This is a tough challenge, and we have yet to figure it out. I'd say we're doing pretty okay, but there's always room for improvement.

One thing we're trying out currently is support rotation, with everyone on the team involved, no matter their status. The more everyone on the team knows about the product, the more eyes we have on ideas to improve it. The more everyone is exposed to customer issues, the higher the incentive to fix them.

We give people on our team the freedom to do whatever they like, whenever they like. A happy team with a focus on customer value leads to happy customers and a healthy business.

That's our ideal.

At the beginning of 2014, we have 700 paying customers. That may not sound like a lot, but it's close to infinity when you're starting a business from scratch.

We're running a bootstrapped business, we've turned down VC funding multiple times, and proudly so.

Open source is still at the core of our business and our team.

We believe in the power of building good products with people who are passionate about them.

Also, there was this:

With our own company growing, both in terms of our team size and our customer base, I keep finding myself thinking more about what kind of company we want it to be.

This touches on all aspects of the business, relationships with our customers, marketing our product, how we treat our community, both globally and locally, and most importantly, treating and growing our team.

What it boils down to for me is openness on the one hand and fairness on the other. Everywhere a company is active, there are always humans involved. Any issues that come up are best served by being brought out in the open, treated with empathy, the will to solve the problem, and the assumption that people are generall well-intentioned in what they do.

This goes into all directions, because at the very core, empathy is the most fundamental skill, both for the humans working in a company, and for the company itself.

Empathy is sometimes described as a personal trait, but it's a skill, a skill that can be learned, that can be honed, and that can be instilled as a core value of a company.

Empathy means taking your customers' issues seriously, acknowledging their problems, helping them fix any issues they might have, no matter if the issue is on their end or on yours.

Customer loyalty isn't something you can buy, it isn't something you can put a number on. Customer loyalty is something you have to work on every single day.

Empathy means building relationships with your customers rather than look at them as transactions. When they have issues, you have issues, it's simple as that.

It also means that when there's a bigger issue at stake that affects your company and your customers, it's tackled out in the open, head on, rather than swept under the proverbial rug. This includes security issues, operational/production issues, but also issues that affect your company in other ways.

We like to think that a company's brand and image can be controlled. The more we repeat our values, what we stand for, the more our customers will believe it.

That's bollocks. You can spend years trying to make yourself look pretty on the outside, but that facade can be destroyed by that one small thing that you didn't want to make public at the time.

Empathy means being open and honest about anything that affects your company. Does that mean you have to tell the world exactly how much money you're making or losing?

In what detail you make what you do public is up to you. We tend to fear that publishing too much could play into the hands of our competitors, that it could confuse customers, despite there being next to no proof this is actually the case.

I admire Buffer's openness in this regard. They're publishing their team's salaries, the letters they send to their investors, numbers about growth and losses. Can that hurt your company in any way? No one knows, because it just hasn't been done before.

Empathy means that your company is aware of its surroundings. Even in times of companies selling things to a global audience, with a distributed team, companies have a home, where they pay taxes, and a community they're inadvertently a part of.

An ethical business is about giving back to the community it's working in. I found inspiration on this in "The Knack", where the employees can get involved in community work on the company's time, and they get to choose a good cause to give something to at the end of the year.

Amy Hoy is doing something similar, part of their profits go to local charities. I found this very inspirational, and we started doing the same with part of our profits last year.

Beyond that, there's community work, helping kids and schools in need, lots of opportunities to jump in and help out in a company's local surroundings.

Empathy means treating your vendors with the same courtesy as you treat your customers. The same applies to them, you want to build relationships rather than think of vendors as a transactional means for your business.

Vendors are people, just like your customers, the people in your community, the people working in your company.

The people on your team are the most important for any company. Some would argue differently, but I'd say that for an ethical business, how you treat the people working for you is what shapes any interaction your business has with its surroundings, with its customers.

There's a quote in "Small Giants" that stuck with me:

For all the extraordinary service and enlightened hospitality that the small giants offer, what really sets them apart is their belief that the customer comes second.

On first sight, it sounds harsh. Clearly, a business' customers are the most important for its continuing success, no?

It takes a happy and driven team to make for happy customers. Relationships can only be made between humans. While customers can use your software or product, or whatever it is you're selling, whenever they have issues, they expect a human to help them out.

Building healthy relationships between your company and your customers requires all people in the company to have healthy relationships with each other, with the people they work with, the people they work for.

Just like with your customers, you can't buy your team's loyalty. It requires you to build relationships with them. Relationships are based on trust.

I'd argue that you can only earn trust by putting your trust in someone in return. Allowing people to do the right thing, yet still give them room to fail and learn, is the simplest beginning to build trust.

When it comes to the people you work with, trust is reflected on different levels, not just work, but also how your company treats their personal lives.

Trust, in turn, comes down to empathy.

Empathy is the recurring theme in this post, it's the recurring theme in any human interaction. Empathy means you take your time to appreciate, to contemplate what another person is thinking, what they're saying.

Whether it's your customers or one of the people you work with. Listening to their concerns and treating them as if they're yours is the start of building trust. If people learn that you can listen to them, without judgment, and help them figure something out, you're off to a good start.

As Chad Fowler said, empathy is your most important skill.

This is something I'm trying to work on every day, work against my instincts, listen to people first, ask questions, before I pass in my own view of judgment. It's hard work.

For an ethical business, a lot of things come down to "doing the right thing."

The right thing in the global, local or your company's micro scope can have lots of different meanings, and figuring those out will be the hardest. We've spent a lot of time working that out for our little business, and we're still at the very beginning.

Does an ethical company strive for profits? Of course, the question is how they're used. A company needs cash to survive in the long run, but it also needs to take care of its surroundings to function well.

What makes an ethical company then? I believe the core values lie in openness, honesty and, most importantly, empathy. Those are skills that need to be acquired, practiced and honed. We're only at the beginning of this journey for ourselves, and we're working hard to stick to these values.

Tags: smallbiz