The Architect’s Place in Society

When you think about our modern world, you quickly see that almost everything you depend on has some sort of software component.  Even things that used to be simple, like the food we eat is now sitting on a very complex and technological base that always includes complex software systems.  Each of these systems was designed by some flavor of software architect.  Some were very good at their jobs, but inevitably, some were not.  If we think about other complex tasks that have such fundamental impact on our lives, there are much more stringent controls on how these systems are designed and operated.

In most cases, this is a byproduct of maturity.  Things like roads and medicine have been around much longer than things like software.  Thus, the state of the industry and the regulation surrounding them is also much more mature.  We can look back into history to see epic failures in all of these mature disciplines.  Each failure has added to the body of knowledge about what not to do.  This results in our current regulatory and industry best practice structures.  None of those things exist in our business.

Yes, we have our share of epic failures, but in most cases these failures do not lead to loss of life.  Thus, we are largely free to make mistakes and we are the only ones hurt from those mistakes.  Or so it appears.

What started out as domain for academics and then later for hobbyists has become very foundational to our modern world.  It is the internet which thrusts the architect into the center of almost everything we do.  Today, the impacts of Internet failure are largely commercial.  A major company gets taken down by hackers and this is annoying or even worrying but it is not catastrophic.  President Obama described the Sony attack “an act of cyber vandalism.”  Thus, it is lower in the pantheon of crimes one can commit.  However, there are other systems, other platforms that would be far more dangerous.  Things like building control software or air traffic control systems.  Water and power management systems.

Ironically, these systems are very slow to advance and seem almost comical in their primitive design to the child of the internet.  However, it is this lack of connectivity that makes them safe and secure today.  A prime example of this is the way US nuclear weapons silos work.  “Ancient” technologies like eight inch floppydisks with zero connectivity are the norm.  It turns out this is a very good thing.  Imagine someone like North Korea getting the root admin password for the computer that launches a US ICBM.  This is something that doesn’t bear thinking about and is not possible today.  Looking forward, we know that this cannot continue.  At some point, the architectures and platforms we are designing today to sell books and play games will underlie the power grid, the air traffic control system and everything else we do.  As these systems evolve and mature, our industry practice and regulatory structures must also mature and evolve.

Thinking about the future of our industry, we must think of ourselves as critical to the functioning of our society.  We should be holding ourselves to the same standards that doctors, lawyers and civil engineers hold themselves to.  While I’m sure there are plenty of examples of where these systems have failed, we also know that in the vast majority of cases, the system works.  Think of your own life experience.  If your child is very ill in the middle of the night, would you hesitate to bring her to the emergency room?  Would you wait until you knew that the “good” doctor you trust was available?  Certainly not.  You would immediately rush her to the nearest emergency room with the full expectation that they would know what to do.  And in 99.99% of cases, that is exactly correct.  The vast majority of doctors in this country are very skilled and know what they’re doing.  The system of board certifications, internships and residency produces a very high level of professionalism that results in a very high standard of care in this country and in most western societies.  There are variations and you could make arguments about what could be improved (certainly, that’s true in the USA) but overall, the system works.

Take this same example to software.  Let’s say that your daughter had a digital virus.  Let’s say that for some inexplicable reason, you needed a computer technician to save her life.  What would you do?  Would you go down to Best Buy and have the dude from “Geek Squad” have a go?  I definitely would not.  I know that those people have no idea what they’re doing (no offence to Geek Squad or Best Buy, but I bet they would not want my daughter’s life in their hands either).  I have some people I know and I trust but there is no way in hell I would allow some dude to work on her in a life threatening situation.  Granted, I am a computer professional so I know things that non-techie folks don’t, but I don’t think that our industry would work the same way if children’s lives depended on the outcome.   It just would not happen.

Naturally, this does not actually occur and this is why our standards are so loose.  What I’m asking you do to is to think forward when actual lives ARE on the line.  When this DOES actually matter.  Then what?  How will we respond as an industry?  This is the critical question that we must answer.

As architects, our job is not to simply examine the world as it is today.  Our job is to project into the future.  To seek this future truth that does not yet exist and cause it to exist.  This is the only way we can know if things are true.

I am currently working on a new book which will explore this issue and other issues around the professional development.  Feel free to join in on the comments below to share your thoughts about this issue.

 

The one eyed man

"In the land of the blind, the one eyed man is king."

