DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Adron Hall
Adron Hall

Posted on

How to Reconnoiter a New Role!

"i.e. Starting a challenging new role!"

I'm stepping into a role right now, which I announced recently "Career Update: Back to Engineering!". In that role I have a number of key topics and knowledge specific to the role that I need to attain. Most of this is centered around the current state of teams, members of those teams, work in progress, product, and service status. The following are some of the important steps I've taken to reconnoiter the current state of things. These steps I've taken to get up to speed as quickly as possible!

  1. 1:1 Conversations and small selective meetings of at most 4 people. I'm very against superfluous and large meetings, they generally amount to a vast waste of people's time and in turn money. Whenever I step into a role where I need to gain situational awareness I keep meetings short, to the point, with topics and reading material arranged before the meetings. I don't want anybody to be surprised, and I want each of us to be able to dive into meetings prepared to rip through the topic quickly with precision and accuracy. At the end of each meeting, all involved should have new information, updates on various projects and related efforts, and actionable steps on anything that needs to be done next.

  2. Notes. I take a lot of notes, mostly just small little comments and words. Sometimes I write things down in notebooks I have. The vast majority however all are markdown in a git repository. Sometimes it's just a git repo that just stays on my local machine, but either way it's a repo with notes in markdown that I commit to regularly. These notes I write in a way that it can be mutated into a checklist of action items and quick to do pieces of research. I include links and related material. There is one part of this note taking I do that is somewhat counter-intuitive. Once I write notes I almost never look at them again. One of the reasons I write, either in markdown or by hand, is that it simply sets the key meeting topics, conversations, and research notes to memory. I then take action from my what is rolling around in my mind.

  3. Keep things short, concise, and to the point. Ever work with anybody that has ADHD, Dyslexia, or other related considerations? As someone with these features I've learned a few very important things about meetings, conversations, and planning. Have shorter rather than longer meetings.

    1. - most people, especially if they're not afflicted by ADHD or Dyslexia, can also sit through short meetings as well or better than long meetings. People with ADHD or Dyslexia however are gonna lose every single damned word in a meeting after about minute 10 and that's pending on a meeting being well organized!
    2. - It doesn't take long to convey a LOT of information if the meeting is being run effectively. I keep them short for that reason, in light of the fact that minds wander and several pieces of information is all that should be transferred to keep retention high! Again, I always aim for short, concise, and to the point. This works most effectively for the most people. If somebody wants long, dry, boring, and ostracizing meetings to show off the latest powerpoint skills or something my meetings aren't for them, just have a whiskey and watch a yule tide log burn for that. Much better experience, I promise!
  4. Keep meetings on schedule and limit that schedule. I strive to keep meetings to a limited time for one to one, groups, and otherwise so that a reasonable amount of time can be dedicated - in blocks of time - to research, coding, learning, and determining the next steps that are best to take.

  5. The few notes that do have data that needs to be retained or more specifically shared end up in lists or a database, spreadsheet, or in a document. This way the key information I can pass between, share, and otherwise provide to others. This follow up mechanism helps others, as well as myself, get the key action items put on the appropriate list of to do items, get action started, or otherwise assist in insuring things don't get dropped post-meeting.

My Blog! I have a personal blog at https://compositecode.blog/ that you can also subscribe to where I post additional collected material, thoughts, music, meetups, conferences, videos (like Twitch), open source projects, database work, data science, and much more.

Top comments (0)

16 Libraries You Should Know as a React Developer

Being a modern React developer is not about knowing just React itself. To stay competitive, it is highly recommended to explore the whole ecosystem. This article contains some of the most useful React component libraries to speed up your developer workflow.