Showing all posts tagged sales:

Keeping The Data Lake Clean

One of the biggest problems in data analysis is making sure that your inputs are clean and sane. This holds true whatever you are using to do the analysis, whether it’s the latest fancypants machine-learning, or a roomful of expert humans doing the calculations by hand.

I think it’s useful to keep this perspective in mind when considering Apple’s recent tie-up with Salesforce.

The first example given by Salesforce is this scenario:

Imagine a sales rep saying "Hey Siri, Daily Briefing" then hearing an overview of their day.

This scenario encapsulates the dream end-state of all of these integrated CRM systems. Normally, of course, the user requesting an overview is not the sales rep but a manager, whether the person responsible for a region who needs to know whether their team of sales reps is going to hit the regional number, or a higher manager preparing a presentation for the board and hoping very much that the key dashboards are all in the green.

The problem with such dashboards is the age-old one of Garbage In, Garbage Out. The predictions are only as good as the data they are based on. Unfortunately, the data are not always good, because by and large, sales reps – and I’ve known a few, good, bad, and indifferent – do not particularly enjoy documenting everything they do for someone else. That last clause is important; the good sales reps take a lot of notes and know all sorts of details about their accounts and territories, but the notes are for their own consumption, and the way they are taken and stored make them hard to access. Sometimes this is even by design, especially among "relationship" sales people who see their value mainly in terms of the thickness of their Rolodex1: "if you fire me, I’ll walk and take all my customers with me!".

We all know how well that play worked out for Tom Cruise’s character in Jerry Maguire. Regardless, getting the input data is a very real problem. This is why I am much more interested in the second half of that example scenario from Salesforce:

They can also easily update Salesforce records after a meeting.

Updating opportunities is already pretty easy from the Salesforce mobile app, but sales managers and Sales Ops types have a tendency to over-complicate the process by adding supplementary required fields which must be filled in to save the simple text-based notes and contact info which are the most valuable parts of the process. Added friction in the data-entry stage leads to opportunity details being added in a rush at the end of the quarter, ret-conning against the ultimate outcome of the opportunity rather than documenting facts in near real time.

Adding support for other technologies on the input side has the potential to remove much of that friction. Siri would let reps have a good rant in the car on the way back from the meeting and transcribe all of that into the activity record. Location data would enter the correct office where a meeting was held. Integration with office suites and cloud storage could add the collateral used in a meeting to the opportunity. Each addition of intelligence on the input side would remove a small amount of friction from the opportunity management process, which in turn would help to ensure that the data which all the fancy analyses are based on are at least somewhat factual.

I have no doubt that most of the videos and presentations around the Apple-Salesforce joint technology developments will focus on showing magical Minority Report2 dashboards, updating in real time, and smiling managers happy with the results being displayed. However, if any of those whiz-bang dashboards are to have utility in the real world, it will be down to the input capabilities in the individual sales reps’ iPhone and Apple Watch, and the technology’s removal of as many excuses as possible not to update Salesforce records.

  1. Yes, Rolodex; that’s how dated this way of thinking is. 

  2. I think I owe Tom Cruise royalties for this article. How much is 50% of no dollars whatsoever, again? I’m sure he doesn’t mind appearing here for the exposure, though. 

Why Sales People Will Always Be With Us

I was looking for something else in my drafts folder, and I found this older thing: Sales People: Do We No Longer Need Them?:

We all know that the internet, in particular, has made us – the customers - more savvy and more able to easily see when we're being "sold." Instead, many now believe traditional sales people should go the way of the dodo bird, and companies should offer something else — experience and customer service.

I think there is a kernel of truth here, but the argument goes too far with it. As in every market transition, there is a sieve effect at work. The good sales people were already operating in a way that is compatible with educated and demanding customers. This breed of sales person leads a diverse team and maintains the context, preventing discussions getting lost down rabbit holes. Bad sales people who rely on ill-informed customers and add no value will fail to make the transition – and indeed are already doing so. However, to bridge from the self-service check-out at the supermarket to the imminent extinction of car sales people – or enterprise sales teams – is too much of a stretch.

Example: my wife just bought a car, and sure, we had done our research, researched alternatives, built several configurations online, and she was pretty sure of what she wanted. She had narrowed it down to three alternatives, so we visited the three dealerships. Two of them had ignorant, pushy and unhelpful sales people - who did not get the sale. The third had a courteous, well-informed sales person who was passionate about his product, and helped us navigate the various finance options to get a deal that worked for everyone – including getting a notary to come to the dealership after hours so we could take advantage of a deal that was about to expire! That sales person earned his commission – and the sale.

Sales is definitely changing, but it's not going away. The only sales people who will lose their jobs are the ones who fail to adapt and evolve.

If this sounds familiar from similar screeds I have written about how AI and automation are not going to take away sysadmins’ jobs, you are exactly right. The fact that one task goes away is only a problem if that single task defined your entire job. Sure, it sucks if you’re a supermarket checkout person, because that automated checkout lane is definitely taking your job scanning barcodes by hand. On the other hand, the introduction of ATMs increased employment in banks for a long time (although it is now declining due to branch closures).

I would like to close from a quote that came up in conversation earlier today:

Ultimately, everyone’s job is sales – or we’re all out of a job.

Photo by Fredrick Kearney Jr on Unsplash

Incentives Drive Behaviour - Security Is No Exception

Why is security so hard?

Since I no longer work in security, I don’t have to worry about looking like an ambulance-chasing sales person, and I can opine freely about the state of the world.

The main problem with security is the intersection of complexity and openness. In the early days of computers there was a philosophical debate about the appropriate level of security to include in system design. The apex of openness was probably MIT’s Incompatible Time-Sharing System, which did not even oblige users to log on - although it was considered polite to do so.

