Time Management
Here are a few books on time management that I have found to be particularly valuable:
First Things First
I first wrote about First Things First, by Stephen Covey, in the April 1998 issue of USENIX’s ;login: magazine. I consider it to be the best conceptual exploration of the subject. Three of its most powerful messages are to:
- Distinguish between the important-but-not-urgent and the urgent-but-not-important
- Exercise integrity in the moment of choice
- Reframe the idea of Time Management into one of Life Leadership
Indeed, when you reframe time management as life leadership, you’re motivated to exercise integrity in the moment of choice, and you become able to distinguish between the important-but-not-urgent and the urgent-but-not-important. This lets you spend more time on the things that are truly the most important to you.
Here’s a great video from a Stephen Covey workshop that visually demonstrates the value of putting First Things First:
Getting Things Done (GTD)
With GTD, David Allen provides a rich, practical toolset to help you — what else — get things done. Here are some of his key points:
- Get your “open loops” (essentially, those incomplete things that you have agreed to do or are planning to do) out of your head and into your system, so that you don’t have to expend inefficient mental energy on that stuff. Free your mind to do what it does best.
- When you’re feeling stuck on a project, focus on the next action that needs to be done. This is an actual, concrete, physical task that you can do that will get you closer to your goal. Identifying the next action, even if it’s seemingly minor, can often help break up logjams.
- Develop in-context lists for where and when you are, to make optimal use of your time. For example, if you accumulate a list of calls to make and have it with you when you get into your car, you can go through a bunch of them when you’re waiting in traffic. As another example, if you just found out about a product that’s currently in beta, and probably not ready for another couple of months, have your calendar alert you 60 days from now so that your future self can follow up.
Here is a interview by Fast Company with David Allen on GTD:
Generally speaking, First Things First takes a top-down approach, and Getting Things Done takes a bottom-up approach. I find them to be highly valuable, complementary in nature, and I’ve successfully applied strategies and tactics from both. I skip the aspects of both systems that I find to be burdensome, and keep what I like. The result is a continually evolving, personalized approach that works best for me.
Type and Time Management
Speaking of personalized approaches, I think that Type and Time Management by Sharon Fitzsimmons is an excellent resource for people looking for time management tips that fit their personality. It’s also great for anyone who is coaching others. The book includes detailed interviews with several people from each of the 16 different Myers-Briggs types (I’m interviewed in the ENTP chapter); discussions of the general interactions with each personality type; a well-organized summary page for each type with specific suggestions; and a final insightful chapter on Comparisons, Contrasts, Questions and Conclusions.













