Watch This Space

Well, I guess I have stuck to my own advice of doing less in order to do more. So well, in fact, that I haven't blogged in, well, nearly seven months!

That's not exactly what I had in mind when I made that last post, but it's funny how life catches up with you when you least expect it, and all you can do is give it your attention. Throw in both professional and personal preoccupation, and the next thing you know, half a year has elapsed.

But, hopefully life and work are close to finished with the curve balls and I can get back to blogging. As those of you who have read my blog have noticed, my blogs aren't just quick missives, usually, and take some time to craft (if you don't mind my using the word "craft" liberally). To kick things back off, I'm going to start a focused series of posts on Enterprise Architecture. The series will look roughly like this (though the final lineup might change - they aren't book chapters, after all, and I do manage at least a little bit of free-wheeling with these things from time to time):

1. Enterprise Architecture's Reason for Being, and in Some Cases, Reason for not Being
2. Key Focal Points for Enterprise Architecture - Communication, Quality, Consistency, Cohesion, Strategy
   
3. Finding Balance in Enterprise Architecture - Accretion and Erosion, Jigsaw Puzzles and Handcuffs
4. Some Practical and Practicable Advice for Enterprise Architects
   
5. Power Struggles, Personality Clashes, Misalignment of Management, and Red Herrings - a Sampling of What Goes Wrong
   

So, there it is, I've committed to several more posts. Watch this space...

A New Kind of New Year's Resolution

Here's a somewhat unconventional thought for the coming year. While everyone else is making new year's resolutions to do more, make a resolution to do less. Note, I'm not saying accomplish less.

Lately I have been reading "Six Disciplines for Excellence" by Gary Harpst. He reminds his readers in the chapter on deciding what's important that "The essence of strategy is deciding what not to do."

Support for the IT department saying no is not always strong in many businesses. It takes a foundation of trust, transparency, and a spirit of interdependence to make this possible in some cases. And, frankly, this should be a goal of any IT leader to begin with. I have found that support not just for saying no, but more importantly for pursuing avenues of work that best serve the health of the company at the expense of delaying taking up an otherwise perfectly good cause, goes up tremendously when everyone at the table shares the same vision for where the company is heading and is confident that IT's role in realizing those goals is sound and on target.

In the spirit of goals about which IT is concerned, there tend to be two major categories in my experience: Striving Goals and Thriving Goals.

Striving Goals are the goals that tend to traditionally get set by the core of the business - revenue goals, production goals, profit goals, growth goals, etc. These may or may not have input from IT when they're established, though hopefully they do if they are at all related to an IT function. If these are in place for the coming year, the question then becomes one of how to reach them. IT's concern is doing its part to help meet these objectives. It's when these goals don't exist, or when IT simply can't realistically meet them, that friction occurs. Still, if everyone sits at a table and discusses the goals openly, these issues can usually be overcome (even if it means saying no to a goal). In the best scenarios, the decisions will be made by the group, not soley by IT leadership digging in their heels.

Thriving Goals are those sometimes poorly-understood (by the business) and somewhat nebulous activities that take place deep within the bowels of IT. Some are an easy sell (virtualization projects with tangible ROI comes to mind), while others (identity lifecycle management, or updating aging technology) are quite a bit tougher. These can be tough to put a concrete ROI to in some cases, especially if you lack metrics to do so honestly and accurately. To make matters more difficult, they also often cut into the time available for tackling those Striving Goals. But, as someone who cares about both the long-term health and wellness of the assets and resources you provide stewardship for, and as someone who cares about growth and retention of your most valuable resources, your employees, it's imperative to build support for making time to focus on these goals as well. Which means carving some time out to focus on the Thriving Goals, and choosing not to work on those Striving Goals, so that your house stays in balance.

