antipaucity

fighting the lack of good ideas

use the surrender tactic: transform weakness into power – law 22 – #48laws by robert greene

Law 22

When you are weaker, never fight for honor’s sake; choose to surrender instead. Surrender gives you time to recover, time to torment and irritate your conqueror, time to wait for his power to wane. Do not give him the satisfaction of fighting and defeating you – surrender first. By turning the other cheek you infuriate and unsettle him. Make surrender a tool of power. –Robert Greene, The 48 Laws of Power (review)


Matthew 5:39

But I say to you, do not resist an evil person; but whoever slaps you on your right cheek, turn the other to him also.

what should a professional services group’s goal(s) be?

Should it be as a revenue stream? Or can it be far, far more?

Every place I have worked since getting into professional services back in early 2008 has viewed the goal of the organization as making money by performing services. Whether or not the customer was happy, something useful was delivered, whether a relationship was engendered and cultivated, and whether there were any future opportunities to do work with the given customer were at best secondary, and often viewed as completely unimportant.

I recently spoke with a company about their nascent proserve wing, and heard a view I’ve had niggling at the edges of my thoughts about how the previously-described environments fail, but couldn’t quite word myself. They view their work as enabling the customer. Proserve engineers spend as much time on this team delivering educational resources and engaging disparate teams from customers as they do actually “working”.

This company, which shall remain nameless for now, doesn’t worry about billable hours for their consultants – they worry about making sure that their customers are benefiting from the product they have purchased. Services aren’t free, but they don’t exist to “make money” – they exist to support, extend, and empower customers to use the product better in their environment. Positive side effects of this approach include bringing new techniques and applications back to the team from various places, and a low-pressure feel (though in a highly-involved and solidly-booked team) to every engagement, as much as possible.

Because the company’s goal is to assist their customers, product engineering, support, proserve, and sales are all working together as a team to get stuff done. Everyone is contributing because it’s vital to get customers happy. They’re already using some of the concepts I outlined in my advice on creating a successful support organization, but are taking them further by applying those ideas and approaches across internal structural divides to make the whole company as effective as it can be.

The organizational mindset that believes everyone is onboard to make customer experiences as good as they can be is one that needs to be adopted by every company across every team.

unsales

I am a huge believer in unsales. And not in the pharmaceutical industry sense.

Because “shipping is a feature“, and because I intensely dislike the “do it for me, then hand me the keys” mentality, I routinely follow the unsales methodology.

What is unsales? It is [almost] only selling what a customer can use today. I want to give a customer something they can both use and play with. I want to give them something at the end of any engagement that does actually accomplish something. But I don’t want to do everything for them – I want them to learn, explore, and discover their own use cases. As they discover what can be done with the tools they’ve purchased, they can start to engage in the paradigmatic shift from “automating” to “automation“. And as they explore, discover, and build, they’ll start to see where further services, training, or products can be brought in to do more.

Some people believe in the “moneyball” approach – sell everything (especially the big-ticket, high-margin products), and then let the customer more-or-less fend for themselves after some extended period of services work.

This is good for the vendor doing the selling … but only this quarter. If you sell “everything”, you have no basis to come back to the customer. You’ve developed no relationship. You’ve only “made a sale”. You’ve followed the Walmart model – sell what you can, when you can.

The better model, in my opinion, is the relational model wherein you spend time getting to know the customer’s employees: the engineers, managers, officers, etc. Get to know them personally, and become someone they can turn to as a “trusted advisor” regarding their pain points.

Relational selling (and working, for that matter) tend to lead towards long-term partnerships, engagements, repeat business, etc.

You can take the short-term view, or you can take the long-term view. One yields consistent returns, one may only ever give a single return.

Be relational.

a break from digitalia

Really enjoyed the break from digitalia this past week. I had one last year about this time, but hadn’t taken a good break before that since 2008.

No electronics. No email. No mobile phones.

It was nice 🙂

If you tried to contact me in the last week, please be patient. I’ll get back to you eventually!

play a sucker to catch a sucker – seem dumber than your mark – law 21 – #48laws by robert greene

Law 21

No one likes feeling stupider than the next person. The trick, then, if to make your victims feel smart – and not just smart, but smarter than you are. Once convinced of this, they will never suspect that you may have ulterior motives. –Robert Greene, The 48 Laws of Power (review)

there’s never enough documentation | there’s too much documentation

Documentation is vital. There’s never enough. And there’s always too much. In general, these are the areas I find documentation to fail:

Not Enough Too Much/Many
why-tos (instead of how-tos)

tutorials on things you need

architecture explanation

design philosophy “how we got here”

“why we are here”

future plans / roadmaps

deltas from standards recording

back-/cross-references to extant (even from other vendors / sources) documentation

extraneous verbiage – use terse verbosity

tutorials on things you don’t need / care about

discussion of non-core aspects of the product

how we used to do things

assumption of comprehension

plagiarism – ie, non-attribution of sources

braggadocio (not just excited) tone

different “voices” or styles

I have no quick-fixes. But I hope the above can help to address problems and help those responsible for documenting what they do to make it better. In the tech world, MSDN and developerWorks are the golden standards by which all other documentation should be compared … and to which [almost] all other documentation fails to aspire to.

the value of face-to-face

I have been working from home for nearly 5.5 years.

The benefits are myriad – not least of which is the minuscule commute and savings on fuel, eating out, etc.

Sometimes I travel for work. This accomplishes many good things – a chance to put faces to names and voices, get a chance to read faces and body language instead of just vocal tones, engage more of a customer’s engineering staff, etc.

Remote meetings (Skype, Lync, Google Hangouts, Webex, GoToMeeting, etc etc) are fantastic tools. Being able to work via VPN or other tools is amazing.

But nothing can replace the face-to-face meeting. Video calls are good, but not a full replacement. As more and more employers embrace optional and/or suggested remote work arrangements, workers can be more and more productive – with less downtime and wasted time (eg commuting).

But never let the power of remote engagement become a full replacement for the power of personal connection when in-person.