By Leonard Fehskens, The Open Group
It being the time of year for commencement speeches, Patty Donovan asked if I could offer some advice to graduates entering the Enterprise Architecture profession.
She specifically asked what three things I wished I had known when I began my career, and it’s impossible to resist the setup. I wish I had known:
1) What stocks to buy and sell when
2) Which managers at what companies to work for
3) Which personal relationships to pursue and which to avoid
Had I known these things, my life would likely have been free of much unproductive stress.
OK; that’s not really helpful advice; these aren’t things that one can actually know in advance.
But there are some things that I sort of knew when I got out of school, that in retrospect have proven to be far more important than I imagined at the time. They are:
1) Things, especially big things, only get done by collaborating with other people.
2) Be open to other perspectives.
3) Nothing in the real world is linear or one-dimensional.
4) You have to be able to commit, and be prepared to deal with the consequences.
Let’s explore each of these in turn.
Things, especially big things, only get done by collaborating with other people
This seems pretty obvious, but we never seem to take it into account. Unless you’re a genius of staggering magnitude, your success is going to be largely dependent on your ability to work with other people.
If you majored in some aspect of information systems, unless you minored in psychology or sociology it’s unlikely you took more than one or two elective courses in one or the other. If you’re lucky, the company you work for will send you on a two or three day “team building exercise” every few years. If you’re really lucky, you may get sent to a week-long “executive development program” in leadership or “organizational dynamics.” These sorts of development programs used to be much more common, but are now much harder to cost-justify. My experience with these things was that they were often interesting, though some of the exercises were a bit contrived. But the key problem was that whatever one might learn from them was easily forgotten without any subsequent coaching and reinforcement, washed out by the implicit assumption that how to collaborate as part of team is something we all knew how to do intuitively.
So what we’re left with is “learning by doing,” and it’s clear from experience that this basically means picking up habits that, without expert coaching, will be a random mix of both good and bad. What can we do about this?
Most organizations have an HR policy about staff development plans, and while people are rarely held accountable for not carrying out such a plan, a sensible request to take advantage of the policy will also rarely be refused. Don’t neglect any opportunity you get to develop your “soft skills” or “people skills.”
Be open to other perspectives
A thoughtfully open mind—the ability to recognize good ideas and not so good ideas, especially when they’re someone else’s ideas—is probably one of the most useful and most difficult faculties to develop.
It’s a cliché that truly effective communication is difficult. In practice I have found this often means that we don’t understand why someone takes a position different from ours, and without that understanding, it is too easy to discount that position. This is compounded by our predisposition, especially among techno-dweeb-weenies, to focus on differences rather than similarities, something Freud called the “narcissism of small differences.”
Fred Brooks (“The Mythical ManMonth,” “The Design of Design”) has long argued that the chief or lead architect is responsible for ensuring the “conceptual integrity” of a design, but this doesn’t mean that all the ideas have to come from that architect. Nobody has all the answers. It is the architect’s responsibility to synthesize worthwhile contributions, wherever they come from, into an integrated whole.
Nothing in the real world is linear or one-dimensional
When I moved on to a new position after leading an architecture team for several years at Digital Equipment Corporation, the team gave me two rubber stamps as a token of their appreciation. One said “It depends …”, and the other said “Yes, but …”.
Though it’s almost never possible, or sensible, to rank anything non-trivial on a single linear scale, we try to do this all the time. Simple models of complex things do not make those things simple. Acting as if they do is called “magical thinking,” for a reason.
So there’s almost never going to be a clearly best answer. The best we can do is understand what the tradeoffs are, and make them knowingly and deliberately.
You have to be able to commit, and be prepared to deal with the consequences
Each of the above three lessons tends to complicate things, and complications tend to delay decision-making and commitment to a particular way forward. While successful architects understand that delayed binding is often an effective design strategy, they also understand that they will never have all the information they need to make a fully informed decision, and finally, and most importantly, that you can’t postpone decisions indefinitely. They seem to have a knack for understanding which decisions really need to be made when, and how to connect the information they do have into a coherent context for making those decisions.
But they also have contingency plans, and ways to tell as early as possible whether they need to use them. In a genuinely supportive environment, it will be OK to reconsider a decision, but only if you do so as soon as you realize that you need to.
So, don’t make decisions any sooner than they must be made, but don’t make them any later either, and make sure you don’t “paint yourself into a corner.”
Len Fehskens is Vice President of Skills and Capabilities at The Open Group. He is responsible for The Open Group’s activities relating to the professionalization of the discipline of enterprise architecture. Prior to joining The Open Group, Len led the Worldwide Architecture Profession Office for HP Services at Hewlett-Packard. Len is based in the US.