I will just pause here to imagine that ethos of openness in the context of today’s social media, where the situation is so bad that Twitter felt obliged to change its default user icon because the "egg" had become synonymous with bad behaviour online.

By definition, security and openness are always in opposition. Gene "Spaf" Spafford, who knows a thing or two about security, famously opined that:

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.

Obviously, such a highly-secure system is not very usable, so people come up with various compromises based on their personal trade-off between security and usability. The problem is that this attempt to mediate between two opposite impulses adds complexity to the system, which brings its own security vulnerabilities.

Ultimately, IT security is a constant Red Queen’s Race, with operators of IT systems rushing to patch the latest flaws, knowing all the while that more flaws are lurking behind those, or being introduced with new functionality.

Every so often, maintainers of a system will just throw up their hands, declare a system officially unmaintainable, and move to something else. This process is called "End of Life", and is supposed to coincide with users also moving to the new supported platform.

Unfortunately this mass upgrade does not always take place. Many will cite compatibility as a justification, and certainly any IT technician worth their salt knows better than to mess with a running system without a good reason. More often, though, the reason is cost. In a spreadsheet used to calculate the return on different proposed investments, "security" falls under the heading of "risk avoidance"; a nebulous event in the future, that may become less probable if the investment is made.

For those who have not dealt with many finance people, as a rule, they hate this sort of thing. Unless you have good figures for both the probability of the future event and its impact, they are going to be very unhappy with any proposed investment on that basis.

The result is that old software sticks around long after it should have been retired.

As recently as November 2015, it emerged that Paris’ Orly airport was still operating on Windows 3.1 - an operating system that has not been supported since 2001.

The US military still uses 8" floppy disks for its ICBMs:

"This system remains in use because, in short, it still works," Pentagon spokeswoman Lt Col Valerie Henderson told the AFP news agency.

And of course we are still dealing with the fallout from the recent WannaCry ransomware worm, targeting Windows XP - an operating system that has not been supported since 2014. Despite that, it is still the fourth most popular version of Windows (behind Windows 7, Windows 10, and Windows 8.1), with 5.26% share.

Get to the Point!

It’s easy to mock people still using Windows XP, and to say that they got no more than they deserved - but look at that quote from the Pentagon again:

"This system remains in use because, in short, it still works"

Windows XP still works fine for its users. It is still fit for purpose. The IT industry has failed to give those people a meaningful reason to upgrade - and so many don’t, or wait until they buy new hardware and accept whatever comes with the new machine.

Those upgrades do not come nearly as frequently as they used to, though. In the late Nineties and early Oughts, I upgraded my PC every eighteen months or so (as funds permitted), because every upgrade brought huge, meaningful differences. Windows 95 really was a big step up from Windows 3.1. On the Mac side, System 7 really was much better than System 6. Moving from a 486 to a Pentium, or from 68k to PowerPC, was a massive leap. Adding a 3dfx card to your system made an enormous difference.

Vice-versa, a three-year-old computer was an unusable pile of junk. Nerds like me installed Linux on them and ran them side by side with our main computers, but most people had no interest in doing such things.

These days, that’s no longer the case. For everyday web browsing, light email, and word processing, a decade-old computer might well still cut it.

That’s not even to mention institutional use of XP; Britain’s NHS, for instance, was hit quite hard by WannaCry due to their use of Windows XP. For large organisations like the NHS, the direct financial cost of upgrading to a newer version of Windows is a relatively small portion of the overall cost of performing the upgrades, ensuring compatibility of all the required software, and retraining literally hundreds of thousands of staff.

So, users have weak incentives to upgrade to new, presumably more secure, versions of software; got it. Should vendors then be obliged to ship them security patches in perpetuity?

Zeynep Tufekci has argued as much in a piece for the New York Times:

First, companies like Microsoft should discard the idea that they can abandon people using older software. The money they made from these customers hasn’t expired; neither has their responsibility to fix defects.

Unfortunately, it’s not that simple, as Steven Bellovin explains:

There are two costs, a development cost $d and an annual support cost $s for n years after the "warranty" period. Obviously, the company pays $d and recoups it by charging for the product. Who should pay $n·s?

The trouble is that n can be large; the support costs could thus be unbounded.

Can we bound n? Two things are very clear. First, in complex software no one will ever find the last bug. As Fred Brooks noted many years ago, in a complex program patches introduce their own, new bugs. Second, achieving a significant improvement in a product's security generally requires a new architecture and a lot of changed code. It's not a patch, it's a new release. In other words, the most secure current version of Windows XP is better known as Windows 10. You cannot patch your way to security.

Incentives matter, on the vendor side as well as on the user side. Microsoft is not incentivised to do further work on Windows XP, because it has already gathered all the revenue it is ever going to get from that product. From a narrowly financial perspective, Microsoft would prefer that everyone purchase a new license for Windows 10, either standalone or bundled with the purchase of new hardware, and migrate to that platform.

Note that, as Steven Bellovin points out above, this is not just price-gouging; there are legitimate technical reasons to want users to move to the latest version of your product. However, financial incentives do matter, a lot.

This is why if you care about security, you should prefer services that come with a subscription.

If you’re not Paying, you’re the Product

Subscription licensing means that users pay a recurring fee, and in return, vendors provide regular updates, including both new features and fixes such as security patches.

As usual, Ben Thompson has a good primer on the difference between one-off and subscription pricing. His point is that subscriptions are better for both users and vendors because they align incentives correctly.

From a vendor’s perspective, one-off purchases give a hit of revenue up front, but do not really incentivise long-term engagement. It is true that in the professional and enterprise software world, there is also an ongoing maintenance charge, typically on the order of 18-20% per year. However, that is generally accounted for differently from sales revenue, and so does not drive behaviour to nearly the same extent. In this model, individual sales people have to behave like sharks, always in motion, always looking for new customers. Support for existing customers is a much lower priority.

