10 Years of Solo Consulting (Part 2)

Episode 43: Better Built By Burkhard

I had this newsletter ready for release on the first Monday of the month (3 July). During the weekend before, a wonderful outing with friends near Nuremberg, I somehow convinced me that 10 July is the first Monday of the month. Probably some cross-wiring of some brain cells due too much heat ☀️I hope that my thoughts about 10 years of solo consulting (part 2) are less confused 😉

10 Years of Solo Consulting (Part 2)

This is the second episode celebrating my 10th anniversary as a solo consultant. In the first episode, I wrote about positioning and customer value as the foundation for a successful business. This episode is about pricing and payment terms.

Pricing

Strategy versus Execution

[…] think of strategy and execution as being housed inside two rooms of the same building, with separate entrances and a connecting door. […] the first room […] could be called expertise, strategy, thinking, analysis, etc. The second room […] could be called implementation, execution, expression, doing, etc.

David C. Baker, The Business of Expertise, p. 165

In the fourth year of my solo career, I assessed for one of the world’s top-5 home appliance makers, whether they should use Qt or a web-based UI framework for their appliances (see my post Qt or HTML5? A Million Dollar Question). My recommendation for Qt would save them more than a million dollar per year. I charged them 7,560 Euros for 72 hours of work.

I was happy when I closed the deal, because it was one of my first deals with a 3-digit hourly rate. When I saw the cost savings at the end, I felt a bit stupid for giving valuable strategic advice for such a low fee. Based on the possible cost savings, I could have priced the customer on the value I’d create for them. Even back then, I might have got 2-3 times of the actual fee.

I understood that I could charge significantly more for strategic advice than for implementation work and that hourly rates are appropriate for implementation work but not for strategic advice. Coaching is priced between strategic advice and implementation work.

I try to start engagements with new customers with an assessment of the customer’s situation and needs: a diagnostic. I analyse the team structure, system architecture and the development process, provide a prioritised list of problems and recommendations how to solve them. We define a desired future state guided by the three-year question and my findings. We may also sketch a migration path from the current to the future state.

The diagnostic is all about strategy and not at all about implementation. It is also the basis on which the customer decides how to proceed.

• Parting ways. The customer does the implementation on its own or hires someone else to do it. I help customers to find external developers. However, I prefer that the customer builds up an in-house team - with a little help from a coach. Then, the customer has its fate in its own hands.

• Coaching. The customer hires me to coach its development team, which does the implementation. The team picks my brain, but doesn’t get my hands for implementation tasks. Pair programming is a good way for coaching - with me in the teacher role.

• Implementation. The customer hires me to get my hands dirty with implementation tasks, too, as part of the development team. Time pressure leads to prioritising implementation over coaching. As a coach, I guide the team. As a developer, a project manager controls me. The customer expects to pay less for implementation, although they still expect me to coach their team. This arrangement is ripe with conflicts.

Selling implementation work and coaching on hourly rates is a lot easier than selling diagnostics at a fixed price - for several reasons. Many customers trust more in their self-diagnosis than in the diagnosis by an external expert. One of my customers turned me down six or seven years ago, because I was too expensive and they were sure that they could easily develop the software by themselves. Five years later, our paths crossed again. They had spent millions of euros to build a big ball of mud. They hired me for a lot more money to pull them out of this mess.

Some companies have a development team idling around. A diagnostic would make them pay most of the team for doing nothing. So, they want to start implementing immediately. Other companies are agile extremists and despise any up-front non-implementation work. It’s just a matter of time when these companies run into trouble.

The ignorance of prospects is only one side of the problem. My ignorance is the other side, as Baker points out.

[…] craft your positioning entirely on your strategy and not your execution. Barely mention the latter, don’t feature it on your web site, and don’t give it any prominence in your presentations. […] The fact that you do implementation is simply a convenience to your clients, primarily, and not so much your prospects.

David C. Baker, The Business of Expertise, p. 172

Guilty as charged! The majority of my blog posts is about implementation. I certainly have some work to do: I must write and talk more about system architecture, team topologies and continuous delivery practices and create productised services for these topics.

Enabling, Platform, Complex-Subsystem and Stream-Aligned Teams

Matthew Skelton and Manuel Pais introduce four fundamental team topologies in their book Team Topologies.

• Stream-aligned teams (a.k.a. feature teams) get valuable features in the hands of customers at a steady place.

• Enabling teams help stream-aligned teams improve their capabilities and become more autonomous. They make themselves superfluous within a few weeks or months. For example, an enabling team could introduce Continuous Delivery or start getting legacy code under test.

