Organisations today are built on software. This is invisible to most employees, leadership, and customers. Good architecture makes it visible; great architecture helps us understand it, enabling us to map out our future with clarity.

Successful companies operate three pages ahead, not three pages behind. Read on to learn how the six layers of great architecture grant 360 vision showing where you are and how to lead towards your company’s goals.

• Introduction
• The Six Levels of Great Architecture
• #1 Executive Layer of Architecture: A High-Level Strategic Overview
• #2 Enterprise Architecture: Mapping the Technology Landscape
• #3 Domain Architecture: Aligning Business and Technology
• #4 Application Architecture: Detailed Design and System Interactions
• #5 System Architecture: Zooming into Core Functionality
• #6 Component Architecture: Building Blocks for Engineering Success
• Further Reading: Exploring the 360-Degree Lens of Architecture and Other Models
• Conclusion

Introduction

In today’s complex organisations, architecture isn’t just about technology—it’s about providing a comprehensive, interconnected view of how technology and business align. The six-layer framework introduced here acts as a 360-degree architecture lens, enabling teams to zoom seamlessly between high-level strategy and detailed implementation.

This holistic 360-degree lens ensures that every stakeholder—from board executives to junior engineers—has the clarity they need to make informed decisions. By bridging these perspectives, the framework not only improves technical accuracy but also fosters stronger collaboration, alignment, and business outcomes.

This lens doesn’t just focus on individual aspects; it ensures every layer of the architecture connects with the others, creating a cohesive view that adapts as your organisation evolves. Each layer builds upon the previous, offering a unified vision that remains actionable at every level.

The Six Levels of Great Architecture

Shining a light through the 360-degree lens on technology underlying the business reveals clarity, context, and actionable insights. This perspective is not the sole responsibility of Architecture teams, though they are accountable for ensuring this clarity is visible and understood from the Executive layer to the newly joined contributor.

Underpinning these levels of great architectural clarity there must be ownership. Roughly, the stack ownership should be shared 50/50 with Engineering, with clarity of ownership at the top and bottom two layers, and a mixed ownership between.

A Note on Roadmaps

Roadmaps are what sit between a current and a future state diagram—and they can exist at any level. From the perspective of a 360-degree lens, these roadmaps serve as pathways that ensure strategic alignment between the present state of your architecture and your envisioned goals.

Roughly, roadmaps should come towards the end of the exercise.

1. Map the current state: Diagrams articulating the current state should come first and be accurate.
2. Converge on the vision: Investment of time to ensure the company vision & goals in the relevant area are understood.
3. Map out the future: High-level future state prepared & circulated with relevant stakeholders.
4. Forge a path: Begin roadmapping.

#1 Executive Layer of Architecture: A High-Level Strategic Overview

Owners: Head of Architecture, Principal Architects.

Purpose: To allow the Executive and Senior Management across the Organisation to understand what makes up of the Enterprise Estate, how it all connects and their domains. To facilitate conversations about specific initiatives and how they provide improvements to the business.

Analogy: The 3D model of a building or large site development.

Why Architecture Needs Design and Marketing

This Executive layer, when seen through the 360-degree lens, becomes a vital storytelling tool. By blending technical insight with modern design and marketing principles, architecture teams can craft visuals and narratives that resonate with leadership. The goal at this level is to help people who lack deep context to quickly understand the message. These people are busy and will move on quickly or dismiss a topic that fails to speak their language.

Many teams fail to show up at this level or if they do, haven’t adjusted their approach to meet the communication style and expectations of Executives and Senior Management.

Architecture teams must push themselves to break free of the visual and design standards prevalent within Technology and pull in advisors from Customer and User Experience teams. These documents must not only be correct, they must look good, be simple and consumable by top managers and the Executive.

At this level teams are competing for time with other departments like Marketing, Product, and Sales. As such, this level of Architecture must be written in a way that is easily consumed by the Executives and the Board. It must be consumable and quickly get the point across.

Simple is best. Omission of irrelevant portions is fine so long as the truth is preserved. Stay out of the detail unless necessary. Each diagram must be designed for the purpose and audience it is intended for.

Base Camp and the Mountain

Through the 360-degree lens, this level is where the current Enterprise position meets the company’s vision and mission. It describes both the base camp and the mountain, providing a clear picture of where we are, the outcomes required, and the path to get there.

Current state diagrams are an opportunity for Technology to show the Business where we are. The future state versions are an opportunity for Technology to help the Business understand why, on the way to the destination the Organisation may need to invest in more or different work than is intuitive.

This level is where the team describes the base camp and the mountain, proving both an understanding of where we are, the outcome required and the path to get there.

#2 Enterprise Architecture: Mapping the Technology Landscape

Owners: Head of Architecture, Principal Architects.

Purpose: To provide a clear and accurate technical view of the Enterprise Estate.

Analogy: The blueprint of a building, with references to deeper levels of detail.

The Reference and the Map

This level is often the highest in traditional architecture teams. There can be a tendency to merge this layer with the Executive level described above. This is a mistake: the two have very different purposes and should be treated as distinct levels of architecture.

While the Executive level is often used to provide a high-level overview of the Enterprise, the Enterprise level is where the team provides a clear and accurate technical view of the Enterprise Estate.

The Reference

The current-state diagrams at this layer must deliver an accurate, high-detail view of the organisation’s domains. These diagrams group domain-level blocks, providing essential context for understanding how key applications interact. They are crucial for identifying unnecessary complexity, duplication, and other opportunities for improvement.

Key benefits of this layer include:

• Identifying problem areas: Highlighting problematic vendors, outdated systems, and potential risks.
• Spotting inefficiencies: Exposing duplication of functionality and areas for system/team consolidation.
• Revealing gaps: Identifying missing components, such as the need for a unified billing or sales system.
• Validating alignment: Confirming whether the Technology Estate aligns with both explicit and implicit business domains.

By focusing on these aspects, this layer serves as a foundation for refining the broader architecture. These insights can inspire high-level representations used in Executive-level discussions to emphasise key issues and proposed solutions.

The Map

