Category: Culture

Posted on

Zero tolerance and work-to-rule create adversarial cultures

Last updated on July 8th, 2021 at 01:16 pm

Defining technical debt explicitly enough for project objectives is difficult. Confronted with this difficulty, some internal customers of technologists adopt a zero-tolerance approach to technical debt. But rarely do they define technical debt explicitly. Post-delivery, when customers discover technical debt, they hold technologists responsible. They do so even in cases when no one could have predicted that a specific artifact would eventually become technical debt. This establishes an adversarial culture in which technologists contend with their internal customers. To defend themselves, technologists sometimes adopt a work-to-rule approach to their work.

How adversarial cultures develop

Delayed or cancelled flights can indicate that pilots or others are engaged in a work-to-rule action
Trouble at the airport. When airline pilots engage in work-to-rule actions, the immediate result can be large numbers of delayed or cancelled flights. The longer-term result might be beneficial to pilots, the airline, and the public, but only if labor peace can be restored, and the damage to the flying public can be overcome. So it is with work-to-rule deliveries as a way of dealing with zero-tolerance technical debt policies. The organization must overcome the adversarial culture that results from indiscriminate attempts to control technical debt. Technologists do gain some measure of protection by working to rule, but the longer-term benefit of the organization’s learning to manage technical debt arrives only if the adversarial culture can be overcome. Image (cc) Hotelstvedi courtesy Wikimedia.
And that’s when the trouble begins.

Within this adversarial dynamic, technologists try to protect themselves against future recriminations by “working to rule.” They perform only work that the internal customer specifies. If they find something else that needs work, they perform that work only if they successfully obtain the customer’s approval. Some customers continue to adhere to zero-tolerance policies with respect to technical debt. But engineers cannot meet such non-specific requirements. Because technologists are “working to rule,” they use the ambiguity of the zero-tolerance requirement to assert that they performed all explicitly specified work. This level of performance is analogous to the work-to-rule actions of some employees involved in labor disputes with their employers. In these actions, employees are literally in compliance with the requirements of the employer, but only literally [LIBCom 2006].

Preventing formation of an adversarial culture

Requiring that deliverables be free of technical debt contributes to formation of an adversarial culture. In such cultures the adversaries are the technologists and their internal customers. Shedding that adversarial culture can be difficult once it sets in. Compelling employees, vendors, or contractors to deliver work that’s free of all technical debt is therefore unlikely to succeed. Whether employees or contractors perform the work in-house, or the work is outsourced, the results can be problematic. In the context of an adversarial culture, deliverables that meet the minimum possible interpretation of the stated objectives are almost certain to carry unacceptable levels of technical debt. What can we do to prevent this?

To avoid creating an adversarial culture, we can specify in project objectives the total removal of some kinds of technical debt. To ensure steady progress, develop a statement of objectives that includes complete retirement of at least one well-defined class of technical debt. Emphasize debt classes that have the highest anticipated MICs in the near term. Address other well-defined classes of technical debt on a best-effort basis.

We must accept as the “cost of doing business,” any other forms of technical debt that remain at the end of a given project. We must also accept that some artifacts might later become technical debt, even though they aren’t at present. We’ll get to them, but unfortunately, not this time.

References

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

Other posts in this thread

Posted on

Technical debt: monochronic and polychronic cultures

Last updated on July 7th, 2021 at 03:23 pm

A Simmental cow and calf
A Simmental cow and calf

In the context of today’s prevalence of global teams, the word culture evokes consideration of the differences between different national cultures. We think of the difference between Singapore and Latvia. Or we might also consider regional differences between Massachusetts and Texas. Or between San Francisco and Los Angeles. These differences are real. They do affect the way the inhabitants of these places deal with technical debt. But these cultural differences are topics for another time.

For now, let’s consider how a particular cultural attribute of teams or groups in organizations affects how they manage technical debt. Specifically, how we regard time correlates closely with our preferences, biases, and even the way we think about approaching technical debt.

