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. Schein defines organizational culture as “…a pattern of shared basic assumptions learned by a group as it solved its problems of external adaptation and internal integration…” [Schein 2016]. Following the concept of technical debt, we can regard as cultural debt the subset of shared basic assumptions comprising enterprise culture that are no longer fitting for enterprise realities. We can also include as cultural debt any assumptions that ought to be shared, but which are missing or are only partially shared. And we can include shared assumptions that conflict with each other and need to be resolved.

An example of cultural debt: the term “IT”

A tape measure calibrated in both feet/inches and meters/centimeters
A tape measure calibrated in both feet/inches and meters/centimeters. The need to possess tools that serve both measurement systems can be viewed as the metaphorical interest charges on a technical debt resulting from the failure to retire the older “English” system. But from another perspective, the debt involved is actually cultural. Retiring the older system would truly involve a cultural shift.

For most modern enterprises, one element of cultural debt is the very term IT itself — information technology. Coined in 1958 by Leavitt and Whisler [Leavitt 1958], the term was apt up to as recently as 20 years ago, when the role of IT was primarily management, storage, retrieval, manipulation, and presentation of data — information — by technological means. Although those functions remain relevant, the responsibilities of IT have expanded dramatically since 1958. In many organizations, IT is now responsible for designing, implementing, and maintaining the communication infrastructure, including Internet access, personal computers, networking, Web presence, telephones, video conferencing equipment, and television.

In modern organizations in which communication plays a critical and strategic role, an essential element for success is a clear understanding of what IT does and what it contributes. To regard IT as the “information technology” function of the enterprise is, therefore, to risk overlooking and undervaluing these more recently acquired responsibilities. And since the IT function is no longer solely responsible for enterprise information, using the name “IT” or the term information technology risks overvaluing the role of the IT organization relative to information management, while undervaluing its role relative to communications.

In Schein’s culture framework, the term IT reflects a shared assumption about the focus and span of the IT function. That assumption is that IT is responsible for information—an assumption that is no longer well aligned to the reality of the role of IT. We can regard this misalignment as a cultural debt.

The consequences of this particular kind of cultural debt can be severe. For instance, IT is typically responsible for selecting and configuring software for personal computers (PCs) — both desktop and laptop. This responsibility can arise as a consequence of two shared assumptions. First, that computers process information, and second, that IT is responsible for technology-based information processing. The result is that decisions about what many regard as a “personal” computer are not in the control of the person who uses the computer. This conflict in shared assumptions can lead to conflict between PC users and IT, when the IT decision is at variance with their personal preferences.

Worse, a centralized decision process for determining PC configurations is likely to produce outcomes less suitable than would a process more focused at the individual level, which only adds to the frustrations of PC users, and exacerbates the conflict between them and IT. To mitigate the risk that some PC users might try to circumvent IT policy, IT must deploy technology to ensure adherence to their policies. We can regard all of that activity, on the part of both IT and the PC users, as metaphorical interest charges on cultural debt.

An example of retiring cultural debt

In 1987, Edward Yourdon founded a magazine then known as American Programmer. In 1990, Cutter Information Corporation purchased the rights toAmerican Programmer and created Cutter IT Journal, which name includes the term IT. At the time IT was more suitable than the term programmer. As noted above, the term IT, while once useful and apt, is now outmoded at best and often misleading. Just as the functional name IT in organizations constitutes cultural debt, so it does in the name of a journal.

So in the autumn of 2016, Cutter IT Journal retired the cultural debt in its name, and became Cutter Business Technology Journal. Journals rarely change their names. When they do, the impact of the journal is temporarily depressed because of the split of citations between the former title and the new title for two years or so [Tempest 2005]. But as research fields change, their journals must keep pace. Evidently Cutter felt a significant need to retire its cultural debt — significant enough to justify a temporary effect on impact.

What about cultural debt retirement in companies?

Difficulties associated with retiring cultural debt in companies depend strongly on both the nature of the culture and the nature of the debt. To provide insight into the issues that can arise, let’s continue with our exploration of the term IT and its cultural implications.

In many organizations, IT reports to an enterprise Chief Information Officer (CIO). Associated with this official’s title are some of the same cultural debts we find associated with the name of the IT organization. First, within their organizations, CIOs aren’t the only officers with information management responsibility. Second, many CIOs have responsibilities that extend beyond information management, to include, for example, the communication infrastructure. And unlike other peer titles such as CEO, CFO, CMO, and COO, the CIO title evokes separation from business-oriented decisions. That separation contributes to a cultural wall between “IT” and “the business.”

