Joan, Laura, Tom and John were waiting for their local software development meetup to start. Each was a software architect at their respective local software firm. A shared interest in team culture had grown into a longtime friendship.

“We’ve had so much churn lately,” Joan commented. “People leaving for greener pastures, and their replacements coming in. I can’t remember the last time I’ve explained so many TLAs.”

“Three letter acronyms are the worst,” Tom commiserated. “Especially when they’re pronounced as actual words rather than a collection of letters. When my CEO jabbers about ‘TCO,’ I can at least go through possibilities and decide she probably means ‘total cost of ownership.’ When she talks about ‘fixing the toc,’I always wonder what the ‘tick-tock’ of a clock has to do with anything. I still don’t know what she means.”

“We’ve had a fair amount of new hires arriving as well,” John said. “Who all have similar questions about, well, everything. Even the ones coming with a bunch of experience don’t necessarily know all the terms and lingo we use.”

“So, how do you ramp them up?” Laura asked.

1) Dedicate someone to answer questions

“I’ve been explaining so many TLAs because I’m doing most of the onboarding,” Joan explained. “For everything engineering, anyway. I hope to inculcate people into our way of thinking right from the start.”

“Do you have a specific system? Or do you let them lead you by their questions?” Tom wanted to know.

“I’m settling into a sequence,” Joan answered. “I’m about to the point where I could probably make a recording and let new employees start with that. But, I’ll keep doing it live. Part of what I’m trying to do is make a strong connection with each new person right from the start.”

“We give each new engineer a mentor,” Laura said. “The mentor meets the new person when they arrive and helps them from there on out. Anything from “The bathroom is down there” to “Here’s the process for code review” to “I have this crazy idea I’d like to try out.”

“That seems like an awful lot for one person to know,” Joan commented.

“The mentor doesn’t need to know the answer to every question, just to know how to route it. Most important is the new employee having a specific person to go to for everything. And, the mentor makes clear that their only priority for the first month or so is helping out the newbie. We don’t even schedule any work on the mentor that first month.”

“We use mentors, too,” John said, “but we’re not nearly as hardcore about it. For us, it’s more, ‘Hey, any questions you have, start with so-and-so.’”

“We started that way,” Laura said. “We found that especially early-career people tended not to ask questions because they didn’t want to waste people’s time. So, we’ve evolved to clearly stating that the mentor’s only responsibility is helping the new person.”

2) Build a glossary

“That’s great for newbies,” Tom said. “Lingo and TLAs, though, pop up faster than a whack-a-mole. I look up a new one once or twice a day. How do you help people come up to speed on those?”

“Wiki,” John said. “Our department home page has a prominent link to our glossary. Half of which are TLAs.”

“We use a wiki as well,” Joan agreed. “Keeping it up to date is a chore, though. As you say, new terminology is constantly popping up.”

“We made a leaderboard for updates to our dictionary,” Laura added. “The top contributor for the sprint gets priority in choosing work for the next sprint. However, we did have to add demerits for unnecessary edits,” she added. “When we first tried out this incentive, I swear that eighty percent of the edits were not remotely related to our work.”

“I can imagine,” the other three said in unison.

3) Discuss everything on the regular

“How do you ramp people up on the culture?” John asked. “We haven’t found a good way to get that across to people. We worry our culture is drifting in ways we don’t want simply because we can’t explain what we do want it to be.”

“Oof, that’s a tough one,” Laura empathized. “Simon Sinek’s book Find Your Why has a process to help teams come to a succinct description of why they do what they do. But, culture is more than that.”

Joan nodded her head. “Having a clear mission, scope, values, and the like can all help. What we’ve found most useful, however, is having team and company discussions about events that seem to go against our culture. We have a process where anyone can point out these events, anonymously if they wish. These go into a specific channel on our team chat. Then, people use emojis to show their feelings about the event. Every Friday, we set time aside to discuss these as a company. You might say we aren’t protecting our culture so much as continually building it through discussion.”

“We don’t have anything so explicit,” Tom said. “We do make a point of discussing our culture and any concerns or perceived violations of it. I agree cultures stay alive not through enforcement but only through discussion.”

Take a tiny step to better orienting your team

“Thank you for all these ideas,” Tom said. “I have so many to take back my team and experiment with: assigning new employees a mentor, and ensuring the mentor has time dedicated to working with the newbie. Maintaining a central, easily discovered glossary of terms and concepts, and incentivizing the team to keep the glossary up to date. And, even though we already have regular discussions about our culture, I imagine writing aspects of that down will help us ensure the critical parts stay the way we want them to.”

“One of the things I love about being a developer is I always have something new to ramp up on,” Laura said. “Still, I sometimes get overwhelmed by that. This discussion is germinating thoughts on how to overcome that.”

“I’m super curious what is taking root in that head of yours,” Joan said. “I’m curious to hear how it grows.”

“I think Joan just signed you up for a future presentation here at our meetup, Laura,” John said with a grin.

“Let’s see whether these ideas wither or thrive first. However they turn out, an experience report down the road is a great idea.”