One of the most memorable concepts I picked up during my architecture days was the dreaded "Thud" documents. Hundreds of pages of design specs that would make a literal thud when printed and dropped on a table. The sound is symbolic of slow, heavy, expensive, and out-of-date systems the moment they land. Building the future legacy.

Product has its version of this, the "Thud" PRD.

If you’ve been a party to one or on the receiving end, you know the pain. A product requirements document that tries to capture the entire system end-to-end including every workflow, rule, state change, interaction, and edge case. The goal is completeness, but the result is churn and friction.

You can’t ship a Thud PRD in a sprint. You can’t ship it in a quarter. Most of the time, you can’t ship it at all because it changes as soon as it lands.

• PRDs should be scoped to a single epic

• Measurable outcomes must be defined

• Instrumentation must be a first-class citizen

• A/B testing should be foundational, not an afterthought

Why “Thud” PRDs Fail

The features are all spec’d out and passed the review. Precious design and engineering cycles are consumed. Then the team is lost in the wilderness building who knows what. The problem is not lack of execution. It is that we planned for the wrong things.

The Thud PRD is built on a false belief: that if we just plan enough, we’ll get it right. The reality is you have no clue what you need to build three months from now.

• You are guessing until users interact with the product

• Most assumptions will be outdated before delivery

• Big specs get political, not better

• Over-scoping creates pressure to deliver features users didn’t ask for

The result is delay, rework, churn, and wasted effort.

A Real-World Example

As a product owner at a financial services company in the mid 2000s, I developed a 52-page PRD for a risk and compliance management platform. It described every feature, system behavior, role, and report across the entire product. Four months in, the team shipped the beta and adoption was in the toilet. The system was technically built to spec, but completely misaligned with real workflows. The team successfully executed a death march.

I salvaged what I could. This time, I wrote a single, concise PRD, focused on a specific user problem: Risk managers wasting hours reconciling POs. There were other problems, but I put those in the backlog for future reference. Maybe we’d build them, maybe we wouldn’t.

The PRD was less than 8 pages. It included a hypothesis, metrics, personas, user stories, and acceptance criteria specific to solving that problem. Within six weeks, we had a prototype that users could test, give feedback on, and we could learn from. The result: a product that shipped on time, with 90% of features actively used in the first month, and happy customers.

The Essentials of a PRD

Avoiding the Thud doesn’t mean writing less. It means focusing on the essentials. Writing for clarity, alignment, measurement, and a specific user with a specific problem. execution. Below are the essential components:

1. Define the Problem
State the specific problem you're solving. Not a feature, not a stakeholder request. A problem backed by data.

“Developers need to configure IAM roles manually for each microservice deployment, resulting in an average of 6 hours per week in setup errors and support tickets.”

2. Identify the User Persona
Name the actual person experiencing the problem. Be concrete.

“Sarah is a backend developer managing five microservices across staging and production. She frequently provisions new environments and spends significant time troubleshooting permission issues during deployment.”

3. Form a Hypothesis
Define your solution as a testable hypothesis, tied to a measurable outcome.

“Introducing a pre-configured IAM role template library will reduce permission setup time by 80% and decrease support tickets related to misconfigurations by 50% within 60 days.”

4. Define Metrics and Success Criteria
Attach the solution to a quantifiable goal. If you can’t measure it, don’t build it.

“Reduce average IAM setup time from 90 minutes to under 15 minutes. Lower access-related support tickets from 40 to 20 per month.”

5. List Considered Options
Show what other paths were explored and why they were rejected. This reduces re-litigation later.

“We considered auto-generating policies based on historical service behavior, but the risk of over-permissioning was too high. Template-based provisioning with explicit scopes provided stronger security guardrails.”

6. Outline Instrumentation Requirements
Define what needs to be tracked to measure outcomes. Include logging, event data, dashboards, and control groups.

“Log IAM template usage by environment, track time from selection to deployment, capture permission denial events post-deployment, and segment error rates by template.”

7. Scope to an Epic or Less
Your PRD should be deliverable in a handful of sprints. If it’s larger than an epic, break it up.

“Goal: Ship within 4 sprints with . Ship initial IAM template library with five use cases (EC2, Lambda, S3, DynamoDB, SQS), including developer documentation and CLI support within three sprints with weekly milestone check-ins and demo-ready builds”

8. Include User Stories, Rules, and Test Cases

Add only the details needed to validate the problem and prove the solution. Include user stories with clear acceptance criteria that reflect the desired outcome. Describe edge cases that are relevant to the target developer persona, especially those that could cause failure in real-world environments. Document any business rules or compliance constraints that must be enforced during implementation. Finally, define test cases that are directly tied to the original hypothesis, ensuring that success or failure can be measured objectively.

Example stories:

• “As a developer, I want to select a predefined IAM role for my Lambda function so I can deploy without writing a custom policy.”

• “As a team lead, I want to restrict template usage to approved roles only.”

Acceptance criteria:

• Templates apply correct least-privilege policies.

• Deployment succeeds without manual policy editing.

• Audit logs show role usage and associated actions.

Avoid describing the entire system. Use a separate product vision and strategy doc for that. Focus on what matters to ease your customer’s pain.

Good vs. Bad: PRD Comparison

Don’t Mistake Agile for Adaptability

Agile rituals won’t save a bad PRD. You can iterate on the wrong thing indefinitely. Without clearly defined problems, measurable outcomes, feedback loops, and learning mechanisms, Agile becomes a delivery treadmill.

Iteration only works when it’s grounded in data and structured for learning.

Final Takeaway

If your PRD can’t be shipped within a few sprints, it’s too big. If it doesn’t define a specific user problem, it’s too vague. If it lacks metrics, it’s just a guess. To simplify it, if your PRD is bigger than an epic, then trim it down.

Kill the “Thud” PRD. Build requirements that help teams learn, adapt, and deliver impact.

Start with the customer problem, form a hypothesis, define the customer’s end state, and work backwards from that.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

Subscribe now

In product development, churn == indecision. Analysis paralysis (gross). Endless strategy debates. Reopened tickets. Lack of Priorities. Zero traceability. Momentum stalls out. As a product manager, your antidote is to maintain a healthy backlog. This is your bread and butter.

TL;DR

• Churn is the result of indecision. Indecision stems from ambiguity. Ambiguity lives in your backlog.

• When churn creeps in, start by diagnosing the health of your backlog.

• A healthy backlog enables execution, reduces risk, and keeps teams aligned.

• As the PM, owning the health of the backlog means driving clarity, context, prioritization, and confidence in what the team will build next.

• User stories must meet a high bar. Use framework (e.g. INVEST) to evaluate if your user stories are meet the “Definition of Ready”

The Anatomy of Churn

Churn looks like endless meetings to clarify scope. Engineers bouncing between tasks. Reopened tickets. Deliverables that miss the mark. “We’re working hard, but nothing’s moving” becomes the mood of the team. Progress slows. Morale drops. Decisions get revisited, again and again.

Churn happens when teams can't make decisions. Not because they're incapable, but because the data is murky and broken. Tasks are vague. Priorities are unclear. Stakeholders disagree. The backlog—meant to be a source of direction—becomes a source of friction.

Churn is the equivalent of “analysis paralysis.” And while engineering teams bear the brunt of this disarray, the root cause is upstream. The problem is an unhealthy backlog. As the product manager, this is your responsibility. It's your product. Your backlog. Your churn to eliminate.

Example: Amazon’s Decision-Making Mechanisms

The underlying pattern for churn is always the same: a failure to decide and act. Decisions aren’t being made because the inputs to decision-making—what to build, why it matters, how to know it’s done—are broken or missing. When backlog items are poorly defined, disconnected from customer value, or unprioritized, they introduce ambiguity and hesitation leading to churn.

At Amazon, the goal is to be bias for action and move fast. This means baking decision-making mechanisms into the culture. Examples of these mechanisms include:

• 1-way and 2-way doors: Know when a decision is reversible (2-way) vs. irreversible (1-way). Individuals and teams should be empowered to execute 2-way door decisions all day long without repercussions.

• Disagree and commit: Align even when you don’t fully agree. The beauty is you make a decision and move forward.1

• Tenets: These eliminate debate, align direction, and introduce a “tie-breaker”.

• 70% rule: When you have 70% of the data, make a decision and go!

• STL/STO: Single-threaded Owner/Single-threaded Leader. Empowering an individual to make tie-breaking decisions across a product or program can unblock teams and keep momentum going.

These mechanisms are not exclusive to Amazon. You can build your own version. But understand that your backlog plays a critical role in enabling fast, confident decisions. As the PM, your countermeasure to churn is a healthy backlog.

Backlog Ownership

Product managers can confuse their job with the daily grind of engineering execution and embedding into scrum ceremonies. While it’s tempting to get in the weeds, you’re not responsible for every task in the sprint. You don’t earn trust by micromanaging the “how,” but by providing clear, prioritized “whats” and “whys.”

Your highest leverage isn’t refining individual tickets, it’s shaping the features, epics, and stories that steer the roadmap. Your job is to look up and out. Own the stack rank of features, epics, and user journeys that make up the roadmap. Your backlog is the connective tissue between long-term vision and short-term execution

The closer an item is to the current sprint, the more detailed and squared away your backlog should be. If you’re three months out, you’re framing customer pain points, epics, and user stories. If you’re three days out, those stories should already be refined, scoped, testable, prioritized, and signed off by engineering.

When engineering teams enter sprint planning, your backlog should be squared away. The stories require no additional meetings to decode intent. Engineers should be able to pull down stories with full context, understanding what to build and why it matters. The backlog should create flow, not friction.

The Engineer's Experience

Engineers are your customers too. An unhealthy backlog is anxiety inducing for engineering teams. Engineers don’t want to chase down context. They don’t want to debate priorities mid-sprint. They want clarity, focus, and a shot at building something that matters. When the backlog is thin, vague, or filled with low-impact work, it creates anxiety. What’s next? Who decides? Why are we doing this?

Engineers thrive when they know what’s next. They understand why the thing they’re building is a priority. They trust that the precious dev cycles used to build the feature connect to the bigger picture and will have an impact. As a PM, your job is to make the next right thing obvious.

