Working in network communications takes a certain mind set, with an innate ability to laugh off issues whilst simultaneously peddling frantically below the surface to prevent sinking. You are ultimately an engineer, a project manager, a commercial delegate, a ‘blame mule’ and the saviour when all hell breaks loose. In short, I love it, but it takes personal development to fit the heavily moulded requirements.
If you’re looking for pats on the back, words of gratitude or a relatively stress-free life, IT in the broader term, is not an discipline you should entertain (or be in if you’re already working in the industry!). As a network architect, you only hear from customers & clients when things go awry. We don’t generally get a hamper of goodies when we deliver a network that works as per design, neither do we get a weekend at Centreparcs thrown in to say thanks. The word “thanks” when received normally comes as an unexpected shock. Stress levels can be very high, 24×7 call out is normal, caffeine intake is off the scale and sleepless nights go with the territory. Why do we do it? The challenge of making something work against all the odds. The pay is also better than working at the local Tesco Express store. A common related reference is that of ‘certified Cisco CCIE’s’ currently stacking shelves at said store. < That’s what happens when you pay for a bootcamp in India without experience. Sorry, it needs to be said. It also needs to be raised that coming out of university with a networking degree and a CCNA doesn’t mean you’re a network guru. You my friend have just earned yourself a ticket to learn about networks in the real world and shadow people who have painstakingly earned their position and experience. *rant over*.
I love the field of networking, but it’s all too easy to get wrapped up in a web of want and desire and actually forget why you entered the field in the first place. The pay (as previously mentioned) attracts some people, but for others (including myself) it’s the constant feed of knowledge and the feeling of “I have to know this” which keeps me happy
Many engineers seek certification routes with the likes of Cisco to get started in networking and whilst the knowledge gained certainly points you in the right direction, it’s all too easy to become completely centred on gaining accreditations. Eventually focus shifts from engineering systems to being centralised on the features & tools provided by your vendor of choice. The larger picture starts to change and the next thing you’re blaming the commercial team because they don’t understand all that’s required in deploying a situation. Projects begin to slip and fury takes its place where there was once energy and PMA! (Positive Mental Attitude). Before you know it, you’ve became an elitist in your own eyes and noble humbleness is quickly replaced by arrogance. Every engineer hits this point when becoming self-aware of ones skill set. As pointed out by many other great blogs, we engineers form cogs in the greater machine of a money making factory and we take a salary home for the trouble.
Enabling those who pay our salaries a utilisation method has become more of an apparent need recently. This blog post by Ben Horotitz outlines a situation I have been in more than once. http://bhorowitz.com/2012/08/18/a-good-place-to-work/ This is one example of how the IT industry implodes on itself regularly. Just because a new RFC has came out which defines a method of delivering VPLS over pseudowires over TRILL over tunneled ATM, it doesn’t mean your managers give a damn or should give a damn. A business structure follows the below in a very rough manor.
Simple business model
“Idea -> Investment -> People get titles and roles to play -> Company generates product/service -> Company sells product/service -> Profit hits the bank account -> Your salary gets paid -> Profit gets reinvested”
“Formula: Money out = Sales – Overheads”
The last step referencing reinvestment is a grey area. The directors may see a reinvestment as a new house or swanky car as a reward for taking the risk in setting up the business.
The idea and investments normally come from risk takers. Risk takers do not normally wish to know what embedded code goes in to a bootstrap routine, or how much the coffee costs that you lather your brain in every day, they just want to enforce and execute the formula above. My previous frustration of “they just don’t get it” isn’t really relevant. It was my issue not theirs. This thought process leads down an interesting path and for many of us a dark and dirty path that not many engineers wish to traverse. The route of a management framework and procedure. This in turn helps to generate a “rules of engagement” methodology that can be used to efficiently connect your skill set to the fourth and fifth step in the simple business model above. It should provide a means to avoid the scenario covered in Ben Horowitz’s blog entry and assist in building the “good place to work” scenario.
After a moment of awareness that can be summarised as follows “I have to change”, the research trail began. Vast amounts of internet wasteland was trawled. My search ended bearing ripe fruit (see image to the right for proof). Techies such as myself look at things in black and white. Right and wrong. Tool by tool. It’s our greatest strength, but also our greatest weakness. The PRIDE framework (PRofitable Information by DEsign) was the fruit born out of the search for a better way to manage my systems life-cycle. It appeared to be hiding somewhat from the rest of the world, but it didn’t matter. PRIDE is about systems (irrelevant of the tools) and how to deliver efficiently and effectively. It appears to have been written in full knowledge of the challenges that we as engineers face everyday which for me is a huge invitation to read. I shall consume it and apply where simple quick logic fails for managing workloads. Also, I’ve noted a large amount of job adverts recently which state “experience with PRIDE framework or Consulting framework required” so maybe the world is about to make a shift in to recruiting more autonomous IT people who can just deliver without the total blinkered vision of their microverse.
For more information around PRIDE, try the following links: