Organization and Culture

Area Description

The organization is going through a critical phase, the “team of teams” transition. There are increasingly specialized people delivering an increasingly complex digital product, or perhaps even several distinct products. Deep-skilled employees are great, but they tend to lose the big picture. The organization is in constant discussions around the tension between functional depth versus product delivery. And when it goes from one team to multiple, the topic of the organization must be formalized.

Leaders often must think about how their company should be structured. There is no shortage of opinions there. From functional centers of excellence to cross-functional product teams, and from strictly hierarchical models to radical models like holacracy, there seems to be an infinite variety of choices.

A structure needs to be filled with the right people. How can the organization retain that startup feel it had previously, with things getting this big? Many leaders know intuitively that great hires are the basis for your company’s success, but now the organization must think more systematically about hiring. Finally, the people hired will create the company’s culture. Many employees and consultants emphasize the role of culture, but what do they mean? Is there such a thing as a “good” culture? How is one culture better than another?

Ultimately, as the Digital Practitioner moves into higher leadership, they realize that the concern for organization and culture is all about creating the conditions for success. The leader can’t drive success as an individual any more; that is increasingly for others to do. All you can do is set the stage for their efforts, provide overall direction and vision, and let your teams do what they do best.

This Competency Area proceeds in a logical order, from operational organization forms, to populating them by hiring staff, to the hardest to change questions of culture.

Structuring the Organization: Product and Function

Description

There are two major models that Digital Practitioners may encounter in their career:

  • The traditional centralized back-office “IT” organization

  • Digital technology as a component of market-facing product management

The traditional IT organization started decades ago, with “back-office” goals like replacing file clerks and filing cabinets. At that time, computers were not flexible or reliable, business did not move as fast, and there was a lot of value to be gained in relatively simple efforts like converting massive paper filing systems into digital systems. As these kinds of efforts grew and became critical operational dependencies for companies, the role of Chief Information Officer (CIO) was created, to head up increasingly large organizations of application developers, infrastructure engineers, and operations staff.

The business objectives for such organizations centered on stability and efficiency. Replacing 300 file clerks with a system that didn’t work, or that wound up costing more was obviously not a good business outcome! On the other hand, it was generally accepted that designing and implementing these systems would take some time. They were complex, and many times the problem had never been solved before. New systems might take years — including delays — to come online, and while executives might be unhappy, oftentimes the competition wasn’t doing much better. CIOs were conditioned to be risk-averse; if systems were running, changing them was scrutinized with great care and rarely rushed.

The culture and practices of the modern IT organization became more established, and while it retained a reputation for being slow, expensive, and inflexible, no-one seemed to have any better ideas. It didn’t hurt that the end customer wasn’t interested in computers.

Then along came the personal computer, and the dot-com boom. Suddenly everyone had personal computers at home and was on the Internet. Buying things! Computers continued to become more reliable and powerful as well. Companies realized that their back-office IT organizations were not able to move fast enough to keep up with the new e-commerce challenge, and in many cases organized their Internet team outside of the CIO’s control (which sometimes made the traditional IT organization very unhappy). Silicon Valley startups such as Google and Facebook in general did not even have a separate “CIO” organization, because for them (and this is a critical point) the digital systems were the product. Going to market against tough competitors (Alta Vista and Yahoo® against Google, Friendster and MySpace against Facebook) wasn’t a question of maximizing efficiency. It was about product innovation and effectiveness and taking appropriate risks in the quest for these rapidly growing new markets.

Let’s go back to our example of the traditional CIO organization. A typical structure under the CIO might look as shown in Classic IT Organization.

org chart
Figure 101. Classic IT Organization

(We had some related discussion in Application, Infrastructure, Development, Operations). Such a structure was perceived to be “efficient” because all the server engineers would be in one organization, while all the Java developers would be in another, and their utilization could be managed for efficiency. Overall, having all the “IT” people together was also considered efficient, and the general idea was that “the business” (sales, marketing, operations, and back-office functions like finance and human resources) would define their "requirements" and the IT organization would deliver systems in response. It was believed that organizing into "centers of excellence” (sometimes called organizing by function) would make the practices of each center more and more effective, and therefore more valuable to the organization as a whole. However, the new digital organizations perceived that there was too much friction between the different functions on the organization chart. Skepticism also started to emerge that “centers of excellence” were living up to their promise. Instead, what was too often seen was the emergence of an “us versus them” mentality, as developers argued with the server and network engineers.

One of the first companies to try a completely different approach was Intuit. As Intuit started selling its products increasingly as services, it re-organized and assigned individual infrastructure contributors - e.g., storage engineers and DBAs - to the product teams with which they worked [4], p.103.

org chart
Figure 102. New IT Organization

This model is also called the "Spotify model” (see New IT Organization). The dotted line boxes (Developers, Quality Assurance, Engineering) are no longer dedicated “centers of excellence” with executives leading them. Instead, they are lighter-weight “communities of interest” organized into chapters and guilds. The cross-functional product teams are the primary way work is organized and understood, and the communities of interest play a supporting role. Henrik Kniberg provided one of the first descriptions of how Spotify organizes along product lines [169]. (Attentive readers will ask: “What happened to the PMO? And what about security?”. There are various answers to these questions, which we will continue to explore in Context III.)

One important note: Human resources management lines of authority in this model may still be by functional center, not product line. This is the case at Spotify. However, the overall power structure shifts in favor of product focus decisively.

The consequences of this transition in organizational style are still being felt and debated. Sriram Narayan is in general an advocate of product organization. However, in his book Agile Organization Design, he points out that “IT work is labor-intensive and highly specialized”, and therefore managing IT talent is a particular organizational capability it may not make sense to distribute [207]. Furthermore, he observes that IT work is performed on medium to long time scales, and “IT culture” differs from “business culture”, concluding that "although a merger of business and IT is desirable, for the vast majority of big organizations it isn’t going to happen anytime soon".