Vice versa, with a subscription there is a strong incentive for vendors to persuade customers to renew their subscription - including by continuing to provide new features and patches. Subscription renewal rates are scrutinised carefully by management (and investors), as any failure to renew may well be symptomatic of problems.

Users are also incentivised to take advantage of the new features, since they have already paid for them. When upgrades are freely available, they are far more likely to be adopted - compare the adoption rate for new MacOS or iOS versions to the rate for Windows (where upgrades cost money) or Android (where upgrades might not be available, short of purchasing new hardware).

This is why Gartner expects that by 2020, more than 80 percent of software vendors will change their business model from traditional license and maintenance to subscription.

At Work - and at Home, Too

One final point: this is not just an abstract discussion for multi-million-euro enterprise license agreements. The exact same incentives apply at home.

A few years ago, I bought a cordless phone that also communicated with Skype. From the phone handset, I could make or answer either a POTS call, or a Skype voice call. This was great - for a while. Unfortunately the hardware vendor never upgraded the phone’s drivers for a new operating system version, which I had upgraded to for various reasons, including improved security.

For a while I soldiered on, using various hacks to keep my Skype phone working, but when the rechargeable batteries died, I threw the whole thing in the recycling bin and got a new, simpler cordless phone that did not depend on complicated software support.

A cordless phone is simple and inexpensive to replace. Imagine that had been my entire Home of the Future IoT setup, with doorbells, locks, alarms, thermostats, fridges, ovens, and who knows what else. "Sorry, your home is no longer supported."1

With a subscription, there is a reasonable expectation that vendors will continue to provide support for the reasonable lifetime of their products (and if they don’t, there is a contract with the force of law behind it).

Whether it’s for your home or your business, if you rely on it, make sure that you pay for a subscription, so that you can be assured of support from the vendor.

  1. Smart home support: "Have you tried closing all the windows and then reopening them one by one?" 

Let Me Tell You A Story

Any good presentation is a story, and a good presenter is adept at telling their audience a story in a way that is compelling. Some are naturally good at this sort of thing - but all of us have been forced to sit through presentations with no unifying thread of story.

Luckily for the rest of us, there are techniques that can help us become better storytellers, and avoid boring our audiences to tears.

One of the most effective approaches I have learned is called SCIPAB, a technique developed by Steve Mandel and now spread by the company he founded, Mandel Communications. I was lucky enough to be trained in SCIPAB by Mandel Communications as part of a more general "presentation skills" training. I don’t want to steal their thunder (or their business!), but I do want to share some of the insights that I carry with me and use regularly.

SCIPAB is an acronym, which stands for the phases of a story:

  • Situation
  • Complication
  • Implication
  • Proposal1
  • Action
  • Benefit

These phases have a specific technical meaning within the Mandel technique, but they also align with the phases of another framing device, Joseph Campbell’s Hero’s Journey. There are seventeen phases to the Journey, which Steve Mandel wisely condensed to six for his audience of sales people and marketers. To quote Wikipedia:

In the Departure part of the narrative, the hero or protagonist lives in the ordinary world and receives a call to go on an adventure. The hero is reluctant to follow the call, but is helped by a mentor figure.

The Initiation section begins with the hero then traversing the threshold to the unknown or "special world", where he faces tasks or trials, either alone or with the assistance of helpers.

The hero eventually reaches "the innermost cave" or the central crisis of his adventure, where he must undergo "the ordeal" where he overcomes the main obstacle or enemy, undergoing "apotheosis" and gaining his reward (a treasure or "elixir").

The hero must then return to the ordinary world with his reward. He may be pursued by the guardians of the special world, or he may be reluctant to return, and may be rescued or forced to return by intervention from the outside.

In the Return section, the hero again traverses the threshold between the worlds, returning to the ordinary world with the treasure or elixir he gained, which he may now use for the benefit of his fellow man. The hero himself is transformed by the adventure and gains wisdom or spiritual power over both worlds.

Let us map SCIPAB onto the Hero’s Journey, so that we can take our audiences on a journey with us and lead them to a shared conclusion.


The S, Situation, is the status quo at the beginning of the story, where our audience is living today. In most heroic stories, this is some kind of idyll, but actually in most presentations, this part is present as an opportunity to confirm our understanding of our audience’s… well, Situation. In a general audience, this is to level-set that we all understand the main forces and trends affecting our industry or sector. In a more specific audience, this is our opportunity to confirm our understanding of their specific context, and to trot out all the homework that we have been doing on them. (You have been doing your homework on your audience, right?) If this phase goes well, we have successfully positioned ourselves as the right mentor to lead our audience on a the journey.


The C, Complication, is where we depart from the comfortable status quo. In this section, we are pointing out the trials and tribulations that are the consequence of the Situation. This is where we start to turn up the heat a little and say things that may be uncomfortable for the audience, pointing out ways in which the status quo is problematic or unsatisfactory. This often boils down to 'that was a great plan, until these changes occurred, which made it no longer such a good fit".


The I, Implication, is the nadir, the lowest point of the emotional journey. Here we describe the ordeal that is inevitable if the Complication is not addressed, the "innermost cave" of the Hero's Journey. This phase is specifically about the bad things that can happen: toil and trouble, with the ultimate possibility of failure in the background. At this point the audience should be deeply uncomfortable, facing unpleasant truths about the long-term consequences of staying on their current trajectory.


Having brought the audience to this low point, we give them a vision of what is possible. The P, Proposal, is where we describe a different outcome, the "treasure or elixir" that our audience might win by confronting the monster that we described in the previous steps. Here we are selling a shining vision of a possible future - one that is accessible if only the Situation can be confronted in the right way, avoiding the Complications and their Implications.

