Home of Shariq Mustaquim on the Internet!
Why do HR insist on team building on my personal time (after 5pm or on a Saturday) with a mandatory attendance?
If anything it is sending the opposite signal to me, you don't care for my personal boundary.
If “culture” requires sacrificing personal life, the problem isn’t the calendar. It’s the culture.
Challenging times feel long. That doesn’t mean they are.
Ask any batsman who endured Rudi Koertzen’s iconic, slow-rising finger.
For the batsman, it wasn’t just “out” … It was a slow crawl to death.
“Dude… just give me out already. I get it. I’m done.”
Good programmers copy, great programmers paste.
My introduction to StackOverflow was during a Kelsey Hightower demo, where he casually copied a snippet of code (probably staged) from the programmers Q&A site and uttered the iconic line "Good programmers copy, great programmers paste"
Having a stellar reputation on the site now feels like a lost art, but back then, it was a fun ride while it lasted.
At Amazon, a meeting room often has an empty chair to represent the customer.
This connects with another of Amazon’s distinctive peculiarism: Working Backwards.
Instead of starting with features, teams start with the customer’s ideal outcome.
The first deliverable is not a prototype or a design document. It is a "future dated" press release written as if the product has already launched.
I like the concept of Working Backwards because it focuses on outcomes not outputs.
"When people having a shared goal don't cooperate, it results in a worse outcome for all of them." [Game theory]
Working with software vendors can feel like a real-life game theory exercise. Both client and vendor want a successful product, yet both often lose time, energy, and goodwill.
Your organization funds a new app. You spend weeks on requirements and designs. Then a disagreement arises over scope, timelines, or a technical trade-off.
The vendor says, "That’s not in the contract"
The client says, "But it is essential for users"
Both sides dig in. The vendor won’t do extra work without a change request. The client won’t issue one for something they assumed was included. The result? Delays, frustration, and a relationship focused on "who’s right" instead of "what’s right."
Game theory calls this a "non-cooperative equilibrium". In software, this means defensive emails, endless clarifications, and missed deadlines.
To break the cycle, build trust and transparency (yes, easier said than done). Treat the project as a shared mission, not a transaction. Shift from "us vs. them" to "we’re in this together."
Software is a real human collaboration challenge in which clients and vendors succeed or fail together
There is a reason IKEA wants you to build your own furniture. Research suggests people who built their furniture by hand valued it more.
I connect this directly to the principle of "People over Process over Tools".
When people build a process themselves, they value it and adhere to it more. This organic ownership is always better than having a process parachuted in from the top.
Because no tool can fix what unclear ownership or a broken process cannot deliver.
The right answer, if late, is the wrong answer.
During my time at AWS, one Amazon "Peculiarism" that shaped how I approach decisions is the idea of "two-way door decisions".
If a decision is low risk and reversible, don’t wait for perfect information. Take it, test it, and adjust if needed. Its like walking through a door you can always come back from.
This way of thinking is deeply tied to the "Bias for Action" leadership principle. Speed matters, and so does learning. Not every decision needs long analysis, meetings and PowerPoint slides.
Would you like to know some more Amazon "Peculiarisms"? I can think of around 10 from the top of my head.
I will never forget this one part of my AWS onboarding. The instructor showed us this short, animated video by Brené Brown about empathy. It used this characterization of a fox in a hole, and it just clicked for me. The point was that empathy isn't about having the right answer or fixing someone's problem for them. It's about climbing down into the hole and sitting with them for a minute. As Brown says, it's "feeling with people."
In cloud world, we are constantly in the weeds with complex systems and stressed-out customers. It's easy to get lost in the technical puzzle. But that lesson was a constant reminder: the person on the other end of the screen is having a real, human crisis. Sometimes, the most technical thing you can do is to first say, "Wow, that sounds incredibly frustrating. Let's figure this out together."
That early lesson stuck with me. Sure, technical chops are what get the problem solved, but empathy is what makes a customer actually trust you.