Before I managed engineers, I spent time studying educational technology: how people learn, what tools do to help, and what they do that gets in the way. I did not expect it to shape how I lead a team. Looking back, it shaped that more than anything else I studied, because a team that is not learning is a team that is slowly becoming obsolete, and most of the job of a manager is arranging for learning to happen.
The learner does the work
The first thing the field teaches is that learning is something the learner does. Not the teacher, and not the software. A lecture can be excellent and produce nothing if the listener never does anything with it. The same is true of an onboarding document, an architecture talk, or a tool rollout.
On a team, this means I am suspicious of anything that transfers knowledge by exposure. The engineer who read the design doc has not learned the design. The one who changed it, or broke it, or explained it to someone else, has. I try to arrange work so that the learning is in the doing, and I try not to mistake having been told for knowing.
Feedback has to be fast and specific
The second idea is that feedback changes behavior only when it is close to the action and specific about it. A grade at the end of a term changes almost nothing. A comment on the sentence, the day it was written, changes the next sentence.
Engineering already knows this at the mechanical level, which is why we have linters and tests that run in seconds. I think it applies at the human level too. A review comment the day of the change teaches. A performance conversation months later, about patterns nobody named at the time, does not. The most useful thing I can do for someone's growth is shorten the loop between what they did and what they hear about it.
Scaffolding has to be removed on purpose
Scaffolding is the support you give a learner so they can do something they could not yet do alone: the worked example, the template, the pairing partner. The field is clear that scaffolding works, and equally clear that it has to be taken away as competence grows, deliberately, or it becomes a crutch that stops growth exactly where the support ends.
I think most teams are good at putting scaffolding up and bad at taking it down. The checklist that was written for the first month is still being followed in the third year. The pairing that got someone started is still happening when they should be leading. Removing support feels like withdrawing help. It is the opposite. It is the moment the learning is allowed to finish.
Whatever you assess, you get more of
The last idea is the one every teacher learns the hard way. Students study what is on the test. If the test rewards memorization, they memorize. If the test rewards reasoning, they reason. Assessment does not measure behavior so much as produce it.
Engineering teams are assessed constantly: in reviews, in what gets praised, in what gets promoted, in which numbers are on the dashboard. Every one of those is a test, and the team is studying for it. If visible output is what gets noticed, output becomes visible and quality goes quiet. I try to remember that every metric I introduce is a lesson plan, and to ask what it will teach before I ask what it will measure.
Why I think this matters
Most of what a manager does is set the conditions under which people learn. Who works on what, how fast the feedback comes, when the support is removed, what the assessment rewards. I came to those ideas through education and found them waiting for me in management. I think any engineering leader would benefit from spending some time with how people actually learn, because that is the work.
Photo source: https://photos.robertstowe.com/bengaluru