Human Skills in the AI Era: Learning Through Experience - Episode 1: The Engineer Who Made the Work Make Sense
What one young engineer taught me about communication, ownership, and learning in practice
As AI changes how we build software, technical ability remains essential. But I keep thinking about another question: what helps an engineer make their work useful to the people who need it?
One young engineer I worked with gave me a memorable example.
At the time, I was a project manager at an offshore software development company. Our team was working on AI projects for Japanese clients. I wanted us to deliver high-quality work and communicate clearly. But I wasn’t an AI engineer. To manage the project well, I needed to understand what the team was building, why they had chosen a particular approach, and what the results meant.
This engineer helped me do that—and he involved me before the work was finished.
When a request came in, we discussed what the client was trying to achieve. Before the team trained a model, we brainstormed the approach, questioned assumptions, and considered whether we were heading in the right direction. Those conversations helped us catch potential problems early, before they turned into avoidable rework.
He explained the technical terms and reasoning in ways I could follow. I could ask more useful questions, contribute to the discussion, and prepare to explain the work to the client. The collaboration continued as the team worked: we exchanged questions and comments, checked our understanding, and adjusted when needed.
The reports were part of that same process. He gave clear updates, helped explain what the team had achieved, and raised issues or questions that needed the client’s attention. As a report deadline approached, he stayed involved and helped me rephrase technical explanations so the client could understand them.
The work didn’t feel like something the engineers completed and then handed over for me to explain. We were thinking through the request, the approach, the progress, and the client’s understanding together.
He carried learning into his work
Our company knew that communication was a challenge for many engineers, both in conversation and in writing. We created courses in logical thinking and writing, with contributions from project managers, including me, and external instructors. Engineers and people from other roles joined the sessions.
I noticed that relatively few people consistently applied what they had learned in their day-to-day work. The engineer in this story did. He put the ideas into practice in his reports, explanations, and preparation for client conversations.
I later noticed the same quality in another colleague. What stayed with me was not simply that they attended training. They were willing to try a different way of working, even when it felt unfamiliar, and keep doing it until it became useful.
Courses can be boring, too general, or poorly connected to someone’s actual work. Still, learning does not become a skill just because we sat through a session. It becomes a skill when we carry it into the next report, meeting, explanation, or decision—and adjust when we see that it hasn’t worked.
That willingness to practice is easy to overlook. It may be one of the most important differences between knowing that communication matters and becoming someone others can work with effectively.
Learning only matters when it reaches the work.
He turned feedback into improvement
I had high standards for our work and for what we delivered to the client. I gave the team comments throughout the project: while we were discussing the request, brainstorming the approach, and reviewing how we explained the work.
He took feedback seriously. If he needed more detail, he asked questions. Then he applied what we had discussed. I could see the improvement in the next version of the approach, the next update, or the next report.
I sometimes thought of him as a “human AI”: we exchanged feedback, and the work kept getting better. What impressed me was not that he agreed with everything. He listened, understood the point, asked for clarification where needed, and turned it into action quickly.
He wasn’t the team’s formal leader, but I began to experience him as one. He helped the team think through the work, made it easier to collaborate with the client, and kept improving the result from one round to the next. Leadership showed up in how he helped the group move forward, even before it appeared in his title.
A technical role still affects everyone around it
An engineer’s work has effects beyond the code or model itself. The way an engineer understands a request, chooses an approach, communicates progress, and responds to feedback can shape how the whole team works—and what the client is able to understand and decide.
When I think about forward-deployed engineering, I see capabilities in this story that seem especially relevant. An engineer working close to users and business problems needs to connect technical work with the people and context around it. I’m not saying this one story defines the FDE role. It showed me how useful these behaviors can be.
Here are some of the capabilities I saw, and ways to practice them:
Clarify the problem before choosing a solution. Ask what the user is trying to achieve, who will use the result, and what success would look like. Check your understanding before work begins.
Think through the approach with others. Share your assumptions, possible methods, and concerns early. Ask what could go wrong and how you will know whether the approach is working. A short discussion before implementation can prevent much more costly revision later.
Make your reasoning and progress understandable. Explain what you are doing, why you chose that approach, what has changed, and what still needs attention. Use examples when technical language makes the idea difficult to follow.
Use feedback to improve the next version. Listen for the specific point behind a comment. Ask for an example or a suggested improvement if the feedback is unclear. Then apply it and show what changed.
Take responsibility across the whole process. Think beyond your assigned task. Help colleagues and users understand the result, raise questions that need decisions, and stay involved as the work moves from idea to implementation and communication.
What changes when AI can help?
AI can help engineers generate ideas, explain technical concepts, draft updates, and prepare questions. Those tools can make parts of the work faster.
But teams still need to decide whether they are solving the right problem, whether an approach makes sense in context, and what feedback should change in the next iteration. Someone needs to check that an explanation reflects the actual work and that the team’s commitments are realistic.
The engineer I remember used his technical ability in a way that helped the whole project: he made it easier for us to think together, catch issues early, explain decisions, and improve through feedback.
Tools will keep changing.
The ability to clarify, collaborate, communicate, and learn from each round of work can grow with them.
A little bonus
The photo above shows two amazing colleagues I worked with. One of them is the engineer in this story. Can you guess which one? ✨
And a book behind the scenes: when I helped design our logical thinking and writing courses, one of the references I used was The Pyramid Principle: Logic in Writing and Thinking by Barbara Minto.