This is Part 4 of our series on Upskilling in Engineering.
In the previous article, we explored the mechanics of good teaching: scaffolding, intersubjectivity, and contingency. Together, these describe how effective mentors provide support, build shared understanding, and adjust their guidance as a learner develops. But knowing how to support someone is only part of the picture. The other part is deciding how much to lead.
That question points to another distinction to be made: the difference between teacher-centered and student-centered learning.
In a teacher-centered approach, the instructor drives the process. Think of a traditional classroom where the teacher lectures at the front of the room and students complete assignments independently.
In a student-centered approach, the teacher steps back from the front of the room and instead facilitates learning that the students drive themselves. A teacher might divide a class into groups and give them a problem to work through together. The teacher is still present and involved, checking in with each group and correcting when necessary. Students are not left to sink or swim. They simply have more ownership over the process.
Both approaches have a place in professional environments, and understanding when to use each one is what makes the difference between effective upskilling and inconsistent development.
One well-established method for teacher-centered learning is the Gradual Release of Responsibility framework, which moves through four stages:
This structure works particularly well when teaching established processes, introducing a completely new skill, or working in a high-stakes environment where there is little room for error.
Consider teaching someone to program PLCs for the first time. A mentor might begin by demonstrating the basics: uploading and downloading code, flashing firmware, setting up I/O, writing initial ladder logic. That is the I Do stage. From there, the learner takes the controls while the mentor provides direct instruction — telling them to add a normally open contact here, assign a tag there. That is We Do. Next, the learner drives independently but the mentor steps in only when progress stalls. That is We Do Together. Finally, the learner programs independently and reaches out when needed. The mentor still checks in periodically, but that involvement gradually fades as the engineer becomes more capable. That is You Do.
The progression mirrors the concept of fading from the previous article in this series. Support is not removed abruptly. It is withdrawn strategically, in step with the learner's growing confidence.
When a project has more time and flexibility, student-centered learning can be a powerful alternative. In a collaborative learning model, a group of engineers is given a task or problem to work through together. Rather than directing each step, a more experienced engineer checks in at regular intervals to review progress, answer questions, and redirect when necessary.
This approach is best suited to situations where the stakes are manageable and the schedule allows for some exploration. It gives people the space to discover what does not work, reason through problems together, and ultimately build a stronger understanding than they might have developed through direct instruction alone. There is an added benefit as well: working through challenges together tends to strengthen team cohesion in ways that closely supervised work often does not.
The tradeoff is time. Collaborative learning requires more of it, both to allow the team to work through problems independently and to accommodate correction if something goes meaningfully off track. It is not the right structure for every situation, but where conditions allow, it creates durable learning and stronger teams.
Alongside these two structured approaches sits a third form of learning that tends to happen more informally: experiential learning.
Experiential learning is not a direct transfer of knowledge from mentor to learner. Instead, it is learning that occurs as a byproduct of being present in a working environment. Someone is pulled into a client meeting they were not strictly needed in. A conversation about new hardware happens to include people who were already on a call. A junior engineer watches a senior engineer work through a difficult problem in real time.
In each case, learning happens not because it was explicitly planned, but because someone was in the room when something useful occurred.
In a traditional office setting, this kind of learning happens organically and frequently. In a remote environment, those moments largely disappear. The hallway conversation, the overheard troubleshooting session, the informal lunch debrief — none of these happen automatically when a team is distributed. That means experiential learning needs to become intentional. Adding someone to a technical support call, including a newer engineer in a design discussion, or simply narrating your reasoning while solving a problem out loud — these are small choices that recreate what a shared physical space once provided.
Experiential learning is not a replacement for teacher-centered or student-centered structures. It is a complement to both, and it should be happening continuously regardless of which primary approach a team is using.
No single approach is universally correct. The right choice depends on the project, the people involved, and the environment.
In high-stakes, time-constrained situations, teacher-centered learning is usually the better fit. There is limited room for error, and the cost of someone working through a problem independently and arriving at the wrong answer can be significant. Close guidance keeps development on track without exposing the project to unnecessary risk.
When there is more time and flexibility, student-centered learning allows people to develop deeper ownership of their work. They collaborate, make mistakes in recoverable ways, and build problem-solving capability that tends to stick longer than knowledge that was handed to them directly.
The key is that the choice is made intentionally.
Choosing the right structure helps set people up for success. But what happens when that structure is missing, or when the level of support provided does not match what a situation actually demands?
In the next article, we will look at the cost of poor scaffolding — what happens when people are placed in situations without adequate support — and what those failures reveal about the importance of intentional upskilling.