Simple v Not Easy

Simple v Not Easy? Really, Big Red Car? That simple, huh?

Big Red Car here. It’s still a little rainy in the ATX but it sure is cooler and greener and cooler. More rain today, maybe.

So, The Boss is talking to four different CEO clients and they all stumble on the same bit of wisdom.


It is very simple to identify what the problems may be in founding or running a startup. In the lean, agile, crawl, walk, run ethos that is startup land — it is simple to identify problems.

You have a website or app to develop and you need some tech assistance. You may need a CTO.

Marketing? Maybe you need a CMO.

You and a co-founder are no longer the match made in Heaven?

You may need to split up.

Identifying problems is simple.

Not easy

Solving that simple problem is not easy.

Big takeaway — even simple problems may require the infamous 5-7 touch problem solving process.

There are a lot of simple problems but there are almost no equally easy solutions.

This is a common lament. Bad news, CEOs, this is normal.

Now, back to our regular programming.

But, hey, what the Hell do I really know anyway? I’m just a Big Red Car. See, wasn’t that simple?cropped-LTFD-illust_300.png


5 thoughts on “Simple v Not Easy

  1. Or Solution bias V Analysis – Often Simple means complete this vs. Not simple means Evaluate this. It is never easy to uncover the problem but always simple to Pull a solution out of the Air. Fortunately for the start-up they can try and fail at a lower risk especially if they are still living on OPM (Other Peoples Money). The enterprise has a customer base and public accountability, market expectations to innovate or be thrown in the dinosaur pit. Additionally the enterprise has many moving parts who need to be on same page, bought in and enthusiastic. Ugh everything seem Not easy! Thanks for letting me vent!

  2. > You have a website or app to develop and you need some tech assistance. You may need a CTO.

    Well, for an information technology startup, uh, maybe the CEO needs to learn to write code?

    Or, if the CTO writes the code, then why does the CTO need the CEO and not become the CEO himself (herself)?

    Sure, if the CEO is writing the code, then maybe for some very narrow issue he will need to talk to an expert in that issue, but that’s much less than hiring a CTO.

Comments are closed.