Tuning out the Noise, When Not to Finish a Project, and Planning vs Doing

In the comments section of my last post Rob left a comment with some really good questions that I thought were worthy of an entire post. These are all things that I constantly struggle with, which makes them great questions to think about, write about, and discuss:

How do you tune out the noise? How do you manage to avoid the Firehose of great ideas from every direction – colleagues, friends, yourself, the internet? There seem to be opportunities around every corner.

I have a hard time with this, so it starts for me with controlling the input as much as possible. That’s why I try not to read too much of the news. My partners and I typically meet once per week, so we save our ideas for that meeting instead of randomly interrupting each other throughout the week. That has the perk of putting some time between the initial thought/idea and the pitch. I find that time to think often changes or refines my perspective. Plus knowing that I’m going to pitch it to my partners helps me think through the pros and cons, as opposed to just shooting from the hip.

It also helps me to step back and think – is that really something I’m interested in? Meaning, would it be worth the time, effort, opportunity cost, and other trade offs? For instance, it’s enticing right now to want to start something new and big. But I have a young child and a growing business, so it probably isn’t the right choice right now. It challenges me to think about maybe trying something simple, or simply just enjoying life right now and getting back in the game with something new in a few years.

As the person who is managing our programming projects and also doing the programming, I’m constantly fighting this battle to keep focus on what’s most important, not on the new idea. The latest programming project always seems like it’s the most important. I like to pull up my Google Doc and literally talk through with the guys – is this more important than X or Y? This has become a habit over the years, and has probably inadvertently helped me apply the same mentality to other things.

Sometimes I find it incredibly difficult to judge whether it’s worth finishing a task – some things are useful even if they’re only half done, but lots of things I find aren’t useful until they’re 100% complete – and that jump from 95%-100% can often be longer than you realise as issues are uncovered.

This is so true. When we spec out a project, we often spend a lot of time on that last 5%. A proof of concept vs getting something out the door are two totally different things.

One area where we have been able to make this work is programming. For years I finished the front-end consumer experience while leaving the back-end features incomplete, meaning if there’s a problem I’m digging through the database and manually adjusting something, vs having an admin interface that anyone in the company can use or even automating certain tasks. But we were able to get more revenue generating projects done. This year I’m spending quite a bit of my time wrapping up projects like this from 5+ years ago. It’s exciting in that you get that feeling of completion, and we get some much-needed efficiencies internally, but also somewhat boring in that I’m not releasing cool things for our customers.

How do you judge when things are worth completing vs considering sunk costs & opportunity costs of doing something different?

We discuss opportunity cost almost every time we’re making a tough decision. I think just being aware of it puts you ahead of most people. We try not to let the sunk costs on a project determine what we’re going to do in the future. I think having multiple partners helps here, because usually at least one of us is emotionally removed enough from the decision to think logically. We’ve killed quite a few almost-done projects that just weren’t right – usually because they’d take up too much time or money to complete, but sometimes because the market has changed or we have some new information we didn’t have 6 or 12 months ago.

But, unfortunately, I don’t have any great formula to follow. These types of decisions are always hard.

How distinct is your time set aside for planning and your time set aside for “doing”?

I don’t set a ton of time aside for planning, other than our weekly meeting. It’s kind of always running in the back of my mind, for better or worse. Especially at night or if I’m doing some mundane task like shoveling snow or folding laundry. Other than that, I probably spend an hour or so each week reading my industry RSS feeds and newsletters, and during that time I’m trying zoom out and think if anything I’m reading is applicable to us. The only other time I’ll set aside for planning is when we’re about to embark on a new project. Then I’ll spend time researching, writing up a plan, and creating a short pitch to run by our team. Otherwise, I’m trying to spend as much time as possible “doing”. The hard part at this stage of the business is that a lot of that “doing” is stuff like HR or IT that’s not exactly my preferred use of time.

