Employee training is a promise, and like every promise, it has two sides. One side offers time, money and patience. The other side offers attention, effort and trust. When both sides keep their word, people grow and companies get stronger. When one side breaks it, the damage lasts longer than any course.

In the first post of this series, we stood at the workshop bench on the first day after school. This post is about the agreement that keeps someone standing at that bench. It’s the part of training that nobody prints on a certificate: the ethics of it.
The Old Contract at the Bench
Apprentices in the old crafts signed a real contract. It had a name, an indenture, and it bound both sides for years. The master promised to teach the trade fully, without holding back the best secrets. The apprentice promised to work hard, stay the full term and keep the workshop’s methods to themselves.
Both sides took a risk. The master spent years teaching someone who could leave the day the contract ended. The apprentice gave years of labor for a skill that wasn’t guaranteed to pay off. What held it together was the contract, and underneath the contract, trust.
We don’t sign indentures anymore, thankfully. A modern developer can leave a job with two weeks of notice. But the shape of the deal hasn’t changed. Someone invests in you, and you decide what to do with that investment. That decision is where morals and ethics live.
What the Employer Promises
Let’s start with the side that holds the money. An employer who trains people is making several promises, whether they say them out loud or not.
The first promise is time. Training squeezed into the gaps between deadlines isn’t training. It’s a guilty secret. If a company sends someone to a course, the work should wait. If a developer is learning a new feature, an hour of exploration on a test server shouldn’t need an apology.
The second promise is honest guidance. A master who hid the best techniques broke the indenture. A senior developer who answers questions with “figure it out” breaks the modern version. Teaching well means sharing the shortcuts, the mistakes and the reasons, not only the final answer.
The third promise is room to use what was learned. Few things hurt morale more than learning a better way and being told to keep doing it the old way. A developer who comes back from a course full of ideas needs a place to try one. Otherwise the training becomes a reminder of what the job won’t allow.

The fourth promise is the one this cartoon breaks: safety. People learn when mistakes are survivable. When every error feels like a threat to the job, a team learns one lesson well. It learns to hide errors. Nobody grows in that workshop. They only get better at covering their tracks.
What the Developer Promises
Now the other side. Training isn’t something that happens to a developer, like weather. It’s something they take part in, and their part comes with promises of its own.
The first promise is attention. A paid course where you answer email in the back row is a broken promise, even if nobody notices. The company paid for your mind in that room. Give it.
The second promise is application. Learning that never reaches the work is a hobby, and a hobby is fine on your own time. Employee training exists so the work gets better. Bring one idea back and try it. Then tell your team what happened, good or bad.
The third promise is to pass it on. In the old workshop, the journeyman who once swept the floor would one day stand beside a new apprentice. That was part of the deal. The same is true today. Learning on the company’s time means the team gets something back. A short summary, a lunch talk or a well-written wiki page. Knowledge that stays in one head is a single point of failure.
The fourth promise is honesty about what you know. A certificate says you finished a course. It doesn’t say you mastered the subject. Claiming more than you learned puts the team at risk. People will trust you with work you aren’t ready for.
How the Promise Breaks Quietly
Promises rarely break in one dramatic moment. They wear down, a little at a time, until one day nobody believes in them anymore.
On the employer side, it starts with a training budget that exists on paper. It vanishes every time a deadline appears. It continues with a course approved and then cancelled the week before. It ends with a team that stops asking, because asking never works. Nobody announced that learning was over. Everyone understood.
On the developer side, it starts with skipping the follow-up exercises because the course felt easy. It continues with never mentioning what was learned. It ends with a manager who stops approving courses, because nothing ever seemed to change afterward. Again, nobody announced it.
The fix on both sides is small and boring. Write the promise down. Agree before a course what the developer will bring back and when. Put learning time on the calendar like any other meeting. Then check in afterward, honestly, about what worked. Promises that get looked at stay alive. Promises that get assumed fade.
The Hardest Moment: Leaving
Every honest conversation about training ends up here. People leave. Sometimes they leave right after the company paid for something expensive. That moment tests both sides of the promise more than anything else.

Most real exits sit somewhere between these two panels. Few people write a check. But there’s a big difference between leaving with gratitude and leaving with a smirk. One honors the investment. The other treats it as a free ticket out.
Leaving well is a skill, and it’s part of the promise. Finish what you started, or hand it over cleanly. Write down what only you know. Train the person who takes your place, even for a week. Say thank you to the people who taught you, and mean it. The industry is smaller than it looks, and people remember how you left far longer than how you arrived.
The employer has a part here too. Treating every resignation as betrayal poisons the workshop for everyone who stays. People watch how leavers are treated, and they adjust their own trust to match. A company that wishes departing people well, and means it, keeps a friendly alumni network. Some of them come back years later, more skilled than when they left.
Some companies add a repayment clause: leave within a year of an expensive certification, and repay part of the cost. That’s fair when it’s clear before the training starts. It turns an unspoken promise into a written one, and written promises cause fewer arguments.
Ethics Beyond the Contract
Training also carries quieter ethical questions. What you learn at one company about its systems, its customers and its data stays there. Skills travel with you. Secrets don’t. Taking a client’s code or a private design to a new job breaks a promise nobody needed to say.
There’s a gentler side to ethics too. Being trained puts you in debt to the people who taught you. Most of them don’t want repayment. They want you to do the same for someone else one day. That’s how the craft survives. Every good teacher you had is paid back by every person you teach.
The Case Against the Promise
You could argue that this is too romantic. Employment is a transaction. The company pays a salary, the developer does the work, and training is a perk like a parking spot. Nobody feels guilty about leaving a parking spot behind.
I understand that view, and I agree with part of it. A job isn’t a family, and no one should stay somewhere unhealthy out of guilt. If a company breaks its side of the promise, the developer owes it far less.
But treating training as a pure transaction makes both sides poorer. Employers who see it that way invest the minimum, and developers who see it that way learn the minimum. The best teams run on something warmer: the shared understanding that we’re all building each other’s careers. That isn’t romance. It’s the most practical arrangement anyone has found.
What to Remember
If you lead a team, keep your side first. Protect learning time, share what you know, let people use new skills and make mistakes survivable. Then expect the same seriousness back.
If you’re the one being trained, show up fully, bring something back and pass it on. If you leave, leave well. The next post steps out of the office altogether. It visits the conference halls and meetups where developers learn from strangers.
The Workshop Bench series
- Developer Training: The Day School Ends and Learning Begins
- Employee Training Is a Promise Both Sides Keep (this post)
- Learning from People: Conferences, Meetups and Mentors
- Every Way to Learn, and Which One Fits You
- A Letter to the Developer Starting Out
Training is not a perk you collect, it is a promise you keep.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
Discover more from SQL Authority with Pinal Dave
Subscribe to get the latest posts sent to your email.





5 Comments. Leave new
We had been to a training a couple of years back. After the completion of the course, our manager offered to pay the tuition fee..but we did not availed it as we felt that we got benefited by the training and so we would pay the fee.!!
Another great post, Sir!!
After reading it, I found another two questions:
1. Who pays for the training? Indeed, it’s a big question!!
2. Is the training available for Corporate or Individual? Most of the time, it is available for Corporate
3. Did you get Leaves to attend the training? Another big question, if it is not arranged by the company
Sir, any thought on the ITPro side?
The point which you mentioned on Reporting Back the Learning is really important. Because in a practical scenario, only few select folks would be able to make it to the training (due to cost, seat availability, and work load etc.), even though many people are interested to attend it. And in many organizations, people are sent for trainings/sessions on a rotation basis, hence next time when someone else goes for a training, they would post the learnings back which inturn will help us. Hence posting the learnings back is really essential both from an individual’s as well as an organization’s standpoint!!
After reading your post, my answer to the question ” Left or Right ” is RIGHT. The post is awesome as it has covered good points.
This is really excellent post, thanks a lot for narrating this Pinal.