The Many Hats I’m Wearing as a Founder

The roles people have in companies are not secrets to anyone. Nor are they surprises.

Yet, when creating a company, they’re easy to overlook, with devastating business implications.

When starting a company, you will have to do things you never did before. Things you don’t know how to do. Things you don’t like doing. Things you didn’t know needed doing. Things you thought didn’t need doing anyway, and which you may have been cynical about. I most certainly have been.

This gets “worse”, or let’s say more challenging and interesting, when you’re alone in the company.

Wearing hats

I like the metaphor of wearing hats. Because that’s what I’m doing all the time. Before tackling any given task, I ask myself: What hat am I going to wear while doing this task? And with that question in mind, I change who I am as a professional human being. While wearing the “cool”, Dilbertesque Developer Hat, I can get away with the occasional snarky and sarcastic comment (you may know me from Twitter). This attitude is less useful when wearing The Marketing Hat, and absolutely wrong when wearing The Sales Hat. In engineering, everything is a risk, and difficult. In sales, everything is possible and can be turned into money. How much more different could these worlds be?

This is obviously not strictly related to running a company. Wearing many hats can be a situation that can happen to employees as well, and it isn’t a bad thing. It’s a cool challenge. A nice way to get out of one’s comfort zone.

Yet, as an employee, those hats are often assigned to us. As an enterpreneur, I have to discover the need for wearing those hats myself. And if I don’t feel like it, I can ignore any specific hat, at my own risk (which I can ignore as well). And as a solo entrepreneur, I’m wearing them all myself.

Some hats at Data Geekery

Here are some hats that I’ll discuss in this long read, which I have been wearing when running Data Geekery. And some hats I’ve chosen not to wear. The hats I’m oblivious of, I can obviously not discuss. Feel free to comment, though!

• The Developer Hat
• The QA Hat
• The Operations Hat
• The User Experience Hat
• The Requirements Engineering Hat
• The Product Manager Hat
• The Project Manager Hat
• The Marketing Hat
• The Sales Hat
• The Public Relations Hat
• The Customer Support Hat
• The Legal Hat
• The Account Management Hat
• The Accounting Hat
• The Human Resources Hat
• The Administrative Hat
• The CEO Hat

If you work in the enterprise, you might identify even more hats, or more nuanced hats. For instance, the legal hat can be split into many different sub-hats, including risk, compliance, acquisitions, etc hats. Sales might include business development. Human resources might include internal fraud detection. Such distinctions really don’t make sense for a very small company like Data Geekery.

Let’s look at the many hats I’m wearing at Data Geekery, what they mean for the business, why they’re so important (and often overlooked / not appreciated by developers, including myself, in the past), and for each hat, how I see myself wearing it, how I see myself in that role, and an occasional anecdote:

The Developer Hat

This is the hat most of us are comfortable with, assuming your background is being a developer. This doesn’t change once you start a business. It just gets a little less important in terms of time spent wearing this hat, over time. In fact, it gets a whole lot less important. Which is good, that means the business is successful.

Here’s what wearing this hat involves (among many other things):

• Architecting code
• Designing code
• Writing code
• Testing code
• Documenting code (not just for yourself, but also for your customers)

Not necessarily in that order. Of course, we could split all of these technical hats as well, but that’s not going to be the point of this business related blog.

How do I see myself wearing The Developer Hat?

I feel quite at ease doing this work. I’m naturally sarcastic, skeptical, with a dry sense of humour (not denying the occasional lame dad joke and pun). I would also think of myself as very thorough, although not perfectionist. I like logical thinking and reasoning about code. And I think I’m not too bad a coder.

The QA Hat

I’m lucky that QA (Quality Assurance) for jOOQ can be 100% implemented through The Developer Hat. Most of the tests are automated, some tests are triggered manually (especially when testing the more esoteric database products), but still the tests run automatically through standard JUnit tests.

If automated tests aren’t possible or reasonable, e.g. because you have a very complex UI, or your test involves a lot of “human factor” (including user experience validation), I guess you simply cannot do without real human testers.

How do I see myself wearing The QA Hat?

Luckily I don’t have to. I don’t know how people put up with the monotony of repeatedly and manually testing user interfaces without too much automation, when the main experience of the job must be like: “Rats, why did this break again?”

Yet, having worked with human testers in the past, I do recognise the supremely high value they have for the business. A lot of business logic resides with these testers, who know the application and the domain very well. I think this hat does not get the attention it deserves in our industry.

The Operations Hat

If you work at a small to medium sized company, there’s always that one employee who takes care of all the servers, the licenses, the backups, security, etc. Maybe you are that employee, but chances are, you’re not. Need a new laptop? Just get one from the stash and put a ticket on yours. That person will take care of it.

Guess what? If you’re solo in your company, you’ll do all of that, yourself. And there’s one simple advice I have to give here: Don’t be stingy. Buy those licenses. Outsource those services. SaaS is a real blessing in this regard. Or, do you really want to worry about “stupid” things, like security or backups? Absolutely not.

Do get:

• A cloud file hosting service that suits your file archival needs
• A professionally hosted mail server
• Office automation
• A payment services provider

And other things that make sense for your business. There are many tiny little services that are so valuable both from the business side, but also from the operations side. The jOOQ manual uses Disqus to provide feedback. This feedback is very important from a Customer Support Hat perspective. But also from an operations hat perspective. Because by paying for this service, I have something that just works. One piece of infrastructure software less to worry about.

For Data Geekery, developing a library, infrastructure needs have been a bit simpler than for other businesses. Most importantly, Data Geekery doesn’t host any customer data on servers, which requires quite a bit of additional work and due diligence – rightfully so – in times of GDPR and constant data breaches.

Cloud

I have several devices, depending on what kind of work I do (coding, consultancy, presentations). I need my documents on each of these devices. Google Drive is just too simple not to use. All my invoices, contracts, notes, quotes, purchase orders, etc. are quickly available on any device. It kinda seems like a no brainer, but if you work at a larger company who has their own NAS, this option might not occur to you.