2 comments on Tuning out the Noise, When Not to Finish a Project, and Planning vs Doing

  1. Rob says:

    Some great insight here!

    >Plus knowing that I’m going to pitch it to my partners helps me think through the pros and cons, as opposed to just shooting from the hip.

    OK, so I’ve gone back and forth on this a lot. Sometimes I think if you discuss an idea too early when you haven’t fully thought it through and it is judged as if it were a fully fleshed out thought rather than a seed, it can be judged overly hashly, so I see where you’re coming from. However, from the other side if you think about something too long, when you talk to another person about it you can’t really be objective – it’s like you have an agenda and want to defend the idea – it might be that the core is good but there are some problems that other people can see but you can’t. I think 1 week is probably about right – not too late that you’re married to the idea, and not so early that it gets shot down instantly for being immature. I also think that a bit of time between idea and review is good, as it hopefully mitigates “shiny new thing” syndrome.

    It’s awesome that you’re polishing off the backends of system by the way – hopefully that will reduce the burden on you and empower employees more.

    I have a retired friend who spent decades of her career as an SQL programmer, doing backend reports and database updates for government projects. There were some complex things, but most of the volume of work was to do with payment records, name and address updates etc. It always seemed insane to me that what she was doing should have been handled by a clean frontend that non-technical people could use. They tried a few times over the years to refactor the whole system but there was never the budget, so she continued doing that job until retirement.

    >I don’t set a ton of time aside for planning, other than our weekly meeting.

    Forgive me please, but so that I’m understanding correctly.

    You have a thought, and you make a note of it. Where?
    You review those thoughts and turn some of them into action points. Is this at the weekly meeting?
    At some point, you review your action points, prioritise then decide what is next. When do you do this?
    How granular is your to-do list / project planning? Are you ticking handfuls of things off a day, or only one or two things off a week?

    I try and keep solid blocks of time – usually the mornings – 90 mins or 2 hrs for working on a larger project, then at some point I’ll take care of emails, deal with smaller issues etc. Some days though it seems like it’s all smaller issues..

    Are you still using the index card method?
    What does the “timetable” of your work day look like in an ideal world vs reality?

    • Adam McFarland says:

      All good questions Rob! Happy to expand and clarify:

      You have a thought, and you make a note of it. Where?

      If it’s something to discuss at our meeting, I add it to a notepad file that I keep. During the meeting I’ll take more rough notes in that file. Then each week after the meeting I either do the task if it’s quick (like sending an email) or transition things to permanent locations, like our programming Google Doc or my Remember the Milk to-do list.

      You review those thoughts and turn some of them into action points. Is this at the weekly meeting?

      Yes. We’ll discuss who should be doing it, when they should do it, if there’s anything we’ll need to buy that we don’t have, etc.

      At some point, you review your action points, prioritise then decide what is next. When do you do this?

      Usually as we’re discussing something, we’re trying to figure out where it fits in and prioritize it. I’m constantly revising the order of programming projects as things change. Usually I update my partners, but sometimes it’s minor so I don’t bother. Maybe once per year we sit down and review everything together and make sure it’s prioritized properly.

      Nothing else that we do really has a long term plan. We either decide to do it in some capacity now, or we decide to pass on it. Most marketing ideas we’ll experiment with the minimum cost/effort and then go from there.

      How granular is your to-do list / project planning? Are you ticking handfuls of things off a day, or only one or two things off a week?

      Both I suppose. Programming projects usually take a few weeks each, give or take, so I’m working on one of those at a time. Although one project might have several smaller components, so it’s rare that we go a week without launching something.

      But I also have my routine tasks in my Remember the Milk. For example, tomorrow I have to check on some Facebook Ads, review some #s from our HTTPS migration, check that an automated report I created a few weeks ago is still working properly, and update an internal wiki page. Most days aren’t that busy, I tend to push those types of tasks to Friday when I’m at the warehouse, but that’s an idea of the type of small tasks I check off each day. I usually do those along with email first thing in the morning or last thing at the end of the day.

      Are you still using the index card method?

      Yes, but more for life stuff than for work. For work I tend to just have that one programming project that I’m working on along with my daily tasks and whatever pops up. I am a lot less strict on my programming goals now, it’s less of a big deal if I’m a few days or a week later than originally anticipated.

      What does the “timetable” of your work day look like in an ideal world vs reality?

      With the baby now, my day is a lot more rigid. I have from 7:30 – 4:30, Monday – Friday while she’s at daycare and I try not to work outside of that unless it’s urgent or I’m doing an off-hours project like the HTTPS migration. Most days I try to do email earlier in the morning while everyone is getting ready, although that only works about half of the time. If nothing urgent pops up, I get most of my programming done from 7:30 – 11:30, then catch up on email and have lunch. In the afternoon I might do another hour or two of programming, but usually I’ll do smaller tasks and/or do a workout, take a nap, or work on a home project. Wednesday afternoons we meet, and Friday’s I’m in the warehouse, so this schedule is my Monday, Tuesday, Wednesday morning, and Thursday schedule.

      To your point, a week rarely works out like that but that’s the schedule I’m aiming for. If I get derailed, it’s usually some issue that needs my attention (customer service, warehouse , employees) or one of my partners needs to discuss something so we have a phone/Skype call. Increasingly, the baby has doctor’s appointments and gets sent home sick and whatnot, so those things can throw off a day too.

Leave a Reply

Your email address will not be published. Required fields are marked *

Commenting Rules

I'm honored that you found this post interesting enough to leave a comment. Before posting, I have a few ground rules:

  • Please keep your comments as relevant to the post as possible.
  • No personal attacks or any other nastiness.
  • Your first comment is subject to my approval.

Thanks!