I've always wondered about this saying.  It strikes me that this isn't the best analogy to use when talking about the unique value that each of us bring to the world.  If you think about it, a sighted person who is suddenly thrust into a community of only blind people would not be hailed as a conqueror.  No, they would be ostracized as a freak, perhaps feared, most certainly the subject of ridicule.  This is the human condition.  We are social animals and instinctively seek the safety of conformity.

Strangely, we live in a society that puts individualism at a premium.  And then we seek out and attempt to destroy anyone who's actually different.  What an interesting contradiction.

In the workplace, the high performers are often praised and set as examples above the rest of the team.  However, the team will usually seek to bring this person down and will resist a single member outshining the rest.  It's just a natural competitive instinct to resist being placed into a lesser category.  In reality, the most successful teams attempt to share the credit and bring the entire team up at the same time.  Naturally, this is not actually true.  In any group, there will be variations in performance and thus you will always have a #1 performer.  This inherent dishonesty in team dynamics has always puzzled me.  It's necessary, but seems like a dishonest way to go about things.

Thinking back to my childhood, I was raised in the '70s in San Francisco.  One thing that was consistent drummed into me was that we were all equals as humans.  All people are the same.  If you thought of someone as less than you, that was discrimination.  Today, I understand that this was simply a reaction to the horrible oppression of blacks and other minorities; at the time I was just a kid so I took the advice literally.  I really believed that we were all the same.  That men and women were the same.  That there was no difference between an American and a Japanese person.

Then I grew up.

I found out, much to my horror, that this is simply not true.  Men and women are NOT the same.  We have different bodies, we generate different hormones, we look at the world differently.  When I started traveling extensively in my '20's I realized that Americans were very different than Europeans and very different than Asians.  This is a very good thing.  Through diversity, we find strength.  However, diversity does not imply that we are all equally good at everything.  We are not the same, we are not equal, interchangeable identical parts in a giant machine.

Thus, the idea that we're all equal just doesn't work.  We need to have a level playing field, we need to have the same opportunities.  But we're not the same.  It is OK to discriminate between people, but we need to do it on merit, not the color of their skin.

This gets us to the point of the argument:  In business, democracy does not work.  We don't all get the same vote because we're not all equal.

Why the dichotomy?  Why use democracy for political life but not for business?  Because in business, there is a winner.  That changes everything.

When you have winners and losers, there is a required difference and ranking.  You must have a #1 by definition or there is no winner.

Yes, I'm aware that there are businesses out there where "making money" is not the claimed objective.  That's fine.  I'm not saying it's about making money all the time.  What I'm saying is that all businesses have a purpose.  They either achieve this purpose or they do not.  This is winning or losing.

The phrase that I've always liked is "Meritocracy."  The implication in a meritocracy is that people rise or fall based on merit.  There is no assumption of equality, but there is an assumption of fairness.  Not everyone wants to live in a meritocracy.  I assume that is because they don't like the competitive nature and don't want to be constantly stack ranked against others.  However, I would argue that they're simply fooling themselves.  Every company I've ever worked for has had some sort of ranking system.  It may be hidden and very covert, but it's there.  How else do you assign promotions and bonuses?  I don't want to work somewhere that awards promotions based on "time in grade."  Just being able to breathe regularly does not seem like the correct criteria for becoming a supervisor.

I think another key difference here is the ability to vote with my feet.  In government, you don't really have the option of leaving because you don't like the current administration.  In my line of work, I do have that option.  It would be different if my career choices were limited due to circumstance, but I'm lucky to work in an industry that's still growing.  Thus, when I have no choice in leaving I prefer equality because that gives me at least some guarantee in life.

Thus, "fairness" is not the same thing as "equality."  So, what do you want in your workplace?  Fairness?  Or Equality?  I know how I would vote.

What's the difference between SDS and Storage Virtualization??

One of the things that always happens when a new term comes up in our industry is confusion about what it really means.  This is after the phase when everyone claims that the term is actually not new and is something that they've been doing all along.  I've already blogged about that phase of SDS here.

Now we are in the (very healthy) phase where we all argue about what the term REALLY means.  This is really good progress!!

One thing that I'm seeing consistently on the web is references to things that look suspiciously like Storage Hypervisors being defined as Software Defined Storage.  Let's be clear:  Storage Hypervisors are a very good thing, but they are not the same as SDS.

