A developer and I once discussed (possibly argued) quite enthusiastically about the consequences of the decisions we were making as a delivery team. An application program interface (API) we developed was to specification. It was beautifully documented. We had tested it thoroughly, and we were proud of it. By all appearances, our job was done. But we still didn't know how the downstream consumers of our API would receive it.

Download this free guide

PDF: Are you migrating to DevOps?

As DevOps is slowly taking over the IT landscape, its vital that IT pros understand it before jumping right into the movement. In this complimentary guide, discover an expert breakdown of how DevOps impacts day-to-day operations management in modern IT environments.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

When asked, the developer's responded, "We don't care about that."

He felt that it was up to them to adjust their consuming service based on what we gave them, seeing as they were clearly told what we were delivering to them, and that we had “done it right”.

What ensued was an impasse, a robust "discussion" wherein I argued why that should be our business, based on systems thinking principles.

We agreed to disagree.

There are always consequences

Everything we do has consequences, good or bad. That's because everything, while it may appear independent, is always interdependent.

Interdependence is fundamental to systems. Our life is a system. Everything is a system.

Everything is also, conversely, a component of a bigger system.

Every component in this picture is both a component of a system,
and a system itself.

In the scenario on my project, as it turned out, we had not known about one of the mobile application team's requirements, and their whole application failed upon receipt of our API. The result was several weeks of API rewrites and retests. This, of course, is "waste," a topic for an essay on Lean, which is intimate to successful DevOps, but more about that on another day.

The consequences of poor software design, development and delivery -- of a poor DevOps support model -- are always felt, whether that be by the operations folk, or the customer, or the shareholders, or whomever.

Likewise, the consequences of teams that work "together" but don't consider the consequences of their actions endanger others.

Systems thinking principles in teams

Teams don't work in isolation. They're a part of system. Nowadays, we use terms like DevOps to describe this culture. ("Culture" is how we deal with work, not how many beanbags we have.) It means having a real DevOps support model.

While tools help us achieve these aims, it’s systems thinking and the culture that actually get us there.

While tools help us achieve these aims, it's systems thinking and the culture that actually get us there.

When we enable and educate our teams to be part of a system themselves, they consider not only the individual components of this system but also the system as a whole -- and the consequences of their actions.

Rethink your DevOps support model

The person who wears the support pager is the person who has the best view of the system's bad behavior and the system's supportability. This person knows all too well the consequences of the actions taken by those earlier in the lifecycle.

Traditionally, this person is operations personnel.

However, in Mature DevOps practices other personnel in the team carry the pager too. At my current employer, all developers and some QAs do too.

We do this because we espouse ownership (and consider the consequences) of the work our teams do.

In my case, I'm not a systems engineer and when I'm personally unable to resolve the pager alerts, I seek the assistance of someone who can. They're usually very willing to do so because they benefit directly from educating the rest of us.

It all dovetails

So much can be said and written about the dovetail of systems thinking principles, Lean, Agile and DevOps.

But for now, I will leave you with this summary and leave the door open to further discussions:

Supporting a system and empowering team members to support their system aids understanding of what causes issues, provides insight into regularity of recurring issues, and improves empathy and ownership -- and quite rightfully has everyone thinking in consequences and thus systems thinking.

2 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

I believe that once all of us are elements of a bigger system, the organization where we work in, for example, we must be aware of how much we are responsible for the maintenance of the whole system, we must be aware of how every little action can impact the entire system.