Structures, Processes, Vendors

Definitions

Conway's Law
Organizations design systems that mirror their own communication structure. If you have disjointed teams, you will build disjointed systems.
HiPPO
Highest Paid Person's Opinion. When decisions are made based on authority rather than data or user research.
Change Request (CR)
A formal proposal to modify a system. In bad vendor relationships, this is the primary revenue stream for the vendor, incentivizing them to deliver incomplete initial products.

Goals

Processes must serve the outcome, not the other way around.
Build vs. Buy decisions should be based on strategic value, not "control".
Flatten approval hierarchies to match the speed of software deployment.

Questions to Ask

What are the steps to get approval for this idea?

If the answer involves weeks of waiting and 5+ signatures for a minor change, your process is the bottleneck, not the technology.

Has this undergone business process reengineering (BPR)?

Digitizing a bad process just gives you a fast bad process. You must fix the workflow before you build the software.

Explain what agile/velocity means to you and what are examples of agility in this project?

Many vendors/teams claim to be 'Agile' but just do 'Waterfall in Sprints'. If they can't define velocity or give examples of pivoting based on feedback, it's fake Agile.

Why are you coming with an "all or nothing" / "Big Bang" plan?

Usually because the funding/approval process is so painful, teams try to bundle everything into one massive request. This increases risk of failure. Iterative funding is safer.

Why can't we just get all these people into a room and decide?

Async communication is great for work, but sync meetings are necessary for decisions. Endless email threads/committees avoid decision-making responsibility.

Why is onboarding of developers/services still manual?

Manual onboarding kills momentum. If it takes 2 weeks to get a laptop and access rights, you have wasted 2 weeks of salary.

How long does it take to on-board a new service, API, or developer?

This is a key metric for 'Lead Time'. If onboarding takes weeks due to manual approvals or provisioning, you cannot be agile.

Alarm Bells

This cannot be done any other way because that's SOP/policy/IM8.

Policies are meant to serve outcomes. If a policy prevents a logical solution or a good user outcome, the policy (or its interpretation) should be challenged, not blindly followed.

We're just doing what Min/PS/DS/CE pushed for.

This is HiPPO-driven development. Leadership provides direction, but implementation must solve a verified user problem. Blind execution often leads to expensive white elephants.

If we don't do it ourselves, we don't have full visibility... we should DIY.

This is 'Not Invented Here' syndrome. You are trading the reliability of a proven market solution for the burden of maintaining a custom tool forever, usually just to satisfy a desire for 'control'.

This company is able to customize it in Xyz way... It's not their main product line.

They are going to milk you like a cash cow via Change Requests. If you are the only client asking for this feature, you are now maintaining a fork of their software.

There needs to be X approvals from xxx, yyy, zzz groups to make an edit to the website.

Bureaucracy has crept in. If you need a committee to change a typo, your governance structure is broken.

We need to continue with the current approach because that's how things have always been done.

The most dangerous phrase in business. It ignores technological advancements and changing user needs.

We classify this as 'Sensitive' purely because it was classified that way years ago, without review.

Over-classifying data forces you into expensive, cumbersome compliance architectures that kill agility without reducing real-world risk.

We propose to build a new custom Sharepoint site... we want to use Bootstrap (in 2025).

This is 'Legacy on Arrival'. Choosing a framework that peaked over a decade ago for a greenfield project signals that the team has not upskilled. You are creating technical debt before the first line of code is even written.

We are implementing a microservices architecture (because everyone else is).

It increases maintenance costs by 10x. Unless you have Google's scale, you are paying for complexity you don't need.

Meeting rooms are absolutely silent.

Everyone just sits quietly in meetings. Nobody speaks up or disagrees.

We have a "Green Scorecard" culture.

If all your metrics are green but the product isn't shipping, you are managing "impression" rather than reality.

Stop being so negative. Why are you always questioning everything?

This is shooting the messenger. You are training your team to practice "Impression Management" rather than problem-solving.

Leadership punishes "I don't know."

Framing complex work as "pure execution" forces teams to hide reality. If you demand efficiency on innovation work, you incentivize people to bury problems.

The vendor/stakeholder uses complex sentences and third-party pronouns ("The system," "They," "The team") rather than "I" or "We".

The "Pinocchio Effect": Liars use more words and distance themselves from the lie using third-person pronouns. A trustworthy partner usually says "I" or "We" and keeps it simple.

We got a waiver for the refactoring and documentation, so we can skip it for now.

Waiver culture. When teams systematically use waivers to defer critical work, technical debt accumulates unchecked. This creates fragile, unmaintainable systems that eventually collapse under their own weight.

We are trying to change the organization with just one "Change Champion".

You need a "Guiding Coalition" of 5 to 50 people with real power. A lone wolf gets eaten.

I'm ok with lousier work to improve psychological safety here.

The "Comfort Zone" (safe + low standards) is useless. We want the "Learning Zone" (safe + high standards).

I don't care if it was an experiment or a production error. Failure is failure.

If you punish an experimental failure the same way you punish a lazy error, people will stop experimenting.

Dealbreakers

Red Flag
No one has a hypothesis on what is the problem with a product, feature, system.
Why

Aimless execution. Without a clear problem hypothesis, teams cannot validate whether their work solves anything meaningful. This leads to wasted resources building solutions in search of problems.

Red Flag
We're chasing after some urgent deadline (funding/procurement) rather than user value.
Why

Process-driven panic. When deadlines drive decisions instead of user outcomes, you optimize for spending budgets rather than delivering value. This produces expensive but useless deliverables.

Red Flag
Vendor lock-in: The vendor owns the code/logic and we are afraid to fire them.
Why

Hostage situation. When you cannot change vendors without losing critical business logic, you lose negotiating power and control over your roadmap. The vendor can extract premium pricing while delivering minimal value.

Red Flag
We are trying to force a structural change without a Guiding Coalition.
Why

Structure doesn't change itself. You need a powerful team to break the inertia. (See Guide: Transformation).

Apptitude / Curated by Zixian Chen

© 2024–2026. All Rights Reserved.