Managing Digital: Concepts and Practices

Consider the following two industry reports.

In September 2015, Minneapolis-based Target Corporation laid off 275 workers with IT skillsets such as business analysis and project management, while simultaneously hiring workers with newer “Agile” skills. As quoted by a local news site, Target stated:

“As a part of our transition to an Agile technology development and support model, we conducted a comprehensive review of our current structure and capabilities … we are eliminating approximately 275 positions and closing an additional 35 open positions. The majority of the impact was across our technology teams and was primarily focused on areas such as business analysis and project management." [149]

Jim Fowler, Chief Information Officer at General Electric, says:

“When I am in business meetings, I hear people talk about digital as a function or a role. It is not. Digital is a capability that needs to exist in every job. Twenty years ago, we broke e-commerce out into its own organization, and today e-commerce is just a part of the way we work. That’s where digital and IT are headed; IT will be no longer be a distinct function, it will just be the way we work. … [W]e’ve moved to a flatter organizational model with “teams of teams” who are focused on outcomes. These are co-located groups of people who own a small, minimal viable product deliverable that they can produce in 90 days. The team focuses on one piece of work that they will own through its complete lifecycle … in [the “back-office”] model, the CIO controls infrastructure, the network, storage, and makes the PCs run. The CIOs who choose to play that role will not be relevant for long.” [122]

Modern Management Information Systems (MIS) courses and textbooks, especially at the undergraduate, survey level, seek to orient all students (whether IT/MIS specialists or not) to the role and function of information systems and their possibilities and value in the modern enterprise. This book, by contrast, intends to prepare the student for a career as a digital professional, in those industries that offer digital products per se as well as industries that rely on digital technology instrumentally for delivering all kinds of products. A central theme of the book is that IT, considered as a component, represents an increasing proportion of all industrial products (both consumer and business-facing). This trend towards IT’s increase is a key characteristic of Digital Transformation.

Current MIS survey texts have some common characteristics:

IT, or the digital function, has had a history of being under-managed and poorly understood relative to peer functions in the enterprise. It struggles with a reputation for expensive inflexibility and Dilbert-esque dysfunction, and has generated a fair amount of mistrust with its business sponsors. The DevOps and Agile movements promise transformation but are encountering an entrenched legacy of

Understanding and engaging with the challenges of this legacy are ongoing themes throughout this introductory text. Some of the more radical voices in the Agile movement sometimes give the impression that the legacy can be simply swept away. Mike Burrows notes that, in terms of the systems thinking at the core of Agile philosophy, such a move might be ill-advised:

“Some will tell you that when things are this bad, you throw it all away and start again. It’s ironic: The same people who would champion incremental and evolutionary approaches to product development seem only too eager to recommend disruptive and revolutionary changes in people-based systems -— in which the outcomes are so much less certain” [45 p. 827].

IT management at scale within an organization is a complex system. The IT workforce, its collective experience, and its ongoing development (through education and training) is another complex system orders of magnitude larger. Complex systems do not respond well to dramatic perturbations. They are best changed incrementally, with careful monitoring of the consequences of each small change. (This is part of the systems theory foundation underlying the Agile movement). This is why the book covers topics such as:

While these practices, and their associated approaches and policies, have caused friction with digital and Agile practitioners, they all have their reasons for existing. The goal of this book is to understand their interaction with the new digital approaches, but in order to do this we must first understand them on their own terms. It does no good to develop a critique based on misconceptions or exaggerations about what (for example) process management or governance is all about. Instead, we try to break these large and sometimes controversial topics into smaller, more specific topics:

By examining IT management in these more clinical terms, we can develop a responsible critique of current industry best practices that will benefit students as they embark on their careers.

One of the most important and distinguishing features of this book is its emergence model. In keeping with the entrepreneurial spirit of works like Ries’ The Lean Startup, the book adopts a progressive, evolutionary approach. The student’s journey through it reflects a process of emergence. Such processes are often associated with founding and scaling a startup. There are many helpful books on this topic, such as the following:

The emergence model and overall book structure is discussed in depth in the main introduction. Here, for the instructor, are some notes on the thought process.