Conversely, Abbott and Fisher in The Art of Scalability argue that: "…​ The difference in mindset, organization, metrics, and approach between the IT and product models is vast. Corporate technology governance tends to significantly slow time-to-market for critical projects …​ IT mindsets are great for internal technology development, but disastrous for external product development” [4 pp. 122-124]. However, it is possible that Abbott and Fisher are overlooking the decline of traditional IT. Hybrid models exist, with “product” teams reporting up under “business” executives, and the CIO still controlling the delivery staff who may be co-located with those teams. We will discuss the alternative models in more detail below.

Conway’s Law

Melvin Conway is a computer programmer who worked on early compilers and programming languages. In 1967 he proposed the thesis that:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. [73].

What does this mean? If we establish two teams, each team will build a piece of functionality (a feature or component). They will think in terms of “our stuff” and “their stuff” and the interactions (or interface) between the two. Perhaps this seems obvious, but as you scale up, it is critical to keep in mind. In particular, as you segment your organization along the AKF y-axis, you will need to keep in mind the difference between features and components. You are on a path to have dozens or hundreds of such teams. The decisions you make today on how to divide functionality and work will determine your operating model far into the future.

Ultimately, Conway’s law tells us that to design a product is also to design an organization and vice versa. This is important for designers and architects to remember.

Defining the Organization

There are many different ways we can apply these ideas of traditional functional organizing versus product-oriented organizing, and features versus components. How do we begin to decide these questions? As a Digital Practitioner in a scaling organization, you need to be able to lead these conversations. The cross-functional, diverse, collaborative team is a key unit of value in the digital enterprise, and its performance needs to be nurtured and protected.

Abbott and Fisher suggest the following criteria when considering organizational structures [4 p. 12]:

  • How easily can I add or remove people to/from this organization? Do I need to add them in groups, or can I add individual people?

  • Does the organizational structure help or hinder the development of metrics that will help measure productivity?

  • Does the organizational structure allow teams to own goals and feel empowered and capable of meeting them?

  • Which types of conflict will arise, and will that conflict help or hinder the mission of the organization?

  • How does this organizational structure help or hinder innovation within my company?

  • Does this organizational structure help or hinder the time-to-market for my products?

  • How does this organizational structure increase or decrease the cost per unit of value created?

  • Does work flow easily through the organization, or is it easily contained within a portion of the organization?

Team Persistence

Team persistence is a key question. The practice in project-centric organizations has been temporary teams, that are created and broken down on an annual or more frequent basis. People “rolled on” and “rolled off” projects regularly in the common heavyweight project management model. Often, contention for resources resulted in fractional project allocation, as in “you are 50% on Project A and 25% on Project B” which could be challenging for individual contributors to manage. With team members constantly coming and going, developing a deep, collective understanding of the work was difficult. Hard problems benefit from team stability. Teams develop both a deeper rational understanding of the problem, as well as emotional assets such as psychological safety. Both are disrupted when even one person on a team changes. Persistent teams of committed individuals also (in theory) reduce destructive multi-tasking and context-switching.

Product and Function

There is a fundamental tension between functional specialization and end-to-end value delivery — the tendency for specialist teams start to identify with their specialty and not the overall mission. The tension may go by different names:

  • Product versus function

  • Value stream versus activity

  • Process versus silo

As we saw previously, there are three major concepts used to achieve an end-to-end flow across functional specialties:

  • Product

  • Project

  • Process

These are not mutually-exclusive models and may interact with each other in complex ways. (See the scaling discussion in the Context III introduction.)

Waterfall and Functional Organization

For example, some manufacturing can be represented as a very simple, sequential process model (see Simple Sequential Manufacturing).

manufacturing sequence
Figure 103. Simple Sequential Manufacturing

The product is already defined, and the need to generate information (i.e., through feedback) is at an absolute minimum.

Even in this simplest model, feedback is important. Much of the evolution of 20th century manufacturing has been in challenging this naive, open-loop model. (Remember our brief discussion of open-loop?) The original, open-loop waterfall model of IT systems implementation (see Waterfall) was arguably based on just such a naive concept.
waterfall
Figure 104. Waterfall

(Review Agile Software Development on waterfall development and Agile history.) Functional, or practice, areas can continually increase their efficiency and economies of scale through deep specialization.

Defining “Practice"

A “practice” is synonymous with “discipline” — it is a set of interrelated precepts, concerns, and techniques, often with a distinct professional identity. “Java programming”, “security”, or “capacity management” are practices. When an organization is closely identified with a practice, it tends to act as a functional silo (more on this to come). For example, in a traditional IT organization, the Java developers might be a separate team from the HTML, CSS and JavaScript specialists. The DBAs might have their own team, and also the architects, business analysts, and quality assurance groups. Each practice or functional group develops a strong professional identity as the custodians of “best practices” in their area. They may also develop a strong set of criteria for when they will accept work, which tends to slow down product discovery.

There are two primary disadvantages to the model of projects flowing in a waterfall sequence across functional areas:

  • It discourages closed-loop feedback

  • There is transactional friction at each hand-off

Go back and review: the waterfall model falls into the “original sin” of IT management, confusing production with product development. As a repeatable production model, it may work, assuming that there is little or no information left to generate regarding the production process (an increasingly questionable assumption in and of itself). But when applied to product development, where the primary goal is the experiment-driven generation of information, the model is inappropriate and has led to innumerable failures. This includes software development, and even implementing purchased packages in complex environments.

The Continuum of Organizational Forms

The following discussion and accompanying set of diagrams is derived from Preston Smith and Don Reinertsen’s thought regarding this problem in Developing Products in Half the Time [264] and Managing the Design Factory [229]. Similar discussions are found in the Guide to the Project Management Body of Knowledge [223] and Abbott and Fisher’s The Art of Scalability [4].

There is a spectrum of alternatives in structuring organizations for flow across functional concerns. First, a lightweight “matrix” project structure may be implemented, in which the project manager has limited power to influence the activity-based work, where people sit, etc. (see Lightweight Project Management Across Functions).

matrix figure
Figure 105. Lightweight Project Management Across Functions

Work flows across the functions, perhaps called "centers of excellence”, and there may be contention for resources within each center. Often, simple “first in, first out” queuing approaches are used to manage the ticketed work , rather than more sophisticated approaches such as cost of delay. It is the above model that Reinertsen was thinking of when he said: “The danger in using specialists lies in their low involvement in individual projects and the multitude of tasks competing for their time.” Traditional I&O organizations, when they implemented defined Service Catalogs, can be seen as attempting this model. (More on this in the discussion of ITIL and shared services.)

Second, a heavyweight project structure may specify much more, including dedicated time assignment, modes of work, standards, and so forth (see Heavyweight Project Management Across Functions). The vertical functional manager may be little more than a resource manager, but does still have reporting authority over the team member and crucially still writes their annual performance evaluation (if the organization still uses those). This has been the most frequent operating model in the traditional CIO organization.

matrix figure
Figure 106. Heavyweight Project Management Across Functions

If even more focus is needed — the now-minimized influence of the functional areas is still deemed too strong — the organization may move to completely product-based reporting (see Product Team, Virtual Functions). With this, the team member reports to the product owner. There may still be communities of interest (Spotify guilds and tribes are good examples) and there still may be standards for technical choices.

matrix figure
Figure 107. Product Team, Virtual Functions

Finally, in the skunkworks model, all functional influence is deliberately blocked, as distracting or destructive to the product team’s success (see Skunkworks Model).

matrix figure
Figure 108. Skunkworks Model

The product team has complete autonomy and can move at great speed. It is also free to:

  • Re-invent the wheel, developing new solutions to old and well-understood problems

  • Bring in new components on a whim (regardless of whether they are truly necessary) adding to sourcing and long-term support complexity

  • Ignore safety and security standards, resulting in risk and expensive retrofits

Early e-commerce sites were often set up as skunkworks to keep the interference of the traditional CIO to a minimum, and this was arguably necessary. However, ultimately, skunkworks is not scalable. Research by the Corporate Executive Board suggests that: “Once more than about 15% of projects go through the fast [skunkworks] team, productivity starts to fall away dramatically.” It also causes issues with morale, as a two-tier organization starts to emerge with elite and non-elite segments [113].

Because of these issues, Don Reinertsen observes that: “Companies that experiment with autonomous teams learn their lessons, and conclude that the disadvantages are significant. Then they try to combine the advantages of the functional form with those of the autonomous team” [229].

The Agile movement is an important correction to dominant IT management approaches employing open-loop delivery across centralized functional centers of excellence. However, the ultimate extreme of the skunkworks approach cannot be the basis for organization across the enterprise. While functionally specialized organizations have their challenges, they do promote understanding and common standards for technical areas. In a product-centric organization, communities of interest or practice provide an important counterbalancing platform for coordination strategies to maintain common understandings.

Scaling the Product Organization

The functional organization scales well. Just keep hiring more Java programmers, or DBAs, or security engineers and assign them to projects as needed. However, scaling product organizations requires more thought. The most advanced thinking in this area is found in the work of Scrum authors such as Ken Schwaber, Mike Cohn, Craig Larman, and Roman Pichler. Scrum, as we have discussed, is a strict, prescriptive framework calling for self-managing teams with:

  • Product owner

  • Scrum master

  • Team member

hierarchy
Figure 109. Product Owner Hierarchy

Let’s accept Scrum and the 2-pizza team as our organizing approach. A large-scale Scrum effort is based on multiple small teams; e.g., representing AKF scaling cube partitions (see Product Owner Hierarchy, similar to [219], p.12; [249]). If we want to minimize multi-tasking and context-switching, we need to ask: “How many product teams can a given product owner handle?”. In Agile Product Management with Scrum, Roman Pichler says: “My experience suggests that a product owner usually cannot look after more than two teams in a sustainable manner” [219 p. 12]. Scrum authors, therefore, suggest that larger-scale products be managed as aggregates of smaller teams. We will discuss how the product structure is defined in Investment and Portfolio.

From Functions to Components to Shared Services

We have previously discussed feature versus component teams. As a reminder, features are functional aspects of software (things people find directly valuable) while components are how software is organized (e.g., shared services and platforms such as data management).

As an organization grows, we see both the feature and component sides scale. Feature teams start to diverge into multiple products, while component teams continue to grow in the guise of shared services and platforms. Their concerns continue to differentiate, and communication friction may start to emerge between the teams. How an organization handles this is critical.

In a world of digital products delivered as services, both feature and component teams may be the recipients of ongoing investment. An ongoing objection in discussions of Agile is: “We can’t put a specialist on every team!". This objection reflects the increasing depth of specialization seen in the evolving digital organization. Ultimately, it seems there are two alternatives to handling deep functional specialization in the modern digital organization:

  • Split it across teams

  • Turn it into an internal product

We have discussed the first option above (split the specialty across teams). But for the second option consider, for example, the traditional role of server engineer (a common infrastructure function). Such engineers historically have had a consultative, order-taking relationship to application teams:

  • An application team would identify a need for computing capacity (“we need four servers”)

  • The infrastructure engineers would get involved and provide recommendations on make, model, and capacity

  • Physical servers would be acquired, perhaps after some debate and further approval cycles

Such processes might take months to complete, and often caused dissatisfaction. With the rise of cloud computing, however, we see the transition from a consultative, order-taking model to an automated, always-on, self-service model. Infrastructure organizations move their activities from consulting on particular applications to designing and sustaining the shared, self-service platform. At that point, are they a function or a product?

Final Thoughts on Organization Forms

Formal organizational structures determine, to a great extent, how work gets done. But enterprise value requires that organizational units — whether product or functional — collaborate and coordinate effectively. Communications structures and interfaces, as covered in Coordination and Process, are therefore an essential part of organizational design.

And of course, an empty structure is meaningless. You need to fill it with real people, which brings us to the topic of human resource management in the digital organization.

Evidence of Notability

