Human Skills in the AI Era: Learning Through Experience - Episode 2: The Engineer Who Learned the Business and Helped the Team Grow

What a colleague taught me about domain knowledge, shared ownership, and the willingness to change

In the first article, I wrote about Hieu, an engineer who helped make technical work understandable to the people around him.

Another colleague taught me something closely connected: how much an engineer’s contribution can grow when they invest in understanding the business—and keep developing themselves along the way.

We worked on a consolidated accounting product at a Japanese SaaS company. I was a product owner in Vietnam; he was an engineer in Japan. We had two development teams working with a shared discovery team, while our business colleagues worked in another location.

We had the usual planning, refinement, and retrospective meetings. But what made him stand out was what he did between those meetings.

He looked beyond his own tasks

From my first days on the project, I noticed how actively he participated in conversations.

He followed discussions about his colleagues’ work and offered support across backend development, frontend development, infrastructure, and product discovery. When I asked the team a question, he was often among the first to respond—and his answer usually reflected an understanding of the surrounding context.

Later, I realized that he also read conversations in business and customer success channels. He paid attention to what customers were saying and what colleagues were trying to resolve.

I couldn’t see exactly how he organized all that information. What I could see was the result: he could connect a technical discussion with something happening elsewhere in the product or business.

His awareness helped him notice when a question needed answering, when someone needed support, and when information from another conversation might be useful.

He studied the domain before anyone asked him to

Consolidated accounting is a demanding domain. Understanding a feature can require understanding the accounting process behind it, the people performing that process, and the consequences of getting it wrong.

He chose to build that foundation himself.

He studied Japanese bookkeeping, beginning with Level 3. I remember seeing regular study time blocked in his calendar. Those foundations gave him more of the language and concepts needed to understand discussions with product managers and users.

As his knowledge grew, he could understand more of the problem directly, ask better questions, and contribute ideas to discussions about possible solutions.

He also began using the product with a stronger understanding of the accountant’s workflow. That gave him another way to examine a feature: what would it feel like to perform this task as a user?

What impressed me was that he had taken the initiative. He saw knowledge that could help him do his work better and made time to acquire it.

He helped other people learn too

He went a step further and built a gamified accounting study application, sharing it with colleagues in Japan and Vietnam.

That detail stayed with me. He had found a way to make a difficult subject more approachable for other engineers.

His learning began to benefit the team: more people had an opportunity to understand the domain and participate in conversations about the product.

He was increasing his own ability to contribute while helping colleagues build theirs.

He joined discovery while the questions were still open

His involvement began early, when an idea might still be a small hint in a roadmap or an initial conversation about a customer problem.

He listened, questioned assumptions, and contributed an engineering perspective while we were still discussing what, why, and how. He also encouraged other engineers to participate early.

He paid attention to feedback from sales and customer success, asking further questions to understand the customer’s underlying difficulty.

At user events, he prepared demonstration data and showed the product himself. He spoke directly with users and experienced their questions firsthand.

Those activities helped him understand the reasoning, uncertainty, and practical constraints behind a request. He could bring that understanding into discussions about what we should build and how it might fit into the user’s work.

His communication grew with his responsibilities

His work became increasingly visible, and he eventually moved into engineering management, leading both development teams. He continued to participate in technical exploration, proofs of concept, and research alongside his management responsibilities.

But his growth wasn’t seamless.

Earlier, his comments could be very blunt. In English, which was neither his first language nor ours, some messages could sound harsher than intended. As his responsibilities grew, the effect of his words mattered more.

We had conversations about how he communicated and how he could use one-on-one meetings to understand what team members were experiencing.

Over roughly three years, I saw him change.

He became more willing to listen, reconsider his approach, and ask how he could improve. He paid closer attention to colleagues who were quiet in meetings and made more effort to understand their difficulties.

He spent time encouraging people to share what they actually thought—including the uncomfortable parts that might otherwise remain hidden.

That changed something in my own thinking.

I used to wonder whether human skills were mostly qualities people already possessed, waiting for the right moment to become visible. Watching him grow showed me how much can develop through motivation, feedback, and repeated practice.

What this means for engineers interested in FDE work

When I think about forward-deployed engineering, several parts of his approach seem relevant: learning the domain, understanding workflows, speaking with users, joining discovery, and connecting technical choices with business needs.

He was also developing the ability to listen and help other people contribute. Technical understanding and human understanding grew together.

His path led into engineering management. Other engineers might apply similar capabilities as senior individual contributors, technical leads, or FDEs.

For me, the lesson is that this kind of growth can begin inside the project you already have: in the domain concept you choose to study, the user conversation you join, the knowledge you share, and the feedback you decide to act on.

What we can practice in our own work

Looking back, several habits made his contribution valuable—and they are things we can begin practicing in our current projects.

1. Build context beyond your assigned tasks.
   Follow relevant conversations across engineering, product, sales, and customer success. Look for connections that could help your team make a better decision.

2. Study the domain deliberately.
   Set aside regular learning time. Start with the concepts behind your current work, then connect what you learn to actual user problems.

3. Experience the user’s workflow.
   Use your product to complete a realistic task. Prepare the data, follow the steps, and notice where the process becomes difficult or confusing.

4. Join discovery early.
   Contribute while the problem is still being explored. Ask why it matters, what assumptions need checking, and what alternatives are worth considering.

5. Ask questions that deepen understanding.
   When someone requests a feature, explore what happened, who was affected, and what they were trying to achieve.

6. Make your learning useful to others.
   Share an example, a short explanation, or a small tool that helps colleagues understand something you recently learned.

7. Create space for other voices.
   Invite quieter colleagues to contribute. Ask about obstacles, give people time to answer, and follow up on what they share.

8. Turn feedback into a change in behavior.
   Ask how your approach affects others, choose one specific adjustment, and practice it in your next meeting or conversation.

These capabilities can help engineers work more effectively at the intersection of business and technology, including in FDE roles. They are also useful across many other professions.

What stayed with me most was seeing him develop over time. He kept building his technical knowledge, his understanding of users, and his ability to work with people. His example reminded me that human skills can grow through the same willingness to learn, practice, and improve that we bring to technical work.