At some point, or if you’re going to work with highly sensitive data, perhaps a NAS does make sense. Until then, get faster and better results (and backups!) with cloud hosting.

This also includes hosting your code, which in jOOQ’s case is:

• BitBucket for the commercial sources
• GitHub for the Open Source Edition

Office automation and mail server

But really, the first and most valuable investment I’ve made for Data Geekery is to get licensed for Office 365. There’s absolutely nothing better and cheaper in the market for more value in the topic of office automation. The entire service palette is included, even an exchange server. Ask yourself: How much time do you want to spend setting that up? You’ll never get comparable value for any DIY solution.

A few developers might think that open source is a viable alternative in this space. Unless your clients are also open source-y: I suggest you don’t go down that route. Microsoft’s products are really great and I do think they make me look more professional with clients that are not too technical.

I remember the times at a previous employer who wouldn’t want to give me an exchange server, because M$. I had to constantly tell my customers to please send me calendar invites as plain text, because I could not open them otherwise. Of course, we could lament Microsoft’s monopoly and the (then) lack of standard calendar formats. But why would my customers care about these things? They just want work to get done. We were using Thunderbird and a DIY calendar implementation (!). It was the mid 2000s. Times were different.

Eventually, I figured out that I should just start BCC’ing my boss and his boss on my frequent emails about re-sending calendar invites. Swiftly, I received an exchange server and MS Outlook.

Payment

Also very important for any business is to be able to get paid.

Do you sell only 1-2 very expensive enterprise licenses per year? Don’t worry about automation. Your entire business is oriented towards The Sales Hat and The Key Account Management Hat. You want to manually process quotes, purchase orders, invoices, and possibly play golf or something with your customers.

Do you sell hundreds of inexpensive consumer licenses per year? Automate! I can tell you, the amount of time I now spend on account management, running after expired credit cards, finding out whether 7 licenses are still enough, etc. is already very high, even with the automation provided by my payment services provider.

Also, be very careful to pick the right payment services provider. You want these things to be covered:

• They help you with VAT (in the EU)
• They support a lot of payment methods (there’s a big world beyond credit cards, you know)
• They help you with PCI compliance (and you never want any credit card information yourself!)
• They support many currencies, and convert them correctly
• They have customisable checkout forms and APIs for your license management

You don’t want to build a sophisticated shop yourself, unless of course, the purchasing action is a key part of the User Experience – as in a retail shop – in case of which this advice does not apply. Otherwise, again, don’t waste too much time early on with this non-essential activity. You can still do that later (I haven’t, after 5 years in business).

How do I see myself wearing The Operations Hat?

Operations work is some of the worst (for me). While work may be a bit less monotonous than QA work, it feels like operations is all about extinguishing fires all the time. And mostly, these fires should have been prevented by automation and resilience as well. (Perhaps by QA’s sloppy work?). And by outsourcing to SaaS vendors.

I do think that developers and operations people are entirely different breeds of people. Without judging them, I simply couldn’t do this. And very luckily, I don’t have to. Since the invention of SaaS, we live in the best of entrepreneurial times! Marc Benioff (the Salesforce founder) said, in his book Behind the Cloud:

All companies benefit when they can afford to focus on innovation rather than infrastructure

This is also, of course, why you should buy jOOQ rather than roll your own SQL API!

The User Experience Hat

You’d think I’m lucky here, because jOOQ does not have to worry too much about UX (User Experience)? But that’s wrong. jOOQ is an API. It is mainly an API. And as such, a key success factor is its UX. Just look at JPA Criteria API for a UX comparison.

I think the term UX is underused and also underappreciated in the context of APIs, because APIs have users. And they “experience” the API just like an “ordinary” user of a UI experiences the UI.

One of the key features of jOOQ is that a user should never really need to look things up in the manual as they discover the API. Everything should be exactly where a user would expect it.

Perhaps, among APIs, this is a bit specific to a SQL DSL API like jOOQ. Because the assumption here is that the user already knows SQL, and now they want to write SQL, but with jOOQ.

I cannot give any general advice on UX as I am far from being an expert in this domain. But I can give this one advice: Do apply dog fooding agressively. I write tons of jOOQ queries in the integration tests. jOOQ uses tons of jOOQ API internally. I observe user code on GitHub and at customer sites, when I do jOOQ related consultancy jobs. I keep running into warts and bumps as far as the API design is concerned all the time. I tend to notice such flaws long before any customer – at least before they mention it to me. I fix the flaw. Because the UX of using jOOQ must be impeccable. This is a key distinguishing factor compared to competing products and alternatives, where I often feel that “making it work” is good enough. It is not good enough for jOOQ. jOOQ users must feel great about themselves, when they use jOOQ. That’s UX.

I think a lot of people in software underestimate the benefits of UX. If you create your own business: Don’t underestimate these benefits. If your customers are non technical, they will quite likely make a purchasing decision almost purely based on their first UX impression. Functionality often seems secondary. The best example: Apple.

How do I see myself wearing The User Experience Hat?

I personally love this topic. User experience is all about the customer and their success. Specifically, it’s their success thanks to my own hard work – this is a very rewarding feeling. My work matters, in the best possible way. I specifically like the UX perspective, because I’ve always had a “faible” for design.

A different perspective on customer success will be repeated through The Requirements Engineering Hat and The Customer Support Hat.

The Requirements Engineering Hat

This is a hat many developers already know, because often, they do participate in the requirements engineering process. Ideally, a developer will spend time with the customer and watch them solve problems in order to identify:

• Missing features
• Wrongly implemented features
• UX problems
• Plain old bugs (that the customer might not even notice)
• Performance problems (again, the customer might not notice this)

