Most of this guide is about the work. This chapter is about the people doing it and the clock they are doing it against. Even an engineer who never wants to manage sees the whole board differently once the lead’s questions are in view: who grows from this task, is the vision shared, and is the estimate honest?
I once told my manager a project would take me three months at the outside, and probably closer to one. It was my project, I knew the hardware, and I had the design in my head and most of it on paper. He judged a single engineer too risky and hired four people to help. Within a month the project had ground to a halt, because the four of us now spent our days explaining the design to each other, and I had been pulled off to something else before the explaining was done. I came back later to a codebase with no attention to the hardware, expensive operations on the hot path, and nobody who could say who owned what.
Nothing about that was anyone’s bad intent. It is arithmetic. Every person added to a problem adds lines of communication, and the lines grow faster than the people: one engineer has none, two have one, five have ten, eight have twenty-eight. Each line costs time to keep in agreement, and when the problem is small enough for one focused engineer to hold in his or her head, every line is pure cost.
Lines of communication grow as n(n - 1) / 2. One person has none. Eight people have twenty-eight, every one of which has to stay in agreement for the work to move.
This is why principle 1.9 says the straight path is often the fastest. Adding people helps when the work can be split along interfaces that are already locked, so each person owns a piece end to end and the lines only have to carry the contract. Adding people before the interfaces exist multiplies the lines without multiplying the work, and the project slows down in proportion to the help it received.
A glimpse of how a lead reads the room: when to add people and when to protect one, how to match a task to the person who will grow from it, how to hold a common vision without drowning in meetings, and how to put a number on the work that will embarrass nobody later. Carry the questions even if you never carry the title.
Lines of communication grow faster than headcount; add people along locked interfaces, and protect the one engineer who can hold a small problem whole.
The work has a shape; so does each person doing it. A lead who actually knows the people leads better, full stop. Learn what each engineer enjoys, where each one struggles, what excites a person, and what quietly drains one. Then grow people on purpose. The trick is to hand out tasks that push a little past what is comfortable while staying grounded in what is already known: far enough to learn, close enough to win.
Comforttoo easy, bored
Stretchthe growth zone, assign here
Overwhelmtoo far, stalls
A task in the stretch zone is grounded in what a person knows but reaches into what a person is becoming. That is where people learn fastest and finish proud.
Tailor the work to a person’s skills, and to the skills a person is reaching for, whenever the project allows it. People light up at a challenge that fits, and excited people do better work. Let engineers build things from scratch when it makes sense, too. There is a real pride in making something your own that a bolt-on or a half-reverse-engineering job never gives, and that pride shows up in the result.
One honest catch: to lead this way, you have to know the craft well enough to ask real questions and propose real solutions. This is principle 1.3 turned toward people. You need not have done every job, but you do need enough depth to see when someone is stuck, to ask the question that breaks the logjam, and to recognize good work when it lands.
Low signal
Assign by who is free
Hand the next task to whoever has an open slot. The work gets done; nobody grows, and the bored engineer starts looking elsewhere.
vs
High signal
Assign by who grows
Match the task to the person who will stretch into it. The work still gets done, and a person levels up and stays excited while it happens.
Assign into the stretch zone, on purpose, and know the craft well enough to see when someone is stuck.
A lead usually starts the same way an engineer does: with a project summary or a general idea of the solution. Share it. Take the feedback seriously, and hear the disagreements out; things go better when there is a common vision, and the people doing the work very often see what the lead missed. A few minutes of real listening buys an enormous amount of commitment.
And then, at the end of the day, you are in charge, and sometimes you can see something the room cannot yet. There is no prize for spending three weeks in meetings convincing everyone of a call you are already confident is right. Once the direction is sound, set the marching orders and go. Answer questions as they come, because questions are how good people commit, but keep the whole decision closed in the hallways.
Earlier in my career I managed engineering at a smaller company where programs rarely ran over budget or missed a date. The operating principle fit on an index card: take care of your customer and your customer will take care of you. Disagreements were welcome, loud ones included, as long as they came through the door and up the chain. Going around the chain instead of through it was the one thing I would not keep a person for, because a team that argues in the open can decide, and a team that argues in the hallways never finishes deciding. Later, as a technical program manager on a much larger program, with a title that carried less authority than it looked like and a team that treated due dates as suggestions, I finished early and under budget anyway. It took more out of me than any technical problem ever has, and it taught me that the authority to decide and the authority to be heard are different things, and a lead needs both.
The lesson. Hear everyone, decide once, and insist that disagreement travel the right way. The marching orders only work when the people under them believe their objection was heard before the order was given.
Low signal
Decide by exhaustion
Meet, and meet again, until the last holdout finally agrees. Weeks evaporate, momentum dies, and the decision was sound on day one.
vs
High signal
Align, then commit
Hear the room out, fold in what is right, then set the direction and move. Keep answering questions, without relitigating the call.
Listen long enough to earn a shared vision, then decide once and keep the decision closed in the hallways.
Email, reviews, context-switching, and the ordinary admin of being employed take their cut. Plan to roughly eighty percent efficiency and your schedule stops lying to you. You can refine it with engineering bands, since a senior moves faster than a first-year, or just use a blended average. Either is fine, as long as it is honest about the hours a day actually contains.
A project I joined at the start was scheduled for three months. I proposed simple solutions that fit the customer’s window. Without anyone quite deciding to, the team made them the standard way instead: fuller frameworks, weaker requirements, and a test apparatus so elaborate that the head tester agreed, when I asked him directly, that it was complex for no reason anyone could name. The three months became three years, and the project was still going when I left it. Nobody had ever re-estimated. The original number simply stopped being mentioned.
The lesson. An estimate is tied to a design. Change the design and the estimate is void, whether or not anyone says so out loud. The honest move when the approach grows is to re-estimate in public, and the honest move when the date is fixed is to shrink the approach back to the need.
3 monthsthe schedule, with the simple design
became
3 yearswith the standard way, and counting
0re-estimates along the way
For the shape of the work itself, here is a simple trick borrowed from Agile with a twist. List the tasks at a high level, give each one a complexity score from the Fibonacci ladder (1, 2, 3, 5, 8, 13, and so on), and then let each task’s share of the total complexity stand in for its share of the effort. Now “this task is twenty-seven percent of the project” is a sentence you can say out loud, and progress is just the share of complexity that is finished.
Weighted complexity: the sentinel build
Task
Complexity
Share
Status
1
Acoustic front end
5
17%
Done
2
Detection and confidence
8
27%
In progress
3
Radio and mesh relay
8
26%
Planned
4
Localization
5
17%
Planned
5
Power management
3
10%
In progress
6
Field enclosure
1
3%
Planned
34% complete
Status in one line: the front end is done, detection and power are underway, and about a third of the total complexity is behind us. No burndown chart required to say where things stand.
Then there are deadlines. The most useful habit here is to refuse your own autopilot. If the thing you normally build in six months is wanted in one, resist quoting six by reflex; ask honestly whether one is possible, and then tweak the design to make it possible: cut scope to the real need, change the approach, lean harder on the prototype. Often it can be done a different way. If it can, commit to it and hold the team to it. And set deadlines more often than once a week, because a task given a week tends to eat the whole week. Shorter checkpoints keep momentum honest and surface trouble while it is still small.
Low signal
Default to your usual six months
Quote the timeline the work “always” takes, without asking whether a different design could hit the date the customer actually needs.
vs
High signal
Design to the deadline
Ask what would have to be true to land it in one month, reshape the design to get there, then commit to it with checkpoints tighter than a week.
A task given a week takes a week. A task given Thursday takes until Thursday.
Plan at eighty percent, estimate by share of complexity, re-estimate in public when the design grows, and design to the deadline instead of quoting the usual six months.
This page only teases the discipline. There is far more to say about hiring, feedback, conflict, career growth, and the long game of building a team that builds itself. The reason a slice of it lives in an engineering guide at all is simple: seeing the work through a lead’s eyes, even once, changes how an engineer reads the whole board. You start matching tasks to people instead of slots, you start naming the vision out loud, and you start estimating in a way you would be willing to sign.
Start from the need, keep the signal high, own the problem to its edge, then remember the problem includes a person who wants to grow and a clock that is honest. Lead that way and the whole team rises with the work.
For each person on the team, write one line: what he or she is reaching for next. Then look at the task list and find one assignment that could move toward it.
Score your current task list on the Fibonacci ladder and compute each task’s share. Say the status in one line, and see whether it matches the status you have been reporting.
Take a deadline you quoted by reflex and ask what would have to be true to hit half of it. Write down the design change that would get there, even if you decide against it.
Leading rests on the same spine as the engineering, with two more things in the problem: a person who wants to grow and a clock that has to be honest.
This chapter on one page
Each line is the sentence to remember from its section. The number takes you back to it.
9.1Lines of communication grow faster than headcount; add people along locked interfaces, and protect the one engineer who can hold a small problem whole.
9.2Assign into the stretch zone, on purpose, and know the craft well enough to see when someone is stuck.
9.3Listen long enough to earn a shared vision, then decide once and keep the decision closed in the hallways.
9.4Plan at eighty percent, estimate by share of complexity, re-estimate in public when the design grows, and design to the deadline instead of quoting the usual six months.
9.5Leading rests on the same spine as the engineering, with two more things in the problem: a person who wants to grow and a clock that has to be honest.