There was an error in this gadget

Thursday, September 13, 2012

Cross-posted from O'Reilly Radar: Mobile developers, integration, and discovery are what count now

I wrote this guest post on O'Reilly Radar.  It's about three new battles to watch as the mobile hardware gap closes.


Tuesday, September 11, 2012

Video interview: Lessons about carrying out high-impact projects

Andy Oram, my editor at O'Reilly, did this fun interview: "Lessons about carrying out high-impact projects from author Chris Vander Mey"

He writes:

Chris Vander Mey, CEO of Scaled Recognition, and author of a new O’Reilly book, Shipping Greatness, lays out in this video some of the deep lessons he learned during his years working on some very high-impact and high-priority projects at Google and Amazon.
Chris takes a very expansive view of project management, stressing the crucial decisions and attitudes that leaders need to take at every stage from the team’s initial mission statement through the design, coding, and testing to the ultimate launch. By merging technical, organizational, and cultural issues, he unravels some of the magic that makes projects successful.
Highlights from the full video interview include:
  • Some of the projects Chris has shipped. [Discussed at the 0:30 mark]
  • How to listen to your audience while giving a presentation. [Discussed at the 1:24 mark]
  • Deadlines and launches. [Discussed at the 6:40 mark]
  • Importance of keeping team focused on user experience of launch. [Discussed at the 12:15 mark]
  • Creating an API, and its relationship to requirements and Service Oriented Architectures. [Discussed at the 15:27 mark]
  • 22:36 What integration testing can accomplish. [Discussed at the 22:36 mark]

O'Reilly Radar (

Thursday, September 6, 2012

Are you effective? How to measure your personal email signature!

If you're a manager of any kind - product, engineering, people, cats - you send email.  Lots of it.  Each email message you send is an opportunity to build your social network and product awareness. But you don't know how effective your reach is or if you should be changing your messages.

Luckily, it's really easy to measure your email traction.  Follow these three quick steps.

  1. Create a link you can measure in
  2. Add these links to your signature
  3. Measure, modify, and measure again!

1. Create a link you can measure with or Google Short Links. is typically used to create short, easy-to-share links.  But since it's a redirector, it captures that the link was clicked on and who clicked on it.  This is your measure.  It's easy to create a link - just paste it into the website and copy the funny URL you get.  See Figure 1 - that funny "" link is what you want.  Click to copy!

Fig. 1.  Create a link in
UPDATE: If you want to track multiple sources to the same point (e.g. in my case I want to know whether my Alumni group is generating more traction than my Meetup group), you need to create unique URLs.  On most sites you can append a parameter to the destination URL to make it unique.  For example, my book's URL is:
And if I want to make it unique for my Google alumni group, I just add something to the end as a "querystring parameter" - something starting with a question mark and followed by some characters.  You may need to try some different combinations, but on Amazon I just used:

2. Create a signature.

In my case, I created a clear call to action and also linked to my other presences, including this blog.  See the figure below.
Fig 2.  Create an email signature in GMail.  Or whatever.

Now, the Scaled Recognition website has Google Analytics hooked up, and Blogger (my blog hoster) has great analytics, but by creating a signature with links I can measure specific clicks from MY sent email.

3. Measure!

One of the mantras I espouse in Shipping Greatness (note the link!) comes from Lord Kelvin: "That which cannot be measured cannot be improved."  Now that you have measured, you can improve.  You'll get charts like you see below in Figure 3 (just click on Stats in  

Fig 3.  Measure!
One challenge here is that you can't do a proper A/B test in which some recipients of your email get one treatment of your signature and others get a different treatment.  That's OK - sometimes we have to settle and ship the software we have.  You can still change up your signature in a week or two and see whether your audience changes, your traffic changes, and so forth.

What you'll need to do to make this number meaningful is control for email volume.   To do this, create a search in your GMail, or Outlook or whatever, that gives you a count of the number of messages you sent.  In GMail I entered the following into the search box:
after:2012/8/30 before:2012/9/6 from:me in:sent
And from there I get a count of the number of email messages I sent.  The metric you want to drive up is the click-to-email ratio, A.K.A. "conversion."  It is simply this:

# of Clicks / # of email messages sent

Good luck!

Thursday, August 30, 2012

Steve Jobs and his use of the dysfunctional relationship

I finally read Walter Isaacson's great biography of the late Steve Jobs.  I admit, it was more fascinating than I expected, but for a different reason: I found an astounding portrayal of how dysfunction can be captivating.

Steve would routinely berate, abuse, and express great disdain for people, opinions, and ideas.  And yet, people continued to work with him and thought he was a great genius in spite of this dysfunction.  Why is that?

I think it comes down to Reinforcement (wikipedia). There are well established psychological theories of positive and negative reinforcement.  The canonical example is that a rat presses a bar and gets a food pellet.  This is a fixed-schedule reinforcement (blue FR line in the figure below).  This is what most businesspeople follow.  Work->Salary->Promotion.

What's creepy-fascinating is that if the positive reinforcement, the pellet, is delivered randomly instead of every time, the rat is FAR more likely to press the bar.  See the red "VR" line - it's a much steeper slope and a far more effective way of getting taps on the bar.  In business a "tap on the bar" might equate to submitted reports, new ideas, or checked in code.  Some argue that this phenomenon is why people stay in abusive relationships, because even though an individual is abused, there is occasional and random positive reinforcement and that relationship is much harder to leave than one in which the reinforcement is sparse but continuous.
I'd argue that Job's behavior, conscious or not, was quite similar to abusive relationships.  His abuse was constant and his praise was over-the-top and apparently random.  Sure, you could argue that his praise was nonrandom because he would praise people when they finally got the color blue right, but the reality is that nobody else could tell the differences in the shades of blue, which means the results were effectively random.