In Harpst's book, he says that his small, growing business achieved more by doing less, by cutting out the activities that weren't truly important. Anyone can choose to do everything requested of them. It takes discipline to begin focusing people on identifying the very most important objectives (VFOs, or Vital Few Objectives, in Harpst's book) and to resist the temptation to attempt to fulfill all the requests that come in the door.

But, by choosing to be more focused on fewer things, choosing to harness people's energy and creative talent rather than dilluting it across many tasks and activities that drag on indefinitely, and by balancing future-seeking Striving Goals with Thriving Goals that ensure your technology and human foundations thrive not just next year but for the next decade, 2008 can be the first of a succession of best years in your company's IT history.

I look forward to writing more about Striving and Thriving Goals in 2008. In the meantime, Happy New Year to my readers. I wish you fulfillment, happiness, good health, and balance in 2008.

Is Your Software Throw-Away?

It's a simple question: Is the software you or your team is building throw-away?

Really, the question that should be asked is a bit more complex, and the answer arrived at is one that should be shared with the team openly and candidly, and it should serve as guidance to many of the decisions made throughout.

Many of the very talented and skilled software development professionals I've worked with want to be part of a team creating a superior product, doing very high quality work. It instills a kind of artisanal pride, and there's an allure to being part of an effort to create a lasting piece of software development mastery. An enduring triumph, if you will.

I would argue that there is, in fact, a tendency for most teams undertaking the creation of a software product to veer toward overbuilding software in lieu of clear guidance as to how much quality and sophistication is enough. By the same token, I have also seen a great number of overzealous product managers push an agenda of supreme quality at the risk of project viability. And, of course, we've all seen the opposite, as well: rushing a project out the door, only to pay the price in spades later.

In my experience in solution and enterprise architect roles, some of the most important factors that have weighed in on the architecture and design decisions have been cost-benefit criteria. In short:

• What are the costs to the business of delays of the system's roll-out?
• What are the costs to the business of delays in making changes later?
• How long will the system be in production, and how does that translate to maintenance costs over the product's life?
  
• What are the impacts of errors in the system?
  
• How likely is the technology to change in the near future that the product is built on, and will the company look to follow prevailing technology change cycles?
• How tied to core functions of the business is the software?
• What is the realistic likelihood of the system needing to be adapted to a new setting? (i.e. new country, new line of business, new language, corporate spin-off or merger, etc.)

Without answering these questions and more, you can never be completely certain that you're building the system in the right way. What is perhaps a little tougher to crack in this cost-vs-effort calculus is whether your current thoughts on any of these issues accurately reflect the future.

There are a lot of proponents of formal processes - formal requirements gathering, formal architecture, formal design, formal QA, and so on. Anyone who knows me and has worked with me knows that I believe a certain amount of all of these things should be consciously chosen based on the best-informed answers to the questions above. But, choosing the right amount is a delicate art much more than a science.

A friend recently asserted that I might not mesh well with a particular company we were discussing because that company didn't have a level of process rigor that he had come to associate with me. In truth, though, I think there's an appropriate amount of process that should be associated with each undertaking. It just happens that on recent engagements I've been part of undertakings that were to serve as core business function enablers, which meant we needed teams and processes that were more disciplined in nature, probably trending toward the median of the complexity range or perhaps just a little to the high side. I've also been on projects in the past that had well-understood short shelf lives, and these projects received much less process rigor, but it's always based on context and a conscious, calculated decision.

Focusing some of this discourse on the requirements, architecture and design pieces, the key reasons for performing these exercises in the first place in my opinion are:

1. Communication
   
2. Organization
   
3. Thinking through problems "on paper"
   
4. Project and corporate memory

Communication is paramount when dragging product visions and requirements out of people, when conveying design concepts, and when articulating plans. Formal communication is sometimes not necessary, though. If you're a lone developer working directly with the lone user of a very small, very simple system, it may suffice to capture requirements from meetings, log them somewhere so that the next poor sap who has to maintain the code can find them, and move on. If you're directly connected to the customer, with no middleman so to speak, then communication is a bit more natural and of course direct. There are obvious trade-offs down-stream to short-changing formal communication, which is a key issue some have with XP, Agile, etc., but the important question is not "if", but "how much is the right amount, both now and for the future".

Organization is vastly more important in cases of regulatory compliance, contractual obligations, in large and/or complex projects, or with a distributed workforce. Organization can be done by the team itself (think scrums, XP, etc., in the vein of self-orchestrating mechanisms), or can be done using heavy-weight processes with product lifecycle suites that can manage all artifacts related to the project in one place even with a distributed workforce. You would likely use a different organization approach to adding a page to your portal than you would to creating a multi-product, multi-vendor, multi-team, multi-million dollar health care system which lives would depend on and that would be subject to regulatory scrutiny.

All software projects involve R&D, thought-problems, uncharted territory, investigative research, and puzzle-solving. If people already knew how to build it, it probably would already be built and you wouldn't be reinventing the wheel (or one would hope - I know that's not always the case). But, how important is knowing why the team made a decision? How important is being able to track a series of decisions or actions? If the product will have a steady owner for years, maybe not terribly important. If it will pass through many people's hands, it may be critical. Tactical decisions made after release 1 of a product tend to be the force that erodes otherwise good architecture. Those decisions can be made for any number of reasons - laziness, time crunch, unfamiliarity, incompetence, you name it. Sometimes the documentation is there but nobody bothers to read it before making changes, so the formal documentation of why and how within a particular design would be ignored anyway. And, for some, formal modeling using UML or Visio's amalgam of elements is more constraining than simply drawing on a board. Knowing what the dynamics are today and in the future will help guide how much thought process should be captured and saved, and how much time and money to spend on the process of designing formally vs. designing on the backs of cocktail napkins. It'll happen one way or another, since it's an important part of the creative process for many, but the question is rather how much you care about formally representing it and making it consistent among projects and teams, and how you want to ensure it is leveraged in future actions.

