10 Years of Solo Consulting
On June 1st, 2013, I started out as a solo consultant (a freelancer in legal terms). I was just 19 days shy of my 45th birthday. Family, friends and colleagues declared me crazy to quit a well-paying permanent job in my mid-forties and to strike out on my own. According to them, I was doomed.
It turns out, I wasn’t. Going solo was the best decision of my life - second only to marrying my wife 28 years ago. From my income, we were able to pay off the mortgage of our flat - 12 years earlier than planned. We have set aside a sizeable nest egg for retirement. Most importantly, my work-life balance is better than ever before. We go hiking in the nearby mountains nearly once a week. Long walks along the Inn river every other day during lunch breaks and a supportive circle of friends help as well.
This is the happy state after 10 years with quite a few rough patches. In 2016, I couldn’t find a project for six months - no matter what I tried. I applied for some permanent jobs and went through the interviewing process. I turned down all the jobs in the end. And suddenly, three freelance opportunities came in within a week. My solo career went on.
Even after 10 years, I feel queasy whether I’ll find the next project. I think that I will never get rid of this feeling entirely. That’s good, because this uneasiness keeps me alert and lets me attract customers proactively. Rainy-day savings of 6-12 months help minimise the feeling.
I was close to a burnout once in my solo career. I worked 70-80 hours per week for eight months. My wife fortunately noticed the burnout symptoms early and practically forbid me to extend the contract. She was right: It is not worth to sacrifice my mental or physical health for work. Working too much doesn’t lead to a sustainable business.
I run my business very similar to how I develop software: in a ruthlessly incremental way. I try out something, say, a productised service. Then, I regularly check what works and what not. Based on my findings, I adapt the service. I might add or remove features, add a new distribution channel (e.g., a self-pace video course in addition to an in-person course), or change the pricing. The important thing is to restrict the risk. If the new service fails, I can still continue my business.
In the rest of this newsletter, I’ll share some of my experiences from 10 years of solo consulting: what worked for me and what not. These experiences are the result of many small decisions, which are always tradeoffs shaped by the special context at the time. Your context differs. Therefore, your decisions and experiences will differ. Please experiment yourself and find your own special way.
Positioning
My initial positioning statement was: I help customers build Qt embedded systems. My focus was on building user interfaces with Qt on embedded devices like infotainment systems in cars, driver terminals in agricultural and construction machines, and display computer of e-bikes. I excluded Qt applications for desktop and mobile on purpose, because there was and is too much competition in these areas. It was clear that I couldn’t compete on price.
I could back up my positioning with my experience. In 2013, I already had 7 years of embedded development and 14 years of Qt development under my belt. My job at Nokia (2009-2012) was to convince manufacturing companies to use Qt in cars, home appliances, TVs and STBs. I worked out a Qt-based system architecture with the senior technical people in these companies. These conversations taught me what companies needed.
In 2018, I got more and more dissatisfied about the compensation for my work. I enabled my customers to build the operator terminals of their machines on their own. These companies had control over their fate for the first time in their life. And, I got a meagre hourly rate of 90 Euros. Something was wrong. I felt slightly powerless in the sales conversations, which were mostly about the hourly rate. Two years later, I came across the Win Without Pitching Manifesto by Blair Enns.
Expertise is the only valid basis for differentiating ourselves from the competition. Not personality. Not process. Not price. It is expertise and expertise alone that will set us apart in a meaningful way and allow us to deal with our clients and prospects from a position of power. […]
It is first through positioning our firm that we begin to shift the power in the buy-sell relationship and change the way our services are bought and sold. […]
Positioning is an exercise in relativity. Our goal when endeavouring to position ourselves against our competition is to reduce or outright eliminate them.
Blair Enns, The Win Without Pitching Manifesto, p. 7-8
Without doubt, I had the expertise, but prospective customers didn’t know about it. The first step was to improve my positioning. Further steps will be to write and talk about my expertise. After going through the Positioning Workshop of the Win Without Pitching company, I changed my positioning to:
I specialise in smart user interfaces for industrial machinery.
As many prospects don’t know what Qt is and rightfully don’t care, I replaced it by the more telling “smart user interfaces”. This widened the focus area. I compensated by narrowing “embedded systems” down to “industrial machinery”.
My mission complements the positioning statement and explains how my customers benefit from smart user interfaces. In short, the mission reads.
I free smart machines from dumb user interfaces, one machine at a time.
I am not 100% satisfied with the positioning statement. “Smart user interface” sounds a bit vague, as “smart” needs an explanation. It also tries too hard to jump on the “smart” bandwagon: smart speakers, smart machines, smart TVs, smart everything. “Industrial machines” feels a bit too narrow. A CT scanner or an X-ray apparatus is not so different from an industrial machine, neither is a car from a harvester.
Some weeks ago, I came across the article Get Ready for UX-Defined Vehicles or Not by Junko Yoshida. She argued that “software-defined vehicles” (the latest trend in the car industry) should be replaced by “UX-defined vehicles”. The drivers of a car don’t care about the software but about the user experience. That’s pretty much Guideline 1 of my mission: Focus on What Customers Want to Buy. A better positioning statement could be:
I specialise in machines defined by their user experience.
Or shorter: I specialise in UX-defined machines.
Customer Value
Customers don’t care whether the HMI is implemented with Qt, QML and C++, Flutter and Dart, or Slint and Rust - at least not primarily. They only care about technology, if it makes achieving their objectives harder or easier. Here are some objectives I encountered in the past:
A harvester must not stand still during the short harvest season. If it does, manufacturers want to be able to fix the issues in the software of the ECUs (including the driver terminals) themselves - remotely, of course. They don’t want to depend on a supplier. They want to have their fate in their own hands.
A manufacturer of professional cooking appliances wants to reduce the development cycle for new appliance generations from 4 years to 1 year and less - without reimplementing most of their existing software. The team structure, software architecture and development process are the main obstacles.
A manufacturer cannot find enough developers, lacks an experienced developer to guide a team, or needs a temporary replacement for someone on maternity leave or someone who left the company.
It’s notoriously difficult to find out what the most important and urgent business needs are and where I can create the most value for a customer. In his book Pricing Creativity, Blair Enns provides a simple and powerful tool to elicit the business needs: Ask prospects the three-year question to uncover their desired future state.
“It’s three years from today and you and I are having coffee. You are really happy with the progress you’ve made over these past three years. What’s happened to make you so happy.
Blair Enns, Pricing Creativity, p. 72
The three-year question is also known as The Dan Sullivan Question. Dan Sullivan is the inventor of this question. Enns’s formulation of the question is easier to remember than Sullivan’s. The time horizon of three years steers the conversation towards strategical objectives - away from short-term tactical considerations. In a diagnostic, the prospect and I work out a phased plan how and when to reach the objectives.
As many people struggle with this question, I nudge them forward with Sullivan’s DOS questions: Dangers, Opportunities and Strengths.
Specifically,
what dangers do you have now that need to be eliminated,
what opportunities need to be captured, and
what strengths need to be maximised?
Dan Sullivan, The Dan Sullivan Question, p.47
Top managers should be able to answer these questions without much ado. After all, strategy is their lifeblood. At least, it should be. Ideally, they come up with two or three serious dangers and opportunities each and want to change the status quo. Then, getting high-value work as an advisor or coach is quite likely.
The backing of top management is crucial for achieving change: e.g., for introducing Continuous Delivery with all its principles and practices to a software development team or for converting a big ball of mud into a maintainable and extendable architecture. The backing is especially important to overcome the resistance of middle management.
Middle managers struggle most with the questions. One manager even called my questions “mean”. His answers made it pretty clear that he was only looking for a cheap developer. His answers showed absolutely no urgency, although his team had already spent more than 4 years on the reimplementation of an operator terminal - a task that normally takes at most half the time. My request to talk to the director approving the project was ignored.
The three-year question raised enough red flags to decline the opportunity quickly. Earlier in my solo career, I might have accepted the work for a half-decent hourly rate out of fear of not finding other work any time soon. I would have soon fought against the shackles of a micro-manager and regretted my decision heavily.
These days, I have the luxury to decline such opportunities, as I have a good financial buffer and as more rewarding work is typically just around the corner. If you don’t have this luxury yet, restrict the project to 1-3 months. Then, you can easily jump ship for a more interesting project with nicer people.
I do not only use the three-year question in sales conversations but also in paid diagnostics. I pose the questions to the developers, the middle managers and the executives to get a realistic assessment of the problems in the organisation. The questions unearth, for example, blocking or slowing dependencies between teams and discrepancies in required and actual product development cycles. Points, where developers, middle managers and executives disagree, require further analysis.
The answers enable me to identify the pain points in an organisation or company and to come up with a plan how to alleviate the pain. They give me leverage for a proposal and the ensuing negotiations.
To Be Continued
The answers to the three-year question tell me how much value I can create for the customer. The value defines the price and the type of the engagement: consulting, coaching or implementing (ordered from high to low value/price). In the beginning, I accepted payment terms like 30 days after the end of each month. Since 4 years, my customers pay me in advance.
I deliberately decided in favour of working solo and against having employees. So far, I am not incorporated. I work as a self-employed person. However, I am considering to create a Limited company for tax reasons.
I’ll cover these topics in the next newsletter(s). I’ll end with a topic that I value more with every passing year: work-life balance. Hiking in the mountains once a week is a great way to relieve stress.
Great insights indeed! Thanks for sharing.
I discovered your blog because you mentioned "Slint" (thanks to Google search!). Slint is a project that I intend to specialize in as a freelancer. I have more than ten years of fullstack web/mobile development, and learnt Rust more than a year ago, and wanted to shift my career towards something I always wanted to do but never had the opportunity to do it: developping great cross platform apps with Rust.
You blog is full of great content, I'll read as much as I can for sure. It also made me rethink my interest in embedded software.
Thanks for sharing your experiences and tips!