DevOps-Leader Practice Questions

Google's "Project Aristotle" was an extensive internal study to determine the factors of high-performing teams. The research concluded that the single most important dynamic is psychological safety — a shared belief that team members will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes. This foundation of safety enables the interpersonal risk-taking necessary for innovation, learning, and problem-solving. It was found to be more critical than any other factor, including individual skills or team structure, and it underpins the other four key dynamics: dependability, structure & clarity, meaning, and impact.

A. Team members are all located in the same office.

Project Aristotle's research found that co-location was not a significant predictor of team effectiveness.

B. The team has a strong, hierarchical management structure.

A rigid hierarchy can inhibit psychological safety; the study found team norms, not management style, were key.

D. Individual performance is the primary measure of success.

The study emphasized collective success and group norms over focusing solely on individual high-performers.

1. Official Vendor Documentation: Rozovsky, J. (2015, November 17). The five keys to a successful Google team. Google re:Work. Retrieved from https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/. This is the primary source from the Google research team, stating, "Psychological safety was far and away the most important of the five dynamics we found."

2. Peer-Reviewed Academic Publication: Newman, A., Donohue, R., & Eva, N. (2017). Psychological safety: A systematic review of the literature. Human Resource Management Review, 27(3), 521-535. (See Section 1, Introduction, para. 2). This review discusses the growing importance of psychological safety, highlighting Google's Project Aristotle as a key real-world study demonstrating its impact on team performance. https://doi.org/10.1016/j.hrmr.2017.01.001

3. University Publication: Deloitte, & Amy C. Edmondson. (2023). The role of psychological safety in leadership and team development. MIT Sloan Management Review. This article from an MIT publication discusses the concept pioneered by Edmondson and validated by studies like Project Aristotle, emphasizing its role in creating high-performance environments.

Transformational leadership is defined by four key dimensions, often called the "Four I's." The behavior described—challenging assumptions, taking risks, and soliciting ideas—directly corresponds to the dimension of Intellectual Stimulation. This component involves encouraging creativity and innovation among followers by questioning the status quo and reframing problems. A DevOps Leader uses this approach to foster a culture of continuous improvement and experimentation, which is essential for high-performing teams. They empower their teams to think critically and contribute novel solutions, moving beyond conventional methods to achieve organizational goals.

A. They focus on contingent rewards and manage by exception.

This describes transactional leadership, which relies on exchanges and corrective actions rather than inspiration and empowerment.

B. They avoid making decisions and abdicate responsibilities.

This is characteristic of a laissez-faire leadership style, which is generally ineffective and passive, not transformational.

C. They make decisions unilaterally and expect compliance.

This describes an autocratic or command-and-control leadership style, which stifles the creativity and autonomy central to DevOps.

1. PeopleCert. (2022). PeopleCert DevOps Leader Candidate Syllabus. Version 1.1. Section 2.2.1, "The four components of transformational leadership," lists Intellectual Stimulation as a core dimension, which involves stimulating followers' efforts to be innovative and creative.

2. Bass, B. M. (1990). From transactional to transformational leadership: Learning to share the vision. Organizational Dynamics, 18(3), pp. 22-23. This foundational article defines Intellectual Stimulation as a leader's role in arousing followers "to think in new ways and emphasize problem-solving and the use of reasoning before taking action." (DOI: https://doi.org/10.1016/0090-2616(90)90061-S)

3. Northouse, P. G. (2018). Leadership: Theory and Practice (8th ed.). Sage Publications. Chapter 8, "Transformational Leadership," describes Intellectual Stimulation as leadership that "stimulates followers to be creative and innovative and to challenge their own beliefs and values as well as those of the leader and the organization" (p. 172).

In Value Stream Mapping each quality-related metric has a “mirror” that expresses the same reality from the opposite angle. “% Rework” measures the proportion of work that must be redone; its mirror therefore measures work that flows through first time without needing rework. In the PeopleCert DevOps Leader courseware this mirror is called “% Complete & Accurate (C&A),” also known as First-Pass Yield. A high % C&A automatically means low % Rework and vice-versa, satisfying the definition of a mirror metric.

A. Lead Time – measures elapsed time, not quality; not the inverse of rework.

C. Cycle Time – process time per item; unrelated to defect rate.

D. Work In Progress (WIP) – inventory level, has no direct inverse relationship with rework.

