harisrid Tech News

Speak less, and listen more.

Being a senior engineer across companies has been both an amazing experience and an arduous experience. I’ve gotten more used to the requirements, roles, and responsibilities of the position, but I still notice gaps and places where I can upskill more. Alright, let’s dig and dive in!

My Personal Story of Growth

My growth into this role wasn’t easy ; there were definitely growing pains. I faced challenges with feelings of frustrations in adopting new day-to-day habits, understandings, and workflows. I had to learn how to change my habits and re-architect my calendars to accommodate the role’s needs . I’ve had to learn how to better leverage block scheduling to redesign a calendar to work with others. I had to learn to collaborate more with my Product Manager to create feature-trackable tickets and tasks, where they both communicated the most appropriate level of context across audiences – technical and non-technical – and needed to ship features.

The hardest skill of them – “ACTIVELY LISTEN – AND SPEAK LESS”

I also had to learn how to engage in more active listening. Coming into the role of senior engineer, I imagined that I would be the one “calling the shots”. I imagined that I had to be the main talker in the discussions or conjuring up the full design schematics. That I’d have to behave like the sole person who says to their team “Here’s how we do everything “under the sun””.

I was absolutely wrong!!! What was I thinking! Oh my god!!!

Nowadays, I speak less – I focus more on soliciting input from others, across all organizational roles and levels. I’m amazed how much others can meaningfully contribute – staff engineers, senior staff engineers, managers, tech leads from other teams, and even junior engineers . It’s amazing to see systems and problems evolve when you enable your peers to drive the conversation and the “take the lead” in their expertise areas. The best example was one week where I personally saw three individuals ( names not shared for journalistic integrity 🙂 ) in my design meetings scope down a system and help me create three tickets – each focused for three different phases of work – to meet a multi-quarter deliverable .

WOAH!!!

As a senior engineer, it’s become my responsibility – in design discussions that can go across a week from half-an-hour to one-hour long – to “hold the space” and let the other participants ( typically more experienced in their domains ) drive the conversations, the questions, and the answers. I take on the role of an observer or a note taker; I combine the best of their inputs to make the set of decisions needed to evolve our team’s understandings of business problems.

Meeting Role Expectations

1. Tickets and task creation – coding features is easy, but solving the right business problems and translating those into code features is hard. A single person – such as a PM ( product manager ) or a direct manager – can not bear the sole responsibility to figure out what their organization needs to accomplish. It’s not pragmatic and it’d never scale!!
   Imagine a worst case scenario where on a 11-person team – with 1 PM and 10 engineers – that each engineer asks the PM to figure out what the team should be doing. Nope, it turns out that senior and senior-plus engineers need to collaborate with their product teams and management chain to figure out how to steer the ship. Collaboration with PMs, PPMs, and other parties on long-term, multi-quarter deliverables matters more.
2. Doing work – to figure out, not do work – sometimes, your work will involve figuring out NOT TO do work. Wait what! But I just poured hours in design discussions, reading through code, and setting up meeting agendas. And I ended up finding out that … we didn’t even have to execute on a task. Wait, we don’t have to handle all data sources? We don’t have to build something that already exists :-O ! WHAT!!!
   Yep this happens. And it’s not a bad thing. Welcome to the R&D ( Research & Development ) side of engineering. It means you ( and your collaborators ) are being smart. Turns out there’s a lot of work that was done to figure out not to do work – those 16 hours you spent over two weeks helped you avoid multi-quarter efforts in the hiding :-O . Woah, your team gets to focus on more pressing deliverables instead. It also presents as an opportune time to make good write ups on your R&D.
3. You’re no longer “just a coder” – being a junior engineer means getting to spend most of your time writing code or reading code. I’d argue that 80% of time as a junior engineer is spent deep in code bases : reading code or writing code. But the higher your level, the less time you’ll code – you’ll either naturally transition or get forced by meetings with others to more high impact tasks : designing systems and infrastructure, junior talent mentorship, code reviews, navigating ambiguity, and design documentation. Don’t go into the senior, staff, or principal level roles if you want to code 24/7.