Chapter 2 – Strategic vs Tactical Mindsets

Before I get too far into this chapter, I want to make sure the audience understands a couple of things:

• I’m speaking from the perspective of a Network Engineer who made the move to Network Architect
• I’m not, in any way, shape, or form trying to shame, put down, or insult the engineering field at all!

The Engineer: Tactical Problem Solver

If you’re currently an engineer (again: network, server, security .. doesn’t matter), take a moment to think about what you do on a day to day basis.  I’ll bet it’s similar to what I was doing as an engineer almost twenty years ago.  I’d get a list of tasks that needed to be completed, and I’d do them.  Sometimes those tasks would come in the form of tickets from whatever ticketing system we were using.  Sometimes those tasks would come in the form of what we’d call “drive-bys”: a co-worker stopping by my desk, calling me, or emailing me and asking for help with something.  Other times those tasks would be something that was planned in advance (eg: maintenance) to overhaul, improve, change, or fix the network.  Sound at all familiar?

This is the realm and scope of the engineer: he or she is solving immediate or short-term projects and problems.  The advantage of this is that they know what needs to go where, what needs to be configured in what way, and what’s talking to what.  Likely they know that right off the top of their heads, too, and can recite it at a drop of a hat.  These are the folks you want and need operating and making changes to your systems because they understand what’ll happen when it’s completely properly, and what may happen if it doesn’t get completed properly.

This is all tactical.  It’s immediate, or very short term.  You can become a very valuable member of the staff by honing this tactical mindset, remaining an engineer throughout your career.  In fact, companies would be foolish not to encourage some of their engineers to do just that.  However, if you want to make the move to an architecture role, you’re going to have to change that mindset and start thinking bigger.  Much, much better.

The Architect: Strategic Thinker

Building off the last section is the architect.  He or she is looking at bigger things and longer distances to deliveries.  They’re looking at the entire system and how what they’re doing will impact it.  For instance, again from a networking perspective: the network architect has to have a view into what the server folks are doing, what the developers are cooking up, what the security teams are doing, etc.  All of that so when they propose a new architecture for the network, it meshes properly with the other groups.  They may even need to influence those groups, too, but we’ll get into that in a difference chapter.

The other key point is that the architect is planning for something that may not be realized for years.  Not days or weeks, or even months.  They can see a bit into the future and can plan the direction for their specific sub-system so that in time, improvements and advantages of that direction become apparent to others.  And that word “direction” is key, as well.  An architect may be proposing changes to their sub-system, but it’s important that they set directions, too.  More than, for example: this set of things needs to change so it can perform better.  Instead, something like: we should be looking at these new key technologies so that our sub-system has the following properties over time.

Size and time.  An engineer is a bit more myopic and planning short-term.  An architect is almost scheming for entire systems, and changes that won’t appear for a year or two.

How I Did It

I remember late in my Network Engineering career at AOL, I was trying to make the move from Senior to Principal.  It wasn’t going to happen, much to my chagrin, but I didn’t understand why.  My manager at the time sat down with me and laid it out clearly.  He said, “You’ve got one of the sharpest tactical minds in this entire company, but you don’t understand strategy.”  My problem at the time was that I didn’t understand what he meant by that.  Sort of a double-whammy, if you will.  It wasn’t until I got laid off from AOL and moved to Comcast that I understood it.  In fact, it hit me like a train.

What I saw when I moved to Comcast as a datacenter network architect was a team of very skilled network engineers who didn’t understand strategy.  The common question I was asked was, “What problem are you trying to solve?”  Sometimes architects aren’t trying to solve a problem, they’re trying to take something that works and make it work better.  One of the guys down the hall from me at AOL had a simple sign on his office door: “Good Enough Isn’t!”  I’ve never forgotten that, and it’s driven me ever since.  But more importantly, this interaction with the engineers at Comcast showed me what my limitations were back at AOL, and why I never was able to make that jump.

Reference the second bullet point from above and keep in mind that I’m not now trying, nor ever did try to insult the engineers at Comcast.  It’s just all they understood at the time: change is bad, we have something that’s working, let’s keep it going.  The architect’s job is to set a new, or even slightly altered path, and convince the change-hesitant engineers to come along.  And that’s what I worked on while I was there.  Jumping from Comcast to Verisign in 2012 saw me in exactly the same role and working with an engineering team a bit hesitant to change.  “What problem are you trying to solve?”  Again it was my job to help set a new direction and convince the network engineers to help me get there.

Next: Social vs Transactional

The architect has to have a different, expanded mindset than the engineer that he or she was before.  Hopefully the text above helps explain the difference.  Next on the list is what I call Social vs Transactional.  I’ll get into the way successful architects work with folks in other organizations.