How people experience space and time

Anthropologist Edward Twitchell Hall, Jr. (1914-2009) developed fundamental concepts for thinking about how we experience space and time. In The Silent Language [Hall 1973], he introduced the concepts of polychronic time and monochronic time. They represent two different ways human cultures relate to time.

People and cultures with a monochronic orientation (M-People) regard time as linear. M-People are most comfortable when they undertake only one task at a time. They tend to sequence tasks one after the other. Their motto is “Work on one and get it done.” When M-People must tackle more than one task in an hour, they divide the hour into blocks. They dedicate each block to one task. But time division isn’t always possible. When M-People work in groups, and when they must do more than one thing simultaneously, they divide their groups. Then each subgroup can focus on one task at a time. This is more or less how conventional (pre-Agile) project teams work.

People and cultures with a polychronic orientation (P-People) regard time differently. They define time more in terms of completed tasks than in terms specified by the hands of a clock. For example, a farmer might define time by what’s happening: it’s time for planting, for harvest, for haying, for canning, or for calving. Finer increments are also defined by what’s happening: it’s time for milking, time for breakfast, or it’s sundown or sunset. More than one thing can be happening at any given time.

Monochronic and polychronic orientations in organizations

In organizational cultures, the differences between monochronic and polychronic orientations are evident at every level of activity. For example, in a meeting of M-People, only one person has the floor at any one time. M-People schedule their agenda items, and after they move to the next agenda item, they don’t return. (Well, they do sometimes return, but they aren’t comfortable when they do) A meeting of P-People might have several people talking at once. They bounce from topic to topic as the discussion calls for it. M-People are very uncomfortable in P-style meetings; P-People are likewise uncomfortable in M-style meetings [Brenner 2018].

M-approaches can work just fine when we know in advance what the tasks entail. We can carve up our total work into pieces and address them one at a time, because they either don’t interact much, or because we can control their interactions. And we can partition the work across the available people and groups, each working on one piece of the effort.

And that has worked well for much of the work involved in producing and maintaining today’s complex technological assets.

But M-approaches can get into trouble when we work on something that’s complex or unfamiliar. When we don’t have (and can’t devise) a detailed plan of the work, dividing the work either by time or by task can be difficult to get right. To do this kind of work, we must depend more on interpersonal relationships and close teamwork than on scheduling and task partitioning. M-style approaches can flounder. And that’s where P-style approaches have big advantages.

In polychronic work styles, we’re more focused on accomplishments than schedule, because we don’t really know enough about the work to make a detailed schedule. In some instances, estimating how much work something might take is essentially impossible because we don’t understand the task in enough detail. We must then let events guide us, in the way the seasons guide the farmer. The people doing the work must adapt as they go, which requires strong relationships, tight collaboration, and trust.

Polychronic approaches might work better for technical debt management

And that brings us to technical debt management. We can address some kinds of technical debt with M-style approaches. We understand those debts and we know how working on their retirement will affect other work. But many forms of technical debt are so entangled with the rest of the organization’s efforts that P-style approaches are more likely to be successful.

For example, consider a project that’s aimed at retiring some kinds of technical debt. That might require access to assets that are critical to certain revenue streams. And suppose that ongoing work unrelated to retiring that technical debt might also affect these same assets. Coordinating all these efforts is complicated, even when we’re planning for only the next few weeks. But coordinating these efforts six months or twelve months in advance is probably impossible, because we can’t create schedules reliable enough to support such planning. The schedules of the various interlocking activities aren’t well enough controlled for that, any more than a dairy farmer controls the calving schedule. The cows control the calving schedule.

For many technical debt management activities, M-style approaches are simply unworkable. We cannot answer with useful precision questions like these:
  • What is the total cost this year to retire the technical debt of that kind?
  • How long will it take?
  • What would it cost if we retire that debt next year?
  • Will that debt retirement interfere with our plans for the rollout of the Marigold products next September?

Last words

