On Individual and Departmental Goals

It’s that time of year again whereupon three months into the year, organizations everywhere begin the exciting task of examining the tabula rasa of a new year filled with potential of achieving amazing things. As part of that task, many organizations set goals for individuals and departments in hopes that they will lead said individuals and departments to greater success for the company. There is no shortage of information on this topic, freely available after a short Google search.

One common theme to goal setting is that they must be SMART which is a fun HR derived acronym for Specific, Measurable, Aggressive, Realistic and Time-bound. Substantial evidence shows that goals set in this manner are in fact correlated with happier, more motivated employees and greater success in the achievement of the goals. However, I would argue that the resultant success and happiness are not caused by the fact that goals are SMART but instead by the underlying process through which the goals are worked towards. It is quite feasible that an organization would set SMART goals and then still have highly unhappy employees who achieve few if any of the goals nine months later. This happens because goals alone are useless regardless of how SMART they are. Goal achievement relies on the underlying system and strategy that support the goals.

Scott Adams has written about the difference between systems and goals. We all have regular experience with goals gone awry. Many of us are sure this will be the time that we lose 20 lbs or exercise more or read more books or whatever. It does not matter if the goal is SMART or not. I can say “I will read 24 books in 2021” which is Specific (read more books), Measurable (24), Aggressive (I read 7 last year), Realistic (outside any context of course which is critical) and Time-Bound (one year). But if there is no underlying system and strategy for accomplishing this goal, all the smartness in the world will result in the same failure.

A system is a set of things—people, cells, molecules, or whatever—interconnected in such a way that they produce their own pattern of behavior over time. The system may be buffeted, constricted, triggered, or driven by outside forces. But the system’s response to these forces is characteristic of itself, and that response is seldom simple in the real world.

Donella Meadows, Thinking In Systems

System has a specific definition and meaning in this setting. It is the interconnected nature of the pieces of the system that produce the results that the system outputs. In order for an organization or a department or an individual to achieve goals, there must be an underlying system of management designed at least in part to facilitate the necessary behavior of goal accomplishment. If this system is designed, either intentionally or more often haphazardly, to produce behavior other than goal accomplishment, no amount of SMARTness will ever overcome it.

A trivial example applied to my desire to read more books. On its face, the goal seems SMART. However, that is only so if the underlying system that I use to make choices with my free time has taken into consideration the constraints on that time. Unless I have examined the amount of free time I had in 2020 and discovered a great deal more of it and then dedicated my future expenditures of that time to reading via a disciplined schedule, the goal of 24 books is much more likely to be DUMB (Definitely Underestimating My Behavior) than it is to be SMART even though on the surface, the goal seems to conform to the definition.

I would actually argue that one of the core principles of good management is the diagnosis and analysis of the Realistic in SMART. This is the area where management skills make or break the underlying system that allow successful goal achievement. In order to determine if a goal is realistic, a manager must understand and be able to answer the following questions:

  • What is the underlying system of how work gets done by the organization?
  • What is the underlying system of how work gets done by the department?
  • What is the underlying motivational type of the individual (if setting individual goals)?
  • Are all of these cohesive with each other?
  • Are they congruent with each other? (see Esther Derby’s work on Change and Congruence)
  • What are the constraints on work within the system?
  • How much work can the org, department or individual realistically do given the system within which it operates?
  • And so on and so on.

The key to successful goal setting and achievement is to have an underlying system of behavior that clearly defines what is realistic. It is not realistic to lose 10 lbs if you do not throw away all the Cheetohs in the pantry and continue to eat donuts every Saturday morning because it is a family tradition. The system that includes Cheetohs and donuts will overcome any amount of SMART goal setting because it is the system that produces the behavior that leads to outcomes. It is not realistic to have 8 priority one departmental goals if the underlying system of the organization is such that at any moment the entire department may be reallocated to focus on unrelated organizational goals.