Debates over organizational form are frequent of late. The years between 2010 and 2020 have seen a massive shift in many IT and digital organizations, from a focus on deep functional specialization to broader, cross-functional teams. Best practices and lessons at this writing are still unformed. Works such as Narayam’s Agile Organization Design [207] as well as coverage of the topic in other literature and industry guidance provide evidence of notability.

Limitations

Organization design influences, but does not completely determine, organizational results.

Related Topics

IT Human Resources Management

Description

Now that you have decided, for now, on an organization structure, you need to put people into it. As you scale, hiring people (like managing money) becomes a practice requiring formalization, and you will doubtless need to hire your first human resources professional soon, in order to stay compliant with applicable laws and regulations.

Basic Concerns

Human resources management can also be termed "people management”. It is distinct from supply chain and technology management, being concerned with the identification and recruitment, onboarding, ongoing development of, and eventual exit of individuals from an organization. This brief section covers the topic as it relates to digital management, incorporating recent cases and perspectives.

Hiring

Here is a typical hiring process:

  • Solicit candidates, through various channels such as job boards and recruiters

  • Review resumes and narrow candidate pool down for phone interviews

  • Conduct phone interviews and narrow candidate pool down for in-person interviews

  • Conduct in-person interviews, identify candidates for offers

  • Make offer, negotiate to acceptance

  • Hire and onboard

Your organization has been hiring people for some time now. It has always been one of your most important decisions, but you have reached the point where a more formal and explicit understanding of how you do this is essential.

First, why do you hire new staff? How and when do you perceive a need? It is well established that increasing the size of a team can slow it down. Legendary software engineer Fred Brooks, in his work The Mythical Man Month, identified the pattern that “adding more people to a late project makes it later” [43].

Are you adding people because of a perceived need for specialist skills? While this will always be a reason for new hires, many argue in favor of “T-shaped” people — people who are deep in one skill, and broad in others. Hiring new staff has an impact on culture — is it better to train from within, or source externally?

Second, how are you hiring staff? In a traditional, functionally specialized model, someone in a human resources organization acts as an intermediary between the hiring manager, and the job applicant (sometimes with a recruiter also in the mix between the company and the applicant). Detailed job descriptions are developed, and applicants not explicitly matching the selection criteria (e.g., in their resume) are not invited for an interview.

Such practices do not necessarily result in good outcomes. Applicants routinely tailor resumes to the job description. In some cases, they have been known to copy the job description into invisible sections of their resume so that they are guaranteed a “match” if automated resume-scanning software is used.

A compelling case study of the limitations of traditional human resources-driven hiring is discussed by Robert Sutton and Huggy Rao in Scaling up Excellence: Getting to More without Settling for Less [274]. The authors describe the company Lotus Software, one of the pioneers of early desktop computing.

With [company founder] Kapor’s permission, [head of organizational development] Klein pulled together the resumes of the first 40 Lotus employees …​ [and] submitted all 40 resumes to the Lotus human resources department. Not one of the 40 applicants, including Kapor, was invited for a job interview. The founders had built a world that rejected people like them.

Sean Landis, author of Agile Hiring [2], believes that: “accepted hiring wisdom is not very effective when applied to software professionals”. He further states that:

  • Very few companies hire well

  • Individuals with deep domain knowledge are in the best position to perform great hiring

  • Companies often focus on the wrong candidates

  • It is important to track metrics on the cost and effectiveness of hiring practices

In short, hiring is one of the most important decisions the digital enterprise makes, and it cannot be reduced to a simple process to be executed mechanically. Requiring senior technical talent to interview candidates may result in improved hiring decisions. However, such requirements add to the overall work demands placed on these individuals.

Finally, it is important to understand the costs of a bad hire. One risk is hiring "toxic" individuals who do not work well with others, degrade team morale, and even drive good employees to leave. Recent research by Michael Housman and Dylan Minor suggests that while the benefit from hiring a highly qualified “superstar” worker at most is $5,303, the cost of hiring a “toxic” worker (one destructive of morale and team norms) averages $12,489 — certainly a risk to consider [132].

Process as Skill

Sometimes new employees come in expecting that you are following certain processes. This is in part because “process” experience can be an important part of an employee’s career background. A skilled human resources manager may consider their experience with large-scale enterprise hiring processes to be a major part of their qualifications for a position in your company.

This applies to both “business” and “IT” processes. In fact, in the digital world, there is no real difference. Digital processes:

  • Initiate new systems, from idea to construction

  • Publicize and grant access to the new systems

  • Capture revenue from the systems

  • Support people in their interactions with the systems

  • Fix the systems when they break

  • Improve the systems based on stakeholder feedback

It is not clear which of these are “IT” versus “business” processes. But they are definitely processes. Some of them are more predictable, some less so, but they all represent some form of ordered work that is repeatable to some degree. And to some extent, you may be seeking people with experience defined at least in part by their exposure to processes.

Education and Training

Human resources departments are frequently responsible for education and training. Sometimes, employees take trainings and then through some form of examination or other proof, achieve a "certification" which can further their career. ITIL and PMBOK have been well-known IT certifications offered to individuals.

More recently, organizations have embraced a "dojo" approach; immersive environments where entire teams are trained [251]. Such approaches focus more on learning by doing, as opposed to passing multiple-choice tests (the basis of basic ITIL and PMBOK certification).

Allocation and Tracking People’s Time

When a new hire enters your organization, they enter a complex system that will structure and direct their daily activities through a myriad of means. The various means that direct their action include:

  • Team assignment (e.g., to an ongoing product)

  • Project assignment

  • Process responsibilities

Notice again the appearance of the "3 Ps".

Product, project, and process become challenging when they are all allowed to generate demand on individuals independently of each other. In the worst-case scenario, the same individual winds up with:

  • Collaborative team responsibilities

  • “Fractional” allocation to one or more projects

  • Ticketed process responsibilities

Fractional allocation is the practice of funding individuals through assigning them at some % to a project. For example, a server engineer might be allocated 25% time to a project for six months to define its infrastructure architecture, while being assigned 30% to another project to refresh obsolete infrastructure.

