|Where are you headed?|
Unclear directionLet's face it, when your direction is not clear, how can you expect anyone to follow you and be clear about where they are headed? The easiest way to find out which direction people are heading is by asking around. Grab ten people at random, invite each individually to a coffee and ask them what the direction of the company is - and how they are contributing to the effort. The answers may be sobering. Are you aware of potential conflicts between different goals that you did set? How do you expect others to resolve a conflict you have generated?
Articulate the one, singular course you are setting in one sentence. Avoid long sentences, avoid "and" / "or" clauses - and use simple terms. Ask yourself "Does that make sense?", then get feedback from others. If they need to interpret or misunderstand you, rework. After you came up with a powerful, yet simple statement, use every opportunity to communicate it. Do others quote you correctly?
Conflicting prioritiesGoals can conflict on many levels. Even company goals can clash or contradict one another. For example, you might set the goals of "being the most agile company in the region" and, at the same time, "growing the business by selling new services". Sounds simple enough. But: What do you prefer? People working on becoming more agile, or people working on introducing new services? You can say "Both", but: where is the priority?
Managers easily fall into the trap of simply adding new objectives, without clarifying how they fit into existing priorities: Do they override, abolish or subject to existing objectives?
Keep the list of objectives short, as with each additional item, you are adding confusion.
As long as you are simultaneously pursuing more than one goal, be very clear which is more important. Whenever you are setting new goals, take your time to clarify what this means to existing objectives. Do not hestitate to openly abolish existing goals, to help your employees be clear that they are no longer valid.
Systemic inconsistencyThe goals you set are actually irrelevant as long as your organization makes it impossible to each these. For example, you can not set the goal of "becoming an agile company", while keeping existing roles, silos and escalation policies in place.
Before setting a goal, spend time to understand which forces in your system contribute and/or distract from this goal. Actively work on resolving issues which distract from or oppose the goal you have set.
Perverse incentivesSometimes, you want to achieve a certain goal, yet there are (dis-)incentives within your system that make it unattractive to reach that goal, leading people inherently to pursue different goals. For example, you might set a goal to "let everyone work in Scrum teams", and then forcing people in Scrum teams to abandon their chosen area of focus and expertise, nurturing resistance rather than support for the agile transition. Another example of perverse incentives might include providing new responsibilities to grow people, without rewarding the obtained results: you're actually encouraging people to find a better job elsewhere - or resist personal growth!
When you have a goal, spend time to think "What could happen when people do this?" Put on different thinking hats and think of potential consequences. Keep in mind that you are working in a complex system, and the more complex your organization is, the more likely you are forgetting some important constraint!
Whimsical inputWhen you just need something done, it's very tempting to find someone who can help you with that and set them right on the task, especially if it's just a small thing. This does affect both the autonomy of whoever you are talking to as well as their otherwise determined objectives. Are you aware of what your simple demand does to the overall company strategy?
Here is one example: Jim is your expert on explorative testing, so you want Jim to hold a workshop for all interested employees: It's just two hours. But: Plus preparation time, Jim may not be contributing to the team's primary objective for a full day. Did you consider whether exploratory testing is even needed - or appreciated - by the others? You are quickly opening a can of worms with every single, simple request.
Scrum is very clear that nobody, NOBODY except the Product Owner gives work to the teams - and even then, only in rare, special circumstances can that be done outside pre-determined planning intervals. Get used to the idea that any form of assignment, even voluntary, is not your job.