1. PeopleCert. “DevOps Leader Official Training Material”, v1.0, Module 5: Value Stream Mapping, slide 14 “Mirror Metrics – % Rework ↔ % Complete & Accurate”.

2. Forsgren, Humble & Kim. “Accelerate: The Science of Lean Software and DevOps”, 2018, ch.3, Quality & Stability; discusses first-pass yield as complement to rework.

3. MIT OpenCourseWare, 15.760A “Lean/Six Sigma Systems”, Lecture 7, slide 18 “First Pass Yield vs Rework” – defines mirror relationship.

David Kolb's Experiential Learning Theory model is based on two axes: the perception continuum (how we think or feel) and the processing continuum (how we do things). "Thinking" corresponds to Abstract Conceptualization (AC), and "watching" corresponds to Reflective Observation (RO). The learning style that combines these two is Assimilating. Individuals with this style are skilled at processing a wide range of information and organizing it into a clear, logical format. They are more interested in abstract ideas and concepts than in people and practical application, excelling at creating theoretical models.

(Assuming a standard option list for Kolb's styles)

A. Diverging: This style combines feeling (Concrete Experience - CE) and watching (Reflective Observation - RO), focusing on brainstorming and imaginative ability.

C. Converging: This style combines thinking (Abstract Conceptualization - AC) and doing (Active Experimentation - AE), focusing on problem-solving and practical application of ideas.

D. Accommodating: This style combines feeling (Concrete Experience - CE) and doing (Active Experimentation - AE), focusing on hands-on experience and carrying out plans.

1. Vanderbilt University, Center for Teaching. (2023). Kolb’s Experiential Learning Theory. Vanderbilt University. Retrieved from https://cft.vanderbilt.edu/guides-sub-pages/kolbs-experiential-learning-theory/. In the section "Learning Styles," the Assimilating style is explicitly defined by the intersection of Abstract Conceptualization (Thinking) and Reflective Observation (Watching).

2. Kolb, D. A. (1984). Experiential learning: Experience as the source of learning and development. Prentice-Hall. In Chapter 4, "The Structure of Learning and Knowledge," Kolb details the four learning styles. The Assimilating style is described on pages 77-78 as having strengths in inductive reasoning and creating theoretical models, corresponding to the AC-RO quadrant.

3. University of Leicester. (n.d.). David Kolb. Student Learning Development. Retrieved from https://www2.le.ac.uk/departments/lili/projects/g-step/resources/david-kolb. The "Learning Styles" diagram and accompanying text confirm that Assimilating (assimilator) involves "Watching and Thinking" (Reflective Observation and Abstract Conceptualization).

The Beyond Budgeting model consists of 12 principles designed to create a more adaptive and empowered organization. One of its core management principles is to move away from fixed, negotiated annual targets. Instead, it advocates for setting relative and ambitious goals based on external benchmarks (like competitors) or internal benchmarks (like other teams) to foster a culture of continuous improvement. This approach prevents the gaming of targets and encourages performance that is competitive in the current market environment, rather than just meeting an arbitrary internal number.

A. Centralize decision-making for efficiency.

This is incorrect. Beyond Budgeting promotes decentralization, empowering frontline teams with the autonomy and authority to make decisions.

C. Allocate resources through detailed annual budgets.

This is incorrect. This describes the traditional budgeting process that Beyond Budgeting explicitly seeks to replace with more dynamic, on-demand resource allocation.

D. Reward individuals for meeting fixed, pre-negotiated targets.

This is incorrect. Beyond Budgeting advocates for rewarding shared success based on relative performance, moving away from individual bonuses tied to fixed targets.

1. Bogsnes, B. (2016). Implementing Beyond Budgeting: Unlocking the Performance Potential. Wiley. In Chapter 2, "The Beyond Budgeting Principles," principle #8 is "Targets: Set relative and ambitious goals for continuous improvement; don't negotiate fixed performance contracts" (p. 26). This directly supports the correct answer. The book also explicitly refutes the concepts in the incorrect options, such as annual budgets (Principle #10) and fixed performance contracts (Principle #12).

2. Hope, J., & Fraser, R. (2003). Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap. Harvard Business School Press. The authors introduce the 12 principles, with a key focus on establishing "relative performance contracts" (Chapter 7, pp. 131-148) instead of fixed targets, and moving away from centralized control and annual budgets.

3. Frow, N., Marginson, D., & Ogden, S. (2010). "Continuous" budgeting: Reconciling budget flexibility with budgetary control. Accounting, Organizations and Society, 35(4), 444-461. This paper analyzes the Beyond Budgeting model, noting that a key feature is the use of "relative improvement contracts" and moving away from the "fixed performance contract" inherent in traditional budgeting (Section 2.2, p. 446). https://doi.org/10.1016/j.aos.2009.10.004

The scenario describes a common problem where an IT department is busy but has low throughput, indicating poor workflow. Visualizing work, often through a Kanban board, makes bottlenecks and priorities visible to all stakeholders. Limiting Work in Progress (WIP) is a core principle of Lean and DevOps that forces the team to finish existing tasks before starting new ones. This reduces context-switching, improves focus, and accelerates the flow of value from development to the client. By managing the flow of work, the team can deliver valuable changes to clients more frequently and predictably.

B. Increasing the budget for the IT department to hire more staff.

Adding more people to a system with poor workflow often decreases productivity due to increased communication and management overhead, a concept known as Brooks's Law.

C. Implementing a more rigorous change approval process to ensure quality.

This would add bureaucracy and delay, further slowing down the rate of change and worsening the problem from the clients' perspective.

D. Asking Thierry to create a comprehensive requirements document for all future changes.

This is a waterfall approach that creates large batches of work and delays feedback, preventing the team from responding quickly to evolving client needs.

1. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations. IT Revolution Press.

Chapter 5: Make Our Work Visible: "One of the most critical steps to enabling fast flow is to make all the work in the value stream visible... Kanban boards are a common way to visualize work." (p. 57).

Chapter 6: Limit Work in Process (WIP): "When we have too much WIP, there is rampant multitasking, which makes it difficult to complete any one thing... By limiting WIP, we can get a much better understanding of the flow of work." (p. 65). This directly addresses the "busy but struggling to deliver" symptom.

2. Lwakatare, L. E., Kuvaja, P., & Oivo, M. (2020). "Dimensions of DevOps." In Agile Processes in Software Engineering and Extreme Programming – Workshops (pp. 216-223). Springer, Cham.

This publication discusses Lean principles as a core dimension of DevOps, stating, "DevOps is also influenced by Lean principles, which focus on the elimination of waste and continuous improvement of the value stream... Practices such as value stream mapping, limiting work-in-progress (WIP), and small batches are used." (p. 218). This supports using WIP limits to improve value delivery.

DOI: https://doi.org/10.1007/978-3-030-49392-926

Kotter’s Dual Operating System supplements the hierarchical structure with a constantly-evolving network that follows five guiding principles. The first principle is that change is driven by “many change agents, coming from everywhere in the organisation, not just the usual few appointees.” Widespread voluntary participation gives the network the diversity, energy and speed needed to sense and respond to opportunities faster than a traditional hierarchy acting alone. This principle is therefore one of Kotter’s core rules for a Dual Operating System.

A. Change managed only by a central PMO contradicts Kotter’s call for broad, decentralised participation.

B. A “have-to” mindset is the opposite of Kotter’s “get-to/want-to” principle that fuels discretionary effort.

C. Creating two independent companies misrepresents the model; Kotter stresses “two systems, one organisation.”

1. Kotter, J. P. “Accelerate!” Harvard Business Review, Nov 2012, pp. 48-49 – lists “many change agents from everywhere” as Principle 1.

2. Kotter, J. P. Accelerate (XLR8). Harvard Business Review Press, 2014, Chapter 2, pp. 22-24 – five principles, first is “many volunteers drive change.”

3. DevOps Institute. DevOps Leader (DOL) v2.4 Courseware, Module 7 “Leading Change”, slide 14 – enumerates the same five principles.

4. MIT Sloan School of Management, 15.311 Organisational Processes, Lecture on “Networks & Change,” course notes p. 6 – cites Kotter’s five principles including “many change agents.”

5. Stanford University, MS&E 280: “Organizational Dynamics,” Spring 2019 reader, Kotter excerpt pp. 2-3 – reiterates principle of widespread volunteers in the Dual Operating System.

Teal organizations are defined by three core breakthroughs: self-management, wholeness, and evolutionary purpose. The most prominent of these is the shift from traditional hierarchical pyramids to decentralized, self-managing structures. In this model, teams and individuals have high autonomy and are trusted to make decisions without seeking approval from a chain of command. Authority and decision-making are distributed throughout the organization, relying on peer-based advice processes rather than formal managerial oversight. This structure enables greater agility, resilience, and employee engagement by replacing formal control mechanisms with trust and shared purpose.

Why Incorrect Options are Wrong:

A. This describes an Amber (Conformist) or Orange (Achievement) paradigm, which relies on rigid hierarchies and top-down authority, the opposite of a Teal organization's structure.

B. This is the primary driver of an Orange (Achievement) organization, where success is measured by profit, market share, and outperforming competitors, not by an evolutionary purpose.

C. This is characteristic of a Green (Pluralistic) organization, which values empowerment and stakeholder input but typically retains the underlying pyramid structure and management layers.

References:

1. Laloux, F. (2014). Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness. Nelson Parker. (This is the foundational text for the concept, widely cited in academic and university settings covering organizational theory). The three breakthroughs are introduced in Part 1.2, with "Self-Management" detailed in Chapter 2.2.

2. Hudescu, L. (2018). The Teal Paradigm of Organizations. International conference KNOWLEDGE-BASED ORGANIZATION, 24(2), 221-225. This paper explicitly states, "The hierarchical pyramid is replaced by a self-management system... Teal organizations are characterized by the absence of hierarchy, job descriptions, and objectives" (p. 223).

3. Kunneman, H. (2016). Good work in a Teal organization. Zin in werk, 10(1), 1-15. This academic analysis discusses the core principles, noting, "The first breakthrough of teal organizations is self-management. Teal organizations have found the key to operate effectively, even at a large scale, with a system based on peer relationships, without the need for either hierarchy or consensus" (p. 4).

A Strict top-down hierarchy contradicts Teal’s distributed authority model.

B Management-by-objectives with tight target control reflects an Orange mindset, not Teal.

C Centralised executive committees negate the self-management principle fundamental to Teal.

1. PeopleCert DevOps Leader (DOL) Official Syllabus v2.1, §2.4 “Organizational Models – Teal”, bullet 3, p. 19.

2. Laloux, F. (2014). Reinventing Organizations, Ch. 2, pp. 55-58 – outlines “self-management” as a core Teal pillar.

3. MIT Sloan School of Management course 15.342 “Organizations Lab”, Lecture 7 slides, 2020, slide 12 – Teal = “self-organising, no hierarchy”.

4. Bernstein, B., Bunch, J., & Canner, N. (2016). “Beyond the Holacracy Hype.” Harvard Business Review, July–Aug., p. 40 – discusses Teal/self-management traits.

Based on the principles of the PeopleCert DevOps Leader certification, here is the analysis of the question.

As the multiple-choice options were not provided, this answer assumes a standard set of options commonly associated with this topic in an exam context.

Assumed Options:

A. Identify waste in a process

B. Visualize the flow of work and information

C. Calculate process cycle efficiency

D. Define the organizational reporting structure

Correct Answer: D

A Value Stream Map (VSM) does not define the organizational reporting structure.

Explanation

A Value Stream Map is a fundamental Lean tool used to analyze and improve the flow of value to a customer. Its primary purpose is to visualize all the steps—both value-adding and non-value-adding—in a specific process, from request to delivery. This visualization helps teams identify sources of waste (muda), calculate key performance metrics like lead time and process cycle efficiency, and design a more streamlined future state. A VSM is process-centric, focusing on how work flows across teams and departments. It is distinct from an organizational chart, which is a human-resources tool designed specifically to depict formal hierarchical reporting lines and departmental structures.

Why Incorrect Options are Wrong

A. Identify waste in a process: This is a primary function of VSM. It visually exposes delays, rework, handoffs, and other forms of waste.

B. Visualize the flow of work and information: This is the core definition of a VSM; it maps the end-to-end flow of both the work item and the information required to process it.

C. Calculate process cycle efficiency: VSM captures the necessary data—Value-Added Time and Total Lead Time—to calculate this critical Lean metric.

References

1. Rother, M., & Shook, J. (2003). Learning to See: Value Stream Mapping to Add Value and Eliminate Muda. Lean Enterprise Institute.

Reference: Page 3 defines a value stream as "all the actions (both value added and non-value added) currently required to bring a product through the main flows essential to every product." The book's methodology focuses exclusively on mapping process steps, information flows, and timelines, not organizational hierarchies.

2. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations. IT Revolution Press.

Reference: Chapter 8, "The Second Way: Amplify Feedback Loops," describes value stream mapping as a critical tool to "make the flow of work visible" and to "see where work is flowing well and where it is queued or stalled." The focus is entirely on the process flow, not the reporting structure.

3. Martin, K., & Osterling, M. (2014). Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation. McGraw-Hill.

Reference: Chapter 1, "What is Value Stream Mapping?", explicitly states, "Value stream mapping is a method of visualizing the flow of a product or service from the time an order is placed... until the product or service is in the hands of the customer." It contrasts this with other tools, implicitly separating it from organizational charting.

4. MIT OpenCourseWare. (2005). 16.852J / ESD.62J Integrating the Lean Enterprise, Fall 2005. Massachusetts Institute of Technology.

Reference: Lecture 5 notes on "Value Stream Mapping" detail the symbols and metrics used, such as process boxes, inventory triangles, and data boxes for cycle time and lead time. The entire framework is designed to analyze process flow and efficiency, with no elements for representing managerial reporting lines.

A – Mapping explicitly visualises each material/information hand-off in the end-to-end flow.

B – A core purpose of VSM is to surface bottlenecks and the seven Lean wastes.

C – Lead time, process time, inventory counts, etc., are captured on every VSM as baseline metrics.

1. Singh, B., Sharma, S.K., and Sharma, R. “Value Stream Mapping: Literature Review and Implications for Research.” International Journal of Production Research 49(18), 2011, pp. 5531-5553. DOI:10.1080/00207543.2011.596351 – Sec. 3, para 2 (“VSM is a diagnostic tool… it cannot by itself remove waste”).

2. Krafcik, J.F., and Shook, J. “MIT Lean Aerospace Initiative – Lean Enterprise Model.” MIT OCW Course 16.852J (2009), Module 4, slide 27 (“VSM highlights waste; improvement comes from subsequent Kaizen”).

3. Rother, M., and Shook, J. Learning to See. Lean Enterprise Institute, 3rd ed., 2009, pp. 6-7 (“The map only makes problems visible; action is required to eliminate them”).

4. Humble, J., Kim, G., and Walls, J. DevOps Handbook. IT Revolution, 2016, Ch. 2, p. 35 (“Use VSM to see work flow and queue times; the map does not change the system”).

A Community of Practice (CoP) is the most suitable solution for Bernhard. CoPs are voluntary groups formed around a shared interest, enabling members from different teams (and even different chapters) to share knowledge, discuss challenges, and explore emerging topics like AI-based testing. This directly addresses his need for a broader community beyond his formal chapter structure. It fosters a culture of continuous learning and collaboration, which is central to DevOps, without re-introducing the rigid silos that cross-functional teams are designed to break down. A CoP provides the perfect informal network for sharing specialized expertise and best practices across the organization.

B. Proposing a Center of Excellence (CoE) is often a move towards centralization and control, which can conflict with the autonomy and culture of DevOps teams.

C. Reverting to a functional silo would be a regressive step, undoing the benefits of the cross-functional team model his organization has adopted.

D. Limiting interactions to his chapter is insufficient, as the scenario explicitly states he seeks a broader community to supplement his chapter meetups.

1. Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations. IT Revolution Press.

Section: Part V, Chapter 23, "How to Get Started on Your DevOps Journey".

Content: The book advocates for creating Communities of Practice as informal, voluntary groups where people can meet to discuss common interests and share knowledge. This mechanism is presented as a way to "reinforce the desired culture" and connect specialists across different teams, which directly aligns with solving Bernhard's problem.

2. Wenger, E., McDermott, R., & Snyder, W. M. (2002). Cultivating Communities of Practice: A Guide to Managing Knowledge. Harvard Business School Press.

Section: Chapter 1, "Introduction: A New Frontier".

Content: This foundational text defines CoPs as "groups of people who share a concern, a set of problems, or a passion about a topic, and who deepen their knowledge and expertise in this area by interacting on an ongoing basis." This definition perfectly describes the type of group Bernhard needs to connect with others interested in AI-based testing.

3. Kniberg, H., & Ivarsson, A. (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds.

Section: "Guilds".

Content: This widely referenced paper on the "Spotify Model" describes a Guild as a "community of interest" that is wider than a chapter, cutting across the entire organization. Anyone can join a guild, making it the ideal structure for someone like Bernhard who wants to connect with a broad group on a specific topic (e.g., a "testing guild" or an "AI automation guild").