Sometimes you just have to roll up your sleeves, and get dirty

Have you ever found yourself wishing there was an easier way to do something? Or wishing someone would just do their job and make that tool that would make your job easier?

Some time ago I found myself needing to perform the complex calculations of link budgets for satellite systems. There were no commercial programs available and satellite operators were just providing a hard copy output of their proprietary link budget tools. I needed a way to give customers a budgetary estimate of satellite link parameters without engaging a satellite operator with their long lead times.

So I wrote my own link budget calculator using Microsoft Excel. It wasn’t easy and it took a long time. I used reference formulas from my various satellite communications text books. I double checked its results with the few hard copies I had from satellite operators. After a lot of hard work using Visual Basic, complex array formulas and multiple iterations, I ended up with something usable and accurate. It still required parameters specific to the satellite in question but sometimes these could be guesstimated closely enough and sometimes these could be obtained from the satellite operator or from previous link budgets on file. In the end I had a tool that my team could use to get within the ballpark of proper antenna sizes and amplifier requirements for a workable satellite link using our products.

Today, with overloaded Engineering and Product Management teams, I pitch in, develop tools and share them with my team to make the job easier. These challenges have enhanced my skills in software development significantly. Here are a few examples:

requirements gap analysis

DVB-S/S2 calculator

product operation: DIP switch position tool

We’re all busy and we all have priorities vying for our time.Next time you find yourself wishing for a tool, spend a bit of your spare time, even after hours time, developing the tool yourself. There are so many benefits: you’ll save yourself time in the future, enhance your skills, get satisfaction and maybe even generate a little appreciation and admiration from your peers.

The Latte Huddle—leadership with socialized efficiency

Methods to improve productivity, innovation and morale are continually sought by high performing companies. Sometimes enterprising employees are forthcoming with ideas to enhance one or more of these. More frequently, a company hires a management consulting firm, they inform about industry best practices or new trends, and these methods are implemented internally.

One method of promoting productivity and innovation is enabling “water cooler” discussions. Incidental encounters of personnel from different departments can lead to innovative discussions and foster team building. Additionally it may lead to problem solving solutions not otherwise possible with the limited interaction scope of colleagues who normally work together. Steve Jobs obsessed about office layout attempting as much as possible to enable these “serendipitous encounters“. He made overt design choices, such as bathroom placement, to maximize personnel cross-pollination.

Another method, the “morning huddle“, or “stand-up meeting”, really gained popularity a few years ago. Some companies took it very seriously and instituted it across the board. Like many popular management styles, such trends are not typically new ideas—usually they are merely rediscovered concepts perhaps applied to a different sector of industry. So it is with the huddle. Its origins may stem from Scrum or some other agile development practice. Despite having origins decades ago, it exploded into popularity a couple of years ago, was widely implemented but seems to have quickly diminished in popularity over the past few years.

The waning of its popularity is a shame. There is a lot of value in having these concise, small group meetings in any high productivity multifaceted organization. They serve to align priorities, bubble up problems for immediate action, promote communications and enhance team building. The key is to keep them efficient. Take lengthy subjects offline and always focus on just two or three key elements for the huddle, e.g. brief summary of tasks for the day, identify obstacles, communicate priorities, socialize corporate vision/strategy.

I instituted daily huddles with my Sales Engineering group when it was entirely located at one physical location, headquarters in Ottawa. Since then I have successfully diversified my team into a globally based, in-region team which has necessitated a change in how I effect group leadership. Back in the heyday of headquarter-centric Sales Engineering, I conducted a daily mid-morning huddle but…

I took a slightly different tack—I conducted these while to–ing and fro–ing a local Starbucks. We took turns buying the lattes. These huddles were short and effective. They served to align priorities and address concerns before they became unmanageable. Hosting them off-site, in the privacy of a vehicle, encouraged open frank discussions without fear of being overheard.

The whole daily ritual took no more than twenty minutes. It was very sociable and highly effective. However, it raised a new problem that required an inventive solution: how to determine who’s turn it is to pay for the lattes! A long time ago, when my group was just two of us, it was relatively easy to remember. When I hired a third member into my group, it quickly became a challenge to remember the order of who previously paid so as to ascertain who’s turn it was to pay at the present huddle.

Necessity being the mother of invention, we put our heads together and came up with a unique solution to this problem. We applied our engineering expertise and acumen to the problem and devised a web application to track who paid when.