This emotional alternation between high and low is very important. In a longer presentation (or blog post or white paper or any other kind of story, for that matter) you can even repeat this alternation multiple times, taking the audience with you on an emotional roller coaster ride. Too much doom & gloom in one dose, and you’ll start to lose them - not just because it makes for a depressing presentation, but also because you end up talking down their current situation. No matter how bad they might accept intellectually that things are, having someone else poke at the sore points over and over (and over) will trigger a negative emotional reaction sooner or later. Don’t call other people’s babies ugly - at least, no more than is strictly necessary!


Because this is ultimately a storytelling methodology in service of a sales effort, the key is to include concrete requests and actions that the audience should take. This is the A of SCIPAB: specific Actions that you want to happen as a consequence of the story you have told. This could be a next-step workshop where you can go deeper into specifics of your Proposal, an opportunity to present to someone higher up the org chart, or a request for the audience to do something, such as download an evaluation version of your tool - but the key to ensuring progress and maintaining momentum is to ask for something at every step.


Finally, close on the B, Benefits. This is the high point of that emotional roller-coaster, and also aligns to the Hero’s Journey. This is where the prospective customer gets concrete about the "treasure or elixir" they can gain from our Proposal - not to mention the "wisdom or spiritual power" they will gain along the way. This is to the Proposal what the Implication is to the Situation: the consequences that we can reasonably expect, given that starting point.

Above all, don’t be boring

By structuring your communications in this way, you will be able to have much more explicit and productive conversations with prospective customers - and at the very least, you won’t be boring them or inducing Death By Powerpoint.

Plus, this way is much more fun for the presenter. Try it, and let me know how it goes!

  1. This is also known as "Position", but "Proposal" is what I learned, plus I think it fits better within the flow. 

Thinking Two Steps Behind

In my day job, I spend a lot of my time building business cases to help understand whether our technology is a good fit for a customer. When you are building a startup business, this is the the expected trajectory: in the very early days, you have to make the technology work, translating the original interesting idea into an actual product that people can use in the real world. Once you have a working product, though, it’s all about who can use it, and what they can do with it.

In this phase, you stop pitching the technology. Instead, you ask questions and try to understand what ultimate goals your prospective customer has. Only once you have those down do you start talking about what your technology can do to satisfy those goals. If you do not do this, you find yourself running lots of "kick the tyres" evaluations that never go anywhere. You might have lots of activity, but you won’t have many significant results to show for it.

This discipline of analysing goals and identifying a technology fit is very useful in analysing other fields too, and it helps to identify when others may be missing some important aspect of a story.

Let’s think about driverless cars

Limited forms of self-driving technology already exist, from radar cruise-control to more complete approaches such as Tesla’s Autopilot. None of these are quite ready for prime time, and there are fairly regular stories about their failures, with consequences from the comic to the tragic.

Uhoh, This content has sprouted legs and trotted off.

Because of these issues, Tesla and others require that a drivers keep their hands on the wheel even when the car is in Autopilot mode. This brings its own problems, falling into an "uncanny valley" of attention: the driver is neither fully engaged, nor can they fully disengage. Basically it’s the worst of both worlds, as drivers are no longer involved in the driving, but still cannot relax and read a book or watch a film.

These limitations have not stopped much of the commentary from assuming self-driving car technology to be, if not a problem that is already solved, at least one that is solvable. Extrapolations from that point lead to car ownership becoming a thing of the past as people simply summon self-driving pods to their location, which in turn causes massive transformations in both labour force (human drivers, whether truckers or Uber drivers, are no longer required) and the physical make-up of cities (enormous increases in the utilisation rate for cars mean that large permanent parking structures are no longer required) - let alone the consequences for automotive manufacturers, faced with a secular transformation in their market.

Okay, maybe not cars

Self-driving technology is not nearly capable (yet) of navigating busy city streets, full of unpredictable pedestrians, cyclists, and so on, so near-term projections focus on what is perceived as a more easily solvable problem: long-distance trucking.

The idea is that currently existing self-driving tech is already just about capable of navigating the constrained, more predictable environment of the highways between cities. Given some linear improvement, it does not seem that far-fetched to assume that a few more years of development would give us software capable of staying in lane and avoiding obstacles reliably enough to navigate a motorway in formation with other trucks.

Extrapolating this capability to the wholesale replacement of truckers with autonomous robot trucks, however, is a big reach - and not so much for technical reasons, as for less easily tractable external reasons.

Assuming for the sake of argument that Otto (or whoever) successfully develop their technology and build an autonomous truck that can navigate between cities, but not enter the actual city itself. This means that Otto or its customers would need to build warehouses right at the motorway junctions in areas where they wish to operate, to function as local hubs. From these locations, smaller, human-operated vehicles would make the last-mile deliveries to homes and businesses inside the city streets, which are still not accessible to the robot trucks.

This is all starting to sound very familiar. We already have a network optimised for long-distance freight between local distribution hubs. It is very predictable by design, allowing only limited variables in its environment, and it is already highly instrumented and very closely monitored. Even better, it has been in operation at massive scale for more than a century, and has a whole set of industry best practices and commercial relationships already in place.

I am of course talking about railways.

Get on the train

Let’s do something unusual for high-tech, and try to learn something from history for once. What can the example of railways teach us about the potential for self-driving technology on the road?

The reason for the shift from rail freight to road freight was to avoid trans-shipment costs. It’s somewhat inefficient to load your goods onto one vehicle, drive it to a warehouse, unload them, wait for many other shipments to be assembled together, load all of them onto another vehicle, drive that vehicle to another warehouse, unload everything, load your goods onto yet another vehicle, and finally drive that third vehicle to your final destination. It’s only really worthwhile to do this for bulk freight that is not time-sensitive. For anything else, it’s much easier to just back a truck up to your own warehouse, load up the goods, and drive them straight to their final destination.

