Why Guardrails Can’t Be Defined Ahead of Time

Why Guardrails Can’t Be Defined Ahead of Time

There is an idea that a leader can delegate to team members and specify “guardrails”—the line between what the teams are empowered to decide and what leadership retains decision-making over.

That does not work.

At least, not in a product development setting.

It doesn’t work because it is impossible to know what the issues will be ahead of time. For example, you can’t say up front, “You can decide whether feature ABC in the backlog should be one or two microservices.”

You can’t say that because to even know that that issue will arise requires delving into the design of feature ABC—but that won’t happen until work is about to begin on it. In other words, you can’t anticipate it until you are right upon it.

So you don’t even know about the issue ahead of time. And if you try to characterize all of the kinds of issues and which side of the guardrail they should be on, you will go nuts.

It is possible to specify general guardrails, such as “You can decide technical issues about microservices”, but that is very ambiguous. It will inevitably lead to situations in which some people interpret it in one way, and others will interpret it another. Suppose, for example, that a team decides that they need to change a microservice that they built and use, but that service is also shared by another product? At that point your guardrail fails. Again, if you try to specify all the myriad conditions, you will go nuts.

It is possible to specify general guardrails, such as “You can decide technical issues about microservices”, but that is very ambiguous.

It is only when the issue becomes concrete—when there is a specific situation that must be decided—that it is possible to define the precise boundary between what the teams can decide and what a leader might want to retain control over.

Let the Teams Rule Every Issue—Or Not?

An extreme approach is to let development teams decide absolutely about certain issues; so, for example, on anything related to how they do their work, they decide, period. You accept the cost of poor decisions, hoping that teams will work those out over time.

But in business, time is everything. If you wait for a large group of teams to work through every issue, will you miss important market presence? And will costly mistakes be made?

It might also mean that some teams do things one way and other teams decide to do things another, and individuals on teams decide to do things their own way as well, because—after all—the Agile Manifesto’s first value begins with “Individuals”, not “Teams”. Letting everyone decide completely on their own, using very blunt guardrails, is very risky.

Dialogic theory tells us that groups of people are a complex adaptive system, and that they will evolve their own narratives, memes, and approaches over time. That is true; but that does not mean that they will evolve in a positive direction, or a unified one. Just look at the political division that we see across the world today on issues such as vaccines, masks, and left-versus-right politics. What happens is that sub-communities form, and they develop shared beliefs—their own “reality”—and one cannot say ahead of time what direction that will take.

Dialogic theory tells us that groups of people are a complex adaptive system.

Indeed, the rise of fascism in Weimar Germany was a complex adaptive system at work.

That’s why in an organization, management oversight is essential, to make sure that shared narratives are positive and productive. Intervention needs to be both dialogic and diagnostic. Not that management is a panacea—far from it. But the solution is not to eliminate management: the solution is to improve how management works. In short, we need the right leadership paradigms, for managers and for everyone in general.

Then What Should We Do?

If you cannot anticipate what the guardrails need to be, that does not mean that you should give up on the idea. Do your best to delineate the range of issues over which you feel that a team or teams are capable of deciding on their own. But don’t stop there.

Leaders need to stay involved. That’s called participative leadership. That does not mean that you micromanage people, or take away their autonomy: it means that you stay involved. You ask questions. You look at the work. You make suggestions in an inquisitive and open way. You talk to people one-on-one to ask them what they think. You advocate for them, and you share updates with them. And when you need to make a decision that you feel is yours to make, you ask their opinion—if appropriate—and if the decision affects them, then you take responsibility for it.

Participative leadership ensures that you have a clear, unobstructed view into the goings on. You don’t need to ask for status; you don’t need to look at reports. You know, because you are there, in the middle of it. Not directing, but observing, inquiring, facilitating, and suggesting. And when an issue comes up on which you feel you need to make the decision, you can say so, right then and there, and it is clear and unambiguous.

