Engineering leadership has a dirty little secret: most of the work that matters is invisible. Pauline Jepp's presentation, which draws on systems thinking, rock climbing, and the emergent patterns of flocking birds, makes this explicit in a way that most engineering management content dances around. She is not selling a framework or a certification. She is describing a mindset shift where the leader's job is less about making decisions and more about shaping the conditions under which decisions get made. That is a profound distinction, and it is one that too many teams learn only after they have burned out a senior engineer by promoting them into a role that rewards command and control over context and care.
The practical takeaway here is that autonomy and alignment are not opposites. They are two ends of a living system, much like the flocking behavior Jepp references. A flock of starlings does not move because a central bird issues commands; it moves because each bird follows a few simple local rules, and yet the whole formation stays coherent. Jepp translates this into engineering leadership by arguing that you do not need to micromanage your team's every commit or architectural choice. Instead, you need to establish clear principles, model the behaviors you want to see, and then trust the system to self-organize around those constraints. For our readers who are making the jump from hands-on coding to leading people, this is the difference between being the smartest person in the room and being the person who makes the room smarter. If you are struggling with this transition, we would point you to our guide on navigating engineering leadership transitions and our deep dive into team autonomy frameworks, because the specific tactics matter less than your willingness to let go of the keyboard and trust the process.
But here is where Jepp's talk earns its keep. She does not shy away from the uncomfortable reality that a lot of critical leadership work, like mentorship, code review feedback, and cross-team communication, is invisible and therefore uncompensated. In a world where metrics like story points and pull request counts still dominate performance reviews, how do you reward the engineer who spends an hour helping a junior colleague untangle a dependency mess? Jepp suggests that leaders must actively create visibility for this work, not just in private 1:1s but in public forums, sprint reviews, and promotion packets. We would go a step further: if you are a leader and you are not actively shielding your team from the tyranny of the visible, you are building a culture that optimizes for busywork over impact. The specific consequence to watch here is whether your team's "invisible" contributions are showing up in their performance reviews. If they are not, you have a systemic problem, not a people problem.
The most compelling thread in Jepp's talk is her use of rock climbing as a metaphor for transition. When you climb, you cannot grip the wall forever; you have to trust your foothold, commit to a move, and accept that you will be off-balance for a moment. That is exactly what it feels like to step from engineering into leadership. You are no longer measured by the code you ship but by the environment you create. The open question we would leave our readers with is this: Are you willing to be the leader who supports the invisible work of others, even when that means your own technical contributions become less visible? If the answer is yes, you are on the right path. If you hesitate, that hesitation is your signal to rethink your definition of impact before you take the title.