Authority vs. Influence in Leading Organizational Change

Authority – the power or right to give orders, make decisions, and enforce obedience.

Influence – the capacity to have an effect on the character, development, or behavior of someone or something, or the effect itself.

Authority is power.  If you want to rule the galaxy by power, then join the dark side of the force.  Influence is ability. If you want to lead the galaxy by working together with the citizens to solve the problems, then continue your training to become a Jedi Knight.

Early on in my career I would always say to myself… If only he had the authority to make these things happen. It would be easy. I had some misconceived notion that being able to say what needs to be done would equate to those things actually being done.  I would simply create a vision, tell the organization that they had to follow this vision and I can move on to the next challenge.

As I progressed through my career I moved into positions with authority.  My dream finally came true… I would not need to spend a long time campaigning to the mass number of people to get their buy in, I could simply give the marching orders.  Although this helped change move quicker, it was not long-lived.  The moment we achieved the goal or I redirected my focus to the next opportunity, the previous initiative would fall back to its previous state.

Authority gives you immediate change but it's not long-lived. You can tell somebody what to do.  They may do it for the moment.  Unless they understand what the problem is that you're trying to solve and why you're doing it, they will not continue doing so after the change.  

Authority causes people to act on orders/tasks.  Influence is working with people to understand and solve the problem collaboratively together.

In dealing with organizational change, I have learned a great deal of what is needed to help move the critical mass from their current state to the desired state, and to ensure sustainability.  I have had to develop a skill set to connect with people, build their trust, unleash their passion, grow their confidence, and move toward a shared vision.  Being able to influence takes a lot of work.  You don't get there overnight.  You need relentless pursuit. The ability to be open to refine the vision as you get insight from these people.  Give autonomy to those people affected by the change.  Lead by example.  Build long-lasting relationships.  Earn respect.

Influence is when others accept your ideas or direction. It means that people have internalized your message. They believe it. They might even be excited about it. 

Authority causes people to act on orders/tasks.  Influence is working together to understand and solve the problem.

For long-lived organizational change you need to put in hard work toward influencing the people.  People are very habitual.  To develop these habits it takes time.  We do not quit bad habits, rather replace them with good habits.  Make being a positive influence your habit.  Having influence with others does not only make you a fantastic change agent, it also makes you an fantastic colleague.

In future posts I will speak to this specifically in the context of Organizational Agility Transformations.

David Dame

Standardization and Autonomy - Can they co-exist?

Companies have two avenues for growth: acquisition, or organic growth.  Regardless of how they are growing their increasing size increases the difficulty of the company successfully responding to change.  Retaining as much as possible of advantage of that small company’s ability to rapidly pivot can be a key element of a company’s success.

In the past, large organizations were seduced by the notion of having a standardized process across all their product teams within the organization.  I can understand the appeal of having one “best process” uniformly across the organization.  However this appeal is based on a manufacturing paradigm of working with tangible items which does may apply in other industries.

Process standardization at the organizational level gives the benefits of:

• common reporting/monitoring processes, formats, and channels
• simpler governance decision-making

One other presumed benefit is a reduced cost of moving teams around the organization, but this is rarely realized because intellectual work cannot be mass produced.

A model of a large organzation

Having a standardized process across the organization forces process design to accommodate the lowest common denominator.  It also takes a larger effort and time for the organization to be able to pivot and adjust  to move as one entity because of the critical mass.  From a people perspectives, employees feel like there a cog in the wheel and they're not motivated to improve how they work because they believe it is a big bureaucratic exercise (which it usually is in large organizations) that "other" people have bestowed down on them.  This standardization comes at a huge cost for productivity and efficiency within the majority of the product groups. 

Giving product groups (and teams) autonomy empowers them figure out the best way for them to work as smaller units to optimize productivity and efficiency.  Smaller teams can have shorter feedback loops and can inspect and adapt more frequently and progress more quickly.  Smaller scope for process design allows them to optimize more precisely because it is based on a smaller set of skills, expertise, team makeup, and particular product/technology.  

From the people perspective, giving the individuals autonomy to define how they work, how to best optimize their own work leads to higher morale, motivation, and productivity.  Even when the technology changes over time, giving the autonomy at the smallest reasonable unit allows them to rapidly go through and adopt the change quicker.  It also allows each product group (and teams) inspect/adapt/change at the rate that is within their threshold and within the context of their business needs.

Autonomy is one of the factors a motivation that Daniel Pink talks about in his book Drive.  I think we can all agree that we want to motivated workforce.

The downside of that autonomy is that the operations of the organization becomes less transparent.  Or simply, make it more complex to be able to see if your organization is moving forward.  

Can you marry the two to get the best of both worlds?  In my experience, YES!

View fullsize

You can do this by loosely defining workflows and processes from the above at a very high level and .  This way the organization knows that the highest level of the flow that goes through to deliver products or services.  When product groups (even teams within the groups) create their own processes and practices they do it and to detail out between the boundaries that they have to play with.  The organization themselves reports on the high level processes to be able to monitor how all the work is progressing to be delivered.  Each product group can define their own product group practices and processes for all the teams within their product group, trying to define them at the highest, but still responsible level to allow individual teams discern autonomy and how they specifically meet those.  

A good example would be The Definition of Done.

The organization will have guidelines that they want all their products and services to ensure encompasses what they call a releasable product.  Each product group will have their level of definition of done that meets their particular products needs in order to transfer the product is ready to be released to the market.  Furthermore, each team will have their own specific  definition of done that addresses all of the above in any specific things that they feel they need to do to produce releasable software.  This should help ensure transparency from the top down.  This also allows for easier updates at the appropriate level without it being all or none.

One thing that I did not mention in this post, is that this hybrid will cause more work for external auditors because they will not have one central place to review the processes.  However, I would rather put the burden on a few than many of the organization.  The regulatory auditors are going to have to just the way in which they audit software companies going forward to meet the new agile paradigm.

This is just one of the scaling mechanisms that I have seen prove successful.  I will be sharing more and hope to hear back from you about techniques that you have used in scaling agile across a large organization.

David Dame