After burning the midnight oil a few times, the web server and application was up and running. With access from our ubiquitous smart phones, we were able to start logging who paid for the lattes. It also automatically calculated who had paid the least overall and suggested that individual user as the next one to pay.

I learned a lot about web servers, SQL databases, HTML5 and PHP as result of this hands-on development experience. I even made a native Blackberry 10 mobile app to access it.

The Latte Huddle—simple, social, geeky and effective. Consider adding one to your leadership regimen. You’ll be amazed how adding the element of relationship building to an efficient work-related huddle yields employee effectiveness.

Systems Engineering in a COTS world

Systems Engineering plays an extremely important role in the complex process of solution selling. For vendors and customers alike, anytime a product based solution is brought to market, the vendor must employ sound Systems Engineering practices to ensure commercial success.

Here’s a simplified view of how this process works.
Many customers are looking for solutions that don’t require customization in order to effectively address their business needs. Some customers are capable of using their own (or outsourced) resources to augment an existing solution and customize it to their particular workflow or challenge. Others simply don’t have the budget to do this and they are seeking solutions that closely fulfill their requirements.

In a government procurement process, this is known as commercial off-the-shelf (COTS). The concept is directly applicable to the commercial industry as well. Here the key is to design a solution that meets the critical needs for the bulk of the potential customers in the total addressable market (TAM).

Starting at the product or solution conceptual stage, Product Management uses a broad range of inputs and collaboration to generate a product plan. The product plan needs to ensure that the solution fulfills the needs identified in the market within the scope of development budget and a host of other constraints. Along the path to success, a further collaboration of Sales Engineering, Marketing, Sales and Product Management devises the details of the sales strategy. This sales strategy, for complex solution sales, needs to focus on Consultative Selling.

In defining the Consultative Selling strategy, it’s important to focus on the customer’s actual business problem. Naturally customers understand their business needs and problems, but frequently the root causes of the business problem may not be apparent to the customer. The Consultative Selling process aims to uncover the real sources of the customer’s business needs.

There’s an apocryphal quote attributed to Henry Ford that says, “If I had asked people what they wanted, they would have said a faster horse.” The provenance may not be historically accurate, but it’s an apt illustration of the concept of Consultative Selling—and that’s where the value of Systems Engineering really shines in a commercial organization selling COTS solutions.

Now the need for Systems Engineering becomes apparent. The Systems Engineer, (often known as the Sales Engineer), needs to find creative ways of identifying customers’ core business problems. The Systems Engineer then identifies which of the customer’s core business problems are specifically addressed by the value proposition of the solution offering. Further analysis by the Systems Engineer will uncover the gaps between the customer’s needs and the solution’s specification. The difference between what the solution does and what the market needs is known as Product gap. When evaluating this on a case-by-case basis for a particular customer, I refer to this simply as a gap analysis.

The Systems Engineer must apply Consultative Selling to uncover the customer’s needs, perform a gap analysis to identify any short-comings with the solution offering, and finally apply creativity to minimize or eliminate the gap. It’s harder than it sounds and requires an astute and insightful approach. Frequently, it requires addition of third-party products to make the solution comprehensive and ensure that it addresses the salient business needs uncovered by the Consultative Selling process.

Experienced Systems Engineering methodology is key to the managing this process for the success of commercial organizations. Ensure that your Sales Engineering team is well-versed on the Consultative Selling methods and employs sound Systems Engineering practices—this will help to ensure success.

(This article was posted in INCOSE Canada’s TechTalk)

Wreck Diving: a Sales Engineering analogy

As an avid scuba diver, I enjoy diving on shipwrecks. I have found that the skills I employ for Sales Engineering overlap with those used for wreck diving.

Scuba diving is a passion of mine. The name of this blog, “Decompression Stop”, is a technical diving term.

In Ontario we have the best shipwrecks in the world. A rich maritime history and a propensity for severe weather combine to yield a prolific shipwreck record that estimates hold is in excess of 6,000. The highly anaerobic environment of our huge fresh water lakes help to preserve wooden and steel shipwrecks that can be more than 100 years old.

Wreck diving requires discipline. You must remain cool, calm and collected. You must be prepared for disorienting events such as “silt out” that can cause sudden, complete loss of visibility.  Frequently, wrecks are located in areas of strong current which adds to the strain of the dive. Special training is recommended and, at the very least, diving with others who already have wreck diving experience is a must.