A central problem in conceiving the book was the question of overall learning progression, or narrative. As noted in the Preface, it was first developed to support a required semester-long survey class on IT management at the University of St. Thomas in St. Paul, Minnesota, in the largest software engineering program in the country.

Currently, two primary narratives or learning progressions are used to in teaching computing:

The stack is how the most rigorous topics are taught. Algebra is the foundation for trigonometry, trigonometry is required for calculus, for example. Logic is needed for discrete math, required for automata and compilers, and so forth. The stack is also how technology is described: physical, logical, and conceptual layers, for example, or layered abstractions in networking protocols.

The systems lifecycle, on the other hand, is how we tend to structure industry guidance. We plan and design, we build, we run. Guidance such as CObIT and ITIL show lifecycle influences, as do software engineering programs in colleges.

However, both the stack and the lifecycle have limitations:

Instead, this book’s emergence narrative draws on systems theory, in particular John Gall’s idea that “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system” [103]. Henrik Kniberg created a compelling visual image showing how systems scale: through ongoing, iterative re-design and elaboration of fundamental characteristics (Systems evolve and scale iteratively ^[2]).

What if we treated the student’s understanding as such a systems scaling problem? What would be the simplest possible thing that could work? How would we iteratively evolve their understanding, based on practical topics? Scaling seems to be orthogonal to the other narratives (Three narrative dimensions).

As we’ll cover in the main introduction, reading books on organizational scaling inspired the idea that growth does not happen smoothly; instead organizations tend to cluster at certain scales and struggle to grow to the next scale. Hence the overall structure of the book:

A key focus of the book is explaining what practices are formalized at which level of growth. The thought experiment is, “what would I turn my attention to next as my IT-based concerns scale up?” For example, the book currently proposes that work management (implying rudimentary workflow, e.g., Kanban) correctly comes before formalized project and/or process management, which in turn tend to emerge before enterprise governance practices (e.g., formalized risk management).

Note that this would be a testable and falsifiable hypothesis if empirical research were done to take inventory of and characterize organization scaling patterns. If we found, for example, that a majority of organizations formalize governance, risk, security, and compliance practices before formalizing product management, that would indicate that those chapters should be re-ordered. In my experience, small/medium businesses may have formal product management but Governance, Risk, and Compliance, (GRC) are still tacit, not formalized. This does not mean that GRC is not a concern, but they have not yet instituted formal policy management, internal audit, or controls.

The presence of product management at an early stage in the book (Chapter 4) is intended to provoke thought and debate. Product management is poorly addressed in most current college computing curricula as well as the de facto industry standards (e.g., the TOGAF® ADM, PMBOK, and ITIL). Yet formalizing it is one of the earliest concerns for a startup, and the imperatives of the product vision drive all that comes after. Evidence to this effect is seen (as of 2015) at the University of California at Berkeley I-School, which has replaced its Project Management course with Lean/Agile Product Management, taught currently by Jez Humble, author of Continuous Delivery, Lean Enterprise, and co-author of The DevOps Handbook.

This book however is not a complete dismissal of older models of IT delivery. Wherever possible, new approaches are presented relative to what has gone before. The specifics of “what’s different” are identified, in the interest of de-mystifying what can be fraught and quasi-religious topics. (Why is a Scrum standup or a Kanban board effective, in terms of human factors?)

The emergence model can also be understood as an individual’s progression within a larger enterprise. Even starting from day one at a Fortune 100 corporation, I believe a person’s understanding still progresses from individual, to team, to team of teams, to enterprise. Of course, the person may cease evolving their understanding at any of these stages, with corresponding implications for their career.

This book does not cover specific technologies in any depth. Many examples are used, but they are carefully framed to not require previous expertise. This is about broader, longer lifecycle trends.

There is benefit to restricting the chapters to 12, as a typical semester runs 14 weeks, and the book then fits well, with one chapter per class and allowing for an introductory session and final exam. Of course, a two-semester series, with two weeks per chapter, would also work well. Each half of the book is also a logical unit. The chapters have been re-ordered and refactored many times, and based on further research may evolve further.