Conventional project management might not work well for technical debt retirement efforts. Regarding technical debt retirement efforts as “projects,” with defined schedules, defined budgets, and defined staff assignments might be a serious error. Agile approaches, which are inherently more P-style, might work better.

References

[Brenner 2018] Richard Brenner. “Polychronic Meetings,” Point Lookout 18:1, January 3, 2018.

Available here; . Forthcoming.

Cited in:

[Hall 1973] Edward T. Hall. The Silent Language. New York: Anchor Books, 1973.

Originally published in 1959. Order from Amazon

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

Other posts in this thread

Posted on

With all deliberate urgency

Last updated on July 7th, 2021 at 03:21 pm

Dusty Baker as Manager of the Washington Nationals in 2017
Dusty Baker (center) as Washington Nationals’ Manager, at a game at the home field of the Baltimore Orioles, May 8, 2017. At right is Davey Lopes, the first base coach. I can’t identify the man on the left. If you can, let me know. Photo (cc) Keith Allison courtesy Wikimedia

One of the drivers of technical debt—one of the most important generators of technical debt—is pressure to complete projects. It is pressure that leads to crossing the fine line from urgency to panic when it comes to deadlines.

On October 12, 2017, the Chicago Cubs and Washington Nationals met at the Nationals’ home field for Game 5 of the National League Divisional Series. The series was tied 2-2. It was a high-pressure game that would decide the division championship. By the end of the second inning, the Nationals led 4-1. They would eventually lose, 9-8.

Pressure situations are tough.

After losing the first game of the series, Dusty Baker, the Nationals’ manager, conducted a press conference before Game 2. A difficult situation for any manager. He’s quoted [Gonzales 2017] as saying, “There’s a fine line between urgency and panic, and the thing that you never want to do, you never want to panic.”

“The thing that you never want to do, you never want to panic”

These are words of wisdom that apply just as well in business, especially with respect to technical debt. Consider this scenario:

Sales at Unbelievable Growth, Inc.,(UGI) have been only fair this fiscal year—far from “unbelievable.” But a new product is under development, an app for Android and iPhone called StrawIntoGold 1.0. It has an uncanny ability to predict the price movements of specific common stocks over the next 60 seconds. (This is totally fictitious) Unfortunately, StrawIntoGold development is behind schedule. After the all-hands meeting yesterday, the core engineering team had a three-hour meeting. They found some ways to wrap things up in the next ten days. They think they can do it by eliminating some testing and performing other tests manually. And they plan to re-use some code from the beta version that they had previously decided to replace.

If the UGI engineers succeed, they’ll be incurring technical debt. They’ve crossed the “urgency line.” Although it’s too soon to say definitively that they’ve panicked, the risk of reaching some degree of panic is high. And that risk will get higher as the deadline approaches.

Urgency focuses our energy and attention. As Dusty Baker says, “You have to be of the coolness of mind, but then bring desire to succeed in your heart, and then respond.” When urgency is deliberate, urgency gets the job done. Deliberate urgency is what Kotter calls healthy urgency [Kotter 2014].

Consequences of panic

Panic is something else. It can cause us to choose to cut corners, a choice commonly cited as a source of technical debt. When it makes clear thinking difficult, it impedes memory, increases error rates, reduces attention spans, and contributes to toxic conflict. In short, it makes any kind of brainwork more difficult, less effective, and less reliable.

It’s reasonable to suppose that panic isn’t helpful in avoiding or removing technical debt in any kind of technological asset. It’s just as reasonable to suppose that panic actually contributes to technical debt formation and persistence.

Urgency, good. Panic, bad. Once you let panic into an organization’s culture, the effect on technical debt is predictable. Over time, technical debt will increase out of control.

So what alternatives do the UGI engineers have? In most organizations, they would probably have no alternative. StrawIntoGold 1.0 would be offered to customers in a very sorry state that might not affect its performance, but its maintainability—its sustainability—would be poor. The prospects for version 2.0 would not be bright.