SDS is a Storage Management Architectural Pattern that allows for the remote management and configuration of storage assets.  Storage Virtualization is a technique for creating "virtual" storage assets (LUNS, Shares, Objects) on top of heterogeneous storage platforms.

Let's say you had four arrays from four different manufacturers.  To make this simple, let's say they're all block devices that support iSCSI (yes, simplistic but stay with me here).  If I were to apply an SDS style architecture, I would simply create a control plane (like ViPR from EMC) to manage them.  Whenever I wanted to do anything (provision a LUN, unmask a LUN, turn on Dedupe, etc.) I would go to the SDS control plane and issue my requests.  I would be ignorant of the underlying implementation (it's an ABSTRACTED control plane) but what I get back is an IP address pointing to the iSCSI end point on the actual SAN that I already had.  Thus, SDS allows me to abstract the management of my SAN but does not fundamentally change my data path.  Got it?  OK...

Let's take the same example, and install a Storage Hypervisor.  In this case, I install an appliance (either virtual or physical) and that appliance then mounts LUNs against my existing four arrays.  See the immediate difference here?  In this case, the Storage Hypervisor is the consumer of the storage.  Then, the storage hypervisor does it what it does (formats with it's own file system, adds meta data, etc.) and then RE-PRESENTS this storage to the actual clients.  This can be in the form of new LUNS or shares or whatever.  AT THE SAME TIME, this storage hypervisor might have a very slick SDS style abstracted management layer.  However, these are totally separate things.

For an example of this, take a look at the V-Series from NetApp.  These are basically NetApp head units that mount LUNs from non NetApp arrays.  They then format the luns with WAFL and pretend they're disks.  This is a great example of a "storage hypervisor" but not really SDS since it does not offer an abstracted control plane.

Got it?  Awesome!!

Top 5 Software Defined Storage Myths

Whoah.  Everyone has an opinion about Software Defined Storage (SDS) these days.  That's awesome!

Unfortunately, we have some really funny ideas running around about what SDS really is.  The only way to prevent this is to build up a standard definition and then compare alternates against this definition.  When they don’t hold up, you have to call out those willing to twist the term.  Here are some common SDS myths that we’ve seen running around the internet lately:

Myth 1:  SDS Isn’t Real

Our favorite is that claim that SDS is not a real thing and therefore I can call any product I want SDS.  This one is particularly awesome because it refutes itself instantly.  If there is no such thing as SDS, why on earth would you even use this term?  If it means nothing, then by definition your product or architecture is not SDS because SDS is nothing.  See?  Silly argument.  SDS is a real thing and we see customers asking for SDS features daily.  For vendors who claim that SDS isn’t real:  stay on the path you’re on.  More money for the rest of us.

Myth 2:  SDS is the Same as Storage Virtualization

This one is more interesting.   In this case, people are comparing two terms that are pretty loosely defined and claiming they are the same.  Tougher to refute because both terms a bit fuzzy so comparing them is twice as hard as just talking about one.  In looking deeper at this argument, we mostly see this being proposed by folks who already make Storage Virtualization technologies.  This is red light number one.  When someone takes a new term and applies it to something they’ve been doing for years, you should be suspicious.  Yes, it’s possible that they were way ahead.  Most likely, they’re just twisting the facts.  Second, it appears that most people who use the term “Storage Virtualization” apply it to the notion of providing a software aggregation layer on top of existing storage back ends.  While this is super interesting technology, it is certainly not new and it mixes data plane and control plane architecture.  One thing we know for sure is that SDS implies a segregated control plane.  This means that traditional Storage Virtualization products are not SDS.  They may embrace SDS style control planes but the notion of a virtualized data plane is not required for SDS so they’re not synonymous. 

Myth 3:  SDS means Software Delivered Storage

This one is really fun.  Basically, there are some vendors out there who have very cool software only storage products.  We won’t name them to protect the innocent, but ten seconds on Google and you can find them.  They are claiming that because they’re software only (no hardware as part of the bundle) that they’re SDS.  That’s pretty silly.  If you take a look at most of the major “legacy” storage players out there, what you will see is a software solution that’s bundled with hardware.  The vast majority of SAN/NAS products out there are software running on pretty standard Intel/AMD hardware.  They choose to bundle the hardware and software into a package to make it simpler do deploy/service and perhaps to gain some revenue on the hardware, but fundamentally all the value in the platform is software.  By breaking this delivery model and selling just software, does that mean I have an SDS solution?  Obviously not.  SDS is not a business model.  SDS is a Storage Management Architectural Model.  If software only vendors want to create an abstracted control plane, then that’s great and they can support SDS.  However, a traditional SAN can do the same thing if they choose to do so.  There is nothing inherent to SDS that requires you to have a software only business model.