With three chapters in each section, the book can be covered in one intense semester at a chapter a week, although expanding it to a two-semester treatment would allow for more in-depth coverage and increased lab exposure. This required new thinking. How could students learn IT management at scale in a lab setting? A hands-on component is essential, as IT management discussions can be abstract and meaningless to many students. (“Incidents are different from problems!”)

Ten years ago, the best that would have been possible would be paper case studies, perhaps augmented with spreadsheets. But new options are now available. The power of modern computers (even lightweight laptops) coupled with the widespread availability of open-source software makes it possible to expose students to industrial computing in a meaningful, experiential way. There is great utility in the use of lightweight, pre-configured virtualization technologies such as Vagrant, VirtualBox, and Docker.

The initial course used a central server, but even that is not necessary. The class can be taught with zero computing budget, assuming that each team of students has access to a modern laptop (recommend 8 gigabytes of RAM and 250 gigabyte drive) and a fast Internet connection. Initial lab versions used free and open-source versions of Chef, Jenkins, Nagios, JUnit, Ant, and other tools, evolving to Node.js, microservices, Docker, and Kubernetes. See the dm-academy resources on GitHub for the current status.

Some may question the inclusion of command-line experience, but without some common technical platform, it is hard to provide a meaningful, hands-on experience in the first half of the course. Currently, digital professionals require hands-on technology skills; barriers to developing them being much lower than in years past. The initial course assumed that the students are at least willing to learn computing techniques, with no prerequisites beyond that. Not even a programming language is required; the Java currently used as a sample is minimal.

Truly beginning students will have to work at the Linux tutorials, but all they need to master is basic command line navigation; this is possible with a diverse student body, some with no previous computing experience. The labs for the second half of the course mostly use games, experiential paper-based classroom exercises, GUI-based software, databases, and office productivity tools.

The emergence model is intended as the learning progression for either traditional semester-based education, or industry training. Labs tie into the emergence model and encourage the students in hands-on exploration of fundamentals, as if they were starting their own business or initiative. As they progress, they remain grounded in the basics of applied technology. Even the most highly scaled topics, such as Enterprise Architecture and portfolio management, become more real when the students are reminded that the systems in question are simply larger and more numerous versions of the examples they see in the lab.

IT management evolutionary model (read bottom to top) is a conceptual illustration of an IT management progression (read the figure bottom to top). Elaborating the outline into chapters, we have:

The emergence model seeks to define a likely order in which concerns are formalized. Any concern may of course arise at any time — the startup founder certainly is concerned with security! Formalization means at least one or more of the following:

In general, startups avoid overly formalized process and project management. To the extent the concerns exist, they are tacit (understood or implied; suggested; implicit). Certainly, a small startup does not invest in an enterprise-class service desk tool supporting a full array of IT management processes or a full-blown project management office with its own vice president and associated portfolio automation. Simple work management, with a manual or automated Kanban board, is likely their choice for tracking and executing tasks.

But by the time they are a team of teams, specialization has emerged and more robust processes and tools are required. Finally, the more complex, enterprise-scale concerns at the end of the book are presented as part of a logical progression.

The danger, of course, is that the formalization effort may be driven by its own logic and start to lose track of the all-critical business context. By carefully examining these stages of maturation, and the industry responses to them, it is the author’s hope that the student will have effective tools to critically engage with the problem of scaling the digital organization.

Finally, the scaling model also emphasizes the critical importance of the high-performing, multi-skilled, collaborative team. Coordination and enterprise problems must be given their due, but too often the proposed solutions destroy the all important team value. As stated elsewhere in this book, it is possible that there is no higher unit of value in the modern economy than the high-performing team. Maintaining the cohesion and value of this critical asset is presented as a clear priority throughout the subsequent chapters.

Some of you may be familiar with the idea of a Minimum Viable Product (MVP), minimum marketable release, or similar. In these terms, it is important to understand that each section of the book represents an MVP but not each chapter. IT value cannot be delivered without the components discussed in each of chapters 1 through 3. The chapters of each section tend to be interdependent in other words.