By Daniel J. Pritchett on February 5, 2010
I have been quiet on the enterprise collaboration front for the past few weeks. Lately I’ve been brushing up on public-facing web app development using PHP (and sometimes Ruby/Rails).
I’ve been blogging in quick spurts about the sort of tasks I’m putting myself through over on my Posterous mailblog.
Recent topics on the mailblog:
Posted in Sharing at Work
By Daniel J. Pritchett on January 13, 2010

Image via Wikipedia
Reward programs gone horribly wrong
I think we’ve all seen examples of reward systems leading to counterproductive behavior. My favorite example is working for a fast food joint when I was in college and having a “seventy second drive-through time” contest. Our goal was to keep the average time between customers leaving the drive-through menu (presumably having just placed an order) and customers leaving the drive through window (presumably having just received their food) below one minute and ten seconds – for an entire week. The reward for meeting this goal was a week’s vacation in Hawaii for the GM and his wife.
We had a clock above the drive through window that let us know what our average drive through time was for the day. That clock was the center of our world for a week, and we were led through some strange strategies to beat it. The eye-popping cheats my team employed to meet this goal were as follows:
- Assistant GM wearing headphones sets up an unsecured cash drawer on a makeshift table outside in front of the drive through menu. Customers placed orders with her directly and paid. She asked them to wait until she gave them the go ahead to drive forward to get their food.
- AGM receives word via her headset that the customer’s order is nearly complete and she waves them through. Customer drives over the sensor, starting the seventy second drive through clock at 0.
- Customer arrives at the window seconds later, receives the food through the window, and drives off. Total automatically measured drive through time: less than ten seconds.
- In case of an unusual order, the customer was asked to pull all the way through and wait in the front parking lot to have the order delivered when it was finished.
Why people buy in to flawed reward systems
I can only really defend #4 as sound practice for operating a drive through. If a customer’s complex order is going to slow up the rest of the business, it makes sense to pull them aside and let simpler orders keep going through. Similarly, a table for two is always quicker to get at a restaurant than a table for ten. The rest of these things were unsafe and dishonest and completely against the spirit of a program to minimize drive-through time, but I believe the GM received his trip to Hawaii all the same. The only reason the rest of us were complicit in these ill-advised plans was because we wanted to keep our jobs.
So – make sure your employees’ individual incentives are aligned with your organizational goals. If your new systems and processes (such as Enterprise 2.0) are going to require realignment of your employee’s daily work, be sure their goals and rewards are similarly recalibrated.
Current management theory on rewards and engagement
I had a conversation this morning with a coworker about career advancement in the form of promotions and raises and how (or if) they aligned with internal collaboration tools like SharePoint. I was thinking of Freakonomics when discussing this but I just got around to reading Venkatesh Rao’s review of “Drive” by Dan Pink (drive in this context appears to be mean employee engagement) and this part jumped out at me:
[W]e get a speculative list of reasons why carrots and sticks don’t work for creative work. The book calls this list the “Seven Deadly Flaws”
- They can extinguish intrinsic motivation
- They can diminish performance
- They can crush creativity
- They can crowd out good behavior
- They can encourage cheating, shortcuts, and unethical behavior
- They can become addictive
- They can foster short-term thinking
In-the-flow versus “sure we’ll get to it the day after we run out of real work”
This fits right in with the accepted idea that the way to make enterprise collaboration work is to use it “in the flow” of our everyday work rather than using it “above the flow”. In the flow means you’re actually getting your job done by using these tools as opposed to doing your job once and then going to another platform to write about it.
At the end of the year when your corporation looks over its employees’ performance and decides who’s helping the company out to the degree they need to be reinforced and who isn’t, are your reward systems structured to account for team-wide successes or individual stars? It is easy enough to compare one person’s productivity against another’s as long as you are only measuring their direct outputs and not those of the people they work with and facilitate on a daily basis. If you want your collaborative systems to succeed, be sure employees are incentivized to share rather than hoard.
Related articles by Zemanta
Posted in Sharing at Work | Tagged business, Collaboration, Company, Creativity, Employee engagement, Employment, Freakonomics, Microsoft SharePoint, Motivation, Venkatesh Rao
By Daniel J. Pritchett on November 13, 2009

