harisrid Tech News

And I guess a bit about how I run my meetings 🙂

Hmmm this is a really good question. What’s my role?

I think I wrote about this a while ago, but as a senior engineer, I used to envision my role entailing a “calling the shots” frame of reference. That my decision-making would be top-down, and that leadership meant making the majority of decisions.

But I’ve transitioned away from this parochial, limited mindset.

My role is to be a coordinator or an orchestrator – one who listens closely and careful. I always ask myself the most important question : How do I best understand the background of individuals – or for that matter, groups of people – and collaborate with them to achieve an organizational goal?

It’s organizational thinking at its finest.

My job is to work at a higher-level and to figure out how to leverage the domain knowledge and expertise of others to tackle a problem. And I think it’s actually really fun; I find it tremendously rewarding. I like to joke about this in my head, but oftentimes, the position entails taking a more backseat role, as a passenger, and see how your collaborator drives, evolves, and problem-solves¹ :-).

So what do I like to do?

Oftentimes, I schedule a 30-minute or 1-hour meeting block with a delineated agenda stating the discussion leaders and the material they’ll cover. Doing so enables me to pick up enough signals to steer planning.

In other meetings, I listen more actively, take meticulous notes, and ask a few guiding questions. I’ve learnt that speaking less, and listening more, matters, because there’s a lot of information that one needs to parse in order to solve problems accurately.

A Short Example

Ok, well this just sounds ambiguous and up-in-the-air, so I’ll provide a short example.

I’m on a recent project entailing Airflow DAG Automation work to scan and then to export sensitive data elements, and to do so requires working with three major components – scheduling Airflow DAGs, evolving backend API endpoints, and writing the correct query for edge case scenarios. Yes I’m experienced, but I’m also unfamiliar with all knowledge areas . Luckily, I’ve identified individuals – inside and outside my team – who know their domains. Which means that I can schedule meetings – 1:1 or group – with the subject matter experts to establish foundational context for creating tasks or to execute tasks 🙂 !

I don’t know things perfectly, but, I do know how to get the ball rolling in what looks to be the right direction.

The Role’s Challenges

But what would you say make this tricky? Everything you wrote seems obvious, doesn’t it?

Not exactly.

( What are you asking for? ) – The first challenge is to know what I’m asking for – to know what’s needed. I think it’s the best skill and it’s a three-fold skill : to ask the right question, to provide the most accurate level of supporting context, and to communicate your business needs to someone. Analogize it to a LLM and prompt engineering or Google Searches – the better your ask, the better your response.

( Who should you rope in? ) – The second challenge involves identifying the correct parties to “rope in” so that they’re ramped up. Long-running efforts are naturally collaborative, and members need solid understandings of what’s going on to reduce feature time-to-delivery.

( How do you get alignment? ) – And finally, the last challenge – group alignment : to get buy in/consensus and to healthily resolve technical disagreements. Because frequently, we operate with imperfect solutions and dissenting opinions permeate everywhere. Especially from questions like”What’s our scope?” or “What should we build out?”

Footnotes

1. It’s fascinating to see how another brain in real-time works, isn’t it? ↩︎