Hi, this is a comment.
To delete a comment, just log in and view the post's comments. There you will have the option to edit or delete them.
Interesting. For a certain circle of folks, the Twitter handle can be a proxy for a universal identifier, and thus a useful pivot for metadata. And with automation like yours, you could come along later and change that — e.g. by adding alternate ids.
Interesting reading Kartik. How would you see your integration and crowd sourcing approach integrated with services like twist? http://twist.flaptor.com/
I think that any service that wants to associate users with areas of expertise/description could benefit. So for example, a service like Twist might be able to tell not only what topics are trending, but also what types of people are talking about those trending topics. It adds another level of metadata to the mix.
We are alike! FTF was life-changing for me. I haven’t felt a need to read Allen’s GTD — reading the 43folders.com description and the Wikipedia article were enough to get me going. I have 43 folders on my desktop and on my Palm Pre.
In spite of the optimistic view that enterprises can develop internal skills to provide their own technical support for Open Source Software packages, few actually do develop and maintain those skills. Where an enterprise lacks the internal skills to provide its own professional technical support, they need to turn to support providers just as they turned to the proprietary software developers’ support teams. The Open Source Software technical support market is consistently less expensive than comparable cost of support for proprietary products but it remains a legitimate cost that most enterprises need to budget … either in a commitment of internal resources or in a contract with an external provider. Using Open Source Software without a support plan is self-insurance with a potentially large deductible as it can be quite difficult for qualified technical support staff to suddenly get engaged and come to grips with Open Source Software integrated by the enterprise. Furthermore, enterprises need to qualify their support vendors to make sure those providers actually have team members capable of supporting mission-critical software (MySQL, Apache httpd, OpenLDAP, etc.). We agree that enterprises that become internally competent achieve the benefits you suggest but most are unwilling to make the financial commitment to sustain such a capability year on year in the face of business pressures. The technical support specialists will continue to be a valuable service pool for Open Source Software much as they are for proprietary software.
One point that I hope doesn’t get lost here is that even IT organizations that develop internal competence can contract effectively with open source technical support specialists. As I mention:
“They identify where they want to be treated as a customer, where they want to interact as a peer, and where they want to play a leadership role.”
Compared to dependent IT organizations, interdependent IT organizations can make better use of the talents of technical support specialists, since they have a deeper understanding of the value that those companies provide.
Well-put, Kartik! Marty offers a realistic, pragmatic reply. However, I’m seeing my employer dabble with the model that Kartik describes. Our Open Source & Linux Profession (OSLP) runs several development services that benefit our corporation. None of us doing this for the OSLP are IT workers, but we have had conversations with IT. Let’s say that they’re “intrigued” at this point. Could take years. Developing…
Great article Kartik. I think this is a great model. I have seen the power of open and collaborative IT development in my own experience. Unfortunately, I have also seen the difficulty in getting organizations to change their mindset and be open to this kind of approach. It can be done though, it just takes time and some level of trust building. I think the key is to just give it a shot and use small successes to pave the way forward.
[...] Open source leads to interdependent employees (as opposed to dependent or indep) http://kartiksubbarao.com/open-source-and-interdependent-it [...]
Kartik – I like the use of Covey’s model as a way of describing the effect on behaviors (or perhaps the required behaviors) of those that participate in Open Source Software development. Many of the points made here, as you suggest, apply well to the concepts of Open Innovation and may result in similar beneficial outcomes. Nice work.
Likewise, Open Innovation and Open Source share many challenges. In particular, if the decision makers sitting higher up in the food chain are not themselves interdependent, then the ability for folks in lower levels to participate in open models is significantly constrained. In my mind, a key catalyst to moving IT organizations (and others) into a more open mindset is through a top-down approach. There needs to be active encouragement, rewards, and a clear support structure (e.g. support for experimentation, failures, etc.) for folks to “participate” and embrace open principles. Otherwise, the reward system is not aligned with the model presented here and interdependence remains remains relegated to corporate statements.
Great connection to Covey! There is a growing attention in the open source field for the human factor in decision making on open source applications in enterprises. Which is good. Because it is complex to get a yes for Open Source in situations where it can add value. As an Open Innovation Ambassador I have to admit that there is lots of organisations where Open Source Application and its services suppliers network (if any) is not suitable at present.
In cases that we do have a great Open alternative to Closed Environments we have to be patient indeed. We can tell them, we can show them, they will see it, they will hear it, but in the end it is what people believe that makes the difference. Open Source has not yet come to the point that decision makers and IT directors feel backed by the currently available software, the infrastructure and services suppliers. System integration in Open Source sucks big time, if I may be so blunt. There is more. If all the worldwide available Open Source service suppliers would have to service 1% of the enterprises worldwide, we would run short on capacity quickly. It is no use blaming decision makers as long as we ourselves (the Open minded) focus only on the positive effects of Open Innovation.
But we are getting there! Let us shift our attention more towards customers concerns about Open Source. These issues go way beyond software features, staffing and hiring suppliers: e.g. Total Cost of Operation, how to sell it to the boss, smooth integration, network of suppliers, training, and … building trust.
Using open source software is becomming an industry standard, however the most basic questions remain. That is compatibility of various open source licenses, and this is a very big legal issue. Let’s take for example an IT organisation, downloaded a sourcecode with a GPL component or licensed with GNU GPL. Now to make the required innovation it requires an EPL component or licensed using Eclipse Foundation’s EPL. The innovation will not be possible since EPL and GPL are not compatible licenses, meaning that the GPL license conditions are breached and that the originator of the GPL license can sue your organisation.
It made me cry. So many dreams, so many failures, is there really a company out there that can get past the crud and collaborate successfully? If so, hire me.
[...] I Interdependent ? By brunocornec Reading the brilliant article that Kartik Subbarao wrote recently on Open Source and Interdependent IT , I was questioning myself [...]
Very interesting Kartik, as usual. And always inspiring: http://brunocornec.wordpress.com/2009/09/12/am-i-interdependent/
Well written, well developed, well presented thesis, Kartik. As some of my peers on the HP Open Source and Linux Profession leadership team (past and present) have already mentioned, this resonates with our own experience. I experienced a particular moment of recognition in reading your description of the limitations we place on ourselves by reducing all decisions to monetary ones. Many of us in business will identify with the general Catch-22 mindset that says “We can’t develop this capability for the marketplace because there’s no demand, hence, no business justification, no future revenue stream”. (The obvious Catch-22 here is there’s no market because we haven’t developed the products(s) that would helpcreate, or at least grow the market.)
I hadn’t considered the Open Source model from this point of view (interdependence) before, but like so many other ideas that weave the fabric of this development model it seems intuitively obvious in retrospect. I suppose another aspect of this I find personally appealing, if occasionally frustrating, is that it reinforces the notion that this is a marathon, not a sprint. It’s a continuum that individuals and IT organizations alike can position themselves along at any given point in time, and change only infrequently appears to happen quickly. But change is the only true constant, and it’s inevitable given sufficient time. We’re making inroads with our own IT organization that will bear fruit, and I suspect we are approaching a tipping point. I’ll keep my fingers crossed.
A good model indeed! … Looking at your Dependent-Independent-Interdependent model, it reminds me of a line… “We are taking apart each task and sending it…to whomever can do it best… and then we are reassembling all the pieces.” – from Thomas Friedman’s ‘The World is Flat’. I’m trying to related it to the “Bottom Up” approach this book talks about. Having said that, I worry how so many versions and licences of a open source software (OSS) is maintained and integrated as rightly pointed out by Ian Vernon in his comments. What’s your take on that? What should be any IT organization’s considerations (benefits and losses) before thinking about OSS as a long term strategy if not immediate? Will you agree that any big organization (already having vendor relationship) should not go for OSS in entirety but only where required as this may take some time to mature?
> Looking at your Dependent-Independent-Interdependent
> model, it reminds me of a line… “We are taking apart
> each task and sending it…to whomever can do it
> best…and then we are reassembling all the pieces.”
> – from Thomas Friedman’s “The World is Flat”. I’m
> trying to related it to the “Bottom Up” approach this
> book talks about.
Yes, I agree that Tom Friedman does an excellent job of
explaining the emerging realities and possibilities of
the flat world. In fact, this same
delegation/specialization model is very common to Unix,
Linux and many other other open source projects. Good
interfaces defined by open standards, with each component
focused on its particular job, integrated effectively
across the board.
>Will you agree that any big organization (already having
>vendor relationship) should not go for OSS in entirety
>but only where required as this may take some time to
>mature?
I don’t think that open source is an all-or-nothing
proposition, and can certainly be implemented as a phased
approach. Adopting interdependent, open ways of working
throughout the areas of people, process, technology and
business is the broader goal. That will naturally
translate into a strategy of preferring (and contributing
to) open source software, but proprietary software can be
part of the mix too, if its value is well-understood.