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

1
Processes must serve the outcome, not the other way around.
2
Build vs. Buy decisions should be based on strategic value, not "control".
3
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.

?
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 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.

?
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.

?
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.

?
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.

?
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

They say...
This cannot be done any other way because that's SOP/policy/IM8.
Why it's scary

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.

They say...
We're just doing what Min/PS/DS/CE pushed for.
Why it's scary

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

They say...
If we don't do it ourselves, we don't have full visibility... we should DIY.
Why it's scary

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'.

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

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.

They say...
There needs to be X approvals from xxx, yyy, zzz groups to make an edit to the website.
Why it's scary

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

They say...
We need to continue with the current approach because that's how things have always been done.
Why it's scary

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

They say...
We classify this as 'Sensitive' purely because it was classified that way years ago, without review.
Why it's scary

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

They say...
We propose to build a new custom Sharepoint site... we want to use Bootstrap (in 2025).
Why it's scary

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.

They say...
We are implementing a microservices architecture (because everyone else is).
Why it's scary

Microservices introduce massive operational complexity (network latency, distributed tracing, consistency). Unless you have the scale of Netflix or Google, a 'Monolith' is usually faster, cheaper, and easier to maintain.

Dealbreakers

They say...
No one has a hypothesis on what is the problem with a product, feature, system.
Why it's scary

Aimless execution.

They say...
We're chasing after some urgent deadline (funding/procurement) rather than user value.
Why it's scary

Process-driven panic.

They say...
People avoid doing necessary work (refactoring/docs) because they are hiding behind "Waivers".
Why it's scary

Waiver culture.

They say...
Vendor lock-in: The vendor owns the code/logic and we are afraid to fire them.
Why it's scary

Hostage situation.

Apptitude / Curated by Zixian Chen

© 2024–2026. All Rights Reserved.