With Data Geekery, this has become even more important. As with many of these hats, a customer interaction does not involve a single hat only. For me, requirements engineering mostly happens in parallel with Customer Support, either through email support or, when a customer orders consultancy services, directly at the customer site.

I love meeting customers!

Not just because I can better fulfil all the tasks wearing the other hats, but also because after such a meeting, I will leave with a big list of things that have to be changed, or improved. Again, maybe one such new requirement may come from the customer themselves. But most of them are ideas I get from merely observing them use my product.

Granted, requirements engineering is quite simpler for technical products like jOOQ compared to “ordinary” products solving problems in some other industry and domain. The main reason is that the domain I’m working in is also technical, and thus much better understood by a software engineer. As a nice side effect, this also helps stay clear of bikeshedding minefields like software architecture, DDD, and all sorts of topics where software engineers tend to build non-essential bloat and ceremony, following the latest Fowlerism.

How do I see myself wearing The Requirements Engineering Hat?

Like the previous User Experience Hat, this one is all about understanding the customers’ needs. While UX was about the human / machine interaction, and thus operating more on a psychological level, The Requirements Engineering Hat is more functional, working on actual value propositions for the customers’ businesses.

I love doing this. I’m in constant touch with a large community of jOOQ users through different channels: In real life, through Twitter, mailing lists, GitHub, Stack Overflow, or 1:1 email with paying customers. Each interaction helps me prioritise topics, and get a new perspective on the topic. As long as I’m in control of most of these interactions, I can get a long term feel of what’s really important, and how a problem should be tackled in order to serve as many customers as possible.

Which leads us to The Product Manager Hat.

The Product Manager Hat

Very closely related to the previous Requirements Engineering Hat, wearing The Product Manager Hat means I will prioritise the tons of requirements I’ve gathered. Not only will I prioritise them, I will also merge them. A single generic feature that can very easily be specialised 100 times is often better than 100 completely distinct features that all do kinda (but not exactly) the same thing.

We call it refactoring. It also applies to many other areas in professional or even personal life. This is about the big picture. Where do we want to go in 1 year. In 5 years. How can we consolidate and/or separate features into distinct units, which we can sell maybe at different prices to a different target audience under the name of a new product?

As can be seen, unlike The Requirements Engineering Hat, which still focuses on individual customer needs, this hat is a much more strategic, “backoffice” hat, where individual customers do not play such an important role anymore. It is much more about markets as a whole, leading to The Marketing Hat, and how to offer value to these markets.

So far, jOOQ has been a single product, doing a single thing only. So, product management hasn’t been a very central aspect of my business, especially the business part of product management. In the near future, I’m planning to create new products on top of and around jOOQ, mostly under commercial licenses. I will definitely get back to the topic of The Product Manager Hat when I’m ready to share more experience.

How do I see myself wearing The Product Manager Hat?

Until now, this hat hasn’t been very essential to jOOQ. The technical aspect of product management was implemented frequently, but I’m definitely looking forward to the business aspect of product management as I’m planning to grow Data Geekery.

The Project Manager Hat

Unlike The Product Manager Hat, which looks at mid to long term strategies, transcending the needs of individual customers, the Project Manager Hat is about less strategic short term work. About the allocation of time, money, and human resource budget to a set of tasks. In a way, when product management has defined the strategic goals, project management will implement the steps required to achieve those goals.

Depending on whether you’re a product company or a services company, the focus may be more on one or the other. As jOOQ is a product of very limited, technical scope, project management is not something that is required very frequently. Luckily, I think. Because project management is an extremely challenging task, with a lot of seemingly random influence

How do I see myself wearing The Project Manager Hat?

At previous employers, I have never envied the project managers. In most companies, this work involves running after all sorts of problems, poking people to finally do work X or Y, worrying about delays, budget constraints, and the mood of everyone involved.

It’s quite a stressful world, and I really don’t like stress. There are people who are born to do this job. I am not. If Data Geekery ever evolves to a point where project management is needed, I will definitely hire someone for this.

Until then, I’m really happy that I can stay out of this trouble. I don’t have meetings, deadlines, nor most other sorts of obligations.

The Marketing Hat

I love marketing.

My wife keeps laughing at me for my unlimited self esteem. I kept telling her for years that jOOQ was “objectively genius”. Whatever that means! Marketing is the extension of that. While The Sales Hat is all about telling your customers that they’re awesome, The Marketing Hat is about telling your customers that you’re awesome yourself.

Sales and marketing in a nutshell:

Sales: “Customers, you rock!”

Marketing: “Customers, we rock!”

Of course, I’m exaggerating. And I’m unfair to marketing. Again the developers’ cynical perspective. The Marketing Hat might as well be the most important hat in this list, at least for Data Geekery. This is why this will be the biggest chapter.

First off, marketing is about markets:

• Identifying markets
• Researching markets
• Validating markets
• Entering markets

And once we’ve put a product in a market

• Establish and maintain a brand
• Continuously validating product market fits
• Influencing the market

A lot of people mistake marketing for the only visible thing a marketer does. That’s the very last bullet. We see some company’s advertisements, newsletters, brands, etc.

But behind the scenes, there are many more tasks. Granted, I do not very formally execute the above tasks, mostly, because this is not my main skill – I’ve learned this over the years by myself as a byproduct of doing Data Geekery. For Data Geekery, marketing is rather simple, just like product management before. There’s a single product, there’s a big market for that product, and so far, as a single person company, I’m very far from having saturated this market.

Influencing the market

But I have been heavily influencing the market, through a variety of ways, including:

• Technical content marketing
  
  Through the jOOQ blog and its syndications such as DZone and JAXEnter has worked exceptionally well. Most of the customers have been acquired through inbound sales, meaning that customers who already had the need (were in the target market) would easily find jOOQ through Google. Other customers would learn about the fact that they might have the need via the jOOQ blog and brand through a constant brand exposure over the blog and other channels.

  Eventually, they would give jOOQ a try and they would love it.

• Nontechnical content marketing
  
  You’re being exposed to this right now, reading this blog. This is an experiment I’ve started, inspired by a lot of similar blogs, such as the one by Groove HQ. The goal is quite different from the technical content marketing blog, as is the target audience.

  While the nontechnical blog should also help improve the jOOQ brand (and my personal brand, see below), it does not do so by advertising jOOQ itself, or the training, or the consultancy services. Instead the goal is to create a conversation around what’s behind creating a business with like minded people, other entrepreneurs, or people who are simply interested in jOOQ, Data Geekery, or me.

  The feedback so far has been very encouraging, in an entirely different way from the technical blog. The business blog triggers many more reactions and discussions, both online (e.g. on Twitter) and offline (through 1:1 emails). It sparks great ideas both for me and for you, and the wonderful thing is: All of this greatness and openness is being attached to the jOOQ brand.

  This has secondary effects. Someone who is unlikely to ever license jOOQ but finds jOOQ and its business interesting nonetheless, will refer both this blog, and perhaps jOOQ to their network. This again means that a trusted referral will eventually lead to someone discovering jOOQ who is much more likely to also license jOOQ.

  I’ve done so with the above Groove HQ blog all the time. I don’t care about their product right now. But I do care about their blog. And I’m sure, my many referrals have converted for them, already.

  And if not, it doesn’t matter either. Because everyone is learning interesting things about creating a business, including myself, which is rewarding. When you’re a small company, not all of your actions need to be immediately money driven. You can experiment, and do what you like, without knowing or worrying about the immediate effects. And I do like conversations with you.

• SEO (Search Engine Optimisation)
  
  I had many discussions with other influencers in our industry about the usefulness of the above syndications (e.g. DZone and JAXEnter). There is wide agreement that syndications hurt SEO for your own domain. I agree with that. But SEO and search engine related traffic is only one side of the coin. Especially DZone allows me to get my brand and value proposition onto an entirely different channel and target audience that I couldn’t easily reach otherwise. At the price of (probably) less direct traffic from Google on the jOOQ blog itself.

  If I wanted to increase conversion rates for on-site purchases (e.g. selling a book or training), this disadvantage is very relevant. Conversions for these “easy” purchasing decisions can be linked directly to traffic. However, purchasing jOOQ licenses is not an “easy” decision. If tools like IDEs, monitoring tools, etc. are hammers (easily replaceable), then jOOQ is a nail (becoming a part of your application for good). When selling nails, it is much more important to build up long term trust in a brand, rather than focusing on individual clicks. I do believe that in my business, reaching more channels e.g. with syndication is more important than SEO for a single domain.

  See it as a form of advertising. By publishing on other domains, I can advertise my brand for a relatively low price (slightly impaired SEO)

• Advertising
  
  I may have completely misunderstood how Google Adwords or Facebook Advertising works. But it simply hasn’t worked for me. At all. There’s a high initial price you have to pay before you see any results at all, and then, you should probably iterate and continously improve your message. Or, you just engage in content marketing, which is free advertising, once you establish a brand and get decent SEO.

  Your mileage may vary (and I should definitely hire someone at some point to do this again for me), but I’ve found advertising not to work very well for me.

  As a small company, there aren’t too many options in advertising, either. Stack Overflow seems like a very good place to advertise, but is super pricey. I might get back to this topic in 5 years.

• Newsletter
  
  There once was a newsletter about jOOQ. It had a few very loyal readers, who would open every email several times and click on the links several times. And then, there were 90% of people who never even opened the email. The newsletter grew to 5000 readers relatively quickly, but had little engagement.

  Mailchimp claimed that engagement on the jOOQ newsletter was 2.5x higher than the average engagement of similar IT related newsletters. Yet, I found the task relatively boring and not very effective, given the absolute engagement numbers.

  With GDPR, I finally killed the newsletter, which saved me the hassle of sending this stupid GDPR email everyone else did. This is by no means a very thorough assessment of how well newsletters work. I’m sure they do for some. I personally hate every single newsletter I receive with very few exceptions, so I may just not be the right person to author them. Do make your own experience here.

• Merchandise
  
  I have mixed feelings about this. I know that people in our industry have a really strange desire for stickers. That’s something totally affordable, and people are going to put my brand on their laptops for free. That’s really cool. In other industries, like sports, brands have to pay a lot of money to be displayed on sporting devices or on the sporting people themselves. Of course, the brand exposure is a different one.

  T-Shirts and other merchandise are another story. I really don’t understand why companies do that. When going to conferences, I have received dozens of really ugly T-Shirts over the years. Today, I no longer accept them because I’ll throw them away or donate them to Caritas anyway. Producing T-Shirts is much more costly than stickers, and I’m not convinced the effect is much bigger.

  I personally don’t believe in merchandise (in our industry). It may work for some exceptional cases, like those Oracle DBA that have model America’s Cup boats in their offices. But a small and/or niche company simply doesn’t have a strong enough brand such that customers would like to associate with the brand on that level.

• Website optimisation
  
  The jOOQ website is quite static and I’m not doing any A/B testing to find out what works best for onboarding customers who navigate the website for the first time. Without this, I’m surely losing quite a bit of money on the first impression the website makes, especially on mobiles (shame, shame).

  This is quite a time intensive thing to do (my main excuse), but I would definitely recommend you don’t make the same mistake as me and neglect this topic.