When cultures view IT as an information-centric service organization, a remnant perhaps of the middle or late 20th century, they tend to regard IT as a source of expense to be minimized, rather than as a strategic partner [Ross 2000]. Trends toward strategic acceptance of IT are nevertheless favorable, with room for improvement, according to recent surveys of CIOs [CIO 2018], probably because of reality.

The reality is that business technology must contribute to formulation and implementation of enterprise strategy. To the extent that CIOs and their organizations are viewed as separate from “the business,” their ability to help shape enterprise strategy is limited. This situation subjects CIOs to cultural assumptions about their responsibilities that in some instances conflict with each other, or with enterprise reality. That’s a significant source of the metaphorical interest charges on the cultural debt.

One possible way to retire this debt might entail retitling Chief Information Officer to Chief Business Technology Officer (CBTO). That’s precisely what happened at Forrester Research in 2011 [Plant 2014].

Unfortunately, the name CBTO conflicts with the three-word pattern of enterprise officer titles (C*O), which might create an urge to name the office Chief Technology Officer (CTO). But that role usually has responsibility for the functions that create technological products or services. Thus, for many organizations, to create a CBTO where there is already a CTO might create further sources of conflict. Using the CTO designation for the CBTO is probably impractical.

But we must find some way to retire this particular cultural debt, because it is such an effective generator of technical debt. CBTO seems to be the best available path.

References

[CIO 2018] CIO. “2018 State of the Cio: CIOs Race Towards Digital Business,” CIO, winter 2018.

Available: here; Retrieved March 30, 2018

Cited in:

[Leavitt 1958] Harold J. Leavitt and Thomas L. Whisler. “Management in the 1980s,” Harvard Business Review, November-December, 36, 41-48, 1958.

Cited in:

[Plant 2014] Robert Plant. “IT Has Finally Cracked the C-Suite,” Harvard Business Review, July 16, 2014.

Available: here; Retrieved: April 8, 2018

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

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

Order from Amazon

Cited in:

[Tempest 2005] “The effect of journal title changes on impact factors,” Learned Publishing 18:57–62 (2005).

Available: here; Retrieved: April 5, 2018

Cited in:

Other posts in this thread

The Broken Windows theory of technical debt is broken

In the United States, the Broken Windows theory of crime control first appeared in the public conversation in 1982, when Kelling and Wilson described it in The Atlantic (then known as The Atlantic Monthly) [Kelling 1982]. Briefly, the theory suggests that in urban environments, by applying police resources to preventing small crimes such as vandalism, public drinking, and toll jumping, one can prevent serious crime and create an atmosphere of order and lawfulness. Gladwell popularized the idea in his explosive best seller The Tipping Point [Gladwell 2000].

Broken windows in an old abandoned factory
Broken windows in an old abandoned factory. To work in an environment dominated by properties like this must certainly be demoralizing. But whether existing technical debt actually causes people to make choices that incur new technical debt is another question. At this point, it’s an open question.

In the year before Gladwell’s work appeared, Hunt and Thomas incorporated the Broken Windows theory into their work, The Pragmatic Programmer, suggesting it as a justification for the importance of retiring technical debt immediately upon discovering it [Hunt 1999]. Briefly, the theory as applied to technical debt in software is that tolerating low quality and technical debt in a given asset encourages further degradation of quality and incurring additional technical debt. Within the software community, the Broken Windows theory of managing technical debt is widely accepted [Note a].

However, between Kelling’s work in 1982 and the work of Hunt and Thomas in 1999, criminologists and sociologists had become skeptical of the Broken Windows theory as applied to crime prevention. As far back as 1998, investigations had begun to cast doubt on the Broken Windows theory [Harcourt 1998]. In 2006, Eck and Maguire assembled a review of the escalating controversy [Eck 2006]. Research by O’Brien, Sampson, and Winship, based on “big data” analyses, failed to produce evidence of validity of the Broken Windows theory beyond a weak positive correlation between social orderliness and lawful behavior [O’Brien 2015]. Indeed, their research instead showed a very strong positive correlation between private violent behavior and major crimes. Others have noted that what appeared to be positive results for the application of the Broken Windows approach to crime prevention in the 1990s was actually explainable by other phenomena [Note b].

Social scientists and criminologists have taken these findings seriously enough to have founded the Center for Evidence-Based Crime Policy at George Mason University, which maintains an evidence-based policing matrix to assist law enforcement organizations in evaluating the validity of claims about the efficacy of specific tactics and strategies, such as the Broken Windows theory. (See their review of Broken Windows Policing.)

