Overall Summary

Patrick Gleeson's Working with Coders provides a guide for non-technical professionals who need to collaborate with software developers. Product managers, designers, executives, marketers, and others increasingly find themselves working with engineering teams but often struggle to communicate effectively, understand technical constraints, or build productive relationships. This book bridges that gap.

The book's central premise is that working effectively with developers doesn't require becoming technical yourself. Instead, it requires understanding how developers think, what they care about, how software development actually works, and how to communicate in ways that enable collaboration. These are learnable skills that dramatically improve working relationships.

Gleeson writes from experience on both sides of the divide. As someone who learned to code after years in non-technical roles, he understands the confusion and frustration non-technical people experience when working with developers. He also understands the developer perspective that often seems opaque to outsiders. This dual fluency enables him to translate between worlds.

The book is practical rather than theoretical. Gleeson focuses on situations readers actually encounter: explaining requirements, understanding estimates, navigating technical decisions, handling disagreements, and building trust over time. Each chapter addresses real challenges with actionable guidance.

Throughout, Gleeson maintains respect for both sides. He doesn't portray developers as difficult or non-technical people as clueless. Instead, he shows how different contexts, incentives, and communication styles create misunderstandings that better approaches can resolve. The goal is genuine collaboration, not manipulation or mere tolerance.

The book serves anyone who works with developers but lacks technical background. It's particularly valuable for product managers, project managers, and business stakeholders who interact with engineering teams regularly. Even readers with some technical knowledge often find gaps in their understanding of how developers think and work that this book addresses.

High-Level Overview: Key Arguments and Goals

Understanding Developer Mindset: Developers approach problems differently than non-technical professionals. Understanding their priorities, frustrations, and working styles enables much more effective collaboration. This understanding doesn't require technical knowledge, just curiosity and attention.

Communication Across the Divide: Many collaboration failures stem from communication problems rather than technical disagreements. Learning how to explain requirements clearly, ask good questions, and interpret technical responses prevents misunderstandings that derail projects.

Respecting Technical Constraints: Software development involves real constraints that non-technical people often don't see. Treating these constraints as legitimate rather than excuses for laziness builds trust and produces better outcomes.

Managing Without Controlling: Non-technical collaborators can't evaluate technical decisions on technical merits. This requires different management approaches based on trust, clear outcomes, and appropriate oversight rather than detailed direction.

Building Productive Relationships: Long-term success depends on relationships built through many interactions. Investing in these relationships pays dividends across projects and careers.

Bridging Organizational Cultures: Technical and non-technical teams often have different cultures, values, and working styles. Successful collaboration requires bridging these differences rather than expecting one side to fully adopt the other's approach.

Part I: Understanding Developers

Who Developers Are

Gleeson begins by humanizing developers for readers who may view them as mysterious or intimidating. Developers are professionals with skills, perspectives, and concerns like any other professionals. They're not a different species, even if they sometimes seem to speak a different language.

The developer population is diverse. Some are highly social; others prefer solitary work. Some care deeply about user experience; others focus primarily on technical elegance. Some communicate clearly; others struggle to explain their work. Stereotypes about developers often mislead.

What developers share is training in systematic problem-solving. Programming requires breaking complex problems into precise steps, handling edge cases, and thinking through implications. This training shapes how developers approach not just code but all problems, sometimes in ways that frustrate non-technical collaborators who think differently.

What Developers Care About

Understanding developer motivations helps non-technical collaborators work with them more effectively.

Craft and quality matter to most developers. They take pride in well-written code and feel frustrated when pressured to produce work they consider substandard. This isn't perfectionism for its own sake; quality code is easier to maintain, extend, and debug. When developers resist cutting corners, they're often protecting future productivity.

Interesting problems engage developers more than routine tasks. Given a choice, most developers prefer challenging work that stretches their abilities. This preference can create tension with business needs that sometimes require boring but necessary work.

Autonomy is highly valued. Developers generally want to determine how to solve problems rather than being told exactly what to build. Micromanagement that removes autonomy demotivates developers and often produces worse results than trusting their judgment.

Recognition for good work matters, though developers may not seek it overtly. Acknowledging technical achievements, even when non-technical people can't fully evaluate them, builds goodwill.

How Developers Think

