Your Last 30 Days

August 5, 2010

When a new US President is elected there is a focus on their first 100 days in office. The process seems to be credited to Franklin D. Roosevelt who met with Congress each of those first 100 days to pass new laws and establish new programs that quickly made a difference at the time.

When managers take new jobs some also start with a specific agenda for their first 100 days. I remember reading a good list of references on the Social, Agile, and Transformation blog which is written by Isaac Sacolick.

That’s all well and good, but how about when you leave a job? How should you handle the time immediately after your resignation as your notice period starts, your last 30 days (or maybe it’s your last two weeks)?

Leaving a job is in someways more important than starting. Resignations will be more important to the people who need to carry-on their functions and yours (the responsibilities you are vacating). In leaving a role, it’s important that a proper transition occurs so that the work, and especially the people (your soon to be former colleagues), are not impacted by your departure. An organized and proper transition is not only the professional thing to do, it is also the right thing to do.

Here are some ideas on how to organize a transition during your resignation period.

  • Create a transition document: On the day of your resignation be prepared with a transition document in outline form. There is no need at this point to have anything more than an outline because what you really want to achieve is to establish a forum with your colleagues (the ones who will carry your work forward) to identify the information that is important cover. Share the outline with your manager on the first day of your resignation and with anyone else your manager feels should be part of your transition process.
  • Summarize your time at the firm with an Introduction section: Include your first day with the firm and your last. Describe your function and your responsibilities (in your own words) and summarize the major contributions that you feel are important for your successors to know about. Provide a reference to your job description, and describe any promotions you may have received, or ways in which your job or your role changed over time.
  • Highlight Key Projects: Do a look-back of your work and write summaries for key projects that you accomplished. Include references to any exhibits or project artifacts (so that people can easily find the information), people who contributed to the projects with you (including outside vendors), and any future strategies for the project work that may have been discussed at that time or afterward. If there are projects that are still in-flight, considering labeling your project descriptions as completed (referencing a date) or active.
  • Highlight Vendor Relationships and Agreements: If you were responsible for managing (or coordinating) the relationships with any outside vendors, list contact names, phone numbers, and email addresses so those relationships can be re-established after you leave (or during your transition period). Summarize the external parties (including attorneys) who may have worked on contracts and agreements with you. Provide references to contract exhibits and summarize important contract points that will help your successors manage those agreements going forward.
  • Be a good citizen, clean-up after yourself: Sure, you’ll clean your desk and throw out unneeded documents and office supplies and you’ll return equipment (such as a laptop and Blackberry), but don’t forget about your system access. Create a list of your usernames and logins, any special permissions you may have had to applications, remote access methods, entries on emergency call lists (or call trees), and access cards to remote facilities; this list will help your colleagues decommission your access when you leave. Also check your calendar for any recurring meetings you may have organized and create a list so that meeting invites can be easily reissued.
  • Summarize Strategy: If you were in a role responsible for product architecture or strategy, or responsible for an important function within the firm, then your forward looking approach and plan will be important for your successors to understand. Describe your perspective for managing the function, any initiatives you were anticipating to start, or any ideas that you were contemplating but may not have had the chance to execute. New managers will certainly bring their own ideas and approach to your former function, but they will also appreciate all the help you can provide to get them started.
  • Take care of your people: If you are a manager responsible for people, make sure your manager (and/or your Human Resources department) is aware of any ongoing activities or promises that were made to your team members. Were you mentoring someone? Was someone promised a raise, a promotion, or a title change? Provide references to any performance review documents. Highlight the good (and the not so good) work habits of your team members so that your successors will be fair to your people as the management and the leadership of the function changes to accommodate your resignation.

When you resign from a firm you in fact take-on new responsibilities; and you will leave behind a large group of people who will assess your performance. It’s your opportunity to organize your transition so that others are not adversely impacted by your individual decision.

Agile Development is not fast, it’s frequent.

July 23, 2010

The principles (and the intention) of Agile Development are often confused with the word agile which people interpret to mean fast (in the sense of being quick and doing things other than in a thorough way). Of course that is an incorrect interpretation. Agile methods are not intended to be fast, if anything Agile teaches us to be iterative, repetitive, and to break down larger problems into smaller pieces that can be more easily understood, completed with higher quality, and delivered on an expected schedule. From that perspective, Agile teaches us to be Frequent in the way we approach our work.

So Frequent may in fact be another principle of Agile Development. As a principle it doesn’t only have to apply to software development work. We can apply Frequent methods to other disciplines too.