When demand is un-coordinated, these multiple channels can result in multi-tasking and dramatic overburden and, in the worst case, the individual becomes the constraint to enterprise value. Project managers expect deliverables on time, and too often have no visibility to operational concerns (e.g., outages) that may affect the ability of staff to deliver. Ad hoc requests “smaller than a project, bigger than a ticket” further complicate matters.

The Phoenix Project presents an effective and realistic dramatization of the resulting challenges. Work is entering the system through multiple channels, and the overburden on key individuals (such as Brent, the lead systems engineer) has reached crisis proportions. Through a variety of mechanisms, they take control of the demand channels and greatly improve the organization’s success. One of the most important lessons is well articulated by Erik, the mentor:

“Your job as VP of IT Operations is to ensure the fast, predictable, and uninterrupted flow of planned work that delivers value to the business while minimizing the impact and disruption of unplanned work, so you can provide stable, predictable, and secure IT service …​ You must figure out how to control the release of work into IT Operations and, more importantly, ensure that your most constrained resources are doing only the work that serves the goal of the entire system, not just one silo. [165 p. 91+]+

In order to understand the work, measuring the consumption of people’s time is important. There are various time-tracking approaches:

  • Simple allocation of staff payroll to product or organizational line

  • Project management systems (sometimes these are used for weekly time tracking, even for staff that are not assigned to projects — in such cases, placeholder operational projects are created)

  • Human resources management systems

  • Ticketing/workflow systems — advanced systems, such as those found in the Professional Services Automation sector, track time when tickets are in an “open” status

  • Backlog management systems (that may seem similar to ticketing systems)

  • Home-built systems

There is little industry consensus on best practices here. There are reasonable concerns about the burden of time tracking on employees, and poor data quality resulting from employees attempting to “code” activities when summarizing their time on a weekly or bi-weekly basis.

Accountability and Performance

Regardless of whether the company is a modern digital enterprise or more traditional in its approach, the commitment, performance, and results of employees is a critical concern. The traditional approach to managing this has been an annual review cycle, resulting in a performance ranking from 1 to 5:

  1. Did not meet expectations

  2. Partially met expectations

  3. Met expectations

  4. Exceeded expectation

  5. Significantly exceeded expectations

This annual rating determines the employee’s compensation and career prospects in the organization. Some companies, notably GE and Microsoft, have attempted “stack rankings” in which the “bottom” 10% (or more) performers must be terminated. As the Davis and Daniels quote above indicates, such practices are terribly destructive of psychological safety and therefore team cohesion. High-profile practitioners are therefore moving away from this practice [45], [213].

The traditional annual review is a large “batch” of feedback to the employee, and therefore ineffective in terms of systems theory, not much better than an open-loop approach. Because of the weaknesses of such slow feedback (not to mention the large annual costs, expensive infrastructure, and opportunity costs of the time spent), companies are experimenting with other approaches.

Deloitte Consulting, as reported in the Harvard Business Review [46], realized that its annual performance review process was consuming two million hours of time annually, and yet was not delivering the needed value. In particular, ratings were suffering from the measurable flaw that they tended to reveal more about the person doing the rating, than the person being rated!

They started by redefining the goals of the performance management system to identify and reward performance accurately, as well as further fueling improvements.

A new approach with greater statistical validity was implemented, based on four key questions:

  • Given what I know of this person’s performance, and if it were my money, I would award this person the highest possible compensation increase and bonus

  • Given what I know of this person’s performance, I would always want him or her on my team

  • This person is at risk for low performance

  • This person is ready for promotion today

In terms of the frequency of performance check-ins, they note:

…​ the best team leaders …​ conduct regular check-ins with each team member about near-term work …​ to set expectations for the upcoming week, review priorities, comment on recent work and provide course correction, coaching, or important new information …​ If a leader checks in less often than once a week, the team member’s priorities may become vague …​ the conversation will shift from coaching for near-term work to giving feedback about past performance …​ If you want people to talk about how to do their best work in the near future, they need to talk often …​

Sutton and Rao, in Scaling up Excellence, discuss the similar case of Adobe. At Adobe: “annual reviews required 80,000 hours of time from the 2,000 managers at Adobe each year, the equivalent of 40 full-time employees. After all that effort, internal surveys revealed that employees felt less inspired and motivated afterwards — and turnover increased”. Because of such costs and poor results, Adobe scrapped the entire performance management system in favor of a “check-in” approach. In this approach, managers are expected to have regular conversations about performance with employees and are given much more say in salaries and merit increases. The managers themselves are evaluated through random “pulse surveys” that measure how well each manager “sets expectations, gives and receives feedback, and helps people with their growth and development” [274 p. 113].

Whether incentives (e.g., pay raises) should be awarded individually or on a team basis is an ongoing topic of discussion in the industry. Results often derive from team performance, and the contributions of any one individual can be difficult to identify. Because of this, Scrum pioneer Ken Schwaber argues that: “the majority of the enterprise’s bonus and incentive funds need to be allocated based on the team’s performance rather than the individual’s performance” [249 p. 6]. However, this runs into another problem: that of the “free-rider”. What do we do about team members who do not pull their weight? Even in self-organizing teams, confronting someone about their behavior is not something people do willingly, or well.

Ideally, teams will self-police, but this becomes less effective with scale. In one case study in the Harvard Business Review, Continental Airlines found that the free rider problem was less of a concern when metrics were clearly correlated with team activity. In their case, the efforts and cooperation of gate teams had a significant influence on On-Time Arrival and Departure metrics, which could then be used as the basis for incentives [168].

Ultimately, both individuals and teams need coaching and direction. Team-level management and incentives must still be supplemented with some feedback loops centering on the individual. Perhaps this feedback is not compensation-based, but the organization must still identify individuals with leadership potential and deal with free riders and toxic individuals.

Observed behaviors are a useful focus. Sean Landis describes the difference between behaviors and skills as follows:

Two things make good leaders: behaviors and skills. If you focus on behaviors in your hiring of developers, they will be predisposed for leadership success. The hired candidate may walk in the door with the skills necessary to lead or not. If not, skills are easy to acquire through training and mentoring. People can acquire or modify behaviors, but it is much harder than skill development. Hire for behaviors and train the leadership skills. [2+]+

He further provides many examples of behaviors, such as:

  • Adaptable

  • Accountable

  • Initiative-taker

  • Optimistic

  • Relational

Evidence of Notability

Many executives and military leaders have identified the central importance of hiring decisions. In large, complex organizations, choosing the right people is the most powerful lever a leader has to drive organizational performance. The organizational context these new hires find themselves in will profoundly affect them and the results of their efforts.

Limitations

Hiring the right individuals will not lead to organizational success if other aspects of the operating model are ineffective; e.g., demand and execution management that encourage too much work-in-process.

Related Topics

Why Culture Matters

Description

“Culture” is a difficult term to define, and even more difficult to characterize across large organizations. It starts with how an organization is formally structured, because structure is, in part, a set of expectations around how information flows. “Who talks to who, when and why” is in a sense culture. Culture can also be seen embedded in artifacts like processes and formally specified operating models.

But “culture” has additional, less tangible meanings. The anecdotes executives choose to repeat are culture. Whether an organization tacitly condones being five minutes late for meetings (because walk time in large facilities is expected) or has little tolerance for this (because most people dial in) is culture. The degree of deference shown to senior executives, and their opinions, is culture. Whether a junior person dares to hit “reply-all” on an email including her boss’s boss is culture. Organizational tolerance for competitive or toxic behavior is culture.

Culture cannot be directly changed — it is better seen as a lagging indicator, that changes in response to specific practical interventions. Even tools and processes can change the culture, if they are judiciously chosen (most tools and processes do not have this effect). Skeptical? Consider the impact that computers — a tool — have had on culture. Or email.

We have already touched on culture in the Product Management discussion of team formation. These themes of psychological safety, equal collaboration, emotional awareness, and diversity inform our further discussions. We will look at culture from a few additional perspectives in this section:

  • Motivation

  • Schneider matrix

  • The Westrum typology

  • Mike Rother’s research into Toyota’s improvement and coaching “katas”

Motivation

One of the most important reasons to be concerned about culture is its effect on motivation. There is little doubt that a more motivated team performs better than an unmotivated, “going through the motions” organization. But what motivates people?

One of the oldest discussions of culture is Douglas McGregor’s idea of “Theory X” versus “Theory Y” organizations, which he developed in the 1960s at the Massachusetts Institute of Technology.

“Theory X” organizations rely on extrinsic motivators and operate on the assumption that workers must be cajoled and punished in order to produce results. We see Theory X approaches when organizations focus on pay scales, bonuses, titles, awards, writeups/demerits, performance appraisals, and the like.

Theory Y organizations operate on the assumption that most people seek meaningful work intrinsically and that they have the ability to solve problems in creative ways that do not require tight standardization. According to Theory Y, people can be trusted and should be treated as mature individuals, in contrast to the distrust inherent in Theory X.

Related to Theory Y, in terms of intrinsic motivation, Daniel Pink, the author of Drive, suggests that three concepts are key: autonomy, mastery, and purpose. If these three qualities are experienced by individuals and teams, they will be more likely to feel motivated and collaborate more effectively.

Schneider and Westrum

One model for understanding culture is the matrix proposed by William Schneider (see Schneider Matrix, similar to [248]).

matrix
Figure 110. Schneider Matrix

Two dimensions are proposed:

  • The extent to which the culture is focused on the company or the individual

  • The extent to which the company is “possibility-oriented” versus “reality-oriented”

This is not a neutral matrix. It is not clear that highly controlling cultures are ever truly effective. Even in the military, which is generally assumed to be the ultimate “command and control” culture, there are notable case studies of increased performance when more empowering approaches were encouraged.

For example, military commanders realized as long ago as the Napoleonic wars that denying soldiers and commanders autonomy in the field was a good way to lose battles. Even in peacetime operations, forward-thinking military commanders continue to focus on “what, not how”.

In Turn the Ship Around: A True Story of Turning Followers into Leaders, Captain L. David Marquette discusses moving from a command-driven to an outcome-driven model, and the beneficial results it had on the USS Santa Fe [189]. Similar themes appear in Captain D. Michael Abrashoff’s It’s Your Ship: Management Techniques from the Best Damn Ship in the Navy [5].

Neither of these accounts is surprising when we consider the more sophisticated aspects of military doctrine. Don Reinertsen provides a rigorous overview in Chapter 9 of Principles of Product Development Flow. In this discussion, he notes that the military has been experimenting with centralized versus decentralized control for centuries. Modern warfighting relies on autonomous, self-directed teams that may be out of touch with central command and required to improvise effectively to achieve the mission. Therefore, military orders are incomplete without a statement of “commander’s intent” — the ultimate outcome of the mission [230], pp.243-265. Military leaders are also concerned with pathological "toxic command” which is just as destructive in the military as anywhere else [293].

Similar to the Schneider matrix is the Westrum typology, which proposes that there are three major types of culture:

  • Pathological

  • Bureaucratic

  • Generative

The cultural types exhibit the following behaviors:

Table 20. Westrum Typology
Pathological (Power-oriented) Bureaucratic (Rule-oriented) Generative (Performance-oriented)

Low cooperation

Modest cooperation

High cooperation

Messengers (of bad news) shot

Messengers neglected

Messengers trained

Failure is punished

Failure leads to justice

Failure leads to inquiry

(Excerpted from [224].)

The State of DevOps research has demonstrated a correlation between generative cultures and digital business effectiveness [224], [44]. Notice also the relationship to blameless postmortems discussed in Operations Management.

State of DevOps Survey Research

DevOps is a broad term, first introduced in DevOps Technical Practices. As noted in that section, DevOps includes continuous delivery, team behavior and product management, and culture. Puppet Labs has sponsored an annual survey for the last five years, the State of DevOps report. It consists of annual surveys with 25,000 individual data points. It shows a variety of correlations including:

  • Core continuous delivery practices such as version control, test automation, deployment automation, and continuous integration increase team engagement and IT and organizational performance

  • Lean product management approaches such as seeking fast feedback and splitting work into small batches also increase team engagement and IT and organizational performance [44]

