Inherited Management Complexity

How many times have you found yourself entangled in a web of technical complexities that seemed far greater than the sum of their parts?

You’re not alone.

Today, I found myself waiting for an AWS CodePipeline to retry while simultaneously watching QuickBooks Desktop Enterprise try to update itself (a software many businesses still rely on, surprisingly). As I sat on a call with two other architects, it became clear that what appeared to be a simple task was, in reality, a labyrinth of inherited management complexity.

The Invisible Layers

On the surface, updating a .NET program on a server sounds straightforward. But in a live production environment, it ain’t. Consider the following:

• OneXFinance, a fully built .NET application, brokers the connection to QuickBooks.
• It communicates with oneXerp via a series of SQS queues acting as intermediaries.
• On the oneXerp side, we have AWS Lambdas; on the oneXFinance side, .NET assemblies.
• Both oneXerp and oneXFinance reside within the same VPC, sharing resources — including the CodePipeline we’re troubleshooting.

OneXFinance runs on a server because it must interface with QuickBooks, which is also hosted on that same server (for more on hosting QuickBooks Desktop in AWS, see this article). This setup involves a managed directory, an EC2 instance, workspaces, and various network configurations. All these components must be traversed by the pipeline to successfully deploy the updated oneXFinance code into production.

This is inherited management complexity in action. A task that could have taken a few clicks in isolation now resides within an intricate automated process requiring active management.

Dealing with the Complexity

Ok, I’ve got inherited management complexity — what am I supposed to do about it?

As with most things, there is no single solution, no global solution, no everlasting solution; managing such complexity is inherently challenging.

There are traps you can avoid though!

Trap 1: Too Much Measurement

Trying too hard to quantify complexity can be a pitfall. Complexity is inherently difficult to measure and often frays at the edges. Over-analysis can lead quickly to paralysis, preventing timely decision-making and introducing further complexity. A truly hellacious cycle.

Trap 2: Too Little Measurement

On the flip side, pretending complexity won’t impact your project is equally dangerous. I’ve encountered this issue way more often than the aforementioned. Lots of “oh I’m sure this’ll sort itself out”-type logic. Scary stuff. This approach might seem to work sometimes in fast-moving domains where technology evolves rapidly enough to outpace accrued technical debt, but I mean…you’re putting it all on red.

Ignoring complexity leads to micro-processes that are automated and then abandoned. I’ve seen so many half-filled Smartsheets, forgotten Monday.com boards, Asana projects left in limbo, orphaned database records.

I’m sure they were well-intentioned initiatives. But they also couldn’t be sustained — victims of inherited management complexity.

Strategies for Managing Complexity

Here’s how I (generally) think about — and try to prepare for — inherited management complexity:

1. Assess the Scale of Your Process

First (roughly) quantify the scale of your process using some complexity factors:

• Number of Users (U): Total number of external users (E) and internal users (I).
• Number of Systems Involved (S): Total systems or platforms that need integration.
• Available Administrators (A): Number of administrators or support personnel available.
• Technology Complexity (Tc): Rate from 1 (simple) to 5 (very complex).
• Process Complexity (Pc): Rate from 1 (straightforward) to 5 (highly complex).
• Requirement Specificity (R): Rate from 1 (vague) to 5 (explicit and detailed).
• Regulatory/Legal Requirements (L): Number of regulatory bodies or legal constraints involved.

Note: Adding 1 to A prevents division by zero when no administrators are available.

Interpreting the Complexity Score:

• Low Complexity (CS ≤ 20): Manageable with minimal oversight.
• Moderate Complexity (21 ≤ CS ≤ 50): Requires careful planning and resource allocation.
• High Complexity (CS > 50): Demands robust management strategies and possibly additional resources.

2. Calculate the Critical Mass for Adoption

Critical mass adoption is the minimum level of engagement needed for your process to be effective and self-sustaining. It’s influenced by factors from Step 1.

• We: Weight assigned to external users (e.g., importance or influence, from 0 to 1).
• Wi: Weight assigned to internal users (from 0 to 1).

Weights should sum up to 1 for a balanced equation.

Example Calculation

External users needed for adoption: E=50
Internal users needed for adoption: I=20
Total users: U=70
Weight for external users: We=0.6
Weight for internal users: Wi=0.4        

Interpreting the Adoption Threshold:

• In this example, 54% of total users need to adopt the process for it to succeed. We should develop strategies to engage at least this percentage of users.

3. Set Realistic and Measurable Metrics

Keep your metrics SMART:

• Specific | Measureable | Achievable | Relevant | Time-bound
• e.g., “Adoption across 90% of modules by 60% of users within 3 months”

4. Engage Stakeholders with a Structured Plan

-Identify and Categorize Stakeholders

• List all stakeholders: Anyone who is affected by or can affect the process.
• Assess Influence (I) and Interest (In): Rate each from 1 (low) to 5 (high).
• Stakeholder Matrix Example:

-Develop Engagement Strategies

• Key Players (High Influence, High Interest): Involve this stakeholder in decision-making, provide them regular updates, and actively seek their feedback.
• Keep Satisfied (High Influence, Low Interest): Engage this stakeholder periodically, ensuring their needs are met without overloading them with details.
• Keep Informed (Low Influence, High Interest): Provide this stakeholder regular information, listen to their concerns, involve them in minor decisions, but don’t overcommunicate.
• Monitor (Low Influence, Low Interest): Minimal effort; monitor for any changes in this stakeholder’s influence or interest.

-Create & Execute a Communication Plan

• Frequency: Determine how often to communicate with each stakeholder group.
• Medium: Choose the most effective channels (e.g., meetings, emails, newsletters).
• Content: Tailor messages to address the specific interests and concerns of each group.

5. Maximize Existing Resources

Before investing in new tools or systems, make the most of what you already have! Inventory all software, platforms, and tools currently in use. Assess whether existing tools can be repurposed or extended to meet new needs. Compare current capabilities with requirements identified in your process. Look for ways to integrate existing systems to enhance functionality. Many platforms have underutilized features that could meet your needs. Invest in training team members to better utilize existing tools.

A Real-World Example: The BotOracle Developer Ambassador Program

When we started building the BotOracle Developer Ambassador Program, we faced our own inherited complexity. We really didn’t want to create just another waitlist. Instead, we are crafting an experience and providing genuine value to participants.

We are aiming for:

• Active Engagement: Encouraging developers to contribute and participate meaningfully.
• Technical Collaboration: Seeking assistance in solving real technical problems.
• Community Building: Nurturing a solid developer community that feels invested.

Given our limited time, budget, and resources, we are leveraging what we have. We are creating social proof badges and an award system, asking the developer community to help with technical challenges. In return, they received recognition they could showcase in their professional endeavors.

We officially kick off the program on November 25th and have already filled 4 out of 250 slots. We’re committed to providing a meaningful experience and offering developers the opportunity to be part of the first wave creating Automations for the Bo-Verse.

The Takeaway

Inherited management complexity is an unavoidable aspect of modern technology projects. Systems are interconnected, dependencies abound, and what seems simple on the surface usually hides layers of intricacy.

The key isn’t to eliminate complexity — that’s often impossible — but to manage it effectively:

• Acknowledge the complexity rather than ignore it.
• Avoid over-complicating your assessment; focus on practical management strategies.
• Engage all stakeholders and aim for that critical mass of adoption.
• Leverage resources wisely, and don’t be afraid to ask for help.

By approaching complexity thoughtfully, you can navigate these challenges and keep your projects moving forward.