Table of contents
I joined BigBasket (referred to as BB from now) in the month of Apr, 2016 as a Principal Engineer (Full-Stack Development). Little did I know that I would end up becoming one of the core members of the Platform Engineering Team (formed in 2017) as an Architect.
During my transition from Principal Engineer to Sr. Principal Engineer to Architect roles in BB's Platform Engineering team, I gained valuable insights in Impact, Working Style,Problem Solving, and Communication and I am documenting them here. These reflections are deeply personaland not intended as a blueprint. However, if they offer guidance to anyone, it would be a positive unintended outcome. (These insights extend beyond BB and can benefit those with titles like Staff/Staff+ Software Engineer.)
🔊 Impact
As you are no longer in the Sr. Software Engineer / Tech Lead position, being a Principal/Staff+ Engineer your impact circle is wide now. You may lead more than one service team or more than one product. Be ready to juggle.
You may end up working on a project that could very well be spun-off into their own dedicated teams.
Projects with bigger timelines/lengths get assigned/picked for you, over time.
Hence feedback cycles are long and costly. Be aware of this risk and plan counter-measures.
The more strategic / challenging things become, the more stretched or spread the tasks become (across various teams). Timeline need to be estimated in better ways. Have end date in mind always and connect the dots backwards.
Many a times dates/constraints nurture us to simplify and innovate.
Be ready to form your own team vs having favourites.
Periodically try to detach yourself from whatever task you are specifically working on and see the world view. Also realize that focus is the only path to freedom.
-
-
Frequently review the “Priorities”. As Mahdi Yusuf put it, “Plans are nothing, planning is everything”. Ensure your tasks are falling into one of these 4 quadrants 👇 and act accordingly.
Remember that Impact holds more weight than title. However, titles hold significance specifically in situations of conflict within a room or a team, where a definitive decision needs to be made.
🏗️ Working Style
You got to be extra thorough. Don’t have any assumptions whatsoever. Be it simple prototype you are trying to build, or demoing a tech spec of a strategic product or doing a critical service rollout, or solving a multi-minute outage of a critical data component…. Be thorough.
Depend on yourself more. The more higher you grow, the more alone you will become. Unfortunately. Get comfortable in finding answers yourself. But don’t sit in a cave for far too long. Seek help when you run out of options.
The more higher up you are, the higher level of harshness (of feedback) you receive.
Be an active contributor in the meetings you were invited. If you don’t have any big role to play in the meeting, don’t bother attending. RSVP: No.
- Always ensure how you can help/improvise what is out there.
Always have a backup plan. For any larger rollout. If things go south. Not like one experiment is the backup for one other. But inside one experiment, follow backup approaches.
As the best book on Staff Engineer mentioned you would be
Writing Code+Setting Technical Direction+Mentorship and Coaching+Injecting Engineering Context into Org decisions. With this multi-faced experience eventually you may lead certain strategic value projects.Be the Glue engineer and an awesome builder sometimes.
Respect should be earned, not demanded. Replace authority with influence. Ignore your title and back your arguments with real experiences/data. Move people with your conversations.
To be a good leader, one has to be a good follower.
🤔 Problem Solving
You are expected to solve complex technical problems independently. You should possess excellent analytical and problem-solving abilities, be able to identify root causes, and propose innovative solutions. Your problem-solving skills should extend beyond coding and include areas such as system design, performance optimization, scalability, and reliability.
Jack of many, but master of some. Along with deep knowledge in a particular area, having a breadth of experience across various technical domains will come really handy.
You will find less time to code for sure. But you are not very far off from coding something yourself.
Remember that your job is not just about solving (problems) through code. Come to consensus with it fast.
Pay more attention to Proof of concepts, Short scripts, tiny frameworks and hello-world apps for quick reuse. Faster iterations on the foundational blocks is always a killer advantage.
Always back your decisions with data. No one cares about your affinities/interests or your ego. Data should always drive decisions. Period.
You should be empathetic. Being a senior sometimes it satisfies our ego to rewrite the code that is written by your colleague without even talking to them. Sure, you may have the best possible optimisation on the planet. But Software Engineering is more about people and less about code. If you understand Big-O complexities, then Ego is like
O(2^n)while poor code isO(n). You will hurt feelings easily. See if you can recognise this in (or ahead of) time and offer solutions. Figure out all possible alternative ways. Pick the ways that cause more collaboration and less struggle.Other engineers may make poor technical choices. Educate instead of ridicule. Give constructive feedback without personally insulting someone. Once again, remember Software Engineering is more about people and less about code.
You should be adaptable, not just with tech, but more with people. You should be happy if the junior engineer you helped gets credit. You should be happy in receiving constructive criticism of your code. You should be able to calmly onboard with an org’s decision that you disagree with. We have thick skins and aren’t concerned about looking right all the time.
Don’t focus too much on shiny tech. (Technologies come and go. Foundational principles remain.) Focus on the core. Focus on simplicity. Focus on minimum viable architecture (that creates a minimum loveable product). Boring technologies work. Period.
Don’t just complain, but instead provide solutions. Lets say, you found one of your dependent services is down and blocking your flows ? Try to dig deep, collaborate with them and ensure you take steps towards identifying a solution to the problem.
We should be opinionated sometimes. Seniors like us should give opinions. Loud and clear. Don’t shy away from them. Give your advice confidently, but politely.
Record everything. Save artefacts. Right from your dotfiles, to containerized setups, to runbooks, to architecture diagrams, to multi-month project plans, to the points you want to discuss in upcoming
1:1s, to feedbacks you want to give to others, to the things you did as “glue work” that improved something, record anything and everything. You will need (and reuse) them some day, for sure.Be a partner in creating value. Not a roadblock. Demonstrate that you want to say Yes, instead of looking for reasons to say No.
View every outage as a learning opportunity. Embrace them without fear. While you don't anticipate them eagerly, seize the chance to learn when they occur.
🗣️ Communication
Over time, you will get influence in the company and you have to consciously use it for good.
Don’t be a brilliant jerk. Because everyone loves to take a friendly B engineer, over a jerk A+ engineer.
You will have to communicate more and more. Be watchful of what you are speaking and not-speaking.
You are not quite a problem solver alone all the time, but more like a force multiplier sometimes or even majority of times.
i.e.. You should be an enabler sometimes. So ask (right) questions more and make the teams solve problems themselves.
But ensure you are approachable. Like a geeky friend, but not like a school principal. Strike the balance. (I got burnt multiple times on this topic specifically, before I started working towards solving it.)
Write a lot, draw a lot, talk a lot, be creative. Right from organizing your todo list, to drawing architecture diagrams, to plotting a timeline of long projects with detailed person vs task granularity, to giving tech-talks internally and externally, to blocking your zen time vs meeting time, to perfectly crafting a root-cause-analysis (R.C.A) document for an outage, try to get your hands full on these. They give clarity, inspire you and everybody.
The more higher you grow, the more you get to work with different people, with different skill levels and diverse expertise. Again don’t be a brilliant jerk. Sometimes you have to interact/support a fresh college graduate with the level of humbleness, as you would interact/support a CTO.
Paradox. The more replaceable you become (with all the mentoring, KTs, wikis, coaching you do) the more irreplaceable, strong and influential you become. Embrace this idea. Don’t keep the knowledge to yourself. Period.
There are many more “golden” learnings from my ~7 year journey in BB. And one blogpost (no matter how long it is) will not be able to cut it 🤷. Thanks for reading anyway.
P.S: I've joined forces with Razorpay, rocking this new adventure!