Play the Long Game

This isn’t about Financial Planning.

This isn’t about your Insurance Policy.

This is the one thing you need to get square in your head before you take on that new project.

Play the Long Game.

Don’t worry about the metrics, don’t worry about what your competition is doing better, don’t worry about how much someone else sleeps versus how much you sleep, don’t worry about what works and what doesn’t.

That’s short game thinking and you’re in it for the long game.

I want an Easy Life

Great – start with the end goal in mind.

It’s not going to come to you on a silver platter.

Forget all the hype, all the articles that are promoting someone else over you, all the followers you don’t have and guest posts you are missing out on.

If you want it, go work for it, go make it happen.

That’s all.

(foot note: this post first started out as “Great – Go work for it.  That is all” – it is that simple)

I Need that Fix

I need my coding fix to keep the logical part of my brain happy.

I need my writing fix to get out everything I have in my head.

I need my entrepreneurial fix to engage that feeling of starting something and growing it.

I need my sales fix that drives me to reach out and network with people.

I need my leadership fix when coaching and working with teams.

I need my exhaustion fix when I finish going for a run.

I need my building fix when I try to build something with my hands, admiring the calluses I have earned at the end of the day.

I need my humble fix when I try something new and keep failing no matter my level of effort.

I need that family fix where I get to step back and be amazed by all they can do.

We all have a variety of fixes we need in our life, the goal should never be to focus on just one, but instead to understand what ones we need and how to craft a life around that.

Clean Out the Clutter

Whether it’s the physical or mental – when we work in clutter – we never achieve our best work.

Think of an athlete, a soccer player, trying to pass on a field littered with garbage – they can’t setup a pass because the ball keeps bouncing off of a garbage can and going the wrong way.

Now think of your office, books and manuals strewn around the floor and on your desk while you try to focus on what is in front of you?  It’s a little hard when you have 17 sticky notes around your monitor with things you need to be doing when you are trying to focus on the current task now.

Now in your mind, how many different projects are you working on, how many can you keep separate without requirements on one not spilling into the other?  Is one project nagging at you the most but you don’t want to work on it because it’s going to take too long to get started on it?

Whatever the reason we want to use, one of the primary reasons for failing to achieve our goals is clutter.  We have too much going on and can’t focus on the one or many that we need to do to move forward.  Maybe we are trying to do too much in too tight a timeframe or maybe we are trying to do too much with the limited amount of resources we have.

There is a reason that so many of us look forward to “Spring Cleaning” – it’s the time of the year where we all commit to throwing the garbage, the clutter out, so we feel unencumbered and free to move forward and focus on what we really want to achieve.

The Primary Pain Point

You can’t deploy to Production because you didn’t fill out these forms.

You can’t use this library because it goes against our standards.

You can’t change that code because we don’t know what impact it will have.

Some sample issues you probably hit as a developer that reveal themselves to be the problem.

But they aren’t the problem, they are the symptoms.

And you won’t always recognize them as the symptoms and not the primary pain point until you’ve gone through the fire a few times, taken a step back thereafter and looked at what the real problem was from the beginning.

Why did you not know that you had to fill out forms to deploy to Production?

Who should you have cleared the user of a new library with?  Does it really go against your standards or are the standards out of date when compared to a new library?

How come no one can identify the impact that a change in code will have?

These aren’t the answers, these are the questions, that need to be asked, to get us closer to the Primary Pain Point, so then we can start to formulate a real solution.