Engineering Management Without Being an Engineer

Engineering Management Without Being an Engineer

You do not need to be able to write code to manage engineers effectively. What you need is a clear mental model of how technical work gets done, a process that creates accountability without micromanagement, and enough technical vocabulary to have honest conversations about risk and trade-offs.

The Non-Technical Founder's Biggest Mistake

The most common mistake non-technical founders make with engineering teams is swinging between two extremes: over-specifying (telling developers exactly how to build something, which wastes their expertise and creates resentment) and under-specifying (saying "build me a feature like Instagram Stories" and wondering why what comes back is not what they pictured).

The right operating mode is to own the what and the why, and let the engineers own the how.

• What: The user behavior the feature enables or the problem it solves
• Why: The business or user outcome you expect the feature to produce
• How: The technical implementation — architecture, libraries, algorithms. This is the engineer's domain.

Running Sprints Without Becoming a Scrum Master

You do not need Jira, a dedicated scrum master, or daily standups that last 40 minutes. You need three things:

1. A weekly prioritization meeting (30 minutes). At the start of each week, review what was completed, identify what carried over and why, and set the priority for the next 5 days. Keep this to 30 minutes. If it takes longer, the work is not defined clearly enough.

2. Written tickets with acceptance criteria. Every piece of work should exist as a written task with three fields: what to build, why it matters, and what "done" looks like. "Done" is the most important field. If developers have to guess what done looks like, reviews create conflict.

3. A weekly demo. Friday afternoons, developers show what shipped. This is not a status meeting — it is a proof-of-work ritual that creates pride in shipping and surfaces issues before they accumulate.

Technical Debt Conversations You Need to Be Able to Have

As a non-technical CEO, you will regularly hear: "We need to refactor this before we can add that feature." You need to be able to evaluate this claim without dismissing it (which kills developer trust) or accepting it uncritically (which lets technical debt become a veto over every roadmap decision).

Questions to ask:

• "What specifically breaks or slows down if we build the new feature on the existing code?" (Concrete risk assessment)
• "How long does the refactor take versus how long does it slow down each future feature if we don't do it?" (ROI framing)
• "Is this a refactor we can do incrementally while shipping features, or does it require a freeze?" (Risk to delivery)

A developer who can answer these questions clearly and concretely is managing technical debt responsibly. One who says "it's just messy and needs to be fixed" without specific consequences is expressing preference, not business risk.

Hiring vs. Outsourcing

The framework for this decision:

Outsource (contractor/agency) when:

• The work is bounded and well-defined (build this feature, fix this bug)
• The work is outside your core product (mobile app, landing page, integration)
• You need specialized expertise for a short period

Hire (employee or long-term contractor) when:

• The work touches the core product that differentiates you
• You need someone who holds context across months, not weeks
• The work requires iteration — shipping, learning, adjusting — not just delivery

A common mistake: hiring a contractor to build the core product. Contractors ship and leave. When something breaks 6 months later or a new feature needs to build on that code, no one who understands it is available. Core product work requires continuity.

Where to Find Developers in the Caribbean and Diaspora

This is a real operational challenge in Jamaica and the region. Channels that work:

• University partnerships: UWI, UTech, and NCU produce CS graduates who are often looking for their first serious role
• Caribbean tech communities: Caribbean Developer Community, Tech Beach Retreat network, Facebook groups like Jamaican Developers
• Diaspora outreach: Jamaican and Caribbean developers in the US, Canada, and UK often want remote-work arrangements with Caribbean companies
• Upwork/Toptal/Contra: For specific scoped work, these platforms have reliable contractor pipelines

Vet developers on three things: past work (GitHub, live projects), how they communicate async (because remote work is communication-dependent), and how they respond to ambiguity — because good developers can operate with imperfect information.