Myth 4:  SDS means Object Storage

Ummm.  What?  We would not include this at all but there are some folks who seem to think this.  The notion that object stores are somehow related to SDS is pretty bizarre but it seems to be common.  Perhaps because many more modern storage systems are starting to be object based??  We don’t really know.  The reality is that object stores are not new.  Things like S3 and CDMI have been around for years and some of them have SDS attributes and some don’t.  Object stores are really cool, but they’re data plane constructs.  They are completely orthogonal to what SDS is trying to achieve.

Myth 5:  Traditional SANs Cannot Support SDS

Again, quite a silly notion.  As we have discussed, SDS is all about abstracting control surfaces from data plane and data services.  There is no inherent reason why you cannot do this on a traditional SAN or NAS platform.  What is true is that many of these platforms were designed before the concept of SDS was formalized but it’s not true that they cannot adapt to this new management paradigm.  It’s up to the SAN vendors to decide how/if they want to join the SDS world or not.  Since we are highly abstracted from the underlying implementation there is no reason why we cannot support traditional architectures along with newer software only or object store based systems.

Who's got more Myths?  

The New Hotness: Software Defined Storage

One thing I love about the industry I work in is the great passion and the awesome competition for ideas that we have.

One thing I really hate about our industry is all the people who just take their existing product and then re-label it as the new hotness.  Come on people, you're better than that.

Just as Cloud before it and SDDC more recently, the term "Software Defined Storage" (SDS) has suddenly become very hot in the storage industry.  Amazingly, it turns out that almost every storage vendor ALREADY HAS a great SDS product that they've been making for years!!  WOW!  These guys are really good.

Wait, what?

Yes, that's right.  Now that SDS is hot, everyone is simply claiming that their product is already a great SDS platform (surprise!).  Sometimes they do this by simply redefining the term (see here for example).  Others just blatantly ignore the facts.  Still others do actually have really cool SDS products.

You can see the problem here.  Those not very close to the subject quickly become confused.  What does this term actually mean?  What should I do about it?  Is this something I should really care about?  This then becomes FUD (Fear, Uncertainty and Doubt) that prevents truly great products from being adopted because of all the noise.  You can see this happening with SDS on Wikipedia where they claim SDS is simply a marketing term and doesn't really have a definition or purpose.

That's really sad because SDS is actually one of the more revolutionary things to come out of the storage world I quite a while.

So, what is SDS, really?

 

Software Defined Storage (SDS) is a Storage Management Architectural Pattern that allows for the remote management and configuration of storage assets.  Because SDS is a management architecture, it is completely abstracted from the underlying hardware infrastructure.  In other words, SDS describes a “Control Plane” architecture that is separate and distinct from a “Data Plane” (or “Data Path”) architecture.  SDS is being driven by the movement of datacenter architectures to highly automated, policy driven management frameworks (such as VMware’s vCloud Suite or OpenStack).  This movement is closely related to "Cloud" and to what is sometimes referred to as "Software Defined Data Center" or SDDC.  These frameworks require highly abstracted management layers in order to isolate the Cloud Management Framework (CMF) from underlying infrastructure details and/or changes.  There are three main components to these Cloud infrastructures:  Compute, Storage and Network.  SDS is the control plane for the Storage component of cloud infrastructures.

SDS has the following mandatory attributes: 

1)      All functions must be available via a simple remoting interface.  This is normally done via a web style (SOAP, REST, etc.) interface but this is not a requirement.

2)      SDS is defined as a “Control Plane” or out of band management channel.  This is normally done via an IP based management network but this is not a requirement.  Note that SDS cannot be implemented in band by definition due to the restrictions of physical connectivity.

3)      SDS solutions must offer a single control plane (also referred to as a “control surface”).  Underlying systems can be disjoint or multi-vendor but the SDS solution must be unified to claim that it is actually a SDS solution.

4)      SDS is independent of the “Data Plane” or I/O path.  This implies that all current and future storage protocols (FCP, FCOE, iSCSI, NFS, etc.) can be driven by an SDS based interface.  However, all dependent components must also be managed by a single control plane.  For example, FCP based solutions must have a single control plane for zoning and LUN masking.

