Just Because You Can Doesn’t Mean You Should

Do you struggle with this too?

It can take different forms:

  • ‘Doing it yourself’ when it would be better to let someone else handle it.
  • Gold plating, which is adding more features because you think they are ‘cool’.
  • Putting extra effort towards something other than your product without any potential value to the customer.

And more.. Heck, I’ve caught myself doing a few of these just recently. The other day I received an email from a new student of my online project management training. There were warning messages showing up all over the place, and she never received her login details after purchasing access to the course.

I jumped in right away and fixed it as soon as I could. It turns out my web host had upgraded their versions of PHP and mySQL, and the software I purchased to deliver the training was using some old, deprecated PHP functions.

But as I was sitting there debugging the code a question crossed my mind.

Why am I doing this?

Doing It Yourself

I resolved the issue. I can debug php code on my own server. But should I be?

Should I even be hosting this on my own server where I’m responsible for all of the configuration, design, etc?

Would this problem have happened in the first place if I didn’t insist on ‘doing it myself’ and let a team of people who are really good at avoiding problems in the first place do it?

The answer is no, it wouldn’t have happened. My students would receive a better experience and I could have spent more time developing new training material or writing to help more people, instead of debugging code.

So I’m looking into migrating my training courses to a new platform, hosted by a company who knows what they are doing.

I just freed up a few hours per week of my time to do more teaching and writing. Sweet!

Gold Plating

Sometimes as developers we think we know what the customer wants better than they do.

It’s true that sometimes they don’t know what they want until they see it. There have been several occasions in my career where I had my teams develop prototypes ‘on the down-low’ to show to a customer because we knew they’d love it when they saw it, and authorize us to proceed. And most of the time, we were right.

But gold plating occurs when you go further and fully develop new features in a product without the requisite assessment of need/value from the customer and without accounting for the additional work in your schedule and budget.

And yes, I’m guilty of this too. There are several aspects of my online training that I spent considerable time on that no one uses. If they were scaled-down features to be used for experimentation to gauge student interest that I could enhance later if the need was justified, excellent. That’s iterative development, and is wonderful. But I spent a long time on some of these features that are now happily hosting a family of pet dust bunnies.


New project managers fall into this trap all the time with documentation. I know I did.

You spend tons of time on a project management plan because you want to make sure an auditor who might review your work would say “You get a gold star for making it look important, especially with all the flowery language and the fact that it’s 300 pages.”

Yea! You can knock someone down by throwing your plan at them.

Here are the lessons I’ve learned and want to convey to you about documentation:

  1. Identify the ‘customer’ of your documentation clearly
  2. Every word must add value to the people you identified in # 1
  3. The shorter and more concise, the better. The people in # 1 might actually read it.

If you can play bull$#!t bingo as you read through your documentation, try again.

Better yet, put your bull$#!t detector hat on as you are writing it in the first place.

Just because you can doesn’t mean you should.

What are your examples of doing something you shouldn’t have?

Come on, it’s very therapeutic.

It’s easy, just start with something like “Hello, my name is Josh. And I’m a gold-plater.”

Leave a Comment


Leave a Reply

Mark Hummel

Hi, my name is BetterLate’n’Never and I love being siezed by an idea and acting on it while the idea is fresh and vivid. However, this moment, for me, is very brief and occassionally non-existent. Sometimes I invest considerable effort chasing this inspiration, creating some of the best work of my career. Other times I dump effort into something that turns out to be relatively useless. Being an idea junkie, I have more ideas in five minutes than I could make happen in five months. So I’m working to pry apart that tiny space between idea and action to ask myself a few questions, such as (1) How does this compare with the other work to which I have? (2) If this is really such a great idea, how about I spend 15 minutes writing it down, review with the rest of my commitments tomorrow morning, and then decide what to invest? (3) What about talking the idea over with a colleague? (4) Learn to develop ideas in stages, using each as a feasibility assessment for the next?

I’d like to hear how others who are “siezed by ideas” manage the torrent of opportunities and this moment of choice.


Josh Nankivel

Take a look at personal kanban Mark! It’s a great way to capture those ideas and tasks as they come up, and have a place to prioritize them and make sure you never forget them.

You may want to divide your backlog into Covey’s quadrants to classify urgency and importance…

Mark Hummel


The personal kanban looks fascinating! I just ordered a copy of the book. Being a very visual person, I like the fact that the system is both visual and visible to others: providing context that connects the work to the larger purpose. Appears that the approach can handle ideas, vision, priorities, workflow, performance, and accountability, without undue complexity. And even more importantly, will help me make sure I’m working on what matters rather than just keeping very busy. Thank you, thank you, thank you!


Josh Nankivel

You bet Mark, you’ll love it. The best thing is that kanban in general is infinitely flexible – you map your own value stream(s), whatever they are. Be sure to start by mapping how things *actually are* and not how you want them to be. Evolve your process as you use it…the kanban should always be a mirror of reality and evolve along with process improvements and experiments.