Similarly with Sales Engineering, before you plunge into the abyss of consultative selling, the Sales Engineer (SE) needs specific training and experience. Additionally, in order for the SE to navigate the quagmire of the solution selling process, the SE needs to be prepared for the unexpected.

.
Customers are increasingly savvy about their business needs. The SE must plan to address detailed questions about the value proposition of the offered solution and how it specifically applies to the unique business case of the particular client being addressed.

Equally the SE needs to recognize when they’re in too deep and that proceeding without further research would only damage the customer relationship. In this case, the SE should acknowledge this to the customer and offer to do more research offline and to subsequently get back to the customer with the relevant information.

Armed with appropriate training and experience, Sales Engineers can successfully employ consultative selling techniques. Increasingly this method of selling is enabling companies that offer comprehensive and complex solutions, to connect with their customers in a valuable way that is apparent and relevant to the customer’s business needs. If along the way you manage to have a little fun, then good for you—you must be getting the hang of it.

                 navigating the quagmire

Group motorcycle trip: a Systems Engineering analogy

A big part of my Sales Engineering experience is classical Systems Engineering. Frequently, when seeking a solution for a customer’s business case, a Sales Engineer needs to go beyond the company’s product portfolio and draw on third party products.

It turns out that the skills we use to pull off a major group motorcycle trip draw on our experience in Systems and Sales Engineering (and vice versa). Let me explain.

.

I’ve completed two epic motorcycle trips with my colleagues and Sales Engineering veterans, Walter and Jerry. In July, 2014 we did our second trek—4,200 km around Lake Superior over nine days. We went clockwise around the lake to maximize our chance for great views en route.

Miner’s Castle Rock, Michigan

.
Trip planning is always a delicate exercise employing the judicious use of advanced interpersonal skills as we negotiate where we should stay and what we should see. In this I utilized my Sales Engineering experience to ensure that top must-see destinations were strategically incorporated as way-points in our GPS units.

We stayed in lakeside cabins and these quaint quarters had us jostling for space to spread out our huge assortment of motorcycle paraphernalia. You need to understand what irritates a particular person and work around that to avoid conflict. I won’t lie—not all conflict was avoided but we all came out of it happy. Conflict resolution is a science and an art.

And so the trip progressed with long days of riding and short stops for quick sight-seeing.

Ouimet Canyon, Ontario

When you do this…

with characters like these…

and you do it right…
you end up at cool places like this:

In Systems Engineering, you need to know the ins and outs of each piece of equipment in the solution you’re designing in order for it to be viable. You also need to listen, know when to step up and when to back down. So too with group motorcycle trips—understanding your companion colleagues and what makes them tick is key. Only then will you be able to pull off an amazingly successful and super fun career—and maybe even the occasional epic trip.

DIY motorcycle starter valve sync: a Sales Engineering analogy

I have found similarities between Sales Engineering and other activities that on the surface are seemingly unrelated. In this series of Sales Engineering Analogies I’ll explore some connections I’ve made between my Sales Engineering career and other activities in my life.

I’ve been suffering from the reasonably well documented surging problem with my 6^th gen 2006 Honda VFR800 Interceptor. At small throttle openings, the bike was surging. In neutral, I could not get it hold any steady RPM in the 2K-3.5K range. My research convinced me that my surging problem could be somewhat reduced, if not eliminated, by synchronizing the Starter Valves.

This would prove to be a large effort. Details on the construction of the DIY differential 4-way manometer etc. can be found here.

First things first – I tore apart the top of the engine area and took apart the air box for the first time since taking ownership of this slightly used VFR only two months earlier. Well imagine my surprise when I found this on top of my air filter:

.
.
It looks like a mouse made a nest in the top of my air box, probably during a winter when the previous owner winterized and stored it himself.
.
.

.
.
.
.
.
.
After cleaning the air filter, I rigged up my jig next to the bike.
.
.
.
.
.
.

.
.
I disconnected the 5-way vacuum connector and connected up the jig’s manometer lines to the starer valves on the throttle bodies.
.
.
.

.
.
.
.
.
The initial readings were way off clearly demonstrating that the Starter Valves were not well synchronized.:
.
.
.
.
.
.
I then proceeded to start synchronizing the Starter Valves. Because this is a differential manometer, changing one Starter Valve basically affects all the others. The Starter Valve adjustment nuts are sensitive – just gently pushing on the set screw nut sends the manometer readings soaring – so you want to be sure they’re getting re-seated in their natural resting spot by blipping the throttle before making further adjustments. More details can be found here.

