Forem: Wael Mansour

Shadow Org Charts: Why the Official Hierarchy Is Only Half the Story

Wael Mansour — Wed, 29 Apr 2026 15:21:00 +0000

Every company has two org charts. The official one lives in an HR system somewhere. It shows boxes, lines, and reporting relationships. It is neat, hierarchical, and largely fictional as a map of how decisions actually get made.

The second one exists nowhere in writing. It lives in people's heads — in the instincts of engineers who have been around long enough to know who you really need to talk to before a proposal goes anywhere. This is the shadow org chart, and understanding it is one of the more underrated career skills an engineer can develop.

What the Official Chart Actually Represents

Org charts are documentation of authority, not influence. They tell you who has formal power — who can hire, fire, promote, and approve budgets. That information is real and it matters. But it captures a snapshot of a single dimension of organizational life.

What it misses is everything informal: who the technical expert is that three teams quietly consult before making architecture decisions, which program manager is the actual connector between two organizations that are theoretically aligned but practically siloed, and which senior engineer has been at the company long enough that even VPs will run a contentious idea past them before taking it to a staff meeting.

The org chart is the skeleton. The shadow org is the nervous system.

Why Informal Power Structures Develop

Organizations are made of people, and people form relationships that predate and outlast any reporting structure. A manager who was promoted two years ago still defers to a peer who mentored them. An engineer who moved teams carries institutional knowledge and trust that their new org chart position does not reflect.

Tanya Reilly's The Staff Engineer's Path makes this point clearly: staff-level engineers need to understand not just the technical landscape but the organizational one. The ability to influence without authority — a phrase that appears often in conversations about senior technical leadership — is fundamentally a shadow-org skill. It only works if you know where the informal authority actually sits.

Expertise creates its own gravity. When someone becomes the go-to person for a particular system, a domain, or a type of problem, people route around the org chart to reach them. Trust networks form through repeated collaboration, especially in ambiguous situations where the org chart offered no guidance. Historical relationships — people who worked together through a reorg, a crisis, or a product launch — carry weight that no reporting line can fully convey.

The Types of Power That Never Appear on Any Chart

There are a few archetypes worth learning to recognize.

Decision gatekeepers are people whose approval or buy-in is required before something moves forward, even though they have no formal authority over it. This might be a security architect who hasn't shipped code in three years but whose concerns can halt a launch.

Informal advisors are the people leadership quietly consults before making anything official. Their titles are often misleading. They might be an individual contributor with a decade of context, or a director who is technically peers with five others but whose read on a situation carries disproportionate weight.

Connectors hold the shadow org together. They know everyone, they understand each team's actual priorities (not the stated ones), and they are often the fastest path between two groups that technically have a shared manager but practically never talk.

Blockers are their own category. These are individuals whose opposition — stated or unstated — can stall an initiative indefinitely. Ignoring them is almost always a mistake.

What It Costs to Not Know

The consequences of shadow-org blindness tend to be concrete and painful. An initiative that needed sign-off from a particular team lead stalls because the engineer driving it escalated to the wrong person. A proposal gets shot down in a staff meeting because the informal advisor whose concerns were never addressed chose that moment to voice them publicly.

Missed alignment is probably the most common failure mode. Two teams are nominally working toward the same goal but the engineers who actually have influence over each team's direction have never been in the same room. The official structure suggests this should be fine. The shadow org makes clear it isn't.

How to Start Mapping It

Observation is the first tool. Watch who speaks in large meetings — not who is called upon because of their title, but who volunteers information and whose contributions visibly shift the conversation. Watch who gets thanked in all-hands updates. Both patterns point toward informal influence.

One-on-ones are the best research instrument available. When meeting someone new, asking "who else do you think I should talk to about this?" generates a map of consultation networks faster than any org chart crawl. The people who keep appearing in these referrals are usually load-bearing nodes in the shadow structure.

Pay attention to who gets consulted before decisions go public. There is almost always a pre-meeting before the meeting — a round of informal calls or Slack conversations where the real debate happens. Noticing who is in that circuit, and eventually being in it yourself, is how influence compounds over time.

Watch where escalations actually land. When something is stuck, where do people take it? The answer is often a person, not a process — and that person's real organizational weight becomes visible in how quickly the problem moves afterward.

The Map Is Never Finished