The future-state diagrams at this level serve as navigational tools. They chart the course for ongoing and upcoming change programs, clearly illustrating the improvements these programs aim to deliver. Through the 360-degree lens, these maps should highlight the transformation from the current to the desired future state, showcasing the alignment with strategic goals.

Key aspects of this mapping process include:

• Flexibility during early stages: Diagrams remain adaptable during discovery and design phases, ensuring accuracy as the future state becomes more defined.
• Actionable insights for stakeholders: Providing clear, digestible visualisations that enable discussions with key sponsors and stakeholders about how investments will yield measurable improvements.

This dynamic interplay between the Reference and the Map solidifies the Enterprise layer’s role as a critical bridge between the strategic and technical aspects of architecture.

#3 Domain Architecture: Aligning Business and Technology

Owners: Solution Architects, Principal Engineers.

Purpose: To ensure domain owner(s) have clarity on their accountabilities from a technology ownership and hand-off perspective. To facilitate better conversations about how the organisation is or is not enabling the right focus and alignment between the business (intended domains) and technology (actual domains).

Analogy: Floorplan or layout of a proposed multi-story building, broken up into ground and lower level commercial, mid-level apartments, and upper-level penthouse hotel suites.

Cooperative Governance and Alignment

All layers require collaboration, but this is the first where ownership is shared between Engineering and Architecture. Through the 360-degree lens, this layer represents the intersection of high-level architecture diagrams and detailed design.

Architecture assures alignment with the broader Enterprise and Executive views, while Engineering ensures coherence with Application and Component layers. This collaboration fosters clarity, accountability, and a unified approach to domain-level challenges.

No leader can lead without knowing who and what they lead or where they are to go: the domain level provides this for both current and future state. It must be built by and understood by both parties:

• Architecture assures it is aligned with the Enterprise and Executive views.
• Engineering assures it is aligned with the Application and Component views.

Domains and Conway

Conway’s Law is particularly relevant here: the structures that Engineering teams create often mirror the structures of the organisations they work within. Accurate domain maps empower leaders to scrutinise these structures, evaluating their validity and exploring pathways for improvement.

Domain-level diagrams provide a framework to address:

• Technical debt: Exposing inefficiencies and outdated structures that need modernisation.
• Organisational debt: Highlighting misalignments between technical and business domains.
• Transformation opportunities: Articulating the pathway to a more effective future state, underpinned by aligned domains and improved functionality.

This layer’s insights allow organisations to identify and mitigate risks, streamline operations, and establish a robust foundation for sustainable growth. Building competence here will support success in layers up and down the stack. Great collaboration between Architecture and Engineering teams provide evidence for correctness of designs at the Enterprise and Executive level.

This is where organisations can unlock the ability to “see around corners”, as the Architecture and Engineering teams combine their skillsets and vision.

#4 Application Architecture: Detailed Design and System Interactions

Owners: Solution Architects, Principal Engineers.

Purpose: To provide a detailed diagrammatic explanation of an individual application, showcasing key systems, their interactions, and their connections to upstream and downstream applications and domains.

Analogy: A detailed design of a single floor in a multi-story building, illustrating connections to other floors, potential bridges to neighbouring buildings, and room layouts as block-level representations.

LEGO Sets and Their Instructions

This layer of architecture should be treated like LEGO sets, particularly in large organisations. Here, the Application diagrams function as the instruction booklets. These diagrams should provide enough detail to enable the seamless assembly or modification of components and highlight any dependencies on external systems.

Using the LEGO modular buildings analogy, the goal for any target state modifications and roadmaps should be to ensure each application delivers essential functionality while remaining independent enough to avoid over-reliance on peer applications.

When tight dependencies exist, the level above: Domain-level diagrams should flag these as constraints, turning them into opportunities for improvement.

Cooperative Governance

The Application layer reinforces the critical partnership between Engineering and Architecture. Key responsibilities include:

• Architecture’s Role: Ensuring applications align with higher-level Enterprise and Domain views while delivering intended outcomes.
• Engineering’s Role: Guaranteeing that applications are built to specification and functioning as designed. Engineering teams should actively participate in redesigns and replacement planning to ensure long-term viability.

By fostering this collaborative governance model, organisations can optimise their application architecture to better meet both technical and business objectives.

As described in the Domain section, these two layers are an opportunity for Architecture and Engineering to integrate the organisation’s vision and lead together.

#5 System Architecture: Zooming into Core Functionality

Owners: Lead Engineers, Senior Engineers.

Purpose: To provide a zoomed-in view of a single system within an application, focusing on specific functions such as checking account names via third-party services or processing transactions.

Analogy: A detailed outline of a single room, showing desk arrangements, seating, adjoining facilities, entrances and exits, and the tools required to fulfill its purpose.

Zoom in, Enhance

If the Application layer represents a LEGO instruction booklet, the System layer is akin to a single page from that booklet. It offers focused, high-detail insights into specific system and are typically documented in a Detailed Design Document (DDD).

A typical documentation repository for an application may include:

• A high-level Application view.
• Links to relevant Domain-level diagrams.
• A collection of DDDs, each describing logically grouped functionalities.

This layer is instrumental in supporting squads as they design, build, and maintain functionality within existing applications.

As Built and Assured

At the System layer, the emphasis is on precision and assurance. It offers:

• Detailed Functionality Maps: Including API call structures, system dependencies, and integration points.
• Support Documentation: Covering troubleshooting guides, disaster recovery protocols, and operational procedures.
• Compliance Assurance: Particularly critical in regulated industries, where this layer demonstrates adherence to governance and regulatory requirements.

For stakeholders, the System layer ensures that teams are delivering what they’ve promised while maintaining alignment with broader enterprise goals. It also provides the foundation for rigorous review and approval processes, ensuring consistency, quality, and compliance across the estate.

By zooming into individual systems, this layer empowers engineers to build robust solutions while maintaining alignment with organisational objectives.

#6 Component Architecture: Building Blocks for Engineering Success

Owners: Lead Engineers, Senior Engineers.

Purpose: To provide clarity to the engineering team responsible for building each individual component of a system. The lowest level formal design should go down to the specific components and serve as the starting point to understand how something was built.

Analogy: A detailed view of a single item within a room, for example, a chair or a computer.