Developers are trained to think precisely. Programming languages require exact syntax; computers do exactly what they're told, not what programmers meant. This precision training affects how developers communicate and what they expect from communication.

Ambiguity that non-technical people tolerate often frustrates developers. When requirements are vague, developers must make assumptions that may not match intent. They often ask clarifying questions that seem excessive but reflect genuine need for precision.

Developers think in systems. They consider how components interact, how changes propagate, and how edge cases affect behavior. This systems thinking helps them anticipate problems but can make them seem negative when they raise concerns others haven't considered.

Developers also think about future implications. Code written today must be maintained tomorrow. Shortcuts that save time now often cost much more time later. When developers advocate for approaches that seem slower, they're often considering maintenance burdens that non-technical people don't see.

Part II: How Software Development Works

The Development Process

Non-technical collaborators benefit from understanding how software actually gets built. This knowledge helps set realistic expectations and enables more productive conversations.

Software development typically involves requirements gathering (understanding what to build), design (determining how to build it), implementation (actually writing code), testing (verifying it works), and deployment (releasing it to users). These phases overlap and iterate rather than flowing strictly sequentially.

Different methodologies organize this work differently. Waterfall approaches complete each phase before starting the next. Agile approaches work in short cycles that include all phases. Understanding which methodology a team uses helps non-technical collaborators engage appropriately.

Regardless of methodology, software development is inherently uncertain. Unexpected complications arise. Requirements change. Technologies don't work as expected. Plans that seem solid frequently require adjustment. This uncertainty isn't a sign of poor planning; it's intrinsic to building things that haven't been built before.

Why Software Development Takes Time

One of the most common frustrations for non-technical people is that software takes longer than expected. Gleeson explains why this happens.

Hidden complexity lurks beneath simple-seeming features. "Add a login" sounds straightforward but involves password security, account recovery, session management, error handling, and numerous edge cases. What looks like one feature is actually dozens of interconnected features.

Existing systems constrain new development. Code rarely starts from scratch; it must integrate with existing systems that have their own quirks and limitations. Working within these constraints takes time that greenfield development wouldn't require.

Quality requirements add effort. Code that merely works differs from code that works reliably, handles errors gracefully, performs efficiently, and can be maintained by others. These quality dimensions require additional effort that's invisible in the final product.

Testing and debugging consume substantial time. Writing code is only part of development. Verifying it works correctly and fixing problems when it doesn't often take as long as initial implementation.

Technical Debt

Gleeson introduces technical debt as a concept non-technical collaborators should understand. Technical debt accumulates when teams take shortcuts that make future work harder. Like financial debt, it enables faster progress now but requires repayment later with interest.

Some technical debt is strategic. Taking shortcuts to meet a critical deadline may be the right tradeoff. But debt must eventually be addressed, and the longer it remains, the more it costs to fix.

Non-technical collaborators who understand technical debt can have better conversations about tradeoffs. When developers say something will take longer because they need to address technical debt, this isn't an excuse; it's an investment in future productivity.

Ignoring technical debt leads to systems that become increasingly difficult to change. Features that once took days eventually take weeks. Innovation becomes impossible because all effort goes to maintaining fragile systems. Understanding this dynamic helps non-technical people appreciate why developers sometimes advocate for work that doesn't produce visible features.

Part III: Communicating with Developers

Explaining What You Want

Clear requirements are essential for successful development. Gleeson provides guidance for non-technical people who need to explain what they want built.

Focus on outcomes rather than implementation. Describe what users should be able to accomplish, not how the software should work internally. "Users need to find products by category" is better than "Add a dropdown menu with categories." Outcome-focused requirements give developers room to propose solutions non-technical people might not imagine.

Provide context. Explain why features matter, who will use them, and how they fit into larger goals. Developers who understand context make better decisions when facing tradeoffs or ambiguities.

Be specific where it matters. Vague requirements force developers to guess. When specifics matter, provide them. When flexibility is acceptable, say so explicitly.

Use examples. Concrete examples often communicate more clearly than abstract descriptions. "Like how Amazon shows related products" conveys more than lengthy explanation.

Acknowledge uncertainty. If you're not sure what you want, say so. Developers can help explore options if they know exploration is expected. Pretending certainty when you're uncertain creates problems when requirements inevitably change.

Asking Questions

Non-technical collaborators often need to ask developers questions. Asking effectively gets better answers and builds better relationships.

Ask open questions. "How does this work?" invites explanation. "Does this work like X?" invites yes or no. Open questions get more information and help developers share what they think is important.

Admit what you don't know. Pretending to understand when you don't leads to miscommunication. Most developers respect honest acknowledgment of limited technical knowledge and will explain more clearly when they know it's needed.

Ask about implications. "What would happen if we changed X?" helps developers share their systems thinking. These questions often reveal considerations non-technical people wouldn't have imagined.

Ask about tradeoffs. "What are we giving up with this approach?" surfaces concerns developers might not volunteer. Understanding tradeoffs enables better decisions.

Don't ask gotcha questions. Questions designed to catch developers out damage trust. Ask to understand, not to test or trap.

Understanding Answers

Developer responses sometimes confuse non-technical collaborators. Gleeson helps decode common patterns.

Technical explanations may include jargon that obscures meaning. It's appropriate to ask for clarification in non-technical terms. Most developers can explain concepts simply when they know it's needed.

"It depends" is often an honest answer, not evasion. Many questions genuinely have different answers depending on circumstances. Follow-up questions about what it depends on usually get useful information.

Estimates with caveats reflect genuine uncertainty, not lack of commitment. When developers say "probably two weeks, but it could be longer if we hit problems with X," they're being honest about risks. Stripping caveats from estimates creates false precision that leads to disappointment.

Concerns about approaches may sound like obstruction but often reflect legitimate technical judgment. When developers push back on proposed solutions, they usually have reasons worth understanding.

Part IV: Managing Technical Work

Estimation and Planning

Non-technical collaborators often need to plan around technical work without being able to evaluate it directly. This creates challenges Gleeson addresses.

Estimates are uncertain. Software estimation is notoriously difficult because every project involves novel elements. Treating estimates as commitments rather than projections creates problems when reality differs from predictions.

Estimate ranges communicate uncertainty more honestly than point estimates. "Two to four weeks" acknowledges uncertainty that "three weeks" obscures. Non-technical collaborators should request and respect ranges.

Breaking work into smaller pieces improves estimation accuracy. Large estimates are less reliable than small ones. Asking developers to decompose work helps identify hidden complexity and produces better predictions.

Tracking actual versus estimated over time reveals patterns. Some developers consistently underestimate; others overestimate. Some types of work vary more than others. Historical data helps calibrate future planning.

Buffer for unknowns acknowledges that surprises happen. Planning that assumes everything goes perfectly fails when anything goes wrong. Building buffer into plans provides resilience.

Making Decisions

Non-technical collaborators must sometimes make decisions about technical matters they can't fully evaluate. Gleeson provides approaches for these situations.

Focus on outcomes. You may not be able to evaluate technical approaches, but you can evaluate whether outcomes meet needs. Define success criteria clearly, then assess results against them.

Trust with verification. When you can't evaluate decisions directly, trust developers' judgment while verifying results. This differs from blind trust (no verification) or distrust (constant second-guessing).

Seek multiple perspectives. For significant decisions, getting input from multiple developers reveals whether there's consensus or disagreement. Consensus increases confidence; disagreement suggests deeper investigation.

Understand tradeoffs. Ask developers to explain what different approaches gain and sacrifice. Even without technical expertise, you can evaluate tradeoffs against priorities.

Escalate appropriately. Some decisions warrant additional expertise. For critical or irreversible technical decisions, bringing in senior technical people or outside experts may be appropriate.

Handling Disagreements

Disagreements between technical and non-technical collaborators are inevitable. Gleeson provides guidance for navigating them productively.

Separate what from how. Non-technical collaborators typically have more standing on what should be built (requirements) than on how it should be built (implementation). Recognize where your expertise applies and where developers' expertise should prevail.

Seek to understand before seeking to be understood. When developers disagree with proposed approaches, understanding their reasoning often reveals legitimate concerns. They may also misunderstand requirements in ways that explanation can address.

Find underlying interests. Disagreements often persist because both sides argue positions rather than exploring underlying interests. Understanding what each party actually needs often reveals solutions that satisfy everyone.

Escalate constructively. When disagreements can't be resolved directly, escalation to managers or executives may be necessary. Present the disagreement fairly, acknowledging both perspectives, rather than positioning for victory.

Part V: Building Relationships

Trust and Respect

Long-term success depends on relationships built through many interactions. Trust and respect form the foundation.

Deliver on commitments. When you say you'll do something, do it. Reliability builds trust; broken promises destroy it. If circumstances change, communicate proactively rather than simply failing to deliver.

Respect expertise. Developers have spent years developing skills. Treating their expertise as valuable, even when you can't fully evaluate it, shows respect that developers appreciate and reciprocate.

Admit mistakes. When you're wrong, acknowledge it. Defensiveness damages relationships; accountability builds them. Everyone makes mistakes; how you handle them matters more.

Give credit. When projects succeed, acknowledge developer contributions. Credit that flows only to non-technical people while developers do invisible work creates resentment.

Protect developers' time. Unnecessary meetings, constant interruptions, and ever-changing priorities waste developers' time and signal disrespect. Being thoughtful about demands on their time shows consideration.

Day-to-Day Interactions

Relationships build through accumulated small interactions. Gleeson provides guidance for daily collaboration.

Be available but not intrusive. Developers need focus time for complex work. Being available when they have questions while not constantly interrupting balances accessibility with respect for concentration.

Keep communication channels clear. Understand how developers prefer to communicate (email, chat, meetings) and use appropriate channels. Urgent matters may warrant interruption; non-urgent matters should use asynchronous channels.

Follow up on conversations. When you discuss something, follow up later. This shows you were listening and care about outcomes. Conversations that disappear into silence signal that the interaction didn't matter.

Celebrate successes. When things go well, acknowledge it. Positive feedback reinforces good patterns and builds relationship goodwill.

Handle problems privately. When things go wrong, address issues privately rather than publicly. Public criticism embarrasses and alienates; private conversation preserves dignity while addressing problems.

Navigating Organizational Dynamics

Developers and non-technical collaborators often exist in different organizational contexts with different cultures and incentives. Navigating these differences requires awareness.

Understand engineering culture. Engineering teams often have distinct values, norms, and communication styles. Observing and adapting to these cultural elements eases collaboration.

Recognize incentive differences. Developers may be evaluated on different criteria than non-technical roles. Understanding what developers' incentives reward helps predict behavior and find alignment.

Bridge silos. Organizational structures often separate technical and non-technical teams in ways that impede collaboration. Individual relationships can bridge these silos even when organizational structures don't.

Advocate for developers. When developers face organizational challenges, non-technical collaborators who advocate for them build loyalty that improves collaboration. Standing up for developers when they're not in the room demonstrates genuine partnership.

Part VI: Common Challenges

Scope Creep

Requirements that expand continuously create one of the most common project problems. Gleeson addresses how non-technical collaborators contribute to and can prevent scope creep.

Scope creep often happens gradually. Each addition seems small, but cumulative additions overwhelm original plans. Non-technical collaborators must recognize when "just one more thing" has become a pattern.

Preventing scope creep requires discipline about prioritization. Not every good idea belongs in the current release. Maintaining focus on core requirements while deferring enhancements preserves project viability.

When scope must expand, acknowledging the impact shows respect for developers. Pretending additions are trivial when they're not damages trust. Honest conversation about tradeoffs (extend timeline, cut other features, accept lower quality) enables informed decisions.

Changing Requirements

Requirements change for legitimate reasons: markets shift, users provide feedback, business priorities evolve. But constant changes frustrate developers and undermine productivity.

Minimizing unnecessary changes respects developer investment. When requirements change, previous work may be wasted. Thoughtful requirements upfront reduce wasteful churn.

When changes are necessary, explaining why helps developers accept them. Changes that seem arbitrary breed frustration; changes with clear rationale are easier to accept.

Timing changes appropriately reduces disruption. Changes early in development cost less than changes late. Batching changes rather than trickling them continuously enables more efficient adaptation.

Unrealistic Expectations

Non-technical collaborators sometimes have expectations that can't be met. Gleeson addresses how to recognize and handle these situations.

Unrealistic expectations often stem from misunderstanding how software works. What seems simple from outside may be complex inside. Education about software development helps calibrate expectations.

