A call to GTD practitioners: An invitation to share your top questions, tips, and insights

Over the last year or so I've had the pleasure of receiving email and phone inquiries from people having various challenges implementing David Allen's Getting Things Done methodology [1]. Along the way I've been collecting the frequent questions, tips, and insights that have come up, with the goal of continuing to share them [2] with others adopting the system.

This collection seems to be reaching a tipping point, and as part of a new project I'm soliciting your favorite "aha," insight, or question that most dogged you before you made the system click. I'll be sharing the results (with surprises and answers, of course!) in a future work, and I'd be very grateful for your input.

So how about it? What information wasn't clear from reading the book, but helped you the most? Was it dealing with too many next actions? A tool or gadget that you found crucial? Maybe blocking time for the "heavy lifting?" Or was there something that just didn't make sense to you?

I'd love to hear what you have to say. Please leave a comment below or send your wisdom to gtdtips@matthewcornell.org, and stay tuned for the results. Cheers!


References

• [1] I am not associated with The David Allen Company in any way, and I don't use copyrighted materials in my business. Additionally, all my knowledge has been gained the hard way - reading, studying many competing systems, applying it to different domains, teaching, and collaborating. The overall strategy: Pour ideas into head, try out, wait for synthesis to create something new. Then share!
  
• [2] Some GTD-related articles you might find useful:
  • Are daily to-do lists and GTD compatible?
    
  • Best practices for GTD and administrative assistants
    
  • Dealing with Meeting Notes - GTD to the Rescue!
    
  • Dealing with multiple/dependent next actions in GTD
    
  • Depressurize your email with a 24 hour response time
    
  • Four Planner Hacks for Paper-Based Productivity | D*I*Y Planner
    
  • GTD Workflow Assessment/Tips Checklist
    
  • Organizing Electronic Documents GTD-Style?
    
  • Reading Books The GTD Way
    
  • Some GTD warning signs
    
  • Some answers to "Should I keep it?" when filing
    
  • Some common GTD questions, with answers
    
  • What are the essential habits of GTD?
    
  • What's in a name - GTD project naming conventions
    
  • What's your maximum response time?
    
  • When inputs exceed your workflow system's capacity
    
  • Why every problem should be a GTD project
    
  • Plus a few fun ones: A GTD WorkFlow tool: The five stages on a business card cube and Personal Productivity Playing Cards!
    
  
  

An invitation to share your top GTD questions, tips, and insights

Over the last few years I've been collecting bits of wisdom for people implementing David Allen's Getting Things Done: The Art of Stress-Free Productivity, with the goal of continuing to share them with others adopting the method.

This collection seems to be reaching a tipping point, and as part of a new project I'd love to hear your favorite "aha," insight, or question that most dogged you before you made the system click. I'll be sharing the results (with surprises and answers, of course!) in a future work, and I'd be very grateful for your input.

So how about it? What information wasn't clear from reading the book, but helped you the most? Was it dealing with too many next actions? A tool or gadget that you found crucial? Maybe blocking time for the "heavy lifting?" Or is there something that just doesn't make sense to you?

Please send your wisdom to gtdtips@matthewcornell.org, and stay tuned for the results. Cheers!

A few highlights from "My job went to India"

In my previous post (Productivity for Programmers, #2: Efficient vs. Effective) I gushed about Chad Fowler's book My Job Went to India: And All I Got Was This Lousy Book.

As I said earlier, I wish I had read this book as a programmer years ago. Why? Not because it's about coding (it's not), but because it addresses how to think about being valuable to your organization. Yes, it's set in the context of the current outsourcing/offshoring issue, but it's a good read for everyone, esp. as more jobs than programming are moving to India.

As promised, here here are a few of my favorite ideas from it. Highly recommended!

• 3. Lead or Bleed?: I haven't been given the opportunity...? Seize the opportunity!
  
• 4. Invest in Your Intelligence
  
• 5. Be a Generalist: Generalists are rare ... and, therefore, precious.
  
• 7. Don't Put All Your Eggs in Someone Else's Basket, which talks about the "professional services barrier" (more on this later).
  
• 8. Be the Worst:
  • be the worst guy in every band you're in. a) you fit in, b) your playing gets transformed. works in the downward direction too!
    
  • The people around you affect your own performance. Choose your crowd wisely.
• 9. Love It or Leave It:
  
  • You have to be passionate about your work if you want to be great at your work.
    
  • Work because you couldn't not work.
• 12. Find a Mentor
  
• 13. Be a Mentor: To find out if you really know something, try teaching it to someone else. Also, mentors tend not to get laid off.
  
