August 27, 2015 § Leave a comment
A while back, I wrote about a run-in I had with a rental car company, or to put it more accurately: a rental car company’s algorithm. It’s quite frightening to think about the implications of “lights-out” algorithms making important decisions that can affect all aspects of your life. And as someone who witnesses – first hand – the often abysmal job that enterprises do when testing their APIs (which frequently have algorithms running beneath the covers), I’m particularly concerned about what this will spell for the future.
If you’d like to learn more about these possible repercussions, check out the extremely well written article by Frank Pasquale on aeon.co.
Cyberspace is no longer an escape from the ‘real world’. It is now a force governing it via algorithms: recipe-like sets of instructions to solve problems. From Google search to OkCupid matchmaking, software orders and weights hundreds of variables into clean, simple interfaces, taking us from query to solution. Complex mathematics govern such answers, but it is hidden from plain view, thanks either to secrecy imposed by law, or to complexity outsiders cannot unravel.
If you’d like to read more of my posts about Big Data, click here.
August 20, 2015 § Leave a comment
As I’ve described in other posts, there are many advantages to being a sales engineer. One of the most attractive benefits is generally being free of the politics, mind games, and brinksmanship that take place during a high-value, strategic technology sale. These are usually the domain of the sales representative, which is why they get such big commission checks – or get fired.
Unfortunately, there are circumstances where sales engineers can be dragged in to some distasteful encounters with a prospect, which usually revolve around a live session to go over deep technical aspects of the proposed product or service. I label these interactions as “ambushes”, because an unsuspecting SE often has no idea what they’re getting into until it’s too late.
I’ve been on both sides of the table in a technical sales ambush, so in this series of blog posts I’ll provide some guidance about how to avoid them, and what to do if you get caught up in one.
First, what are some of the signs that you’re about to walk into an ambush?
- You are selling a product or service that will replace an in-house solution created or maintained by people still on the prospect’s payroll, or there’s an alternate offering from another vendor that has passionate backing from some members of your prospect’s technology team.
- You’re in the mid to late stages of a sales cycle, when it appears that your solution actually has a chance of being chosen.
- The prospect has requested a live, onsite meeting at their offices. They may call it a “review session”, or a “technical deep dive”.
- The prospect has invited a large and diverse group of technically focused people to the meeting, often including someone with a title like “chief architect” or “lead engineer”.
- The prospect can’t (or won’t) provide you with a list of topics for discussion in advance. Instead, the session is billed as a “friendly, open-ended exploration to get more technical details” about your product or service. Trust me: there’s nothing “friendly” or “open-ended” about an ambush.
At first glance, none of these attributes necessarily indicate that the meeting will be an ambush. However, when you step back and look at the big picture – especially from a cynical perspective – you begin to realize that the true purpose of the encounter is to introduce fear, uncertainty, or doubt into the equation, and thereby torpedo the deal if at all possible.
I’ll write about guidelines to cope with an ambush in some upcoming posts, but for now here’s a high level list:
- Make sure the sales representative is in attendance.
- Request a list of questions in advance.
- Encourage one or more of the prospect’s business executives to observe.
- Consider bringing someone from your own engineering team.
- Don’t take the ambush personally.
July 11, 2015 Comments Off on Poshly – one of Fast Company’s 10 Most Innovative Big Data Companies – is growing
I’ve long been a fan of practical usages of Big Data: applications that aggregate raw information – and lots of it – to address real-world business challenges. I’ve already written about Poshly (disclosure: I’m an investor), and I continue to be impressed with their progress.
Poshly is expanding their team by hiring a lead front-end engineer and deployment specialist, so if you – or someone you know – is interested in joining a winning team in a hot space, I encourage you to check out these opportunities.
June 19, 2015 Comments Off on Bad Sales Engineer Behavior #2: Skepticism
As I continue my tour of seven of the worst sales engineering (SE) traits, let’s take a look at skepticism. Selling complex, high-value products and services is hard enough even when everyone on the team is upbeat and optimistic. Long hours, grueling travel, and the interpersonal challenges of coping with mercurial prospects all result in generous amounts of stress and significant sales professional turnover.
An already-difficult job is made much tougher when the sales team is burdened by friction between the sales representative and the SE. In particular, skepticism is one of the most toxic attitudes an SE can display, and it’s often one of the biggest sources of tension in the relationship.
I define skepticism as continual – and even adversarial – questioning of sales representatives by their SE colleagues, especially in the early stages of a sales cycle. SE skepticism can emerge even earlier, such as when marketing leads arrive, or on initial telesales qualification calls.
I once had an SE on my team who needed to be sold – every time – on why he should deign to deliver a demo. Unsurprisingly, this created extensive and unnecessary hostility between him and his sales partner. This SE lost sight of the basic reality that his customer was the sales representative, not the prospective client.
Don’t get me wrong: rational, unemotional evaluation of potential opportunities is essential when allocating scarce sales resources. But unless something looks really off, the SE’s job is to give 100% and be an encouraging participant as the deal moves through the funnel. If something appears troubling about the prospect or opportunity, it’s most productive for the SE to position it as a challenge that can be solved by positive, constructive teamwork.
You can learn more about sales engineering here.
May 30, 2015 Comments Off on Increased reliance on APIs demands more effective testers
It seems everywhere you look these days, someone is extolling the virtues of APIs. For example, here’s an article from Fortune that highlights how APIs are serving as competitive differentiators.
However, those enterprises that are placing such emphasis on their APIs must appreciate that they also need to invest in their testing staff with proper tooling and training. I recently wrote about this on the SmartBear blog, which you can read here.
April 28, 2015 Comments Off on Excellent article on laptop encryption
Did you know that you have very few privacy rights when you cross a border (into the US or anywhere else in the world, for that matter)? I blogged about the dangers of bringing a laptop through customs a while back. Naturally, it’s a good idea to remove any sensitive information from your laptop, especially when you’re traveling. For those situations that require you to keep important data on a computer that’s at risk of being inspected (or stolen), full-disk encryption can be a lifesaver.
Operating system vendors have been doing a great job at strengthening their products, so there’s really no excuse not to take advantage of encryption. Here’s a link to an excellent article from Micah Lee on The Intercept that explains how to do this on Windows, Mac, and Linux computers.
With step-by-step instructions, it’s one of the best written tutorials I’ve seen about this topic. It’s well worth your time to make the effort, but remember: don’t lose your password!
March 1, 2015 Comments Off on ServiceV – a superb service virtualization technology for the API and Agile era
I’ve been working with SoapUI since its earliest days, and I’m very excited about the direction that SmartBear is taking the Ready! API platform, which includes products such as SoapUI NG Pro, LoadUI NG Pro, Security, and ServiceV Pro.
At WiseClouds we deliver classes and supporting consulting services on all these exciting solutions, and we’re honored that SmartBear directly sells these courses to their clients. Many of our students go on to earn their SoapUI certification after attending these classes.
Mock services have long been one of the most useful features in SoapUI. Customers use mock services to quickly stand up virtual versions of the real services (SOAP and REST) that are in development. They can then construct their tests using these virtual services and then quickly switch over to the live services once they’re ready. Some of these enterprises have come up with really creative uses for mock services, including simulating middleware, third party APIs, telecom switches, and all sorts of other scenarios.
ServiceV represents a bold step forward for SmartBear, offering tremendous new functionality (such as assertions, datasources, and simulation for network latency and message buses – to name just a few) for creating virtual services, which are now known as Virts.
ServiceV is an idea whose time has come, for two primary reasons:
1. The rise of the API economy
It’s no secret that APIs are more essential than even before: it’s nearly impossible to go through your day without interacting with an API, whether or not you know it. They are the foundation of modern software, infrastructure, and the entire Internet. And APIs commonly invoke other APIs, which is an enormous increase in complexity.
This means that properly testing these assets is not an optional responsibility: it’s mandatory, and will continue to gain in importance. Failing to adequately test APIs can be disastrous – just read the news most days for the latest examples of outages, breakins, and other API failures.
ServiceV makes it easy to develop comprehensive tests that truly reflect the realities of the modern, API-based information-processing environment.
2. The advent of Agile delivery methodologies for software
Thanks to Agile techniques, software of all types – including APIs – is delivered much more frequently now. In many organizations, the quality assurance team is finding it nearly impossible to keep pace with the frenetic schedules driven by these practices.
ServiceV is a way for architects, developers, and operations staff to provide something for their quality assurance colleagues to use while the actual services are still being shaped and refined.
At WiseClouds, we’re so enthusiastic about what ServiceV represents that in addition to our current training and consulting solutions, we’ll be launching an exciting new Software as a Service offering that’s built upon ServiceV. If you’d like to learn more about that, be sure to subscribe to the blog and I’ll keep you posted.