Running the Project

Work backwards from where failure occurs, so that you can then plug those gaps.

Either or both options have situations where they're better. No matter what, there must be a plan that's being executed to handle a surge later on.

These are extremely simple but can absolutely show dedication (or lack thereof) to optimizing performance. Better performance will help improve transaction completion rates and user satisfaction.

UIs have no excuse doing poorly on mobile responsiveness and accessibility.

There are obvious differences across models, some do better than others. Like Claude 3.5 sonnet is really good with code and Gemini 2.0 or gpt 4.5 give me really good creative writing pieces. The business objective to keep up with the best in class and choice when there are advancements. The fear is always stagnating because of a lack of incentives to change.

From a business perspective, need to understand how resource usage meets objectives. Can users access the offering? Can they transact? Are they satisfied? How can costs be reduced?

Lack of utilization of free AWS tools like Trusted Advisor and enterprise support indicates a lack of cost discipline and workload optimization.

A 10% failure rate is common; excessively high rates suggest potential measurement errors. Review start and end points of measurements to ensure they accurately reflect customer transaction success.

Manual monitoring is inefficient and unresponsive. Real-time, automated monitoring is essential for timely service issue detection and resolution. Stats should be used for ongoing health checks, not just periodic presentations.

What is the backup frequency? Are these active or passive copies? Where are they stored? How many copies? How long does it take to restore them? Are these complete snapshots or diffs? You'd always want some variant of the 321 backup rule.

You're trying to recreate something that's presumably solved well. And doesn't seem like you did your competitive audit. Even if you're satisfied with your solution, you should say why yours works better, eg from user research.

They're very different things! The person saying this betrays a lack of understanding of what these 2 acronyms mean. Ui is a part of ux. Ux is far more than just tinkering with screens, colors, typography, spacing on figma templates. And this lack of clarity prevents us from going into what needs to be solved and how we should solve them.

You can't track the productivity increase for every person, but you can follow >5 teams for several weeks and record how much they benefit in time savings, efficiency, errors they encounter, or even entire work flows they no longer do. But this has to be done before you deploy and is pointless to lament you didn't after the fact.

It's part and parcel of running systems. Patching is essential.

They're very different things! The person saying this betrays a lack of understanding of what these 2 acronyms mean. UI is a part of ux. UX is far more than just tinkering with screens, colors, typography, spacing on figma templates. And this lack of clarity prevents us from going into what needs to be solved and how we should solve them.

Bureaucracy crept in. If this is for a new tool, then it's also the case we bought a new tool and overlaid past processes.

Finance processes (fixed payments for vendor work) can ironically encourage spending more than common sense dictates, because they can let vendors pocket the change if the job turned out easier. People also want to buffer so no one needs to reseek approval. End result, people add buffers, overestimate, and vendors pocket the "change".

We only listen to feedback if it's good, or if our bosses are affected by it.

Lack of data integrity and actionable insights. At this point we might as well not even have measured, that'd be better than getting wrong conclusions from incorrect data.

Relying on manual system checks signals a reactive operational model. Business outcomes benefit from proactive, automated monitoring, with clear triggers tied to business objectives.

Reducing UX to purely visual UI tweaks betrays a fundamental misunderstanding of user-centered design. True UX is about understanding user needs and designing effective, efficient, and satisfying solutions. Ignoring user research leads to poorly adopted products.

Launching projects without a plan to quantify business impact makes it impossible to justify the investment and demonstrate ROI. Projects must be accountable for delivering tangible value, requiring measurement from the outset.

Overly complex approval processes for routine tasks signal a bureaucratic culture that stifles agility and innovation. In tech, quick adaptation is crucial. Excessive bureaucracy hinders progress and responsiveness.