Competing Ideals

DISCLAIMER: I have absolutely no evidence other than my own personal observations to back the following claims. Please disregard at will.

The biggest productivity killer in the modern startup are Competing Ideals© — where a singleemployee/founder/what-the-fuck-ever has multiple projects that are in direct competition with each other. Examples include, but are not limited to, the following.

* Product – There are really three main functions of a Product organization: ideas, execution, and optimization. Each of these compete with the stakeholder for your direct attention, and in such a way that excelling at any one will completely trainwreck the others. Greenfield ideas should not be limited necessarily by the current state of execution, otherwise you innovate half-assedly. Execution should not be worried about coming up with the next big idea..they’re much too worried about getting the current product out the door. Execution also shouldn’t worry about optimizing, otherwise they’ll never be able to truly move on to the next big thing. Optimization cares only about the current product, and how to make it better (more monetizable, easier to use, etc.)

* HR/Recruiting – While these two fields are often tied together, having either of HR doing recruiting, or recruiting doing HR, will end in disaster. HR should be dedicated to the current employees, and how to make their lives/benefits/sexual harassment lawsuits more efficient and enjoyable. Recruiting should be doing just that, and worrying about the state of current affairs keeps them away from job fairs, interviews, hard drugs, resume searching, casual sex, cold calling passive candidates and whatever the hell else young people do.

* Engineering – Your most senior coders should be designing/coding/implementing/neckbearding the projects that will make the company the most money. As a trade for getting to work on the fun stuff, they get to train less senior coders to maintain existing and/or less money-intensive projects. As those coders get better and more in tune with the company/language/product/free kombucha, they get to work on the higher priority projects and help hire the new less seniors. 

This is a completely nonsensical and rambling post, but I stand by it 100% nonetheless. Forward it on to 10 of your closest friends, and riches will be bestowed upon you. If you neglect your responsibilities, fire will rain down from the sky and frogs will inhabit your rivers. The end.


Software Projects, Failure, and You

Most software projects will fail, and fail in seriously spectacular ways. Failures far more embarrassing than the drunken/awkward Techcrunch interview you gave for the consumer facing product this project is invariably linked to.

These technology projects fail, not for lack of technical or product skill, but instead due to an individual stakeholder having undue influence. These individuals are often in this state of implicit power for reasons explicitly unrelated to their technical or business understanding of the problem domain. For example:

1) This individual is on the board

2) This individual is an advisor to the company

3) This individual has a reputation for success and influence that precedes his or her involvement in the new project

4) This individual is considered a rainmaker

In the truest terms, this is not a positive role to have. When the rainmaker would come to town, he would pray for rain (obviously) and it would either come or it wouldn’t. If it came, the rainmaker took full credit, for it was obviously something he did! If the rain didn’t come, it was the villagers’ faults for not believing hard enough. And the cycle would go on in perpetuity. Eventually for most rainmakers, it would rain at *some* point, so as long as this scene wasn’t playing out in a desert or a dust bowl, the rainmaker would live a nice fat fraudulent life.

5) This individual speaks with a confidence and certainty that simply draws in other stakeholders, parties that exert direct influence over other stakeholders, and possibly even those committed to completing the project’s component tasks

If any of the 5 scenarios sound familiar, your project will fail. It will fail because the project’s scope is no longer tied to the success of the company. The success of the project is now tied to the success of the individual, for lack of a better word, “Rogue Stakeholder”.

You’re hoping for rain that will eventually come and then praising the shaman. By doing so, you’ve created some interesting new problems:

1) The rainmaker/board member/confident talker will now be involved in every future project planning session, warranted or not and regardless of their own relative merits, and this will continue happening as long as the company exists.

2) You’ve lost the ear and confidence of the stakeholders that you know the right way to get things done. The rest of your time in this position will be an uphill battle to re-establish the kind of trust needed for autonomy.


How do you stop this from happening? You have a couple of options, some of which would probably result in termination and/or jail time. My actual proposal might be a little strange, but I think it *just might work*.


** This is much easier to track down then it has been in the past

** Visualize how the project is laid out, using time as the primary metric. Make it painfully clear what changing the scope of a project does to the deliverability date.

** Do not leave any planning meeting without having a clear idea of priorities. If the meeting will cut short, have the other stakeholders schedule a follow up meeting SPECIFICALLY to complete this. Once again, provide visualizations that provide extreme clarity around the real costs (human, opportunity, and anything associated) with taking on the pet project’s changes.

** Try not to fall into one of the stereotypes I’ve listed above, and make sure you’re extremely nice, calm, and polite throughout this whole shitshow. That’s why they pay you the big bucks. 🙂