Building a vernacular with your engineering team
Building a vernacular with your engineering team
สวัสดีโลก! (Hello World! in Thai)
Thanks, as always, for welcoming this newsletter into your inbox. It’s been an outstanding couple of weeks. The book continues to pop up in new stores around the globe. I try to keep the links up to date here. On Amazon, it’s entered the top 20 in various categories at the random times I’ve looked. The audiobook is now also generally available, including on Audible!
I’ve even had two different people now request signed copies. If you would also be interested, let me know.
If you’ve already purchased and read the book (as some of you have let me know), please rate it on whatever platform you purchased it from. It helps me reach others who might be interested. Even if you don’t want to give me a five-star review, that’s fine! I can take the criticism.
As always, you can get the latest info, links to this newsletter, and to the podcast from itdependsbook.net
About this newsletter
If you are new to this newsletter, I’ll explain. Every two weeks, I release a chapter from my book It Depends: Writing on Technology Leadership 2012-2022, which was released by Unit Circle Press this month. The chapters are released out of order from the book, but each stands on its own. There is also a podcast serializing the audiobook in order.
The latest podcast
The latest episode of the podcast is The Personal Strategy Offsite. Taking a day, once, twice, or even four times a year to reflect on how things are going and think about where you want to go next is a valuable practice. This episode includes how to approach this practice and get value from it. You can hear it wherever you get your podcasts, such as Spotify, Apple Podcasts, or YouTube…
I was also a guest recently on the CTO Podcast and The Jason Cavness Experience.
About this week’s chapter
I’m including Chapter 11 this week, “Building a vernacular with your engineering team.” I originally wrote it by request for the LeadDev website.
I was reminded of it while working on an e-mail to my team. Like many companies, we’ve had a rule about not deploying significant changes on Friday afternoons. Over time, this became known as “no-deploy Fridays.” Which didn’t quite capture the original intent, and as new people joined the team and heard the phrase, the understanding became “Don’t deploy anything on Fridays,” and then, since we are globally distributed, the understanding became “Don’t deploy anything when there is a timezone where it is Friday.” This might mean not deploying after lunch on a Thursday for US West Coast developers. A simple phrase and how different people interpret it is now impacting our velocity.
When I worked at Microsoft, I originally found the “Microsoft-isms” really off-putting, but now, from time to time, I will find myself using the phrases “let’s double-click on that” or “party on the data,” and I will simultaneously smile to myself and cringe.
Your team has a language that is all its own. Understand it.
Building a vernacular with your engineering team
Originally published January 8, 2021
Teams consist of people. People communicate via a common language. The base unit of most languages is words.
The impact of language
Whether written or spoken, words are essential – both the general terms we use and those specific to our work.
The terms and phrases that are specific to our jobs or our companies create a vernacular. The definition of vernacular according to Merriam-Webster is ‘the mode of expression of a group or class.’ Our vernacular separates software developers from lawyers, Amazon employees from Microsoft employees, and your team from the other teams in your company.
The words and phrases that we use in team discussions give us a shorthand. They save time. Instead of saying, ‘Ok, deploy this to production, let the support team know that it is going live, and then let marketing know once it has gone to 50% of active users.’ Your team may just say, ‘let’s deploy-ify it.’ The larger context is defined and understood in the vernacular of your team.
One of the challenges of joining a new company or a new team is learning the vernacular. One of the significant struggles of team forming or cross-team communication is different definitions for the same words.
Consider the word ‘Agile’. To you, it may mean ‘Scrum’ because your only experience working in Agile teams was working with the Scrum framework. For me, it may mean Kanban or a set of principles not tied to any specific framework. If we are on the same team and I say that I think we should work in an Agile way, we could have very different interpretations of what that means, which may inadvertently create tension in the team.
‘Done’ is another word that often leads to problems – both for a development lead and between teams. A developer on your team says that their feature is ‘done’. Do they mean that they finished the code? That they tested the code? That they deployed it to the staging environment? That the code is running in production? That the A/B tests for the code have completed?
Having clarity on the meaning of words is critical. Companies will often create glossaries of the terms and phrases in everyday use to help onboard new employees. You should do the same for your team for the words and phrases your team uses day-to-day. As a leader, you should also deliberately cultivate your team vernacular.
Creating a team vernacular
Creating a team vernacular is a simple way to drive team unity, identity, and alignment around best practices.
A simple way to start building a team vernacular is to use a group meeting to identify and define the words and phrases used in the team. You can get the discussion started by spending a few weeks taking note of words or phrases that come up often in team discussions. Terms such as done, tested, shipped, agile, stuck, autonomy, microservice, or waiting, may have different definitions from different people on a team.
Ask the team what they think each of these words means. If there is a general agreement, add it to your team glossary. Don’t stress over creating a perfect definition for each word. You can reference a dictionary definition or definitive blog post if you want, but your goal is team consensus around the meaning, nothing more.
Once the team establishes the primary vernacular, update it as necessary. Clarify the definitions of the new terms introduced. If someone uses a word in a new way, ask, ‘What does that word mean to you?’ If you don’t recognize a term that others are using, ask the team for the definition. Add these new words and phrases to your glossary. Over time, the meanings of words will change as they understand new subtleties or gain new skills. When this happens, append or replace the existing definitions.
Using your vernacular to train the team
Creating consistency in the words you use, or introducing new words, is also a valuable way to train your team or introduce new concepts.
You may find that there is debate within the team about the constraints for a system to be called a ‘microservice’. This debate is an opportunity to find blog posts or a book for the team to read together and discuss to create the definition for the team glossary.
If you want to understand secure coding practices better, you could watch a conference talk as a team and then discuss what words and techniques you could introduce into your vernacular.
As you build your glossary, include the phrase and what it means to your team and the references your team used to arrive at that meaning. Your dictionary can then become an onboarding tool, a training tool, and a reference to share with other groups.
Vernaculars happen
Groups of friends, co-workers, teams, and families all create unique vernaculars over time. The in-jokes you have with friends, the shorthand you have with your partner, the CEO’s catchphrase. Be aware of this, be deliberate about it within your team, and use this naturally occurring phenomenon to your advantage!
Thanks again for reading! If you find it helpful, please share it with your friends.