Toyota Kata

Academics and consultants have been studying Toyota for many years. The performance and influence of the Japanese automaker are legendary, but it has been difficult to understand why. Much has been written about Toyota’s use of particular tools, such as Kanban bins and Andon boards. However, Toyota views these as ephemeral adaptations to the demands of its business.

toyota kata
Figure 111. Toyota Kata

According to Mike Rother in Toyota Kata [238], underlying Toyota’s particular tools and techniques are two powerful practices:

  • The improvement kata

  • The coaching kata

What is a kata? It is a Japanese word stemming from the martial arts, meaning pattern, routine, or drill. More deeply, it means “a way of keeping two things in alignment with each other”. The improvement kata is the repeated process by which Toyota managers investigate and resolve problems, in a hands-on, fact-based, and preconception-free manner, and improve processes towards a “target operating condition”. The coaching kata is how the improvement kata is instilled in new generations of Toyota managers (see Toyota Kata, similar to [238]).

As Rother describes it, the coaching and improvement katas establish and reinforce a coherent culture or mental model of how goals are achieved and problems approached. It is understood that human judgment is not accurate or impartial. The method compensates with a teaching-by-example focus on seeking facts without preconceived notions, through direct, hands-on investigation and experimental approaches.

This is not something that can be formalized into a simple checklist or process; it requires many guided examples and applications before the approach becomes ingrained in the upcoming manager.

Evidence of Notability

Culture quickly emerged as one of the key concerns of the DevOps community. Google’s research into psychological safety is a concrete validation of its importance and notability.

Limitations

Culture is both intangible and a lagging indicator. Culture cannot be changed through exhortations to "be more collaborative" and so forth. However, organizational priorities that are perceived to be real - as in reinforced by performance objectives - can change culture. Work practices (including even the use of certain technologies) can and do change culture. (Skeptical? Think about how email changed work culture, for better and worse.)

Related Topics

Industry Frameworks

Description

This culminating section consists of a critical examination of the IT management frameworks, which can be seen as structured approaches to many concerns discussed in Context III: coordination, processes, investment management, projects, and organizational structures.

Industry frameworks and bodies of knowledge play a powerful role in shaping organizational structures and their communication interfaces, and creating a base of people with consistent skills to fill the resulting roles. While there is much of value in the frameworks, they may lead you into the planning fallacy or defined process traps. Too often, they assume that variation is the enemy, and they do not provide enough support for the alternative approach of empirical process control. At the time of publication, the frameworks are challenged on many fronts by Agile, Lean, and DevOps approaches.

Defining Frameworks

There are other usages of the term “framework”, especially in terms of software frameworks. Process and management frameworks are non-technical.

So, what is a “framework”? The term “framework”, in the context of a business process, is used for comprehensive and systematic representations of the concerns of a professional practice. In general, an industry framework is a structured artifact that seeks to articulate a professional consensus regarding a domain of practice. The intent is usually that the guidance be mutually-exclusive and collectively exhaustive within the domain so that persons knowledgeable in the framework have a broad understanding of domain concerns.

The first goal of any framework, for a given conceptual space, is to provide a “map” of its components and their relationships. Doing this serves a variety of goals:

  • Develop and support professional consensus in the business area

  • Support training and orientation of professionals new to the area (or its finer points)

  • Support governance and control activities related to the area (more on this in Governance, Risk, Security, and Compliance)

Many frameworks have emerged in the IT space, with broader and narrower domains of concern. Some are owned by non-profit standards bodies; others are commercial. We will focus on five in this document. In roughly chronological order, they are:

  • CMMI (Capability Maturity Model Integration)

  • ITIL (originally the Information Technology Infrastructure Library)

  • PMBOK (Project Management Body of Knowledge)

  • COBIT (originally Control Objectives for Information Technology)

  • The TOGAF framework (The Open Group standard for Enterprise Architecture)

Both ITIL and COBIT have recently released new versions (COBIT 2019, ITIL 4) which respond in some measure to these challenges noted above. However, since much of the current industry practice still reflects earlier versions, the discussion here will remain for the forseeable future.

Observations on the Frameworks

In terms of the new digital delivery approaches, there are a number of issues and concerns with the frameworks:

  • The misuse of statistical process control

  • Local optimization temptation

  • Lack of execution model

  • Proliferation of secondary artifacts, compounded by batch-orientation

  • Confusion of process definition

The Misuse of Statistical Process Control

Some frameworks, notably the original Capability Maturity Model (CMM), emphasize statistical process control. However, as we discussed in the previous section, process control theorists see creative, knowledge-intensive processes as requiring empirical control. Statistical process control applied to software has therefore been criticized as inappropriate [226].

In CMM terms, empirical process control starts by measuring and immediately optimizing (adjusting). As Martin Fowler notes: “a process can still be controlled even if it can’t be defined" [250]. They need not - and cannot - be fully defined. Therefore, it is highly questionable to assume that process optimization is something only done at the highest levels of maturity.

This runs against much current thinking and practice, especially that deriving from Lean philosophy, in which processes are seen as always under improvement. (See discussion of Toyota Kata.) All definition, measurement, and control must serve that end.

PMBOK suggests that “control charts may also be used to monitor cost and schedule variances, volume, and frequency of scope changes, or other management results to help determine if the project management processes are in control” [223 pp. 4108-4109]. This also contradicts the insights of empirical process control, unless the project was also a fully defined process - unlikely from a process control perspective.

Local Optimization Temptation

IT capability frameworks can be harmful if they lead to fragmentation of improvement effort and lack of focus on the flow of IT value.

The digital delivery system at scale is a complex socio-technical system, including people, process, and technology. Frameworks help in understanding it, by breaking it down into component parts in various ways. This is all well and good, but the danger of reductionism emerges.

