What Does I.T. Stress Mean For The Enterprise - Part 2

A year ago I made a video about Employee Stress

Last year I made this video where I gave a broad title but then I really focused narrowly on the impact of scheduling stress on your workforce.

Give this cut down version a quick watch and then I’ll continue. [0]

Transcript

So let’s talk about what does it stress me for the enterprise. So I just want to use the TOGAF ADM to talk about that a little bit. So if, if you’re getting a group together and just start it with preliminary, right? Getting grouped together, bring in different people. You’ve got your business people, you’ve got your, your C team. You’ve got your architects. You’ve got people that are concerned about creating a TOGAF implementation for the enterprise, right? So there’s going to be lots of nervous and lots of what’s happening. Lots of confusion, possibly, right? Everybody comes to new situations with different situations, but almost everybody that’s coming to the preliminary is going to have some, some form of stress and maybe excitement, stress. It might be good stress, but there’s going to be stress. And so, someone definitely has to be the leader, the leader of leaders, king of teams. But anyways, so there’s going to be lots of stress around preliminary, getting through that process. Definitely can be an exercise of frustration, right? Because everybody wants their vision. Everybody wants the best for the enterprise and how to get there can be very confusing.

Eventually that all sorts out, right? Eventually you come up with your, your standard operating procedures. You come up with your standard documents. You come up with your inner, with your architected sequencing of how things work. If you’re fallowing in TOGAF, obviously that’s going to the next one is going to be the architecture vision, right? Creating architecture vision. So now you’ve got a team of architects that are creating the architecture vision and they’re stressed, right? So it might be one person that person has all the load on their shoulders. And if that’s you, and that you want to change your relationship to that, let’s have a chat about that. But as a team, you have architectural vision that you’re working on. And every time you were working through the ADM, life cycle, you have a new project. Okay. You have, and you’re going to go back to your documents and you’re going to architect it all out.

And it should be just 1, 2, 3, 4, 5, but then, oh, wait, we’ve got 10 of these and we’ve got to get them done yesterday. Right? So that pressure pressure pressure is time. Schedule. Project management is always knocking at the door. When’s it going to be done? When is it going to be done? When is going to be done? So you’ve got your PMO office. You’ve got your Architect Office. You’ve got your CEx team. You’ve got everybody trying to get everything. Everyone wanting it all at once. Okay. How do you separate the stress and getting those documents done? Okay. So initial architecture is done. Pass it off to the business team, business architect, and now the loads on his shoulders or her shoulders that person’s shoulders. So you have that pressure, pressure, pressure. Okay. Got to get all the business stuff. Can’t forget anything. And okay. They pass it on to the infrastructure team.

Okay. Now everything’s on their shoulders of, is there going to be the right equipment? Is the cloud going to be it or is it on-prem? All the different structures and then pass it on to the technology, architecture, pressure, pressure, pressure, pressure, opportunity, solutions, pressure, pressure, pressure migrating. Okay. So it’s been developed and oh my God, they went through crazy process of development and no, they were all stressed out and pass it on to deployment and, and just goes through the life cycle, right? Every team and department that it goes around through the ADM, through the life cycle, through everything it’s stress and pressure and anxiety. Because if it’s not done, then it’s burning inside. Right. And throughout the ADM life cycle, the, you can either be stressed and anxious about that process or it can be set up so that everybody has the time that they need need without, without punishment, I guess is a good way to say it.

If things don’t go as quickly as required, what if we were to architect the enterprise process in a way that everybody could do their job to their maximum best, without fear for what it means. If, if they’re not on time and that’s a whole different paradigm, right? What does it mean? If a project is late? I mean, I get it. There’s licensing things, but if it’s arbitrary deadline, then all you’re doing is creating adrenaline and cortisol, stress and hormones inside the body. And you’re wearing out your team for nothing. If it’s an arbitrary deadline. And even when it’s not an arbitrary deadline, human compassion for acknowledging that people are doing the best they can do. And then there’s, there’s a fallout, but the enterprise should absorb that; not the people.

And Now For Part 2: What Does I.T. Stress Mean For The Open Enterprise

Yes while stress in the Open Enterprise impacts people the most, let’s jump back in and focus on I.T. Stress and what is Means For The Open Enterprise. Perhaps along the way we can find ways to lower the stress levels for our I.T. Systems, People inside the Enterprise, and your Customers.

As a side note, software of course can’t feel emotions, but it can be stressed and break due to bugs, choke points, security breaches, and other break downs from what is expected. This impacts the people factor in the enterprise.

1.0 Software Bugs

If software did have emotions then what would keep it up at night would be those bugs that we all have accepted must be part of the picture. It is no accident that I’m relating the human experience to bugs because while they keep software from functioning as desired, we as human experience them with an emotional response. Often as annoyance or frustration for the end user, but this is especially true for the developer that wrote the code. Just about every emotion can come up. Anger, embarrassment, sleepiness, depression, and so much more. The proverbial joke of a developer going through stages of grief [1.1] while working on a bug are very much the experience of many developers.