“Reviewing performance is good; it should happen every day.”

July 9, 2010

NPR posted an interesting article on a interview with Samuel Culbert, a UCLA business professor and author of the book Get Rid of the Performance Review! You can access the NPR article here.

The article (and I would expect the book) offer some excellent perspectives on performance reviews in the workplace. Feedback on employee performance is not something that can be scheduled for once or twice a year. To be effective, and to create cohesive and high performing teams, feedback must be constant and ongoing. Managers should be observers of performance and should develop skills for understanding human nature and giving accurate and helpful feedback to enhance and improve performance.

If there is anything more insidious than a once or twice yearly performance review it is a 360-degree review process. If managers, whose job it is to be responsible for people, to provide useful feedback, and to understand human nature, don’t have the proper communications and collaboration skills to provide proper feedback, how can individuals (ie, managers and non-managers alike) contribute to a 360-degree review process in a way that is productive or even fair? It’s a rhetorical question, obviously they can’t.

I like the perspective communicated in this part of the article:

How often have you heard a manager say, “Here is what I believe,” followed by, “Now tell me, what do you think?” and actually mean it? Rarely, I would bet. Bosses seldom show that kind of respect.

That type of dialog initiated by managers is not only respectful, it’s collaborative and it also sets an important precedent in the way people work with each other at all levels inside an organization. That type of dialog is in fact cultural. And corporate cultures based on solid principles that empower and treat people fairly create the best organizations.

Playing iTunes .m4a Files on a Squeezebox2

May 30, 2010

I encountered a problem playing iTunes .m4a files on Squeezebox2 devices. It was interesting that from the same Squeezebox Server the files played fine on a Squeezebox3, but when attempting to play on a Squeezebox2 an error appeared on the Squeezebox Server’s Web interface, “Problem: Can’t open file for: <file>.m4a”. Other files, such as .mp3 filetypes, played fine.

I validated that the .m4a file existed in the music directory and there were no permission issues. To troubleshoot the problem I activated debug logging for os.files, os.paths, player.source, player.streaming, and scan.scanner and then restarted the Squeezebox Server; the logging messages were recorded in the server.log file. The problem was straightforward:

Slim::Player::TranscodingHelper::checkBin (242)   Found command: [faad] -q -w -f 1 $FILE$ | [lame] –silent -q $QUALITY$ $BITRATE$ – -
Slim::Utils::Misc::findbin (100) Looking for executable: [lame]
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/share/squeezeboxserver/Bin/i386-linux/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/share/squeezeboxserver/Bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/kerberos/bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/local/bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/local/bin/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/libexec/lame
Slim::Utils::Misc::findbin (111) Checking for lame in /usr/sbin/lame
Slim::Utils::Misc::findbin (130) Didn’t find binary for lame
Slim::Player::TranscodingHelper::checkBin (265)    couldn’t find binary for: lame
Slim::Player::TranscodingHelper::getConvertCommand2 (421) Error: Didn’t find any command matches for type: mp4

So it seems that lame is needed to stream music data from an m4a file to a Squeezebox2 device. (But lame is not used when streaming music data to a Squeezebox3. That’s interesting too.)

I needed lame for Redhat Linux, it’s an open source project maintained on SourceForge here. After downloading the source, run a ./configure, make, and make install. And that fixed the problem.

Move Messages to Folders with Outlook VBA

March 27, 2010

Let’s say your email management approach is to save important messages to a folder other than your Outlook Inbox. You might save messages from outside vendors to a folder named “Vendor Documents” or messages related to corporate policy to a “Policies” folder. Here’s an Outlook VBA macro that helps to file those messages from your Inbox in a single click:

Sub MoveToFolder(folderName)

 mailboxNameString = "Mailbox - Firstname Lastname"

 Dim olApp As New Outlook.Application
 Dim olNameSpace As Outlook.NameSpace
 Dim olCurrExplorer As Outlook.Explorer
 Dim olCurrSelection As Outlook.Selection

 Dim olDestFolder As Outlook.MAPIFolder
 Dim olCurrMailItem As MailItem
 Dim m As Integer

 Set olNameSpace = olApp.GetNamespace("MAPI")
 Set olCurrExplorer = olApp.ActiveExplorer
 Set olCurrSelection = olCurrExplorer.Selection

 Set olDestFolder = olNameSpace.Folders(mailboxNameString).Folders(folderName)

 For m = 1 To  olCurrSelection.Count
    Set olCurrMailItem = olCurrSelection.Item(m)
    Debug.Print "[" & Date & " " & Time & "] moving #" & m & _
                ": folder = " & folderName & _
                "; subject = " & olCurrMailItem.Subject & "..."
    olCurrMailItem.Move olDestFolder
 Next m

End Sub

Some customizations are necessary to make this all work for your email system. First, copy-and-paste the program to the Visual Basic Editor in Outlook (which you can open with Alt-F11). You’ll need to create a new VB Module (use the Insert->Module menu choice) to hold the macro if you don’t already have custom Outlook macros defined.

Second, the text highlighted in the blue bold font needs to be edited for the name of your Exchange mailbox; you can usually find the name of your mailbox on the left side of the Outlook window at the top, it starts with “Mailbox” like in the example above.

Third, you’ll need to add other VBA macros which call the MoveToFolder() macro with the correct folder name passed as  a parameter. For example, we might create two additional macros one each for the Vendor Documents and the Policies folders; the macro for Vendor Documents might be called MTV() and the Policies folder macro MTP():

Sub MTV()
 MoveToFolder ("Vendor Documents")
End Sub

Sub MTP()
 MoveToFolder ("Policies")
End Sub

(Note, the destination folders should already exist in your Outlook folder list.)

The last step is to assign the macros to Outlook toolbar buttons so you can move the selected messages in your Inbox to the appropriate folders with a click. If you’re managing multiple destination folders, and you created multiple macros (one for each folder), you can also create a new toolbar to organize all your MoveToFolder() macros. Here’s a Microsoft Knowledge Base article that describes how to assign Outlook VBA macros to toolbar buttons: How to Assign a Macro to a Toolbar Button.

The MoveToFolder() macro will work on a single selected message, or a group of messages selected in a sequential range (with a Shift-Click), or a non-sequential range (with Ctrl-Clicks). Also, an activity message will be written to the VBA Editor’s Immediate Window (which is opened with Ctrl-G) so you can go-back and view MoveToFolder() activity. A total win for email convenience, give it a try.

Corporate Practice

November 1, 2009

As managers we work hard at choosing the best individuals for a job. We write job descriptions, conduct searches, and choose the best people we can find (the best educated, the most experienced, the best trained) for the roles in our groups. But having the best individuals doesn’t automatically create better teams. Managers are constantly challenged with the inefficient and inferior results that develop by people working as individuals, not sharing information, and not collaborating with colleagues. Conducting work in silos ultimately hurts innovation.

Why is collaboration so hard, why is it an unnatural way of working for most individuals? Kent Beck has a perspective on the situation in his book Extreme Programming Explained: Embrace Change. As Beck views it, the influences for individual performance start with our very early academic training and the typical reward systems found in the work environment:

It’s hard to collaborate. Our whole education system is tuned to individual achievement. If you work with someone on a project, the teacher calls it cheating and punishes you. The reward systems in most companies, with individual evaluations and raises (often cast as a zero sum game), also encourages individual thinking.

(Quoted from page 152 in the first edition of the book.)

The analogy (or thought experiment) that I sometimes like to use is about a professional baseball team. In the Majors players are selected to be the best in their positions. The process of scouting players, training them through the minors, and bringing them up to the Major League teams has been very well developed over multiple decades. The players chosen for the Majors are the best and the most skilled in their individual positions; the best pitchers, catchers, fielders, etc. You can’t find better individual players than those that are chosen to play in the Major Leagues.

Yet, the manager of a baseball team requires practice. Then the question that develops is, if the players are the best and the most skilled, why is practice necessary? And the answer, which isn’t immediately obvious to many people, is that practice is necessary to make a better team. Practice is working together, collaborating, allowing a second baseman to know the throwing habits of a catcher when trying to throw-out a runner stealing base, for example. Practice is when a first baseman learns the nuances in the step of a pitcher when he is about to throw to first base. Or when a shortstop learns to cover for the second baseman who is fielding a right-side grounder. The perspective on practice and what teams do during practice is what makes a baseball manager great, what creates great teams, and ultimately what distinguishes one team from another in the Major Leagues.

If you connect with that analogy, if you find that you are dwelling on the idea more as a thought experiment, there is one last question to consider to tie it together with the corporate world: What is the analogy to “practice” in a company made-up of knowledge workers?

