Solarwinds Geek Speak

I wrote a few articles for the Solarwinds Geek Speak blog that I’d like to share. They are short articles, but I think you’ll find some value in each. Start with the 80/20 rule below post below and read the rest if you have the time.

The 80-20 Rule of Analysis and Optimisation

Start with Continuous Improvement, then do DevOps

The pain of network variation – part 1

The pain of network variation – part 2

A disclaimer: Solarwinds didn’t ask me to promote these posts –  I’m sharing them because they’re posts I would have otherwise published on this blog.

Add a comment below if anything strikes a chord, or if you want to disagree, correct me, etc.


The Feynman Principle


Richard Feynman

Interviews often start with softball questions like…

So why are you interested in working for our company?

This question gives the candidate an easy way to warm-up and could give the interviewer some insights into the candidate. I’ve asked this question many time and sometimes heard a reply like..

I really want to learn about large scale networks. My current network is too small and is limiting my progress.

Continue reading

Include the why

whyI recently stumbled upon an interesting speech from 1984 by Charlie Munger of Bershire Hathaway fame. Charlie is Warren Buffet’s right-hand-man, and a straight talking genius in his own right. It’s a fairly long speech and Charlie has a few very interesting things to say, but one particular section on ‘explaining the why’ really struck home.

Here’s a brief quote:

….if you always tell people why, they’ll understand it better, they’ll consider it more important, and they’ll be more likely to comply. Even if they don’t understand your reason, they’ll be more likely to comply.

So there’s an iron rule that just as you want to start getting worldly wisdom by asking why, why, why, in communicating with other people about everything, you want to include why, why, why. Even if it’s obvious, it’s wise to stick in the why.

The ‘why’ is notably absent from most conversations in our high-tech sphere. I’ve wasted countless hours interpreting solutions to ill-defined or undefined problems. I’m guilty of writing many ‘why-less’ documents and emails also. Upon reflection, I can recognise the folly of not explaining the problem at hand before launching into the solution.

When I drop the reasoning and background and go straight for the solution, I find that I trigger much frustrating communication, organisational friction and ultimately lost time.

Perhaps I feel I’m being efficient by banging out a quick email which omits the ‘why’, but it’s certainly not effective. Perhaps I fall into the trap of assuming everyone is on the same page and the ‘why’ should be self-evident.

I’m with Charlie on this one, I think we could all provide more ‘whys’ in our email, network designs, change control documents, etc. I’m going to try and add more ‘why’ to my communications over the coming weeks with the goal of reducing friction and improving the effectiveness of my communication.

What do you think?

Thoughts on leaving Amazon

Hi All,

I left Amazon in late 2015 to become an independent contractor. I took a contract working for a small managed service provider, which was closer to my home and offered a more family friendly schedule. It wasn’t an easy decision to make. I knew that I was going to miss some really cool colleagues, some fascinating nerdy discussions and a very tough, but massively effective thought-system.

The network I’m currently working on is tiny when compared to Amazon’s but most networks are. I’m back to figuring out the messy work of taking over projects in the deployment stage and trying to squeeze advanced features out of enterprise hardware. I’m working within a different set of constraints. Continue reading

Career – Zen and the art of network maintenance

Getting Zen


Zen and the art of motorcycle maintenance‘ by Robert Pirsig is a modern classic.  When I first read this book I didn’t quite get the zen I was looking for. But then again maybe I was trying too hard which isn’t very zen-like.  It is a wonderful book and although I missed many of the metaphors I gleaned some solid advice on how to enjoy my work. I think Pirsig’s motorcycle maintenance tips can help us in our day-to-day life. I’ve even dared to add a few tips of my own.

Continue reading

Career – The network rockstar and the checklist

We’re in the midst of a networking boom at the moment and new technologies are being released at a rapid pace.  So much so that network engineers need a suite of knowledge management tools to navigate the daily deluge of articles, documents, twikis and notes.

That said, how much of your day-to-day activities are markedly different than they were two years ago? As I see it, the role of the network engineer is largely unchanged.  One still has to gather requirements, write designs docs, order, ship, build, configure and troubleshoot. Design reviews are still required and change procedures are still needed before touching the live network.

Continue reading