Where are YOU in ten years?

For whatever reason, this quote stuck with me over the years. For me, it instills a very specific point, if you want to be somewhere different two, five or ten years from now, you start today. It also suggests, that humans are a very distracted set of algos, where-as if you don’t constantly advertise to yourself what you’re spending time on and what you WANT to spend time on- you’ll almost NEVER get to where you wanted to be. Today, I have an average of ten simple printouts, sayings and project ideas I want to remember hanging on my wall. 

 Prototype it, IT WORKS!

Prototype it, IT WORKS!

shitty software used by millions is better than perfect software used by none
— http://hintjens.com/blog:19

 

And the Most important one:

There are more- and they rotate from year to year, but you get the idea. I can say- thanks to Mr Gates, that they’ve had a profound impact on my work and my life. Over time, these “advertisements” act as a constant reminder, not for the weeks when things are humming along gracefully, but as guidance for the weeks when it seems like everything is falling off the rails. They remind me what's important, to “Get things Done” and “Ship it! Let your competition worry about perfecting it”.

Time Management

Screen Shot 2018-03-03 at 8.53.24 AM.png

Along with where you want to be- comes where were you and what have you completed? It’s been my experience that most people can’t tell you what they spent their time on last week, last month or even last year. If you can’t articulate what you spent your time on in the past, how can you plan your time into the future? Ten years comes at you fast.

Most contractors understand if you don’t pre-plan and allocate your time appropriately, a single client or set of clients can easily blow through their time allocation. Over the years i’ve come to understand that technologists ARE THE WORST at this. "Geeks" who believe everything has to be perfect to ship, or every time the competition pokes its head up with something new and shiny, they have to bolt that feature on too, because… NOBODY KNOWS! .. JUST CAUSE! What’s worse, when you get to the end of a cycle (product, quarter, … decade), most of them have absolutely no idea what they spend time on or what they want to allocate their time towards in the future.

I realize there are those who view time tracking as overkill, or those who fear managers will inevitably use it against them in future reviews.. I’m not talking about that, i’m talking about simple personal timers that help you get an idea of when you’re OVER committing to a project, client or research endeavor. When is enough enough? Contractors know this, because that’s how they bill every cycle, no time tracking, no food.

Personally, i've been using a very simple app [for the last decade] called “Timings”. Every time i flip a project, I just select the new project timer and get to it. For me, it started out as a very simple way to keep track and bill client engagements. When it came to the end of the month, there was no thinking, just add up the numbers, multiply by hourly rate, BAM invoice sent. Over time, my number of engagements grew, and my number of available hours shrank (kids expedite this a bit), it became evident I needed to not just track where my time WENT, but also where it needs to go in the future. It’s like money in that respect, when you have lots of it, you don’t need to future plan. When you have … not lots of it, you start having to pick and choose where you want to spend it. Something almost NO ONE does with their time.

In recent years I've also started a yearly google spreadsheet with all my projects and prioritize them based on where i’ve spent my time, how much time I actually have (somewhere between 1750 and 2500 hrs a year) and where I want to spend my time into the future. Every month I fill in the numbers to make sure i’m on track, but every year I ask, is this where I wanted to be a year ago? Am I spending too much time on open-source vs clients? Or worse.. vs versa? When you start putting things in context, how many [usable] hours there really are in a day, week, year.. the answers start staring you in the face. It's like looking at your finances, at some point it's just obvious what you can and cannot spend money (time) on. Assuming any new talent or project takes ~10,000 hours to become proficient in, you'd better start ... soon.

After a few cycles of just looking at the data, a funny thing happens.. you start making choices a bit differently, if only because there's data staring at you in the face. For instance, the year prior you decided you wanted to really focus on writing more open-source software. Open-source is tough because in some years it makes you zero dollars, other years it actually makes negative dollars, and some years, .. all the dollars. If you're right, eventually there's a market for it, but you have to be patient and continuously invest in it. It's about writing things down and finding a balance. Very quickly you start to make mental adjustments in areas like, how much time is this feature really worth? and how much doc is good enough (and are you getting paid for it)? Most right brainers will suggest that you need to be complete, but if nobody asks you that question, was it really worth documenting it?