Containerisation helped somewhat, but railways are still limited to existing routes; a new rail spur is an expensive proposition, and even maintenance of existing rail spurs to factories is now seen as unnecessary overhead, given the convenience of road transport’s flexibility and ability to deliver directly to the final destination.

In light of this, a network of self-driving trucks that are limited to predictable, pre-mapped routes on major highways can be expected to run into many of the same issues.

Don’t forget those pesky humans

Another interesting lesson that we can take from railways is the actual uptake of driverless technology. As noted above, railways are a far more predictable environment than roads: trains don’t have to manoeuvre, they just move forwards along the rails, stopping at locations that are predetermined. Changes of directions are handled by switching points in the rails, not by the operator needing to steer the train around obstacles. Intersections with other forms of transport are rare, as other traffic generally uses bridges and underpasses. Where this separation is not possible, level crossings are still far more controlled than road intersections. Finally, there are sensors everywhere on railways; controllers know exactly where a certain train is, what its destination and speed are, and what is the state of the network around it.

So why don’t we have self-driving trains?

The technology exists, and has done so for years - it’s a much simpler problem than self-driving cars - and it is in use in a few locations around the world (e.g. London and Milan); but still, human-operated trains are the norm. Partly, it’s a labour problem; those human drivers don’t want to be out of a job, and have been known to go on strike against even the possibility of the introduction of driverless trains. Partly, it’s a perception problem: trains are massive, heavy, powerful things, and most people simply feel more comfortable knowing that a human is in charge, rather than potentially buggy software. And partly, of course, it’s the economics; human train drivers are a known quantity, and any technology that wants to replace them is not.

This means that the added convenience of end-to-end transportation limits the uptake of rail transport, and human factors limit the adoption of driverless technology even when it is perfectly feasible - something that has not yet been proven in the case of road transport.

A more familiar example?

In Silicon Valley, people are often moving too fast and too busy breaking things that work to learn from other industries, let alone one that is over a hundred years old1, but there is a relevant example that is closer to home - literally.

When the Internet first opened to the public late last century, the way most people connected was through a dial-up modem over an analogue telephone line. We all become expert in arcane incantations in the Hayes AT command language, and we learned to recognise the weird squeals and hisses emitted by our modems and use them to debug the handshake with our ISP's modem at the far end. Modem speeds did accelerate pretty rapidly, going from the initial 9.6 kbits per second to 14.4, to 28.8, to weird 33.6, to a screamingly fast 56k (if the sun was shining and the wind was in the right quarter) in a matter of years.

However, this was still nowhere near fast enough. These days, if our mobile phones drop to EDGE - roughly equivalent to a 56k modem on a good day - we consider the network as being basically unusable. Therefore, there was a lot of angst about how to achieve higher speeds. Getting faster network speeds in general was not a problem - 10 Mbps Ethernet was widely available at the time. The issue was the last mile from the trunk line to subscribers' homes. Various schemes were mooted to get fast internet to the curb - or kerb, for Americans. Motivated individuals could sign up for ISDN lines, or more exotic connectivity depending on their location, but very few did. When we finally got widespread consumer broadband, it was in the form of ADSL over the existing copper telephone lines.

So where does this leave us?

Driverless vehicles will follow the same development roadmap2: until they can deliver the whole journey end to end, uptake will be limited. Otherwise, they are not delivering what people need.

More generally, to achieve any specific goals, it is usually better to work with existing systems and processes. That status quo came to be over time, and generally for good reason. Looking at something now, without the historical context, and deciding that it is wrong and needs to be disrupted, is the sort of Silicon Valley hubris that ends in tears.

Right now, with my business analyst hat on, driverless vehicles look like a cool idea (albeit one that is still unproven) that is being shoe-horned into a situation that it is not a good match for. If I were looking at a situation like this one in my day job, I would advise everyone to take a step back, re-evaluate what the actual goals are, and see whether a better approach might be possible. Until then, no matter how good the technology gets, it won’t actually deliver on the requirements.

But that doesn’t get as many visionary thinkpieces and TED talks.

Images by Nabeel Syed and Darren Bockman via Unsplash, and by ronnieb via Morguefile

  1. The old saw is that "In Europe, a hundred miles is a long way; in the US, a hundred years is a long time". In Silicon Valley, which was all groves of fruit trees fifty years ago, that time frame is shorter still. 

  2. Sorry - not sorry. 

Reference This!

One of the downsides of working for a little startup that is going to change the world, but doesn’t quite have the name recognition yet - is that you get asked for customer references all. the. time.

Now on one level, I have absolutely no problem with this. It makes perfect sense from the point of view of a prospective customer: some rando just showed up, and sure, he’s got some good PowerPoint game, but I’ve never heard of him or his company - why should I waste any time on him?

The problem that a prospective customer might not appreciate is that by the nature of things, a growing startup has many more prospects than existing customers. Every single member of the sales team, if they are doing their job, has as many sales prospects at any one time as there are total customers in production. If we were to walk each of those prospects past a real customer, just so they could kick the tyres and see whether we have something real, pretty soon our existing customers would stop taking our calls - not a clever strategy, when we sell subscriptions and rely on customers renewing their contracts.

The trick, then, is to balance these requirements. On the side of the prospective customer, the goal is to validate whether this interesting startup has an actual product - or just an interesting idea and some vapourware slides. This is an absolutely valid goal - but prospective customers should recognise vendors’ incentives as well.

Reputable vendors who actually intend to build a lasting business have no more interest in wasting time and resources in projects that do not go anywhere than customers do. We know that our tech works (again, assuming for the sake of argument that the vendor you’re talking to is not just a straight-up scammer), so our goal is not to waste our limited time and resources chasing after something that is never going to be a successful, referenceable production implementation.