5)      SDS implies deep integration with physical storage assets and supported operating systems and hypervisors.  Being able to present, remove, backup, replicate and perform other storage operations implies a deep level of integration with the underlying physical asset and the hosts (physical or virtual) being serviced.  However, SDS does not specify how this is performed.  SDS is not synonymous with virtualized storage.

 

It is important to note that SDS is not synonymous with cloud nor is a SDS compliant platform required in cloud scale architectures.  However, SDS does provide many of the storage abstractions required by these types of architectures.  Also, SDS is not synonymous with “Virtualized Storage” which is also commonly associated with cloud scale architectures.

It is important to note that abstraction and “virtualization” of Data Plane constructs (LUNs, iSCSI, Storage Aggregation Layers, Storage "Hypervisors," etc.) is separate from but related to control plane constructs.  Innovations such as auto-tiering, Flash based cache, de-duplication, virtual storage controllers, software based arrays, etc. are all concentrated in the data plane.  Each of these provides opportunities for SDS innovation via the control plane but they, themselves, are not directly related to SDS nor is SDS dependent on any one of these data plane technologies or architectural models.

Anyone care to offer a different definition?  Let's get it on!

 

Should Architects Evangelize?

When making radical changes to operating practice, you by definition will be injecting large amounts of change into the organization you are working with.  Things like private cloud are different enough that they will cause strain within organizations who attempt to implement these new technologies.  I find that there is an interesting dichotomy within the IT business around change and progress.  The business is populated by people who love technology and often pursue the latest bright shiny object just because it is, well, new.  Is it better?  Who knows?  At the same time, we work within extremely large infrastructures that are incredibly expensive to build and thus are very long lived.  These two things seem at odds and often create a type of cognitive dissonance that seems to escape some people.

This is especially true of the press covering the high tech world.  They’re always searching for that new thing which means that the tried and true technology that actually works usually gets short shrift.  If all you did was read the blogosphere or the high tech press, you’d think that things were very different than they actually are.  I spend most of my working life worrying about private cloud adoption.  This is something that’s been around for a few years now and you’d think that it’s a known thing.  However, the reality is sharply at odds with this.  Recently, I conducted an informal survey of about a hundred customers.  I asked them questions like “do you have a private cloud.”  Unsurprisingly, about 50% claimed to have one.  We then we asked, "do you allow self service provisioning?"  Very surprisingly, only about 50% of those companies said yes.  This means that only about 25% of the total (admittedly small) sample had even the most basic cloud feature enabled.  There’s always debate about what “cloud” really means, but pretty much everyone agrees that self-service is a necessary basic feature.  Let’s be clear, we didn’t ask if ALL their workloads were running on a cloud style architecture.  We just asked if ANY of their infrastructure supported it.  This means that the vast majority of enterprise workloads are not running on a cloud.  This may be a stunning revelation to those who are already talking about the "post cloud era."

As an architect, this is disappointing.  I really think that my customers can benefit from the concept of cloud.  Whether they buy my product or not, the core concept of cloud has immense power.  If they’re not aware of the benefits or don’t really understand the term, I can’t really help them reach their full potential.

This brings us to the question of evangelization.  The first person I ever met who called himself an evangelist was Guy Kawasaki when he worked at Apple.  His business card just said “Software Evangelist” which I thought was pretty cool.  I wish I’d been more careful with the card, I thought I’d kept it but couldn’t find it the other day when working on my new book about architects.  Sigh.

 

 

Being an evangelist is a funny thing.  Much like “Architect” the job description is a little fuzzy.  What I can say is that I know a good one when I see one.  For many companies evangelization is a key part of their business strategy.  Rackspace for example is doing an awesome job of pushing their agenda for OpenStack via evangelization.  Yes, they’re doing it for self-serving reasons, but they are also doing a great job of promoting what is essentially a free technology.  That’s good for all of us.  On the other hand, doing it poorly can be really annoying.  Not to be mean, but if you look at what my old employer, Microsoft is doing in this space, it’s not amazing.  The last OpenStack talk I attended by a MSFT presenter quickly turned into a naked sales pitch for their product.  The audience then checked out and started to disengage.  It’s a fine line, but you need to understand why Evangelization isn’t selling.

I bring this up because I believe that this is a key skillset and activity for the fully actualized architect.  Having a vision is nice.  Having a massive impact on the organization is what we live for.  The implication is that the journey to truth involves convincing others that your vision for the future truth is a big part of that journey.

