DEV Community

Cover image for Making Sure You're In The Room Where It Happens

Making Sure You're In The Room Where It Happens

kathryngrayson profile image Kathryn Grayson Nanz ・6 min read

If you've watched Hamilton (or been subjected to a family member or friend who has), then you're familiar with "the room where it happens" – the song describing the process where decisions and conversations happen behind a closed door...and if you're not in the room where it happened, you're on the outside. Turns out the workplace isn't all that terribly different now than it was in the 1700s, at least in this regard – being in the right "rooms" can absolutely help you. And before we get too cynical, I'm not talking about networking, schmoozing, or sucking up by being in the rooms with the higher-ups – I'm talking about strategically getting yourself assigned to projects, in calls, and on teams that help you level up your skillset.

Everyone has knowledge gaps and things they're less comfortable doing in the workplace. This could be a specific technical thing, like a language / framework you don't have as much experience working in. But it could also be a high-level concept you've read about but never actually used, or a communication / "soft skills" thing. Doesn't matter, really, what the thing is – what does matter is whether there's someone else on your team or in your company who is great at that thing, and whether you can get into the room with them. Because being in the room will help you in three main ways:

  1. You see how other people think through issues and problem solve. Almost every dev will have a different approach to breaking down a problem, and no way is really wrong. The more methods you learn, the more tools you have in your own toolbelt.
  2. You learn new technical approaches you might not have known before or actually seen in use (vs. just reading about them in the documentation). Walking through a tutorial is nice, but doesn't always transfer cleanly to the codebase you're working in. Being with someone as they implement those hypotheticals in practice can really help you cement the knowledge.
  3. You see other people fail and troubleshoot. It sounds a little silly, but my favorite part of pairing is actually watching other people make the same kinds of simple, obvious mistakes that I make all the time (typos, missed semi-colons, etc.) and Google stuff. It's reassuring to see that senior devs are just, ya know, people – and to be reminded that errors and slamming your head against the keyboard is just part of the job, and not a personal failing.

Okay, so what "rooms" are we talking about here?

Pair Programming

One of the most obvious (and best) examples of this is pair programming; two people intentionally creating "the room where it happens" in order to code something together. I'm a huge fan of this as a method of learning, but it's also fair to acknowledge that true, by-the-book pair programming – the kind where you switch off being the one coding, narrate every line of code you write, etc. – can be an involved and time-consuming process that doesn't always fit into the schedule when things just need to get done, so it often just doesn't happen. We often think of pairing as an all or nothing concept: either we're pairing, or we're working individually. But that's not really true. There's a third option – observing.


And yes, I'm talking about literally just watching while someone else works. In an ideal world, you could interrupt to ask the occasional question, but even if you can't there's still a ton you can learn from just being in the same room where the work being done. In the situation when things just need to be finished without interruption, I like to keep a notebook nearby. That way, I can write down the questions I have and follow up on them later – first with a Google search, and then with someone else later if I can't find the answer on my own (usually with my boss, during our scheduled weekly one-on-one meetings).

Often, I find these opportunities by just listening to what folks talk about working on during morning stand-up, and reaching out to them afterwards to see if I can hang out with them while they do it. Most times, it's a Slack message as simple as "Hey, I heard you mention that you were working on refactoring the state management in [X part of the application] today – mind if I jump on a call with you while you do that and watch?" 99.9% of the times, the answer is "Sure!"

"Crashing" a call / meeting

Sometimes, I hear about other stuff going on around the company that sounds interesting to me – personally, I like to jump into client calls (to hear client feedback directly) and code architecture / planning calls (because I feel less skilled in that area). When I see stuff like that on a coworker's calendar, or hear them mention it in standup, I usually poke around to see if that's a "room" I can get into. Organized calls and meetings are a little bit more sensitive than just jumping into an impromptu pairing session with a teammate, so it's best to double-check and be extremely polite when asking about these opportunities – however, that doesn't mean you shouldn't do it, if there's something you'd really like to be involved in. You can sometimes help your case by offering to take the meeting notes, advance the slide deck, or take similar less enjoyable "grunt work" tasks off someone else's hands during the meeting in exchange for crashing.

Most importantly, though, is to always respect the answer and any boundaries that are given to you. If they say "Yes, you can listen, but you need to stay on mute the whole time.", then you better follow those rules. And if it's a flat out no, don't argue or wheedle – just say "Thanks anyway!" and move on.

Asking to be added to a project

Similarly to the call or meeting situation, sometimes there are longer-term projects or task-based teams put together to tackle a specific problem. These can be a wonderful opportunity to participate in something new and challenging, work with folks outside your immediate team, and get experience working outside your job parameters – all while looking like an above-and-beyond employee. Plus, rather than being a one-off situation, you get to be in the room for an extended amount of time; truly a win-win situation, when you can swing it! If you see something like this coming together and want to be involved, the best method is usually to bring it up with your boss and/or express your interest to the team or project lead.

Make sure, before you do this, that you can definitely handle the additional demands of the project in addition to your current workload - or at least, have a plan that you can propose to your boss regarding redistributing the work or adjusting timelines and expectations. And of course – like the above – be sure to respect the answer given to you.

Open source, volunteer, and freelance positions

Sometimes, the rooms we want to be in are pretty far from the rooms where we are, and they just won't be available to us in our current working situations. This is a bummer, but not a hard stop – in tech, we're pretty lucky that a ton of work happens online and entirely remotely. If you can't find what you're looking for internally at your company (and you don't want to quit yet), there are still lots of ways to find similar rooms elsewhere through contributing to open source, volunteering, and freelancing. There are tons of open source projects desperately looking for contributors of all kinds. There are non-profits near you that almost certainly need technical help in some way. And if you think your skills are ready to be put to the test, you can always seek out paid freelancing positions (because hey, why not get paid while you're at it, right?). All these options can put you into new situations, with new people, to practice new skillsets.

You won't always be invited into "the room where it happens", but you CAN invite yourself in. Many companies try to reduce the number of people explicitly invited to things as a means of kindness – they don't want you stuck in meetings all day, unable to get your own work finished. This is generally a good thing, but the downside is that you might be missing out on some cool stuff! Remember, not invited != not welcome. You don't need to be involved in everything, but if there's a specific area you know you'd like to learn more about, or a project you'd like to be involved in, don't hesitate to (respectfully) ask if you can be in the room where it happens. Be proactive about your own career, and remember – even if you have the world's best boss, nobody will ever be a better advocate for you than you.

Discussion (1)

Editor guide
foresthoffman profile image
Forest Hoffman

These are good points! The worst that can happen is someone saying no.

Also <3's for Hamilton
King George from Hamilton play dancing