So, all of that being said - please don’t ask vendors for references on the first date. If the vendor you're talking to is any good, they will be qualifying you as aggressively as you are qualifying them. We vendors are very protective of our customers - once more, assuming you’re dealing with a reputable vendor in the first place! Please don’t see this as us being difficult or having something to hide; rather, it’s a preview of how your own relationship with us as a customer would be. If you trust us with your business, we will be equally protective of you. You want to be sure that if we come to you in the future with a request to talk to someone about your experience with our products, it’s for a good reason, and not something we will ask you to do every other week.

Once everyone is comfortable that there is a real opportunity - that is when we can get other parties involved. Until then, here’s a white paper, here’s a recorded webinar, here’s an article by an analyst who spoke to some of our customers - but my current customers are sacred to me, and I won’t introduce you to them until you convince me that you’re serious.

This has been your subtweet-as-blog-post of the day.

Image by María Victoria Heredia Reyes via Unsplash

When is a Cloud not a Cloud?

Further thoughts on yesterday’s post, prompted by some of the conversations about it


I realised that in yesterday’s post I implied that the key difference was between different markets; that in some markets, a full-on enterprise sales push is required, while in others you can rely on word of mouth to allow good products to emerge.

I do believe that there are macro divisions like that, but even within a more circumscribed group of products, you can still see big differences that are driven at least in part by sales activity.

Let's talk about cloud.

The conventional wisdom is that Amazon’s AWS dominates because of under-the-radar adoption by developers. In this view, teams who wish to move faster than corporate IT’s procurement and delivery cycles use their company credit cards to get resources directly from AWS and release their code directly to the cloud. By the time the suits realise this has happened, the developers have enough users on their side that it’s easier just to let them keep on doing what they’re doing.

There is a fair amount of truth to this story, and I have seen it play out more or less in this way many times. What is neglected in this simple scenario is the other cloud vendors. There was a while back there when it wasn’t obvious that AWS was going to be the big winner. Google Compute Engine seemed like a much better bet; developers already had a high comfort level with using Google services. In addition, AWS initially offered bare-metal systems, while GCE had a full-stack PaaS. Conventional wisdom was that developers would prefer the way a PaaS abstracts away all the messy details of the infrastructure.

Of course it didn’t work out that way. Today GCE is an also-ran in this market, and even that only thanks to a pivot in its strategy. AWS dominates, but right behind them and growing fast we see Microsoft’s Azure.


Data from Synergy Research Group

And look who’s right behind Microsoft: IBM! Microsoft and IBM of course have huge traditional sales forces - but what some commentators seem to miss is that the bulk of AWS’ success is driven by its own big enterprise and channel sales force. A developer getting a dozen AMIs on the company AmEx might get usage off the ground, but it doesn’t drive much volume growth. Getting an enterprise contract for several thousand machines, plus a bunch of ancillary services? Now we’re talking.

Also note who’s missing from this list - anything driven by OpenStack. There are as many opinions on OpenStack technology as there are people working on it - which seems to be part of the problem. The one thing that seems clear is that it has not (yet?) achieved widespread adoption. I am seeing some interest on the SDN/NFV side, but most of those projects are still exploratory, so it remains to be seen how that market shakes out - especially with competition from commercial offerings from Cisco and VMware ramping up.

A good sales force won’t be able to push a terrible product, not least because sales people will jump ship in order to have a better product to sell, which makes their job easier. However, a good sales force can make the difference between a good product emerging from the churn, or not.

Underestimate sales at your peril.

Image by Jan Schulz via Unsplash

Enterprise Sales - What, Why, and How


This blog is called Find The Thread because it started out as an overflow from Twitter, and so it’s not always obvious what connects one post to another, without the context of the social stream. That said, one recurring theme is me getting all defensive when somebody says something nasty about the business I’m in - and this post is no exception.

What set me off this time is a piece entitled Selling software to big companies is a 'baroque tribal ritual bloodletting,’ says investor. The "investor" in the title is Martin Casado, who can be presumed to know what he is talking about:

In 2007, Casado cofounded networking startup Nicira, which raised $41.82 million in venture funding before VMware gobbled it up in 2012 for $1.26 billion.

At VMware, Nicira's networking-virtualization technology became a $600 million business, before Casado left for Andreessen Horowitz just a few months ago.

Now Business Insider is of course quoting the most inflammatory statement in the title to drive traffic - which is fair enough. Also, I don’t think Martin Casado is wrong as such. What I suspect he is doing is generalising too much from his own experience.

The Nicira technology that Martin Casado developed is deep infrastructure, hidden way behind the curtain of IT. It’s Software-Defined Networking, basically virtualising networking equipment in the same way we have become used to doing with compute infrastructure. This sort of development is well suited to certain approaches to development and adoption. To quote myself:

[Developers] wanted a tool that would perform a specific, often quite technical, task for them, and assembled a band of like-minded enthusiasts to work on the project in their off-hours.

This is great when the outcome of the project is something like the Linux kernel, which is safely hidden away from users who might cut themselves on its sharp edges. Problems start to occur when the band of hackers try to build something closer to the everyday surface that people see and use.

That describes Nicira - or Martin Casado’s example in the BI article, Mesosphere - to a T. People are trying to get something done, something quite specific that is an evolution of a well-understood domain. People in that position will indeed go looking proactively for a tool to achieve that specific thing.

So far, so good. The problem is that certain types of problem are exciting and trendy to work on. Others… not so much. When is the last time you saw a popular open-source CRM system, or ITIL-compliant service desk?

That’s why makers of less trendy software have to actually, y’know, go out and sell.