@BlakePalmer presenting for @Lunaweb at last year's BarCamp Memphis
The second annual BarCamp Memphis is finally here!
Tomorrow I’ll be heading to the MASE building to listen in to soome good presentations, panels, and wide-open discussions (“core conversations”) about technology development, new media, and entrepreneurship.
- “Social Tools in the Enterprise” with Ryan Hinricher. Ryan and I are going to get into the how and why of using collaborative software to improve team work. Ryan’s perspective is that of a realtor using SaaS tools like Salesforce and Basecamp to connect with his associates across the country. Mine is that of an enterprise software developer using collaboration platforms such as SharePoint and Jive to work with local teammates and with our branch offices.
- “It’s a Small URL After All” with Bob Hazlett. Bob and I walk through the arguments for and installation of a personalized URL shortening service of your very own using Yourls.

@skippytpe Macbooking at the barbecue lunch during BarCamp Memphis 2008
I’ve also got a few presentation ideas in mind for optional afternoon sessions if I can drum up some interest. I’d be happy to review several of my recent blog topics in a discussion format, such as
Check out the full list of scheduled BarCamp Memphis topics. Any topics you want to lead or suggest for discussion can be written on the flip chart tomorrow morning and voted on by your fellow attendees. Proposals with the most votes will be slotted in for afternoon sessions! See you there!
Related articles by Zemanta
Posted in Sharing at Work | Tagged barcamp, Bob Hazlett, Collaborative software, enterprise, Enterprise social software, Google Wave, Jive, lunaweb, Microsoft SharePoint, ruby, ruby on rails, Ryan Hinricher, software as a service
By Daniel J. Pritchett on November 11, 2009

David Heinemeier Hansson, creator of Ruby on Rails
Digging deeper into Rails programming styles
The last Sharing at Work post showed how to set up a Rails development environment using a Ubuntu Linux virtual machine. This week, I’m in the midst of developing my first ground-up public-facing web application using Ruby on Rails.
Learning a new way to dynamically generate HTML
My Rails development has already been aided in several places by kind folks in the #rubyonrails IRC channel on Freenode. One interesting thing they’ve directed me to is an alternate templating language called Haml. Rails uses something called “embedded Ruby” by default – .erb files that describe HTML output with some necessary Ruby interwoven to generate the dynamic parts of a page. haml does much the same but it takes a minimalist approach to syntax.
Nesting is handled by indentation (two spaces per level of nesting). Tags are not closed, the closer is simply inferred by the order in which they are used and the associated indentation.
To illustrate the goodness of haml I’ve borrowed some code snippets from a longer article on Hhaml at Rail Spikes.
Embedded Ruby example; 20 lines and 547 bytes:
This shows a stock offering div containing a name, a symbol, a the latest price and date of the latest trade, and some dynamically generated links to buy and sell the stock in question.
The same code using Haml; 13 lines and 365 bytes:
Click through to the original Sharing at Work post if these code snippets aren’t showing up on your screen.
What’s Haml doing for us?
You can see right away that the Haml code provides a lot less for the developer to read through and its appearance nicely dovetails with the CSS models we use to do page layout. To quote the Rail Spikes article linked above, “Hampton says he came up with Haml by starting with a fragment like this and seeing what he could take out without losing anything. I’ll follow his example.” I like it and I’m going to try to use this throughout my project. Maybe it will be useful to you too.
In the next post I’ll share what I’ve learned from Rails. Consumer web app development seems to be evolving faster than the SAP/Business Objects toolset I’ve been using at work.
Posted in Sharing at Work | Tagged Business Objects, Cascading Style Sheets, erb, haml, HTML, Languages, Page layout, programming, ruby, ruby on rails, SAP, Web application