There are various definitions of "reductionism”. This discussion reflects one of the more basic versions.

A reductionist view implies that a system is nothing but the sum of its parts. Therefore, if each of the parts is attended to, the system will also function well.

This can lead to a compulsive desire to do “all” of a framework. If ITIL v2011 calls for 25 processes, then a large, mature organization by definition should be good at all of them. But the 25 processes (and dozens more sub-processes and activities) called for by ITIL v2011 [1], or the 32 called for in COBIT 5, are somewhat arbitrary divisions. They overlap with each other. Furthermore, there are many digital organizations that do not use a full framework-based process portfolio and yet deliver value as well as organizations that do use the frameworks to a greater degree.

The temptation for local, process-level optimization runs counter to core principles of Lean and systems thinking. Many management thinkers, including W. Edwards Deming, Eli Goldratt, and others have emphasized the dangers of local optimization and the need for taking a systems view.

As this document’s structure suggests, the delivering of IT value requires different approaches at different scales. There is recognition of this among framework practitioners; however, the frameworks themselves provide insufficient guidance on how they scale up and down.

Lack of Execution Model

It is also questionable whether even the largest actual IT organizations on the planet could fully implement the full scope of the process-based frameworks. Specifying too many interacting processes has its own complications. Consider: Both ITIL 2011 and COBIT devote considerable time to documenting possible process inputs and outputs. As a part of every process definition, ITIL 2011 had a section entitled “triggers, inputs, outputs, and interfaces”. The “Service-Level Management Process” [281 pp. 120-122], for example, lists:

  • 7 triggers (e.g., “service breaches”)

  • 10 inputs (e.g., “customer feedback”)

  • 10 outputs (e.g., “reports on OLAs”)

  • 7 interfaces (e.g., “supplier management”)

COBIT similarly details process inputs and outputs. In the Enabling Processes guidance, each management practice suggests inputs and outputs. For example, the APO08 process “Manage Relationships” has an activity of “Provide input to the continual improvement of services”, with:

  • 6 inputs

  • 2 outputs

But processes do not run themselves. These process inputs and outputs require staff attention. They imply queues and therefore work-in-process, often invisible. They impose a demand on the system, and each hand-off represents transactional friction. Some hand-offs may be implemented within the context of an IT management suite; others may require procedural standards, which themselves need to be created and maintained. The industry currently lacks understanding of how feasible such fully elaborated frameworks are in terms of the time, effort, and organizational structure they imply.

We have discussed the issue of overburden previously. Too many organizations have contending execution models, where projects, processes, and miscellaneous work all compete for people’s attention. In such environments, the overburden and wasteful multi-tasking can reach crisis levels. With ITIL in particular, because it does not cover project management or architecture, we have a very large quantity of potential process interactions that is nevertheless incomplete. (It should be noted that ITIL 4 now terms its primary concerns "practices", not "processes" - this is a notable shift.)

Secondary Artifacts, Compounded by Batch-Orientation

The process hand-offs also imply that artifacts (documents of various sorts, models, software, etc.) are being created and transferred in between teams, or at least between roles on the same team with some degree of formality. Primary artifacts are executable software and any additional content intended directly for value delivery. Secondary artifacts are anything else.

An examination of the ITIL and COBIT process interactions shows that many of the artifacts are secondary concepts such as “plans”, “designs”, or “reports”:

  • Design specifications (high-level and detailed)

  • Operation and use plan

  • Performance reports

  • Action plans

  • Consideration and approval

and so on. (Note that actually executable artifacts; e.g., source code, are not included here.)

Again, artifacts do not create themselves. Dozens of artifacts are called for in the process frameworks. Every artifact implies:

  • Some template or known technique for performing it

  • People trained in its creation and interpretation

  • Some capability to store, version, and transmit it

Unstructured artifacts such as plans, designs, and reports, in particular, impose high cognitive load and are difficult to automate. As digital organizations automate their pipelines, it becomes essential to identify the key events and elements they may represent, so that they can be embedded into the automation layer.

Finally, even if a given process framework does not specifically call for waterfall, we can sometimes still see its legacy. For example:

  • Calls for thorough, “rigorous” project planning and estimation

  • Cautions against “cutting corners”

  • “Design specifications” moving through approval pipelines (and following a progression from general to detailed)

All of these tend to signal a large batch-orientation, even in frameworks making some claim of supporting Agile.

Good system design is a complex process. We introduced technical debt in Application Delivery, and will revisit it in Architecture. But the slow feedback signals resulting from the batch processes implied by some frameworks are unacceptable in current industry. This is in part why new approaches are being adopted.

Confusion of Process Definition

One final issue with the “process” frameworks is that, while they use the word “process” prominently, they are not aligned with BPM best practices [30].

All of these frameworks provide useful descriptions of major ongoing capabilities and practices that the large IT organization must perform. But in terms of our preceding discussion on process method, they, in general, are developed from the perspective of steady-state functions, as opposed to a value stream or defined process perspective.

The BPM community is clear that processes are countable and event-driven (see [255]). Naming them with a strong, active verb is seen as essential. “True” IT processes, therefore, might include:

  • Accept Demand

  • Deliver Release

  • Complete Change

  • Resolve Incident

  • Improve Service

However, if reviewing ITIL, a BPM consultant would see the "process" called “Capacity Management” and observe that it is not countable or event-driven. “How many capacities did you do today?” is not a sensible question, for the most part.

Evidence of Notability

The major frameworks have had an enormous influence on digital and IT management. They drive many of the basic assumptions encountered in digital management and IT practices. Consultancies and training organizations monetize them; auditors assess organizations against their "best practices".

Limitations

Frameworks struggle to strike a balance between too extremes: being either too specific and prescriptive versus being too abstract and theoretical. In the digitally transforming economy, informed by Agile practices, they seem to specify simple cookbook recipes to increasingly dynamic and complex problems. Is this inherent to any framework? Can a new framework overcome these issues? That, in part, is the motivation for this document.

Related Topics


1. Note that ITIL 4 has renamed "processes" as "practices".