• Platform teams build services, libraries or customised Linux systems and provide these platforms as a service to the stream-aligned teams. For example, a platform team could build a library for the J1939 communication between the HMI and a construction machine.

• Complicated-subsystem teams solve problems for which special expertise is needed - like image recognition for medical images.

Depending on the topology, I can charge lower or higher hourly, fixed or value fees. As part of a stream-aligned team, I do implementation work. I charge by the hour, because the requirements are not known in advance and change often. Most of my income has come from working in stream-aligned teams. Implementation work makes it hard to differentiate from other developers. Measuring productivity is still an unsolved problem.

When I work as an enabler, differentiation becomes easier. I make a stream-aligned team better step by step by teaching them skills they don’t have or by preventing them from going down wrong paths. Coaching a development team is also an enabling activity.

If I can come up with a measurable success criterion for an enabling activity, value prices are a good option. For example, I could offer a customer three options how to get their legacy code under test:

• Option 1: I give three workshops, where I show up to six developers how to get a class under test. The workshops are billed at a fixed price, which is the same for all customers.

• Option 2: The customer and I define a part of the source code to get under test. I work with a customer team to reach 5% path coverage for this part. Based on a diagnostic and my experience with similar projects, I charge a fixed price, which depends on how much value I can create for the customer.

• Option 3: If the team reaches 35%, 50% or 65% path coverage within the next three months, I get a bonus about 50%, 75% or 100% of the price of Option 2. I am available up to 2 days for support during this time. Instead of the coverage goals, I could also set bug reduction goals.

The number of workshops, the selected part of the source code, the coverage goals, the duration and the prices depend on my assessment in a diagnostic. Without a proper diagnostic, I would not offer value prices for Options 2 and 3 but charge a high hourly rate. My offer would also state how many developers are required for Options 2 and 3, that they must be available full time and that I have a veto in selecting them. In return for taking on more risk, I get more control.

By now, it should be clear that I resort to high hourly rates if I cannot measure success or if the prospects reject a diagnostic. I may even choose not to work with such a prospect. This depends on my financial situation, on the number of alternative prospects, on how interesting the project is and on how nice the involved people are.

Providing platforms to customers is ideally suited for fixed prices. My standard example is a library for the J1939 communication on agricultural and construction machines. I implemented J1939 communication over the last 10 years for three different customers.

The first two times, I didn’t know better than to bill by the hour. The third time, I wasn’t able to convince the customer to pay a fixed price for non-exclusive usage rights. They hired a freelancer working for a third of my hourly rate. In the end, I had to iron out a lot of bugs and re-implement substantial parts. And, the customer paid roughly five times of what I would have charged for a ready-made library.

I can only speculate why this and other customers are so reluctant to pay a fixed price for a platform. It’s probably a combination of several reasons. Billing hourly is what companies are used to. They want exclusivity, because they see a competitive advantage. Then, I should try to extract the platform work at least into a separate project and charge a higher hourly rate than for my normal project work. Customers underestimate the costs for a product-worthy implementation. Then, it’s my job to educate customers better. Whether they listen is another story.

I probably have to develop a first version of the platform on my own time and money. The first version must provide good value for customers with a predictable risk for me. It certainly shouldn’t get me into financial troubles. There should be a good chance to make a profit. For risk mitigation, I would introduce the platform as a productised service and reduce the service percentage over time, until it becomes a product.

Providing a complicated or complex subsystem is like providing a platform but on steroids. The sky is the limit for the price. The obvious example at the moment is to use AI for tasks like detecting cancer cells, determining the ripeness of maize, finding counterfeit perfumes or avoiding downtime of machines. This requires highly specialised knowledge in training deep neural networks (DNNs) and in running DNNs on resource-constrained embedded systems.

Building a complicated subsystem is much riskier than building a platform. I would have to find a way how to reduce the risk. Back to the AI example, I would start with a small example, extend it incrementally and blog furiously about it. As I specialise in building smart user interfaces for machines and building AI into user interfaces is guideline #3 in my mission, I am looking into ways to ramp up my expertise.

Mixing different types of work is rarely a good idea. If I mix, say, coaching and implementation, I can be sure of three things. First, I get a lower hourly rate than for coaching-only work: closer to the rate for implementation. Second, I end up doing mostly implementation work. Third, the development team and its managers tend to ignore my recommendations more often, as I am part of the team instead of an outside expert. I have learned this lesson by trial and error.