But even as doubts developed about the efficacy of Broken Windows policing for crime prevention, Broken Windows continued to find adherents relative to managing technical debt in software assets. The software engineering community thus finds itself, perhaps, in the same position with respect to Broken Windows as it is with respect to the Tragedy of the Commons. Broken Windows and the Tragedy of the Commons are both fine analogies, but the fields that originated them now have superior ways of understanding the phenomena in question.

Maybe it’s time for the engineering community to re-examine Broken Windows as it pertains to technological asset quality and technical debt. At this time, the author is aware only of anecdotal support for the Broken Windows theory of technical debt management. Perhaps the Broken Windows theory will work better in engineering than it did in social science or criminology, but do you want to bet your company on that?

References

[CIO 2018] CIO. “2018 State of the Cio: CIOs Race Towards Digital Business,” CIO, winter 2018.

Available: here; Retrieved March 30, 2018

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

Order from Amazon

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

[Leavitt 1958] Harold J. Leavitt and Thomas L. Whisler. “Management in the 1980s,” Harvard Business Review, November-December, 36, 41-48, 1958.

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Plant 2014] Robert Plant. “IT Has Finally Cracked the C-Suite,” Harvard Business Review, July 16, 2014.

Available: here; Retrieved: April 8, 2018

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

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

Order from Amazon

Cited in:

[Tempest 2005] “The effect of journal title changes on impact factors,” Learned Publishing 18:57–62 (2005).

Available: here; Retrieved: April 5, 2018

Cited in:

Other posts in this thread

Zero tolerance and work-to-rule deliveries create an adversarial culture

Last updated on February 1st, 2018 at 07:29 am

Defining technical debt at the level of specificity needed for project objectives is difficult. Confronted with this difficulty, some internal customers of technologists adopt a zero-tolerance approach to technical debt, without specifically defining technical debt. Post-delivery — sometimes much, much, post — when technical debt is discovered or recognized, technologists are held responsible, even in cases when no one could have predicted that a specific artifact would eventually come to be regarded as technical debt. This sets up an adversarial dynamic between technologists and their internal customers.

Delayed or cancelled flights
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 is specified by the internal customer. If they find something additional that must be done, they perform that work only if they successfully obtain the customer’s approval. Some customers continue to adhere to a zero-tolerance policy with respect to technical debt, but such a non-specific requirement cannot be met. Because technologists are “working to rule,” they use the ambiguity of the zero-tolerance requirement to assert that they performed all work that was sufficiently specified. This level of performance is analogous to the work-to-rule actions of some employees involved in labor disputes with their employers, and who are literally in compliance with the requirements of the employer, but only literally [LIBCom 2006].

Requiring deliverables to be totally free of technical debt contributes to formation of an adversarial culture, wherein the adversaries are the technologists and their internal customers. Shedding that adversarial culture, once it sets in, can be difficult. Compelling employees, vendors, or contractors to deliver work that’s free of all technical debt is therefore unlikely to succeed. Whether work is performed in-house by employees, or is outsourced, or is performed in-house by contractors, deliverables that meet the minimum possible interpretation of the objectives of the effort are almost certainly burdened with unacceptable levels of technical debt. What can we do to prevent this?

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

We must accept that any other forms of technical debt that remain at the end of a given project, or any constructions that later come to be recognized as technical debt, are just the “cost of doing business.” We’ll get to them, but unfortunately, not this time.

References

[CIO 2018] CIO. “2018 State of the Cio: CIOs Race Towards Digital Business,” CIO, winter 2018.

Available: here; Retrieved March 30, 2018

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

Order from Amazon

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

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

Available: here; Retrieved: May 9, 2017.

Cited in:

[Leavitt 1958] Harold J. Leavitt and Thomas L. Whisler. “Management in the 1980s,” Harvard Business Review, November-December, 36, 41-48, 1958.

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Plant 2014] Robert Plant. “IT Has Finally Cracked the C-Suite,” Harvard Business Review, July 16, 2014.

Available: here; Retrieved: April 8, 2018

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

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

Order from Amazon

Cited in:

[Tempest 2005] “The effect of journal title changes on impact factors,” Learned Publishing 18:57–62 (2005).

Available: here; Retrieved: April 5, 2018

Cited in:

Other posts in this thread

Technical debt: monochronic and polychronic cultures

Last updated on December 21st, 2017 at 01:41 pm

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.

A Simmental cow and calf
A Simmental cow and calf

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.

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.

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 just as 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.

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:
  • How much will it cost—total—to retire the technical debt of that kind?
  • How long will it take?
  • Will that debt retirement interfere with our plans for the rollout of the Marigold products next September?