If you’re a senior IT guy and you’ve never worked for a vendor in a customer facing role, this may not be an obvious skill that you’ve spent time developing.  On the other hand, I’m sure you understand that you need to have political support to get anything done.  Everyone’s heard the joke about the “Eighth Level” of the ISO stack.  In fact, the joke is so common that you usually don’t have to explain it to people.  I think that’s because it’s fundamentally true.  Like many things, it’s the shared understanding of the truth that makes it funny.

If you shy away from the term evangelist or if you feel this is really selling in disguise, think about how you would like to learn about something new.  Pick an area of technology that’s completely foreign to you.  Would you rather be exposed to that new area by a sales guy?  Or would you rather talk to someone you consider a peer?  Unless you’re strangely into self-abuse, I’m guessing the latter (no disrespect to sales guys…. OK, that’s a lie, it’s pretty disrespectful).  If you are learning about a new technology, do you want to talk to someone who thinks that technology is crap?  Wouldn’t that be a pretty short conversation?  “Hey, should I use the new FOO operating system?  Nah, that’s crap.”  OK.  End of conversation.  So, now you’re talking to a pretty technical person who’s really enthusiastic about something that you know very little about.  What do you call that?  Yep, evangelization. 

Now that we agree that evangelization is a vital part of an architect’s role, let’s talk about what it really is.

It’s selling.

Wait, what?  Didn’t we just agree that everyone hates a salesman?  Yep.  That’s true.  People hate being sold to.  Being really, really, good at selling means that you don’t really sell at all.  The true master salesman seeks to understand the customer’s underlying need and then satisfies that need.  When this happens, it’s called “customer service” which we all love.  When the salesman tries to force fit you into a product or solution with zero regard for what the customer really wants or needs, it’s called “being sold to” and most of us hate that.

I mentioned this in my book “Why we Fail” about enterprise adoption of private cloud.  The best book I’ve ever read about selling to technical people is called “Let’s Get Real or Let’s Not Play” by Mahan Khalsa.  In that book Khalsa introduces many awesome concepts, but one of them that I really like is what he calls “Peeling the Onion” to get down to what a customer really needs.  The implication for us as architects is that we need to understand both the underlying business requirements and the capabilities brought by the technologies.  It is by merging these two that we become evangelists.  Essentially, the future truth that we week to create is assembled by merging these two things.  This discovery process has many forms.  In most cases, all the information we need is hiding in the heads of those around us.  Despite our best intentions, most of the really critical facts are not written down and will never be discovered by browsing the web or reading whitepapers.  It is by talking to business stake holders, users, engineers, administrators and others that the architect can begin to bring those two domains into alignment.

Once you really understand where that overlap occurs, you form your vision.  You begin to understand what application, platform or service can satisfy the stated and un-stated requirements.  You begin your march towards that future truth.  However, you cannot do this by yourself.  Any serious enterprise system is going to be too large for a single person to implement.  This implies that you will require fellow travelers.  How will you recruit these brave souls?  How will you help them understand why the future truth you envision is superior to what they have now?  What secret superhero skill does the architect use to project this future truth onto others and entice them to journey into this great and glorious unknown future?

Wait for it.

Oh yes my brother; it’s evangelization. 

 

 

 

 

What's Worse than a Strategy Consultant? A team with no strategy.

I have to admit that I've done some really embarrassing things in my career.  And believe me, it's a long strange trip from a fresh minted UC Irvine Information and Computer Science grad to where I am now.

Along the way, I've had some really cool job titles.  Like "Technical Director" or "Director, IT Architecture."  You get the idea.  However, one job title that struck me as wrong an still sounds absurd to me is "Principal Strategy Consultant."  I mean, if anyone tells you that they are a strategy consultant you have to question what they actually do.  And to be a "Principal?"  Does that mean you're the king of the do nothings?

What it actually meant is that I got paid to go into businesses, ask dumb questions and then tell them what they were doing wrong.  Man, I loved that job.

As you can imagine, this gives me a funny way of looking at the world.  Or to be more accurate, I'm pretty f'd up and that job just brought out the worst in me.  My first boss told me that I had a "Columbus Complex."  He explained that meant I would take a look at a map, figure out that the shortest path from A to B was a straight line and to hell what any of the "experts" said.  Those of you who know me: you can stop laughing now.  After all, old Chris was right.  Let's forget that he thought the Caribbean was "East India".  I mean, it IS EAST OF INDIA, right?  So, two points for trying.