Shadow org charts are not static. They shift when people leave, when teams merge, when someone builds trust through a high-stakes project or loses it through a public misstep. The engineer who was a key node two years ago may be largely invisible today.

The work of mapping it is therefore ongoing, not a one-time exercise. It requires staying curious about people — their history, their relationships, their areas of real expertise versus nominal responsibility.

The engineers who navigate organizations well are rarely the ones who read the official chart and followed it literally. They are the ones who understood that the chart describes one kind of organizational reality, and built the patience to understand the other kind too.

Yet Another Set of Claude Code Plugins (But Maybe Useful?)

Wael Mansour — Sat, 07 Feb 2026 21:01:01 +0000

I've been tinkering with Claude Code for a while now, and like many developers, I found myself repeating certain workflows over and over. So I did what any developer would do - I automated them into skills, agents, and commands. Then figured, why not package them up as plugins and share them with others?

Here's Claude Code Powerups - basically a small collection of plugins I've put together that help with some common tasks I run into. Nothing groundbreaking, but they've been useful for me, so maybe they'll be useful for you too.

🎯 What Are These Plugins?

Just Claude Code plugins with some specialized prompts and workflows. Each one packages up:

Skills - Some custom commands I found myself needing
Agents - Prompts configured for specific tasks
Tools - A few utilities that make repetitive stuff easier
Knowledge - Basically documentation and patterns I keep referencing

Think of them as shortcuts to avoid having to explain the same context to Claude every time. Less "expert consultant," more "that thing you'd document in a wiki if you had time."

📦 What's Available

🏗️ Clean Architecture Powerup

If you work with .NET and Clean Architecture, this might save you some time. It's got:

Interactive scaffolding - Helps set up new projects without forgetting the boilerplate
Feature generation - Generates CRUD features across layers (saves a lot of copy-paste)
Architectural audits - Points out when you accidentally broke the pattern
Migration assistance - Helps refactor existing code (though migrations are never fun)
Pattern library - Common patterns so you don't have to look them up every time

Useful if you're building .NET applications with FastEndpoints and trying to keep things clean. Your mileage may vary.

View Plugin →

☁️ Azure Architect Powerup

Azure configuration can be a pain, so this plugin tries to make it less painful:

Infrastructure provisioning - Helps you set up Azure resources without missing the obvious stuff
CI/CD pipeline setup - Templates for Azure DevOps and GitHub Actions
Multi-environment deployment - Separate dev/staging/prod configs (because we all forget to do this properly)
Security and monitoring - Basic security and logging setup
Cost optimization - Tries to help you not overspend on Azure

Works with Azure CLI, Bicep, and Terraform. Attempts to follow Azure best practices, though Azure has a lot of opinions.

View Plugin →

🔒 OWASP LLM Top 10 Security Auditor

Security for AI stuff is still pretty new, and I kept forgetting to check for common issues. So:

Vulnerability scanning - Looks for OWASP LLM Top 10 issues in your code
Risk assessment - Security reports (basically a checklist)
Remediation guidance - Suggestions for fixes
Compliance checks - Makes sure you're not doing obviously bad things
Pre-deployment audits - Better to catch problems early

Helpful if you're building AI applications and want to avoid the most common security mistakes. Won't catch everything, but catches the obvious stuff.

View Plugin →

🚀 Getting Started

Installing powerups is simple with the Claude Code CLI:

Install the Marketplace

claude-code plugin install waelouf/claude-code-powerups

Install Individual Powerups

# Install Clean Architecture Powerup
claude-code plugin install waelouf/cc-powerup-clean-architecture

# Install Azure Architect Powerup
claude-code plugin install waelouf/cc-powerup-azure-architect

# Install OWASP LLM Security Auditor
claude-code plugin install waelouf/cc-powerup-owasp-llm

Or install all at once:

claude-code plugin install waelouf/cc-powerup-clean-architecture waelouf/cc-powerup-azure-architect waelouf/cc-powerup-owasp-llm

💡 Why Bother Making These?

Honestly? I got tired of re-explaining the same context to Claude every time I switched tasks. One minute I'm working on a .NET project, the next I'm dealing with Azure deployment, then I'm reviewing security stuff.

These plugins just save me from having to:

Open documentation tabs I've already read 50 times
Remember which patterns I decided to use last time
Copy-paste boilerplate from my previous projects
Explain to Claude what "Clean Architecture" means for the hundredth time

Not revolutionary, just practical. Like having notes from your last project readily available.

🔮 What's Next?

I'll probably add more as I run into repetitive tasks that bug me enough. Some ideas I'm considering:

Frontend patterns (if I can figure out how to keep up with JS framework churn)
Database stuff (schema design, migrations)
DevOps workflows (the kind everyone does but nobody documents)
API design patterns (REST, GraphQL, whatever's trendy)

But we'll see. Depends on what I actually need and have time for.

🤝 Community and Contributions

Everything's open source on GitHub. If you find bugs (which you probably will) or have ideas for improvements, feel free to open an issue:

Marketplace: github.com/waelouf/claude-code-powerups
Issues & Feedback: Open an issue on the respective repository
Contributions: PRs welcome if you want to fix something I messed up

🎓 Learn More

Give them a try if you think they might be useful. Or don't. No pressure.

Questions, feedback, or just want to tell me something's broken? Drop a comment below or open an issue on GitHub.

Original post

How to Be an SME, Not an SPF: From Gatekeeper to Growth Enabler

Wael Mansour — Sun, 25 Jan 2026 18:01:49 +0000

In the fast-paced world of technology and business, there's a certain allure to being the go-to person. The one everyone turns to when a critical system goes down, or a complex problem needs solving. You're the expert, the guru, the Subject Matter Expert (SME). And that feels good. But there's a subtle, yet dangerous, line you can cross, transforming yourself from an invaluable asset into a Single Point of Failure (SPF).

This isn't just about job security; it's about career growth, team resilience, and ultimately, the health of your organization. Let's dive into what these terms really mean and how you can ensure your expertise elevates everyone, rather than holding them hostage.

Defining the Acronyms: SME vs. SPF

At first glance, an SME and an SPF might seem similar. Both possess deep knowledge in a specific area. But their impact couldn't be more different.

A Subject Matter Expert (SME) is an individual with profound knowledge and understanding in a particular field. They are the authority, the person who can provide insights, guide decisions, and solve complex problems within their domain. Think of the lead architect who understands every nuance of a system's design, or the data scientist who can interpret the most obscure analytical models.

A Single Point of Failure (SPF), on the other hand, is a component of a system that, if it fails, stops the entire system from working. In human terms, an SPF is the person without whom a critical process, project, or even an entire department grinds to a halt. Imagine a star striker on a football team who's the only person who can score goals. If they get injured, the team is practically guaranteed to lose.

The critical distinction lies in the impact of their absence. An SME’s absence might slow things down; an SPF’s absence brings everything crashing down.

The Hidden Dangers of Being an SPF

While being the "only one who knows how to do X" can feel empowering and even secure your position in the short term, it's a dangerous trap for both you and your organization.

For the Individual:

Burnout: Being constantly on call, with no one else to share the load, leads to immense stress and exhaustion.
Stagnation: You spend all your time maintaining the status quo or putting out fires, leaving no room for learning new skills, innovation, or career advancement.
Limited Growth: It's hard to move up when you're indispensable in your current role. Your organization might hesitate to promote you if it means creating a gaping hole.
Vacation Guilt: Ever feel like you can't take a proper holiday because everything will collapse without you? That's the SPF burden.

For the Organization:

High Risk: What happens if your SPF gets sick, leaves, win the lottery and decide not to work anymore, or simply makes a mistake? Critical operations can cease, leading to lost revenue, missed deadlines, and damaged reputation.
Slow Progress: Bottlenecks form around the SPF, slowing down projects and innovation.
Lack of Redundancy: The team becomes fragile, unable to adapt to changes or unexpected challenges.
Disengaged Team: Other team members might feel disempowered or unmotivated if they can't contribute to critical areas.

From Gatekeeper to Growth Enabler: The SME Mindset

The shift from SPF to a true, impactful SME begins with a change in mindset.

The SPF mindset often involves hoarding knowledge, being a gatekeeper, and subtly (or overtly) enjoying the power that comes from being the only one who understands a complex system. They might believe that their indispensability is their job security.

The SME mindset, conversely, is about leverage and empowerment. It means understanding that your true value isn't in what only you know, but in how effectively you can enable everyone else to succeed. It's about sharing knowledge, building robust processes, and mentoring others so that the team thrives even without your direct, constant intervention.

Strategies to Transform from SPF to True SME

The good news is that this transformation is entirely within your control. Here are actionable steps to shed the SPF burden and become an impactful SME:

Document Everything, Relentlessly:
- "If it's not documented, it didn't happen." This adage is your new mantra. Create detailed process guides, system architecture diagrams, troubleshooting steps, and decision logs.
- Tools: Utilize wikis (Confluence, Notion), shared drives, README files in repositories, or internal knowledge bases. Make it easy for others to find and understand.
- Regular Updates: Documentation isn't a one-time task. Schedule regular reviews and updates to ensure it remains current.
Cross-Train and Delegate:
- Identify Critical Tasks: Pinpoint the tasks where you are currently the sole owner.
- Train Your Peers: Actively teach your colleagues. Schedule dedicated training sessions, pair programming, or shadowing opportunities.
- Empower Delegation: Once trained, empower team members to take ownership. Start with smaller, less critical tasks and gradually increase responsibility.
- Create a visual example of a cross-training session with two people at a computer.
Automate Mundane and Repetitive Tasks:
- If you're repeatedly doing the same manual task, it's a candidate for automation.
- Scripting: Learn scripting languages (Python, PowerShell, Bash) to automate routine operations.
- Tools: Leverage automation platforms and CI/CD pipelines to streamline deployments, testing, and monitoring. This frees up your intellectual capacity for higher-level problem-solving.
Foster a Culture of Knowledge Sharing:
- Lead by Example: Be open to questions, share your insights in team meetings, and actively seek opportunities to teach.
- Regular Knowledge Sharing Sessions: Encourage your team to hold "lunch and learns" or internal tech talks where individuals share what they've learned.
- Blameless Postmortems: When incidents occur, focus on what can be learned and documented, rather than who is to blame. This encourages open discussion and process improvement.
Seek Mentorship – Both Ways:
- Mentor Others: Actively participate in mentorship programs within your organization. Guide junior team members, helping them develop their skills and confidence.
- Be Mentored: Don't stop learning. Find mentors who can help you grow in new areas, pushing you beyond your current domain of expertise.

The Rewards of Being a True SME

Shifting from an SPF to a truly impactful SME doesn't diminish your value; it amplifies it.

Greater Impact: You move from being a reactive problem-solver to a proactive innovator. You can focus on strategic initiatives, complex challenges, and driving genuine progress.
Enhanced Career Growth: You're seen as a leader, a mentor, and a force multiplier for your team. This opens doors to new roles, promotions, and opportunities.
Reduced Stress and Improved Work-Life Balance: With shared knowledge and delegated responsibilities, you gain the freedom to step away, take a vacation, and truly disconnect without fear of things collapsing.
Resilient Teams: You contribute to building a stronger, more adaptable, and more capable team that can weather any storm.

Ultimately, your goal shouldn't be to make yourself indispensable by hoarding knowledge, but to make your team indispensable by sharing it. Embrace the true spirit of a Subject Matter Expert, and you'll find not only greater professional success but also a more fulfilling and less stressful career.

Some good reads related to this topic:

The Phoenix Project
The Mythical Man-Month
Team of Teams

Original Post:
https://blog.waelouf.com/post/blog/sme-vs-spf/

Nanuq 2.0: Unified Management Platform for Kafka, Redis, RabbitMQ, AWS, and Azure

Wael Mansour — Tue, 20 Jan 2026 01:31:44 +0000

Managing multiple messaging and caching systems across development environments is a common pain point. Each platform requires its own CLI tools, different authentication mechanisms, and unique management interfaces. After working with teams juggling Kafka topics, Redis caches, RabbitMQ exchanges, AWS SQS queues, and Azure Service Bus—often simultaneously—I built Nanuq to solve this problem.

Today, I'm excited to share Nanuq 2.0, a major milestone that brings cloud platform support, enterprise-grade security, and production-ready features to this open-source project.

What is Nanuq?

Nanuq is a unified management interface that consolidates five critical messaging and caching platforms into a single, intuitive web UI:

Apache Kafka - Topic management and monitoring
Redis - 6 data types with full CRUD operations
RabbitMQ - Exchange and queue management
AWS (SQS/SNS) - Cloud message queuing and pub/sub
Azure Service Bus - Enterprise messaging with queues, topics, and subscriptions

Instead of switching between kafka-console-consumer, redis-cli, rabbitmqctl, AWS Console, and Azure Portal, developers can manage everything from one place.

Kafka topic management with message counts and partition details

Unified dashboard showing metrics across all five platforms

What's New in Version 2.0

Cloud Platform Integration

The biggest addition in 2.0 is complete cloud platform support:

AWS (SQS/SNS)

15 AWS regions supported (us-east-1, eu-west-1, ap-southeast-1, etc.)
Full SQS operations: create queues (standard/FIFO), send/receive messages, monitor queue attributes
SNS topic management: publish messages, manage subscriptions (HTTP, Email, SMS, SQS, Lambda)
Multi-region deployment for distributed teams

Azure Service Bus

30+ Azure regions supported globally
Queue management with configurable TTL, dead-lettering, and duplicate detection
Topics and subscriptions with filtering capabilities
Complete message lifecycle: send, receive (peek-lock mode), and dead-letter queue access

Managing AWS SQS queues with send/receive capabilities

Azure Service Bus topic and subscription management

Enterprise Security

Security was a top priority for 2.0:

AES-256 Encrypted Credential Storage

All stored credentials (passwords, access keys, connection strings) are encrypted at rest using AES-256 with DPAPI-derived keys. The encryption service handles automatic encryption when credentials are saved and decryption when they're needed for API calls. Passwords are never exposed in API responses—only metadata returns to the frontend.

Connection Testing

Before saving credentials, users can test connections to verify they work. This validates that access keys, passwords, and connection strings are correct before persisting them to the database, preventing configuration errors.

Unified Dashboard

The new dashboard provides real-time visibility across all platforms:

Server count, topic/queue count, and resource metrics per platform
Environment breakdown (Development, Staging, Production) with color-coded badges
Recent activity feed with filtering by platform and operation type
Quick actions to add new servers for each platform

Activity Tracking & Audit

Complete audit trail with 24+ activity types covering all operations across all platforms:

Advanced filtering (by type, date range, search text)
Export to CSV or JSON for compliance
Visual timeline with Material Design icons
Auto-refresh for real-time monitoring

Complete activity audit trail with filtering and export capabilities

Advanced Redis Support

Full CRUD operations for all 6 Redis data types:

Strings - View, add, update, and delete cached keys with TTL support
Lists - Push/pop elements, view all elements, manage list keys
Hashes - Set/get fields, view all fields, manage hash keys
Sets - Add/remove members, view set members
Sorted Sets - Add members with scores, view sorted members
Streams - Add entries with multiple fields, view stream entries

All operations support pagination for handling large datasets.

Managing Redis keys across different data types

RabbitMQ exchange and queue management

Multi-Environment Management

Tag servers by environment (Development, Staging, Production) with color-coded badges in the UI. This makes it easy to avoid accidentally modifying production resources and helps teams manage multi-environment workflows.

Technical Architecture

Backend: .NET 10.0 Modular Monolith

The backend uses a clean, modular architecture:

Nanuq.WebApi/          # FastEndpoints API
Nanuq.Kafka/           # Kafka integration
Nanuq.Redis/           # Redis integration
Nanuq.RabbitMQ/        # RabbitMQ integration
Nanuq.AWS/             # AWS SQS/SNS integration
Nanuq.Azure/           # Azure Service Bus integration
Nanuq.Security/        # AES-256 encryption service
Nanuq.EF/              # Entity Framework Core context
Nanuq.Sqlite/          # SQLite repositories
Nanuq.Common/          # Shared records and interfaces

Key patterns:

FastEndpoints instead of traditional controllers for better performance
Repository pattern for data access abstraction
DbUp migrations for database schema management
Dependency injection throughout

Frontend: Vue 3 + Vuetify

The frontend leverages Vue 3 with Vuetify's Material Design components:

State management:

Separate Vuex modules for each platform (kafka.js, redis.js, aws.js, azure.js)
Centralized error handling with global notification system
Optimistic UI updates with rollback on errors

Database: SQLite with EF Core

SQLite provides zero-configuration persistence for all server configurations, credentials, and activity logs. DbUp migrations run automatically on startup, making schema updates seamless.

Getting Started

Docker (Recommended)

# Pull and run both backend and frontend
docker-compose -f Docker/docker-compose.yml up -d

# Access the app
open http://localhost:8080

Kubernetes

One-command deployment:

kubectl apply -f https://raw.githubusercontent.com/waelouf/Nanuq/main/K8s/nanuq-all-in-one.yaml

# Check deployment
kubectl get pods
kubectl get service nanuq-frontend

Local Development

Backend:

cd src/services/Nanuq/Nanuq.WebApi
dotnet run  # Runs on http://localhost:5000

Frontend:

cd src/app/nanuq-app
npm install
npm run serve  # Runs on http://localhost:8080

Real-World Use Cases

Here are some scenarios where Nanuq shines:

1. Microservices Development
Developers working on microservices often need to inspect Kafka topics for event streams, check Redis caches for session data, and verify RabbitMQ queues for async tasks—all in one session.

2. Multi-Cloud Deployments
Teams deploying to both AWS and Azure can manage SQS queues and Azure Service Bus from the same interface, reducing context switching.

3. Environment Promotion
Tag servers as Dev/Staging/Production and easily compare configurations across environments before promoting changes.

4. Debugging Production Issues
Quickly check message counts, peek at queue contents, and identify bottlenecks without installing CLI tools or memorizing commands.

Performance Considerations

Pagination
All list operations support pagination to handle large datasets efficiently. Queue lists, topic lists, and message retrieval all use cursor-based or token-based pagination to prevent memory issues when dealing with hundreds or thousands of resources.

Caching Strategy
Frontend implements smart caching with selective invalidation:

Server lists cached until explicit refresh
Queue/topic details cached with 5-minute TTL
Message lists never cached (always fresh)

Connection Pooling
AWS and Azure SDK clients use connection pooling to minimize overhead and improve response times for consecutive operations.

Security Best Practices

What Nanuq Does:

Encrypts all credentials at rest (AES-256)
Never logs sensitive data (passwords, keys, tokens)
Uses HTTPS for all frontend-backend communication
Validates all user input on both frontend and backend

What You Should Do:

Use environment-specific credentials (don't share prod creds in dev)
Enable MFA on cloud accounts
Rotate credentials regularly
Review activity logs for unauthorized access
Deploy behind a VPN or restrict network access

Limitations and Future Roadmap

Current Limitations:

No built-in user authentication (single-user mode)
No role-based access control (RBAC)
Limited to Windows for DPAPI-based encryption (cross-platform encryption planned)

Roadmap (contributions welcome!):

Metrics and alerting (Prometheus integration)
Schema registry support for Kafka
More cloud platforms (Google Cloud Pub/Sub)
Dark mode UI theme

Contributing

Nanuq is open source and welcomes contributions:

Areas we'd love help with:

Cross-platform encryption (replace Windows DPAPI)
Unit and integration test coverage
Documentation improvements
Bug reports and feature requests

Check out the GitHub repository to get started.

Conclusion

Nanuq 2.0 represents a significant step forward in simplifying messaging and caching platform management. By consolidating five platforms into one interface with enterprise-grade security, we're reducing cognitive load for developers and making multi-platform workflows more efficient.

The project is built with modern .NET and Vue.js, follows clean architecture principles, and is designed to be easily extensible for additional platforms.

Try it out, and let me know what you think in the comments!

Links:

GitHub: https://github.com/waelouf/Nanuq
Issues: https://github.com/waelouf/Nanuq/issues

What messaging platforms are you managing in your projects? Would a unified interface like this help your workflow? Share your thoughts below!

Nanuq!

Wael Mansour — Thu, 16 Jan 2025 02:53:18 +0000

What is Nanuq?

Nanuq (which means “polar bear” in the Inuktitut language spoken in the central and eastern Canadian Arctic) is an application designed to simplify the management of Kafka and Redis for developers. Instead of relying on command-line interfaces for each server, Nanuq provides a unified, user-friendly interface that streamlines daily tasks. Whether you’re monitoring queues, managing datasets, or configuring clusters, Nanuq empowers you to handle these critical operations with ease, all from a single UI.

Why?

The main purpose of this application is to help track middleware (Kafka, Redis, etc.) during development.

Another reason is to have a small greenfield project where I can learn new (or refresh rusty) technologies.

Continue reading the post here