Learning on the Job

When we start a new job we know that a good portion of our time will be spent learning the new job—the culture, the systems, the tooling, and the beliefs and behaviors of the other people on the team.

You know, spending time learning how stuff really gets done in this new context and environment!

Strangely, it’s as if learning to do the job is sequestered to only the beginning part of one’s time at the new place of employment and not a consistent philosophy and practice that is done or invested in after the new candidate seems acclimated to her new role.

In other words, learning on the job should be a consistent, large block of time that could be even explicitly mentioned in the job requisite or overview! Imagine seeing that on a job listing:

  • Role / Title: Software Developer
  • FT / PT: Full-time (45+ hours a week)
  • Responsibilities: Spend 5-10 hours per week learning how to be a better software programmer (and human). 30+ hours writing software and collaborating with the team on everything.
  • Compensation: $$$
  • Etc, etc, etc…

I’ve clearly simplified this to talk over my point, but, even though everyone understands that learning on the job is just part of any job you almost never see it called out explicitly, it’s just assumed.

I think it’s unsafe to assume much in a company, especially in the early-stage. This is why I #tatt all the time as I want to know what’s going on in every single area of the business (everyone should at that size)!

Consequently, from here on out, I’m going to call this out intentionally on any of the job descriptions that I create so that folks know that learning is a fundamental part of the job and that that’s included in a normal business week’s work.

In other words, I’m paying folks to learn, all the time. What fun!

%d bloggers like this: