what the warbler knows

The insider intelligence that helps ambitious tech professionals get promoted, poached, or paid properly.

Lost in Translation

Me: "When will the feature be ready?"

Engineer: "It depends."

Me: "On what?" Engineer: "Everything."

This is apparently a complete answer.

Welcome to my life as a non-technical person in tech, where "it depends" is a full explanation and two-week sprints somehow take three weeks.

There's a moment in every non-technical professional's career at a tech company when it happens. You're in a meeting, proposing something important, and an engineer asks: "But how would that actually work?"

The room goes quiet. Your credibility hangs in the balance.

After analyzing engineering handbooks from GitLab and Valve, documentation from Stripe and Discord, and watching too many non-technical leaders successfully navigate technical discussions, a pattern emerges: Technical credibility isn't about learning to code. It's about speaking the language of systems, trade-offs, and constraints.

Here's the playbook that separates PMs who get their features built from those who get politely ignored—and why this same framework determines whether marketing gets engineering support or sales can close technical deals.

The 5 Concepts That Unlock Every Technical Conversation

These five concepts appear in 80% of technical discussions. Master them, and you'll never be lost again.

1. Latency vs. Throughput

Translation: Fast for one vs. fast for many

Think of it like a coffee shop. You can optimize for the fastest single drink (latency) or the most drinks per hour (throughput). Rarely both.

When Figma built their real-time collaboration feature (where multiple people can edit the same design simultaneously), they had to choose: support MORE people in a file but with laggy cursors, or FEWER people with perfectly smooth, instant updates. They chose smooth and instant. That's why when you move your cursor in Figma, your teammates see it immediately—no lag, no jitter. But it also means they limit how many people can edit at once. They prioritized the quality of each person's experience over the quantity of simultaneous users.

Your move: "Should we optimize for individual user experience or total capacity?"

2. State Management

Translation: Does the system have memory?

Stateless = goldfish memory. Every interaction starts fresh. Stateful = elephant memory. Everything is remembered.

On the web, HTTP is stateless by default; applications layer sessions/cookies/state on top. "Chat with memory" is a stateful pattern; many simple searches are effectively stateless requests.

Your move: "Is maintaining state worth the added complexity here?"

3. Synchronous vs. Asynchronous

Translation: Wait in line vs. take a number

Stripe leans on async flows with webhooks—you get an immediate acknowledgment and a later event confirming success/failure. They also document asynchronous capture options for payments. This lets them handle massive volume without making anyone wait.

Your move: "Can we make this async with good UI feedback?"

4. Caching

Translation: Keep a copy nearby

Reddit often obscures or delays visible vote counts (vote fuzzing; some communities temporarily hide counts), so you might not see an upvote reflect right away. It's the classic trade-off: fresh data or fast data, pick one.

Caching speeds reads but complicates freshness. As Phil Karlton quipped: "There are only two hard things in Computer Science: cache invalidation and naming things." (And everyone laughs nervously because it's true.)

Your move: "What's our caching strategy? How stale is acceptable?"

5. Big O Notation

Translation: How badly will this break at scale?

• O(1): Scales perfectly (rare unicorn)

• O(n): Twice the data, twice the time (acceptable)

• O(n²): Twice the data, four times the time (danger zone)

Discord rebuilt their search infrastructure to massively improve indexing throughput and lower latencies at "trillions of messages" scale. Architecture decisions determine whether you'll hit a wall at scale.

Your move: "What's the complexity here? Will this scale linearly?"

The Architecture Patterns That Matter

Monolith vs. Microservices

Monolith: Everything in one place. Simple but eventually unwieldy. Microservices: Separate everything. Complex but scalable.

Microservices shine when you need independent deployability and strong team boundaries (see Conway's Law). They also add distributed-systems complexity, so some teams prefer monoliths for certain cases. Prime Video's team moved a specific monitoring workload from distributed/serverless to monolithic deployment with large cost savings. Shopify has long described their "modular monolith" approach.

How to Contribute Without Coding

1. Frame Problems as Constraints

Don't say: "We need real-time updates" Say: "Users need to see changes within 5 seconds. What are our options?"

2. Ask the Three Magic Questions

• "What are we trading off for that?"

• "How does this fail?"

• "What happens at 10x scale?"

These questions show you understand that engineering is about trade-offs, not perfect solutions.

3. Learn to Read Code (Just a Little)

You don't need to write it. But if you can follow the logic—if/then, loops, variable names—you can have real conversations about implementation. It's like being able to read music without playing an instrument.

Department-Specific Cheat Sheets

Product Managers

Understand data relationships. One-to-many? Many-to-many? New relationships are exponentially harder than reusing existing ones. That "simple" feature might require restructuring your entire database.

Example: Adding "teams" to a product built for individual users isn't just a new database table—it's rethinking every permission, every query, every piece of cached data. When engineers say it'll take months, they're not sandbagging.

Your credibility move: "What existing relationships can we leverage before creating new ones?"

Marketers

Remember those five concepts? They directly impact your campaigns. Client-side analytics can be blocked by ad-blockers and browser tracking prevention—that's 20-30% of your data vanishing. This is a caching problem: your pixel fires (or doesn't), but you don't know until later.

The technical reality: Your attribution is broken because of latency (delayed conversions), state management (cross-device tracking), and async processing (webhooks arriving out of order). When you ask for "real-time dashboard updates," you're actually asking engineers to solve all five technical challenges at once.

Your credibility move: "Should we track this client-side for rich data and accept some loss, or server-side for reliability but less detail?"

Sales

Enterprise integrations are slow because of authentication (OAuth, SAML), compliance (GDPR, SOC2), and bidirectional sync complexity. Every integration is essentially asking engineers to make two different systems—built by different companies, with different assumptions—speak the same language.

The technical reality: That "simple Salesforce sync" involves handling rate limits, retry logic, data transformation, error recovery, and maintaining state between two systems that define "customer" differently.

Your credibility move: "Is this a one-way sync or bidirectional? What happens when the same data is edited in both places?"

Customer Success

You're the detective who helps engineers solve mysteries. The five questions that speed up bug fixes:

1. All users or specific ones? (Helps identify if it's a data issue or system issue)

2. When did it start? (Correlates with deployment timeline)

3. Exact reproduction steps? (Isolates variables)

4. Works in incognito mode? (Rules out caching/cookie issues)

5. Browser/OS details? (Identifies environment-specific problems)

Your credibility move: Create a bug report template with these questions. Engineers will love you forever.

Your Technical Credibility Action Plan

This week:

1. Attend one architecture review. Don't speak, just listen and note which concepts from above appear.

2. Read your company's technical documentation. Yes, it exists. Yes, it's probably in Confluence.

3. Find three engineers whose work impacts yours. Ask them to explain their current challenge in terms of trade-offs.

This month:

1. Create a one-page diagram of your company's tech stack (use StackShare to cheat)

2. Learn to read your product's error logs

3. Join the engineering Slack channels. Lurk responsibly.

The Meta-Lesson

Technical credibility isn't about becoming technical. It's about respecting complexity, speaking in trade-offs, and contributing from your domain expertise.

In a world where AI handles more coding, understanding systems and trade-offs becomes MORE valuable, not less. The engineers who thrive will think like architects. So will everyone else.

Oh, and the next time an engineer tells you "it depends"? Now you know what it depends on.

P.S.: If you're navigating tech without formal power, you need The Influence Map. And if decisions are taking forever at your company, this framework will change everything.

~ Warbler