• Speaking at conferences
  
  I’ve always found this to be the most fuzzy marketing effort of mine. When talking at a conference, I’m really kinda broadcasting a message into the audience, with very little, difficult to follow up interaction at the end of my talks. I’m certain that it is a good way to create initial contact between the audience and my brand. I’m also certain that it is a good way to strengthen a brand (especially my personal brand). But it is almost impossible to link these efforts to actual conversions, that might happen years later – at least for me.

  This effort comes at a high personal price. Travelling is extremely straining. Just recently, I’ve visited the wonderful Eureg JUG for my talk about SQL algorithms (which you should totally watch). German trains are notoriously late, but on this day, they were also frequently cancelled. Reaching Aachen from St. Gallen proved to be an adventure, and instead of 3 hours early, I arrived 1/2 hour late. Thanks to the flexibility of the hosts – especially Michael Simons who improvised a talk prior to my own – we didn’t have to cancel my own talk. But it was frustrating.

  While I do think that talking at conferences is generally great (especially because of the networking with other speakers), I think that the cost / benefit ratio is not very good for small companies like Data Geekery.

  However, see the below personal branding section, talking at conferences is really great to create a personal brand.

• Exhibiting at conferences
  
  From what I’ve heard, this is an extremely expensive way to do marketing (and sales, of course). I never bothered to spend the money, yet. However, most companies I’ve talked to are very happy with the results. So, it probably works (just like advertising). It is obviously also quite resource intensive.

  There’s no point in exhibiting at a conference without having at least 2-3 people at your booth to talk to potential customers. Imagine there are 20 people interested and you can serve only 2 because of a lack of staff.

  That’s another, obvious reason why I haven’t done it. Data Geekery is too small.

• Personal branding
  
  The product brand and the personal brand(s) of the product creator(s) are two different things. Whether the product brand leaves room for the personal brand is at the core of how you want to define yourself as a company. An enterprisey company often does not leave room for much personal branding (nor should it). An example is IBM. A company perceived as more innovative may optionally include some personal branding and maybe even cult around the founder(s). An example are Tesla and SpaceX with Elon Musk. Or they promote individual personal branding of their employees.

  For very small companies like Data Geekery, personal branding has an immediate business effect. After 5 years in business, I can relatively easily sell consultancy and SQL trainings (which you should totally book) through my personal brand only. People don’t really know Data Geekery, they know me. As a company grows, that separation may not be as good an idea anymore, as you may want to scale the consultancy and training business beyond individual employees, and you should be able to charge similar rates regardless who is executing the work. So, the success of consultancy businesses depends more on the company brand, than any personal brands.

  Still, in some cases, companies can profit from being able to show off an array of individual personal brands. Pivotal / Spring is a good example, where a lot of well known, brilliant people with public exposure, e.g. on Twitter, are working. Having several well known people work for your company increases the perceived authority of the company and its services as a whole. Microsoft seems to have been doing something similar recently, by hiring a lot of well known people (and thus getting access to their networks) from the open source ecosystem. This doesn’t mean that Microsoft is now an open source company. This primarily means that Microsoft wants to enter this market. In their case, I think the correct term is “embrace” the market.

  I’ve found building a personal brand quite rewarding and useful. My personal benefit is that I have a channel for my more “human” messages. In other words, I can occasionally rant about things I find important. That’s not really possible with a product or company brand.

• Building a network
  
  This may not be strictly marketing related, maybe part of wearing The CEO Hat, but it’s a side effect you’re getting from personal branding, among other things. Having a strong network is extremely important and will open many doors to your business. I’ll get back to this topic in The CEO Hat chapter.

How do I see myself wearing The Marketing Hat?

I love this activity. It’s so important to growing a business, and I find it very interesting, because ultimately, again, this is about humans: The customers. How do customers interact with my brands, my message, my product, my value proposition? And how can I influence them (in a good way, of course) to get even more value out of my offerings?

I’ve always found the topic of human behaviour and psychology very interesting. If you think so, too, I can highly recommend reading Daniel Kahneman’s Thinking Fast and Slow.

So, perhaps, let’s revise the previous, cynical summary:

Sales and marketing in a nutshell:

Sales: Individual customer, I hear you

Marketing: All customers, I hear you

The Sales Hat

The Sales Hat and The Marketing Hat are very similar. Marketing is useless without sales. Ultimately, after convincing a potential customer about my value proposition through marketing, I want to “convert” that potential customer to become … a customer.

How much sales effort you want to invest is, to some extent, a function of the minimum lifetime value of your product.

• Does a single customer generate tons of revenue? Get to know them better on a personal level and make sure they feel very good about their purchasing decision. After all, they’re buying a Ferrari.
• Does a single customer generate little revenue? Then you simply don’t have the funds to engage with every customer on a personal level. After all, they’re buying a Fiat Punto

There’s no judgement in the above price plans. Luxury products have their place. Commodities have their place.

Pricing is something you’re doing when wearing your Product Management Hat, because you’re judging a market size and product market fit in a certain way, and you’re strategically choosing price plans for that. And then, in function of the pricing, you will invest more in sales (high minimum lifetime value) or marketing (low minimum lifetime value).

An example is the question whether you want to cold call your potential customers. This takes a lot of time and perseverance, and is easy to do wrong. We all know the crappy salespeople from a well known live byte code replacement tool vendor (which I will not name here), who will constantly call you regardless of whether you said 50x already that you’re not interested, not even remember your name and/or affiliation within your company, not even remember whether you’re an existing customer (and thus don’t need to learn about the product).

Some may say “Their sales efforts worked for them”. Others may say “They were successful despite their sales efforts”. We might never know.

How do I see myself wearing The Sales Hat?

I’ll be honest: I do like wearing The Marketing Hat. I don’t like wearing The Sales Hat.

I have no problems at all answering sales related questions professionally. My wife has been in sales for a long time, and she had proof read my sales related emails many times. I’ve learned a lot from her in that regard. This is about inbound sales.

I simply do not have the patience and character for doing outbound sales professionally. I don’t even have a CRM, doing everything in Microsoft Outlook (fail on my side). I should be doing more sales work (and account management work), but it’s tons of effort.

It can be automated but if you’re doing something wrong in your automation, you’re going to spam everyone and leave a bad impression. Perhaps, this is an area where it’s better to do nothing than to do it wrong.

