The Human Disciplines — Feedback and Collaboration

The most expensive system I ever helped repair was not broken by bad engineering. The code was competent everywhere I looked; the individual engineers were demonstrably capable. What had broken was everything between them — reviews that said “LGTM” and meant “I stopped reading”, knowledge that lived in exactly one head per subsystem, and a disagreement about the integration approach that had been resolved by neither side, twice, in writing. In part 3 I covered Delivery, the discipline of shipping. This part covers the two disciplines that determine whether a group of capable individuals is actually a team: Feedback, at 13 points, and Collaboration, at 12.

A quarter of the model has no code in it

Add the two weights and you get 25 — exactly what Engineering Craft carries. That symmetry is not an accident of rounding; it is the framework stating a position. The interpersonal machinery of an engineering team is worth precisely as much as the technical foundation it runs on. Part 1 traced the industry's long journey to that conclusion, from Brooks in 1975 to the Agile Manifesto in 2001; these two disciplines are where my framework turns the conclusion into numbers you can assess against.

The two disciplines are close in weight because they are close in nature, but they are not the same thing, and the framework keeps them separate on purpose. Collaboration is the operating mode — how a team works together hour by hour. Feedback is the improvement mechanism — how a team gets better at everything, including at collaborating. A team can be strong in one and weak in the other, and the failure signatures are completely different: weak collaboration looks like friction, silos and quiet resentment; weak feedback looks like a pleasant team that makes the same mistakes every quarter. The system I described above had both, which is why it was expensive.

Feedback is how a team improves at everything else

Feedback earns 13 points because it is the mechanism through which every other discipline in the model improves. An engineer who cannot communicate cannot deliver review comments that make anyone's work better, cannot extract useful criticism of their own work, and cannot pass on what they know. Whatever their other scores are today, those scores are frozen — and so, wherever they have influence, are the team's.

The multiplier effect is the reason the weight lands above Collaboration's. Better code helps the codebase once; better feedback raises the quality of everything a team produces afterwards. One engineer who lifts the communication standard of a five-person team — sharper review comments, clearer design notes, honest retrospectives — contributes more than one who quietly writes better code in the corner. Improvement compounds; output merely accumulates.

Communication carries the current

Effective Communication takes the largest share, 30 points, because it is the medium the other three flow through. You cannot give useful delivery feedback without the ability to articulate what needs to change and why. You cannot seek feedback well without knowing how to ask a specific question instead of a vague one. You cannot share knowledge you cannot explain. The skill itself is adaptive rather than performative: technical depth for engineers, business impact for stakeholders, actionable specifics in a review — the same idea, re-encoded per audience. In distributed teams, where most communication is written and asynchronous, this sub-discipline quietly becomes one of the highest-leverage skills an engineer has.

The two 25-point rows are the same loop seen from opposite ends, and I weighted them identically because a team needs both directions working. Delivery Feedback is the outbound half: reviews of code, designs and proposals that identify what actually matters, explain why it matters, and suggest a concrete improvement — without prescribing every keystroke and without the drive-by dismissiveness that teaches people to stop asking. Seeking and Receiving Feedback is the inbound half, and it is rarer. Genuinely inviting criticism — asking the right person, at the right moment, a question sharp enough to answer — then separating feedback on the work from feedback on your worth, and demonstrating visible change: engineers who do this improve faster than any training budget can explain. The rarest thing I look for in an assessment is the second half done well; most of us are better critics than patients.

Knowledge Sharing takes the remaining 20: documentation, tech talks, pairing, runbooks — every act that distributes context instead of hoarding it. The blunt test I use is the bus factor. If your absence for a month would strand a subsystem, your expertise is a liability wearing the costume of an asset. Sharing what you know feels like giving away your value; in practice it is how individual knowledge becomes team capability, and the framework rewards it accordingly.

Collaboration is the constant

Collaboration's 12 points reflect a frequency argument rather than a multiplier one. Collaboration is not an activity a team schedules; it is the state the team is permanently in. Every code review is collaboration. Every design discussion, every planning session, every incident response at 2 a.m. is collaboration. Modern systems are too large for any individual to build or maintain alone, which means the quality of the joints between people is a permanent input to the quality of the software — not an occasional one.

And the quality of those joints has a sign, not just a magnitude. Teams that collaborate well are positive-sum: the group produces more than its members could separately, because context flows, blockers dissolve early, and nobody protects territory. Teams that collaborate badly are negative-sum — the meetings, the friction and the guarded information mean the group produces less than the same people would have managed alone. I have seen both, sometimes in the same organisation in the same year, with comparable engineers on each side.

Teamwork takes an unusually large 40 because it is the broadest and most fundamental of the three — the everyday substance of being on a team. Its evidence is mostly unglamorous: contributing honestly to planning, supporting a blocked teammate before being asked, volunteering for the necessary work that wins nobody any visibility, and caring more that the team succeeded than that your name is on the part that did. That last clause is the real assessment line. Plenty of engineers work near a team; the sub-discipline measures working as one.

Trust and disagreement are one mechanism

The two 30-point rows are equal because they are complementary halves of the machinery that keeps collaboration alive over time. Relationship Building creates the trust — the genuine rapport, empathy and understanding of other people's constraints that make hard conversations survivable. It is not networking; nobody is collecting contacts. It is the investment that determines whether a colleague hears your pushback as an attack or as help.

Handling Disagreement is what that trust is for. Disagreement in engineering teams is inevitable and healthy — a team that never disagrees is a team where someone has stopped talking — and the skill is engaging with opposing views on their merits, arguing the position rather than the person, knowing when to commit despite disagreeing, and walking out of the argument with the working relationship intact. The two skills feed each other in a loop: relationships make productive disagreement possible, and well-handled disagreement deepens the relationship. Break either half and the other follows — unresolved conflict corrodes trust, and absent trust, every technical debate turns personal. My broken system from the opening had exactly this failure: two capable engineers, no relationship, and a disagreement that nobody could afford to lose.

One point apart, and why

Why does Feedback edge Collaboration, 13 to 12? The one-point gap is small on purpose — the disciplines are siblings — but its direction encodes the multiplier argument from earlier. Collaboration determines how well the team performs today; feedback determines how good the team becomes. A team with strong collaboration and weak feedback is a pleasant plateau: everyone gets along, nothing improves. A team with strong feedback and slightly rougher collaboration has a trajectory. Given one point of weight to place, I place it with the discipline that compounds — while keeping the numbers close enough to insist you need both.

Together the human disciplines close out 25 points of the model, and with craft and delivery behind us the running total stands at 68. The remaining 32 belong to three disciplines that answer a different kind of question — not how you work with the team, but how far your judgement reaches beyond your own desk. Next: Leading Without the Title.