Software also goes through their own stages of grief in a way, although it’s more panic. An expected thing is expected to happen but it can’t work right it will raise an exception. It reaches out to something and never hears back, then it will time out. If something bad happens to many times then it will throw a circuit breaker and go offline all together. All of these error conditions are in a way Software Bugs, in that what is desired isn’t happening. If Software had feelings these are the things that it would probably “feel”.

As humans when our software breaks then we break too, in this way we are part cyborg, combining foreign systems into us.

2.0 Choke Points

Choke Points, also known as Bottle Necks, are those places where an Enterprise has a capacity problem.

Some Enterprises need more staff to keep up. Some software needs better servers to keep up. Some communications break down because the receiver just doesn’t have enough bandwidth.

All of these conditions create stress. Until now I haven’t really defined stress because we all know what that is, yet to really call it out, choke points create a “feeling of emotional or physical tension“ [2.1] in those waiting for the success of that point of failure.

When these choke points can be identified, a solution created, and then finally resolved then the whole enterprise can breath a sign of relief.

One way Choke Points can be resolved in software is by taking solutions to the cloud. One of the common bottle neck patterns is the need of getting some business information from one application into another one. These integration points can choke if the volume of data flow is too great and offloading that burden to a cloud solution such as Choreo [2.2] or Micro Integrator [2.3] is a good way to resolve these issues without a huge development effort.

3.0 Security Breaches

In some ways Security Breaches can be thought of a Bug in that things don’t work as wanted but they do work as designed even though people probably aren’t aware of it at the time.

Many security Breaches, but not all, could be resolved though proper segregation of duties. One way to get systems behind a firewall, and reduce the stress of their security vulnerabilities, is to use the API Facade pattern [3.1] with modern API Managers [3.2] Only expose User Interfaces and APIs to the public. Keeping the application business side of things in the backroom helps reduce it’s influence of Vicious Bad Actors.

While not a magic bullet, abstracting out the application to the smallest footprint possible through the API Facade Pattern is a great approach. It’s hard to hack what you can’t reach.

4.0 Team Politics

Even if egos are left at the door, people still want their concerns looked after. This inherently creates conflict and the resulting stress of those conflicts.

This is a time and place to really listen to the individual contributors to learn the truth about how their systems are doing and how enterprise policies will impact them and their abilities to achieve the company goals.

5.0 Project Delays

In part one I made a very bold statement saying that project delays should be absorbed by the enterprise and not the individual. How many times have you seen people work 10, 12, 14 hour days for weeks at a time to make a project happen on time, just to be thrown into the next project and do it all over again. That is a quick trip to burn out and burn up. If you don’t take care of your people then is it any wonder why there are so many bugs and breakdowns in the software they are producing. This is a classic case of “fight for survival” and in such cases of stress the cognitive ability is greatly reduced. This is scientifically discussed by Michael Mendl when he said: “Stressors appear to cause shifts, lapses and narrowing of attention, and can also influence decision speed.“ [5.1] And then we can go into the recoil phase and keep going but continue in an impaired state as Sarita Robinson and John Leach point out. [5.2]

Another view of why the people need to be taken care of during projects is the Firefighter Fatigue [5.3] situation which Brad Airsbett and David Nichols point out: “several factors thought to contribute to firefighter fatigue including; sleep loss, firefighter’s work activity, their hydration, and nutrition, the hot and smoky working environment, firefighter’s physical fitness and their experience.“ What can this mean for your team during an I.T. Project? Are those high stress, long day work sessions really getting you the results you desire?

Think of it this way, when you are worried about something happening you create thought loops where your start obsessing over the same thoughts over and over. Quickly you “can’t see the forest from the trees”, and lose perspective. What you create during this condition makes 100% sense to you in that condition, a condition similar to being drunk, but in reality it doesn’t make sense at all. At the least you create a bug or incorrect requirement, at the worst you create something that totally is wrong and needs to be completely re-done.

The Enterprise can’t afford to have it’s employees be in a “firefighter fatigue” type scenario full time. So truly the right thing is for the Enterprise to absorb the impact of new knowledge that comes to light during a project. These types of things might be mental states, scheduling delays, fatigue, need for finding better ways of doing things, and finding the things that weren’t known about when the schedule was created.

6.0 Society and Aging Systems

Perhaps it’s time to stop and consider your customers experience with your enterprise now that we this far into the COVID Erra. What lessons have you learned that you haven’t yet taken action on? What needs to be re-written? What needs a new business solution? What can I.T. do that it hasn’t yet done?

We live in a new world, and so should your company by following best of bread practices of the Open Enterprise. [6.1]