What's so horrible about selling enterprise software? Well, when a big software company like Microsoft, Cisco, or even VMware wants to sell a product, they have to go through "a very baroque procurement process," Casado says.

They have to romance third-party service resellers and consultants into offering their products, who then in turn wine and dine their customers' CIOs and IT departments, taking them to expensive dinners and out to the golf course.

The whole process can take months, if not years, and it hinges just as much on salesmanship and professional contacts as it does on the products themselves. The big tech titans have gotten very good at it, to the point where it's difficult for any kind of new startup to get a seat at the table in deals of any substantial size.

"I would say all of these large companies, their strength is selling to that sales channel," Casado says. "I've always thought that was the most difficult thing for enterprise startups."

This description of the process is exaggerated (especially the wining and dining bit - the days of big deals closed at the golf course are all but gone), but not fundamentally untrue. The point is, this is the channel that exists to get tools that are necessary but perhaps not as exciting as SDN to their customers.

VMware itself did not start out as the VMware colossus that we know today. Back in 1998, they were definitely a like-minded band of hackers. Even by the time I became a user in the early 2000s, compute virtualisation was definitely A Thing, but far from a standard. Now, the technology, the market, and the company have all grown and matured, and so the approach that made sense fifteen years ago is no longer appropriate.

A cynic might even suggest that, having sold Nicira at the height of the excitement around SDN, Martin Casado is holding everyone else to an impossibly high standard because he does not recognise or admit the unique advantages which he had.

Car Analogy

I like cars, so let me try a car analogy here.

If you’re running Tesla1, you do not have an easy job by any means - but you are at least selling into a recognised market. People already buy cars, so you sell a category of product that people already understand. You still have a lot of work to do in clarifying the differences and maximising the positives, but a lot of the interest is self-propelled: people are thinking of getting a new car, hear about this Tesla company, and add it to the list of possible cars they might want to consider.

If instead you are trying to get a flying-car company off the ground2, you are facing a much tougher battle. Nobody is looking to buy a flying car; they are thinking in terms of either a traditional car, or an aircraft. This means that you have to create a new interest where before there was not even awareness of the possibility, then nurture that interest into excitement and eventually (one hopes) a sale. You can’t just sit back and wait for people to Google you; everyone is at their local car dealership, on the Tesla website, or (for the 1%) playing golf with their Gulfstream sales rep.

So what do you do? You hire sales people, you develop a sales channel, and you accept the added time and expense of all this as part of the cost of getting your product out there.

And meanwhile, ignore the snark of the Tesla1 people, who can sit back and let the Google searches roll in.

Bottom Line

I have nothing but respect for Martin Casado and his technical achievements. SDN is upending network architectures everywhere. However, many of the companies doing those SDN implementations at scale are the same network operators as before. Their procurement processes are the controlling factor, more than any supposed lag by vendors.

The enterprise sales process is the way it is for a reason. There are a number of ways to disrupt and shortcut the more cumbersome parts of that process. However, doing so successfully requires a customer base that is equally ready to participate in that process. If you are selling to customers who buy that way, good for you - but don’t try to generalise your findings too quickly to other areas.

Image by Dmitri Popov via Unsplash

  1. I have nothing against Tesla or Elon Musk - although I do object to some of the more excitable and breathless of their fans. I am just picking them as a convenient example. In fact, given how differently Elon Musk operates his various businesses, I would guess that he understands the difference I am articulating very well indeed

  2. Sorry - not sorry. 

Pity the Vendor


Dear users: It’s not easy, being on the vendor side. Let’s assume, for the sake of argument, that you work for a reputable, non-scammy vendor. Let’s also take it as a given that you have done your homework, so you are not spamming people indiscriminately, but trying to reach people whom you genuinely believe to have a need for your product.

How do you go about reaching those people?

Most people are understandably very reluctant to publish their contact details everywhere, because less principled sales people have already saturated their tolerance for randos showing up in their inbox out of the blue. This means that there is a (justifiably) high barrier to getting their attention.

There is also something of a tragedy of the commons effect, as all the vendors converge on those people who have been less diligent about scrubbing their personal details off the Internet.

Here’s the deal: when I contact someone, it’s because I genuinely believe that they might have a need for what I’m selling. It’s a pretty niche market - which is why it makes sense to hire human sales people to build and maintain a small number of customer relationships in the first place. This means I take the time to do my homework, and my approach is specific as I can make it based on public information.

If I’m working on selling into BigCorp and I get a number for Alice or Bob who work there, my first step is not to pick up the phone. Rather, I go off to research what they do at BigCorp, what they personally care about, and so on. I use all of this to build a pitch that might go something like this:

Hi, sorry to contact you uninvited, but I know you are working on A, B, and C as part of an initiative at BigCorp. I have worked with other companies in your position such as WidgetTicklers, who were able to complete their own similar project under budget and ahead of schedule. They did this thanks to key capabilities enabled by our technology: …

You get the idea: it’s not a form letter I’m blasting out, it’s carefully targeted and as specific as I can make it with information at hand.

So what’s the problem? The problem is that the hit rate on doing this is still terrible. It's not mis-targeting, because often when I do finally manage to make contact by some other means, it turns out that I was right, there really was a need - but that was the wrong channel to connect with the person.

Here’s my question: what is a good way to contact you? Assume I have something you want, but not something that would show up in your normal reading. Maybe it’s launched since the last time you went looking for this sort of thing. I’ve done the prep work of identifying a potential interest you might have for this product; how should I bring it to your attention?

Because seriously, this stuff is great, and everyone needs to know about it - not just because I get paid (that too, of course!), but because I think it can really help a whole bunch of people. That’s the definition of win-win.

Image by Anton Repponen via Unsplash

Emails, Meetings, and Slides, Oh My!