Participative leadership ensures that you have a clear, unobstructed view into the goings on.

On the other hand, a leader cannot be everywhere all the time. If people are afraid of their leader, they will not reveal when there are problems. But if they are accustomed to a leader who is inquisitive and supportive, they will proactively notify their leader when something is happening that they cannot deal with on their own. That is the kind of environment that you want to have.

Conclusion

Delegating and standing back to see what happens is an abdication of one’s leadership. Good leaders are not bossy; but good leaders also make decisions when a decision is called for, and in a timely manner, because time matters. Part of the judgment needed of leaders is to know when a decision is needed, and who is capable of making it. Ideally you want to groom people to lead themselves and be autonomous, but that is not a given and it does not happen on its own. People need to learn leadership skills. If they use good forms of leadership, guardrails are unnecessary: the leader will be present or will have been informed, and will know when to be quiet and when to speak up.

Greg Hutchins

Principal Engineer of Quality + Engineering. Founder of Certified Enterprise Risk Manager? (CERM) Academy, 800Compete.com.

3 年

Yes, process guard rails can be and are defined before hand. If a process is in control, capable, and improving, then process based guardrails can and are defined based on DMAIC etc..

回复
Michael Ward

Director Project Management Office / Agile Transformation Leader

3 年

Great Article. Leaders must be close to the work. They can't pop in and pop out which usually causes chaos and strife. Participative leadership is key.

Gianpaolo Baglione

Strategist, Technologist, Creator, Entrepreneur

3 年

“Dialogic theory tells us that groups of people are a complex adaptive system, and that they will evolve their own narratives, memes, and approaches over time. That is true; but that does not mean that they will evolve in a positive direction, or a unified one.” Well stated and very true! It echos the famous quote from Demming about how if left unmanaged systems become selfish and break down.

要查看或添加评论,请登录

Cliff Berg的更多文章

  • They Know a Collapse Is Coming

    They Know a Collapse Is Coming

    The CIO of Goldman Sachs has said that in the next year, companies at the forefront will begin to use AI agents as if…

    78 条评论
  • Agile – I Told You So

    Agile – I Told You So

    I think it is no longer controversial that the Agile movement is in decline. When I made a post about it a year ago…

    51 条评论
  • The Most Brilliant Programmer I Have Known Couldn't Work at Google

    The Most Brilliant Programmer I Have Known Couldn't Work at Google

    During the late 1980s I worked at a 30-person startup. The company was founded by the two fellows who had been the lead…

    31 条评论
  • The Most Guaranteed Way to Improve the Bottom Line

    The Most Guaranteed Way to Improve the Bottom Line

    Culture eats strategy for breakfast, but it’s leaders who generate the culture – leaders at all levels, not just at the…

    2 条评论
  • Empowerment, Not Self-Organization

    Empowerment, Not Self-Organization

    Have you heard people say something to the effect of, “Self organization is not really entirely self organization”? I…

    11 条评论
  • Join a Community that is About Learning

    Join a Community that is About Learning

    Things like leadership, product development, technical practices in DevOps, and more. Free workshops for learning.

  • Anyone Can Learn DevOps

    Anyone Can Learn DevOps

    Are you looking for ways to expand your skills, to be more effective in your organization? One way is to learn more…

  • Use a Capability-Focused Approach — Not an Agile Framework

    Use a Capability-Focused Approach — Not an Agile Framework

    Article here: https://www.agile2academy.

    3 条评论
  • Why Team Performance Is the Wrong Thing to Focus On

    Why Team Performance Is the Wrong Thing to Focus On

    Many companies today are obsessed with teams. The “old” approach of static departments and hierarchies is out.

    12 条评论
  • Leadership Is the Key Skill Today

    Leadership Is the Key Skill Today

    Join our free “Intro” to our acclaimed course, Constructive Agility? for Leaders. (Formerly Agile 2 Foundations) It…

    5 条评论

社区洞察

其他会员也浏览了