“Meetings” in a corporate setting are the equivalent of practice. Meetings imply collaboration because they require more than one person. Meetings are where perspective develops across teams, where information is shared and judgment is improved across individuals, where people learn the nuances in the capabilities (or limitations) of other individuals. Meetings, even if viewed as ad-hoc discussions between two individuals, are where better teams are ultimately created. And like practice in baseball, meetings are a manager’s best tool to drive collaboration, to create higher performing teams, and ultimately to develop excellence in an organization.

Note, this posting was motivated by Issac Sacolick and the Social, Agile, and Transformation Blog. See Issac’s post and the dialog that developed in the comments section for additional background:

When Ogranizational Silos Hurt Innovation

http://ctotodevelopers.blogspot.com/2009/10/when-organizational-silos-hurt.html

Communicating for Quality

October 12, 2009

While in Los Cabos, Mexico we stayed at an excellent hotel named the Hoteles Marquis. Like all memorable hotels the Marquis has a terrific location right on the Pacific coast, it’s buildings are beautifully architected, and their service is top-notch and high quality.

Decisions of location and architecture are strategic and discrete; those decisions are made upfront and you go with them through the life of the hotel’s property and business. Service, however, is different. It is obviouly hard to develop a high quality service and service is on-going, it’s something that you constantly work on.

One morning at the Marquis we were waiting around in the hotel’s outdoor lobby for a bus to take us to an ATV adventure through the Mexican desert and coast. I was having coffee at the top of a short flight of stairs that led to a stone and tile landing connecting another flight of stairs. A young man working for the hotel and sweeping the landing part caught my attention.

At first the floor didn’t appear dirty to me. He was using a wide angled broom to collect the dirt and sand into small piles that he later swept into a stand-up dust pan that had a long handle. He worked meticulously, using the longer part of the broom to clean the corners where the landing met an adjacent wall. And he worked thoroughly, sweeping each area multiple times until he was sure that part of the floor was completely clean. He was also organized and he was methodical covering every square inch. I was impressed.

For a moment I wondered how his managers at the hotel might have trained him to be such a great sweeper. They could have shown him to use the angled edge for corners and to think in patterns so he got the best coverage. Maybe his manager worked with him a few times and then periodically watches him work to make sure he’s keeping-up with the service quality standards of the hotel. But in fact I don’t think that’s the way they do it. That young man was too detailed and too passionate about the way he was going about his work. Instead I think the only direction he got from his managers was to make the floors beautiful for the hotel’s customers and guests. And the young man tirelessly dedicated himself to deliver the best quality he possibly could to his job.

Unstressing Your Life, Wirelessly and in Stereo

July 3, 2009

I bought a Jeep Liberty in 2006 and toward the very end of deciding its color and the features I wanted (and didn’t want), and almost on a whim, I asked the salesperson to throw-in the Bluetooth wireless hands-free connection. It was about a $250 option that I actually didn’t feel was necessary at the time but I like technology and gadgets and adding it didn’t break the bank. I expected that it would be a fun feature to play around with, but I wasn’t really too hopeful about its usefulness; I figured it would end-up being a novelty.

So now after more than three years of driving the car and using the Bluetooth hands-free feature I can report to you from experience that it’s a life changer (or at least for the part of the time that I spend my life in the car). With Bluetooth, Jeep/Chrysler calls it UConnect, you can setup your hands-free capable cell phone, Blackberry, iPhone, etc to automatically connect to the car whenever you turn the key. Gone are the days of untangling wired headsets while driving, searching pockets, or bags, or dashboards for your cell phone when it rings, or worrying about the police when you’re talking on the phone without a headset. You can answer a call without touching the phone, and you can make a call without having to take your eyes off the road to dial a number. (Although I’ve gotten quite good at drive-typing over the years, I think I can thumb-out about 25 words/minute on a Blackberry while steering with a knee.) Having UConnect has definitely changed my driving experience in a positive way, and I mean that with all seriousness since I cruised more than 25K miles/year on average in the Jeep so far.

I recently upgraded my original version (2G) iPhone to the latest iPhone 3GS and I connected the new iPhone to the UConnect in the Jeep and it works great, just like the old iPhone did. But the new iPhone, and really the latest version of the iPhone software, version 3.0, includes a Bluetooth capability that supports wireless stereo headsets. (The technical name of the Bluetooth stereo headset feature is called Advanced Audio Distribution Profile, usually abbreviated A2DP. It’s not proprietary to the iPhone and you might find A2DP on your whatever-model phone if you have a newer one that supports it.)