A good manager understands the constraints on what is and is not realistic for an organization, department and individual. Here lie the dragons of management. Most goal setting exercises I have been a part of have applied a great deal of wishful thinking and magical handwaving around the capacity of the organizational structure. Most of these exercises identify several things that seem highly desirable and then ask “can we do all this?” Because humans are naturally inclined to be good, your experience with social media notwithstanding, the result is often a half-hearted “yes” if only so that we can get on about the business of actually doing work. But in order to have not only successful goal setting but also goal achievement, we must have a more rigorous system around what is realistic. At the very least, a manager must understand the constraints of the system within which she operates and have a strategy for dealing with those constraints.

The strategy work of Richard Rumelt is very helpful here. Specifically, we must realize that good strategy is about policy choice and commitment to action. We have to write strategies for our goals that lay out policies to guide action towards the system behavior that we want. We must lay out consequences for violating the strategy and be prepared to defend them. Circling back to my personal goal, when I discover I have 30 minutes of free time and am thinking about practicing my guitar, I must realize that this hampers the realistic definition of my reading goal and that there are consequences to that choice. The same goes for reducing technical debt of an engineering organization. When faced with opportunity of some free time, if we fill it with yet another story delivering business value instead of dedicating it to removing NHibernate (don’t ask), we have violated the Realistic nature of our goal. To prevent this from happening, we have to have hard policies that say things like “when presented with available resource time, we will always choose to apply that time to the reduction of technical debt”. This guides teams actions but does not dictate it. They can still choose what actions to take within the guardrails of the policy. We must also then ensure that free time both exists and is encouraged. If it does not or cannot be created due to organizational constraints, no amount of SMART goal setting will ever result in a different behavior.

By building a system that produces the behavior we want, goals become mostly secondary in nature. If there are clear policies and feedback loops built into the system to confirm, analyze and affirm behavior, goals will just happen. We must understand the constraints of the system and operate within them as well. We must know the inputs and the outputs of the system and how those interact to balance or reinforce behavior. We must work to ensure that goals are written in such a way that they do not violate the boundaries of the system because that guarantees failure. Successful goal setting is really about system design and is just as hard as more concrete problems like making an API faster or migrating to the cloud.

Restricting Choice

I’m in a book club at work and the current book we’re reading is Good Strategy, Bad Strategy by Richard Rumelt. It is an examination of strategy mostly as it relates to the business world. Most books of this type are barely more than self-help books so one might wonder what makes this book particularly special. Five chapters in, my initial take on that question is that it highlights and enforces the idea that choice and the narrowing of choice is critical to success in almost all endeavors.

So much of strategy work in the world results in grand plans of goals, visions, dreamy ideas of success, and imagining yourself as successful. But none of these things are really strategy. None of them aid you in moving forward in coherent ways towards an end game. You have to establish what constraints you are trying to solve for, define some policies that act as guard rails for action and then begin to act within that structure. This necessarily restricts your actions in the problem space. You can’t have your cake and eat it too. You must choose a direction and then act on it in order to improve. Of course, there is no guarantee that you will choose correctly and therefore you may not actually improve. But without that choice and the constriction of the problem space, you are guaranteed not to succeed.

This relates directly to my post on managing inertia. Inertia is the embodiment of inaction. Worse, it is the impedance of action because it is resisting, actively and passively, the effects of action on the body you are trying to move. Whether you are trying to push a car to a gas station or change how your organization writes software or get your four year old to clean up her room, the current movement of the body through space tends towards the same direction that has always been acting on the body in question. As these bodies grow in an organization, so does the complexity and the difficulty for change. As that complexity changes and grows, so does the problem space and the possible actions for the solution. Many times in an organization, without the difficult strategy work of restricting the problem space and thus the opportunities for action, nothing changes because either actions work in direct conflict with each other or are not coherent and contribute to different goals.

