Spot checking the ‘Senior’
Titles are always somewhat accurate, but they do serve purpose to the company as aggregate (for salary, differentiation, segmentation), but they are not a complete reflection talent. Here I would like to share my internal compass for my own career journey.
On Execution
- A Jr. says ‘Yes’ and delivers a quality project.
- A Sr. engineer can occasionally judiciously say ‘No’, saving time and resources.
“To win without fighting is best.” — The Art of War, Sun Tzu
The point is not to avoid the battle, but to understand the objectives and achieve them without violent, costly, and uncertain means.
In a scenario where the product manager or an engineering manager is asking the team to build a feature that is “popular” with a competitor’s product, a Junior engineer jumps to work, eager to deliver by building the feature. In contrast, a Senior engineer might evaluate the feature’s alignment with the product’s long-term strategy, its relevance to the customer base, and the potential costs involved in maintenance. By saying “No” to a feature that doesn’t add significant value, the Senior engineer not only saves development time but also keeps the team focused on more impactful projects.
There are times when the team is forced into giving a timeline that is too ambitious. It takes guts to attach a disclaimer in the communication that the timeline is more likely to be missed than met. Of course, it doesn’t mean a Sr. says no to everything, but the point is, a Sr. who has always said ‘Yes’ to everything is a bad smell.
On Efficiency
- A Jr. engineer improves the iteration speed of a similar feature.
- A Sr. engineer automates the work or obviates the need to do the work.
“Work smarter, not harder.”
Naval said, almost Kafkaesque, ‘disassociate time and work’. The way I looked at it is, think like a ‘principal’ rather than an ‘agent’ whenever some work is to be done.
Efficiency in engineering isn’t just about speed; it’s also about optimization and sustainability of processes. A Jr. engineer demonstrates efficiency by improving their speed and proficiency with each iteration. Conversely, a Sr. engineer focuses on refining processes or automating tasks to such an extent that these tasks no longer require manual intervention.
I vaguely remember that Uber’s two systems involved in payment processing — core-payment and the tax system — interpreted trip legs slightly differently. There were many brilliant engineers who maintained the parallel hierarchies of nomenclature and documentation and end-to-end tests. However, there were still incidents that cost Uber millions of dollars. Then there was a senior engineer who worked across two organizations to reconcile the ‘slight’ differences in interpretation, so that all the boondoggle wouldn’t be required to begin with.
Consider a process where monthly reports are generated manually, consuming several hours of an engineer’s time. A Junior engineer might streamline this by creating templates or scripts that reduce the time taken to compile these reports. On the other hand, a Senior engineer might automate the entire reporting process.
On the Ownership
- A Jr. knows all the requirements.
- A Sr. knows the Customer.
“Management is doing things right; leadership is doing the right things.” — Peter Drucker.
Drucker talks about how leaders create impact through strategic insights into the customer. The first step for these insights, to put the strategy on hold, is knowing and empathising with your customer.
Ownership in engineering goes beyond merely completing tasks — it’s about understanding the broader impact and aligning work with customer needs and business goals. A Jr. engineer demonstrates ownership by reading/mapping the technical requirements for the tasks. A Sr. not only does that but also embodies ownership by understanding ultimate customer perspectives, preferences, and pain points, ensuring that the solutions developed truly meet the users’ needs.
One more smell test is an engineer’s ability to identify the smallest customer segment that is using the feature or product built. A Sr. must also be able to reason and explain “why” the customer needs a certain feature.
In the Uber Eats Menu development, when we were going through the first major rewrite, we came across an ingenious usage of the ‘notes’ attribute assigned to a menu item in India. The operations team was using it for price calculation purposes. But the same attribute was being used by other countries to store actual notes about a menu item. Initially, we could have continued to maintain the field and create a ‘note2’ field for others, but the tougher work, suggested by seniors, was to create/educate a system that lets one remember the old prices without relying on the hack that used outside Excel formulas.
On the Coaching
- A Jr. seeks others to teach often with direct instruction and guidance on what they know.
- People come to a Sr. to get help on what they need to know. People already know a Sr. as an SME in the field they are seeking help.
“The only way to go fast is to go well.” — Uncle Bob
When more folks are willing to rise to help each other, they are automatically and constantly upping the bar for their knowledge, and this is the only long-term solution for the dreaded ‘unknown unknown’ kind of issues faced by all.
Many companies have nominal onboarding processes where the assigned mentor does the bare minimum, often motivated by ticking off the ‘mentoring’ box on their resume. In companies with the infamous cutthroat culture such as Amazon, some people could get actively misdirected.
Then there are people who are natural leaders and are seen as Seniors in their respective fields; they have (A) built knowledge (which many have aplenty) and exude (B) willingness to share the knowledge with as many people as possible. Gathering knowledge of a domain or technology or product itself is not easy, but people wouldn’t know about it automatically. Then the engineer has to venture out to share with others the knowledge and willingness to help.
- Conducting workshops on tools used for certain development aspects
- Writing comprehensive wiki pages, well-structured and regularly maintained
- Giving site, org, or company-level talks on things one has experimented with or achieved
- Writing external blogs, company blogs, white papers
- Answering questions and building a profile on StackOverflow
One of my default questions to almost all seniors whom I have interviewed is if the candidate has ever used StackOverflow (red flag if you haven’t), and if you claim to like to help other people (red flag if you don’t), what effort have you put to help folks on SO?
After one has done one or more of the preceding things, now it is the beginning of some folks who may come to the engineer to seek help. And a few among them will actually get some value. These are the happy moments to be counted towards mentorship and technical guidance.
This article has grown much longer than I anticipated and there are another few topics I might cover in another post.
Some other differentiators between junior and seniors could be —
- On Decision making — Of ambiguity, long term thinking, forest and tree
- On Innovation — Adoption versus ideation, proposing, experimenting
- On Risk management — conservative versus risk roster, anticipating risk, choosing risks, prioritisation and classification
- On strategic Thinking — Applying strategies versus being able to creation vision-mission and strategy with long term roadmaps
- On Technical depth and breadth — The shape of a T. How broad is the T (AKA breadth of knowledge with decent depth in each respective area)
- On Communication — from presenting the project, work to Stakeholder management and team representation. Identifying stakeholders and their individual PoVs.
- On Adaptability — Adopting to process/team/culture to shaping and building process/team/culture.