Hanson-Smith, Ltd.

Helping leverage technology opportunities – since 1980

Hanson-Smith, Ltd. maxims

These aphorisms reflect decades of experience dealing with curious technical and business problems. If you spend enough time in the trenches, you get to pontificate. It’s The Law.

We codified most of these ideas in the mid 1980s, as Larry and Trevor developed our philosophy of technology product design, development, and delivery. Some of these ideas were significant departures from the way business was done at the time. We prompted many “Aha!” and dropped jaw reactions.

Perhaps these ideas seem more obvious today; but not everybody has quite got the idea yet.

Reasonable people only disagree when their assumptions differ.
Unless it’s written down, it didn’t happen.
The language of the solution should match the language of the problem.
Marketing is deciding when to say “no.”

Reasonable people only disagree when their assumptions differ.

When two reasonable people disagree, it almost always reflects a difference in assumptions – given the same facts and assumptions, people WILL come to the same conclusions.

A disagreement should NOT force a choice or vote. If a reasonable minority position still makes sense, it’s dangerous to “agree to disagree” – especially about technical issues.

Rather, we need to figure out why we BELIEVE there’s a choice, and work backwards...until only one course of action makes sense, to everybody.
(This point of view is what brought Larry and Trevor together in 1978. We were arguing with a roomful of people, all arguing their own agendas and personalities. Larry and I were strangers, at opposite ends of the room. Neither one of us would give up in the search to find common ground, despite everybody else having made up their minds before the meeting. We walked away from that battle, but we won the war.)

Go to top
Unless it’s written down, it didn’t happen.

Many decisions can be made in a meeting or on a telephone call. Ten minutes later, everything is clear.

Ten days later, the details are lost, although the decisions will usually still be clear.

Ten months later, nobody has a clue. The only continuity is from a stream of actions, assumptions, and ancillary decisions that grew out of that meeting. How sad when we later discover that we forgot something important! How often this happens!

Important decisions must be documented. Even more important, the work and assumptions that led to those decisions must be documented. Technical decisions are rarely arbitrary choices between alternate paths, selected through one person’s forceful personality. We don’t make important decisions by voting (see Maxim #1). We figure it out, trying to eliminate all but one option. So it’s not enough to remember the choice; we must also remember the reasons for the choice. Otherwise, history will remember a prudent technical design as merely a compromise, political fiat, or a coin toss.

This is not an argument for bureaucracy, nor for endless paperwork. Good documentation is concise, and merely reflects the work and decisions – it must never become a substitute for the work. The bureaucrat says “My job is to write a report.” The engineer says “My job is to create a good design. A report lets me prove it and preserve it.”
Go to top
The language of the solution should match the language of the problem.

When solving a business or other real-world problem, we tend to get wrapped up in the details of the tools at hand. “When all you have is a hammer, everything looks like a nail.”

When tackling a hard problem, try to formulate an ideal solution in terms of that problem – as if perfect tools already existed. Then build those missing tools.

Users tend to describe their needs in terms of incremental improvements to their existing systems. It is hard for them (for anybody) to design a clean-sheet solution.

Time and again, describing a problem in its own terms has revealed gaps between what users are trying to do versus what engineers are able to provide.
This thinking led to the development of object-oriented technology. Today’s systems are much more suitable for modeling real-world problems than typical options of the 1970s-90s. Yet we still fall into the same trap. It’s hard to look at a business problem other than through the lens of the systems that are currently in place.

Go to top
Marketing is deciding when to say “no.”

The super sales rep never says “no” – every sale is possible. Every objection can be answered. Every barrier can be passed.

Sadly, not every sales rep is Superman. Marketing is what helps normal humans avoid wasting time on unlikely prospects, and instead invest time on good opportunities.

All the classic marketing techniques – collateral sales material, standard presentations, sales cycle design, qualification checklists, advertising, public relations, market research – all serve to find the right subset of prospects. These techniques either help the sales force find the prospects, or help the prospects find the sales force. The ideal marketing campaign makes good prospects ask for more information, yet makes poor prospects turn away in disinterest, confusion, or dismay.

Marketing is thus “statistical selling” – a numbers game that invests time on only the best chances. The experienced sales rep never wants to say “no,” but a good marketing program spells out qualification hurdles to force a “no” decision unless key requirements are met – even when the smell of money is in the air.

Go to top

Comments? Questions?

Feel free to click here to e-mail Trevor Hanson.

Go to top