The Nuts and Bolts

This layer provides the essential detail required to ensure that engineers know what to build, and that the right components are being built. It is also used to verify and trace the “as-built” state, especially during audits.

The Component-level diagram is often part of a DDD and focuses on the individual pieces that make up a system, such as an API call handler, a button, or a form. This layer is pivotal when the system requires complex, reusable components that must function across various contexts.

Although uncommon, the Component-level view is distinct from the System level and holds significant value.

This layer is particularly useful for detailing complex functionality or reusable components that form the foundation of broader system behaviour. For simpler systems, it may not be necessary, but for organisations relying on modular and reusable components, the Component layer ensures everything is designed to specification and is easy to trace and maintain.

For DDDs that require integrating new components from an Enterprise component library, this documentation becomes crucial to ensure clarity and consistency.

Further Reading: Exploring the 360-Degree Lens of Architecture and Other Models

Integrated Architecture Framework (IAF)

The layers and approach described in this post can complement many existing models. Dive into how the 360-degree lens enhances the Integrated Architecture Framework (IAF) by reading: A 360-Degree Lens on IAF: Integrating the 6 Layers of Architecture.

TOGAF

To explore a comparison between the 360-Degree Model and the TOGAF framework, which is widely used for enterprise architecture, check out Choosing the Right Architecture Framework: A 360-Degree Approach vs. TOGAF. This article discusses at a high level the methods and approaches of TOGAF and how it contrasts with more flexible, lighter approaches like the 360-degree lens.

Conclusion

The six levels of architecture presented here form a comprehensive but light framework that bridges the gap between executive vision and technical implementation. Each layer serves a distinct purpose, whether providing executive clarity or enabling detailed component-level understanding. When viewed through a 360-degree lens, this layered approach ensures that architecture fulfils its core value: illuminating current states and charting the path forward.

By maintaining clear distinctions between these levels while ensuring they work in harmony, organisations can better align their technology landscape with strategic business objectives. This framework not only provides the necessary tools for effective communication across all levels of the organisation but also ensures that architectural decisions remain grounded in both business value and technical reality.

The success of modern organisations increasingly depends on their ability to navigate complex technical landscapes. Through these six layers of architectural knowledge and vision, businesses create a shared understanding that empowers better decision-making, fosters more effective communication, and drives successful outcomes.

• Introduction
• The 360-Degree Lens: A Holistic Approach
• IAF: A Specific Framework for Architecture Practice
• Bridging the Two: Where the 360-Degree Lens Complements IAF
• Conclusion

Introduction

There are many frameworks and methodologies that organisations can leverage to design and implement their Enterprise Architecture. In many cases it is not an either-or decision. Two approaches are the 360-Degree Lens of Architecture and the Integrated Architecture Framework (IAF). Whilst these frameworks might seem similar, they serve very different purposes and can complement each other in practice.

The 360-Degree Lens provides a broad, high-level perspective on Architecture that allows organisations to align Business strategy with technological outcomes. It ensures that all layers of the Architecture are seen through a unified, strategic view and gives a structured approach to ownership and zoom-levels.

The IAF, in contrast, is more focused and specific. It is designed to provide actionable, structured guidance on how to implement Architecture within key areas. It focuses on elements and practices within the Architecture discipline, such as Governance, Process Management, and Detailed Design as opposed to a holistic approach to vision and leadership in the Architecture and Engineering spaces.

The 360-Degree Lens: A Holistic Approach

The 360-Degree Lens is an overarching methodology that brings together Business and Technology at all levels of the Architecture. It offers a perspective broken into discrete layers of zoom and ownership that ensures the organisation’s Technology landscape remains aligned with its strategic goals and is understood by all. The Lens offers a comprehensive view that spans from high-level Executive strategy to detailed Component design, and it can be applied across a wide range of organisational contexts.

• Strategic and holistic: Focuses on ensuring that Architecture is aligned with Business outcomes and organisational goals.
• Flexible and adaptive: Can be applied across various organisational structures, regardless of industry.
• Big-picture oriented: Ensures that all Technology decisions are seen in relation to their impact on Business and strategic goals.

The 360-Degree Lens helps identify gaps, opportunities, and misalignments in the organisation’s Architecture. By looking at the Architecture from a broader perspective, it ensures that decisions made in one area align with the overall strategy and vision of the company.

IAF: A Specific Framework for Architecture Practice

In contrast, the Integrated Architecture Framework (IAF) is a more targeted and detailed approach. IAF provides specific guidelines and principles for designing, managing, and governing the architectural process at multiple levels within the organisation. It ensures that Architects have a structured framework to follow, with a clear focus on key components such as:

• Governance: Defining roles, responsibilities, and decision-making processes.
• Operational Design: Practical implementation and system integration.
• Risk Management: Ensuring that technological risks are managed effectively throughout the design and implementation phases.

The IAF is particularly valuable for organisations looking for a clear, systematic approach to Architecture, where each level of design is carefully aligned with the next, from high-level strategy to detailed system components.

Bridging the Two: Where the 360-Degree Lens Complements IAF

Whilst IAF provides a structured approach to Architecture, the 360-Degree Lens complements this by offering a broader strategic view that helps to keep the big picture in focus. Here’s how they work together:

Strategic Vision (360-Degree Lens) ↔ Tactical Execution (IAF)

The 360-Degree Lens ensures that Business goals drive architectural decisions at every level, whilst IAF provides the structure and processes to implement these decisions in a consistent, disciplined manner.

Holistic Perspective (360-Degree Lens) ↔ Specific Practices (IAF)

The Lens gives Architects a complete picture of how each piece of the Architecture fits into the broader context, whilst IAF provides specific frameworks for how to design, build, and govern those individual pieces.

Flexibility (360-Degree Lens) ↔ Rigour (IAF)

The 360-Degree Lens adds flexibility by allowing the organisation to continuously adapt to changing Business needs, whilst IAF ensures that the Architecture is implemented with rigorous standards and best practices.

Conclusion