This isn’t just about productivity. It’s about respect. A clear backlog signals you value their time and talent.

The Measure of a PM: Backlog Health

The backlog isn’t just a necessary evil, it’s how you bridge the gap between strategy and execution. It’s where tradeoffs are made. Where big bets live and die. Where teams obsess over customer pain points and focus on delivering solutions to solve them.

If you can't explain what’s in your backlog, you don’t own your product. You should be able to walk into any team meeting and articulate:

• What problems the team is solving

• Why those problems matter

• How each story fits into the customer journey

• What impact you expect to deliver

A healthy backlog has six traits:

1. Prioritized – Items are clearly stack-ranked. Items are ordered based on factors like impact, cost of delay, severity, not just gut feel.

2. What and Why – Each item articulates what needs to be built and why it matters to the customer and business.

3. Customer Obsessed - Every story starts with the customer in mind and is tied to a broader customer journey.

4. Traceability - Clearly shows the link between tasks, work, and stories to user journeys and business outcomes.

5. Testable - User stories are broken down into clear, testable units

6. Data-driven - Each story has inputs that are data-driven, based on hypothesis, assumptions validated and have outputs that directly impact goals and metrics.

You can evaluate if user stories in your backlog meet the bar through various methods. One of them is INVEST:

• Independent – No hidden dependencies

• Negotiable – Designed for refinement

• Valuable – Has direct user or business impact

• Estimable – Can be scoped

• Small – Fits within a sprint

• Testable – Has clear acceptance criteria

Signs of Unhealthy Backlogs

Backlog deterioration is a subtle, slow burner. A clear sign that its off the rails is when meetings start to multiply. Other indicators are when priorities shift day-to-day or mid-sprint, team morale dips, or lead times increase. Worst case, teams build something no one uses or wants (aka Shelfware).

Final Takeaway

Churn is the result of indecision. Indecision stems from ambiguity. Ambiguity lives in your backlog. You don't owe the team velocity. You owe them clarity. If you're feeling churn, start with the backlog. That's your bread and butter.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

Subscribe now

Product roadmaps look great on paper with neatly laid out requirements, epics, user stories, and acceptance criteria. However, these are, at best, educated guesses. Worse, prioritization of those requirements is often based on gut feel rather than concrete evidence.

This isn’t a post about yet another prioritization framework. Instead, it’s about why experimentation generates the necessary data to make high-quality product decisions. Decisions that minimize waste, avoid costly missteps, and ensure teams are building the right things for the right reasons.

The High Cost of Assumptions

Companies operate on quarterly and annual budgets, demanding measurable results from every investment. The standard pitch goes something like this: "We will deliver Feature X at a cost of Y, leading to Outcome Z." If the math checks out, leadership approves the build.

But here’s the catch: how do you know Feature X is worth building in the first place?

Far too often, product development is driven by assumptions rather than validated insights. A CB Insights study found that 42% of failed startups cited “no market need” as their primary reason for failure1. This means they built something no one actually wanted or needed. The same principle applies to enterprise product teams—without proper experimentation, teams are effectively gambling with development resources.

Why Product Teams Skip Experimentation (and Why They Shouldn’t)

Most product managers don’t apply the scientific method to their hypotheses. Instead, they over index on customer feedback, competitor analysis, anecdotes, and market trend. These are useful inputs, but only paint half of the picture. As a result, flawed assumptions get funded, leading to wasted development cycles and frustrated teams.

The common excuses for skipping experimentation include:

• "Engineering time is too expensive."

• "We need to move fast and ship more features."

• "We already validated this in customer interviews."

But consider this: the cost of wasted development is significantly higher than the cost of early testing. IBM estimated that the cost of fixing a defect post-release is 100x greater than fixing it during the design phase2. Similarly, Google, Amazon, and Netflix have all shown that continuous experimentation leads to better product-market fit, higher user engagement, and ultimately, more successful products.

Scrummerfall: The Silent Productivity Killer

Even in Agile teams, I frequently see the Scrummerfall anti-pattern—where teams follow an iterative development process in theory but a waterfall-style planning process in practice. The cycle goes like this:

1. Develop a PRFAQ (Press Release & FAQ) and/or PRD (Product Requirements Doc).

2. Validate with engineering.

3. Add it to the backlog.

4. Prioritize, build, and ship.

But this sequence misses a crucial step: experimentation. Without it, teams risk building the wrong thing, incurring opportunity costs, and ultimately delivering features that never gain traction.

A Better Approach: Engineering-Integrated Experimentation

Experimentation shouldn’t be a post-development afterthought. It needs to be embedded early in the product definition process. Some mechanisms to consider:

1. Early Dev Spikes for Hypothesis Testing:

   • Dev Spikes are common but often misused—they usually happen after the build decision is already made. Instead, move them upstream into the design and planning phase to test whether a hypothesis is even worth pursuing.

2. Prototyping and A/B Testing Before Commitment:

   • Amazon is famous for its “Working Backwards” approach, where teams write a PRFAQ and prototype ideas before committing resources. Netflix, for example, runs thousands of A/B tests per year, ensuring that only data-backed changes make it to production.

3. Developer-Driven Experimentation (Wacky Thursday, Hack Weeks):

   • Engineering teams often have Wacky Thursday or hackathons to explore innovative ideas. Product should tap into these sessions to validate risky assumptions before formalizing requirements.

4. Customer-Validated MVPs (Not Just Customer Feedback):

   • Eric Ries' Lean Startup methodology emphasizes the importance of testing actual user behavior over stated user preferences3. MVPs should be measured based on engagement, conversion rates, and revenue impact, not just customer feedback.

The Real Goal: Frequent, Quality Releases

Shipping more features doesn’t equate to success. Success comes from shipping frequent, high-quality releases that solve real user problems. A feature that takes six months to develop but isn’t used is infinitely more expensive than an experiment that disproves a bad hypothesis in two weeks.

Instead of blindly following a roadmap, product teams should be asking:

• What assumptions underlie this feature?

• How can we validate them with minimal investment?

• What’s the fastest way to prove (or disprove) our hypothesis?

Jeff Bezos famously said, “Once you have 70% of the data, go.4” The key is ensuring that 70% is based on experiments, not opinions.

Takeaway: Build Experimentation Into the Budget

If teams don’t budget for experimentation, they are budgeting for failure. Early validation ensures that product and engineering efforts are data-driven, minimizing wasted time, money, and frustration.

So, next time you’re pitching a feature, ask: Do we have real evidence that this will work? If not, go run an experiment. Your future self (and your teammates) will thank you.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

Key Takeaways:

1. Plan for Better, Faster, and Cheaper AI: Founders should build with the assumption that AI capabilities will continue improving exponentially. Scaling laws matter more than short-term optimizations.

2. AI Growth Bottlenecks: The three biggest constraints on AI growth: data, algorithms, and compute power. High Bandwidth Memory (HBM) supply is a critical chokepoint, and power availability will soon be the biggest limiting factor.

3. The Inference Wars: NVIDIA dominates training but Groq is leading inference, offering 5x lower cost and 1/3rd the energy per token. The real battlefield is tokens per dollar and tokens per watt, not raw TFLOPs.

4. Datacenters Are Energy, Not Just Real Estate: The AI race isn’t about who has the best chips, but about who controls the power. Inference demand is 20x larger than training, and in 3-4 years, power constraints will slow AI more than chip shortages.

5. AI Business Models Must Optimize for Scale, Not Spend: Startups shouldn’t focus on spending more; they should focus on how much they can scale efficiently. NVIDIA enjoys 70-80% margins, Groq operates at 20% but prioritizes speed and scale.

6. The Big O of Organization scale and hiring: AI startups should scale teams logarithmically, not linearly. If customer growth doubles, you shouldn’t need to double your employees. If you can scale logarithmically, it is a sign that you are doing the right things like automation to scale. Hire generalists and folks that book the win early (i.e. loss bias).

7. China and Europe: China is winning through brute force deployment of compute, but talent that wants to innovate is likely to leave due to government constraints. Europe lacks an AI “Silicon Valley” due to cultural risk aversion—it needs a "Risk-On" enclave to foster AI breakthroughs.

8. The Path to AGI? Solving Hallucinations is critical. Whoever fixes AI hallucinations first will define the industry. Agentic AI (autonomous reasoning systems) comes after this milestone, but hallucination errors must be solved before AI can truly replace high-risk human decision-making.

9. The Economics of AI: More money will be made than incinerated in the long-term. AI is in a Keynesian beauty contest, where marketing and hype matter as much as technology. Most AI startups will fail, but the winners will dominate markets for decades.

10. The Future of AI: The real economic opportunity isn’t in training models but in owning infrastructure, inference, and execution. Prompt engineering will drive the next wave of creativity and business innovation and not constrain extraction of value from AI to just engineers.

The Freight Train vs. The Mopeds

Jonathan Ross might just be a cyborg. Listening to his conversation with Harry Stebbings on VC20 felt like downloading a GPU-accelerated stream of insights on AI, compute economics, and organizational scaling. From Big O notation applied to scaling companies, to Keynesian beauty contests, to the looming bottlenecks in AI infrastructure and the roadmap to AGI. One analogy that stuck with me is that AI compute is like transporting coal across a city using a freight trains versus mopeds.

• If you're using edge computing, you’re essentially moving coal via mopeds—expensive, inefficient, and constrained by individual vehicle capacity.

• If you centralize compute in data centers, you’re running a freight train—economies of scale, lower energy per token, and higher throughput.

• And if you’re NVIDIA, you're monopolizing the railway lines and charging premium freight rates.

The Big O of AI: Scaling Laws and Compute Bottlenecks

Ross highlighted one of the most under-appreciated truths in AI: Founders should build with the mindset that AI will get better, faster, and cheaper. That means thinking in terms of scaling laws, not just short-term optimizations.

Big O Notation in AI Scaling

• The difference between O(log n) vs. O(n^2) is the difference between a company scaling exponentially versus getting buried in inefficiencies.

• GPUs vs. LPUs: Traditional GPUs process AI workloads like O(n^2)—great for brute force, but inefficient at scale. LPUs (Language Processing Units) are designed for O(log n) efficiencies, dramatically improving throughput and cost per token.

The Three Bottlenecks of AI:

