
Hi Team,
Do you know John? If you haven’t met him exactly, you almost certainly have had a new co-worker like him.
Anyway, John’s a good enough guy. He just joined the marketing team. He introduced himself on the first day to everyone, telling safe jokes and showing just the right amount of photos of his two kids.
John is ready to hit the ground running, but there is a slight problem—the team’s processes and tools aren’t exactly what John is accustomed to.
At his previous employer, he built his presentations in Canva. When it came time to review video content, he’d comment in Frame. And while he knows Salesforce well enough, he managed his sales funnel by relying on Outreach.
Well, your team uses Google Slides, doesn’t really like Canva, feels Outreach is too expensive and prefers Google Drive to a dedicated video sharing tool.
So it begins…
Practices vs. Experiences
The average 100-person company spends $3,000-$6,000 per employee annually on software tools. Much of this bloat occurs because we let new hires bring their preferred tools instead of properly onboarding them into existing systems. In this sense, John, in fact, never gets onboarded. He brings fragments of his own work experience to a new company, maybe not calling the same plays, but certainly using the same formations. The team in this case doesn’t get John’s experiences, but his practices, which if not properly aligned, might do more harm than good.
Which brings us to the real question: Should John adapt to the team’s processes, or should they adapt to his?
John doesn’t like to be slowed down, why spend a month learning new tools and assimilating into a new process when he was hired to create splashes in the first few weeks?
This is why.
Onboarding creates Vulnerability
Here's what I've learned: onboarding isn't just about learning processes—it's about showing you can ask for help and are able to adapt. When John needs guidance with your team's workflow, he immediately creates opportunities for collaboration.
By adopting the team's processes, something very powerful happens:
He shows vulnerability (“I need help” … “Can you show me…”)
He gives existing team members a chance to guide and mentor
He demonstrates he can listen and learn
The alternative is the “new guy” spends more time onboarding with IT procuring new services, opposed to understanding the teaching style and possible pain points of his new team.
But that’s only part of the puzzle.
Onboarding taps into something instinctive
Onboarding is not just a chance for new hires to feel welcome, but for the current team to return to one of our most formative habits: sharing.
Think about it. What was one of the first things we did as kids at school? We were taught to share and to show people around. Our classroom, our locker, our work. Your existing team members should want to share what they know. Let them tap into that youthful instinct.
Strongly encourage new hires to adapt and take the time to learn why things are done around here. Encourage them to look around and learn; to adapt but disrupt as needed. At worst, the team will learn what they can improve upon.
Which brings us to …
The Innovation Exception
Now, what if your current processes genuinely aren't working? What if you brought John in specifically to shake things up?
Even then, letting a new team member default to "this is what I used at my last company" isn’t constructive. For starters:
Just because something worked elsewhere doesn’t mean it fits your team’s collaboration style.
It overlooks the fact that your team may have already tested similar approaches.
Fixing systems requires more collaboration, not a shortcut to fast-tracking one person’s preferences.
Not giving current systems an honest shot misses the above-mentioned opportunities. And it’s the only way for suggested improvements to carry real weight—and credibility.
Your Next Steps
If you're onboarding and in John’s position, here’s what you can do starting tomorrow:
Schedule coffee or a general meeting with someone outside your department to understand their daily tools and processes. Even if you’ll never use their tools, you start to see why they use them. That tells you a lot about their priorities, constraints, and what “success” looks like in their world.
Ask senior team members what processes they miss or think should be revisited.
Propose a hypothetical: "If we had to cut software costs by 25%, what would we eliminate first?"
If you’re working with someone new, akin to John, try to keep the following in mind:
Be receptive to “new eyes”. Let John stress-test a process, and explore why he feels strongly about his approach versus the one in place.
Use onboarding as a teaching moment. Explaining a process often reveals steps that could be streamlined.
Remember: time spent now reduces risks later. Teaching someone your process creates redundancy, prevents bottlenecks, and keeps you from having to swoop in to solve problems when you’re on PTO.
Adaptation enables disruption
Every new hire represents a choice: Do we prioritize the comfort of individual preferences, or do we invest in the harder work of mutual understanding?
It’s not really about whether John should adapt to the team or the team to John. It’s about whether two people — one new to the company, both new to each other — are willing to do the uncomfortable work of building something better together.
Six months from now, John may introduce real improvements to the workflow. But those improvements will be grounded in understanding, not assumption. In collaboration, not substitution.
Onboarding isn’t about getting to work as soon as possible. It’s developing the fullest possible understanding of where to make an impact. We can disrupt, but first we must adapt.
Adaptation isn’t the opposite of disruption — it’s the foundation that makes it possible.
As Ever,
Paul Nyhart
Chief Connection Officer - Hi Team


Was this email forwarded to you by a friend (that’s a good friend) you can subscribe below for free.👇