Redefining the word “done”

But some organizations do find alternative approaches. What they do, in effect, is redefine the word “done” as it applies to the StrawIntoGold 1.0 product. In that redefined form, “done” has two stages.

In Stage 1, UGI does release StrawIntoGold 1.0, despite its unsustainable state. But then UGI management makes a clever decision. Instead of moving the StrawIntoGold team on to begin version 2.0, or what is worse, reassigning the team members to other projects, UGI management charters the StrawIntoGold 1.0 team with retiring the technical debt they incurred to meet the version 1.0 deadline.

In Stage 2, they restrict the team’s efforts to technical debt retirement only, so that they produce a version 1.1 that is identical to version 1.0 from the customer perspective. That becomes Stage 2 of “done.” They defer any work on version 2.0, because starting 2.0 would cause fragmentation of the 1.0 team. StrawIntoGold 1.0 is thenceforth shelved, and any new orders are filled with StrawIntoGold 1.1. Then work on version 2.0 begins.

By carefully managing their technical debt, UGI can make its products more sustainable in the very dynamic mobile device app market. They exploit urgency deliberately. They do not panic. Then, at UGI, situations like the one that hit StrawIntoGold 1.0 become rare.

Do you have any teams that have crossed the fine line between urgency and panic?

References

[Brenner 2018] Richard Brenner. “Polychronic Meetings,” Point Lookout 18:1, January 3, 2018.

Available here; . Forthcoming.

Cited in:

[Gonzales 2017] Mark Gonzales. “Nationals manager Dusty Baker preaches calm vs. Cubs,” ChicagoTribune.com, October 7, 2017.

Available: here; Retrieved: December 13, 2017.

Cited in:

[Hall 1973] Edward T. Hall. The Silent Language. New York: Anchor Books, 1973.

Originally published in 1959. Order from Amazon

Cited in:

[Kotter 2014] John P. Kotter. “To Create Healthy Urgency, Focus on a Big Opportunity,” Harvard Business Review, February 21, 2014.

Available: here; Retrieved: December 13, 2017.

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

Other posts in this thread

Posted on

On assigning responsibility for creating technical debt

Last updated on July 7th, 2021 at 03:19 pm

An engineer attending a meeting
An engineer attending a meeting with 14 other engineers. You can’t see the other 14 because they’re at least 4,000 miles away in four separate locations.

When we discover an issue within our organizations, two intertwined imperatives demand attention: “How did this happen?” and “What do we do about it?” As we address the former question, almost inevitably we begin to decide who was responsible for creating the problem. Even if we succeed in avoiding blamefests (see [Brenner 2005a]) we can still make gross errors. Aassigning responsibility for creating technical debt can be a fraught exercise.

Assigning responsibility for creating technical debt provides some clear examples of the many dangerous traps that await us on the path to Truth. How we assign responsibility is due, in part, to patterns of organizational culture.

Causes of growth in technical debt

The causes of growth in technical debt are numerous. They include—among many others—insufficient resources, schedule pressure, existing technical debt, changes in strategic direction, changes in law or regulations, and the risks associated with creating first-of-kind solutions to difficult problems. In most engineering activity new technical debt is inevitable. How we deal with it is up to us.

Unfortunately, many organizations don’t provide the time or resources needed to retire that new technical debt on a regular basis.

When technologists—engineers, their managers, or others in technical roles—try to alert the rest of the organization (non-technologists) to the problems that follow from continually accumulating technical debt, they often meet resistance from non-technologists. Technologists usually hope that intensive education programs can lead to resolving this resistance.

Sometimes education works. Sometimes technologists do receive the additional resources, time, and cooperation they need to start retiring the accumulated technical debt, and to avoid adding more debt to the burden they already carry.

Misconceptions about the causes of technical debt