The 360-Degree Lens and IAF are complementary approaches to Architecture. While the 360-Degree Lens ensures alignment with broader Business goals for teams at every level of the organisation and provides a strategic, holistic view, the IAF offers actionable frameworks and guidelines for implementation. Together, they help organisations achieve strategic alignment and operational excellence, creating a cohesive, adaptable Architecture that is well-governed and aligned with the larger organisational vision.

By applying the 360-Degree Lens to the IAF, organisations can ensure that every level of their Architecture is not only efficient and effective but also strategically relevant and adaptable to future needs.

• Introduction
• Comparison: 360-Degree Model vs. TOGAF
• #1 Flexibility vs. Structure
• #2 Ease of Application
• #3 Customisation
• #4 Resource Requirements
• Conclusion

Introduction

When embarking on the journey to map out the architecture of a medium or large enterprise and define target states, adopting a lighter, more flexible model can be a strategic advantage.

A rigid framework like TOGAF, whilst comprehensive, can be overwhelming and complex for organisations just starting to navigate their architectural journey.

A lighter model, such as the 360-degree approach, allows teams to gain quick clarity, maintain flexibility, and focus on high-level goals before diving into intricate details.

This agility fosters quicker decision-making, easier buy-in from diverse stakeholders, and provides a foundation that can evolve as the organisation matures.

By starting with a lighter model, enterprises can ensure alignment between Business and Technology while avoiding the paralysis of over-structuring in the early stages of transformation.

Comparison: 360-Degree Model vs. TOGAF

#1 Flexibility vs. Structure

360-Degree Model

• Offers a holistic, adaptable approach that connects Business, Technology, and other factors without being confined to rigid methodologies.
• Emphasises a broad view with flexibility in application, making it easier to tailor to different organisational contexts.
• Pros: Easier to implement in certain cases, particularly for those looking for a high-level overview and broad alignment without deep structure. It is lighter in terms of documentation and formal processes.

• Cons: Lack of clear, predefined steps might lead to confusion or inconsistency in some organisations.

  How Leaders Can Help: Leaders can provide clear vision and objectives as adoption progresses. Create a safe space for experimentation and widen the scope of adoption as maturity increases. Teams can navigate the flexibility of the approach without losing alignment with Business goals when focused on clear near-term outcomes (map this portion of the domain at level-x) towards a known vision (map the entire domain to the Executive level).

TOGAF

• Provides a highly structured methodology with predefined steps (e.g., Architecture Development Method (ADM)), tools, and templates.
• Requires more rigour in application, focusing on detailed processes and documentation.
• Pros: Well-documented and comprehensive, making it ideal for organisations that need detailed guidance and want to ensure a systematic approach to architecture.
• Cons: Can be cumbersome and slow to adopt, especially for organisations that don’t need all the details in ADM. It may also be resource-intensive.

#2 Ease of Application

360-Degree Model

• More adaptable and less prescriptive, making it easier to apply.
• Focuses on aligning Business objectives with Technology capabilities without rigid processes.
• Pros: Agile, allows quick iterations and alignment, making it easier for organisations to adopt.

• Cons: Its flexibility can sometimes result in a lack of direction or alignment if not carefully managed, particularly for those new to Architecture. Requires firm and committed leadership.

  How Leaders Can Help: Offering ongoing support and establishing governance without stifling flexibility can help maintain focus and consistency as the team adopts the 360-degree model more widely.

  Governance should go where the problems are. Trust is built as teams provide appropriate outcomes, this trust should lead to a reduction in direct governance. Review periodically to ensure the right level of rigour exists. Where it falls away, governance must become more instructive.

TOGAF

• Requires more time and expertise to apply due to its structured, step-by-step approach.
• Pros: Its systematic approach provides a solid foundation and clarity, making it ideal for organisations that are comfortable with structured processes.
• Cons: Steeper learning curve and can be resource-intensive. Full implementation requires dedicated personnel and time investment.

#3 Customisation

360-Degree Model:

• Can be adapted quickly based on organisational needs.
• Emphasis on collaboration and strategic alignment, rather than fixed sequences or templates.
• Pros: Highly customisable with flexibility to fit the organisation’s specific context.

• Cons: Customisation can sometimes be too broad, potentially leading to a lack of standardisation across multiple teams or areas.

  How Leaders Can Help: Providing a set of guiding principles for customisation, whilst avoiding micromanagement, can strike the right balance. Developing a strong Architecture and Engineering craft with relevant guardrails, automated where possible will help ensure consistency without bloating teams. Apply governance as noted above.

TOGAF:

• Customisation is possible, but within the core principles and processes defined by the methodology.
• Pros: Ensures consistency and standardisation across the organisation, which is especially important in larger, complex environments.
• Cons: Still requires adherence to its overall structure and flow, making it less flexible compared to other models.

#4 Resource Requirements

360-Degree Model

• Typically requires fewer resources to get started due to its broad approach.
• Pros: Less time-consuming and resource-heavy, with a focus on quick alignment and strategic visibility.

• Cons: Limited resources might hinder deeper analysis or refinement in certain areas, especially as the organisation matures.

  How Leaders Can Help: Leaders can guide the teams to prioritise key areas and deploy resources strategically as the organisation evolves. A phased approach allows for gradual refinement without overwhelming the teams early on. As noted above, leaders must give clear instruction regarding areas to focus on as the team progresses towards a more complex and difficult vision.

TOGAF

• Requires more resources, particularly in terms of training, specialised roles, and time investment.
• Pros: Comprehensive training and expertise can ensure that the architecture is well-executed and integrated across all areas.
• Cons: Time and resource-intensive, especially for the early stages of adoption.

Conclusion

While both the 360-Degree Model and TOGAF offer valuable frameworks for enterprise architecture, the key takeaway is that taking action—regardless of the model you choose—is far more impactful than remaining stagnant.

For many organisations, especially those at the beginning of their journey to map out current and future states & align Technology with Business goals, a lighter, more flexible model can be more effective more quickly than a rigid, complicated and resource-intensive approach.

The 360-Degree Model’s adaptability allows for quicker iterations and more immediate alignment with strategic objectives, making it an ideal starting point.

If you’re looking to build momentum and create real, actionable outcomes, the most important thing is to start moving.

The decision to adopt a flexible model today can set the foundation for more structured approaches down the road, ensuring your Enterprise remains agile and responsive to ever-changing needs.

