Read Next

Looking at Threats

I've been thinking of evaluating opportunities lately from the perspective of threats.

There's a downside to it, which is that focusing on the negative can mean a lowering of personal affect, morale, whatever. You tend to get more of what you focus on.

However, evaluating "what are the threats in the way of this succeeding?" seems like a pretty good way to check into ideas that are already on their ways towards correct execution. What could happen, with yourself, your team, competition, or other external stakeholders that could derail your success?

If you identify for threats, you can prepare against them. A cashflow crunch is easier to solve far in the future by securing some lines of credit during good times. If a key client or contract might be paid late, get that credit. If a single client accounts for more than half of your revenue, start diversifying even if it slows down your revenue growth. If a single sector is all you deal in, look if you can pick up a couple side-streams of revenue, especially covering most of your overhead.

Don't obsess over threats, and don't start thinking of them until you're well on your way -- by far the biggest risk is that your project never gets ignited and gets off the ground, and the you or your partners just don't hustle enough. But once things are going, do a once-over on threats. It could be the difference between success and failure. An ounce of prevention and all...

Just Say No!

On Gorilla Tactics

It is important to understand that as a human being, we like to get along with the people around us and that we work with. It is also important to realize that as a developer, it is not our job to please them at the expense of the project. This is a tougher pill to swallow than you might expect, especially when working with volunteers who can pick pu and leave whenever they want. However, sometimes an asset that is created is just not good enough to be included in the project, or is high quality but not in the style you need it to be, and you need to just have the guts to go to your employee/volunteer/contractor and say "I'm sorry, I know you put a lot of work into this asset, but it just isn't high enough quality to go into the project."

I don't suggest being this blunt as a rule, I am merely stating it this way to make my meaning clear. I'm not even going to try and explain some of the good ways of communicating a no - a different topic for a different day. What I =am= trying to convey to you today is that saying no is sometimes the right choice, and you will find that the people working with you and relying on you as a decision maker will actually be happier with you giving a justified no than if you attempt to be their own personal yes man.

Rendering New Theme...