In the vein of Coté’s White Collar Survival Guides, here are some suggestions of my own for knowledge workers.

The Three Horsemen of the Productivity Apocalypse - and how to slay them

There are a few constants of corporate life that are pretty much universal, and those are email1, meetings, and slides. All three are widely hated, and someone is always trying to kill one or other of them. I have even heard people say that these three factors have ruined their lives.

I would say that the truth is a bit more nuanced. "With great power comes great responsibility", as they say, and certainly all three are powerful tools.


Ah, email. If I had a Euro for every time something had promised to kill email… well, I could start by filling out my dream garage, but I’d still have plenty left over after that. We should probably amend the old saw about only cockroaches surviving nuclear war to include Sendmail running somewhere. Despite everything, it’s still the best tool at its job.

The problem is that most of the time we use email wrong. Email chains devolve into endless back and forth, with unhelpful subject lines like "Re: Re: Fwd: RE: Re: …". This is why, amid all the froth about the latest would-be email killer, I was interested to spot an article discussing how to do email right. In particular, the counter-intuitive recommendation is to write longer emails.

A key rule for e-mail is to keep it brief. The recipients are pressed for time – and perhaps, on their mobiles, cramped for visual space – so keep it to a sentence or two.

Wrong, says productivity expert Cal Newport.

His recommendation is something called "process-centric email":

  • When sending or replying to an email, identify the goal this emerging email thread is trying to achieve. For example, perhaps its goal is to synchronize a plan for an upcoming meeting with a collaborator or to agree on a time to grab coffee.
  • Next, come up with a process that gets you and your correspondent to this goal while minimizing the number of back and forth messages required.
  • Explain this process in the email so that you and your recipient are on the same page.

The desired result is to spend a little more time on each individual message or thread, but reduce the number of visits you need to make to your inbox over time.

This is not that dissimilar to the time-tested format of the VITO letter: grab your correspondent’s attention up front, then articulate your message and the reasons why they should care, and close with concrete actions. Of course you will take more time when writing to an actual VITO than to a run-of-the-mill correspondent, but it’s still an effective tool.

The only problem with both these techniques is that they work well one-to-one, but fall down with those huge sprawling email threads that we all know and love to hate. As more and more people get added to the conversation, skirting Dunbar’s Number, any chance of useful communication breaks down.

Modern tools like Slack can supposedly make this situation better, or at least more tolerable, but the problem there is the requirement that everyone adopt the new tool. As long as not everyone is on the new channel, it’s more trouble than it’s worth to either verify someone is on board or to bring them on board. In time-honoured fashion, people default to just adding more and more people to the same old email chain.

The problem is compounded by the perfect confusion which reigns over email etiquette, with no agreement over who goes in To: and who goes in Cc:, let alone anything about hierarchical ordering of participants.

Still, email is better than all the alternatives, for one simple reason: it works, almost always and almost everywhere. That is a high bar for any new offering to clear, as I have written before.


Meetings share many of the same problems as the big multi-user email chains that I was just complaining about. Sure, the attendee list for an in-person meeting is limited by the size of the available meeting rooms - still the most in-demand commodity in any office. Online meetings and conference calls, of course, do not share this limitation.

In either case, though, some attendees may be disinterested, others may be there mainly to be seen, and some may actually be negative. Unless the agenda is enforced ruthlessly, the discussion will move off-topic very rapidly - which anyway is probably a good idea, otherwise why have the meeting in the first place?

One way to optimise the use of meetings comes from Amazon.

In senior executive Amazon meetings, before any conversation or discussion begins, everyone sits for 30 minutes in total silence, carefully reading six-page printed memos.

What makes this management trick work is how the medium of the written word forces the author of the memo to really think through what he or she wants to present.

I have criticised some Amazon quick-fix management practices before, but I think this one makes a lot of sense. In the typical meeting agenda, quite a lot of time is spent level-setting, making sure everyone agrees on the situation to be analysed before proposals can be put forwards. Inevitably, people who are already up to speed - or who think they are - will hijack this process by asking questions, and there are only so many times you can promise to "get to that in just a couple more slides", especially with senior people, before you start losing your audience.

Amazon’s two-stage approach, with the author clarifying their thinking by setting down their analysis and proposal in writing, and the other participants absorbing that message in full before starting to discuss and question it, seems like a really productive way of avoiding the problem.

Sure, it takes a long time to write six-page documents, so maybe save those for the big strategic meetings - but if there is time for a meeting, there should be time for at least a one-page recap of the situation to date, some high-level proposals, and desired outcomes of the meeting. If there is no time to either write or read such a succinct summation, is the meeting really a valuable use of anyone’s time?


What can I say? I’m a fan of PowerPoint. There, I said it. Much like email, PowerPoint can be (and often is) used wrong, putting audiences at risk of death by PowerPoint, but it’s very effective when used well. Not to blow my own horn, but I get a lot of compliments on my presentations. Partly of course this is because people are used to such a low standard that it doesn’t take much to stand out - and partly it’s because I put thought, preparation, and the results of formal training into my slides. Sometimes this takes a bit more effort than it should, but the results are well worth it.

Invest in a couple of books - I like Slide:ology and Resonate by Nancy Duarte, and of course Presentation Zen by Garr Reynolds. If you can get to a training session, so much the better; talking through this sort of material with an instructor is really effective.

See you at the meeting

I’ll drop you an email about it, and send you my slides afterwards.

Image by Nirzar Pangarkar via Unsplash

  1. I’ve given up on hyphenating e-mail since I realised that apart from bills and greeting cards, I receive no physical mail whatsoever, and have not done for some time now. In fact, we could pretty much just go ahead and call it "mail", if it were not for the fact that then you would need a term to describe old-style mail, and "snail mail" is just a bit too precious and insider-y to catch on.