1. Compute (Hardware) → Limited supply of High Bandwidth Memory (HBM) from Samsung & Micron.

2. Data (Training & Inference) → Synthetic data is proving more effective than human-generated data.

3. Algorithmic Efficiency → Moore’s Law is slowing, but architectural improvements (like keeping parameters in-chip) are stepping up.

And yet, inference is 20x the market of training. So while NVIDIA dominates training, the real war is happening in inference efficiency.

Training + Inference: NVIDIA and Groq

NVIDIA has a 70-80% margin in AI compute. Groq, in contrast, operates with a 20% margin but makes up for it in speed and cost efficiency:

• Groq’s inference is 5x lower in cost and uses 1/3rd the energy per token.

• 40% of NVIDIA’s profit comes from inference, yet their model isn’t optimized for it.

• Enterprise buyers focus on specsmanship (TFLOPs, FLOPS, etc.), yet what really matters is tokens per dollar and tokens per watt.

This is where business model innovation becomes more important than raw compute power. The limit isn’t how much we can spend, but how we scale our investments.

The Economics of AI: Why Power Is the Next Bottleneck

There is a mismatch in economics across the AI value chain. The amortization schedules and economics vary drastically:

• Training model → 6 months

• Buying chips → 3-5 years

• Buying data centers → 10-15 years

• Power Plans → 15-20 years

Ross pointed out that power is the next major constraint in AI infrastructure:

• 15 gigawatts currently powers all existing data centers.

• An additional 20 gigawatts of power is is needed to be used.

• In 3-4 years, power—not chips—will be the limiting factor.

The solution? Diversifying workloads across generic infrastructure.

• Data centers are not just real estate; they are energy hubs.

• A GPU data center today can be repurposed for EV charging, edge computing, or other workloads.

The AI Talent Equation: How to Scale Without Over-hiring

Ross’s Big O complexity philosophy on hiring is a wake-up call for every founder scaling an AI startup:

• If you double customers, do you need to double employees? Not if you’re scaling correctly.

• Choose Generalists over Specialists at early stages

• Invest in automation over hiring at later stages.

• The worst trap? Over-hiring before you hit PMF (Product-Market Fit).

This is Amazon’s approach to scaling vs. Walmart’s. Amazon doesn’t need to double websites every time revenue doubles. Walmart has to double stores, inventory, and headcount. AI startups need to scale like Amazon, not Walmart.

AI Outside of the US

Two regions stand at critical junctures:

1. China’s Scaling Strategy

   • This is like Sputnik 2.0 for the US

   • China is winning in Distillation of models

   • China may not have chip efficiency, but they have sheer scale. If chips aren’t efficient, they deploy more.

   • Yet, top talent is fleeing China due to regulatory constraints (Jack Ma effect).

2. Europe’s AI Problem: Risk Aversion

   • The biggest barrier to AI innovation in Europe? A culture of risk aversion.

   • Ross’s suggestion? Create enclaves of “Risk-On” founders who think like Silicon Valley.

The Future: AI, Energy, and the Next 20 Years

This isn’t just another AI bubble—though a lot of money will be incinerated, even more will be made.

• Who will define AI? The ones who solve hallucinations first.

• Who will dominate inference? The ones who optimize for tokens per dollar and tokens per watt.

• Where is the next breakthrough? Agentic AI that doesn’t just predict—but invents.

Ross’s closing thought?

“If I knew I couldn’t fail, I’d place 100% of orders for every chip. But scaling AI isn’t about spending—it’s about surviving.”

In the AI arms race, it’s not the best technology that wins—it’s the best execution.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

Subscribe now

References

1. NVidia Scaling Laws White paper: https://arxiv.org/abs/2001.08361

2. 7 Powers (Corned resources): https://7powers.com/

3. LPUs: https://groq.com/wp-content/uploads/2024/07/GroqThoughts_WhatIsALPU-vF.pdf

4. $1.5bn Investment in Groq (Rev share): https://www.prnewswire.com/news-releases/saudi-arabia-announces-1-5-billion-expansion-to-fuel-ai-powered-economy-with-ai-tech-leader-groq-302372643.html

5. Monopsony: https://en.wikipedia.org/wiki/Monopsony

6. Jevons Paradox: https://books.google.com/books?id=gAAKAAAAIAAJ&q=editions:AAotKDT6KKcC&pg=PR3#v=onepage&q=editions%3AAAotKDT6KKcC&f=false

At Amazon, we document everything—tenets, team norms, and our metrics framework (instrumentation)—because culture drives execution. These artifacts define how we work, align teams, and ultimately determine whether we succeed or struggle. Don’t treat this exercise as a checkbox, treat it as the key to your org’s success. These are arguably the most important artifacts you create.

We’re not perfect, yes, we do end up in situations where we do fall into the Scrummer-fall trap (where teams claim to be agile but still follow rigid waterfall processes). However, our results are downstream of the culture.

When these mechanisms are in place, organizations can scale and move fast—deliberately, not chaotically, in a high-speed, low-drag way. Instead of trudging through a bureaucratic, waterfall-esque, sequential workflow, high-performing teams execute in parallel, scaling efficiently without unnecessary bottlenecks and individuals are empowered to unblock themselves.

Culture Is Your Operating System

Every project plan, user story, spreadsheet, Jira ticket, and RAID log? Those are simply tools and a means to an end. But when you’re juggling 10 projects across multiple teams, you can’t afford to micromanage every moving piece. What keeps the machine running smoothly is a shared understanding of how decisions get made.

If you don’t define and reinforce team culture, entropy takes over. I’ve seen teams that neglect this investment—they churn, they struggle, and eventually, they collapse into a death spiral of misalignment and inefficiency. On the other hand, high-performing teams operate with clarity, trust, and autonomy because they consciously invest in an operating framework.

The Four Laws of Combat Applied to Team Culture

