A leader who can read a pull request and run a database query is harder to bluff and easier to follow. Not because they out-code the engineers, they never will, but because they can tell a real constraint from a polite excuse, and because they can answer their own data questions without queuing behind an analyst.

The quick version

  • Literacy is reading, not writing. The valuable skill for a leader is following what code and queries do and why, not authoring them. Reading is a far smaller investment than writing, and it pays off faster.
  • If you learn one language, learn SQL. It is how you ask a database a question. It is declarative, you say what you want, not how to fetch it, so it is unusually learnable for a non-programmer, and it answers business questions directly.
  • Code is written for humans to read. Good engineers optimise for the next person, not the machine. That is the standard you are allowed to expect, and the lens through which you read.
  • The risk is overconfidence. A little literacy can tip into meddling. The goal is sharper questions and self-service answers, not overruling people who do this full time.

The idea in depth

Start with the distinction that does the most work: reading versus writing. The two are routinely conflated, which is why "I should learn to code" so often ends in a half-finished tutorial and a quiet sense of failure. You are not trying to ship features. You are trying to understand them well enough to lead. Reading a change, tracing what it touches, and asking why it was done this way is a much smaller skill than building it from scratch, and it is the one that changes how a meeting goes.

There is a respected idea underneath this. In 1984 Donald Knuth published "Literate Programming" (The Computer Journal, 27(2):97–111), arguing that we should "concentrate rather on explaining to human beings what we want the computer to do" instead of merely instructing the machine. The same conviction runs through the practitioner canon, Hunt and Thomas's The Pragmatic Programmer (1999) treats clarity and plain expression as a craft obligation, not a nicety. So hold code to that standard, out loud. When an engineer walks you through a change and you cannot follow the shape of it, the honest response is not "I'm not technical", it is "explain this to me the way you'd explain it to a new joiner." If it stays opaque after that, the problem is often the code, not you.

A caveat, because it matters: literate, readable code is an ideal, not a guarantee. Plenty of correct, valuable software is dense, legacy, or written at 2am against a deadline, and not every confusing patch is a red flag. Read it for the questions it raises, not as a verdict on the author. The point is to know what to ask next, not to grade your engineers on their prose.

Why SQL is the language to learn first

If a leader picks exactly one technical skill to acquire, the highest-return choice is usually SQL, the language for asking a database questions. The reason is structural. Most other languages tell the computer how to do something step by step. SQL is declarative: you describe the result you want, "active customers in Europe who bought twice last quarter", and the database works out how to fetch it. That is why a non-programmer can become genuinely useful in SQL far faster than in, say, Python, and why the questions it answers are the ones leaders actually have.

SQL rests on a piece of real intellectual history. In June 1970, IBM researcher Edgar F. Codd published "A Relational Model of Data for Large Shared Data Banks" (Communications of the ACM, 13(6):377–387), proposing that data live in simple tables of rows and columns that relate to one another, so a user could pull a fresh answer from one or more tables with a single query. That model became the foundation of the relational databases nearly every company runs on, and SQL is the language that speaks to it. Learning SQL is not learning a passing tool; it is learning the half-century-old grammar of how organisations store what they know.

SQL lets you say what you want, not how to get it, which is exactly why a non-programmer can learn it.

So make your next data question one you answer yourself. Five verbs do most of the work, SELECT (which columns), FROM (which table), WHERE (which rows), GROUP BY (roll up into buckets), ORDER BY (sort the result). Ask your data team for read-only access to a reporting copy and a few example queries; within a week you can answer "how many sign-ups by week this quarter?" without filing a ticket. The catch: a real production database is a minefield of joins, edge cases and half-documented columns, and a query that looks right can quietly be wrong. Treat your early queries as questions to check with an analyst, not as numbers to put in a board pack.

