Most businesses that do not trade physical goods are professional services businesses. This is true because the world needs more plumbers than piping manufacturers, more custom business software than operating systems, and ostensibly more Agile coaches than Atlassian suites (or sticky note manufacturers).

In implementation professional services (e.g. plumbing or custom business software development), your added value is that you bring a set of skills and an amount of experience to your customers that they can not either economically or timely build themselves.

In advisory professional services (e.g. personal finance advice), your added value is that you provide operational guidance, insights, or decision influence based on research and knowledge that your customers can not either economically or timely perform or access themselves.

Understandably there are nuances in hybrid forms of the above. And there are more political reasons for calling on consultants like reducing perceived risk by introducing a second opinion supporting your own, or creating the option of shifting blame. For the scope of this article we will focus on the true value propositions phrased above though.

Unfortunately, you are not likely to be very successful cold calling Fortune 500s assuring them: "We know shit you don't. Trust us.". This is where a value proposition comes in. At the very least you will have to explain what "shit" you know about. Markets evolve. To retain relevance, your value proposition needs to evolve with them.

What is a plumber

I have a basic understanding of how plumbing installation works. Still, doing plumbing for a decent bath room myself would consume two weeks of lead time, a full day of googling things, and an estimated seven hundred trips to the DIY store. So instead I call James, a real plumber. James spends about thirty seconds looking around the bath room to be. Then he leaves for an hour, only to come back with exactly the materials he needs and not a single piece more. I pay for that hour too, but at least the wholesale plumbing supplies store provided the coffee that James had there. James spends another couple of hours fixing the bath room installation. In the end I pay James substantially more than the hourly rate for a plumber, but substantially less than I can otherwise earn in the two weeks that I would have spent doing the work myself. I am James' ideal customer: I have a reasonable high level understanding of what needs to happen and how much it should cost, but I am utterly incompetent when it comes to implementation. (By the way, when you are in desperate need of a hobby that you get to practice only once a decade and do not care about flooding risks, DIY plumbing is just the thing for you.)

James will always have work to do. People renovate kitchens and bath rooms all the time. But, perhaps contrary to popular belief, James' work does change. A decade ago thermostatic radiator valves were a big deal, but now those are commodity and instead everyone is looking for a fancy boiling water tap as the center piece of their new kitchen. In order to keep up with these developments, James gets commercial and technical product information from that same wholesaler who also provides his morning coffee. The wholesaler in turn gets these products pushed from the manufacterers, who in turn make sure there are nation wide advertising campaigns to inform consumers that only old fashioned losers have a kitchen without a boiling water tap.

By paying attention to what happens up the value chain James can be a plumber for decades in very much the same way that you can easily be, let's say, a Microsoft Data Warehouse professional for decades. You see, a decade ago it was mostly SQLServer, but then came PowerBI and now there is this Azure Cloud thing (before you look it up, MS SQLServer is 30 years old in 2019); staying relevant is a matter of keeping your Microsoft certifications up to date. Similarly, you can earn a long lasting living in custom software development, because once you knew everything about Spring Framework and Hibernate whereas now you are an expert when it comes to micro services and Spring Boot (or some other manifestation of the same ideas for another language runtime).

And of course there are the Agile coaches who first had SCRUM and Kanban, and now… Oops! There is no SCRUM 2.0 and there's nothing further up your value chain apart from a small group of people who do not care to monetise anything beyond existing certification programs. The evolution of the value proposition ends here. This is why you will find Agile coaching companies helping out marketing or finance departments to learn about Agile practices as a last resort to a sliver of lasting relevance. Having reached a certain level of maturity in Agile development practices, the custom enterprise software development industry, at which Agile coaching is targeted, will rather sooner than later no longer require consultants to come in and explain how SCRUM works. And when it does, it will only be for very brief engagements at commodity tariffs at best.

But, you say, "in order to truly benefit from Agile practices you should always rely on a true expert to make sure you are doing it right; so there will always be a need for expert Agile coaches!". This is how over time you painfully learn that customers tend to do things for their reasons, not yours.

Failing to evolve your value proposition puts an expiration date on your operation. Let's have a look at mitigating this.

Why Does Your Customer Need You?

You are a professional services business providing custom software development for your clients on site. You have a portfolio of technologies at which your consultants show expert level proficiency. Why does your customer hire you?