Conventional project management might not work well for technical debt retirement efforts. Regarding them 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:

[CIO 2018] CIO. “2018 State of the Cio: CIOs Race Towards Digital Business,” CIO, winter 2018.

Available: here; Retrieved March 30, 2018

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

Order from Amazon

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

Cited in:

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

Originally published in 1959. Order from Amazon

Cited in:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

Cited in:

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

Available: here; Retrieved: May 9, 2017.

Cited in:

[Leavitt 1958] Harold J. Leavitt and Thomas L. Whisler. “Management in the 1980s,” Harvard Business Review, November-December, 36, 41-48, 1958.

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Plant 2014] Robert Plant. “IT Has Finally Cracked the C-Suite,” Harvard Business Review, July 16, 2014.

Available: here; Retrieved: April 8, 2018

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

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

Order from Amazon

Cited in:

[Tempest 2005] “The effect of journal title changes on impact factors,” Learned Publishing 18:57–62 (2005).

Available: here; Retrieved: April 5, 2018

Cited in:

Related posts

With all deliberate urgency

Last updated on December 19th, 2017 at 12:37 pm

One of the drivers of technical debt—one of the most important generators of technical debt—is 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 (American baseball playoffs). At that point, 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 went on to lose, 9-8.

Pressure situations are tough.

Dusty Baker as Manager of the Washington Nationals in 2017
Dusty Baker (center) as Manager of the Washington Nationals, at a game at the home field of the Baltimore Orioles, May 8, 2017. At the 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
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.”

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—don’t bother surfing for UGI or StrawIntoGold) Unfortunately, StrawIntoGold development is far behind schedule. After the all-hands meeting yesterday, the core engineering team had a three-hour meeting of its own. They found some ways to wrap things up in the next ten days. They think they can do it, but they’ll be 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 will be incurring significant technical debt. They have crossed the “urgency line,” and although it’s too soon to say definitively that they’ve panicked, my personal experience suggests that 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].

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.

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. 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:

[CIO 2018] CIO. “2018 State of the Cio: CIOs Race Towards Digital Business,” CIO, winter 2018.

Available: here; Retrieved March 30, 2018

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

Order from Amazon

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

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:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

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:

[Leavitt 1958] Harold J. Leavitt and Thomas L. Whisler. “Management in the 1980s,” Harvard Business Review, November-December, 36, 41-48, 1958.

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Plant 2014] Robert Plant. “IT Has Finally Cracked the C-Suite,” Harvard Business Review, July 16, 2014.

Available: here; Retrieved: April 8, 2018

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

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

Order from Amazon

Cited in:

[Tempest 2005] “The effect of journal title changes on impact factors,” Learned Publishing 18:57–62 (2005).

Available: here; Retrieved: April 5, 2018

Cited in:

Related posts

On assigning responsibility for creating technical debt

Last updated on December 21st, 2017 at 01:33 pm

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.

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.

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.

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 the resistance can be resolved with an intensive education program.

Sometimes that 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.

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 external to 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].

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:

[CIO 2018] CIO. “2018 State of the Cio: CIOs Race Towards Digital Business,” CIO, winter 2018.

Available: here; Retrieved March 30, 2018

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

Order from Amazon

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

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:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

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:

[Leavitt 1958] Harold J. Leavitt and Thomas L. Whisler. “Management in the 1980s,” Harvard Business Review, November-December, 36, 41-48, 1958.

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Plant 2014] Robert Plant. “IT Has Finally Cracked the C-Suite,” Harvard Business Review, July 16, 2014.

Available: here; Retrieved: April 8, 2018

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

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

Order from Amazon

Cited in:

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

Order from Amazon

Cited in:

[Tempest 2005] “The effect of journal title changes on impact factors,” Learned Publishing 18:57–62 (2005).

Available: here; Retrieved: April 5, 2018

Cited in:

Related posts

Organizational culture and technical debt

Last updated on April 9th, 2018 at 02:13 pm

Organizational culture affects—and is affected by—everything the organization does. It is complex beyond imagining. It both creates leaders and is shaped by them [Schein 2016]. Fortunately, for our narrow purposes—namely, improving how we manage technical debt—we need to explore neither every available model of culture nor their dynamics. 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.

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 is the collection of values, beliefs, and principles shared among the people of the organization. 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.

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.

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 our technical investigations to be guided by considerations of culture.

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 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.

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:

[CIO 2018] CIO. “2018 State of the Cio: CIOs Race Towards Digital Business,” CIO, winter 2018.

Available: here; Retrieved March 30, 2018

Cited in:

[Eck 2006] J. Eck and E.R. Maguire. “Have Changes in Policing Reduced Violent Crime? An Assessment of the Evidence,” in Blumstein, Alfred, and Joel Wallman, eds. The Crime Drop in America, Revised Edition. Cambridge: Cambridge University Press, 2006, 207-265.

Order from Amazon

Cited in:

[Gladwell 2000] Malcolm Gladwell. The Tipping Point: How Little Things Can Make a Big Difference. New York: Little, Brown and Company, 2000.

Order from Amazon

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:

[Harcourt 1998] Bernard E. Harcourt. “Reflecting on the Subject: A Critique of the Social Influence Conception of Deterrence, the Broken Windows Theory, and Order-Maintenance Policing New York Style,” 97 Michigan Law Review 291 (1998).

Available: here; Retrieved: June 26, 2017

Cited in:

[Hunt 1999] Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. Reading, Massachusetts: Addison Wesley Longman, 1999.

Order from Amazon

Cited in:

[Kelling 1982] Kelling, George L. and James Q. Wilson. “Broken Windows: The police and neighborhood safety,” The Atlantic, 249(3):29–38, March 1982.

Available: here; Retrieved: June 25, 2017

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:

[Leavitt 1958] Harold J. Leavitt and Thomas L. Whisler. “Management in the 1980s,” Harvard Business Review, November-December, 36, 41-48, 1958.

Cited in:

[Note a] Articles and blog entries about applying Broken Windows to managing technical debt in software:

[Tuin 2012] Richard Tuin. “Software Development and the Broken Windows Theory,” blog entry at rtuin.nl, August 22, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Matfield 2014] Kat Matfield. “The Broken Windows Theory of Technical Debt,” Mind the Product blog at MindTheProduct.com, November 11, 2014.

Available: here; Retrieved: June 25, 2017

Cited in:

[El-Geish 2015] Mohamed El-Geish. “Broken Windows: Software Entropy and Technical Debt,” blog at LinkedIn.com, March 6, 2015

Available: here; Retrieved: June 25, 2017

Cited in:

[Pietola 2012] Mikko Pietola. “Technical Excellence In Agile Software Projects,” Master’s Thesis, Information Technology, Oulu University of Applied Sciences, 2012.

Available: here; Retrieved: June 25, 2017

Cited in:

[Venners 2003] Bill Venners. “Don’t Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas, Part I,” blog at Artima.com, March 3, 2003.

Available: here; Retrieved: June 25, 2017.

Cited in:

Cited in:

[Note b] Articles and blog entries questioning the validity of the Broken Windows theory of crime prevention:

[Nuwer 2013] Rachel Nuwer. “Sorry, Malcolm Gladwell: NYC’s Drop in Crime Not Due to Broken Window Theory,” SmartNews blog at smithsonian.com, February 6, 2013.

Available: here; Retrieved: June 25, 2017.

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Childress 2016] Sarah Childress. “The Problem with ‘Broken Windows’ Policing,” PBS FrontLine, June 28, 2016.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006a] Bernard E. Harcourt. “Bratton's ‘broken windows’:No matter what you’ve heard, the chief’s policing method wastes precious funds,” Los Angeles Times, April 20, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

[Harcourt 2006b] Bernard E. Harcourt and Jens Ludwig. “Broken Windows: New Evidence From New York City and a Five-City Social Experiment,” University of Chicago Law Review, Vol. 73, 2006.

Available: here; Retrieved: June 25, 2017

Cited in:

Cited in:

[O’Brien 2015] Daniel O’Brien, Robert J. Sampson, and Christopher Winship. “Ecometrics in the Age of Big Data: Measuring and Assessing ‘Broken Windows’ Using Large-scale Administrative Records.” Sociological Methodology 45: 101-147, 2015.

Available: here; Retrieved: June 25, 2017

Cited in:

[Plant 2014] Robert Plant. “IT Has Finally Cracked the C-Suite,” Harvard Business Review, July 16, 2014.

Available: here; Retrieved: April 8, 2018

Cited in:

[Ross 2000] Jeanne W. Ross and David F. Feeny. “The Evolving Role of the CIO,” in Framing the Domains of IS Management Research: Glimpsing the Future through the Past, edited by Robert W. Zmud. Pinnaflex, 2000.

Available: here; Retrieved: December 20, 2017.

Cited in:

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

Order from Amazon

Cited in:

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

Order from Amazon

Cited in:

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

Order from Amazon

Cited in:

[Tempest 2005] “The effect of journal title changes on impact factors,” Learned Publishing 18:57–62 (2005).

Available: here; Retrieved: April 5, 2018

Cited in:

Related posts