• 21. Remember Who You Work For: Your manager's successes are your successes. Solve your manager's problems.
  
• 24. How Much Are You Worth? Ask "Was I worth it today?"
  
• 28. Learn How to Fail:
  • Every wrong note is but one step away from a right one.
    
  • Stressful times offer the best opportunities to build loyalty.
    
  • A craftsperson is really put to the test when the errors arise. learning to deal with mistakes is a skill that is both highly valuable and difficult to teach.
    
  • Rules: 1) Raise the issue as early as you know about it. 2) Take the blame. 3) Offer a solution. 4) Ask for help.
• 33. Me Rite Reel Nice: You are what you can explain.
  
• 35. Suit Speak: Market your accomplishments in the language of your business, and always have your elevator speech ready, just in case. Answer: "What are you working on?" and "What is the benefit of that?"
  
• 36. Change the World: Have a mission. Make sure people know it.
  
• 37. Let Your Voice Be Heard. With respect to the musician metaphor:
  • The best saxophonist doesn't always get the gig.
    
  • Who you've played with is at least as important as how well you play; musicians are cool by association.
    
  • Sometimes, the better musicians are overlooked for work because everyone assumes they won't be available or because they are too intimidated to ask.
    
  • Music works via a network effect. If your social/music network terminates before reaching someone, it's not likely you'll ever be asked to perform with that person until an intermediary connection is made.