flowchart TD
  A(["You have a question:
how many sign-ups per week?"]) --> B{"Can you read SQL?"}
  B -->|"No"| C(["File a ticket,
wait in the analyst queue"])
  B -->|"Yes"| D(["Write a SELECT on a
read-only reporting copy"])
  D --> E{"Number looks plausible?"}
  E -->|"Unsure"| F(["Check it with an analyst
before you act on it"])
  E -->|"Yes, and checked"| G(["Answer in minutes,
ask a sharper follow-up"])
  F --> G
Query literacy turns a queued request into a self-served answer, with a verification step that keeps you honest. Leaders Loop

From literacy to better engineering questions

Pulling your own numbers is half of it. The other half is how literacy reshapes the questions you put to the work itself. The clearest evidence-based lens for that comes from the DORA research program (DevOps Research and Assessment), founded by Nicole Forsgren, Jez Humble and Gene Kim and detailed in their book Accelerate (2018). Drawing on years of survey data from tens of thousands of practitioners, DORA distilled software-delivery performance into a small set of metrics split into two halves: throughput, how often you deploy and how quickly a change reaches production, and stability, how often a change fails and how fast you recover. (The original "four keys" have since evolved; DORA now frames it as a slightly larger set, but the throughput-versus-stability split is the durable insight.)

The reason this matters to a literate leader is that it kills a bad instinct. The untrained question is "why is this taking so long?", which quietly pushes teams to cut corners on stability so they look fast. Ask paired questions instead: "If we ship this quicker, what happens to our change-failure rate?" or "How long would it take us to recover if this deploy went sideways?" You do not need to read a line of code to ask those. But reading code is what tells you whether the answers are real or merely reassuring. One boundary worth keeping in view: DORA's metrics describe delivery performance, not whether you are building the right thing at all. A team can deploy flawlessly in the wrong direction. Literacy shows you how the work moves; it does not, by itself, tell you what to build.

A worked example

Take a head of operations, call her Maya, who owns a customer-support team and a roadmap she does not feel qualified to challenge. (Illustrative scenario; the details are a teaching example, not a real company.) Every week she asks an analyst for "tickets resolved per agent," waits a day or two, and gets a spreadsheet she cannot interrogate further. When she questions an engineering estimate, she is told it is "complicated," and she has no way to test that.

Maya spends two quiet weeks on literacy, not coding, just reading and querying. She works through an introductory SQL course and gets read-only access to a reporting database. Now her weekly question takes her four minutes:

flowchart LR
  A(["SELECT agent,
COUNT(*) AS resolved"]) --> B(["FROM tickets"])
  B --> C(["WHERE status = 'closed'
AND week = '2026-W24'"])
  C --> D(["GROUP BY agent"])
  D --> E(["ORDER BY resolved DESC"])
The same business question, read left to right: which agent, counting closed tickets, this week, grouped per agent, busiest first. Leaders Loop

The shift is not the time saved, though that is real. It is that Maya can now ask the next question, "of those closed tickets, how many reopened within 48 hours?", and see for herself that one agent's high count hides a quality problem. And when she sits in the next roadmap review, she reads the proposed change well enough to ask, "this touches the billing table, what's our recovery plan if the migration fails mid-deploy?" She has not become an engineer. She has become a leader the engineers cannot fob off, and one who stops treating the data team as a vending machine. That is the whole return on a fortnight.

The trap, worth naming because it is common: Maya could now over-reach, rewriting estimates, second-guessing implementation, treating her two weeks as equal to their ten years. Literacy that curdles into meddling does more damage than ignorance, because it arrives with confidence. The discipline is to use the new skill to ask better questions and answer your own, then defer on the how.

Frequently asked questions

Do I actually need to learn to code to lead an engineering team?

No, and trying to learn it the way a junior developer does is usually a poor use of your time. What pays off is reading literacy: following a change, understanding a system's shape, and querying your own data. That is a much smaller skill than writing production software, and it is the one that changes how you lead. Aim to be a fluent reader and a competent SQL questioner, not a part-time engineer.

Why SQL and not Python or JavaScript?

Because SQL answers the questions leaders actually have, about customers, revenue, usage and operations, and because it is declarative, so you describe the result rather than program the steps. That makes it unusually learnable for a non-programmer. Python and JavaScript are more powerful and far broader, but they ask you to think like a builder. SQL lets you think like an analyst, which is closer to how a leader already thinks.

How much SQL is "enough"?

Enough to answer a single-table business question and check it: SELECT, FROM, WHERE, GROUP BY, ORDER BY, and a basic JOIN across two tables. That covers a surprising share of everyday questions. Anything involving complex joins, performance tuning or production data should still go through your analysts, both because it is genuinely hard and because the cost of a wrong number presented as fact is high.

Won't a little knowledge make me dangerous?

It can, if it makes you overconfident. The failure mode is the leader who reads two pull requests and starts overruling people who do this full time. Guard against it by keeping the purpose clear: literacy is for asking sharper questions and serving your own data needs, not for overriding expertise. Treat early queries as drafts to verify, and treat your reading as a prompt for dialogue rather than a verdict.

Can't AI assistants just write the queries for me now?

They can draft them, and that lowers the barrier to getting started, but it raises the value of being able to read the result. An assistant will happily produce a confident query against the wrong column or with a subtly broken filter. Literacy is what lets you sanity-check the output and notice when the answer is plausible but wrong. The skill shifts from writing to reviewing; it does not disappear.

Related in the Toolkit

Query literacy sits on top of how data is stored and served, the server-side world of databases and APIs is exactly what your SQL is talking to, and the engineering-question discipline above is really an applied slice of delivery metrics.

Where to go next