Can you use Steve's technique to drive a team to produce more and work harder?  Undoubtably.  The success of Apple is one example.  Is it evil?  Undoubtably.  And it takes a certain emotional numbness, which Steve demonstrated repeatedly, to actually pull this off.

If you're still unconvinced, consider drawing a parallel to an individual who exhibited Steve's same svengali-like appeal: H. H. Holmes, circa 1886.  Erik Larson chronicles his story in "Devil and the White City," one of my favorite reads of the year.

If you really want to understand what Jobs meant to business, don't read the book.  Instead, read Isaacson's smart article in the Harvard Business Review.

Friday, July 13, 2012

Writing great software (or anything) means managing your energy.

I've learned one big thing over the past weeks of writing Objective-C (a.k.a iOS or iPhone) code for the first time.  When you feel like the thing you're staring at should work and you don't know why, STOP WORKING!

I have a theory behind this rule.  I borrowed it from Tony Schwartz. The theory is after about 90 minutes the average human starts to lose focus and higher-level cognitive functions drift.  Most artists, developers, writers - you cats - are above average, so maybe you get two hours at the outside.  So after about two hours the extra-ordinary human loses the ability to differentiate between minute details, which is what these silly, frustrating, "why-can't-I-figure-this-blasting-thing-out" problems are all about.

The solutions to silly software problems that make developers like me crazy end up being things like:

  • I included a source file instead of a header file.
  • The index was 0 instead of 1.
  • The name of a variable was misspelled - "tacoTrock" instead of "tacoTruck".  
  • I accidentally overloaded a method name as a variable.
These are all really simple, dumb things.  Good defensive programming can help you avoid them.  For example, using a great IDE (integrated development environment) that has autocomplete and text highlighting will help you avoid spelling errors.  Never using "set" to start a method name helps avoid overloading implicit setters/getters.  Using "isFoo" for boolean variables helps you avoid getting confused by true/false states and "didFoo" is a great naming convention for callbacks/delegates.  

But these practices are not enough; even if you write perfect code with perfect style, you're gonna hit a wall.

When you hit the wall, walk away.  Over the past month or so I've tried to step away for 10-20 minutes when I hit the wall.   When I return to work I've found the answer in less than 15 minutes.  Every. Single. Time.  And when I don't step away?  I waste upwards of an hour and don't get the answer.

Every. Single. Time.

Maybe I'm insane or just far below average, but I doubt it.  Rather, I think we all have to manage our energy very carefully.  Skeptical?  Just try it - run your own experiment.  

If you're a type-A overachiever you will probably feel bad about not working during those 10-20 minutes.  I know I still struggle with these feelings.  So try saying, 

"I am running an experiment.  Good science makes for good products, so practicing this good science for two weeks is a good idea.  At the end of two weeks I will evaluate my progress.  In the meantime, I can't argue with how nice it is to walk up to the coffee shop in the sun..."
If you wonder why I'm at Verite most days between 2:30 and 4:30 it's because A) the Red Sox don't start playing until 4:15PST most days and B) I generally need that walk-to-the-coffee-shop break 2 hours after lunch!

Want to know more about managing your energy?  I wrote about it in Shipping Greatness, and you can also read Tony Schwartz's book.

Friday, May 18, 2012

A simple project management spreadsheet in Google Docs

I love Google Spreadsheets and I won't apologize because it's the single best tool for project management in the universe.  It lacks some of Excel's functionality and is somewhat harder to use, but the ability it provides groups to simultaneously edit a single data source is transcendent. That's why I use it for simple project management.

I reference the simple project management spreadsheet shown below in Shipping Greatness and discuss how to use it in some detail.   You can access and copy the spreadsheet here.  What I don't talk about is how I made it.

See, the trick with a simple project management spreadsheet is to make it automatic enough to be useful but not too automatic that it breaks or takes lots of management time.  You can see that each task in the Task Breakdown has an assignee (by globally unique email address), a target version, and time remaining.    If you expand out columns B..D you can see some of the magic...

The first bit of magic is to compute a symbolic name - "email"+"|"+"version".  This enables you to do the lookups in the "Task Allocation" through the SumIf operation.  That's a simple way to get you totals on an individual basis and identify the long pole.

The next trick is to ensure that code complete doesn't end on a Monday.  You can make your estimates of linear development days turn into linear weeks by ROUNDUP("maximum developer days"/5*7).  Apply your fudge factor here (divide by 0.6).  Use the MAX not the SUM of the team's developer days, since code complete is defined by the long pole, not the total work.

Now that you have a code complete date that might end on a sunday, make it end on a monday with a WEEKDAY function.  One such function looks like this: 


What about Test Complete? Well, testing starts either after Code Complete or after the previous Test Complete - so use a MAX function again, and apply similar weekday logic.

Finally - if you have a launch day schedule (e.g. a Patch Tuesday) you need to get a little more tricky. I'm sure there's a better way to do this, but I just created an ugly IF statement, like so:


Notice that this spreadsheet doesn't have any hard dependency checking. That would add LOTS of complexity and you can manage big dependencies in notes, in my experience.

Now that you know how this spreadsheet works, feel free to copy it and let me know if you have improvements. Look for tips on how to use it in the book!

Thursday, March 15, 2012

How not to build an error page.

This is crowdSpring's login error page.  My guess is some VIP ended up serving this, but even so - to have your login timeout and then deliver this error shows very poor attention to detail.  Don't be these guys.  Be THESE GUYS instead (keep clicking...)