Where IT Vendors lose customers

Having a mentor on hand to show the way can be vital for continued success.

Imagine your standard project deployment lifecycle:  3 months of research, 6 months of deployment, 3 years of operation, then it's time to start again.

The problem is, vendors tend to be involved at the "interesting" front-end of the cycle, but ignore the day-to-day side of things as they focus on the next win. This is hardly surprising: sales teams are continually goaled to make new revenue,  and are also mainly engaged with the big decision makers in an organisation, who typically are interested in the new projects rather than business as usual (BAU).

With three or more years of deployment, though, it's important to make sure that the new changes and techniques introduced in the project aren't lost, that once-winning features sidelined or relegated to the old way of doing things, or that – worst of all – some operational problem doesn't derail the entire system and throw the vendor's ability to execute into question.

As previously discussed, some of the sales-to-deployment transition can be better handled by incorporating solution architecture into the process: having someone shepherd the process from inception to deployment is important to make sure that everything goes to plan.

Even in cases where the deployment is carefully managed, however, many organisations still don't have a smooth handover from implementation to day-to-day operations.  This is the sort of case that devops is supposed to address – avoiding the "throw over the wall" mentality that is so common when IT projects move from the "interesting" new phase to the often-perceived boredom of normal operation.   In the worst cases, operations staff haven't been involved in the project, and are merely faced with a raft of new systems and procedures for which they don't see value.

This is where operations mentoring is important: getting a customer's BAU staff up to speed and onside with the new projects capabilities can be crucial to successful adoption of the technologies as intended, which in turn can have a significant impact on later sales.

The operational level is also a crucial relationship to make in order to understand what's going on at the customer, and avoiding "CNN moments" or unfortunate incidents just at the time that renewal (or another project) comes along.

An operations mentor is a skilled member of the vendor's technical staff – not necessarily part of the sales team – who can sit with the customer's operations group for an extended period (say three months), and help build up their own local knowledge in the new products and technologies. Where no local guru exists, this person fulfils that role, with the goal of bringing the customer's own team up to a higher level of operational capability.


It's important to realise that this isn't a traditional staff augmentation role: the goal here is to build up competency so that when the mentor leaves, the customer's team can continue on its own.  With that in mind, the tasks for the mentor should not be day-to-day management of the new systems, but should rather be to help the customer with supplementary education, tips and tricks, and the development of guides and run-books.  The idea is to follow the proverb: "give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime".

The "lifetime" in this context includes future interactions with the sales team – when a customer is comfortable with the previous technology, then they can be much more open to new products, and to deployment in new projects. Operations Mentoring is the way to develop that comfort, as well as to show that the customer's continuing success is important.

What's Really Needed for Solution Selling - DevOps for Vendors?

Solution selling has been held at the pinnacle of achievement by IT vendors for a long time. The goal is to become the trusted advisor to the customer and, ideally, so integrated into their strategy & decision making process that sales simply happen as a side effect.

This isn't as easy as to achieve as the corporate bods who run sale training programs would like to think:  a couple of years ago the Harvard Business Review published an article describing how conventional solution selling has reached the end of its usefulness, especially when the "solutions" being applied to customer problems are really just pre-packaged configurations of what products are available "on the truck".

The hardest thing about B2B selling today is that customers don’t need you the way they used to.

 – Brent Adamson, Matthew Dixon and Nicholas Toman in Harvard Business Review (July 2012)  

The thing is, given the Internet and other ready sources of information, many customers no longer need to approach vendors simply to acquire data about products and capabilities. Customers are also naturally suspicious of the "sales" approach, not wanting to be either baffled by (or simply subjected to)  techno-babble or waste valuable time when they perceive that a vendor simply has a quota to meet.

What they do need, whether they know it or not, is someone to help take them on the journey past simple product selection and into design and deployment stages with deeper insight than they can manage themselves. This is clearly evident by the large number of "vendor neutral" consultants that are often found floating around major projects. Of course, the the challenge that these consultants often have is they lack the detailed design & implementation knowledge required to take full advantage of the technologies purchased by the customer, and also don't have access to the back-line support to engineering & product teams for detailed assistance.

This is where vendors can really help the customer by integrating the sales, design and delivery portions of their organisation. With simple feature & product comparisons already done by the customer's online research, the sales team can become more valuable by being really involved with the design process, and helping see this through to implementation (& even beyond).

Sadly, all to often corporate structures aren't set up to cope with this idea: too often there's a strong demarkation between sales and delivery, with only a few very large customers having access to a team of solution designer^[1] and professional services delivery people as part of a vendor relationship. The difficulty is further compounded, even in these cases, by the separation of profit & loss for sales, professional services and education. Of course it's important to measure performance, but in complex sales situations the complete solution is almost always going to be a combination of product, services and training.

What IT vendors need is to have someone (let's call them a solution architect^[2]) to take the customer on the journey from idea to deployment. What I mean by that is to have someone who will listen to (and help document) the customer's requirements, be involved in pitching a solution concept, work on a developed design, and then guide the customer (and perhaps a larger team) through the implementation phase to successful operation.

The Architect - by BoonieT

This may be easier said than done, as it requires a skill set and temperament to see things through from inception to deployment, and may include the need for project management skills if the architect is to lead a team of others, especially if they are from other organisations. The biggest hurdle, though, may be entrenched corporate structures or simply industry culture in the vendor organisation. This is clearly a significant role, yet the prevailing wisdom is that "sales" jobs are more senior/appealing/lucrative than "implementation" roles. Even if senior, technically-competent people exist in an organisation, it is often the case that such folk are seen as being "too valuable" to tie up on on account or one project for a long time: either they need to get on to the next sale, or fight some fire at another customer.

This is where the traditional concept of separating sales and implementation needs to be changed, to be thought of as simply different phases along the same continuum. Perhaps this idea is really a vendor version of devops.

Of course, operations is where the real rubber hits the road, more on that in a later post.

1 - I studied "real" architecture - buildings and suchlike - so the application of the word "architect" to stuff we do in IT often seems wrong to me

2 - This is more like what a "real" architect does, so I'll consent to use the term here

Can Open Source Help Solve Unemployment?

The other day on the way from yet another airport to yet another hotel, I was chatting with the taxi driver who was interested in what I did. Inevitably, the taxi driver was not really a taxi driver, but just doing it as casual work while he looked for a real job.  He had a degree in electrical engineering, but like a lot of young people was finding it hard to get that first job since he lacked experience.

His story isn't unusual – according to The Smith Family's Dr Lisa O'Brien, Australia (like other countries) is facing record youth unemployment, with many candidates lacking job-ready skills.  Now having that university degree is probably going to help, but even this is no longer a guarantee of employment without experience.

So what has this got to do with Open Source?

Put simply, getting involved in an open source project is a great way for anyone to show that they can contribute in a meaningful way, work well with others, and develop skills and experience that can be directly transferred to a work environment.

The barrier to entry for open source projects is very low – you just need to show an interest in getting involved. In fact, it's not even necessary to be a proficient coder: open source projects often have more need of usability testers and documentation writers than programmers.  Although higher education can help with developing programming and project management skills, many open source projects have contributors who have not yet graduated or may not yet even be of university age.

The results can be quite dramatic: open source companies like SUSE frequently recruit new developers from the ranks of active contributors, and often look for open source experience & reputation rather than demanding formal qualifications.

What this means is that even without a particular degree or even paid work experience, involvement in open source can open doorways into an IT career, in a way that is relatively easy to access.

Just another reason why open source is increasingly important.