Here’s what I’m reading before the RETS conference this week:
The Summer of 1787: The Men Who Invented The Constitution, by David O. Stewart.
Code v2, by Lawrence Lessig.
Social Intelligence, by Daniel Goleman.
I have the privilege of running a company with 36 employees. With that privilege, I also have the responsibility (at least indirectly) of determining how much each of these fine people are paid. For anyone who hasn’t had this glorious task, let me be clear: it sucks.
First, though the competitive market for the job in question should make determining compensation easier, the reality is that there is no “market” rate for the person sitting in front of you. Everyone brings a unique set of skills and experience to the table that makes it nearly impossible to use general job category statistics. The closest you ever get to a “market rate” for any particular person is when they have an offer from another company, and that’s usually too late.
Second, things that really matter to the employee (their financial needs and wants) don’t matter to the employer. What matters to the employer is the contribution of the person. Don’t get me wrong, employees care deeply about their contribution, but the point is that the employee also has personal interests that make negotiations over compensation less than enjoyable or effective.
Third, at least in our business of software development and support, measuring contribution is nearly impossible and almost certainly futile. Lines of code, numbers of bugs, numbers of calls resolved, time of call resolution, etc., are flawed concepts. In fact, all measurements will produce what I call the bubble-wrap effect — if you push down in one spot a problem will simply pop up in a different spot. Moreover, there are plausible arguments that incentive based compensation plans actually thwart creativity. Basically, creative people get annoyed by any attempt to “lure” them into doing a better job with one carrot or another. These attempts at “management” have made Scott Adams rich.
With market forces, personal negotiation, and measurement all relatively ineffective, the end result is a gut level decision. Isn’t that great? Compensation becomes a nearly arbitrary decision specifically checked only by the employee looking elsewhere for a job. Fundamentally despising that part of my job, I studied compensation theories for the better part of three years, trying to figure out something that was fair, transparent, easy, and effective.
First, I read through books like The Great Game of Business by Jack Stack, Bringing Out the Best in People by Aubrey Daniels, and Managing Through Incentives, all of which are excellent books advocating some sort of measurement and incentive compensation system. We even tried some of the ideas for awhile, unsuccessfully. I next stumbled on this post from Joel Spolsky, which led me to the books linked above describing how incentive compensation plans are destined to fail in software companies. Having been floundering around with such plans, Joel’s analysis really made sense.
Yet, that simply left me stuck. Compensation needs to retain the employee and needs to be related to their contribution (i.e., fair). I partly solved the “retention” issue by targeting our salaries and other benefits slightly higher than what I saw as the “market” rate for each position. This worked for awhile but, over time, things can easily get out of whack as the overall market matures or shifts relative to the maturity of your own team.
To combat this and also to try to address the fairness issue, we turned FBS into an employee-owned company. What this means is that each employee of FBS who is here more than six months gets awarded FBS stock as part of their compensation package, and 100% of FBS is owned by the employee stock ownership plan (ESOP). The value of FBS’s stock is determined on an annual basis by an independent valuation firm. So, even though FBS is privately owned, we have a stock price and that stock price or valuation is a reflection of the contribution each of us makes to the company as a whole.
In other words, the stock price and share awards are our performance measurement and incentive compensation all in one. I think this plan works because the success measurement is at a high enough level that there is little risk of creating unintended consequences, and because the small size of our company gives each person an opportunity to see how their individual contributions impact the whole. Actually, we’re working on this last part right now, trying to integrate our strategic planning around the financial metrics and working them down into all levels of the organization to give everyone a better idea of how they can help improve the stock price. So, we’re still walking the tight-rope to a degree, but I feel like we have a good framework that meets the goals of transparency, ease, fairness, and effectiveness. Our stock value went up 160% last year, so something must be working.
One of the stickiest books of the year is Made to Stick by brothers Chip and Dan Heath. This book is everywhere, it seems. A great companion to that book is unstuck by Keith Yamashita and Sandra Spataro. Unstuck is a launching pad for generating new ideas and Made to Stick outlines how to communicate those ideas so they stick. Got that? Seriously, I loved both of these books and highly recommend them.
As we’ve been planning our next software release, I’ve put to use several of the ideas in unstuck, which is one of the most clever book designs I’ve seen. You can start anywhere in the book and each section will lead you to a different, though relevant, section of the book, allowing you to jump all over the place, until you’re done. It seems crazy and haphazard but it isn’t, and it’s fun. Here are some of the ideas I found useful so far:
The ideas in Made to Stick also should help us communicate some of the ideas we’ve been brainstorming for the release. The authors detail six principles for sticky ideas (SUCCESs or simple, unexpected, concrete, credible, stories), but the best bit from the book for me was the “villian” in the story, what the authors describe as the “Curse of Knowledge.”
Essentially, “[o]nce we know something, we find it hard to imagine what it was like not to know it. Our knowledge has ‘cursed’ us. And it becomes difficult for us to share our knowledge with others . . .” To illustrate this point, the authors recount the result of some research in the ’90s by Elizabeth Newton at Stanford regarding “tappers and listeners.” Basically, one person would tap out a song and the other person would listen and try to guess the song. Out of 120 tries, listeners only guessed the tune 3 times. Most interesting, though, was that before they knew the results, the people tapping out the songs predicted that the listeners would guess 50 percent of the songs. The reason is that:
“When a tapper taps, she is hearing the song in her head. . . . It’s impossible to avoid hearing the tune in your head. Meanwhile, the listeners can’t hear that tune — all they can hear is a bunch of disconnected taps, like a kind of bizarre Morse Code. . . . In the experiment, tappers are flabbergasted at how hard the listeners seem to be working to pick up the tune. Isn’t the song obvious? The tappers’ expressions, when a listener guesses “Happy Birthday to You” for the “The Star-Spangled Banner,” are priceless: How could you be so stupid? It’s hard to be a tapper. The problem is that tappers have been given knowledge (the song title) that makes it impossible for them to imagine what it’s like to lack that knowledge. When they’re tapping, they can’t imagine what it’s like for listeners to hear isolated taps rather than a song. This is the Curse of Knowledge.”
I’ve found this to be true for myself time and time again. I know what I’m trying to communicate. I’ve likely been thinking about it for years. I know the tune but I forget that no one else does. So, I’m tapping away (at the keyboard, usually) with lots of words, but I’m not doing a good enough job at communicating the core ideas. Hopefully this will change with the SUCCESs principles. 
If any of you have read either of these books, I’d love to hear your thoughts about them. If not, I encourage you to check them out, especially unstuck.
Caveat: This post might be me whining about how hard my job seems to me at times. I hope not but it might be, so either forgive me up front for that possibility or just stop reading now.
If you’re not familiar with Mitch Kapor or Chandler and are even remotely interested in software, you should check out the book Dreaming in Code, by Scott Rosenberg. Mr. Rosenberg spent a couple of years following Mitch Kapor’s largely failed efforts to build a Microsoft Outlook killer. The story is chock-full of every possible mistake a team can make in trying to release new software. And it’s not like these people were rookies. Kapor was one of the founders of Lotus 1-2-3, the revolutionary spreadsheet that helped launch Windows. Joining Kapor in his open source mission were veterans from Apple, Microsoft, and Netscape. These folks brought some serious experience to the table. But they still failed. (Well, actually, the project is on-going but floundering.)If you want all the reasons for why software is hard, order or pick up Dreaming in Code and enjoy the agony. If you want my opinion, though, here it is: Choosing is hard. Basically, that’s it in a nutshell. Designing software is about making choices. Choices about what features to include or not include. Choices about what options to include for those features or not include. Choices about data to store or not store. Choices about the user interface. Choices about the programming language, OS platform, web or distributed, etc.
The choices are nearly endless and you can pretty much rest assured that every choice will have a critic. If you choose the web, there will be those who need off-line access. If you choose AJAX, there will be programmers you hire who want to use Java or .Net. If you choose to include feature X, you’ll have others wondering why you didn’t include feature Y. If you choose both feature X and Y, you’ll have users saying the software is too hard to use.
Fear of such criticisms, however, is rarely the biggest dilemma. Rather, the biggest dilemma is the “wouldn’t it be cool if . . .” inclination of software developers. Every developer wants their software to be cool and what’s cool is making users happy. But users present an infinite number of desires and so making them happy often means cool stuff gets added, and added, and added.
This is why projects often end up late — the eyes are bigger than the stomach, at least at the beginning of the project. In the beginning, the desire is to want to solve as many user challenges as possible, so lots of stuff gets added into the initial design. Compounding this problem, however, is the fact that predicting the amount of time any single programming project will take is fraught with potential error, which gets compounded yet again when you have lots of projects into a single release. When the project inevitably takes longer than you expect, the easiest solution is to start taking away some of the features you wanted in the first instance, which merely perpetuates the cycle into the next release, where you’ll want to add the “really cool” stuff again.
Perhaps an even bigger problem, however, is that, even if you end up succeeding in adding a lot of cool features, they may not be very elegant. Instead, they could be a mess of features that work for themselves but not with each other. Adding features without creating a mess, that’s the heart of great software design. Others focus on keeping the features simple, but that’s only satisfying to users in the short run. If you want to serve your customers for a long time, sooner or later, as your systems mature, more features need to be added. So, again, adding features without creating a mess is the key to elegance.
This is all very relevant to me right now, because we’re in the throes of re-designing the two most used functions in our MLS software right now, search and search results. An MLS system contains hundreds of fields, so creating an elegant search function is not easy. In addition to the many fields, the purposes for searching are varied, too. Users may be wanting to find properties for a client, for a CMA, for statistical purposes, to evaluate their own production, and more. All of these involve finding listings but can or should they all be in one function?
Similarly, with mapping integral to the search and display function, should the search and search results functions be combined into one function? Will this one function work for consumers as well as agents, because that’s necessary, too, for IDX systems, client e-mails and other public facing features. In fact, as the lines between the private and public side of the MLS systems are blurring more every day, the design challenge for MLS systems has become even greater. Now the system needs to serve both the professional agent and the consumer, who has no time or inclination to learn the system enough to go deeper.
Our deadline is November 2007. I’m confident we’re on the path to elegance and I’m really looking forward to the coming weeks as we’re about to start discussing some of our designs with our customers to get early and continuous feedback. I’ll try to keep you posted as we make progress.
I like to read. After I finish a book (well, a non-fiction book), I usually write up a summary for future reference or publishing on our company intranet. Now that we have this blog, though, I thought it might be interesting to post some of my summaries here, too. Here’s my first:
In Founders at Work, Jessica Livingston interviews thirty “founders” of technology startups, including Steve Wozniak of Apple, Mike Lazaridis of RIM, Blake Ross of Firefox and Paul Buchheit of gmail. Though the founders were active in many different decades and covered many different disciplines, the most fascinating aspect of the book is that there are several strong themes that are common through the interviews. Summing up, success for these founders came from:
Here are some quotes I highlighted from the interviews:
Foreword by Paul Graham: “Apparently sprinters reach their highest speed right out of the blocks, and spend the rest of the race slowing down. The winners slow down the least.” p. ix.
Steve Wozniak’s advice: “First of all, try to have the highest of ethics and to be open and truthful about things, not hiding. . . . Don’t mislead people. Know in your heart that you are a good person with good goals because that will carry over to your own self-confidence and your belief in your engineering abilities. Always seek excellence: make your product better than the average person would.” p.55.
Joe Kraus of Excite! on the ups and downs of a startup: “You never know anything. The hardest part in a startup is that you wake up one morning, and you feel great about the day, and you think, ‘We’re kicking ass.” And then you wake up the next morning, and you think ‘We’re dead.’ And literally nothing’s changed.”
Dan Bricklin of Visicalc on the value of his partnership with Bob Frankston: “Bob’s much more aggressive in many ways than I am, and I’m much more conservative. So we’re very complementary. . . . It’s like having old married couples who spat all the time, always yelling at each other. . . . arguing and stuff like that — that’s just a way of testing your own understanding of things. By arguing with others . . ., that’s how you learn. And if somebody can’t take the arguments with it, then maybe they don’t really believe in what they’re talking about and they don’t understand it well enough.” p. 87.
Mitch Kapor of Lotus: “The most important thing for me is, I don’t want to work with someone who says, ‘Just help me make the business be more successful.’ I want to work with entrepeneurs who are personally passionate, committed, and believe in what they’re doing. Not all entrepreneurs are like that. Some people may be just as happy selling canned tuna . . .” p.98.
Ray Ozzie of Lotus Notes and Groove on money: “Everyone knows that one reason you go to work and do what you do is the hope that ultimately you’ll be compensated. But you don’t have to say it, and it doesn’t have to come through. . . . It should be about how you can impact the lives of users, partners, and the employees themselves. . . . The more you focus on the things that matter when you are talking to people who want to believe in you, the more they will believe in you and the more it will be a sustainable entity.” p.110.
Evan Williams of Blogger on his biggest surprise: “How far you can get on a simple idea is amazing. I have a tendency to add more and more — the ideas always get too big to implement before they even get off the ground. Simplicity is powerful.” p. 125.
Jonathon Schacther of del.icio.us on what he’d do differently: “I would have designed the back-end architecture differently, and that would have saved a lot of work now. Scaling past one machine, one database, is very challenging . . . ” p.227.
Mark Fletcher of Bloglines: “I guess my advice is: solve a problem that you have, first and foremost, and chances are, other people may have the same problem.” p.234.
Charles Geschke of Adobe on introducing technology: “[I]f you’re only focused on the market today, by the time you introduce your solution to that problem, there’ll probably be several others already entrenched. . . . Much better to figure out where the marketplace is going to be in a few years, focus on providing a solution to that, and then let the market forces catch up to you. That’s what we did with Photoshop and it turned out to be a great decision for us . . . .” p.291.
Phillip Greenspun of ArsDigita: “People don’t like to write. It’s hard. The people who were really good software engineers were usually great writers; they had tremendous ability to organize their thoughts and communicate.” p.325.
Joel Spolsky of FogCreek on what works: “The one thing we learned over 5 years is that nothing works better than just improving your product. . . . If we had taken all the effort we put into these crazy [pricing and other marketing] schemes and put it into moving our software development schedule ahead by the equivalent amount, it would have paid off much more.” p.354.
Blake Ross of Firefox on lessons learned: “One is to make sure you are always in communication with the people who are eventually going to use your product. It’s very easy to just lock yourself in a room and code all day, and you forget what the real problems are that people are having. So you have to keep talking to people and keep refining what you are doing.” p.403.
Conclusion: Highly recommended for anyone interested in technology, business, creativity, innovation, and passion.