And, finally, project memory. All of what I just mentioned speaks to this fourth point. How important is it to retain the "why" and "how" of your software systems? In some cases, it may not be that important. If you have a highly stable group of cross-trained professionals who are deeply familiar with the systems, it may show relatively little value to spend more than the minimal amount of time focusing on capturing formally the information and gyrations that went into creating them. This also assumes, of course, that the company will remain a static size and that your employees will never go elsewhere. However, the right answer here usually comes down to answers to the questions asked above. The importance of project memory goes up significantly in cases of outsourcing or partner-led initiatives, complex/large systems, systems that enable core business functions, reusable or composable functionality, in companies with high turn-over or frequent reliance on contractors, and with systems that are likely to enjoy a long life.

Understanding what the business is looking for out of the system, how much that's worth to them, and bringing that into balance with what the IT department needs in order to make a respectable return on the investment both in the near term and in the long run are tall orders to fill. But, to create synergy between the business that the technology serves, and the practitioners bringing it to life, this is an area that should be focused on with each new undertaking. When it's a whopper of a project, make sure everyone knows the level of specificity and attention to detail and historical record required. Likewise, when it's a one-off that will only be justifiably pursued if it can be brought to life with minimal expenditure, have a plan in place that is rational and has the minimum expectations in each area clearly spelled out in order to ensure that the business gets what it needs and the IT department can still make sense out of it toward the end of its life when maintenance or integration is required, as is almost always the case.

This ignores all of the factors that swirl around leveraging and feeding enterprise architecture, but for projects that are in-flight, hopefully this offers food for thought on how to right-size the project to meet everyone's needs, both short-term and long-term.

IT Leaders and the Lingering Need to Create

I've had an interesting series of conversations over the past month or two that have followed a theme. I've talked, in some cases directly and in other cases in a round-about way, with a few different leaders on the subject of creating, and there so far has been unanimity on the subject, possibly at least in part due to the similarity of backgrounds of the leaders.