Mostly, though, education programs don’t work, for reasons beyond mere misunderstanding of the issue. One fundamental problem is the word “technical” in the term technical debt. Non-technologists must be forgiven for believing that since technical debt is inherently technical, it follows that its causes are also technical, that technologists are solely responsible for creating technical debt, and that non-technologists play no role. Those conclusions are, of course, false, but the beliefs persist, and many non-technologists adopt the view that “It’s your problem—fix it.”

A second cause of misconceptions about the causes of technical debt lies in the belief that technologists aren’t working very hard. This belief is founded on assumptions many of us make about what diligent work looks like. Many non-technologists have roles in General Management, Sales, Marketing, or Business Development. They’re working hard when they’re in contact with each other or with people outside the enterprise. They’re traveling, conversing by telephone, or attending or hosting meetings. By contrast, technologists are working hard when they’re at their desks, or attending (face-to-face or virtual) meetings. They do attend meetings off premises, but they do so at much lower rates than do many non-technologists.

When non-technologists assess the technologists’ work ethic, they tend to use the same standards and assumptions they apply to themselves. They under-estimate the technologists’ activity level because outwardly, technologists appear more often to be what non-technologists would regard as “idle”—sitting at their desks, thinking, or typing [Schein 2016].

Last words

All of this shows how language, stereotypes, and assumptions conspire to lead  us to misallocate responsibility for creating technical debt. Some believe that technologists are solely responsible for technical debt, because only they can create it, and they aren’t working very hard to do anything about it. Proceeding from that conclusion, finding a resolution of the problem will be difficult indeed. Language, stereotypes, and assumptions can be traps.

References

[Brenner 2005a] Richard Brenner. “Is It Blame or Is It Accountability?” Point Lookout 5:51, December 21, 2005.

Available here; Retrieved December 30, 2016.

Cited in:

[Brenner 2018] Richard Brenner. “Polychronic Meetings,” Point Lookout 18:1, January 3, 2018.

Available here; . Forthcoming.

Cited in:

[Gonzales 2017] Mark Gonzales. “Nationals manager Dusty Baker preaches calm vs. Cubs,” ChicagoTribune.com, October 7, 2017.

Available: here; Retrieved: December 13, 2017.

Cited in:

[Hall 1973] Edward T. Hall. The Silent Language. New York: Anchor Books, 1973.

Originally published in 1959. Order from Amazon

Cited in:

[Kotter 2014] John P. Kotter. “To Create Healthy Urgency, Focus on a Big Opportunity,” Harvard Business Review, February 21, 2014.

Available: here; Retrieved: December 13, 2017.

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[Schein 2016] Edgar H. Schein. Organizational Culture and Leadership, Fifth Edition, San Francisco: Jossey-Bass, 2016.

Order from Amazon

Cited in:

Other posts in this thread

Posted on

Organizational culture and technical debt

Last updated on July 7th, 2021 at 03:18 pm

A bonsai tree
A bonsai tree. We cannot control the growth of bonsai in detail. We can only make suggestions, and hope that the tree will follow our guidance. So it is with organizational culture.

Organizational culture affects—and is affected by—everything the organization does. It is complex beyond imagining. It creates leaders and leaders shape culture [Schein 2016]. Fortunately, for our narrow purposes—namely, improving how we manage technical debt—we need not explore every available model of culture. All we need to know is how to adjust cultures so that they’re more amenable to technical debt management efforts. Even so, that’s an ambitious objective.

Organizational culture is the collection of values, beliefs, and principles the people of the organization share. Some of these elements are within the awareness of the organization’s people. But some might not be. Culture excludes behavior; behavior is a result of the combined effects of personal choices and organizational culture.

With respect to technical debt, our objective is ambitious because it is at once specific and general. It is general in the sense that as a goal, we would like to devise prescriptions for all organizational cultures as they strive to be more effective in managing technical debt. It is specific in the sense that we’re concerned only with those cultural factors that affect technical debt management.

The case for considering cultural effects on technical debt

But aren’t there enough technical problems to keep us occupied before we get involved in all that culture change stuff? The answer to that, I believe, is yes. But we can make more rapid progress if we allow considerations of culture to guide our technical investigations.

Some of our best minds have been working on the technical debt problem for more than two decades, mostly from the technological perspective. True, we haven’t given the issue the attention and resources it deserves. That might be changing now, but one can reasonably ask a simple question: If some of the causes of the technical debt problem are cultural, and if we begin to make some technological progress in reducing the burden of technical debt, wouldn’t the cultural causes begin to dominate at some point? If that were to happen, the effectiveness of our technical solutions would appear to decline, even though they might be “right,” because technical solutions cannot address cultural problems.

It seems only prudent to prepare for that case by examining the role of culture in creating technical debt and preventing or delaying its retirement.

A reasonable goal might be to define a set of attributes an organizational culture should have if the organization wants to limit the contributions of culture to the formation and persistence of technical debt. I suspect that for most cultures, change would be required, because most organizations now carry more technical debt than they would care to acknowledge.

As with all culture change efforts, we seek, in the end, to modify the behavior of the people who live within that culture. We want to modify aspects of the culture so as to lead its people to be more likely to make choices that are consistent with prudent technical debt management.

Where to from here

With that goal in mind, I’m opening a thread in this blog that I hope will stimulate your thinking and mine about how organizational culture and technical debt interact. This post will contain an outline of these ruminations. Here’s what I have so far:

References

[Brenner 2005a] Richard Brenner. “Is It Blame or Is It Accountability?” Point Lookout 5:51, December 21, 2005.

Available here; Retrieved December 30, 2016.

Cited in:

[Brenner 2018] Richard Brenner. “Polychronic Meetings,” Point Lookout 18:1, January 3, 2018.

Available here; . Forthcoming.

Cited in:

[Gonzales 2017] Mark Gonzales. “Nationals manager Dusty Baker preaches calm vs. Cubs,” ChicagoTribune.com, October 7, 2017.

Available: here; Retrieved: December 13, 2017.

Cited in:

[Hall 1973] Edward T. Hall. The Silent Language. New York: Anchor Books, 1973.

Originally published in 1959. Order from Amazon

Cited in:

[Kotter 2014] John P. Kotter. “To Create Healthy Urgency, Focus on a Big Opportunity,” Harvard Business Review, February 21, 2014.

Available: here; Retrieved: December 13, 2017.

Cited in:

[LIBCom 2006] “Work-to-rule: a guide.” libcom.org.

Available: here; Retrieved: May 9, 2017.

Cited in:

[Schein 2016] Edgar H. Schein. Organizational Culture and Leadership, Fifth Edition, San Francisco: Jossey-Bass, 2016.

Order from Amazon

Cited in:

Related posts

  • Technical debt use disorder
    Technical debt use disorder is a pattern in which the organization can’t seem to retire much of its technical debt, or can’t stop incurring increasing burdens of technical debt, even though everyone in the organization realizes—or almost everyone realizes—that technical debt is harming the organization.
  • Technical debt smell
    Technical debt smell would be a useful indicator of severe technical debt problems. It doesn’t have a real smell, but it might have a metaphorical smell.
  • Using SMART goals for technical debt reduction
    Reducing the enterprise burden of technical debt by setting “SMART goals” in a naïve way might not work. Measuring technical debt is notoriously difficult, and in any case the interest charges matter more than debt volume. Effective SMART goals for technical debt reduction must be closely related to behavior.
  • Cultural debt can be the primary driver of technical debt
    Cultural debt can be expensive, because, like technical debt, it can incur ongoing metaphorical interest charges. Cultural debt is the unfulfilled obligation to alter organizational culture so as to better align it with organizational imperatives.
  • Technical debt: monochronic and polychronic cultures
    Conventional project management might not be applicable to technical debt retirement efforts. Regarding them as “projects,” with defined schedules, defined budgets, and defined staff assignments might be a serious error, culturally speaking. Agile approaches, which are inherently more P-style in nature, might be required.
Show Buttons
Hide Buttons