At the very least, your customer has a need for custom software development. If that is not the case, your industry does not exist anymore and you should all become plumbers instead. Assuming there is still demand for custom software development, why does your customer hire you specifically?

Your customer, and the industry at large, posesses a certain maturity level with respect to the technology portfolio that your company provides consulting for. If your customer is quite mature at dealing with these technologies themselves, then your services are filling a capacity gap for your customer. If your customer is immature at dealing with these technologies themselves, then you are filling a knowledge gap for your customer. The former comes at commodity hourly rates and involves short lived engagements, because customers tend to hire on staff employees for longer lasting shortage of commodity skills. The latter yields longer lasting engagements and comes at higher hourly rates, because your customer is not in a position to hire top people who remain at the forefront of technology leaving contracting consultants as the only other option to meaningfully bring the knowledge in house. Where do you want your business to be?

If you wait long enough, you will automatically move from knowledge provider to capacity provider. This is why you invest in learning about shiny new things all the time; you need to stay ahead of the maturity curve of your customers. This implies that in order to successfully evolve your proposition, you need to somehow keep track of the maturity level of your customers with respect to your services.

At the time of this writing, Single Page Apps are pretty much a given (I filed my 2018 taxes through one and my bank's online solution is a SPA). Cloud computing and Micro services are undisputed, but definitely still new and scary; so you are are right there helping your customers make the transition. And it is too soon to talk about serverless with your enterprise customers. Even though the technology might be ready, you will want to hold off on the proposition until your customers show some threshold level of awareness. Remember: a high level idea of what needs to happen and what it should cost, but utterly incompetent when it comes to implementation is what you are looking for. This is why there is a market entry threshold as well as a commoditisation cutoff in the above visualisation.

You actively keep an eye out for all new technologies, you pay attention to what the cloud and open source vendors have to say about future developments, and you listen to important people who speak at conferences (and also just happen to write books and sell training materials). Essentially, you stay up to date with what happens up the value chain. Congratulations! You are now exactly as business-savvy as your plumber. You will actively hunt and secure a launching customer for each new piece of technology that you identify as valuable addition to your portfolio, such that you can onwards tout your expertise in this area just when the market's maturity has reached your entry threshold. This is also why successful freelance developers always introduce a new technology in the last couple of months of their gig; they are updating their CV for the next one. Evolving their personal value proposition.

#foreverlearning

Adding technologies to your portfolio at the rate that they apparently become relevant is demanding if not exhausting. As you scale your business, individual employees develop specific areas of expertise which ditributes the work load. But then, as you accumulate a list of perhaps seventy five different technologies for which your company provides expertise, it becomes troublesome to come up with a smooth elevator pitch. Or website copy for that matter.

One solution is to stay small. You can happily run a twelve person company providing software development services for a very long time and not grow beyond that. Overhead is low, your tariffs will evolve with the going market rates, you will have no problem internally aligning technology focus and initiatives, and you will be less lonely than a freelancer. You make sure you employ a team of senior people with established networks, so there is a steady stream of new projects coming your way without a need for dedicated sales or marketing. Everyone is happy… Except if you have any outside investors; they will not be happy.

Another option is to stay extremely focused as an implementation partner. Stick to Microsoft Data Warehouse technology and only that. Nothing else. Make sure you stay up to date with Redmond's latest and greatest. As long as you can keep up, everyone is happy… Until data warehousing using Microsoft technology becomes so accessible that end users can do it. That will be the end of business for you. If that scenario seems remote to you, remember there was once a time when you needed to hire a HTML programmer in order to publish a static website.

So what else can you do? How do you grow from twelve to fifty without ending up with a technology zoo run by code writing anarchists? How do you graduate from being a team of individual plumbers?

Beyond Plumbing

Like any plumber, James has a van. It's his office, means of transportation, and his most prominent marketing instrument. The outside shows his phone number and a concise list of the services that he provides: luxury bath room installation, boiling water taps, and climate control systems. Of course he knows how to do all other kinds of plumbing tasks, but he has decided to focus on these as his advertised portfolio. If you gather a group of about fifty individual plumbers like James and list the set of advertised expertises from the collection of vans, you end up with an incomprehensible mix of over a hundred services that are provided amongst the bunch of them. If you were to create a company with these fifty plumbers and their vans, not a single one of your customers would really understand what your company does best or most.

Yet, some form of the above dynamic appears to dictate the fate almost every software development shop growing from twelve to fifty and beyond. To make matters worse, you will likely setup a company blog that allows employees to liberally publish about their indivudal technology fetishes without any communication strategy whatsoever. Why not let everyone use the office space as meetup venue too! It never hurts to have the lively gathering of members of the Unikernel Enthusiast Meetup Group burn through your events budget… Perhaps we can do better?

Shown above, managing the technology portfolio has become a background process with respect to the value proposition. You introduced a number of high level themes that these technologies contribute to. Over time you have evolved from Lightweight Application Development, using Spring Framework and Hibernate on Tomcat plus Single Page Apps, to Cloud Native Computing, deploying micro services to AWS or GCP plus perhaps a hint of serverless in the mix, and finally you aim to evolve onwards to specialising in Software Portfolio Management (however that works you are still figuring out). The themes are now your value proposition and all you have to do is make sure that anything that you add to your technology portfolio fits within these themes. You watch the market for developing high level themes that you should focus on in the future and use these as a guidance for managing your technology portfolio.

Simple, right? As it turns out, doing this well and in alignment is not exactly trivial.

When interviewing a candidate, do you talk about Kubernetes in relation to your cloud native computing proposition and how the technology fits in there today and how that will change in the future? Or do you just babble about technical details to find inevitable agreement in how awesome you both think Kubernetes is?

When colleagues spent their weekend making a Raspberry Pi interact with the latest Azure IoT cloud offering (I don't know if that is a thing you can do, but I am willing to bet that it is) and then writes a post on the corporate blog about it, do you applaud them for cleverness or do you encourage people to think about the business contributions of these actions? Do you build a culture of thinking in commercial outcomes? Did you ever think about the tradeoffs between the personal freedoms of dabbing with technology and the contributions to your value proposition?

Have you spent any time considering what comes after cloud native computing? What is your longer term industry vision?

You learn that it is much easier to make your company temporarily buzzword compliant than it is to make it stand the test of time.

Cloud Native Computing: a Worked Example

You are all about cloud native computing now. Sooner or later, you are going to have to answer the questions of what, why and how. What is your vision on cloud native computing? Why is it important that your customers move on this now? How are they going to do that? You will not get away with "cloud native computing is all about putting things in Docker containers" anymore. Your story requires more depth. Here is an example:

What Is Your Vision On Cloud Native Computing?

Your answer: The essence of cloud native computing is that any developer in your organisation can create, build, and deploy an application independently and without blocking dependencies on other departments, irrespective of whether that application needs to serve hundreds, thousands, or millions of users.

From now on you only work with customers who agree with this. This is harder for the sales people, because previously they could just go to a prospect and shout "Docker!" at them a number of times whereas now they will have to have an actual conversation. But it's a small price to pay for the benefit of having a higher quality conversation with your customers. One about outcomes and vision, instead of deadlines and tariffs.

There are legions of prospective customers out there who want to bring deployments to the cloud based on some Capex vs. Opex optimisation, or cost savings, or to de-risk the maintenance of a legacy system. All valid reasons, but these are not your customers. Let them hire an army of freelancers instead (the ones who put Docker on their CV at the last gig) and let some poor internal project manager deal with it. They are used to talking about deadlines and tariffs.

In the end you are still putting things in Docker containers. Except now you only do this for customers for whom it is part of their strategy execution, not some short lived operational concern. Most interesting professional services value propositions in technology are about top line improvements. Improve business, don't save cost. The latter is an internal process and hardly ever an enjoyable one.

Why Is Now The Time For Cloud Native Computing?

Your answer: Software is still eating the world, and by now it is definitely also eating your business. Whether you are a financial service provider, utilities company, insurance broker, or personal transportation provider, there is someone out there working on a better version of your business for the next generation. You are under constant pressure to repackage your underlying commodity (e.g. credit, insurance coverage, electricity, taxi rides) into software products made for the internet population. Cloud native computing is the approach to infrastructure and application development that enables you to run a fast paced technology product organisation, not an IT department.

This is where you really set yourself apart from competition. You show that you understand your customer is in a position to monetise some underlying commodity. You understand that they are under pressure to create ever more software just to simply reach their customers, the consumer.

Many of your competitors will answer the why question with something along the lines of "Netflix does it too and they are smarter than you, because they speak at conferences. Also Google says it's a good idea to do this.". Let them. You have a deeper understanding why.

How Are You Going To Implement Cloud Native Computing For Us?

Your answer: Using heaps of shiny new technology. Also, we have these reference architectures specifically tailored for <insert vertical here (e.g. finance, health care, travel)>. Additionally, we employ the very best and brightest of the planet using our top notch hiring and internal training processes.

Don't kid yourself. In the end your customer is still looking for a group of plumbers. Someone has to write the code. They just want a group of well informed plumbers who also understand their business objectives and longer term plans. That's you, because you evolved your value proposition to be a partner for cloud native computing implementations; not just a local Kubernetes expert.

What Is Next?

Good. You nailed this cloud native thing. What comes after? What do you have up your sleeve to make sure you don't fall victim to the slippery slope from knowledge provider to capacity provider?

You think about what happens when your current theme commoditises; when all of your customers show maturity in running cloud native IT and are managing a portfolio of software products. As you know solving one problem tends to create another. And this is exactly what your business, and our industry, needs. Another, industry wide, universally recognised problem. You also know that the traditional practice of software asset management is primarily focused on vendor management, negotiating licenses, and managing integrations. What happens when the buy vs. build ratio flips over to the build side? And the buy side consists mostly of fairly transparent pay-per-use contracts? This is your next theme in the value proposition: software portfolio management (or perhaps software product portfolio management, so you also have a place for the Agile coaches who have by now figured out that product management is their next move).

While your people are out there milking the cloud native theme dry, you are internally working on researching the why, how and what of the next one. You will closely look at the best practices of companies who are already eaten by software, often because they were created that way. What happens there and what works? Why is Google so fixed on gRPC and monorepo while everyone else thinks it's overkill? Why do some places use in house tooling that enforces internal API guidelines and strongly emphasise idiomatic development? Is it because they are a bunch of over-engineering geeks or did someone figure out that shifting human resources around projects and product teams becomes easier that way (yes, I said human resources in 2019)? What accomodating tooling should exist three to five years from now? Does that provide an opportunity for a new piece of open source that will gain you industry wide recognition and authority on the topic? You are smart enough to understand that innovation is about figuring out the next cycle, not about rushing to a better mastery of Kubernetes before anyone else (the odds are against you winning that race). You can sell yourself into the trouble of requiring a deeper understanding of Kubernetes and just figure it out along the way on customer time. You can't come up with a vision on a new theme overnight.

Conclusion

I will leave it as an exercise to the reader to figure out whether software portfolio management is actually the next thing to work on. And to come up with a good what, why and how. You get the point by now.

When you are an implementation partner, your actual work will always be plumbing. Or programming. Otherwise you should have gone into business advisory or strategy consulting, but if you pursued an engineering degree it is likely too late for that by now.

How hard you have to work for your gig after the next one and how feasible it is to scale your organisation depends a lot on how well you manage to evolve your value proposition and make it part of your company's hive mind. Not on how well you understand Kubernetes. Of course working with subpar professionals will not get you re-hired, but any team of seasoned software professional will get the job done. A reasonably senior developer will get from zero to deploying a first Dockerised service on Kubernetes in about the same time it takes to read this article.

Alternatively you can stay happy as a small group of experienced software professionals. You get called in whenever technical problems are actually a challenge, when projects are close to failing, or when a business needs something twice as fast as others can build it. I call these software mercenaries. They typically get to choose what they work on and will always have work; just like James.

And finally you can just spend your days implementing Microsoft Data Warehousing technology. Microsoft has an entire department dedicated to making sure that somehow their product range fits any paradigm shift, at least on paper. They have another department dedicated to recommending your services to their customers as long as you put in the effort of keeping your certifications up to date. Let someone else take care of the nuisance of evolving your value proposition and just be ready when someone needs a plumber. The manufacter will take care of generating demand by gently explaining that only old fashioned losers are still running SQLServer on premises.

Don't be ashamed if you opt for one of the latter two. You still get to drive a new Tesla and tell people at your high school reunion that you run a successful IT company. As long as you avoid building yet another technology zoo.