Monthly Archives: April 2004

Following up on my flagged items – Part 6

(Part 5, Part 4, Part 3, Part 2, Part 1)

  • How do you persuade? I find that I’m more successful in persuading someone when I acknowledge strengths in alternatives while demonstrating a superior choice. Sometimes it may truly be the case that the only other alternatives are poor (or even non-existent); however, the more time goes by, the more alternatives become available. Superior choice may come from compelling feature sets, fantastic user experiences, exceptional service post-sale or all of the above. You cannot effectively articulate superiority, though, if you don’t know your audience (i.e. the customer). They say you don’t really know until you can teach. You can’t really persuade until you can paraphrase the need of the other. I want your long-term commitment to my products and services. A quick sell (hasty persuasion) does me little good over time. Valuable transactions like reference-based sales and forms of viral marketing never take hold. Basically, I agree with Robert Scoble‘s authority method of persuasion (i.e. I’m an authority and I’m looking out for your best interests). My point is that you have to know what my interests are before you can make this a persuasive statement.
  • I guess that I’m an edge case when it comes to screen resolution. Vibe: Today’s edge case is tomorrow’s mainstream user.
  • Paul Vick updated a good Top 10 list of application performance rules he wrote several years ago. Vibe: Rule #6: 90% of performance problems are designed in, not coded in. Paul
    responds to some criticism toward his rules, too (via Chris Anderson). Another good post on performance tuning comes from Rico Mariani: Bad Analysis Worse Than None.
  • Joel Spolsky offers Top Twelve Tips for Running a (Technical) Beta Test.
  • Harry Pierson learns that he really needs Documentum.
  • Occasionally I enjoy watching Charlie Rose’s interviews on PBS. Now I can listen to them while I work.
  • Why RSS is better than email and is more productive than the web.
  • Nine women ca’t have a baby in one month. This post from Michael Earls reminds me of the start of my software development career at a large defense contractor. Although our deliverables were all software, management often came from a hardware background. (There was significantly more hardware being built and shipped than software.) All too often, management would throw more bodies on a problem, expecting the results in 1’s and 0’s to follow widget production on an assembly line. Instead, the result was often further schedule delay and quality issues. As I recall, the business term core competency came into vogue soon thereafter, and the company slowly realized that pure software wasn’ one.
  • In another post, Michael asks a good question: Do you believe in your product? Vibe: If I believe in it, then I am passionate about it. If I am passionate about it, then I will make it happen, no matter what challenges I’m faced with. If I don’t believe in it, I’m more likely to give up on it and just let it die.
  • Thanks to Don Box for the pointer to this HyperCard eulogy. One of my first summer internships during college was to produce a graphical office/conference room locator for a five story office building using this product.

Know yourself and your development team

Recently Documentum’s VP of Platform Engineering shared his professional mantra: Execute on your strengths and manage your weaknesses. A quick search on the phrase manage your weaknesses suggests that this is a fairly common philosophy. A number of references substitute identify, develop, etc. for execute when it comes to your strengths, but the general meaning holds true.

I actually prefer develop your strengths over execute on your strengths. It’s not uncommon for me to experience someone else’s strength to the point of it becoming his or her weakness; the same has been true of the exercise of my own strengths. To me identify is too passive–what do you do after you know what they are? And to me execute borders on being too static–strengths of today can become weaknesses or assumptions or common tomorrow. Develop conveys the notion that even strengths require proper thought and action.

Don’t try to overcome your weaknesses while ignoring your strengths. It’s all too easy for your strengths to atrophy to the point of adding to the weaknesses you’re so focused upon.

Discovering Your Strengths provides an overview of the book, Now, Discover Your Strengths. Talent (strength) is defined as any recurring pattern of thought, feeling or behavior that can be productively applied. Weakness is defined as anything that gets in the way of excellent performance.

From this book’s introduction:

Most organizations are built on two flawed assumptions about people:
1. Each person can learn to be competent in almost anything.
2. Each person’s greatest room for growth is in his or her areas of greatest weakness.
. . .
These are the two assumptions that guide the world’s best managers:
1. Each person’s talents are enduring and unique.
2. Each person’s greatest room for growth is in the areas of his or her greatest strength.

A previous mentor of mine used a potluck as an analogy of these two right assumptions. First, there must be a meal (i.e. a viable product or service outcome). Second, if each participant can bring their favorite dish (i.e. exercise his or her talents or strengths) in the course of producing a meal, the event (i.e. the release of the product or service to its marketplace) will be highly successful. The challenge is inviting the right cooks to produce the meal (i.e. forming a team based on individual strengths that can produce the required product or service).

Now, discover the strengths of your team mates and give them room to thrive and Wow! you.

Update 12/1/2008: For more of my book reviews and to see what else is in my book library (i.e. just the business-related or software-related non-fiction therein), please visit my Books page.