For more insights on how to begin this journey and choose the right model, check out The Six Levels of Great Architecture: A 360-Degree Lens.

• Introduction
• The Traits of Resilient Leaders
• Building Resilience Through External Behaviours
  • Reframe and Reinforce the Outcome
  • Prioritisation and Progress Monitoring
  • Leading with Focus and Positivity
  • Fostering Collaboration
• Internal Practices for Staying Positive and Focused
  • Looking Ahead: The Power of a Clear Outcome
  • Looking Back: Learning from Progress
• Conclusion: Why Resilient Leaders Thrive

Introduction

Resilience is a cornerstone of successful leadership. Strong leaders articulate a compelling vision, inspire stakeholders, and guide teams to deliver results. Yet, achieving ambitious goals often demands navigating significant change, which can be difficult for organisations.

Helping an organisation adapt requires clear strategies and resilience. Challenges may arise at both individual and group levels, making progress feel slow or discouraging.

Resilience enables leaders to persist despite setbacks. It is a skill set combining internal and external behaviours, which can be developed and refined to propel success.

The Traits of Resilient Leaders

Resilient leaders are often successful because they consistently apply behaviours that promote perseverance and adaptability. When faced with challenges or new roles, these leaders rely on structured approaches to overcome obstacles and build confidence in their teams.

Below are practical frameworks for developing resilience. The first focuses on external strategies for guiding teams, while the second highlights internal practices to sustain positivity and focus.

Building Resilience Through External Behaviours

Reframe and Reinforce the Outcome

Leaders must frequently communicate and reiterate the vision. A clear and consistent message ensures team members understand the ultimate goal and the steps to achieve it.

1. Break down long-term goals into achievable short-term milestones.
2. Reaffirm these objectives regularly, ensuring alignment across the team.
3. Use language that inspires confidence and clarity:
   “Today, we’ll focus on achieving this milestone, which is crucial to our broader vision.”

Prioritisation and Progress Monitoring

Establish a regular cadence for team check-ins, especially during formative phases or high-pressure periods. This ensures alignment and fosters accountability.

• Begin and end the week with team meetings.
  • Check-In at the start of the week: Identify priorities, discuss roadblocks, and align on short-term objectives.
  • Check-Out: Review progress, celebrate wins, and plan for the next week.

Leading with Focus and Positivity

Lead by example through clear communication, positivity, and unwavering focus on outcomes.

• Address off-topic discussions tactfully, keeping the team on track.
• Acknowledge both individual and team achievements.
• Escalate issues promptly and transparently when additional support is needed.

Fostering Collaboration

Encourage collaborative problem-solving while recognising that solutions may require time. When decisions stall, facilitate structured analysis, such as developing an options paper to weigh pros and cons.

Internal Practices for Staying Positive and Focused

Looking Ahead: The Power of a Clear Outcome

Take time daily to focus on your goals:

1. Write down both long-term visions and immediate objectives.
2. Celebrate milestones by building a “success timeline.”
3. Use this clarity to guide your team and stakeholders effectively.

Looking Back: Learning from Progress

Reflect weekly on achievements to maintain perspective:

• Review recent accomplishments and challenges.
• Identify lessons learned to refine future strategies.
• Use evidence of progress to reinforce confidence and motivation.

This habit counteracts the illusion of stagnation, especially in complex organisations, and provides a foundation for positive communication with your team.

Conclusion: Why Resilient Leaders Thrive

Resilient leaders inspire trust and achieve results by consistently applying learned behaviours. Through structured internal and external practices, they remain focused on their vision, adapt to challenges, and build successful teams.

Mastering these traits enables you to lead confidently, motivate others, and deliver the outcomes your organisation needs.

• Introduction
• Overview
• Split Focus
• Professional First
• Personal Impact Review
• Decide

Introduction

There are times when one must make a decision that will cause ripples, sometimes waves. This can be uncomfortable, as these waves may extend beyond the professional realm and affect one’s personal relationships or situation. These decisions become multi-dimensional. It is difficult to consider both dimensions at once, which can result in decision gridlock and a sense of being overwhelmed.

Even the perceived threat of personal retaliation, burned bridges, or strained relationships can be anxiety-inducing. The key outcome of the process described here is a framework that helps highlight what action is obvious and provides a clear list of impacts that can then be addressed by you and your support group.

Some examples of decisions a leader may face in their professional or personal lives include:

• Deciding how to present a fact base and options to an audience with influence over you and your peers who possess divided and strong opinions on a desired outcome.
• Considering internal or external career decisions.
• Choosing to report unethical behaviour at work, risking strain in personal relationships with involved colleagues.
• Opting to pursue a high-stress promotion while considering the impact on your mental health and home life.

There is a simple framework one may use to help in this situation.

Overview

1. Split Focus: Understand the different dimensions of the decision.
2. Professional First: Prioritise professional impacts before personal ones.
3. Personal Impact Review: Analyse personal consequences separately.
4. Decide: Make an informed choice based on the insights gained.

Split Focus

The two dimensions present in these situations can cause one’s decision-making process to “bounce” between both, resulting in difficulty arriving at a set of impacts, let alone reaching a place where one can articulate why a decision should go one way or another.

It is helpful to split one’s focus to be first professional, then personal.

Professional First

This focus must be strictly on those elements of your decision that impact you professionally. It is forbidden to write anything or consider any element that isn’t strictly relevant to this side of the decision.

Write your decision down. Below this, create a table with two columns: one each for the pros and cons of doing this action. I use a spreadsheet, but any form will do.

Note: It can be normal for there to be very few items to write in either column at this point as it may turn out the best action is obvious, the difficulty often exists in the perceived personal impacts.

Personal Impact Review

Below this table or in another tab, replicate the table for personal impacts. Here, it is forbidden to write anything or consider any element that isn’t personal.

This is where, in the “con” column, one may now write about bridges that may be burned and other personal discomforts that may arise from this action.

Decide

Frequently, the best action becomes obvious upon completing the professional portion of the exercise. Viewing the possible outcomes with this strict lens can be liberating.

Considering personal pros and cons separately helps to articulate to oneself where anxiety originates and why one may feel conflicted. It provides a list of such items to work through, even if this means simply acknowledging them and moving on.

• Introduction
• A Leader’s Role in Decision Making
• Balancing Desires to Progress with Sticking to Strategy
• Speak About the Problem

Introduction

Chesterton’s Fence is a principle that changes shouldn’t be made until the context and reasons that caused whatever is to be changed to exist are understood, and therefore any second or third order consequences have been taken into account and planned for.

When faced with a problem to solve, it is natural for people to leap to the conclusion we should immediately embark on some change activity. Doing so without considering Chesterton’s Fence can lead to regretful outcomes. Leading teams through these decisions is made simpler with a few key actions.

Help your teams seek understanding first, before demolishing something that may have real value.

A Leader’s Role in Decision Making

As leaders, we must become very good at incorporating a large amount of context from across the organisation. This is context your teams will lack, due to their roles keeping them closer to discrete problems being solved.

It is therefore a leader’s responsibility to ensure teams are coached to decisions that align with organisational goals. To do this one must strike the balance of ensuring people have enough awareness of the interrelations between various groups across the organisation, competing priorities and the strategic direction without being overwhelmed and unable to operate.

Using context and thoughtful concepts like Chesterton’s Fence, a leader can help teams step back and consider the impacts of different directions in a structured manner.

Balancing Desires to Progress with Sticking to Strategy

It is common for influential and high-performing team members to prioritise immediate action towards a goal - this is both healthy and necessary if the organisation is to succeed. These tendencies must be balanced to ensure all move in the same general direction - and to avoid tearing down perfectly reasonable and important “fences” as individual groups progress.

There are two key actions you can take as a leader to help teams avoid ignoring context and history while they forge a path successfully.

1. Make sure your team understands where they’re going - teams without a clear strategy cannot be expected to think of solutions that align with their peers and other business units. An excellent way to do this very quickly is by using the Now, Next, Later Framework.

2. Clarify the change and the options around it by writing an options paper. This is an excellent and quick way for people to articulate first what they want to change, then work towards understanding the second and higher-order implications of the change. Progressing within this structure results in an artefact you can use to frame questions, ensure strategic implications are covered and socialise it with your peers before deciding on the change itself.

Speak About the Problem

In addition to dealing with this in discrete interactions, help your wider team understand this and other biases by talking about them in your all-hands meetings, one-to-ones and other sessions, make time to talk about these pitfalls in thinking. Talk about your strategy, how your peer business units show up and what they need. Acknowledge the humanity we share and that it’s up to us all to hold each other to account.

Use analogies and examples aligned to your team’s skill sets. For example, if explaining the impacts of Chesterton’s Fence to a team of Software Engineers, I would use the typical reaction of an engineer to a new or older codebase, which is invariably “the only option we have is to rewrite it from scratch”. This is a natural reaction but almost never a good idea. Challenge yourself to find examples in your team’s area of expertise and challenge them to understand why stepping back to consider context & higher-order consequences is so important.

There are many psychological biases or pitfalls we can fall victim to. Understanding them and frameworks to avoid being trapped is a critical skill for leaders to develop.

• Introduction
  • Some Statistics on the Explosion of Complexity
  • Why Should You Care About This Complexity?
    • Completely In-House Benefits and Risks
    • Mixed In-House and Open Source Benefits and Risks
• Governance of Licensing and Security Exposure
  • SBOMs as an Automated Supply Chain-Governance Framework
    • Assurance of Content
    • Insight During Emergencies
    • Automated Policy Enforcement
• Summary

Introduction

Software complexity has increased exponentially over the past 20 years. Long gone are the days when teams wrote the entire codebase themselves. Nowadays, engineering in your company is more similar to plumbing:

1. Product decides what, and Engineering decides how to build it.
2. Engineers go to the store and choose which components to use.
3. Engineers plumb components together, writing comparatively small amounts of differentiating functionality on top of the glued-together parts.
4. Repeat as market demand and company goals change.

For almost all industries, this process is correct and unavoidable if an organisation wishes to remain competitive. Software is too complex, and the demand for speed to market is too great for any company to survive the extended time it would take to “hand craft” every building block, glue tube, and button required.

It is only in the most critical applications that teams must still write or closely review every line of code, such as in some areas of health, aviation, and, one hopes, all military software.

Before diving into why SBOMs truly matter and how teams can leverage them, it is important to cover some high-level points outlining how the technology industry got into this situation.

Some Statistics on the Explosion of Complexity

Open source has become a cornerstone of modern development. The Linux Foundation estimates over 70% of any given piece of software is made up of Free and Open Source components, while the 2024 Open Source Security and Risk Analysis Report suggests this percentage may represent upwards of 500 individual open source components per application. Finally, the Sonatype 9th Annual State of the Software Supply Chain reveals the average version updates released per project (across the average of 500 components in your application!) is roughly 15 per year.

Consider the implications: for each application in your business, there are on average 7,500 changes being made to the underlying pieces your team has chosen to use per year. This is a wildly different and more complicated supply chain than previous development methodologies used. As we learned in WWII, long and complex supply chains are fragile and vulnerable to attack.

Multiply these numbers by your major applications and consider if you are confident in your team’s ability to manage this complexity, detect and respond to threats, or even just stay on top of updates without some form of assistance and structure.

Why Should You Care About This Complexity?

You, the business person, demand speed, quality, and safety in all your company produces. This drives the adoption of tools and processes. Technology teams, therefore, rightly focus time on only work that differentiates your product from competitors.

Fundamentally, the trade-off made with this decision is between speed to market and control. The more open source or third-party code we use, the faster we get to market but the less we control our codebase. Statistics quoted above make it clear which option most companies have chosen.

Unchecked, this abrogation of control and understanding can have profoundly negative consequences if the risks are not managed. This element of product development is so fundamentally important to security that it has been legislated in multiple jurisdictions. Most notably in the United States with the Executive Order on Improving the Nation’s Cybersecurity, in the EU with the NIS 2 Directive, and the Cyber Resilience Act.

Completely In-House Benefits and Risks

Mixed In-House and Open Source Benefits and Risks

Clearly, we prefer faster time to market over all else. This has exposed us to undue and unacceptable risk, which can be mitigated via proper use of SBOMs.

Governance of Licensing and Security Exposure

In the completely in-house model, there are only a few items to govern: the codebase itself, the language it’s written in, and any associated tooling. Humans are pretty good at understanding small handfuls of things, so governance is easy.

With mixed in-house and open source, the numbers involved leave humans in the dust. This is where SBOMs come in.

SBOMs have been around since 2010, but legislative changes combined with a greater industry focus on security have seen momentum towards adoption build.

There are currently two main SBOM types: SBDX, a public standard initially focused on licensing, and CycloneDX, which was initially focused on cybersecurity elements but can also be used to track licensing.

Don’t get too caught up in this element: your team likely uses tools that offer SBOM creation and management, so it’s better to leverage what is present than introducing “the best” tool.

The key point here is that SBOMs track this complexity in applications, providing one file outlining the contents, licences, and potential cybersecurity risks of an application. This feature of the SBOM model makes it perfect for automated governance and alerting of complex mixed in-house and open source creations.

SBOMs as an Automated Supply Chain-Governance Framework

Governance conjures images of people devoted to asking for data, creating reports, and chasing down non-compliance. Things don’t need to be this way. Organisations should hate manual governance. Done properly, SBOM setups provide assurance of content, insight during emergencies, and automated policy enforcement, all automatically.

Assurance of Content

Engineers on modern teams are used to automation having opinions about their job, so adding SBOM creation and scanning won’t be surprising. If there is existing build automation, adding SBOMs isn’t too difficult.

The overall process from changes to release can be understood as below. Note the only new checks going in here are 3.1 to 3.3. Engineers should already have multiple robots combing through their code checking for style, correctness, and legibility.

1. When Engineers finish their work and check it in, automation creates a file with licenses and versions of open source components, alongside the normal build process.
2. This gets sent to a central location.
3. Scanners pick up the file and check it for:
   1. Licence violations, e.g. licences your legal team have vetoed or projects with no licence.
   2. Cybersecurity vulnerabilities, based on criteria your cybersecurity team have set.
   3. Known threats and malicious actors, again based on your cybersecurity team’s settings.
4. If the scanners show green, the build can go to production.
5. If not, the team is alerted and get to work fixing the issues.

These three scans are sufficient for an organisation’s first foray into automated supply chain governance.

Insight During Emergencies

The central location SBOMs are stored within is invaluable during cybersecurity incidents as the organisation now has one place to look for whatever open source component needs to be urgently remediated. I have led teams through urgent vulnerability investigation and remediation activities. Without SBOMs, this is a hair-raising and time-consuming activity. With SBOMs, at least the hairs raise only for a short time due to the easier time teams have to locate problems that need fixing.

Adopting SBOMs saves time during cybersecurity incidents. Saved time saves money and reduces risk exposure.

Automated Policy Enforcement

It is uncommon for engineers to understand the implications of open source licences. Licences are often ignored when selecting which component to use in favour of documentation quality, marketing, or familiarity.

This means it is likely your organisation has not only tens of thousands of open source components but many tens or hundreds of licence agreements that have been injected and tacitly agreed with by employees with no legal knowledge.

Adopting SBOMs allows Legal to be engaged up-front, confirm acceptable licences, and automate enforcement. Nothing but hard work and a solid exemption process will get past the historic load, but without implementing governance going forward, the problem silently worsens.

Summary

All companies today rely on software to function, and many companies have large teams working hard to build software themselves. Most projects contain a large amount of code downloaded for free from third parties, which has largely gone ungoverned and represents material risk to the business.

This risk can be mitigated by implementing SBOMs appropriately. This requires collaboration between Cyber, Legal, the Business, and Technology but should mitigate the risk or alert on violations automatically going forward.

Go talk to your friendly Technology teams today about SBOMs and how they can help us create safer and more resilient software for customers.

• Introduction
• Why We Do This: Our Happy Place
• A Strategy to Improve
  • Read
  • Think
  • Write
  • Review
  • Repeat, Send
• Principle of Simplicity

Introduction

The wider an area one is responsible for, the more one will be called on to provide updates, answer questions, and generally represent varied work. These questions come from peers and the layers above.

Those of us who were previously engineers are often not good at responding to these questions. Depending on the circumstances and who is asking, it is common for explanations to devolve into discussions of minute details, burying the answer in a sea of irrelevant or confusing technicalities, often missing the point entirely.

Failing to adequately and concisely respond to a query doesn’t feel good. It can cause the requester to be frustrated, waste time with clarifying questions, and reduce the chances they’ll come to you with these questions next time.

This is not good for career advancement and does not help the organisation win.

Why We Do This: Our Happy Place

Diving deep into a subject and exploring every angle was the secret to success when dealing with technical problems. It is often the “happy place” we return to when uncertain, stressed, or under time pressure.

A helpful model to consider why we fall back on this is the Dreyfus model of skill acquisition. Diving deep is intuitive or absorbing, while communicating at the level required to succeed as a manager is difficult and requires conscious focus.

A Strategy to Improve

Identifying maladaptive behaviours is the first and most difficult step to becoming better - if you’ve just reached this milestone: congratulations! The rest is fairly easy though time-consuming.

I’ve approached retraining myself to respond more usefully in situations where I’m liable to fall back into my deep-dive happy place by creating a structured approach I can force myself to follow. Eventually, it’ll become second nature.

Improving your communication is as simple as looping through these actions: Read, Think, Write, Review, Repeat, Send.

Read

Carefully and with focus, read the request. Don’t press reply or start thinking about your response immediately.

Think

Depending on the combination of seniority, surrounding context, and potential outcomes of the answer, you’ll want to spend anywhere from a few minutes to much longer on this step. Knee-jerk responses to high-level management entail a level of risk that is seldom worth taking.

Think about the request from the perspective of the one asking, and try to understand what’s going on around the question.

• What context do they have or lack that might be relevant?
• Is there anything between the words you might have missed?
• What are the drivers behind this question?
• Why are they asking about this now?

The less context someone has, the more possible answers might exist for their questions. Ambiguity like this is tough. Try to reduce this uncertainty by consider the situation with the questions above.

When considering how to respond, also consider whether something has happened recently (e.g. an outage, a particularly fiery review meeting, something good) that may have triggered this question? How might this influence the response they expect?

Write

Draft a response. Fewer words is better.

Review

Read the question again. Read your response:

• Have you answered the question?
• Have you included anything extraneous?
• Have you included context where relevant?

Nobody likes to read 10 pages where a paragraph will do. Make sure you’ve been parsimonious with your words but don’t be a Spartan. Just as nobody likes reading an essay, they also don’t like to ask 10 clarifying questions. There is a balance, try to find it.

Repeat, Send

If you’re not 80-90% confident you’ve answered it well, start the process again. If you are, or you’ve run out of time, send off your response.

Lean on senior colleagues or your manager for advice. It’s our job to help each other out in these situations and people will understand the struggle to learn this skill. Honesty and a humble demeanour seldom goes badly.

As you respond in this way, keep an ear out for any reactions or responses. These can come directly as replies, from requests you make for feedback or hearsay. Use this information to inform changes in your approach.

Realise even the most well-formed reply may result in follow-up questions - these aren’t inherently bad. What we want to avoid are follow-up questions that could have been avoided by a more appropriate message. The goal is to help your audience understand what they were missing in the shortest possible time. Alignment is key to success in a large organisation. Everything you say or write either helps align teams or confuses them.

Principle of Simplicity

Communication is hard and large organisations are complicated. Keep your communication simple, to the point, and unambiguous.

Craft your reply to suit the audience and be ready to field follow-ups. Each interaction is an opportunity to help push the organisation forward, keep this in mind and put the appropriate amount of thought into your words.

• Introduction
• What does Resource abstract?
• Why is it an important term in corporates?
• Managers: when to and when not to use it
• Contributors: what does it mean to be referred to this way?
• Final point on abstractions in corporates

Introduction

Beyond the basics, all language is an abstraction, allowing us to discuss complex topics efficiently and clearly. We amass knowledge beneath ever-higher pyramids of abstraction, enabling us to discuss increasingly complicated subjects efficiently.

For example, take the word “Oxygen.” It abstracts elements of chemistry, physics, and the natural world, labeling the molecule in a way that allows us to discuss topics involving oxygen without needing to describe it every time. Imagine trying to explain what breathing accomplishes without an abstract term for this critical component of the respiratory process!

It’s common for contributors to feel offended when referred to as resources, and this is fair enough. Without understanding the purpose of the word, it can seem dehumanising. This feeling likely stems from a lack of understanding of the term and what it represents.

What does Resource abstract?

It is more than an alternative to “people” or “person.” The word is used to refer to any or all of the following:

1. Full-time employees
2. Contractors
3. Outsourced contributors
4. Physical goods (e.g., servers, laptops)
5. Virtual goods (e.g., software licensing)

In common use, the word is employed when discussing whether a plan has what it needs to succeed. Work may be sufficiently or insufficiently “resourced,” meaning it is lacking in one or more of these items necessary for success.

Why is it an important term in corporates?

This level of abstraction allows communication to remain concise and focused, which is important as information ascends the hierarchy. An interested or concerned executive can inquire about which resources specifically or whether there is a plan to address a lack of resources, without needing to know specifics.

Managers: when to and when not to use it

This will depend on your workplace culture. Keep in mind the connotations that can come with this word for audiences that may not understand its meaning or appreciate its use. It is never good to alienate your workforce or make them feel dehumanised.

Always tailor your communication to your audience. Writing a report for your superiors? Be concise and factual. Answering questions in a company or departmental ask-me-anything session? Humanise your language and simplify it so everyone understands your meaning, not just your words.

Contributors: what does it mean to be referred to this way?

Essentially, nothing. Don’t read too much into it. Someone either didn’t read this article or failed to target their language appropriately.

Remember, we have entire departments with this label: Human Resources. Our time is bought and paid for by the company, and we exchange it for outcomes. Many elements need to work together to provide those outcomes, and we call these resources.

Final point on abstractions in corporates

Everything is numbers. Hema Patel once taught me that if one cannot summarise a problem in numbers, one doesn’t understand the problem.

This means you, me, and the seats we sit on all live in a spreadsheet somewhere and are summed, divided, costed, and accounted for. The word “resource” is simply a linguistic reflection of this fact.

It is vitally important as a manager to be able to jump between different levels of abstraction as appropriate, from high-level financial summaries where individuals are reduced to numbers and costs, down to the level of the individual themselves. It can pay to periodically explain the differences and necessity of each level of abstraction to your teams. This is part of implementing leadership: all benefit from understanding more about each other’s roles as we work together to succeed.

The Now, Next, Later Framework

A leader must develop and show a vision to the organisation. This vision needs to be aligned to the organisation’s overall strategy. The team needs to feel they are achieving material progress towards strategic goals quarter by quarter. The now, next, later framework helps formulate these in a structured manner and can help create a roadmap for success.

When leading larger teams the now, next, later framework is very useful as a crowdsourcing tool to develop a picture of what your organisation’s individual groups may be prioritising. It works from one team up to whole organisations.

The Now, Next, Later data aggregation, planning and display framework is great in these situations, especially when a quick roadmap or visualisation is required. Created by Janna Bastow, it is flexible, quick to teach and easy to keep up to date. Janna suggests using it instead of traditional roadmaps and if you work for a company that allows this, great. If not it is still useful as a discovery and display tool as you to understand the high level plans for an area to adapt into whatever format may be mandated.

Fundamentally the now, next, later roadmap consists of three columns showing work across three time horizons.

1. Now: things being worked on now
2. Next: things in plan/ready to work on next
3. Later: things that might be a good idea to do in the future

It’s that simple. Any ticket-based management software (MS Whiteboard, ProdPad, MIRO) can accommodate it, failing that use excel or a physical board and post-its. Janna goes into great detail in her post Why Janna Invented the Now-Next-Later Roadmap.

Using the Framework

The combination of freedom within constraints make this tool excellent in group sessions and will build out to a solid base for your next step, whether that’s refining what’s next or digging into multiple streams to produce a formal, standard roadmap.