In all cases, we agreed that the rewards of leadership differ from the rewards of being in a creative role, such as a software developer, data analyst, application architect, etc. On leadership, the consensus among this group was that reward came in the form of seeing the people around you succeed in their personal and team objectives and grow as individuals. While being very rewarding to the types of leaders whose style is to focus on motivating, guiding, and nurturing their teams to reach their full potential and strive for excellence, it often doesn't yield tangible rewards that the leader can directly point to and say "I created that!" After all, if you're leading well, they created that - your role (at least in the leadership style I'm discussing here) is to have enabled and empowered, and to be proud and praiseful.

The other type of role, where one creates, has rewards that can be outwardly seen. When a piece of software emerges from your efforts as part of a team, there is something to point to and be proud of. Many of the IT leaders I know, especially some of the best, came from roles where they created things or were part of the team that created things - business analysts, project managers, architects, developers, data analysts, etc. In many cases for these leaders, there is a small void created when they are no longer creative within the IT context. The pride of creation and craftsmanship is lost, replaced with a different kind of pride, but one that doesn't necessarily fill the same need.

This can make for a tough transition for some IT leaders from someone who creates to someone who leads those who create. The creative drive that inspired them to get into IT in the first place doesn't just disappear. And, so, I think it's important to recognize the need, and have a way to continue to embrace and feed that need. Especially during a transition from creative genius to leadership phenom. For some, when a dissonance occurs after reaching a career goal of a leadership position after working years in the trenches, this creative outlet is critical in the effort to resist sliding back into the familiar role of creative talent with its extrinsic rewards.

If you're in IT leadership now after prior roles creating, do you have a creative outlet? Would you benefit from one? If you find yourself struggling with a transition from creating to leading, respect the need to create and provide yourself with a therapeutic outlet. Just because we stop doing something doesn't mean the desire ends with it.

My Bookshelf

I was talking to a friend and colleague recently about books I've read that were influential. He commented that he most often reads technical books, but would like to explore some new areas of growth outside of the technical realm.

A few months ago, another friend and colleague began purchasing several non-technical books to improve his critical thinking skills, technology-agnostic design knowledge, and other facets of being an accomplished software engineer.

Yet another person I've been working with on a current engagement was talking to me recently about enjoying taking a break from reading technical books and focusing on such scintillating topics as time management. Clearly there's a common thread here.

In my experience, a lot of the IT professionals I've worked with get to a particular point in their technical growth where things just start to look a lot the same. New technologies resemble old technologies with prettier marketing; new methodologies look like recycled processes of old, just renamed and spiffed up for modern times.

The rate of churn is high in IT right now, with new platforms and APIs and buzzwords rolling out at a frantic pace. But, frankly, what we do in IT today isn't that much different from what we did 10 or 20 years ago. While technology evolves at a rapid pace, or so it seems from the consumer's perspective, the techniques and disciplines and even underlying technologies themselves honestly don't change that quickly.

I think practitioners get fatigued from the churn. Keeping up with a new technology stack from Microsoft every 18 months is exhausting, and there are plenty of articles out there to support that claim, so it's not just me! Eventually, I think these same practitioners begin to look for lasting self-improvement. Learning a technology has a half-life of a few years, as that technology will certainly be phased out soon enough and your investment in learning it will turn quickly into a decreasing-value asset as soon as the technology's replacement has been named.

I think this is at least a portion of what is behind, even subconsciously, the quest for some lasting knowledge and self-improvement. There is a great deal of wisdom literature that anyone can pick up and grow from in a lasting way, or at least in a way that has a longer half-life than "Learn ASP.NET 2.0 in 24 Hours". You just have to be willing to take a step back from the milieu of technology churn long enough to focus on something that transcends technology du jour.

To that end, here is a sampling from my bookshelf.

Non-technical books I've read and recommend:

• First Things First - Covey, Merrill, Merrill
• Built to Last - Collins, Porras
• Leadership and Self-Deception - The Arbinger Institute
• First, Break All the Rules: What the World's Greatest Managers Do Differently - Buckingham, Coffman
• The E-Myth Revisited - Gerber
• Danger in the Comfort Zone - Bardwick
• Zen and the Art of Motorcycle Maintenance - Pirsig
• Man's Search for Meaning - Frankl
• The Mythical Man-Month - Brooks (well, not exactly technical, but this one might be questionable on this list; still, it's my list, so here it is)
• Successories Great Little Book on Effective Leadership - Tracy (OK, I expect to catch some flak on this one, but there are some good quotes and one-line reminders mixed in with the cliches in here)
• The Art of War - Sun Tzu
• Tao Te Ching - Lao Tzu

Books I'm reading, read most of and need to go back and finish, or that are on my bookshelf waiting to be read:

• Enterprise Architecture as Strategy - Ross, Weill, Robertson
• Six Disciplines for Excellence - Harpst
• Executive Intelligence - Menkes
• Blue Ocean Strategy - Kim, Mauborgne
• Every Mistake in the Book - Lennon

Have some books of your own that you think I should add to the list? Let me know, I welcome suggestions.

Understanding the Business - Part 2

There are a lot of buzzwords in this industry of ours. I say words, but let's face it: IT people love acronyms like Dr. Phil loves quaint country colloquialisms. So, perhaps it's more accurate to say that IT people love buzzletters (though it doesn't exactly roll off the tongue, I know).

One of the big ones that I've worked with in my career is EA (Enterprise Architecture for the non-hip). For years EA has been yoked with the burden of fixing the woes of the modern IT shop supporting brick-and-mortar businesses - a way to harmonize and homogenize, a way to keep the flies out of the technology ointment. Has EA worked where you are? If your results are like mine, it's been a mixed bag.

Most people look at EA as a technology solution to a technology problem. I'm not the first to say this, but let me reiterate what a lot of very smart folks have said already: EA isn't a technology solution to a technology problem, it's an enterprise solution to a communication problem.

Most companies I've seen want to apply EA solely within the IT department to ensure quality in the software that go into the production environment (aka "build the thing right"). And, it's true, architecture is a facet of quality assurance as it can provide a lot of inputs and constraints to ensure that the products built or purchased are built right. I don't want to discount architecture's importance in building the thing right.

But, the word Enterprise doesn't just imply something, it states the obvious. EA won't live up to its potential unless the entire enterprise is involved. What's more, architecture isn't just a technical term, but I think that's actually the root of the problem: people assume architecture to be a technical discipline within the domain of technical work. Yet, the business is just as much a part of Enterprise Architecture as the IT department, each with different but connected responsibilities.

The reason EA fails is because the enterprise architects - those poor folks who are trying their best to make the technology serve the future of the enterprise - have very little true, accurate insight into the way the business works and the future direction that things are heading. There are some who have spent so long with the company that they know it as well as the people doing the work in the business, but those people are rare, and eventually they retire or move on. In short, most architects can ensure that we're building the thing right, but most lack anything deeper than surface knowledge into the business, the very knowledge that would ensure that we're "building the right thing", which is the other side of EA coin.

There are a lot of processes to make sure that we deliver good software products to the users on a per-project basis (despite the gross dearth of adherents to such processes). But, what about EA processes? Well, not too many, actually, at least not holistically speaking.

In pieces, we have EA covered, I think. There are a whole slew of buzzwords and acronyms that cover the gamut of what we need to do for good EA: knowledge management (KM), business process management (BPM), business process re-engineering (BPR), project management office (PMO), project portfolio management (PPM), business architecture, change control board, project review board, vision statements, project charters, governance, etc.

Let's pause for a moment. It would be great if EA were as easy as picking from the buzzword buffet the things that satisfied your appetite for closer alignment between IT and the business in a way that resulted in quicker results, better probability of the solution meeting the needs, the solutions being of a high quality and in harmony with the other solutions they interact with, all without spending a fortune and dedicating an army to managing it all. But it isn't.

If it were, I bet more companies would be touting how great their IT departments are at strengthening and extending their business models rather than (justifiably) complaining about how out-of-sync the IT department is with the business, how poor the quality of the results are, and how long it takes to get anything done. No, what modern enterprises with modern IT - which is to say technology woven into the day-to-day workings of the business - demands is an all-encompassing enterprise solution that begins with the C-level executives and permeates every part of the business.

What is called for is not just for technology to be woven into the business, but also a way for the business to be woven into IT. I'm not going to claim to have the answer on how to do this for every company out there. You may find some inspiration from sources like ZIFA and EUP, but I believe the starting point is something that looks comprehensively at the whole organization, empowers the business to own their business process information and strategic direction but holds them accountable for sharing and updating it proactively and consistently. It needs to create synergy between the business departments so that the left hand knows what the right hand is doing, and create ways for IT to tap into that information as early as possible and in a regular fashion in order to keep the ear to the tracks, so to speak.

I don't think there will be a one-size-fits-all answer to this new challenge. But, it is just that for those organizations whom EA would benefit: a challenge for IT leaders to spend more of their energy building a partnership with the business at the executive level in order to create support throughout the enterprise for EA from all angles and elevations. Then, to help shepherd and codify a process that can serve the entire enterprise, not just in building the right thing and building the thing right, but also in creating a foundation of understanding and communication that will lead to more productive and proactive collaboration.

Solving for X - Reducing the Complexity Within

One of the tenets of good software architecture and design is the notion of minimal internal complexity (as opposed to external complexity). External complexity is the complexity of the problem itself, a difficult subject by nature - some things we do in the workplace are just simply complex and there's no way to simplify them beyond a certain point. Internal complexity is that which we introduce.

Some might call it "swatting a fly with a sledgehammer." We've all been guilty of it at some point or another. It just happens; we think we have a clear understanding of what solution a problem calls for, but instead of doing just the right amount, we overdo it. We provide a complex answer to a simple problem.

It's especially a danger in technology. For those of us working in IT as a supporting arm within a traditional business, we deal with a lot of external complexity in that we don't ever seem to fully understand the business, always finding ourselves dragged around by the tail just a half-step behind the change happening within the business, always playing catch-up to try to understand the new model and what the impact will be, always trying to better internalize how the business operates so we can be a better partner. For the most part, that external complexity will always be there to some extent.

And, for those of us working either directly with technology or within a pure technology-driven company, the external complexity comes directly from the work itself. Technology is a complex, ever-evolving landscape that no one can ever fully master. The best you can hope to accomplish is to be either really good at something that evolves very slowly (mainframe developers come to mind) and eventually fade into obsolescence (perhaps not the best career move); or, become really good at knowing how to adapt to and minimize the impact of that ever-changing external complexity. The really good technology people who stay abreast of changing technologies and who seem to move effortlessly from old to new tech as the landscape evolves have mastered just this art.

But, there's a more insidious danger in the technology world that stems from the internal complexity that we add to an already complex field. Taking it as a given that we are already tackling challenges of external complexity, it would seem to behoove us to simplify as many other areas as we possibly can. I liken this to an algebra problem where the student is asked to solve for x.

In an algebra problem, one often has a combination of variables and constants combined into expressions within an equation. Take an equation like this (my examples and definitions come from here):

7x - 2 = 8 + 2x

The steps for solving algebraic equations look like this:

1. Combine like terms
2. Isolate the terms that contain the variable you wish to solve for
3. Isolate the variable you wish to solve for
4. Substitute your answer into the original equation and check that it works.

Not too tough for an equation like what's listed above. But, what about something like this (I made this up, the aforementioned site isn't to blame for this one):

(ax/wq) - p * r = u²/(zc/kl)

Suddenly the equation is far more complex, and there are no constants, just variables. You might be able to isolate the variable you wish to solve for, let's say x in this case, but unless someone gives you the values that the variables represent, you won't be able to come up with a number that x equals.

Allow me a new but related tangent for a moment. My wife gave me a gift when we were younger: a paperweight. In the spirit of full disclosure, I should confess that I've never understood paperweights. I've never had paper that required weighing down while in the confines of an office. I guess I just don't work in drafty places. But, this paperweight has a quote from Francis Bacon that is always on the forefront of my mind: "Constancy is the foundation of virtues."

Now, not only do I think paperweights are dumb, but I thought that quote was dumb, or at least vague to the point of my dismissing it. Quaint? Maybe. Brilliant insight to life and the world around me? Not as far as I could tell. I politely thanked my wife for the thoughtful gift, and then... weighed down some papers with it. Splendid! Those papers went nowhere, so the paperweight was deemed a successful addition to my desk.

Years later, though, the simple brilliance of this quote struck me like a lightning bolt: It is the certainties in our lives, the constants, that enable us to tackle the variables. Now, that's what it means to me, and as with most quotes you lack the context, so maybe it means something altogether different; but, what's important (to me) is that it carries meaning now that resonates with me in a profound way. Those steady, bedrock aspects of our inner selves, as well as our outer world around us, are the things that give us a firm footing from which to strive to achieve something just beyond our ready grasp.

I should take a moment to mention that my wife is the most brilliant gift-giver I've ever known. She somehow taps into a person's inner self and finds something that even they might not know they need or want, something that adds to their life, not just to their collection of useless knickknacks. So, my appreciation for the paperweight has grown since it was originally given, and over the years my awe at my wife's gift-giving genius, among her many other inspiring qualities, has deepened. When I think about the constants in my life that have helped me to grow and achieve, she's at the top of the list.

As I've been confronted by ever-increasing external complexity in the workplace, I have seen an increase in the internal complexity introduced as a foil to the external complexity that well-meaning people are trying to deal with. But, as you can imagine, internal complexity doesn't quell external complexity; it amplifies it!

If your organization reminds you of the second, more complex algebra equation more than the first, what does that tell you? If you are in a complex environment that lacks constants, does that environment produce quality results in a timely fashion? Are people inspired, empowered, fulfilled and rewarded by the work they do? Or is it an environment that creates churn, frustration, animosity, political games, communication disconnects, information silos, sub par work, and frustrated partners and clients? I've seen several environments where smart people couldn't even figure out where to begin attacking a problem, because there were too many other variables that weren't yet settled: shifting org structure, undefined communication pathways, unclear/absent/confusing/onerous processes, unclearly defined responsibilities, turf wars, you name it.

If your people are struggling to be effective in accordance with the goals and principles that matter most in your organization, I urge you to take a good hard look at whether their equation has more variables than constants. Find ways to create the stability and firm footing that will serve as the foundation of the virtues you want your organization to embody and the support for solving the variables that matter most.