.
.
Eventually you get a feel for this and ultimately I got them to line up something like this.
.

Conclusion (test ride time):

There is an unbelievable difference with the bike now. It’s like a completely new machine. Let me tell you that the small throttle opening surging problem is all but gone. I can coast down to idle in first gear without surging nor does the bike sound like it wants to stall. I can then roll on the throttle again with smooth response.

This servicing was worth every minute of time it took in preparation and execution. I find it’s the same with Sales Engineering. You only get out of it, what you put into it. Cut corners and you can expect problems down the road. Do your due diligence on requirements and gap analysis and you’ll be rewarded with a happy customer.

I was awarded a patent… but for what?

In April, 2014, I was awarded my first US Patent. It’s a goal of most engineers, to discover or invent something worthy of a patent. I was pleased to achieve this when the US patent authority issued US 8,707,370 to me.

The minute details are here.  It’s written in patent-speak and a tough slog even for me, so allow me to translate and tell you what this is for and why it matters.

How it works

Most of us have received TV in one or both of the two conventional ways: cable or satellite. Many of us have a choice in provider – albeit a limited choice. But what if you live in a condominium like my beloved parents?  As a condo tenant you’re usually not allowed to mount unsightly satellite antennas on your balcony railing. Instead, Multiple Dwelling Units (MDUs) are typically pre-wired for cable TV. This leaves the tenant with no choice for their TV provider other than to subscribe to the cable routed into their apartment.

Increasingly newer developments and renovated MDU complexes are being fitted with Ethernet networks—the wiring with connectors that look like over-sized telephone jacks.

This enables a new type of TV service provider option – IPTV. Bell’s relatively new Fibe-TV offering uses IPTV technology and is already available to many urban homes. Thus a typical urban home now has three mainstream choices to receive TV: cable, satellite, and IPTV.

Back to MDUs. If an MDU has been retrofitted with Ethernet cabling, a new localized IPTV service may be deployed in the MDU by utilizing a multi-service satellite receive solution called a satellite Gateway.  The Gateway translates the satellite TV services into IPTV services and forwards these onto the local MDU Local Area Network (LAN).  In the tenants’ apartments, the IPTV services are readily accessed using authorized receivers, Set Top Boxes (STBs).

Here’s an example:
The Gateway in this case is housed in an equipment room near the roof of the MDU for convenient proximity to a satellite antenna. The Gateway receives all the TV services available from a particular satellite TV provider such as the Bell TV or the Shaw Direct services. The Gateway converts all the services into a format suitable for broadcast on the Ethernet network in the MDU (basically by wrapping up the satellite services into multicast IP streams).

Tenant apartments would have a TV and a Set Top Box (STB) with remote control. The STB can receive all the services on the Ethernet network as made available by the Gateway. All a tenant needs to do is contact the service provider and subscribe to an appropriate TV package. The service provider then authorizes that tenant’s STB for the subscribed services.

The beauty here is that the service provider can use all the same back-office applications and procedures (billing, conditional access) for this new subscriber as they do for their regular satellite subscribers since the encryption of the services is passed through the Gateway all the way to the STBs.

The Patented Part

So where does my patent fit into all of this? Well needless to say there are a lot of technical things going on in this system to make it all work. In all this complexity is the need for the Gateway to make known to the STBs exactly what services are available and how to access them in the Ethernet network. This traditionally has involved the use of complex protocols of communications between all the STBs and the Gateway. Since there are frequently many different equipment manufacturers involved in the deployment of such a system, each vendor needs to implement these protocols and since they are complex, it takes a lot of time and money.

This is where my patent comes in. The patent defines a simple method for the Gateway to tell the STBs how to access the services on the Ethernet network. Since it is simple, it is easy for all the equipment manufacturers to implement. Ease of implementation lowers the barriers-to-entry for manufacturers and this translates into lower costs for the equipment and a quicker time to market for the whole service.

In one ideal business model, STB manufacturers would pay a license fee to the assignee of my patent, International Datacasting Corporation (IDC), for the right to implement the patented protocol in their equipment in order to be compatible with IDC’s Gateway product.

And there you have it—an explanation of my patent and how it can be used to bring more choice to consumers and more efficient solutions to service providers.