For example, you might want to migrate or reclaim some software or maybe improve some part of your engineering department. You grandly say “Go forth and do this”. Then, 5 months later, you find out that while lots of people have been talking about lots of actions, nothing has really happened. But why? You told people to go fix this thing. Unfortunately, no actual constraints were placed on the actions of teams and because there were competing goals that you explicitly or implicitly endorsed (like continue to make money and add features to said software), nothing meaningful happened.

To fix situations like this, policies must be written and then enforced that constrain the actions of teams down to the classes of behavior that solely support the goal. In the example above, a policy would need to be put in place that no new work will be done on the existing software other than bug fixes and critical patches. You know that you have written a good policy when you can read it and see that it will cause pain, perhaps for yourself. It will make some people upset or annoyed or worried because something they are used to doing (probably because you told them to in the past) is being eliminated. Without this feeling of pain through the restriction of choice, success will continue to be out of reach.

Much of this seems applicable to the personal as well. I struggle with making progress on almost everything because I never sit down and restrict the availability of choice. I want to learn the guitar and Spanish and do some writing and read more books and be a better woodworker and be a better father. In the end, the multitude of choices overwhelms each other. Even if I act on all of these in a given week, barely any progress is achieved because there is no focused effort on a singular goal. A better strategy would be to restrict choice to a single activity or set of actions until the desired level of mastery is achieved. This actually should be easier at a personal level because there are no competing organizations or groups all with their own inertia. The guiding policy wouldn’t be nearly as complex. “In my available free time for the next quarter, I will practice the guitar.” At first, it is very limiting. But it is also quite freeing. I don’t have to think about learning Spanish or woodworking (though being a better father is sort of just an overarching thing worth working on at all times).

Success only comes from the combination of decision and action. Constantly wanting the best of everything will necessarily result in wish-washy results whether personally or in business. This is the hard part of strategy work and involves difficult choices that most people prefer to avoid because of their implications. I may not learn Spanish if I only practice my guitar which depresses me so instead I never commit and therefore always have the potential to succeed at both. I may have to stop making as much money in my business if I commit to improving technical processes and outcomes which will make me sad and so I’ll just hope that I can do both and that it will all magically work out. This is what makes management so frustratingly hard. It’s something I’m coming to terms with through experience. The restriction of action space is the only way to truly succeed and that often will result in difficult conversations and directions even if only with the voice in my head. But without this restriction of action, the natural tendency is to keep doing the same things because of inertia and as they say, if you think you’ll get different results doing that, there’s a place at the asylum reserved.

Managing Inertia

In Simon Wardley’s business strategy methodology, Wardley Maps, there are a class of behaviors you can take in all contexts to improve your ability to act strategically and improve your chances of success. These are called doctrine, universal rules that one should use across contexts. By analogy, in war, you have a doctrine to train your soldiers to shoot before you go into battle or in chess, you should learn the moves of the pieces before playing your grandfather. Doctrine isn’t a sliver bullet but it is guiding principles broadly applicable to multiple situations.

These doctrine are applicable to certain broad categories of activities you might take: Communication, Development, Operation, Learning, Leading and Structure. One of the key ones in Operation that intrigues me is Manage Inertia. This applies to the broad category of operating the business, of doing the day to day things that allows progress to be made on a variety of fronts. A formal definition of inertia is the resistance of any physical object to a change in its velocity. In business, the physical object takes on other definitions and could be a team, a process, a piece of software, or any number of other constructs. The fact that inertia exists in your business is A Good Thing. It’s a sign of success because without past success, continuing to do the same thing would be pointless. It is the fact that inertia rises out of past successes that creates a paradox and the need to deal with it. Much like your brokerage telling you that past success is no guarantee of future performance, Tesla notwithstanding, business success in the past must be often disregarded so that change can happen and the business can evolve.