Getting to the point here, I'm a long term guy.  When I talk to people about their products or their services, I'm always looking at a multi year horizon.  That's not really "long term" for other industries like the guys who manage forests or something but it's pretty long term in the technology business.  Looking five years out in our business is really tough.  It's so difficult in fact that many product teams that I've worked on don't really try.

And that's a shame.

I call it "Lack of Strategic Context."  Which is a fancy way of saying you have no clue where you're going.  A director I was talking to the other day put it this way: "Why are we debating if you should take the train, fly or drive?  You don't even know which city you're going to."

You see the problem?  If you have no destination in mind then you're just wandering in the desert.  That's no way to lead your tribe, my friends.  Having an ultimate destination in mind is vital.  Even if you're wrong, it's better to have one in mind that to have nothing.

Don't believe me?  OK.  Let's talk about what happens when you don't have a strategic context:

1. Team dissonance.  Ever been on a team that is not aligned?  Ever been in a meeting where everyone is arguing and nobody can even agree what they're arguing about?  On what basis are we trying to make a decision?  It's very frustrating.  Team members will not perform at their peak with high levels of team dissonance.
2. No clear decision criteria.  Without clear strategic goals, how do you make decisions?  What criteria do you use?  Not every decision has a strategic impact, but they all should be made in a strategic context so you can decide HOW to make the decision.  What factors will you use to weigh your options?  These are all strategic context issues.
3. Duplicative or contradictory work.  If your destination is unclear, how do you minimize the amount of repetitive or unnecessary work that gets done?  Being able to decide what NOT TO DO is usually way more important (and more difficult) than deciding what TO DO.
4. Multiple, conflicting agendas.  Whether overt or covert, people will develop their own plan.  Nobody likes wandering around in circles.  Without a clearly defined joint strategic context, the team members will start establishing their own vision.  The better the team, the worse this problem gets.  Smart people will figure it out but they won't always come to the same conclusion. 

So, how do we establish a strategic context?

There is no one single way to get this done.  In the end, all that matters is that you have a shared long term vision amongst the team members.  You can spend a week in a conference room or go build teepees in the desert together (and yes, I actually did that once; not recommended).  However you get there, you need to have a single unified vision of your long term future together.

This really only works if you are the team leader or you have great support from your leadership.  You cannot "manage up" on strategy.  Here are some tricks that I've used with various teams I've worked with in the past.

1. This is your strategy.  It has to work for you and your style.  You can hire a consultant to help with the process, but you cannot get strategy from other people.  Just doesn't work.  Most of the folks who hired me to be a strategy consultant ultimately failed because they really didn't believe in or accept what I was telling them.  In the end, I realized that my job was more like a AA leader.  They have to want to change.
2. Strategy is a living thing.  Don't waste time on long winded reports or white papers.  I really prefer PPTs, but that's just me.  Do what works for you.  However, you really need to think of your strategy as the group's shared vision, not the paper or document.  That's just an artifact.  A point in time that you use to explain it to others.  The point of strategic context is to get the team aligned, not to produce fancy documents or presentations.
3. This is an in person, touchy feely thing.  You cannot get a highly distributed team aligned to a group strategy or vision.  I have NEVER seen this work.  NEVER.  Get the team together, work as a group for as long as it takes.  Meet regularly to ensure that you're still on target.  Go get drunk together.  I have made more progress on this issue over beers after some trade show than I have ever done during a WebEx with guys from all over the world.
4. This is about passion, not reason.  Highly talented people are passionate about what they do.  This means that they form emotional attachments to their work products.  You need to recognize that.  Allow them to vent that emotion when their pet project gets de-funded.  Dissent within the team is awesome while you are discussing what you should do.  Once the call is made, then it's time to get with the program or get lost.  Your team needs to understand that it's OK to bitch or complain within these sessions but that it's not OK to be off message externally.
5. Interview your team.  Take time to sit down with each member of your team individually.  Ask them to explain the team's long term goals.  If they can't do it, you've failed to achieve strategic context for them.  Keep in mind that this is your failure, not their failure.  Explain the goals and reset.  Repeat this process at least quarterly.  Ask yourself if the goals are correct.  If your own team doesn't get it, will anyone else?

I wish you good luck in your journey.

ITA