Developers sometimes agree to unrealistic expectations rather than pushing back. This avoids immediate conflict but creates larger problems when expectations aren't met. Non-technical collaborators who create safety for honest assessment get more accurate information.

When expectations and reality conflict, something must give. Either scope reduces, timeline extends, quality decreases, or more resources apply. There are no other options. Understanding this constraint helps non-technical collaborators engage tradeoff conversations productively.

Communication Breakdown

Communication failures create many project problems. Gleeson identifies common patterns and remedies.

Assumptions substitute for communication. Both sides assume the other understands things that were never discussed. Explicit communication about requirements, constraints, and expectations prevents assumption-based failures.

Different vocabularies create confusion. The same words mean different things to technical and non-technical people. Clarifying terminology and checking understanding reduces vocabulary-driven miscommunication.

Information silos keep relevant information from reaching those who need it. Proactive information sharing and regular check-ins surface issues before they become crises.

Fear of asking questions leaves confusion unaddressed. Creating environments where questions are welcomed rather than judged encourages the communication that prevents problems.

Part VII: Growing Your Understanding

Learning About Technology

While deep technical knowledge isn't necessary, some technical understanding helps non-technical collaborators work more effectively with developers.

Conceptual understanding of how software works improves communication. Understanding roughly what databases, APIs, front-ends, and back-ends do enables more productive conversations even without implementation knowledge.

Familiarity with developer tools helps non-technical collaborators participate in processes. Understanding what version control, issue trackers, and deployment pipelines do (not how to use them technically) provides useful context.

Industry awareness about technology trends helps non-technical collaborators understand developer perspectives. Reading technology news and observing what developers discuss reveals what matters in their world.

Gleeson cautions against superficial knowledge used to micromanage. A little technical knowledge can be dangerous if it leads non-technical collaborators to second-guess developer decisions they don't actually understand. Learning should increase collaboration, not enable interference.

Learning from Developers

Developers themselves are excellent resources for non-technical collaborators seeking to understand technology better.

Ask developers to explain things you don't understand. Most developers enjoy teaching and appreciate interest in their work. Genuine curiosity builds relationships while building knowledge.

Attend technical discussions even when you don't understand everything. Exposure builds familiarity over time. You'll gradually understand more, and your presence signals interest in developers' work.

Request debriefs after projects complete. Understanding what went well, what didn't, and what was learned provides insight into how development actually works.

Read what developers write. Documentation, technical blogs, and code comments reveal how developers think and communicate. This exposure builds understanding even without technical implementation knowledge.

Continuous Improvement

Working effectively with developers is an ongoing skill that improves with attention and practice.

Reflect on interactions. What went well? What could improve? Regular reflection converts experience into learning.

Seek feedback. Ask developers how you could collaborate better. Their perspective reveals blind spots self-assessment misses.

Observe others. Notice how effective non-technical collaborators work with developers. What do they do differently? Learning from others accelerates improvement.

Stay curious. Technology evolves constantly. Maintaining curiosity about changes keeps your understanding current and signals ongoing interest to developers.

Conclusion: Partnership, Not Translation

Working with Coders concludes by reframing the goal of non-technical collaboration with developers. The aim isn't merely to translate between worlds or to manage developers effectively. It's to build genuine partnerships where both sides contribute their expertise toward shared goals.

This partnership model requires mutual respect. Non-technical collaborators respect developer expertise even when they can't fully evaluate it. Developers respect business, user, and design expertise that non-technical collaborators bring. Neither side has all the answers; combining perspectives produces better outcomes than either achieves alone.

Partnership also requires shared ownership. When projects succeed, everyone succeeds. When they fail, everyone fails. This shared stake motivates collaboration rather than blame-shifting.

Gleeson acknowledges that building these partnerships takes effort. Different backgrounds, vocabularies, and working styles create friction. Organizational structures sometimes work against collaboration. But the effort pays dividends in better products, smoother projects, and more satisfying work for everyone involved.

The final message is encouraging. Working effectively with developers doesn't require becoming technical. It requires empathy, communication skills, and genuine respect for another discipline's expertise. These are capabilities anyone can develop with attention and practice. Non-technical collaborators who invest in these capabilities find that working with developers becomes not just tolerable but genuinely rewarding.