My plan is to assess my ideas for offerings based on enabling, platform and complicated-subsystem work and decide which offerings to pursue. I want to make my business fit for the next ten years and get less dependent on implementation work.

Productised Services

Your pricing (including hourly rate, scoping decisions, and value based pricing, if you use it) is far less important in making oodles of money than your efficiency in stacking engagement after engagement, and without customizing each one. […]

If you want a more efficient [and less exhausting] method [than value-based pricing], package a service or two from your menu and charge more. And do it consistently. I should clarify that there is no innate reason that the package price needs to correlate with the hours it requires to complete that work. Not at all! The price is what it is - the only difference is that it’s high - and it doesn’t vary much from engagement to engagement, if at all.

David C. Baker, Secret Tradecraft of Elite Advisors, p. 96 & 98 (Kindle edition)

Baker advocates for productised services, which are 80-90% product and 10-20% service. The product part hardly changes over time and can be reused from engagement to engagement. The service part is specific to each customer. A productised service should cost me very little time and provide high value to the customer. Then, I can charge a high price, which is the same for each customer.

So far, I have introduced one productised service: a license compliance check for embedded Linux systems. What made me create this productised service?

When I worked as a business developer for Nokia Qt from 2009-2012, Nokia had just published Qt under LGPLv2.1. So, I had to explain LGPLv2.1 to Qt customers. After I started my own business, every customer asked me whether they had to buy a commercial Qt license or whether they could get away with Qt LGPLv2.1 and soon LGPLv3.

After I did a full license compliance check for a customer on an hourly-rate basis, one of their suppliers asked me whether I could do the same for them. That was the moment, when I decided to turn the license compliance check into intellectual property (IP) and charge a fixed price for it. I didn’t know back then that I had created a productised service.

All my potential customers must check license compliance for their embedded Linux systems and they must decide whether to buy Qt or not. However, they don’t have the knowledge. On top of that, there are very few people out there with the right expertise. It’s an excellent niche for me. In short, I recognised a pattern in what my customers needed and satisfied their needs with a productised service.

Over the years, I have identified a few candidates for productised services:

• Building an embedded Linux system with Yocto including features like window manager, software update, fast boot, secure boot and 4G/5G Internet.

• CAN communication with J1939, CANOpen or proprietary protocols for agricultural, construction and industrial machines.

• Getting legacy code under test.

• Setting up a CI/CD pipeline.

• Introducing continuous delivery practices to a development team.

• And many more.

As I mentioned earlier, I need some time to assess which candidate I will introduce as the next productised service.

Payment Terms

In the first years of my solo adventure, I accepted bad payment terms out of fear of losing the business and because of not knowing better. At the end of the month, I sent the invoice about the hours worked to the customer who had another 30 days to pay the invoice. So, I saw the money two months after I had done the work.

Some customers discussed the timesheets with me trying to reduce the paid hours. Some customers were intentionally late in paying their bills. They waited until I sent a reminder. One customer only paid after I threatened to stop working - 5 weeks, 3 reminders and 1 threat of legal consequences late.

And it was not only the payment terms that customers forced onto me. It was dozens of pages of legalese with warranty, liability and damage clauses that would ruin me for life. I signed these contracts and hoped for the best.

5 years ago, I was finally fed up of this waste of my time and money. In contrast to the purchasers and accountants of this world, I don’t get paid for negotiating the contracts or for chasing after unpaid invoices. So, I decided to charge in advance and to set my own terms and conditions (no liability, no warranty, no damages, etc.). And the best is: I get away with it!

When I bill by the hour, my customers have the option to pay everything in advance and get a 10% discount or to pay monthly rates in advance. If they don’t use up the hours by the set date (which never happens), they don’t get any money back. If they are late with the payment, I won’t start work or I will cancel the project (as allowed by my contract). Productised services are always paid in advance. Guess what: I don’t have to chase after unpaid bills any more.

Manufacturers understand upfront payments. Their machines don’t leave the premises until paid in full. Service companies tend to go for monthly rates in advance and forfeit the discount, because they need to get the money from their customers first - with a two month delay. Customers want 100% of my expertise from the very first minute. So, it’s only fair to get paid 100% in advance.

I probably get away with setting my own terms, because companies know that my involvement increase their chance of success significantly and because I have other options. And - I just tried it.

To Be Continued

I still owe you answers to some more questions: Why do I prefer to work alone? What would be good reasons to open a Limited company? And, why is a good work-life balance more important for me than earning even more?