I shared a screenshot from Basecamp with a coworker today. He was amazed at the amount of tickets I had “Done” and this got me thinking.
It was easy for him to measure my level of productivity by looking at the amount of work I supposedly delivered. While not far from the truth, it’s the type of work and the quality of the deliverable that matter more. And that is not obvious from looking at “done” tasks.
To me, the work I choose not to do helps me gauge my level of productivity. It's being able to focus on high-impact work that's more important to me. And that is where my system comes into play.
A couple of years ago I bought Shape Up, a book written by the amazing team at 37signals(doing a re-read, now). Needless to say, I adopted a couple of things from the book that have helped me stay focused to this day.
It was easy for him to measure my level of productivity by looking at the amount of work I supposedly delivered. While not far from the truth, it’s the type of work and the quality of the deliverable that matter more. And that is not obvious from looking at “done” tasks.
To me, the work I choose not to do helps me gauge my level of productivity. It's being able to focus on high-impact work that's more important to me. And that is where my system comes into play.
A couple of years ago I bought Shape Up, a book written by the amazing team at 37signals(doing a re-read, now). Needless to say, I adopted a couple of things from the book that have helped me stay focused to this day.
One project per client. It might sound crazy but I do this even when I work alone. I do it for the same reason I still work on feature branches, commit individual work with relevant comments, and submit pull requests. Because if I need to provide a report or if someone needs access to my work, they will be able to understand what, why, and how without me needing to do a full onboarding.
Don't jump to tasks. With the advent of todo list apps and personal productivity systems, people tend to attach checkboxes to anything that's asked of them.
Not so fast!
I don't know if what the client is asking me is what they actually need. Why tell them "Yes sir!" only to find out that I'm implementing something useless. Any request or suggestion lands in Basecamp's message board as a pitch.
A pitch includes:
Not so fast!
I don't know if what the client is asking me is what they actually need. Why tell them "Yes sir!" only to find out that I'm implementing something useless. Any request or suggestion lands in Basecamp's message board as a pitch.
A pitch includes:
- A statement of the problem (short description) which I fill in instantly
- The time I am willing to spend implementing the solution, and possible deadlines
- The proposed solution, if I have one at the time
- Possible pitfalls / rabbit holes
- Things I'm not willing to do — this is especially useful when I'm asked for an MVP but the requirements smell like finished product
Implement later. Unless it's urgent, I don't jump into implementation right away. Some things need time to mature before they're ready to be implemented. Maybe in one week the client changes his mind and the work is de-prioritized. Maybe I uncover an unknown that changes the feasibility of the project. Who knows?
Ultimately, letting some time pass will allow the client to change their mind.
Avoid hi-fi (overspecification). There is no time to get specs that translate 1:1 into code. I get part of the requirements before starting and the other part while doing the work. My goal is to get a rough description of the work, that's enough for me to cover the bases and get going.
Cover key points. The description of the work should cover the most important aspects, in terms of the purpose as well as the desired outcome.
Know where to stop. Anyone looking at the description of the work should be able to understand the boundaries. They should be able to tell what it is, where it starts and where it ends. This way, I'm able to avoid scope creep as well as extending deadlines indefinitely.
As you can see, my system revolves around writing.
If there's anything you get from this article, get this: Write things down, know when to start and when to stop, know what's too much, and let things sit for a while.
A.
Ultimately, letting some time pass will allow the client to change their mind.
Avoid hi-fi (overspecification). There is no time to get specs that translate 1:1 into code. I get part of the requirements before starting and the other part while doing the work. My goal is to get a rough description of the work, that's enough for me to cover the bases and get going.
Cover key points. The description of the work should cover the most important aspects, in terms of the purpose as well as the desired outcome.
Know where to stop. Anyone looking at the description of the work should be able to understand the boundaries. They should be able to tell what it is, where it starts and where it ends. This way, I'm able to avoid scope creep as well as extending deadlines indefinitely.
As you can see, my system revolves around writing.
If there's anything you get from this article, get this: Write things down, know when to start and when to stop, know what's too much, and let things sit for a while.
A.