Based on my experience using Bluetooth hands-free in the car, the wireless stereo headset feature just might be one of the most underpublicized and undervalued features of the iPhone 3.0 software. To check it out I bought a low cost (about $29) Bluetooth stereo headset from Insignia; here’s a link to the model:

http://insigniaproducts.com/products/portable-audio/NS-BTHDP.html

Connecting (which the Bluetooth process calls “pairing”) the Insignia headset to the iPhone was a little tricky because you have to press a button, wait for some beep sounds, then some red and blue blinks, and enter a security code into the iPhone, but I followed the directions that came with the headset and it all worked out Ok.

So the cool thing about this now is that you get a wireless stereo headset to listen to your iPod. When I’m commuting (which is over 2 hours/day), or at the gym (which is probably less than 2 hours a week), or other times I use an iPod (listening to audio books or podcasts), it’s wireless and it’s in stereo, and just like in the car there is no more frustration with juggling/finding/untangling or yanking out wired headsets. And the audio quality is really good (especially considering it’s wireless).

Unfortunately the UConnect in my Jeep doesn’t have the right version Bluetooth to do A2DP, but wouldn’t that be awesome to play music wirelessly and in stereo in your car right from your iPhone or iPod. Or wouldn’t it be cool to stream music by Bluetooth directly from your iPod to your stereo at home. I guess that will all be coming in the future.

Although A2DP doesn’t work on an original 2G iPhone, it’s supposed to work on the standard 3G iPhone with the 3.0 software version, so if you have that model try it out.

If you’re wanting to unstress your life in a similar way, here is some more information for you. MacWorld Magazine published a thorough review of A2DP support in the iPhone software update which you can read here at this hyperlink:

http://www.macworld.com/article/141249/2009/06/iphonea2dp.html

And here’s some technical background on the A2DP Bluetooth capability:

http://en.wikipedia.org/wiki/A2DP#Advanced_Audio_Distribution_Profile_.28A2DP.29

A Creative Look at Pair Programming

March 15, 2009

I follow John Mayer the singer and songwriter on Twitter. Besides being a fan of his music, on Twitter Mayer (@johncmayer) is creative, funny, and he provides some transparency into his musical projects which are interesting. Mayer also writes the Battle Studies Mid-Action Report blog where he uploads videos and photos that are referenced in his Twitter postings.

A few days ago Mayer made a statement on Twitter, in @reply to a question from a follower, which I found intriguing. He replied:

I still write in front of a mirror.

You can view the full post, which also includes the original question here.

I was struck by the statement since, for me, it is completely counterintuitive to what you would expect the creative writing process to be. Writing is a very intellectually internal process. You typically hear of writers having a quiet workplace in the woods, or in an attic, separated from people and activity in order to create an environment to be alone with yourself and your thoughts. The process of creating words from thoughts, emotions, or feelings (whatever they may be) is usually considered to be a very individual process requiring deep introspection and contemplation achieved by developing an ability to see yourself from within.

So, I would think that writing in front of a mirror is opposite to being introspective. To me it seems as close as you can get to introducing a second person into the process without having someone else in the room. The mirror then is a tool to externalize the creative process, to forcefully move creativity outside of yourself, or possibly an attempt to see yourself as someone else in order to develop a collaborative process when there is only one person involved. That scenario is so contradictory to the way that I think about creative writing, it is so out-of-the-box and unexpected, that I frankly find it brilliant.

There is also a creative process that occurs in software development and programming. I’ve always related to the description that Fred Brooks gives of the software development process in his book The Mythical Man-Month. Brooks, referring to the book The Mind of the Maker by Dorothy Sayers who identifies creativity with three stages, the idea, the implementation, and the interaction, says:

A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author. It is realized in time and space, by pen and ink, and paper, or by wire, silicon, and ferrite. The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker.

Brooks then goes on to describe computer programming using the short phrase:

The programmer builds from pure thought-stuff.

The statement describes a computer program being built (or developed, created, written) from the thoughts (or ideas, concepts) of a single individual.

Several years ago, and together with a close colleague, we implemented the eXtreme Programming (XP) software development methodology at aluminium.com. The methodology was popularized by its author, Kent Beck, in the book eXtreme Programming Explained: Embrace Change. The premise behind XP is to take all the things that people generally consider to be good for creating quality software and to do those things to the extreme. For example, everyone generally considers testing to be directly related to quality; the more you can test a program the fewer errors it is likely to have. So in XP testing is done to the extreme by writing the tests for a program before the program is actually written. The “test first” approach, or sometimes called “test driven development,” can be viewed as being radical by someone who is used to working in a more traditional software development methodology where tests are written after the program is created.

