There is one thing that anybody who has been in a room with me longer than 5 minutes can tell you – I am not a smart guy! I have lots of smart friends. I am not one of them. Sometimes I feel like I’ve done more stupid things, more often than I would like to admit, and its only that I have been stupid enough often enough that I have eventually learned “dont do that!“.

A couple of things have happened over the past few weeks that made me think about “The Smartest Guy in the Room”, and I thought I would share a few incomplete thoughts on the matter.

As a Consultant

Back on June 18, Matthew Norwood (who I would nominate for the award of “Nicest man in Network Blogging and Puppeteering”) wrote this blog post about consulting. In this post he talks about how as a consultant sometimes you have to accept that you are not the smartest guy in the room. At first this may seem odd, especially because usually our customers are paying us lots of money because we are experts. Funnily enough, on consulting engagements my job is more “I know where to find how to do that thing you are expert in”.

The most recent example of this was a few weeks back I was working on a Proof of Concept lab with a customer to see how we could integrate a series Juniper MX routers with their existing ASR9000 MPLS topology. Thankfully these sorts of things are fairly standard offerings on both of these platforms but this particular customer had their entire network built on Multicast over MPLS Point-to-Multipoint LSPs. Now when you consider that most people consider Multicast a “corner case” in networking, then these additional requirements made it a corner case inside of a corner case! On top of the fact that the customer engineers I was working with did this day-in and day-out, there was no pretending I was the expert. Instead my job became “I know where and how to make the Juniper MX do what you want”, and that was how I proceeded. And I can tell you this was one of the most enjoyable engagements I have had in quite some time.

As an IT Guy

It’s been stated many times that when you look at a group of IT guys, that most likely many of them were the “nerd” or “geek” growing up and were used to being the smartest guy in the room. As such, we often get interested in all sorts of technologies and ideas and run off on different tangents. I work with a couple of amazing guys who seem to tackle any odd-ball concept that comes to mind – like rigging a relay in circuit with the door control system so they can control the door with their pebble watch or simply building 3D printers to allow them to make all the toys they dream of. And often times they love to do this towards the end of the day/week when we are wrapping up units of work, and I know many late nights have been spent back in the office hacking away on something crazy “just because it can be done”.

Sadly, occasionally we take on tasks that are not our core competencies. This isn’t to say that we are unable to do the work, but simply it is not our strength and it can take much longer to resolve than it would a suitably trained / skilled engineer. A recent example of this was an incident that recently caused our team of network engineers to remember what it means to be a “Windows Administrator” and all the bits and pieces required to get some systems back online. We were more than capable of completing the work, but not necessarily in the most efficient fashion. We called in “a few favours” from friends with the required skills to sort this out, but  sometimes it goes against our gut feeling to seek advice. In times like this we need to accept that there are in fact people with strengths in these areas, and to ask for help is not about admitting defeat.

As Full Stack Engineer

And this leads into my last incomplete thought. Some time last week I engaged in a rant-fest with Paul Gear regarding the topic of breaking down silos within IT and what it means to be a “full stack engineer” (for lack of a better word). Admittedly the rant was primarily around how its not easy to break down silos when we still all refer to each other as “Server Guys”, “Storage Guys” and “Networking Guys” (nobody talks to/about “Security Guys” because they “just say no“), but over the course of the conversation I developed a few opinions (as I am known to do). And these are my thoughts on this…

Recently:

• I have started learning to program in Ruby, as well as learning about OpenStack. I have spent a fair amount of my “down time” learning about coding in Ruby and learning how to automate many of my regular tasks. I have picked up a few libraries developed by the guys at Juniper (mad props to Jeremy Schulman) and started learning more.
• I have started getting to grips with service automation using Puppet, and investigating how end-to-end provisioning of both server and network resources as a single process can improve delivery and satisfaction.
• I have built an OpenStack lab (as part of my beta testing of the Juniper Contrail product), and started to learn how to spin up and down workloads on demand and again how to integrate that with the various network requirements.

Do I want to be a programmer or a guy running servers all day? No, but I do want to be able to “talk the language” of the guys who do. There is great benefit in this ability not just as a consultant but as a member of a “Silo Free IT Team”. My view is that in the future, we will have blended teams of engineers, each with an understanding of the various aspects of the stack (Server, Storage, Security and Network), but we will still specialise in one or two of those areas. Working in such a team will be all about admitting you are not the smartest guy in the room and simply admitting “Yes, but I do know this part pretty well. Let’s come up with a solution”.

I dont see specialisation going anytime soon. Even within each of those four areas of IT there is a world of sub-specialisation that can be entire careers for people. The key is to have an understanding of all of the areas involved and know where best to apply your learned skills and experiences. *This* is what makes the future of IT teams… not a group of “jack of all trades” engineers, as some people interpret the idea of “breaking down silos”.

Mop and Bucket

I’ve learnt over time to know what I know, and to ask for help when I dont. Sometimes it takes me a while to get there, but almost every time that I do things get better 🙂 There is too much happening in IT and too much change in our industry to remain an expert at anything and everything for long. Widen your perspective for high level understanding, and learn where you can best apply and extend your skills.

If nothing else, it will make for an interesting and progressive career!