At some point in the future, I will definitely hire someone in this space. But not yet.

The Public Relations Hat

Like buying flowers for your loved ones, PR is something companies usually do when they screw up.

On a more serious note, PR to some extent overlaps with The Marketing Hat. Its goal is to give a brand a personal face (but not necessarily a personal brand), i.e. a human point of contact. This isn’t just a customer support email address, but a point of contact for a variety of questions, and also an outbound “broadcast” communication channel for announcements of various types (see e.g. this nontechnical blog).

It is somewhat different from The Marketing Hat in that PR deals with principles, strategies, and the public perception thereof, and it doesn’t have any immediate effect on conversions of individual products.

The larger a company gets, the more important this becomes. In times of social media, anyone can easily make any type of accusations that can go viral (often without fear of repercussions), and a company will need to take care of this professionally, to reduce the damage a brand will take from such an event.

How do I see myself wearing The Public Relations Hat?

For a small company like Data Geekery, PR is not really very distinguishable from marketing, so I do not have a personal opinion, nor any strategies on this activity from my side. I’ll just wait for an event requiring PR intervention to happen and will act then.

The Customer Support Hat

This necessary evil seems to be one of the hardest to implement. Write this down and take it very seriously:

Never RTFM your users.

Never send your users standardised replies.

Always take your users seriously.

Yes, I know. You’ve written that impeccable manual. It’s written right there how it works. How anything works. Why do they have the nerve to ask you the millionth time about this silly non-essential feature?

But thinking this way is wrong. For several reasons. If someone asks you a million times about the same thing, a few things could be concluded:

• Your manual sucks. Plain and simple. You didn’t explain the feature very well, or the explanation is hidden in the depths of your manual where the sun don’t shine. Having people ask about the same thing all the time is a perfect indication of a thing you have to improve. And because they’re asking so often, you can easily A/B test your improvements. Try something. Did the questions go away? Try something else. In jOOQ, one such example is the notorious problem of explaining the assumptions made about code sections in the manual. The generated code and the DSL API are expected to be static imported. But this isn’t documented on every page, in order to prevent the noise this would create. So, how to make new users aware of this assumption that long time users will take for granted? I still don’t know. But I do know I’m explaining it wrong.
• The feature sucks. Also plain and simple. Perhaps, the best way to help your customers and avoid the questions is to remove the feature they’re asking questions about. In jOOQ, one such feature is the DAO feature, which I greatly regret. It was so easy to add and so difficult to support. I didn’t do proper product management and added the thing early.
• You have grown. Last but not least, and this is really good news, you might have grown. And it’s simply natural to ask a particular question about a feature. You can add more Q&A on Stack Overflow, such that people whose Google-fu is not too “entry level” will find it. But there will always be those who want to ask a human being about the most trivial, googleable things. Get ready to increase our customer support infrastructure.

Remember: Someone has gone through the trouble of contacting us. They don’t have to. They could have just cursed you and moved on. But they did contact you. Because they want you to succeed. They want you to be a better vendor for them. Take that seriously. They’re the voice of hundreds of others, statistically.

A very good example of this done right is the following tweet by Steven Feuerstein:

As an #RDBMS believer, it is easy for me to snicker at this image, but I then also remind myself: @MongoDB did explode in popularity. #NoSQL did sweep the developer community. The most important thing for us is not to mock, but to understand why and how #SQL failed them. https://t.co/PQEW2yIlWw

— Steven Feuerstein (@sfonplsql) October 17, 2018

Now, as all human beings, customers rightfully expect to be taken seriously and get a timely answer. It’s no secret that if you execute well on this simple task, you will have an even happier customer. Because for most customers, the human interaction is a big part of the game.

And, as a side note, I do take special pleasure when competitors get this wrong. This is really one of the primary areas where jOOQ excels, mostly – I will always do my best to answer every question anyone may have about jOOQ on the internet, regardless if they’re licensed or using the open source edition. The only restriction I impose: 1:1 email support is for licensed customers only. Community support is public. Otherwise, this wouldn’t scale.

It can be delegated easily, but not everyone will put the same dedication into customer support – so a customer support engineer definitely needs to be picked wisely. We all know how we feel when we call that telecom company about some connectivity problems of our home Internet, and they’re just treating us like idiots. This is so unsettling, we might even switch the provider.

How do I see myself wearing The Customer Support Hat?

I like it, but I don’t love it.

I like it because it’s one more way of getting in touch with customers and helping them, as I’ve discussed several times before.

I don’t love it because it’s extremely time consuming and keeping me from doing things I would like to spend more time on, including wearing The Developer Hat or The Marketing Hat.

It’s important, but it’s very repetitive. I should finally outsource it.

The Legal Hat

Like software engineers, lawyers solve problems that we wouldn’t have without lawyers.

After 5 years of doing business, I have grown to have a certain weird admiration for this craft. For example:

• For some weird reason, lawyers only use Microsoft Word documents with no formatting and Arial font. (Could be worse)
• Also, they use Microsoft Word’s obnoxious redlining feature instead of some much more reasonable version control.
• THEY LIKE YELLING AND NO ONE KNOWS WHY NOT EVEN THEM
• They like synonyms, analogues, equivalents, including, but not limited to, identical expressions
• Also, they never really refactor their documents. Just like database indexes, which are only ever created, hardly ever dropped, lawyers seem to not remove any legal clauses.
• Some of them are super sloppy and copy paste all the time. After 5 years of experience of reading through useless NDAs, I’ve found more unexplainable legacy than in any arbitrary 30 year old banking system. Like a lot of legacy software engineers (chickens) they don’t dare touch the legacy because no one knows what would happen next.

There are essentially two things about the topic of legal stuff:

• Get a good legal counsel early on. And I do mean a good one. I’ve found one who specialises in IT contracts with quite some experience with open source. He drafted jOOQ’s license, maintenance, and support agreement as well as the transfer of rights agreement (similar to a CLA) and explained it very well to me. He specifically created the document in a way that makes it easy for me to change pricing, discount schemes, and other things that are “legal implementation details”, not really “legal design considerations”, if you will
• Avoid legal stuff as good as you can. In Switzerland, we have the code of obligations, and a few other codes, that cover all the many things two parties in a contract may want to cover by default. It contains a lot of very reasonable defaults, so you don’t have to write and read agreements all the time. For example, when I do short term consultancy, I usually do not sign a contract, nor have my suppliers (e.g. my accountant, or again my legal counsel) signed a contract with me. There’s still a “contract”. We agreed on hourly rates, project plans, expected deliveries by email. The rest is covered by the code of obligations. Obviously, this works well only when the project is short and thus the amount of money owed is relatively low. No one goes to court because of EUR 500 due for unsatisfactory work. You just pay, write it off, and never work with them again. This is good if you want to avoid litigation, because most agreements are exactly the same and your particular situation is not special.

  In other countries, things may be completely different. To my very limited legal understanding (obligatory IANAL!), in the UK, if you don’t agree on something explicitly, you will have to agree on that thing in hindsight in case of litigation. This is also not a bad thing if you want to avoid litigations, because it forces you to find a constructive solution.

  In the US, there will always be some precedent involving the trade of cattle, specifically when transported over rail per 1839 in some weird jurisdiction that you’ve never heard of, that can be applied to your case. If you have the better (i.e. more expensive) lawyer, you will find those precedents and sue millions off the other party. The US is definitely a legal minefield. I always try to avoid signing things under US law and try to move the jurisdiction to neutral ground, e.g. the UK.

  But again, the best thing is not to sign anything at all, especially NDAs. I’m selling a very general purpose SQL library for Java developers. All the questions a potential customer may have are completely standard SQL related questions. There is absolutely no need for me to understand their business, their trade secrets, their database schema, to help them make a purchasing decision. So, I will simply not sign an NDA.

  If they insist on signing an NDA, well, I have a trick for that as well. I will read their NDA very thoroughly. As I said, most legal documents are crappy, copy pasted pieces of legacy. I will find dozens of inconsistencies, ill-defined terms, void clauses, and outrageous demands such as 24/7, 1h reaction time SLAs (which can only be supported through a significant price increase). I put on my most legalese English, and demand rectification, clarification, amendments, including but not limited to removal of clauses that I deem “very unusual if not surprising“. The important thing is to be thorough here. My demands are justified, and frankly, sometimes a bit embarassing for them, after all, they’re the ones that want to look all tough and professional by using copy pasted legal language. So, they’re left with three options: 1) Execute my amendments, in case of which I will find more flaws and/or increase my prices. 2) Drop the NDA and just go ahead with the call. 3) Drop the purchase of jOOQ.

  The last option hasn’t happened yet. My pricing is too low for this step to be a viable option. Ultimately, they’ll just “meh out” and go with option 2)

  Make no mistake. This may sound petty. And it doesn’t seem customer friendly (see The Sales Hat or The Support Hat). But getting sued in the US for some random useless NDA is a risk I simply do not want to run. I’m privileged to have enough revenue to risk losing 1-2 clients who are excessively legalese.

How do I see myself wearing The Legal Hat?

I’ve grown to like it. I have friends who are lawyers and love contracts. They’ve taught me tons of legal things. Especially the fact that nothing is really ever well defined. A lot of jurisdictions will find a lot of contract clauses void, because inconsistent. Ultimately, most companies should always avoid litigations and try to find a constructive solution.

Usually, a vendor can pay back money (e.g. the jOOQ license guarantees money back under certain conditions) and the thing is done.

Many young enterpreneurs are afraid of this, and worry only about patents, copyright and other things. Don’t be worried. Start adding value to your business, don’t protect too much.

Depending on the specific industry you’re in, there may be important exceptions to this. Especially when you do things that will get you in trouble with penal law.

Also, once you have many employees, the prospect of getting sued (and possibly going bankrupt) is more frightening. If you’re alone, who cares.

The Account Management Hat

The Account Management Hat is not too different from the The Sales Hat and The Customer Support Hat. You’re doing account management with existing customers, trying to find out if everything is OK with their subscription, their usage of your product, their payment, etc. It also includes all sorts of administrative questions those customers may have.

The goal of account management is not to get out of touch with your existing customers. There may be problems the customers have had no time to report. Or they’re too frustrated to spend the time. Or, they think you cannot help them anyway. But if you reach out to them, things might change. You might be able to solve their problem after all, and have one more happy customer.

How do I see myself wearing The Account Management Hat?

Account management is important, but I have never gotten around (another excuse) to doing it professionally. I obviously reply to all inbound emails, and I do ask key accounts (high volume licenses) about how things are going from time to time. But there’s a lot of stuff that can be done for smaller accounts as well, perhaps with some automated emails.

The Accounting Hat

Like The Legal Hat, this is something you definitely want to outsource. Not just because it’s boring, but also because it is difficult to get right. And depending on your jurisdiction and on your style of incorporation (e.g. LLC), doing this wrong might equate tax evasion – because the state expects you to do it right and apply due diligence here. After all, there are enough licensed accountants available on the market, so with significant revenue, there’s no reason to do things yourself, amateurishly.

Getting an accountant is even more important when you do international business, which is a challenge even for most accountants.

How do I see myself wearing The Accounting Hat?

I don’t. Although, as the business has been growing financially, I do like to look at the results of the accountant’s reports.

The Human Resources Hat

I’m just starting to learn about this topic, as I’ve been hiring. (Stay tuned for the results of this hiring process, which has been an extremely positive experience for me!)

Having been a solo entrepreneur for 5 years, this will really completely change my business in many ways, including quite a few of the aforementioned hats.

Of course, I will not roll out a full fledged HR (Human Resources) “organisation” including processes etc. At some previous employers, I’ve found them exaggerated anyway, but YMMV. But some HR considerations are important for a small company just the same.

Most importantly:

This is about people. Much more than all the customer facing tasks. People have people challenges. They:

• Need to feed families
• Want to find purpose in their professional lives
• Want to be challenged
• Want to belong
• Want to be rewarded (financially and otherwise)
• Have their own career goals
• Have their personal constraints and limits of whatever nature
• Have good and bad days

Nothing surprising, really. But it’s an entirely new dimension to a business. It will take some time to handle on top of the existing tasks, in exchange for being able to delegate some of the tasks, or increase the output of some of the tasks. And the first employee will probably be an easier hire than the second one. Because the first will only have to interact with me (and I can predict that to some extent), but the second and the first will have to interact among themselves, and how does that influence the above list?

I’ve met entrepreneurs who didn’t care about this. Sure, you can be successful as an entrepreneur this way. Profits are possible still. But I definitely do not want to be that entrepreneur. I want to create a culture where I, myself, would love to work as an employee.

I was thinking about whether I want to call this chapter HR (Human Resources), because I find the term very wrong – precisely because it shouldn’t be about “resources”. It should be about “humans”. But then again, I recently played this lovely game called “Human Resource Machine” and its sequel “7 Billion Humans“, and I wanted to share these games with you.

Anyway, I like the way Basecamp handles this topic in their book Remote. Like many other companies, and like Data Geekery, they try to be a very employee friendly company. Something I much admire.

How do I see myself wearing The Human Resources Hat?

I have a lot of respect for this role, as this is something very new for me. I’m definitely getting out of the comfort zone here, but I’m very positive that I will be doing the right thing, and make the right choices.

For everything administrative in this area, like social security, I have my accountant. This is again definitely something that should be outsourced.

The Administrative Hat

Administrative work is inevitable and boring. What I’m doing:

• Book flights
• Book hotels
• Read letters, e.g. from insurance companies
• Pay invoices
• Purchase licenses
• Answer phone calls
• Answer emails
• Schedule meetings
• Empty the dishwasher in the coworking space
• Do errands, like take a letter to the post office
• Send out merchandise

As I said. Boring. This can obviously be outsourced, but the difficulty as a small company is the fact that the administrative workload is not that big. So, hiring someone as an ordinary employee is overkill. I would need a freelance assistant. So far, I haven’t found any yet (haven’t searched too hard).

A fellow entrepreneur found a combination of assistant and accountant, which is a jackpot as there are a lot of synergies between the two types tasks. My own accountant could lend me their assistants, but their rates are too high for this kind of work.

How do I see myself wearing The Administrative Hat?

I hate it, but haven’t found a good way to outsource it yet. It’s not a big enough pain to prioritise, too, so I guess I’ll just live with it for another while.

The CEO Hat

Last but not least: The CEO Hat, the least important one.

Because with all the other hats, there’s little work left to do. The CEO Hat is the hat I’m wearing when I represent the company. I often use the “royal we”, when I talk about Data Geekery, despite there currently being only me. It’s fun until you drink beers with people and hear yourself saying “we do this and that” all the time. At which point I hear myself and think I’m a lunatic.

Representation is important, of course. And so is the network. Having a personal brand does help when wearing The CEO Hat, because the CEO is the head and face of the company in all sorts of official regards – especially in small companies.

The CEO also defines company vision, strategy, etc., i.e. stuff that is part of The Public Relations Hat‘s activities. This may again sound weird in a 1 person company, but I find it helpful nonetheless to constantly define and refine who I (or “we”) want to be as a company.

After all, running a company, as this article has shown, includes such a wide array of distinct activities and roles. And regardless of the size of the company, the more I am aware of the individual roles and hats, the better I can execute on those specific roles, or delegate them to someone else.

Conclusion

Wearing all those hats in personal union has a decisive advantage. I never have to communicate anything to anyone. So, there is never any misunderstanding about my intents, regardless of the hat I’m wearing.

It also has a decisive disadvantage. Without any communication ever happening, no decision is ever really challenged (except perhaps by customers). Some ideas that may have been identified as completely silly (e.g. in marketing) could have been exposed and prevented. Other things have been overlooked, when an employee or partner would have noticed.

As I’ve mentioned numerous times, I’m hiring someone to wear some of the hats. The main hat they’ll be wearing is The Developer Hat, but as this is still going to be a very small company of 2 people, they will inevitably also wear these hats, too:

• The Developer Hat (the main one)
• The QA Hat
• The Operations Hat
• The User Experience Hat
• The Requirements Engineering Hat
• The Marketing Hat (optionally they may be blogging)
• The Customer Support Hat
• The Administrative Hat (it’s a remote job with its implications)

I do trust that they’re going to be wearing some hats better than me, or differently, such that we can both take inspiration from this collaboration.

In any case, getting to know and then wearing all of these hats has been some of the most interesting and rewarding activities in my entire career. And as the company grows, I’m looking forward very much to learn more about the nuances (or delegating possibilities) of each one of these hats.

Soon on this Blog

Following up, stay tuned for related blog posts:

• Staying true to your roadmap in the presence of custom requirements
  When creating products, the worst thing you can do is integrate every single custom requirement. It will make maintaining your product almost impossible, just for the quick win of easy money. But how can you still keep the requirement in mind and solve the customer’s problems with something better?
• Alone or not? The first employee is the most difficult hire
  In 2018, I will hire my first employee — after 5 years. So far, I fared very well alone. What are the pros and cons of staying alone?
• How to create a valuable tech blog
  A lot of people blog, and they write cool stuff, which solve exactly the weird, edge case problem someone has 2–3 years later. But is that worth it? It depends. Deep niche content can be valuable, just as general purpose advice. Ultimately, a blog should help drive your business, so what to blog about?