Core skills vs. company-specific skills
June 18, 2021Why are new joiners often quick to offer unwanted advice on how to improve things? Many "newbies" can't distinguish between core skills and company-specific skills.
At some point in your career, I’m willing to bet you’ve worked with someone who just joined the team, and started talking about how “at my old job, we did things differently”, as a petition for change, with no clear reason behind it. And they probably seemed pretty inexperienced—there’s an excellent chance that this is only their second job out of school.
“We should use GitFlow like we did at my last company.”
“We should do stand-up in the afternoon like we did at my last company.”
“At my last company, things were better because everyone used a MacBook.”
There’s also a good chance that you’ve been that person before.
What makes us do this? Why do so many people (perhaps all people, at some point in their life) try to change the way a new team works to conform to the ways of an old team? I think these suggestions are usually offered in good faith. There’s an honest belief that if we just did this one thing differently, work life would be better.
Most of these things are a matter of preference or culture, rather than “the right way.” Of course that’s not to say some new team member in this “at my last job” mode won’t occasionally make a great suggestion, but when they do it’s almost by accident.
I believe what leads to this situation is the fact that “newbies” don’t know how to distinguish between core skills (i.e. how to write functioning code, how to write clear documentation, etc) and company-specific skills (i.e. how to do a stand-up, which tool we use for monitoring, etc).
If we consider the Dreyfus model of skill acquisition, such people are “novices”, relying on non-situational repitition of learned behaviors. It’s not until the “advanced beginner” stage that a person begins to recognize that the skills they’ve learned are applicable only situationally.
If you find yourself itching to suggest “but we did it this way” just because it makes you more comfortable to do things that way, consider whether you’re still in the “novice” stage, and might learn something from those around you who are doing things different.
On the other hand, if you find yourself in a situation where things really are not working, and you remember a way of working that has worked in a similar situation, that’s a good indication that you’re at least an “advanced beginner.”
The key is not to offer advice based on past experience, obviously. The key is to offer advice that is situationally relevant, and as a bonus: that solves a problem the team as a whole feels needs to be addressed!
The Jonathan Test: 12 Steps to Better DevOps
20 years after the original, this is my take on an updated "Joel Test"
The hidden costs of hiring too fast
I was making really great progress at instilling a culture of quality until the pressure above from to "hire more people!"
When should you pick up the phone?
If a discussion becomes emotional, repetitive, or otherwise unproductive, it's time to pick up the phone.