Two of my favorite leadership books are Extreme Ownership and The Discipline Equals Freedom Field Manual. They define four laws of combat—principles that directly apply to scaling teams. I like these four laws because they are easy to memorize, universal, and effective. Below are the definitions of the four laws of combat from the books (https://echelonfront.com/what-is-extreme-ownership/) :

• Cover and Move: Teamwork is the key to success. You will fail if you’re not aligned and mutually supporting each other.

• Simple: Leaders tend to overcomplicate their plans and communication, leading to confusion, chaos, and bottlenecks.

• Prioritize and Execute: There’s only so much time and so many resources. Are you utilizing them to their fullest or losing a war of attrition?

• Decentralized Command: Everything you know about leading is wrong. Learn how empowering your people leads to success.

Cover and Move: Scaling Requires Teamwork

Hiring more people is not the key to scaling. Every team member must be onboarded, empowered, contribute, and understand how to make decisions within the framework. If your team relies on a single person to make every call, you’ve already failed. Remember Brent from The Phoenix Project?

Failover is critical, but role clarity matters just as much. Without clear swimlanes, execution suffers. Every player on the field has a critical role to play and executing in that role requires clarity. There are various mechanisms to bring clarity to this including RACI, RASCI, and DACI.

This is where Cover and Move comes in. Great teams operate like special forces units—when one person isn’t available, others step in and execute seamlessly. They don’t wait for permission; they know how to move forward and are empowered to do so because team norms define how work gets done.

Prioritize and Execute: Scaling Requires Trade-offs

Effective prioritization requires clear frameworks for decision-making, stack-ranking, and tie-breakers. Teams must define goals, measure progress, and continuously realign to stay on track. A metrics framework is the basis for your ability to gauge this. For example, you can’t drive a car or fly a plane and get to your destination without an instrumentation panel. You cannot know how to decide what’s next without knowing what your decision-making framework or tenets are. You cannot know how to execute without SOPs.

Delivering results means making trade-offs and continuously prioritizing work to hit your goals. An example implementation of this is the OODA loop (Observe, Orient, Decide and Act) developed by John Boyd. Prioritization frameworks I have used with varying success include: RICE, RITE, WSJF, MoSCow, etc. Document what guides your priorities (metrics framework), how you make trade-offs (tenets), how you prioritize (frameworks), and how you execute (SOPs).

Decentralized Command: Scaling without Bottlenecks

This is the opposite of micromanagement. To move fast, you can’t have managers scrutinizing every decision. This is where Decentralized Command shines. Every team member should understand the mission, constraints, and trade-offs—so they can execute decisively without waiting for approval. This only works when the team:

• Has a shared understanding of priorities

• Knows and contributes to the decision-making framework

• Trusts each other to execute

Without these, you will suffer from the dreaded “analysis paralysis,” where every decision requires an escalation. This is slow, expensive, and completely avoidable.

Keep It Simple: The Antidote to Gold Plating

Complexity is the silent killer of speed. At Amazon, we operate under the Invent and Simplify leadership principle, but I also like Gall’s Law:

"A complex system that works is invariably found to have evolved from a simple system that worked."

Translation? Don’t build castles in the sky or a Rube Goldberg machine for problems that don’t exist. Solve for today’s complexity, not tomorrow’s hypotheticals. Otherwise, you’ll end up over-engineering, gold-plating, and creating unnecessary bloat.

Culture Eats Strategy for Breakfast

Peter Drucker’s famous quote still holds true. “Culture eats strategy for breakfast.” A well-defined culture creates an environment where teams move with speed, autonomy, and purpose.

Culture isn’t just an idea—it’s your team’s operating system. If you don’t document it, expect ambiguity, misalignment, and slow execution. Write it down. Make it clear. Set your team up to win.

Culture isn’t just an idea, but what makes winning repeatable, and not just happenstance. Write it down.

If you enjoyed this, give Culture Flags a read.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

While there are other business novels like “Greatest Salesman in the world” that pre-date this book, The Goal is a landmark book with timeless lessons learned. If you've read The Phoenix Project, you already know the playbook: struggling business, overworked main character, mysterious mentor, and a breakthrough realization that changes everything. But what you may not know is that The Goal by Eli Goldratt is the book that inspired “The Phoenix Project”.

Unlike most business books, The Goal isn’t a technical manual or a list of frameworks. It’s a novel. Yes, a business novel—a rare breed that mixes storytelling with hardcore operational theory. Instead of a dry, terse read - The Goal is easy to follow and goes by quick (for the most part).

Lesson Learned: Work Isn’t Everything

Work-life balance might sound cliché, but its a central lesson I took away from this book. The book is not just about optimizing business processes, but a lesson in reminding us to invest time in your family, loved ones, and personal relationships. We are reminded to not lose sight of why we work in the first place. Alex, nearly wrecks his marriage because he’s too focused on saving his plant. The lesson? Business problems are solvable. Losing your family in the process? That’s harder to fix.

Key Takeaway: You’re only as good as your weakest link

Alex Rogo, the main character, is a factory manager whose plant is failing. Shipments are late, costs are high, and corporate is breathing down his neck. Enter Jonah, a cryptic yet brilliant mentor (think Yoda meets a management consultant). Jonah teaches Alex The Theory of Constraints—the idea that every system has a bottleneck, and that bottleneck determines the speed of the entire process.

It’s like trying to get through TSA at the airport. It doesn’t matter how fast the agents scan passports if there’s only one security lane open. Everyone is stuck until that bottleneck moves faster.

Optimizing non-bottlenecks is a waste of time. If you want to improve performance, identify the constraint and fix that first.

How to Define Your Goal

In operations, the book argues that a business’s primary objective is to make money. To achieve this, you must:

• Measure Precisely: Define metrics with exactness and use a blend of indicators—namely, throughput (the speed of turning raw materials into sales), inventory expense (the cost of held assets), and operational expense (the cost of moving products through the system). These together reflect the health of your “North Star” metric: making money. The aim is to boost throughput while cutting down both inventory and operational costs.

• Understand Variability: Two phenomena govern operations:

  • Statistical Fluctuation: The natural variability in processes (like predicting how many eggs to use for an omelet, with possible breakage or timing differences).

  • Dependent Events: Sequential steps that must occur in a specific order (for example, you can’t pack a product before it’s picked).
    The interplay of these forces determines overall performance.

• Focus on the Bottleneck (Herbie): Identify the system’s weakest link—the “bottleneck” that limits overall performance. Rather than trying to maximize every resource, concentrate on reducing the load on this slowest part to improve overall flow. This concept is illustrated by comparing a slow-moving scout (Herbie) in a troop: the pace of the whole group is determined by the slowest member.

Identify Input Metrics

Alex with the help of his team figures out how to measure if you’re achieving your objective by monitoring three core metrics:

• Throughput – The rate at which you turn raw materials into sales.

• Inventory Expense – The money tied up in goods that aren’t sold yet.

• Operational Expense – The cost of running the business (labor, rent, utilities).

To make money, you need to increase throughput while reducing inventory and operational expense—a seemingly simple rule that businesses ignore.

Alex doesn’t learn these lessons in a boardroom. He figures them out while hiking with his son’s Boy Scout troop (the slowest kid, Herbie, becomes a metaphor for bottlenecks) and applies them through painful, trial and error at the plant.

Actionable Insights

• Capacity and Flow: Ensure that capacity is greater at the end of the production line than at the beginning. Balance should be maintained between the flow of product and customer demand, not merely between capacity and demand.

• Cost Considerations: Evaluate costs in context—an idle bottleneck means the entire plant is effectively idle, magnifying the cost of downtime. Quality control is crucial to prevent defects at the bottleneck.

• Avoiding Local Optimums: Maximizing non-bottleneck resources can lead to inefficiencies and excess inventory. Instead, keep the work flowing in sync with the bottleneck’s pace (often managed with techniques like “drum or rope” scheduling).

• Batch Sizes and Lead Times: Reducing batch sizes, especially for non-bottlenecks, eases cash flow pressures and cuts down lead times, ultimately giving a competitive advantage by responding faster to market needs.

• Continuous Improvement: The book also stresses the need for regular course corrections and a higher-level “thinking process” to identify what needs to change, how to change it, and what the new target state should be—ensuring that even policy and process issues are addressed systematically.

Beyond Plan Management

While The Goal is written as a novel about manufacturing, its principles most likely apply to problems you are dealing with in your day-to-day.

• In tech, your software release cycles are limited by its slowest phase (hint: it’s usually testing, validation, and UAT).

• In labor planning, you’re only as fast as your bottleneck process (e.g. pack, sort, or ship).

• In life, if you're overloaded at work, your bottleneck is probably time. No amount of effort makes up for bad prioritization.

What Works (And What Doesn’t)

✅ It’s Practical. Every manager, entrepreneur, or operations person will find something here that immediately applies to their work.

✅ It’s Engaging. Unlike dry business books, the novel format makes it a fun read.

✅ It Changes How You Think. You’ll start spotting bottlenecks everywhere—at work, in traffic, even in your own daily routine.

❌ It Can be Repetitive. Some conversations feel repetitive, and a few sections could be tightened up and consolidated.

❌ The Theory of Constraints Isn’t a Cure-All. While Alex treats bottlenecks as the ultimate business problem, real-world challenges are often more complex.

Who Should Read This?

• Managers and business leaders looking for practical ways to improve efficiency.

• Operations and supply chain professionals who want a better way to optimize processes.

• Fans of The Phoenix Project who want to read the book that started it all.

Final Verdict: 8/10

The Goal offers a dual message: streamline your operations by focusing on constraints and maintaining precise metrics, and always remember to balance work with the precious time spent with family and loved ones.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

While writing this post I was inspired by one of my favorite quotes from one of my favorite books:

“If you know the way broadly you will see it in everything.”

― Miyamoto Musashi

Why Product Thinking Matters

Product thinking is not a skill just for product managers and product orgs. This skill applies across disciplines whether marketing, sales, devrel, sales engineering, customer support, etc. Do you want to scale something, an org, a function, an initiative, content, a program, etc.? Then think about it like a product. 

I recently spoke with the leader of a community/customer org and it became apparent that they viewed their world as a bunch of activities, content, campaigns, engagements, etc. Product sense and thinking were completely absent and it showed in the chaos and inability to define and prioritize what needed to be done. This is just one example, but it could be anything. Just because it’s marketing or content, doesn’t mean you can’t think of it in terms of it being a product. 

Using Product Thinking

The following pattern should immediately awaken your product sense 👉 you deliver value that is distributed to a consumer and exchanged for some value in return (time, money, eyes, clicks, etc), and needs to be repeatable. When you identify this pattern in what you/your team does and apply product thinking, then you realize your “stuff” (e.g. content, activities, projects) can be treated similarly to "conventional" products (e.g. goods and services). 

When you deconstruct your business and all its moving parts, you can think of it like the Russian doll analogy -> products within products within products. Viewing the world and your deliverables through the lens of being a product will drive scalable, consistent, and lasting outcomes that keep consumers/prospects/end users/customers happy. 

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

Subscribe now

Overview

This is a lesson on mistakes when parenting a 5-year-old and how this applies in the professional world. Mistakes are a good thing and equally important as having success. This is counterintuitive. If you are not making mistakes, you are not trying, building, or participating. Kids (and adults) should be comfortable making mistakes and not feeling embarrassed about them. I can’t begin to tell you how much milk has been spilled in our house by the 5-year-old. You can’t put up guardrails for every little thing. That only leads to sadness, toil, and burnout. You can’t learn without making mistakes along the way.

An Example

You are the senior person on the team. Another teammate is trying, and you know a mistake will happen. This goes against our instincts, but it’s often best to let them make that mistake so they can learn. Controlling too much of a situation and imposing your “experience” might make a difference at the moment but can work against making the team better in the long run. Sometimes sacrificing a little bit of efficiency for the sake of learning is the right thing to do.

Conclusion

Our ego struggles with making mistakes and compels us to want to be right. That can be a good thing however we have to put it in check and allow ourselves to fail. Using Amazon’s “are right, a lot” principle requires one to have “been wrong, a lot”. Increasing your chances of being right requires experience of being wrong and making mistakes.
Are there exceptions? No doubt, for example, if there is a catastrophic event on the horizon, grave consequences, massive blast radius, or if it’s a rare “one-way” decision. This is why environments where you can practice and make mistakes without fear are critical. Seek out a culture and leadership team that fosters these environments. 

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

   Subscribe now

It is okay to not know something

When you don’t recognize this, it is a total killer in your day-to-day and will kneecap you quick fast in an interview. It is common to get stuck on something you’re not an expert on in interviews. This human tendency is insidious in interviews because it’s easy to get sucked into the question and catch tunnel vision. The instinct is to shoulder this all on yourself, but you can catch yourself and detach.

Lean on the team

Rarely will you run into an interviewer who expects you to know everything. The interviewer is likely looking for the moment you recognize you are not an expert in something and how you handle it. This is why teams exist. As you detach, think about the problem/topic/question being posed and who you can lean on to help answer it and get more insight into how to solve the problem. This should be your go-to. Beyond seeking out your team for help, the usual suspects of being resourceful, researching, etc. can help too.

Check your ego

I have learned this the hard way and it takes time to develop this skill, but you can develop it. All the usual techniques of breathing, pausing, etc. work, but the key skill is your ability to quickly identify you’re caught in the trap. You’ll have an easier time knowing you’re in the trap when you start the discussion by checking your ego. A few ways to do this are using some self-deprecating humor, putting a weakness out there early, or admitting to a mistake early on. This is easier said than done. Remember you can practice this and it will help you in interviews and your day-to-day.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

   Subscribe now

Key Concepts

User stories and tasks require “pointing”. “Pointing” is the act of assigning story points to a given unit of work (e.g. user story, tech task). A story point generally represents a “personal day” of work, give or take a few hours. Typically this accounts for 6 hours of work on the sprint tasks/user stories and 2 hours of buffer for interruptions. Story points are assigned based on the assignee’s bandwidth, availability, and environment constraints.

Guidelines

An effective method I have used is the “Modified” Fibonacci for estimating user stories and tasks. The modified Fibonacci sequence is: 0, .05, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Effective and useful estimates start by giving engineering teams clarity by:

• Minimizing uncertainty. Engineers are comfortable giving estimates when there are minimal to no assumptions and clear constraints and requirements. This is a key role the product manager plays in the process.

• Eliminating confusion. As the PM, aim to eliminate overlap and confusion in the requirements and use cases. Be very specific about the requirements and do not leave anything to chance. Follow the thought of the requirement through to completion.

From there, estimates should be based on two principles:

• Quick and Clean - Avoid overanalyzing the estimate once the above are met. Spend minimal time on making the estimate.

• Accurate, not precise - In alignment w/quick and clean, the estimate does not need to be perfect, just accurate. Provide a high and low estimate, and meet somewhere in the middle.

Anti-Pattern to avoid: Overestimating. When given more time than needed, that time will be filled with things like “gold plating” that aren’t necessary to deliver the feature. This doesn’t mean estimating as low as possible and incurring technical debt, but it does mean making estimations lean enough to avoid Parkinson’s Law (https://www.consuunt.com/parkinsons-law/ ).

Resources:

https://www.parabol.co/blog/fibonacci-estimation

https://www.mountaingoatsoftware.com/blog/why-the-fibonacci-sequence-works-well-for-estimating

https://www.lucidchart.com/blog/fibonacci-scale-for-agile-estimation

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

   Subscribe now

TL;DR

If you are in product management, I can’t stress enough the importance of digging deep into the technical decisions with your engineering counterparts as these decisions can have broad implications downstream on the business and your customers.

Guidance

Show up to the architecture review sessions, listen, and provide input specifically on the trade-offs in customer experience and impact on the business. I was fortunate enough to spend a bit of time as an engineer and architect where topics like dependency management, fault tolerance, and scalability of infrastructure are commonplace. These conversations should not be delegated and isolated to engineering. The quality and resiliency of your products (and services) are directly dependent on the systems and infrastructure they are built on. Think through the trade-offs of those design choices with engineering. Avoid getting tunnel vision on any specific aspect of your product and thinking that engineering will take care of all the technical bits. Get involved in these critical decision points.

Example

A common trade-off and decision point that afflicts the hyperscalers is the question of creating a circular dependency. The prime example is this is AWS S3. Do you follow the DRY principle and have every service take a dependency on S3 and introduce a single point of failure? Or do services roll their own? One school of thought is to take the dependency and build a better, more robust, resilient dependency. Another school of thought is to isolate and build those dependencies within your service. The decision comes down to the service you’re building, but 9/10 times I agree with the former, follow DRY, take the dependency, and take advantage of the efficiency gains and economies of scale. Not to mention, your centralized service becomes more resilient over time (gotta love dogfooding) and your overall architecture less complex. In rare instances you can’t follow this path, go with a failover strategy that hedges against the single point of failure and complete isolation. If your shared dependency fails, you can failover to the isolated dependency, albeit this introduces more complexity. Either path significantly impacts your business in terms of cost and customer experience in terms of quality of service.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

   Subscribe now

Introduction

You don't need to sacrifice features for the sake of "Tech Debt". One of your primary roles as a product manager is to be an interpreter. You are the “seer stone” that translates technology outcomes into business outcomes and customer value. “Tech debt” is a prime example of this. I love this topic of “tech debt” because it is often controversial, but it doesn’t have to be. 

What is it?

Engineering teams use this term liberally to describe an area of the code, architecture, or process where a shortcut was taken, has reached critical mass, and needs to be remediated. Why? “Tech debt” is typically incurred because speed and time to market outweigh perfection. You can optimize software performance and implement best practices at a later stage. The rationale is sound; you need customer feedback to iterate on and you don’t need to solve problems you don’t have yet. 

“Tech Debt” vs. Features

There is no need to put “tech debt” at odds with “features”. Tech debt is a sign of maturity. The beauty of software is that it is malleable, we don’t have the same luxury when building hardware products. You can release software that you’re not entirely proud of and will not solve all of the current or future problems your user base faces, but it will solve at least one problem. The heart of building great software is the team’s ability to experiment, test, release, and iterate in short, rapid cycles. Don’t waste cycles contemplating the universe and what potential problems customers may or may not have. Form a hypothesis using the data you have, place a bet on solving that problem, build it, release it, get feedback, and iterate. This is how you optimize software for customers (the demand side) not only your business (the supply side) and avoid analysis paralysis. 

Where does it come from? 

This software delivery model inherently introduces “tech debt” that may or may not need to be addressed in future releases based on customer feedback, that’s the beauty of it. Rather than viewing “tech debt” as a drag on the team, view it as an opportunity to positively impact the scalability of your business and customer experiences. It is an anti-pattern to try and solve all the problems and potential future problems your customers have in a single release. As risky as it seems, we know the best way to build software that customers love is to “move fast and break things”, “big bang” releases are riskier and more error-prone. Smaller, more frequent releases deliver faster and more manageable chunks of feedback that can be introduced into future releases faster. You’re not going to know how to future-proof your software when you build it, so “tech debt” just becomes an inherent component of building software to account for. And rather than framing it as “tech debt”, frame it as improving the overall quality, scalability, security, sustainability, and maintainability of the software you’re shipping. 

What to do about it?

Reframe “tech debt” in your backlog in terms of customer value. Shipping features and addressing “tech debt” is a common tension point between product and engineering cohorts, but it doesn’t need to be. Items labeled as “tech debt” should be framed in terms of customer value (e.g. scalability). For example:

• Engineering Terms: Engineering brings up a “tech debt” scenario of refactoring all of the config data and config processes.

• Product Terms: Frame this to customers in terms of value, e.g. “We can now deploy regions x times faster, with y% fewer errors leading to an increase in z% uptime and security for customers”.  

Additionally, consider these guidelines: 

• When shipping products, communicate tech debt in a manner that demonstrates customer value. 

• Involve product managers in prioritizing “tech debt” alongside features.

• Avoid siloing “Features” as the PM’s job and “tech debt” as engineering’s job

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

   Subscribe now

Introduction

I have had the honor to interview 100s of candidates during my time in tech (including 30+ candidates at Oracle Cloud as a bartender). These have been for various roles ranging from developers to product managers. While each company and candidate varies in their requirements, below are the five key attributes I look for in potential hires that lead to quality outcomes and impact: cultural fit, work ethic, team player, problem solver, and curiosity to learn. 

1️⃣ Cultural Fit

Joining a new team and company is like a marriage. You have to work with these humans day in and day out to get shit done. Companies have anywhere from one to a dozen plus top-down values, but as a candidate, it’s critical to assess the specific ones the team you’re looking to join embraces and match your experience with those. “Cultural fit” is about values, team dynamics, attitude, and personality.

Considerations

• Can you live with them on a daily basis and vice versa?

• Is there a strong alignment between the individual’s and the organization’s values and operating principles?

• For example, if your culture values “bias for action“, do they have a track record of taking initiative? 

2️⃣ Work ethic

The key here is a passion for the problem space, experience, and freedom to solve problems on one's terms. These individuals are eager to dive deep into the problem space and dedicate time to solving problems and delighting customers. This isn’t something that can be turned on and off easily and the problem becomes an obsession. A strong sense of urgency and passion for the mission means no task is too small or too big to take on. “Work ethic” means having a passion for the problem space and the agency to solve those problems without barriers.

Considerations

• Have they spent time working on a problem outside of regular hours?

• Have they taken the initiative to fix an issue or solve a problem without being asked to?

• Have they spent time learning about the company and products on their own?

3️⃣ Team player

Effective teams realize that no single individual’s needs or ego is larger than the mission. Team players are active listeners and open to learning from others and adopting new ideas that aren’t their own. They will break down information silos, share information freely, and do not suffer from “Not invented here” syndrome. They are effective communicators at multiple levels in the organization, demonstrate empathy towards fellow employees, and are interested in developing those relationships.

Considerations

• Are they self-aware of their strengths and weaknesses?

• Can they check their ego and lend a helping hand without the need for credit and because it’s the right thing to do?

• Can they communicate effectively with diverse groups of humans? 

• Do they improve things around them for their “future selves”?

4️⃣ Problem solver

Problem solvers see disorder, chaos, obstacles, and ambiguity as an opportunity to make something better. They are not stuck on one way of getting the job done and avoid using a “golden hammer”. Problem solvers are open to new data, techniques, and ways to get to the heart of the problem. They can utilize both structured and ad-hoc problem-solving techniques when appropriate.

Considerations

• Can they form, test a hypothesis, and draw clear lines from the inputs to outcomes?

• Can they move forward in intimidating, low-data, and high-risk situations?

• Can they apply both structured and unstructured problem-solving techniques where appropriate?

• Do they leave things better than how they found them?

5️⃣ Curiosity to learn

Change is a constant in technology and those that survive not only adapt to it, but welcome change, are eager to learn, and always digging deeper. They are unsatisfied with surface answers and need to understand “why” something is what it is.

Considerations

• Do they demonstrate a deep understanding of users’ needs?

• Are they able to dive deep into data and go into the unknown to solve problems for users?

• What’s the last thing they learned on their own?

• Do they study and learn in their spare time?

Conclusion

These traits are universal characteristics that companies can use to assess interviewees and interviewees can use to assess companies and gauge overall fit. These traits are not fixed in stone and can be developed over time. Subject matter expertise (SME) and domain knowledge are important to getting the job done however, the focus is on traits that transcend domains.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* Please check your junk mail if you cannot find it

Subscribe now

Problem

Gaining stakeholder alignment on an initiative in highly-matrixed organizations with cross-functional coordination is messy and challenging. Each stakeholder has a separate agenda, high-priority items, and metrics they’re tracking. You are not going to make everyone happy.

Key Takeaways

• You need to clearly articulate the trade-offs to make the decision that delivers the most value for customers and impact for the business even if that means sacrificing a requirement.

• Your goal is to find common ground by building consensus and driving alignment across these various stakeholders. This is where using DATA to justify WHY the team’s efforts and resources should be allocated to specific items versus other items is critical.

• It was said somewhere that you can’t argue with the data. In my experience, once you bring both qualitative and quantitative data to the table, people start falling in line and coming to an agreement. Data brings in the dissenters and gives confidence to those on the fence.

• Finally, when you have to sacrifice a requirement and a stakeholder feels left in the dust, make note of it, put it on a roadmap, and communicate with that stakeholder why it got cut and the time horizon to deliver on it.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

   Subscribe now

My observations in tech have shown that these 5 laws present themselves in various, different situations and it helps to be aware of them. These are useful for creating mental models, observing our environment, and to communicate our thoughts more effectively. When thinking about how to map out our world and create a reference point to anchor on for various concepts, knowing these laws will help you and those you work with do that.

Who should read this? You are building products, managing programs and projects, working in a cross-functional organization, are a founder, are in a leadership position, an engineering manager, a product manager, TPM, CTO, or architect.

#1: Gall’s Law

What it is

Gall’s law states “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system. “

When to use it

This is the most effective way to build products and pretty much anything. Build a simple system first, and improve it over time. Don’t overbuild, build to spec to match the requirements you are trying to fulfill now. A simple solution is preferred over a complex one.

For example, if you are just starting on the path to continuous integration and continuous delivery, you do not want to build out your entire rube goldberg machine to fulfill future requirements that solve problems you don’t have yet. Start with the most basic capability like building an artifact from source control, then introduce additional complexity as your requirements dictate.

This doesn’t mean you shouldn’t consider the future, you absolutely should and what your next moves will be. However, customers, markets, and worlds will change and you don’t want to build for a problem you don’t have yet.

#2: Occam’s Razor

What it is

Occam’s razor states: “Entities should not be multiplied beyond necessity” and paraphrased as “the simplest explanation is usually the best one”. This is the classic “Keep it simple stupid” (KISS) principle.

When to use it

When deciding on something or introducing solving a problem, the simplest solution is usually the best one. Don’t overcomplicate and over-engineer what you’re doing and fall victim to analysis paralysis. Pick the simplest solution and run with it.

This ties in closely with Gall’s law above where Gall’s law is stating to match the complexity of the solution with the complexity of the requirements and Occam’s Razor is focused on decisions. Use data to determine what the simplest solution is, eliminate assumptions, and execute it. Test and retest your assumptions throughout the execution process, iterate, and adapt as needed.

#3: Parkinson’s Law

What it is

Parkinson’s Law states the time required to perform a task tends to extend to all the time available to perform it. Its name comes from the man who invented it: Cyril Parkinson.

When to use it

This is a common anti-pattern observed during estimating and leads to overestimating. When given more time than needed, that time will be filled with things like “gold plating” that aren’t necessary to deliver the feature. This doesn’t mean estimating as low as possible and incurring technical debt, but it does mean making estimations lean enough to avoid Parkinson’s Law.

For example, if you are a product manager or engineering manager, you are familiar with the idea of “pointing”. A story point generally represents a “person day” of work give or take a few hours and includes buffer time. Instead of arbitrarily giving buffer time and bloating estimates leading to Parkinson’s law, seek to give engineers and developers confidence by:

• Minimizing uncertainty

• Eliminating confusion

Using a “Modified” Fibonacci for estimating user stories and tasks is one way to help do this. Avoid being too precise and aim for accuracy when estimating. Estimating doesn’t need to be perfect, just accurate. Provide a high and low estimate, and meet somewhere in the middle.

#4: Conway’s Law

What it is

Conway’s law states that “organizations will design systems that copy their communication structure.” E.S. Raymond stated it this way when referring to software engineering: The rule that organization of the software and the organization of the software team will be congruent; originally stated as ‘If you have four groups working on a compiler, you’ll get a 4-pass compiler’.”

When to use it

This is often seen when an organization pushes into too many silos to deliver “products” when there is a “platform” at play. This is commonly seen in hyperscaler cloud providers where teams are aligned vertically to “products”, however, customers use them together in the form of a solution. The implication of this is that sometimes your “platform” can come off looking like a leaky abstraction.

The natural implication here is that if you want your customers to view you as a platform, then organize it as such. If you want your customers to view your products individually and stand alone, then vertical silos may be required. Either way, there are trade-offs in how you manage cross-functional communications, product launches, go-to-market, sales, support, and marketing. This is the common push-pull I’ve observed in companies trying to get the best of both worlds:

• Vertical organization (e.g. hyperscaler clouds): Faster time to market, autonomy, lacks economies of scale and integration into a platform, the field is required to unify the products into a platform for customers, team empowerment

• Layered, integrated organization: Slower time to market, releases in lockstep, better economies of scale, communications, common thread from product to field to customer, and stronger unification in go-to-market

The bottom line is that if you want to present a unified platform to customers, you must change your organization to match your platform vision or suffer from the inefficiencies of cross-functional coordination and risk fragmentation of your products.

#5: Pareto Principle

What it is

Pareto’s principle states that for many outcomes, roughly 80% of consequences come from 20% of causes (the "vital few"). More commonly known as the 80/20 rule.

When to use it

I most recently saw the usage of the 80/20 rule in regard to ARR. 80% of the ARR comes from 20% of the customers. This is a good way to describe your longtail customers as the ones accounting for 20% of revenue. This varies per company, but it is relatively true, especially in enterprise SaaS products. This is a good rule of thumb to apply to a Minimum Viable Product (MVP). You can fulfill 80% of the users’ requirements with just 20% of the functionality.

There are variations of this everywhere. For example, Google has the 70/20/10 rule1. This was a principle that everyone should spend 70% of their time on their core job, 20% as part of another team, and 10% on something blue sky.

Use the 80/20 rule as a heuristic to gauge where you should prioritize and apply your effort. When you understand what your 20% is to get 80% of the benefits, you can focus your efforts on executing that 20% and making it great.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

Subscribe now

Premise

We hear about culture and values in messaging from leadership, but relatively few companies consciously invest in and live out their cultural values at work. It is a “must have” mandated by the board and used as a placeholder to check the box.

It is difficult for leaders and individuals to detach from their day-to-day work, break down, and understand what the organization’s culture is. Organizations that are purely results-driven fail to recognize taking time to identify and assess their cultures is a high-leverage activity. Explicitly devoting time to focus on this activity and incentivizing leaders to do so will lead to better business outcomes and happier employees.

Who is this for?

• You are a leader of an organization and need to understand and shape the culture.

• You are a rank n file employee and want to assess your company culture and how you fit in

• You want to assess the culture of an organization to understand what they value and how they work

Examples of Culture Flags

Your company likely has corporate values, however, those are interpreted and acted upon differently at the local team level. A given organization’s culture has components of both top-down leadership and corporate values combined with the specific values that organically form within those organizations. Identifying what these “culture flags” are that have organically grown up within your organization or team is the first step to improving them.

A “Culture Flag” is a combination of defining what the behavior is and scoring the effectiveness of it leading to better business outcomes, happier employees, and customers. In the examples below, I use the classic “traffic light” coding to assess the health, effectiveness, and influence of these behaviors on an organization: effective (Green), neutral/case-by-case (Yellow), or toxic (Red). Below is a small set of examples meant to illustrate this concept and not a comprehensive list.

• 🟢 [Green] Open and transparent communications. A great culture has open and transparent communication from the top down and across the organization. People should feel empowered to voice their opinions and know their opinions matter. There is no benefit in hiding information and should be the exception, not the rule. High-performing organizations encourage people to communicate and over-communicate utilizing direct, asynchronous, and passive channels.

• 🟡 [Yellow] Land grabs. A potentially troubling sign to identify is if individuals or teams tend to jump on a new project or topic too quickly to “own it”. This can point to the classic “scarcity” mindset. This “scarcity” mindset illustrates the lack of leadership and strategic thinking in the organization.

  The reality is that if you’re working in the tech world you have an “embarrassment of riches” and there are plenty of opportunities to go around. If you don’t get the opportunity you want, move on to the next one and execute.

• 🔴 [Red] Not invented here (NIH) syndrome: A culture that rewards creating everything from scratch is inefficient at best. If employees believe they will be rewarded by reinventing new things that already exist, it will lead to inefficiencies and sour grapes (unhappy employees). The culture should incentivize people to iterate and tweak existing processes, tools, frameworks, and templates that are already being worked on and only go through the invention effort if it is truly necessary and fill a gap. Over 90% of what is in place is “good enough” and teams should be encouraged to take advantage of what’s there.

I recognize that many of these “culture flags” can be the inverse of one another. For instance, “Open and Transparent communications” could very well be “Closed and opaque communications”. Whichever way you choose to word these and structure your assessment is up to you. The key point is that you should structure a model with the purpose of identifying, assessing, and improving your cultural flags.

Conclusion

You can hire an outsider to observe and break down your culture, but they will lack the data and tacit knowledge that the team has. The more effective approach is to consciously take time out of your day-to-day work schedule to detach and focus on what your culture is, its health, and how to improve it. The usefulness of thinking in terms of “culture flags” is two-fold:

• Internal employees can identify and focus on what needs to be improved, removed, or rewarded.

• External parties can assess an organization’s culture and values to see if it aligns with their own.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

   Subscribe now

TL;DR

We tend to bias towards structured problem-solving, however, ad-hoc problem-solving is required in the real world. You need to use both methods to be an effective problem solver. If you are biased towards one or another, learn the other and when to use it.

Key Takeaways

• It isn’t about whether ad-hoc vs. structured problem-solving is better; both are necessary, and neither is right nor wrong. We tend to bias towards a structured method as the only way because it’s logical and defensible when we’re questioned.

• If you are biased towards action and GSD, you might be more of an ad-hoc problem solver. If you are interested in de-risking your situation and ensuring you get it right you might be a more structured problem solver. 

• An ad-hoc problem solver will need to be structured at some point and vice versa. The adage “in the absence of data, take action” lends itself to the ad-hoc method. From there, you can use that data and use the structured method.

• The best problem solvers understand that both approaches are necessary in our complex world. If you’re purely structured, you end up with analysis paralysis, if you’re too ad-hoc, you introduce a greater chance of being wrong. 

Conclusion

Your goal is to be biased for action AND right a lot. In a given moment this seems like a necessary trade-off to make. However, when you understand both are necessary for good problem-solving, you can implement both methods consciously and appropriately.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

   Subscribe now

Overview

Harry speaks w/Douwe Kiela (Founder of contextual.ai) about large-language models (LLMs) and generative AI. They discuss that we are still in the early days of generative AI even though there is a ton of hype in the AI community. There is a huge opportunity for generative AI in the enterprise, however, there are outstanding questions we don’t have the answers to yet that will limit adoption. There are concerns about the role regulations will play in the widespread adoption of generative AI. These systems are achieving the capabilities to do human tasks and will create economic displacement in the next 5-10 years.

Highly recommended for anyone interested in the enterprise market for generative AI https://www.thetwentyminutevc.com/douwe-kiela/

Contextual AI Value Proposition

Contextual AI is decoupling the retrieval from the generative aspects of LLMs. They are targeting B2B AI use cases with contextual language models. Contextual AI differentiates from other “frontier”, general-purpose LLMs (e.g. ChatGPT and Anthropic) by introducing something called retrieval augmented generation. Their goal is to create a cleaner and more loosely coupled architecture that enables companies to adopt generative AI on their terms. Key points on contextual’s architecture:

• Retrieval augmented generation decouples the memory of the LLM from the LLM generation to add and remove attributions on the fly. This enables organizations to train the model and rely on what it finds leading to stronger attribution

• This “grounds” the generations on what has been retrieved, making it more appealing to enterprises for use cases that require greater predictability 

• Their LLM architecture calls for a cleaner separation of the “data plane” from the “model plane” to improve organization concerns and controls on data privacy 

LLM Considerations

There is an argument that “hallucinations” are a feature, not a bug. However, Douwe says there is a spectrum of generated output from LLMs from “grounded” vs. “hallucinations”. For enterprise use cases, the “grounded” side of the spectrum is more appealing. For inspirational and imaginative use cases, the “hallucination” side of the spectrum might be more appealing. Key points on LLMs:

• Douwe argues that the size of the data matters more than the size of the model

• Their research has shown that training a smaller model on more data over a longer period yields better results than using a large model with lots of parameters

• If you have a huge model running on 1000s of GPUs with limited data, the outcome is going to be ok. 

• The LLaMA model was trained on open data. An emerging GPT-4 use case is to use it to generate data for use with cheaper models (e.g. OpenLLaMA)

• Building GPT-4 consists of 3 basic steps: 

  • Starting with pre-trained data

  • Creating the core model

  • Reinforced learning from human feedback, supervised fine-tuning of the model

Generative AI Market

A Google researcher has said OpenAI has “no moat”, but Douwe argues this is incorrect. OpenAI has a giant moat because generative AI is all about the data. OpenAI has a deep understanding of how to use language models, and giant economies of scale, and can serve up models cheaply because of demand. 

LLM Evaluation

The reality is that we don’t know how to evaluate LLMs. There is a huge market opportunity for LLM evaluations and benchmarks. Nothing exists that describes how to evaluate the quality of these LLMs. For instance, GTP-4 looks amazing, but it’s only trained on things it’s being evaluated on, it is not appropriate for the model to evaluate the quality of itself.

• Stanford HELM project is an example of providing a holistic evaluation of LLMs, however, it is too static

• Researchers need to evaluate models by trying to break them

Enterprise adoption

Enterprise adoption is already happening. Adoption is taking place in the enterprise but in small R&D pockets. There will be a tidal wave next year, however, there are lots of hurdles to overcome around data privacy and security. Data contamination and quality are big issues. There are no good tools for data contamination and health checking of models. This is required for enterprise adoption. There are three categories of models, enterprises will gravitate towards mid-size:

• Frontier models: GPT-4 and Anthropic, strong in Artificial General Intelligence (AGI)

• Mid-size models: Less expensive, Artificial specialized intelligence. Most likely what enterprises will use

• bottom tier models: low barrier to entry, anyone can use, Meta gave away OpenLLaMA

Deployment Trade-offs

The architecture and deployment of your generative AI setup require trade-offs to determine where the model plane goes. For instance, if you put it in the VPC, you have privacy but no feedback, and learning is limited. Contextual is solving for this by decoupling retrieval and generative aspects of AI models.

Regulations

Regulations are becoming more prevalent. There are concerns about the existential threat of AI. There is a non-zero chance that AI takes over the world. For example, the paperclip maximizer scenario: Give an intelligent system a command to create paper clips and it will turn the entire universe into paper clips. However, there is a very slim chance this happens. The people pushing to regulate AI are the same ones that will benefit from it. EU will try to over-regulate AI and kill innovation, hope this doesn’t happen in the US. The only ones who benefit from over-regulation are the big incumbents, it potentially crushes startups. 

Conclusion

While enterprise companies are tinkering with generative AI and there are pockets of production deployments, this is a very early market. There are barriers around data privacy, security, compliance, and separation of concerns that still need to be addressed. Companies are resistant to moving highly sensitive data (e.g. transactions) into a model that lives outside of their four walls, and this is where the architecture and deployment models of generative AI need to be reimagined for enterprise use cases and requirements.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the three actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

Share

3. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

Subscribe now

TL;DR

Developers are the engine that runs digital business and the canary in the coal mine that signals what the future health of that business will be. Developers are rapidly becoming overwhelmed with the pace of technology innovation and expectations to do everything from solving the core business problems to securing the applications (e.g. “shift left”) to operating the applications (i.e. “DevOps”, “build it, run it”). This leads to talent churning out and burning out. Reducing churn, and improving developer happiness are quickly becoming top priorities for companies to retain precious talent and achieve their desired business outcomes.

Who is this for?

Anyone concerned with increasing developer satisfaction, acquiring and retaining developer talent. Example roles include: Platform Product Managers, Platform Engineering teams, SRE Leads, Software Engineering Managers and Leaders, Enterprise Architects, and CTOs.

Take these 3 Steps

1. Create a feedback loop to understand developer interests, challenges, blockers, pain, and friction points. 

2. Form developer communit(ies) that open up opportunities for developers to engage, share, and learn from others in an informal setting.

3. Define your developer personas. Avoid treating developers as a monolith and gather data to understand the cohorts of developers in the organization and how to tailor DX to meet their needs.

Problem Statement

This analysis aims to answers the question: 

What steps should I take to start an initiative to improve developer experience?

Technology innovations in cloud, containers, and AI are accelerating and causing organizations to iterate rapidly and do dev spikes to assess how these technologies impact their business. Organizations rely on developers to solve the problem of testing and integrating these technologies into their core digital business that increasingly runs on cloud infrastructure and services. Investing in developer experience (DX) enables companies to react quickly and assess what to do with these technologies through dev spikes and experiments while integrating them into existing and new business models. The pressure on developers to play double duty of maintaining applications on existing technology while delivering new applications on emerging technology can lead to burn-out. The following meme (I found this and cannot take credit) reminded me of this increasingly common problem.

For example, cloud providers increase complexity for developers because they are product-oriented, not solution-oriented. Services are silo’d and consumed a la carte (e.g. storage, database, compute, networking), while developers require a combination of these services to ship code for the business. The onus is on the developer to figure out how to piece these services together just to provide the infrastructure in addition to actually solving the business problem. Adding to this complexity are the myriad of SaaS tools developers use for other services like observability, security, and each individual developer will create their specific, albeit snowflake, formula to solve these infrastructure-centric problems. 

This quagmire is forcing organizations to take a closer look at DX and investing in platform engineering teams to ease the burden and cognitive overload put on developers. Developer productivity is directly related to developer satisfaction and burnout1. But where do you start? There is hype around platform engineering functions, however there are a few steps organizations can take prior to creating this function that will help stop the bleeding and are also strategic in nature.

Improving developer experience (DX) is not just about implementing tools (e.g. IDP phenomenon) and creating a new function (e.g. “platform engineering”) in order to solve for the technical bits. The primary issues to solve for first are the people and process bits. This the actions in the next section focus on how to start making improvements to DX. Future posts will cover the strategy and technology aspects of improving DX.

Action Plan

Conventional wisdom posits you need a strategy before you move to tactics, however a successful strategy requires data and capturing that data requires implementing specific tactics that we dive into in the following sections: Feedback loops, communities, and developer personas. These initial steps are what you will use to capture data as inputs to formulate a strategy that we will discuss in a future post.

Implement a Developer Feedback Loop 

Organizations cannot know what to improve in DX if they do not know what issues their developers face and why. Organizations experience symptoms that are directly and indirectly related to a poor developer experience and unhappy developers, but struggle to make the connection. Direct symptoms include failure to retain talent, slow time to onboard, and burn-out. 

Additionally, one of the biggest challenges engineering leaders and c-level execs face is visibility into the impact developers are having on the business and what is important to them2. They may have a handle on the basic activities, but aren’t aware of how this delivers value for the business. 

Why developer feedback loops important:

• Captures early warning sign that things are wrong

• Feedback loops give platform engineering, product teams, and leadership visibility into the challenges developers face

• Gives developers’ a soapbox to vent and express their concerns

• Creates developer outreach opportunities to engage and understand how to improve DX

How to implement your developer feedback loop:

• Use existing, in-house tools to create your feedback mechanism like slack, surveys, or a no-code tool

• Brand your feedback loop (e.g. “Voice of the Developer”, credit goes to a colleague for this phrase) 

• Communicate the feedback loop’s availability, how to use, why, how it will be used, and expected benefits and impact far and wide

• Dedicate a role to intake, collecting feedback, and summarizing it for leadership to take action

Start a branded program (e.g. “Voice of the Developer”) that targets developers to express common issues they run into. Instead of these issues living in silos, it is expressed publicly for all developers to see and gives others the ability to upvote/downvote the issues. These issues can funnel into the platform engineering or platform PM teams, triaged, stack ranked, and executed on as part of a roadmap.

Start Developer Communit(ies)

The best way to determine what developer’s want is by understanding their daily struggles, what works, and what doesn’t. A community gives developers the opportunity to express themselves outside of formal feedback (albeit corporate/managerial channels). A community solves the problem of developer’s getting questions answered, sharing best practices as well as giving platform engineering teams the data required to build a platform that works for developers. 

A community provides developers with education and outreach, providing resources, tutorials, and documentation to help developers get started with their services. This focus on supporting developers and fostering a strong developer community has been crucial in driving adoption and building trust among developers.

The common denominator for developers is code. Everything comes back to code. The tooling and scaffolding surrounding that code varies, but the goals remain the same: code it, build it, test it, ship it, operate it. Developers are happiest when they have autonomy over the tools they use within their “inner-loop” for coding, debugging, and testing while agnostic to the tools used in the “outer-loop” for team development. The trend is tool selection for developers as part of the “operational loop” for incident response, troubleshooting, and debugging.

Developers struggle to find the right resources, training, and terminology used to address their technical issues. Organizations need to minimize the learning curve for tools and APIs, as developers are primarily focused on delivering results rather than spending excessive time on training. This can be solved with a diverse set of resources like interactive materials and seeking help from local communities when working with unfamiliar technologies. 

Define Developer Personas

Knowing your user, the developer, inside and out is critical to ultimately building a platform and tooling that solves their problems and leads to successful outcomes for the business. When you consider that developers in your organization are your users, focused on accomplishing X outcome, encounter specific pain (and friction) Y that they solve through Z, you can start to understand how they work and what matters to them. This breakdown creates greater segmentation amongst the population of developers that helps prioritize and target features, programs, messaging, and training to specific developer cohorts.

There are plenty of techniques and methods for doing persona analysis (lmgtfy :)), the important part is picking one that works for the team and running with it. Empathy maps are another good technique for this (what do they say, do, feel, see, hear, gols, pains, etc.). These planning and data collection exercises aim to identify developer cohorts, their pain points, and identify common patterns with high impact. These patterns influence your strategy and roadmap to determine what to prioritize and what tactics to employ. Some key components of this exercise should include: 

• Jobs to Be done. Developer Activities and why they matter

• UX studies. Provide valuable insights into improving command line interfaces, API design, and developer experience.

• Developer feelings and sentiment going through these activities. Empathy maps work well here.

• Technology stacks. What tech stacks are in use? What is the momentum and mass of these stacks?

• Geographies and work styles. Where do these developers reside? What are their work habits? Office, remote, hybrid.

• Key blockers and pain points. What are the key blockers inhibiting developers to be successful, and having a positive impact on the organization, and business? 

Conclusion

Improving developer experience and making developers happy requires starting from a baseline of what you know and forming a hypothesis, all of which requires data. First, help developers make their voices heard through feedback loops. Follow this with forming strong, autonomous communities that empower developers to learn, discover ways to remove toil, share best practices and lessons learned, and get up to speed on technology and systems quickly. Finally, use persona analysis to learn who your developers are, what their goals are, what their pain is, what they need to be productive, and increase job satisfaction.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the four actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

   Share

3. Share your feedback on this article.

   Share Feedback

4. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

Subscribe now

Note: This is an article I originally published on Jan. 21st 2021. I find it is still relevant and it made sense to republish in my latest newsletter.

Overview

Once upon a time, there was no Kubernetes, yes, I know that sounds strange now. Four years ago, my conversations with companies revolved around non-production use cases, developer productivity, and optimizing the value streams to production. Even if you extended your use of docker containers into production, it was not through a container orchestrator, but rather deploying the docker runtime onto your existing production servers and updating your deployment runbooks.

Companies would ask me about the value of docker containers and how it could benefit their software development processes and where it fit in their toolchain. The focus was not on runtime characteristics, continuous delivery (or deployment for that matter), but how to reduce the friction of hand-offs between environments and ultimately into production. Furthermore, how to reduce or eliminate configuration drift.

Companies that ignored that phase of the world and are now considering containers and viewing Kubernetes as their starting point. These are often infrastructure and operations teams building out a "home" for developers to deploy their containers. Hold the phone! This is a very risky proposition when no one in the company has started with the first steps in container adoption (see below). You do not go from a baby in your crib to running sprints overnight, the same can be said about the maturity steps and time required for successfully adopting container technologies in your organization.

This is not meant to scare you away from Kubernetes or overcomplicate its usage, but rather provide a pathway to get there one day (but only if necessary). I have seen development teams in small pockets become productive and successful with adopting containers in compressed timeframes, however moving from this scale to enterprise scale is an entirely separate conversation we will save for the future. For now, my goal here is to be explicit on two points:

1. Kubernetes and containers are inextricably intertwined. You need containers to do Kubernetes, however you do not need Kubernetes to do containers.

2. Start with the non-production use cases of docker containers before you start with Kubernetes.

Container Adoption Maturity Stages

Below are the three evolutionary stages for container adoption. Gain confidence and competency at one stage before proceeding. Pause and consider if you achieved the benefits from your investments in one stage before proceeding. In either case, you may decide the time and effort is not worth the continued investment or you do not have the personnel and skillset to proceed further. You may also be using a platform that only requires the basic stage and automates the processes for the intermediate and advanced stages below.

Basic: Developer Workflow and Collaboration

• Go back in time to four years ago. This stage optimizes the “microprocess” or “inner-loop” that makes up the majority of an individual developer’s workflow day-to-day.

• Introduce dockerfiles into your source code. Include a dockerfile in your source code that will be used to build your source code, its system config and dependencies into a container image.

• Introduce a container registry for pushing and pulling container images. Docker Hub, Quay, JFrog Artifactory, Sonatype Nexus, Harbor are popular choices along with the major cloud providers offer.

• Retool developer workstations to include options for building and working with containers. The most common example is Docker Desktop, but there are others like Captain. There are plug-ins for VSCode, Eclipse, and IntelliJ.

• Upskill developer’s competency in docker and containers through training and specific projects and workflows that benefit from using containers.

Benefits:

Reduce friction in hand-offs between environments and enable easier sharing of system config between developers. Eases the barrier to entry for adopting cloud application platforms.

Cautions:

When you do not have issues with configuration management and your workflow is VM-based, this has the potential to introduce undue complexity. However, consider that most cloud application platforms are using containers (OCI-compliant) as the universal packaging format for deployment artifacts.  

Intermediate: Team Development and Static Environments

• This stage optimizes the “macroprocess” or “outer-loop” that team’s (build managers, release managers, testers, product owners, etc) are responsible for day-to-day. This injects containers into the processes spanning source code repositories to deployable artifacts delivered to production.

• Introduce the docker toolchain into Continuous integration and Production use cases.

• Retrofit your build, test, validation, and release environments to host the container runtime and toolchain you have chosen (docker is one example, but podman is another).

• Retrofit your production servers with the container runtime of your choice.

• Instrument your applications and infrastructure to work with containers.

• Upgrade runbooks, security and observability tooling to work with containers.

• Upskill employees through training and other means and working on projects that benefit from this stage for hands-on experience.

Benefits:

Full fidelity of container images from CI server all the way through to production runtime. Reduce or eliminate configuration drift across environments potentially improving troubleshooting and root cause analysis. Further reduce friction in hand-offs between development and operations teams. Potentially improve release velocity.

Cautions:

This is a much larger investment than individual developer machines and therefore requires a stronger business case to fend off disappointed stakeholders. Toolchains can be brittle, and users commonly have strong preferences or best of breed selections in play. However, most of these toolchains are pluggable and continue to evolve to support container-based workflows. It is easy to get distracted by the number of options here, but stay focused on achieving the right technology and business outcomes and using tools you already have in-house where possible.

Advanced: Dynamic Environments, Automation, and Continuous Delivery

• While the previous two stages are primarily focused on improving developer effectiveness and productivity, this stage is focused on automating tasks that operators perform manually and improving the quality-of-service for applications and services.

• At this stage, your company is embracing immutable infrastructure, infrastructure-as-code, deployment automation, and continuous delivery with plans to adopt these practices at a broader enterprise level.

• Introduce Kubernetes and Continuous Delivery for a small subset of applications that can take advantage of the runtime characteristics of Kubernetes and adhere to cloud-native architecture principles.

• Leverage a public cloud service when possible for initial testing and PoCs. As you move to production, consider if you require a hybrid or multi-cloud deployment of your clusters that span multiple clouds and/or on-premises. If you do require more control, flexibility, and portability across infrastructure, leverage a commercial distribution (e.g., VMWare Tanzu or Red Hat OpenShift or a Kubernetes partner).

• Retrofit, select new, or work with incumbent vendors to retool infrastructure for managing Kubernetes clusters. This operational tooling burden is eased when using a public cloud service, however for complex deployments, compliance requirements and more strategic systems with strong business continuity requirements, this is not an option.  

• Upskill employees and work with vendors to climb the Kubernetes learning curve. There are plenty of resources to learn Kubernetes but harvesting best practices and scaling this knowledge across multiple teams in an enterprise is a major change management challenge. Its best not to go at it alone and you should work with a partner or vendor to help you through this significant change.

Benefits:

In addition to the benefits from the basic and intermediate stages, Kubernetes can improve operational capabilities for deployments of distributed applications and services. This includes local high availability, automated deployment, precision service scalability, and automated configuration and policy management at scale. Kubernetes has a vast eco-system which means there is lots of innovation happening you can take advantage of (not just a blessing, but a curse, see cautions below).

Cautions:

The blast radius for this change impacts a broad and diverse set of users and roles in the organization, so change management is tough to get right and is an ongoing process. For many organizations, adopting Kubernetes is one of many parts in a broader cultural shift underway (e.g., project to product, devops, digital transformation). Being successful with Kubernetes at enterprise scale means adopting a culture that is comfortable with automation at the very least.

Introducing Kubernetes increases the complexity for managing both non-production and production environments. You will have to retool all environments to support Kubernetes and reach environment parity. Examples of tools you likely will adopt include helm, minikube, and Prometheus as well as an entire eco-system of tools aimed at improving the usability of Kubernetes and better integrating with or replacing existing operational tooling. The Kubernetes eco-system is vast which means access to innovation, but also includes the pain of overlap, inconsistency, immaturity, room for error, and plenty of options to consider and distill.

Do the guidelines above work in every use case?

Of course not, there is not always a smooth, linear progression in container adoption and there are exceptions to the rules. I have come across companies using Kubernetes in interesting ways that arguably could not be achieved without Kubernetes and did not include requirements related to the first two stages above. That is because Kubernetes is geared towards automation in production use cases with requirements for multi-tenancy, high availability, elasticity, and scaling. In all cases of containers and/or Kubernetes adoption, start with solving a pain point or improving a key metric and tie that solution to a specific business impact and outcome.

My Ask

Thank you for reading this article. I would be very grateful if you complete one or all of the four actions below. Thank you!

1. Like this article by using the ♥︎ button at the top or bottom of this page.

2. Share this article with others.

   Share

3. Share your feedback on this article.

Share Feedback

4. Subscribe to the elastic tier newsletter! *note* please check your junk mail if you cannot find it

Subscribe now