Another principle of XP usually considered to be radical is “pair programming.” When pair programming two people sit together to write a program. In XP Explained Beck describes pair programming as follows:

Pair programming is a dialog between two people trying to simultaneously program (and analyze and design and test) and understand together how to program better. It is a conversation at many levels, assisted by and focused on a computer.

When I was first learning about XP I clearly remember having a deep and surprising reaction to the concept of pair programming: How can something as personal as writing software, transcribing my thoughts, my concepts, and my ideas, my pure thought-stuff, be shared with someone else simultaneously? How is it possible that writing a program, which can be an intimately creative process for an individual, can be accomplished by working with someone else? For programmers who haven’t done it before, the concept of pair programming can be radical, out-of-the-box, and counterintuitive, which was exactly my initial reaction to Mayer’s statement about writing in front of a mirror.

Pair programming introduces a second party into the creative process. It’s an activity that forces you to communicate, to share and verbalize your thoughts and ideas, and to collaborate in a completely different way. When pair programming, someone else, a second person, is there with you while you’re going through the activity of creative expression. Both people experience intellectual and personal benefits as a result of that collaboration and there are significant benefits to the overall quality of the product, the computer program or the software application, they produce together.

If writing in front of a mirror, as Mayer does, has a similar effect to introducing a second person into the creative process, then the mirror becomes the tool that enables Mayer to “pair program” with himself. Mayer is generally considered to be a gifted artist and it would seem that he is leveraging the pairing concept to make himself, and his art (his music), better.

Knowing that Mayer uses a mirror in the writing process makes the pair programming concept appear less radical. Perhaps when we work alone we limit the expression of our creativity to our own individual experiences. Perhaps collaboration with another person, the second person effect, is required to really broaden the possibilities of our own individual creativity. And perhaps when we pair program to create computer software the second person is really the mirror.

The Most Overlooked Feature of Twitter

February 22, 2009

Often times when someone new follows me on Twitter I’ll usually spend a few minutes going through their timeline to learn about their background and interests. I’ll also read timelines for new people I encounter in @replies or retweeted messages. In addition to a person’s timeline, I recently started reading through Favorites which, in some cases it seems, is a better way to learn about someone.

But the information you’ll find in Favorites is sort of hit-or-miss. I did a quick (and very ad hoc) survey of how Favorites are used by the people I’m following. My observations are that Twitter “celebrities” (ie, those people who have a very large follower base and generate hundreds of tweets) have a very low percentage of Favorites compared to their total tweets. Which is understandable, I guess, since tagging a tweet as a Favorite takes time and their purpose in using Twitter is most likely broad communication for marketing- or evangelizing-type purposes. The reputations of the people in the celebrity group usually proceeds them anyways, so it would seem that their Favorites would be less useful for learning more about who they are.

For the non-celebrity group, say those people with a few hundred followers and who tweet with much less frequency, I found that it’s 50-50 on whether you’ll find Favorites of any value. It seems that most people have tried Favorites as a feature but don’t keep-up with the idea. That’s too bad since I think Favorites can offer a lot of potential if used in the right way.

Twitter has developed Favorites so that it’s public; people can see your list of Favorite tweets even if they’re not logged into the service. Therefore, it’s important to think about how you’re using Favorites. Do you favorite tweets so you can remember or archive them? Have you thought about the tweets that you’re tagging as Favorites from the perspective of someone visiting your Twitter profile, and how that information might be useful to summarize your interests? Or maybe you’re not effectively using the Favorites feature and there’s really nothing meaningful for anyone to see; if that’s the case then you could be getting a lot more value out of the Twitter service by rethinking your approach.

Favorites is a much less talked about feature of Twitter but its potential, when it’s used properly, could be significant. Your Twitter Favorites can summarize your interests and can highlight to your followers and the Twitter public those ideas, concepts, and thoughts expressed through Twitter, by you and by the people you’re following, that you find meaningful and important.

Favorites are a very important part of the Twitter feature set and to leverage it you’ll need to take a little extra time to pick appropriate tweets for your Favorites list. In addition, think about linking to your Twitter Favorites page from your Website or blog so that people in your community can have a convenient way to find the information that you’ve flagged as important; I created a link to my Twitter Favorites on this blog page to make that information more accessible. And if you’re looking for ways to make Twitter more useful, improve the way you’re currently using the Favorites feature.


Follow

Get every new post delivered to your Inbox.