• 38. Build Your Brand: Your name is your brand, and Google never forgets (don't be a jerk).
  
• 42. Already Obsolete: Your shiny new skills are already obsolete. Investigate the bleeding edge.
  
• 43. You've Already Lost Your Job: You are not your job.
  
• 44. Path with No Destination:
  • Focus on doing, not on being done.
    
  • Bad processes create bad products.
    
  • It's how you traverse the path that's important - not the destination.
• 46. Watch the Market: Watch the alpha geeks, and try to be one, or at least "make the hang" with one. (Applies to research as well?)
  
• 47. That Fat Man in the Mirror: Developer, review thyself; do a 360 review: ask trusted people for feedback, using 10 characteristics you feel are important, get constructive info.
  
• 52. Think Global: If I have to depend on someone...I'm going to have better luck if that person feels that I respect them.

Productivity for Programmers, #2: Efficient vs. Effective

Bob Walsh and I are writing a series on Productivity for Programmers, which started with his article Productivity for Programmers, #1: Trusted Systems. In it he identified five trusted systems every programmer should have: Tasks, Decisions, Version Control, Code Snippets, and Bugs. I like Bob's break down (no, not the psychological one resulting from writing "Clear Blogging" - different story), so I want to talk about a related characteristic - Efficiency vs. Effectiveness.


Efficiency

The trusted systems are important, and they are about doing things right, what Drucker called "efficiency" (see David J. Anderson's article Drucker on Effectiveness for a bit more).

In this sense, doing things right means not making people (or yourself) angry because something bad and preventable happened. This is like the The Joel Test applied - You use a source control system (otherwise you could loose your precious baby), you have nightly builds (otherwise you won't know you've broken the build until much later), you have unit tests (otherwise you won't know you've hosed something accidentally), etc.

Similarly for actions/commitments - you should use something like Getting Things Done (otherwise you won't know what you should be working on, and something will fall through the cracks).

Also, your actions/commitments tracking should be integrated with your code-writing and bug-tracking processes. For the former, I strongly suggest an agile methodology like Extreme Programming, which uses stories (further broken down into tasks) to organize programming work. (A great starting point is chromatic's Extreme Programming Pocket Guide - short and concise.) To integrate the two, either block out regular time daily for coding and bug bashing, or transfer story tasks and bug fixing activities to your actions/commitments system - paper, digital, what have you. (I like paper, in spite of my technical bent, but with GTD it doesn't matter. Do pick a self-management system that works with your tools.)

For code snippets use whatever tool you like. I use my patented semi-structured Big-Arse Text File, but wikis and spreadsheets work fine too. In my file I have lots of tips, tricks, and hints, including how to start the database server in debug mode on windows, and the shell command to find text in files (I can never remember the syntax for using find with grep. I can't help it - it's genetic, but marks me as the unwashed...)


In my last job, we set up all these, with great success. It was very comforting getting email at 2am from our cron job saying the build broke, or that a test unexpectedly failed. And having all those unit tests (yes, even the GUIs were test-driven) made my boss very happy. (Not to mention what a mind-blower it was switching to writing tests first; you have to check out Test-driven development - really!)


Effectiveness

So if all that's about being efficient (an important aspect of productivity), where's effective come into play? Drucker's thought was working effectively meant doing the right job (vs. doing the job right - see above). In XP's terms, it starts with the stories being customer-driven. Customers are the ones who get to decide what's important (i.e., what has high business value), with us programmers providing what we know best (technical expertise that guides implementing the whole thing).

But beyond that, you should think about your greater contribution to the organization. You should spend some time every day connecting with the higher-level mission of your business, and thinking about the novel and innovative solutions and tools no one even knows they need yet. This is what moves us from vanilla programmers to more valued "knowledge workers." (The test: are you being told what to do, or are you figuring it out? The latter is what I understand knowledge work to be. The former is more in the "please outsource me" category![1])


So...

So how to do this? First, stop reading now, go out and buy My Job Went to India: And All I Got Was This Lousy Book by Chad Fowler, and read it. Don't let the title fool you - this is the book I wish I'd been handed when I started twenty years ago programming. It's a mind blower; highly recommended.

Second, start (or continue) to stay on top of technology, news, tools, and trends. These are a great source of ideas, and can get you asking those higher-level questions with high value.

Third, give yourself a 20% day [2] - little skunkworks programs (esp. tools that empower others, automate repetitive tasks, etc.) are healthy to work on - both for you and the organization.

Finally, consider starting your own little "Operation Bear Hug" (from Who Says Elephants Can't Dance? by Louis Gerstner - on-line here): visit or call five of your customers, listen carefully to what they love and what they hate about your program, show them you care, then think about whether there's a small change you could make that would implement one of those things, i.e., either add something they'd love, or fix something they hate.


That's about it for now. In the next few posts I'll continue the Productivity for Programmer theme with some highlights from My Job Went to India, then a post about networking tips for geeks. Cheers!


References

• [1] For more on making yourself "untouchable," check out these ideas from The World Is Flat: A Brief History of the Twenty-first Century by Thomas Friedman: The four categories of people whose jobs cannot be outsourced:
  • special - (only a few people) CEOs, stars, sports
    
  • specialized - knowledge workers whose skills are always in demand and not fungible (fungible: work that can be easily digitized and transferred to lower-wage locations)
    
  • anchored - (most Americans) work that must be done in a specific location, involving face-to-face contact with a customer, client, patient, or audience. but there are fungible parts
    
  • really adaptable - constantly acquire new skills, knowledge, and expertise - must be able to constantly create value - make the latest thing in field. adapt as parts of work become fungible. knowing how to "learn how to learn" will be one of the most important assets any worker can have
• [2] From Google's employment page:

  Google engineers all have "20 percent time" in which they're free to pursue projects they're passionate about. This freedom has already produced Google News, Google Suggest, AdSense for Content, and Orkut - products which might otherwise have taken an entire start-up to launch.

  
  

Matt is Back!

OK, that was bad.

I was out sick for the past week. Not your "I feel a little cold coming on, I'm going to take it easy today," but more like "I know I should drink water, but I'm too weak to crawl." Fever of 104+ degrees Fahrenheit (gotta love US units), body wracked by coughing, etc. In other words, just the flu. Answers.com says it well:

An acute contagious viral infection characterized by inflammation of the respiratory tract and by fever, chills, muscular pain, and prostration.

Prostration - quite right.

Interesting facts about being sick:

• It's just like taking sick leave when you're employed, but without the pay.
  
• Be prepared to become seriously depressed once you do feel better. This was unexpected, and unwelcome.
  
• Tracking your actions on a master list GTD-style, instead of scheduling every single one, is great when you're sick. Instead of pushing a ton of them back a week or two, I just had to contact those people on my calendar to reschedule.
  
• Every day I was sick I had anxiety about two pressing projects I had promised to get out. I was finally able to convince myself it was better to be late with them (letting people know, of course), than to kill myself trying to work on them, making mistakes, and generally doing myself and my clients a disservice.
  
• I continued to capture thoughts, ideas, and (more likely) rabid ramblings via my trusty bed-side pad of paper and pen. Those notes are in the Smithsonian now, so I'm glad I did!
  
• I missed my exercise! I do 30 minutes a day, 7 days a week, and being out for a week was nasty. Probably contributed to the depression.
  
• Getting out of the routine - it's hard to get back into the swing. I'm doing exercise, and I'm using the "at least one significant action a day" approach to ensure I am productive again. Even a little thing like rescheduling all my canceled appointments is good.
  
• People didn't mind my canceling their appointments, esp. when I explained I did not want to get them sick. Funny, that.

Anyway, next up: My long-delayed second part on Productivity for Programmers, following Bob Walsh's great Productivity for Programmers, #1: Trusted Systems, the first in our series on the topic.

Stay well!