Inertia in business manifests in particular ways. Organizational units that have achieved success in the past will be unwilling to try new things or learn new processes. Software that has become successful will over time become ossified as more features are added to it in its current structure, cementing design decisions into place. Processes like Scrum or Six Sigma fix initial problems and then are never revisited for examination. The paradox here is that the business landscape is always changing. Businesses must adapt in order to have continued success but they have tendencies to stay the same. This is how the brash startup can disrupt an established player in a vertical. The startup lacks the inertia of the established that acts on every part of the business to keep it from changing for its own good.

Often, certain elements within an organization will, consciously or not, chafe against the inertia and push to make radical changes. In the software landscape, this is often expressed as rewriting some piece of the business’ software after a period of time because technology has moved on and improved. In the best case, this often is a push out of the development teams who see improvements to technology and methodologies and want to do things better. In the worst case, it can be a lack of good business strategy that allows a rogue element to begin a project without guidance or a clear road map. Typically, it’s a little of both.

These rewrites can in fact be successful. With enough engineering firepower and good leadership that focuses on business value and quick wins, rewrites can be done in a way that leads to a rapid evolution of the existing software. However, more often than not, none of that is true. The business focuses engineering talent elsewhere leaving the rewrite understaffed. Management, somewhat out of touch with the landscape as well as the day to day activities, prefers to just sort of hope things will turn out ok. Hard decisions are avoided. The organizational inertia towards the success of the past weighs heavily. This inertia is far more powerful than the average engineer or engineering manager understands.

Other organizational units that interact with the working system have developed rules and processes for that interaction. Over time, through the success of the software, they themselves have become successful which leads to inertia from a different quarter. The marketing team has learned to use the software for its benefits. The business insights group has learned how to get data out and into the hands of stakeholders in a reliable manner. The business executives understand the vocabulary and the predictability of working software. All these sources of inertia work against a rewrite and must be managed thoughtfully and strategically or else the project is doomed.

So we have a paradox. The business must change in order to adapt to an evolving landscape. But the business must not change because what they are doing is successful. Navigating this landscape takes planning and must be done constantly as maintenance on existing systems, no differently than the oil must be changed in the car. Managing this inertia, while a general doctrine, involves critical thought applied to a particular context. There is no silver bullet. Perhaps you can reclaim your software. Perhaps a rewrite is the best plan. But if so, all the sources of inertia that act on the organization must be taken into account and mitigated. You cannot suddenly change a significant chunk in a successful business. The business reached a stable state through time and evolution and a sudden rupture in that stability will rarely succeed.

This management of inertia involves consensus and partnership across organizational units. The irony of course is that the drive for change often arises because one organizational unit has grown tired of the existing inertia and seeks to overcome it by moving alone. However, in a successful business, there is no alone. All units are connected, however tenuously, and the smaller the business, the stronger the bonds between units. So these moments of punctuated equilibrium where a unit thinks they can rapidly change something that the entire business relies on are largely doomed to failure. Conway’s Law cannot be ignored.

How then can we ensure inertia won’t kill us over time? Good strategy goes a long way. By analyzing the issue and developing policies that guide teams’ actions, inertia can be used against itself as small successes help teams develop confidence in their ability to manage change in the organization. A policy that says “we will always be on a framework version within one major version of the current accepted version” will guide teams actions in their planning process and insure that improvements in technology work their way through your system. A policy of “As a team, we will spend one week a year exploring the landscape of our current technology stack” will help sharpen skills and invites broad participation. Policies are critical to guide behaviors and actions. Without them, there can be no consensus on how to move forward.

Overall, the management of inertia is a function of good management. This seems trite but is critical. By defining strategies and policies that guide actions across an organization and then enforcing these policies over time, inertia can be prevented from becoming ossification. Without this management over time, software will grow in size and complexity to a point where changing it becomes perilous and rumblings of replacement will grow louder. It is unlikely at this point that excellent management will suddenly leap out of the fire to guide a difficult project to success. As in health, it is always more advisable to take small steps over time rather than have heart surgery as a strategy. Managing inertia must be consistent and well-guided to allow the business to evolve as circumstances warrant.