Changing Schedules, One Final Time (Maybe)
First, a bit of administrivia. Now that I’m settling in and everything, it seems to me that a Sunday posting schedule might be better. Saturday was ok, but was affected by it being, you know, a Saturday – a day that I’m most likely to be sociable, or at least attempt to be sociable.
Sunday, on the other hand, I’ve basically reserved for most chores. Not that writing here is a chore, mind; I just think that the time I spend waiting for my laundry might be better spent at least drafting a post.
(And now, this week’s post)
Vocabulary
A shared vocabulary eventually forms between the members of any group or community. Startups often have less of this initially, as there isn’t yet a shared background to latch on. In a startup that shared vocabulary is usually seeded from any shared background from the founders or founding members – either from a previous company they’ve all worked in, or being graduates of the same school, or even just being members of the same communities.
The shared vocabulary often forms around jargon, idioms, or even phrases; a lot of it, especially at work, derives from being able to succinctly capture and communicate an idea, and having the same tools to do so makes it much easier.
The thing is, I never really liked a lot of corporate-speak; I admit that, in a lot of ways, they’re supposed to capture some sort of nuanced meaning, but which ends up sounding insipid and flat instead. Being now that I’m working at one of the largest and most valuable companies in the world, I guess it’s inevitable that I’ll be exposed to some corporate-speak.
Again, not that it’s bad, per se.
I honestly never thought I’d use the term skip in conversation with a friend to refer to my manager’s manager, for instance, but it does convey meaning quite succinctly, albeit in a slightly opaque fashion.
That being said, most of the vocabulary I’ve had to front load in the past few weeks hasn’t been dead corporatese, but rather the vocabulary of the domain our team works in. A lot of the words in that vocabulary, sadly, originates from references to codenames and projects, which makes it really tough for a newcomer to the team to quickly grok what’s being discussed. Sure, as I said, once you’ve learned what those words mean in this context, it makes it easier to communicate – and the thing here is, sometimes it’s hard to infer meaning from context, so bootstrapping that shared vocabulary can be difficult.
That is, I also think, the issue with a shared vocabulary: in a way, it represents a barrier to entry; hence, why it’s often advised that writers avoid jargon, or highly technical language, since it alienates readers – the job of a writer is to communicate, after all, and alienating one’s readers is not communicating.
Work though is a different beast.
When at work, a shared vocabulary of technical terms and codenames and other such stuff allows for the conciseness of speech; they’re the equivalent of using pronouns to refer to something already referred to in the past.
One of the things I’ve been doing to handle the firehose of information directed at me is to build a map of the domain – of the shared vocabulary that permeates work discussions. Thankfully, it was easy for me to build that map using the tools available to us internally, and a lot of the stuff to deep-dive into various topics are documented, so all I needed to do was just create a map of pointers to the relevant documents.
There’s still spotty coverage though, and I think I’ll pick up some of that eventually just immersing myself in the culture of the team.
Previously: Week Two