You come to an end of a cycle and realize you've spent a total of 10% of your time allocating investing in it, when you wanted to spend 50%. Stuff happens, markets move, but at least now you have some data to figure out if you're happy or not with the results. Personally- I've found that if i'm not spending at-least 50-70% of my time writing open-source, i'm generally not happy. In most years you only have 1,750 - 2,250 hours to spend on stuff. If you spend an hour a week on things like Reddit, flame wars or youtube that number starts dropping really fast. If you look at that over ten years, that's 500 hours wasted instead of spent on learning a new programming language, or trade.

Over the years i've had a lot of interesting client engagements, K12, higher education, national government, international government, small scrappy startups.. the whole mix. The engagements i've found most interesting and beneficial are those that have an interesting cross-section between what problem they're trying to solve- and open-source. This metric in and of itself isn't all that interesting, until you start applying it to your finite resources (time). At some point along the journey I actually started using this metric "am I spending enough time on where I want to be in ten years?" to … let clients go. Which, I guess not a lot of folks do, because when i've told clients this- I get an odd look.

Project Planning and Forecasting

The magic starts when where you want to be aligns with where they want to be. However, as most contractors will [secretly] tell you, over time a funny thing happens, you and your clients will start to drift. While contractors are very articulate with their time and tasks (eg: that's how they get paid), clients can get distracted very easily. This is especially in the operations business (security or otherwise). Their job is almost defined as "drop everything at the drop of hat and clean up after your CEO who clicked on that stupid .xls for the 50th time".

It becomes habitual, a lifestyle that slowly bleeds into their culture. So much so, without consistent forecasting and planning can really take its toll on an organization. As a contractor, because of this- you start getting really good a being decisive and implicit in your direction, which is not always the case with full timers. You accept your mistakes and move on quickly, where others may carry a losing trade on forever, even if threatens their core business. At some stage, these two methodologies clash.

Earlier in my career I was tasked with developing an "ITIL" based "Incident and Problem Management Strategy". I know. Nothing turns more people on than "ITIL" and the words "strategy". We had a very simple problem, throughout the week, network engineers couldn't focus on their strategic work (eg: network upgrades, etc) because they were constantly bombarded with incidents. The easy solution was to just have an incident team and a install team, seems easy, right? Well, turns out our best "tier 3" people were needed for both install and solving major outages- and if we had duplicates across both teams, 50% of the time they were just sitting idle. Nobody could really focus on anything because when Incidents happen, they had to drop what they were doing, and as every engineer will tell you, it's really hard to get back into a project that way. Nobody knows when the next fire alarm is gonna go off.

Long story short, we started planning for time. Not just on the project side, but on the incident side as well. It's just statistics and the very nature of incidents (much like the weather and the market) are very cyclical. We started project planning "around the incident seasons", while it wasn't perfect, it provided some degree of context and we used this data to help plan projects. This type of data helps you drive a different style of project planning. It forces you to break a project into smaller and more management steps, with more realistic timeframes and resource allocations. The smaller pieces are shipped faster, because they're smaller and more resilient, the project gets done faster because more people are able to focus on the smaller pieces and interleave them more efficiently with smaller incidents.

Most importantly, everyone is happier, because something is being completed more often (everyone likes the gratification of completing a task) and when incident season picks up, we were ready for it. It was built into "the project cost" and everyone is almost expecting things to slow down a little during the storm. We even created a weekly incident forecast to help everyone [mentally] prepare. It wasn't perfect, but it was crazy close.. statistics are a wonderful estimation tool when used properly and within context.

The framework I found, which made the decision incredibly easy, was what I called — which only a nerd would call — a “regret minimization framework.” So I wanted to project myself forward to age 80 and say, “Okay, now I’m looking back on my life. I want to have minimized the number of regrets I have.” I knew that when I was 80 I was not going to regret having tried this. I was not going to regret trying to participate in this thing called the Internet that I thought was going to be a really big deal. I knew that if I failed I wouldn’t regret that, but I knew the one thing I might regret is not ever having tried. I knew that that would haunt me every day, and so, when I thought about it that way it was an incredibly easy decision.
— http://awealthofcommonsense.com/2016/10/the-jeff-bezos-regret-minimization-framework/

The biggest take away for me the past ten years has been, you have to help your clients project plan, especially in the ops business. You have to keep them from getting distracted by incidents and the next-new-thing, and you have to hold them accountable within the scope of your engagement. To do this effectively, you have to know where YOU want to be and help them figure out where THEY want to be. You also have to be willing to drop the dead weight if they choose to go in a different direction.