This post is about my management philosophy & default style (evolved over years & continues to evolve)
Management Philosophy & Evolution
My journey started with studying computer science for 6 years (2000-2006), 2 years in high school and 4 years in college, graduated from IIT Guwahati in computer science in 2006, after that have been working for last 20 years in the software industry, with first 10 years running startups (first one in advertising and second in communication domain), next 10 years working in fintech domain at larger organisations like Flipkart, Razorpay and Rippling.
The high level management philosophy I have followed in a nutshell is that, for effectively managing something (org / product / system / project / initiative / self etc.), the core competency needed for that something (can be tech skills / product capability / domain expertise / awareness) is primary and management skills or tactics are only supplemental. Management can’t operate in a vacuum and requires heavy contextualization to be effective. I have always focused more on learning from every experience (failures & successes) than to form a fixed lens or worldview on management.
Focus Dimensions / Axes
The following dimensions are basically the orthogonal axes for focus, which enables thinking of management as basically doing some level of trade-off on these 2 dimensions of focus.
Impact <> Excellence
This axis in simple terms is outcome focus. Impact being concrete / practical / short term / unsustainable focus, while Excellence being the aspirational / ideal / long term / sustainable focus. Excellence is divergence from reality towards ideal while impact brings convergence back to reality. Shifting focus from impact driven culture to excellence driven culture given move from smaller startup in advertising & communication to larger organisations with mission critical charter, heavily oriented towards fintech domain.
Impact-drivenculture - Prioritizes shipping features and outcomes that move business metrics and customer value. Shorter feedback loops, experiments, and clear outcome ownership are common. Excellence-drivenculture - Prioritizes craftsmanship, technical quality, maintainability, and best-practice engineering (tests, architecture, reliability). Focused engineering / product / operational excellence initiatives increases long-term velocity and product quality but sometimes in short term, can be mistaken for “engineering for its own sake.”
Excellence combined with Impact - It’s important to build resilient engineering practices (excellence) while keeping them tightly linked to business priorities (impact), few examples of losing track of this
Platform building is a good example of losing sight of impact & going into rabbit hole of excellence, sometimes diverging from reality and struggling for adoption later
Getting stuck in wrong trade-off discussion around quantity vs quality (mostly need to balance with hybrid approach) or breadth vs depth (balance required with hybrid approach), also sometimes one enables the other - high quantity of knowledge can enable quality, heavy depth on fundamentals will enable breadth of experience
Resilience is mainly used with reference to ability to recover from failures , basically the engineering practice which can recover when a person/process/product/system failure happens, one good example is practice of having checklist (design/development/deployment/operation) which works well well independent of the person, process, product or system. Another example is peer review (product spec review or tech spec review or code review, incident postmortem review) which prevents blind spots and improves rigor, much earlier in the lifecycle.
Excellence takes much more time than impact expectation in most cases and many times impatience gets many quick wins and smaller but visible impact, which makes people discard excellence as a theoretical and not valuable concept.
Execution <> Innovation
Execution being the progressive / realistic / immediate day to day focus, while Innovation being disruptive / unreal / beyond time horizon and sustainability aspect. Execution is the way to do things the proven way. Innovation is what breaks the existing cycle, out of box or out of cycle thinking is what results in exponential or step-function change.
Execution focused culture - incentivises & rewards high velocity work along with streamlined & predictable execution delivering consistent results which in turn reduces the risk of failing to deliver but increasing the risk of failing to innovate. Innovation driven culture focuses more on generating & pursuing new ideas while driving novel ways of working. Risk taking is appreciated instead of predictability & consistency.
Combining execution & innovation is challenging and only few people I have seen being successful at this, with clear understanding of when & what kind of innovation is feasible & will bring more value than simpler & incremental execution.
The management focus I have followed has significantly evolved over time, skewing more on Innovation > Execution, Impact > Excellence in the first ten years or my career running startups, while now after working in fintech industry for last ten years, the management focus shifted on the Execution > Innovation, Excellence > Impact, which also reflects the uncompromising need for excellence in finance domain due to higher demand of accuracy & reliability while bit less emphasis on innovation.
Underlying Principle
But the underlying principle for the above 2 dimensions is truth centricity or truth alignment, which is the most critical aspect I have kept in mind and it’s not another independent dimension.
Truth seeking - Information can mislead - very popular & common concept, evidence based approach to knowing, experience based learning, not taking words as wisdom & trust as the multiplier or signifier for truth. It basically means knowing the blindspots & pitfalls, having awareness of the unknown, while respecting & acknowledging ignorance. After relying on hearsay information once which then badly backfired, I have ever since ensured that I always have clear evidence in form of screenshot, dashboard, data analysis for statements made. This has acted as a forcing function for truth seeking.
Truth evangelizing - Be a friend not friendly - providing truthful feedback without sugar coating is more helpful than being friendly. A senior individual in general needs frank feedback but also a bit of debate to reflect, as a person with 10+ years experience will not change unless strong self reflection is triggered by something, to focus inward & put effort towards changing both behavioral & situational aspects.
Truth alignment - Truthful with reality - this is slightly different than seeking & evangelizing as even with sufficient evidence + feedback + reflection, there can still be misalignment of understanding of truth vs reality of truth, this divergence is mainly caused by delay in decision or lack of effort or out of control constraints, to converge truth in understanding to reality. This is more like zooming out to see the misalignment and taking steps to bring alignment.
Useful Tenets
Structured thinking is very important but equally important is to keep flexibility to go beyond the structure which has been put in place by yourself or others to not always think inside the box. An example is the “Why → What → How” framework, a simple hierarchy of decision-making
Why / Understanding — start with worldview, intentions, hypotheses. Only after clarifying “why,” define what you aim to achieve.
What / Objective & Key Results — once you know the why and outcome metrics, you set what needs to be done (goals, outputs). ‘
How / Implementation — only after “why” and “what” are clear, you decide the “how.” This makes your implementation more flexible and grounded.
This order helps to avoid tunnel vision & narrow focus on implementation without clear objective or purpose — a common trap in engineering work. But knowing the limitations of this framework (investment required should justify the ROI, this can’t reduce the risk of unknowns & uncertainty), along with the underlying assumptions (availability of knowledge & time to move up this hierarchy for decision making), is critical to avoid using it as hammer to nail every problem.
Embracing, Facilitating But Monitoring Change is an important way to learn, unlearn & relearn while also keeping a boundary around change.
Change has many layers / aspects and so do lack of change - these aspects tend to be different at different time horizons. Example - thinking nobody changes may be correct in the short run, but is wrong in the long time horizon as it takes a long time for people to change. Another example - Change in skill (upgrade or degrade) will sometimes take significant time but monitoring closely can easily show trends in a smaller time window to manage soon.
Change / Lack of Change has many dimensions - can (constraints), should (utility), will (motivation vs effort), want (awareness of impact) and when (timeline) are some important ones. Monitoring or observing changes with some detachment has helped in being aware & having less resistance to embrace change. Many times changes are incorrectly perceived due to false understanding of truth / higher invariant, which can enable discarding the changes in the lower plane, as being contextually not relevant in higher planes.
Change / Lack of change is not always controllable - as in the popular serenity prayer, wisdom is to know the difference between things that you can change and things you can’t change, along with having courage to change things you can while having acceptance for things you can’t change. One practical example in engineering is changing people’s behaviour is far more difficult than changing product / system behaviour. But if constraints make product / system change impractical / infeasible, it will be prudent to train people even with some difficulty.
Celebrating, Respecting, Encouraging Higher Goals is a critical part of building a happier & healthier individuals, teams & org.
Higher goals like diversity, meaning, growth need encouragement & celebration but without mandating it as to make it feel like a burden.
Diversity of thoughts, culture, background, practices, personalities, demographics are important, should be celebrated and respected as long as it’s in a contextually acceptable range for the team and organisation but not mandated. Merit and skill will always beat any mandate or criteria in long term when it comes to probability of success in the role, and the talent density being an important factor for success as a group, it’s important to not have mandates which affect talent density
Meaning brings satisfaction in a job, but it’s still a higher goal which should be pursued by individuals and not mandated as every thing can not have deep meaning but they will still provide heavy tactical utility. Sometimes encouraging and facilitating higher goals doesn’t work well when value is not understood, shown and appreciated, which can’t be solved with a mandate rather than a cultural shift.
Individual growth is a higher goal for people to pursue at their own pace, making it mandatory or expected, having an aggressive timeline results in many unwanted side-effects, people doing career growth hacking with promotion oriented projects, prioritising personal growth over team and organisation development. Have seen some examples - an engineer becoming EM to only realise they didn’t want the manager’s adhocness, schedule & pressure, another example of engineer pushing to get to next level but without looking for step function change in way of operating.
Higher goals along with talented people are generally very important to create teams working without too many rules and processes, just having talent density doesn’t necessarily bring discipline to succeed, it’s the higher goal which inspires people.
Thinking Tools - Have always been fascinated by thinking tools (particularly after reading “Intuition Pump & Other Thinking Tools”), as deep thinking is difficult & requires advanced tools.
Primary thinking tool like mental models like circle of core competence, falsability by experience, first principles thinking, higher order thinking, occam’s razor, ranson’s razor
Another very useful tool is developing intuition (heavily used by Andrew Ng in the ML specialization & Deep Learning specialization courses) and using intuition pumps (something which pumps intuition in desired direction).
Another one is using Nuance as the thinking tool, which can help in avoiding early conclusions & strong opinions, that are generally a way to disguise ignorance or may be sometimes skip deep thinking, also preventing tendencies for prescriptive thinking.
Default Management Style
I have been managing very diverse teams (by experience, talent, culture etc.) while working on varied challenges and the management style has changed / adjusted significantly depending on various scenarios. There is some benefit in general to have a default style of management to avoid daily surprises but it can soon become dogmatic, flexibility & adaptability has been a key behavioral trait to keep.
Default Style - The default style I follow is being supportive to the next set of leads whenever possible & feasible - supporting my team with a combination of inspiration + guidance + verification, while providing team with framework & mental model to be as much independent & autonomous as practically possible
Inspiration is more of long term strategic vision / mission / org / charter etc.
Guidance is more on tactical management challenges around operation / execution / org / talent / communication etc.
Verification is more for ensuring things don’t fall through cracks over time
While limiting the deeper daily intervention, only when the situation is in crisis or can get into crisis soon, and when the failure will be detrimental
Important Aspects - Few important aspects in managing larger teams with 2+ management layer requires
Growing senior talent - Creating opportunities for folks which are aligned with business while also stretching them to make step function changes in their learning & career is a critical way to retain senior talent while also helping them grow.
Risk management - creating next set of leaders & managers is generally not enough & there is need for strong succession plan, along with shadow / reverse shadow with them is critical to ensure continuity of context
Role model behaviour - displaying role model behaviour to solve problems which can be cleanly replicated - excellence initiatives, ticket commander process, design and post mortem reviews, domain expertise
Long term alignment - Aligning product charter / system design / org structure at larger org, team and individual level for long term success, without overlooking the current realities and constraints
Momentum driven execution - Generally momentum is what lifts-off large initiatives spanning teams and using momentum driven execution has helped in getting projects to a critical milestone - first & last mile delivery always need momentum.
Scenarios & Examples - Some examples using above management style during last few org experiences helped in ensuring
Stalled Projects - Have several examples of unblocking stalled projects across previous companies. Meta learning has been that momentum on those projects got lost, either due to past failure or the lost project driver, bringing back some excitement + getting a few smaller wins + making incremental progress helped in moving these along with establishing clear project driver for long run (not always project lead as most the stalled project has spanned across teams).
Turnaround & De-Risking Critical Path - Gone through a few examples of turning around areas (team + product + system) which have been struggling for sometime. Also, removing existential system / product / market / business risk (which can be due to various reasons). Meta learning has been to evaluate & understand situation with deeper thinking & planning on risk management + sustained execution, as these situation need multiple short term wins with strong focus on long running goal
Performance & Growth - Performance gaps are not always due to lack of intent or agency or even skill set, it’s due to lack of ability to bring impact or drive excellence. Generally people in tech companies work hard to get faster growth, but without strong sponsorship (sponsor is not just mentor or coach), it takes a lot more time. Meta learning has been that a combination of inspiration + guidance + verification is what helps senior ICs & managers grow.
Alignment & Process - Alignment & process reduces chaos and provides structure to operate. It doesn’t always directly cause impact or excellence, but without it have seen things getting very inconsistent. Meta learning has been that without thought through structure, freedom means innovation when no pressure but under pressure things become inconsistent and inefficient.
This post is about why nuanced, integrative thinking often produces better insight & more predictable outcomes than simpler prescriptive or one-sided thinking, with few examples for practical guidance around using Nuance as a thinking tool.
Background
Why Nuanced Thinking Often Beats Simple Prescriptions ?
Simple conclusions, prescriptions, or opinions have an obvious appeal — they’re faster to produce, easy to state, easy to remember, and easy to repeat. Nuanced thinking, by contrast, demands patience: it weighs tradeoffs, embraces complexity, and resists the illusion of certainty & clarity.
Generally reaching a simplified conclusion, advocating for a well defined prescription and forming a clear opinion is slightly easier than the nuanced approach, as it requires deeper understanding of the tradeoffs, which takes a lot more time and energy to think & master.
Taking a more nuanced approach which combines multiple frameworks (like in the example of breadth vs depth) will enable deeper understanding, reliable & stable decisions along with predictable outcomes.
Few Deep Dives
Skill & Learning: Breadth vs. Depth
Jack of all trades is master of none, but often better than a master of one.
The classic example is the breadth vs depth, which has been a constant debate over a long time and frameworks have skewed on either breadth or depth, more than often inclining towards the depth (given the distraction due to the internet, lack of depth is a big problem today). Even the popular saying Jack of all trades is master of none presents an incomplete picture compared to the original saying Jack of all trades is master of none, but often better than a master of one.
Depth-First (Specialist) Approach
Becoming world-class in a specific niche
Focused expertise in smaller context
Particular professions require it (e.g., neurosurgery, quantum physics)
Risk: Tunnel vision; may miss adjacent opportunities.
Breadth-First (Generalist) Approach
Diverse skills and perspectives
Flexible adaptability across wider context
Innovation through cross-domain synthesis
Risk: Lack of deep mastery; shallow outcomes.
Nuanced Thinking: “T-Shaped” or “I-Shaped” Thinking
A powerful integrated model — often used in design and management — is the T-shaped skill set:
Vertical stroke: Deep knowledge in at least one core area
Horizontal stroke: Broad familiarity across multiple domains
This lets a strategist or problem-solver apply deep expertise while connecting dots across fields.
Product & System: Velocity vs Quality
Simplistic Problem Prescription
“Move fast first, clean up later.”
This assumes following but all are false at scale
Cleanup is always affordable later
Technical debt interest is linear
Organizational context remains stable
Nuanced Thinking: Product-System Evolving View
Velocity and quality are temporally coupled, but mostly not oppositional. More nuanced strategy
Early phase:
Bias toward speed
But constrain blast radius with guardrails
Growth phase:
Reallocate capacity to foundational systems
Maturity:
Invest in reliability, tooling, and platformization
The mistake is not in moving fast — it’s moving fast without adequate architectural guardrails & forcing functions. Velocity vs quality is a false dichotomy, as without architectural quality it becomes very difficult to even achieve execution velocity.
Nuance As A Thinking Tool
Reaching a conclusion is relatively straightforward. Advocating a prescription is even easier. Forming and expressing an opinion is easiest of all.
What is genuinely difficult—and disproportionately valuable at senior levels is holding nuance in thinking. This has also become important in the AI/ML/LLM world, given the models today respond with so much confidence (even though on the surface, the response definitely shows high level of nuance with pros / cons, many dimensions covered in analysis, but it lacks self-doubt with carefully looking into the blindspots & pitfalls).
Nuanced thinking requires sustained engagement with tradeoffs, second-order effects, higher order abstractions, evolving constraints, and human systems. It demands time, energy, and a willingness to remain uncomfortable longer than most people prefer. As systems grow in scale—technical, organizational, and product-related—the difference becomes clear: most meaningful failures are not caused by lack of intelligence or effort, but by insufficient nuance applied too early.
Cognitive Comfort of Conclusions
Simple conclusions feel productive because they compress complexity into clean, portable statements:
Microservices scale better.
Optimize for velocity early.
Depth matters more than breadth.
Strong consistency is safer.
Each of these statements contains a meaningful insight but none of them is universally correct. Conclusions remove context while prescriptions flatten constraints and opinions replace inquiry with confidence. They are attractive because they reduce cognitive load and enable fast alignment—but they do so by discarding information that often matters later. At small scales or in controlled environments, this tradeoff is acceptable but at scale, it becomes dangerous.
Engineering - Not an Optimization Problem
At junior levels, engineering often feels like an optimization exercise: choose the best algorithm, the fastest database, the cleanest abstraction. At senior levels, this framing breaks down.
Engineering becomes the discipline of navigating tradeoff surfaces in evolving arenas, not maximizing single metrics. Every meaningful decision exists at the intersection of competing forces:
Latency trades off with cost.
Availability trades off with consistency.
Velocity trades off with system entropy.
Depth trades off with adaptability.
The core mistake is not choosing one side of a tradeoff. The mistake is pretending the tradeoff does not exist or assuming it will not matter later. Real systems are socio-technical systems. They include software, infrastructure, teams, incentives, users, and organizational dynamics. Optimizing aggressively along one axis almost always introduces instability elsewhere. This is why prescription-driven architectures often degrade over time—not because they were incorrect, but because they were too certain, too early, and too narrow.
Breadth vs Depth Is a Framing Error
The breadth-versus-depth debate has persisted for decades because it offers a simple story with clear sides. In an age of distraction, depth is framed as virtue. In fast-moving environments, breadth is framed as survival. The nuanced reality is less satisfying but more accurate:
Depth matters most at irreversibility points. Breadth matters most at integration points.
Data models, consistency guarantees, security boundaries, and core abstractions are expensive to change. These deserve depth, rigor, and restraint. APIs, workflows, cross-team interfaces, and product interactions demand breadth, contextual awareness, and synthesis across domains.
Senior engineers are not generalists or specialists in the traditional sense. They are selective specialists - deep where mistakes are costly, broad where coordination and alignment dominate. This is why the commonly quoted phrase is misleading in its shortened form. The original version matters more: A jack of all trades is master of none, but often better than a master of one.
Top-Down vs Bottom-Up Is About Timing, Not Ideology
Top-down and bottom-up approaches are often presented as opposing philosophies.
Top-down emphasizes clarity, direction, and alignment.
Bottom-up emphasizes discovery, feedback, and realism.
Both approaches fail when applied dogmatically. A purely top-down system risks detachment from reality. Decisions become elegant on paper but brittle in practice because they ignore operational friction and emergent behavior. A purely bottom-up system risks local optimization. Teams improve their own components while the overall system drifts, fragments, or loses coherence.
The nuanced approach recognizes that top-down and bottom-up are complementary, not competitive:
Top-down is essential early to establish constraints, boundaries, and intent.
Bottom-up is essential later to validate assumptions, surface edge cases, & adapt to reality.
In effective organizations, leadership sets direction top-down, while execution and learning flow bottom-up. The system remains aligned without becoming rigid.
Forward vs Backward Planning Is a Question of Uncertainty
Planning frameworks often polarize around two extremes. Forward planning starts from current capabilities and incrementally moves ahead. It is realistic, grounded, and low-risk—but can easily become incremental and reactive. Backward planning starts from a desired future state and works backward. It encourages bold thinking and long-term alignment—but can ignore present constraints and feasibility.
The nuanced approach depends on uncertainty and reversibility:
When uncertainty is high and reversibility is low, forward planning dominates. You move cautiously, learn quickly, and preserve optionality.
When the destination is clear and constraints are well understood, backward planning dominates. You align decisions toward a known outcome and avoid local detours.
Mature teams will often combine both, as hybrid approach prevents both aimless iteration & unrealistic grand designs
Backward planning helps to define long-term direction and architectural north stars
Forward planning helps to execute safely, iteratively, and within real constraints
Most Decisions Age & Need Rethinking
Architectural decisions rarely fail immediately. Instead, they age—sometimes gracefully, often poorly.
What works at 10 engineers starts to strain at 50.
What works for 1M users begins to fail at scale at 100M.
What works before compliance becomes fragile after regulation.
Prescriptive thinking implicitly assumes decisions are timeless. Nuanced thinking treats time as a first-class dimension.
A modular monolith is not an ideological stance; it is a temporal one. Microservices are not a badge of engineering maturity; they are a coordination strategy that only makes sense once certain organizational pressures exist. Good systems are not “right” in absolute terms. They are right for now, with an explicit understanding of when and why they will need to change.
Product & Engineering Failures Are Misalignment Failures
Many failures are labeled as engineering problems, but in practice, they are often product–engineering alignment failures.
Velocity without architectural guardrails compounds entropy.
Quality without urgency stalls relevance.
Feature delivery without system health creates fragile success.
The nuanced view rejects these as binary choices. Velocity and quality are not opposites; they are coupled across time. Moving fast early is often rational—provided the blast radius is constrained. Investing in foundations later is essential—provided the product has demonstrated real demand. The failure mode is not speed. It is speed without a plan for its consequences.
Predictability Comes From Explicit Tradeoffs
Systems become predictable not by eliminating uncertainty, but by making the assumptions explicit.
Nuanced thinking teams document:
What they are optimizing for today
What they are intentionally not optimizing for today
Which constraints dominate the current phase
When and why decisions should be revisited
This practice converts unexpected failures into anticipated ones, and catastrophic rewrites into controlled evolution. Over time, this discipline becomes a competitive advantage, silence is not neutrality but is hidden technical and organizational debt.
The Real Marker of Thinking Maturity
Nuanced thinking is cognitively expensive. It resists slogans and soundbites. It does not fit neatly into decks or one-line principles. It often sounds conditional, cautious, and incomplete—especially when compared to confident prescriptions. But at senior levels, conditionality is not weakness, it is an evidence of understanding.
Strong engineers defend solutions.
Senior engineers explain tradeoffs.
Principal engineers design for change.
The most reliable signal of thinking maturity is not the number of systems someone has built or the tools they know. It is how they reason about questions such as:
What depends on this decision?
What breaks if our assumptions are wrong?
What are we consciously sacrificing?
How does this decision age over time?
If an answer sounds overly simple, it is often shallow. If it sounds more nuanced, it is usually grounded in lived experience. The internet rewards opinions and certainty but organizations survive on nuance.
As systems grow larger, slower, and more interconnected, the cost of premature certainty grows with them. The role of senior engineers & product leaders is not to eliminate complexity, but to engage with it deliberately and transparently. Nuanced thinking is not indecision instead it is respect for reality.
System design and product development are not about finding the “right” answers — they are about making context-aware, time-sensitive tradeoffs explicit.
Nuanced thinking:
Replaces ideology with adaptability
Trades speed of conclusion for durability of outcome
Produces systems that evolve instead of collapse
In real life scenarios, clarity is not the absence of complexity — it is many times, slightly deeper level of thinking around complexity.
This is a post on I-Shaped learning framework to build expertise
Overview
Generally for building technical & engineering expertise, the learning framework which has worked well is something like an I-Shaped Learning where there are three important components of the learning plan which are explained in the diagram below.
There is a lot of debate going on with regards to breadth focus vs depth focus. Even the popular saying “Jack of all trades is a master of none” is misrepresented today as an insult to people who are focusing on the breadth while ignoring the depth but the original full quote “Jack of all trades is a master of none, but often times better than master of one” was in fact a complement.
General guidance for the plan would be to spend equal time on each of the three components (minimum 4 weeks each) in the first iteration & repeat again for deeper learning. The plan is basically a checklist, create a copy & update each of the checklist item with specific details, artifacts like docs, mind-maps etc and individual learning.
Breadth On Fundamentals
Learning a wide range of fundamentals (computer science, coding, design & language) is very important to build mental muscle to understand different nuances & comfortably handle technical complexity as well as building a good grip on systems.
CS Fundamentals
This should be covered by any CS fundamentals MOOC course in references, follow one course & complete it, instead of spreading thin across many information sources.
Data Structures
Basic Data Structures
Understanding & practicing problem solving using the basic data structures - arrays, linked lists (singly & doubly), lists, stack/queues, min/max heaps, maps, trees. Also various data structure considerations - space, time complexity (read/write).
Advanced Data Structures
Understanding & practicing problem solving using some of the advanced data structures considerations (memory hierarchy with caches, hashing techniques, immutability, large data sets) and examples (priority queues, binary trees, bloom filters)
Understanding & knowledge of a couple of advanced algorithms from any domain like - parallel (matrix multiplication), streaming (count-min sketch), randomized algorithms (quicksort), string (suffix trees), graph (DFS, BFS), mathematical (linear programming).
Coding Fundamentals
The clean code book & the examples link in references can be a good start as it covers many of these things.
Code Design
Code Constructs
In-depth understanding of common code constructs (variable/constant, conditions, loops, functions, type/class, try/catch, thread safety, annotation) and knowledge of advanced constructs & concepts (macros, currying, trait/aspect, symbolic tree)
Code Structuring
Learn various code structuring mechanisms (modular decoupled structure, convention based structure, domain driven design based structure, tech vs functional oriented, frontend/backend structure, framework vs library structure) & list examples for each.
Coding Practices
Coding Best Practices
Learn & list down coding best practices - language independent like general (naming, readability, indentation etc), design (low coupling, don’t repeat yourself) & language specific like syntax (standard linting, using obvious not obscure constructs, nuances of constructs), semantics (exception handling, concurrency, built-in types behavior).
Code Review Best Practices
Learn & list down code review best practices - code review checklist (readability, security, structuring, test coverage, reusability), code review metrics (inspection rate, defect rate, defect density), code review automation (danger.js), code review diligence (400 lines at a time, nitpicks %), code review etiquettes (suggestion instead of command, conversation instead of fault finding)
Design Fundamentals
Design Patterns
Solid Principles & OOP Design Principles
Go through & practice some of the important design patterns like observer, strategy, adapter, facade by implementing them. Common design principles like SOLID, OOP (composition over inheritance, container structure using core + extensions / modules / plugins - for inversion of control & dependency injection)
Distributed System Patterns
Go through and learn various distributed design patterns like single node patterns (side-car pattern, adapter, ambassador), multi-node patterns (discovery, cluster management patterns - consensus algos, leader/master election, data/control plane), batch computational patterns (work queues, event based processing, coordinated workflows), distributed transactionality patterns (2-phase commit, saga pattern etc.)
Design Anti-Patterns
Code & Design Anti-Patterns
Learn some of the common coding anti-patterns (spaghetti code, god class, cyclic dependencies, copy/paste, golden hammer, dead code, scattered code, boat anchor) and code smells (duplicate code, large functions, lazy/large class, mysterious naming, unsafe type handling, side-effects)
Distributed System Anti-Patterns
Learn some of the common distributed system anti-patterns - microservice anti-patterns (distributed monolith, shared database, dependency disorder, entangled data, improper versioning, missing api-gateway) & list down reasons why these result in bad design.
Language Fundamentals
Language Independent
Programming Languages Landscape
Look at various programming language families (procedural. object oriented, declarative, functional, logic), operating model (interpreted, compiled), abstraction level from machine to humans (machine, assembly, high level), origin (academy, industry)
Programming Languages History
Many of the languages have evolution paths where sometimes in the new language, fundamental changes are introduced while other times its only incremental new constructs. Go through a couple of these like c -> c++, java -> scala, erlang -> elixir.
Language Specific
Constructs & Language Design
Language constructs starting from syntax to semantics, then looking at the overall language design. Constructs for different programming paradigms - declarative (macros, annotations), procedural (first order functions, loops, conditions), oop (type, inheritance, polymorphism, generics, reflection), functional programming (closure, higher order functions, pattern matching, list comprehensions) etc. Do this for any one language.
Language Evolution & Philosophy
Language evolution and philosophy are important to know and understand, this builds the context in which programming language has been developed. Most being open-source helps in looking at the evolution of the language & learning.
Compiler & Virtual Machine Internals
The way language and various constructs operate or are implemented in the VM, this gives a good view of the VM for doing tuning, optimisation and knowing internals like scheduling, memory management helps in debugging & troubleshooting issues.
Depth On Single Tech Stack
Important thing to keep in mind for this section is to reduce context switching & have deeper thinking to understand the journey of a tech stack well, so that the learnings here can be extrapolated quickly for any tech stack, whenever required on demand.
Tech Stack
Stack Selection
Select Tech Stack
Based on interest, select one of tech stack for deep dive (like data stack - any sql or nosql data stores or messaging stack - kafka, rabbitmq or functional stack - elasticsearch, neo4j or infra stack - docker container, kubernetes)
Tech Stack Mind-map
Mind-map for covering the breadth of the tech stack - pros/cons, high level design, when to use this tech stack, comparative analysis with competition, use-case mapping (popular use cases with understanding of why this tech stack was preferred)
High Level Design
Component / Block Diagram
Create the component or block diagram based on the HLD understanding of tech stack, iterate over it couple of times and then compare with the existing component or block diagram from tech stack developers
Data & System Architecture
Create the data & system architecture of the tech stack based on the HLD understanding of tech stack, iterate over it couple of times and then compare with the existing data & system architecture diagram from tech stack developers
Deep Dive
Low Level Design
Schema & API
Go through & list down the data schema (for meta, master & transaction data models) and various APIs (type - sync/async, protocol - rest/grpc, format - xml/json, security - authn/authz, contract - sla/limits, robustness - idempotency/degradation)
Tech Stack Components
Go through & list down the important components like language, base libraries (like lucene for Elasticsearch), abstraction layers - data, logic & api layer, underlying storage mechanism, concurrent processing mechanism (threading vs lightweight processes)
Code Level Design
Data Structures & Algorithms
Go through & list down the important DS/Algo used in the tech stack, need & rationale behind using those, what optimisation (space or time or both) these DS/Algo bring, review the space/time complexity, are there better alternatives & why.
Data/Compute, Code, Read/Write Flows
Go through & list down the important flows in the tech stack - from different point of views - data & compute, read & write flow, code flow. Create the flow diagram for the listed flows along with their inter-relationships like cross-dependencies, pipelines etc.
Evolution
Design Tradeoffs
Fundamental Resource Tradeoffs
Go through and list down the fundamental resource tradeoffs (compute, storage, memory, network, time) that are applicable to the tech stack, why these tradeoffs are important for the success of the tech stack
Distributed System Tradeoffs
Go through and list down the distributed system tradeoffs (consistency - serializability & linearizability, availability, partition tolerance) that are applicable to the tech stack, why these tradeoffs are important for the success of the tech stack.
Decision Log
Critical Design Decisions
Go through & list down the critical design & architecture decisions from inception, look at the anatomy of each of these decisions (3 fundamental parts for each decision - problem - approaches - solution) and the retrospective of decision - impact, pitfalls etc
Important Design Decisions
Go through & list down the important (non-critical) design & architecture decisions, look at the anatomy of each of these decisions (3 fundamental parts for each decision - problem - approaches - solution) and the retrospective of decision - impact, pitfalls etc
Breadth On Tech Stacks
This section is the last and open-ended, it is more like understanding the landscape of tech stacks based on various needs & use cases, mainly to be able to judiciously choose the appropriate tech stack whenever needed based on various parameters.
Considerations
Tech Stack
General
Create mind-map for the important things to consider when evaluating any tech stack - pros/cons, high level design, when to use which tech stack, comparative analysis, use-case mapping, functional/non-functional & ecosystem related evaluation criteria
Non-Functional
Go through & list down the non-functional considerations (security, robustness, stability, resilience, scalability, performance) which are important for selecting any tech stack for a given problem, why they are important & how to measure each of these considerations.
Ecosystem
Support, Community & Management
Go through & list down the ecosystem considerations like support (sponsors, core contributor activity etc), community (size, involvement) & management (managed service, paid support) which are critical for operability & sustainability of tech stack.
Benchmark & Independent Evaluations
Go through & list down the various benchmark & independent evaluations to be reviewed to be able to take more data driven & well researched decisions. For example - https://jepsen.io/ is the de-facto standard for distributed system evaluation.
Landscape
Data Stores & Messaging
SQL & NoSQL Data Stores
Go through different sql databases (mysql, mssql, pgsql, oracle) and nosql datastores like key-value stores (redis, aerospike), columnar stores (cassandra), document stores (mongodb, couchdb), graph stores (neo4j, dgraph), search store (elasticsearch, solr)
Generic vs Specialized Data Stores
Look at the datastores from generic vs specialized functionality point of view - generic (sql db, in-memory, key-value, columnar, document) or a bit more specialized (graph, search, time-series, analytical). Mind-map for considerations for a few categories.
Messaging Frameworks
Look at the popular messaging frameworks (like kafka, pulsar, rabbitmq, activemq), messaging considerations like functional (delivery guarantees), performance (throughput, latency), consumption model (pull, push), storage model (log, index)
Processing & Application
Stream & Batch Data Processing
Go through & list down the open-source stream & batch data processing frameworks like storm, spark, flume, flink, skoop) & commercially available (redshift, athena, snowflake, big-query, synapse)
Application Frameworks & Libraries
Go through & list down the application framework & libraries which are relevant for current work - backend(django, flask for python, gin, gorm for go), frontend (react, vue, angular), other framework & libraries (grpc, graphql, rule engine, workflow engine)
As the organization scales & in general also, the biggest challenge is that of decentralized decision making, these are some thoughts on how to enable this. It can also encourage deeper participation, experimentation, innovation and keeping the team driven.
Problem
The biggest challenge in the growing organization is around decision making, how to enable decentralization of decision making. When the organization is small, context is limited and most of the time centralized decision is what works well and not much alignment needed, sometimes the divergent views are not present while other times time is limited.
But as the things scale, context increases & decision making becomes more complex as well as nuanced. Teams need a framework which can enable them to take decisions without being too dependent on the leadership or experts.
Solution
Transitioning from How to What to Why or Doing to Knowing to Understanding becomes a stepping stone in moving from centralized decision making to decentralized decision making allowing people to choose what based on why and how based on what. The why (understanding) inspires & motivates the what while the what (knowledge) guides & aligns the how (doing).
The difficulty comes as there is no standard way to define these and even though the idea of moving from how to what to why seems good on paper but operationalizing it is not easy. Below is the framework to define & evolve the How to What to Why over time.
Framework
Core flows in working through anything can be done at three levels - how, what & why. The decision making is also required at each level & the most important thing for decisions in the fast changing world is the flexibility & agility to change the decision in response to new information or dynamic circumstances, for this we need to move to higher order thinking by pushing the decision to the next level. Basically when the focus is shifted to “what”, “how” becomes flexible & open-ended, similarly shifting focus to “why” makes the “what” flexible.
How / Doing / (Solutioning + Execution + Operation)
This is the implementation or in general terms tactical level which covers end to end roadmap to get somewhere by doing. It involves problem solving which itself can be divided into 3 phases - solutioning (problem definition -> exploring approaches -> finalizing solution), execution (planning, implementing & delivery), operations (production support, maintenance & evolution). This is the most important level to bring anything to life, but this level is a lot more focused on doing & lacks seeing the bigger picture of whether something is relevant for a larger goal or not.
The decisions here tend to be much more tactical in nature as getting something done is more important than to introspect/retrospect/prospect on whether it is good in the long term or not, whether it moves us towards the larger goal or not. Also, this level is more input or effort oriented instead of outcome oriented which means focus will be to think of how to do something rather than what to do, which also makes it less future proof as even if the result or outcome is not getting achieved, the decision need not be changed.
Defining what has a lot to do with knowing deeply about the problem which is critical to define the success metrics for any solution. Once the success metrics is in place, what needs to be done becomes clear but the objective along with key results quantifying & slicing the what based on time (different quarters) & space (various teams). Decisions to do “what” are completely focused on outcome & will help in making the “how” flexible as it doesn’t matter which solution brings the outcome as far as it is achieved.
Why is the highest level in the framework with focus on the reason, intention & rationale behind doing something. This is the level where civilisational & cultural lens matters, based on the environment & upbringing of the person, team & organization, the worldview will be formed which will then drive the hypothesis & experiments to make decisions based on the “why”.
WorldView - This is generally not discussed in detail and also lot of times abstract & not defined concretely as its subconsciously built in form of learnings from environment.
Hypothesis & Experiments - The hypothesis helps in making some prediction based on the world view & doing experiments to evolve the hypothesis.
General Concepts Around Decisioning
Problem vs Solution Focus
The problem & solution focus many times becomes important to be flexible towards solutions and not become rigid with a solution. It will also enable us to move from deterministic thinking to hypothesis thinking (where solution is seeked using hypothesis + experiment).
Deterministic vs Probabilistic (Hypothesis) Thinking
The hypothesis approach towards defining problem & solution is by default adaptive while a more deterministic approach might be appropriate for situations where being right is critical (even if it means to delay decision & wait for sufficient information). Probabilistic thinking enables incremental decision making by refining & evolving the hypothesis with more experiments (gathering relevant information).
Assumption Blinds vs Hypothesis Guides
Assumption is basically an implicit unknown & unproven point taken as truth while hypothesis makes that unknown explicit which is important to understand the gaps that can be there in the decision being made due to imperfect knowledge & understanding of the world around us. Sometimes facing ignorance explicitly is a lot better than implicitly claiming knowledge, which is probably the reason for many decisions being incorrect & that coming as surprise too.
Progress vs Perfection (Incremental Thinking)
In most of the decisioning cases, progressive decisions are better than aiming for perfect decisions, incremental thinking helps in evolving decisions which is more future proof.
Acknowledging Ignorance vs Claiming Knowledge
Focusing on ignorance & acknowledging it will result in seeking more knowledge & understanding of the world around us needed to make better decisions while claiming knowledge when its not there, will only result in decisions with of lot of faulty assumptions that can not only make the decision wrong but also result in incorrect learnings from those decisions.
Journey vs Destination vs Intention
The decisioning framework of how -> what -> why is also closely related to the thought process of moving from journey (process of getting somewhere) -> destination (knowing somewhere to go) -> intention (reason to be thinking of a destination). Generally people who understand intention will not be fixated on a destination and definitely will not be bothered to take a journey to any destination based on the larger intention.
Making Right Decision vs Making Decision Right
Most of the time the focus is on making the right decision which pushes us to think a lot, gather as much information as possible, create mental models & decisioning frameworks. But we need to give a lot more importance on how to make the decision right once that decision is made as it’s not always possible to see the correctness of a decision in the short run & many times as it takes a long time to see the truth of the decision. The approach to decision making should involve a good amount of effort & thinking on both aspects - what will be the right decision & what will it take to make the decision right.
Will be writing another post soon to look at some of the examples for using this framework & the learnings from that, it may not be the best framework but can help in steering to the shore.
Individual development has many facets to it, sometimes we may get right opportunities & environment to grow & learn while many times we have to seek or create those opportunities based on individual aspirations & situations. The aim in the post is to put together a template to help anyone who is starting with outlining a development plan for oneself or someone else, these are just ideas to help think about career in more structured way.
There are many different point of views when it comes to approaching self development, whether it should be goal oriented or journey focused, many times the goals create too much pressure & sets an artificial boundary while journey focus gives relaxed growth & also provides flexibility to explore. But this problem with goals is more due to the way goals are defined, if the goals focuses too much on how instead of what & why. Basically instead of steps to reach the goal, we should be defining it crisply first & then overtime think of ways to achieve it.
One of the important learning has been that everyone has some aspirational & concrete goals, in fact most people don’t spend too much thinking time on aspirations & even when some people have clear aspirations, generally they will not share their aspirations unless there is high trust environment. Just for example if there is an aspiration in person to
Planning in general means that you are putting together some kind of projection in future to guide the journey & bring focus on the goals from time to time, it can be done in either forward looking (more suitable for short term oriented plans) or backward looking (suitable for long term oriented plans). The forward planning is basically building on things incrementally based on current situation & competency while backward planning is basically to backtrack the journey to plan for the end goal which is far enough in future to enable anyone to change the situation & competency as required.
If the forward & backward planning converges, that means the work being done today is aligned with individual’s long term aspirations, which means chances are that individual will get more job satisfaction. But if they are not aligned, there will always be a feeling that working on something else may enable the person to achieve those aspirations.
Generally there are few of the themes where “WHY” a person is doing something is clear, people might have different targets based on personal preferences but theme wise it is similar. First theme is the financial theme - basically everyone wants to ensure stable future for oneself & family, next are the becoming & doing themes which are closely related but can result in very different choices in the career. The last theme is around learning which acts as lever or leverage to enable a person to move from current role or work or domain etc to something which the person aspires to do.
Aspirational Goals - Act as a compass
Aspirational goals are basically larger than life goal which many times will be something abstract or open ended, it doesn’t need to be practical or achievable based on current competence & situation, these are meant for much longer duration & scope of these should reflect that.
Next 10 years
Financial Theme - Achieve financial freedom for next 10 years, this is more inline with the FIRE movement, it is an important aspect but generally not sufficient to define the journey individual needs to take.
Becoming Theme - To become someone, mostly this translates to taking some role may be as engineering leader, product leader or business leader - for example - Technical Architect, Engineer Manager etc, more can be read on engineering ladders
Doing Theme - To do something like build world class product, open source contribution, or to work on new (0-1) product, growth (1-10 or 10 -100) product, mature product (scaled)
Learning Theme - To learn some skill - tech (design/architecture), domain, non-tech (product, finance), management (project, people)
Next 5 years
Financial Theme - Achieve financial freedom for next 5 years, this is more like stepping stone towards the 10 year goal
Becoming Theme - To become someone - Principal Engineer
Doing Theme - To do something - Take 1 product to customers - internal or external customer, paying or not paying customer
Concrete goals are basically more detailed & are like a roadmap of what a person aims to do in next 1 year, this again can be growth & learning oriented when looking at longer 1 year timeline while competency & outcome oriented in the shorter 6 month timeline. The goals here should have opportunities mapped to ensure that the plan to achieve those goals is in place, also these need not be abstract or open ended instead should be immediately actionable.
Next 1 year
The next 1 year timeline is focuses on linear & possibly non-linear growth, the linear is incrementally doing better & progress to next role while non-linear is either creating multiplier effect by solving cross cutting concerns (breadh) or solving complex concerns (depth).
Non-Linear Growth (large impact taking the person leaps ahead in career) - mostly by addressing some cross cutting concerns which will have multiplier effect in the org or solving complex problem having long term impact
Linear Growth (current role to next role) - understanding the role delta in terms on increased expectations, mostly focusing on incrementally taking more responsibilities
Next 6 months
This should be based on expectations for the next role & also previous review, many of these things are in geneeral already in progress.
Improving the system design by keeping in mind the bigger picture of the system.
Increasing the tech breadth which will enable him to make better tech choices while working on the designs. - I-Shaped learning paradigm (breadth on fundamentals & first principles along with depth on one tech stack / area and finally breadth on many tech stacks/area) - Example - Distributed System Design & Algorithms
General Aspects
There are few important general aspects which are mostly common but should find some place in everyone’s individual development plan.
Time & Energy Management
Everyone has limited amount of time & energy, it is important to manage these well to accomplish more, the time management will be very different based on different roles, have been using a generic framework - role responsibilities framework which uses a simple approach of understanding the responsibilities of a role, give some percentage to each responsibility based on importance.
Example - For engineer role, the responsibilities (execution, solutioning, operational, mentorship, idp) & a sample time allocation for ideal situation may look like this - execution-35%, solutioning-35%, operational-15%, mentorship-10%, idp-5%. In the equilibrium state, time allocation should be like that which means that the focus is to ensure time management comes back to this equilibrium state every few weeks or months depending on the skewness created due to situational factors.
Plan for the week and keep the day open - generally have seen that very granular planning at a day level creates more pressure as either adherence will not happen due to some unplanned activity or unnecessarily mind space will be taken to ensure adherence, it is better to plan for the week, keep track and review things by end of the week.
For any kind of deep work, continuity of thought & focus is critical which is basically the maker schedule while when the focus is more on delegation & breadth of knowledge, context switching is required & many times good, this is basically the manager schedule. Good article on this - Maker vs Manager Schedule
Energy management is equally important, sometimes only optimising on time will drain the person of energy required to perform and may result in slowness of mind, burnout or even feeling exhausted quickly. The best way to keep up with the energy needed is to take breaks (within day, month, quarter & year), taking enough rest.
While the time is more continuous in flow, it automatically brings rhythm & consistency but energy is generally non-continuous with many bursts (up and down) which is where chances of mismanagement is much higher and mostly it’s not even talked about unless someone starts feeling very low.
Learning & Thinking Structure
Breadth Vs Depth - There is lot of debate going on with regards to breadth focus vs depth focus. Even the popular saying “Jack of all trades is a master of none” is misrepresented today as an insult to people who are focusing on breadth while ignoring the depth but the original full quote “Jack of all trades is a master of none, but often times better than master of one” was in fact a complement. To avoid this dilemma, its better to use a combination of both breadth & depth in something like I-shaped learning paradigm - in this paradigm the focus is on breadth (for the high level) - depth (in one area) - breadth (for the low level). The
Strategy Vs Tactics - This is again highly debated topic and generally strategy is associated with long term deep thinking while tactics are short term shallow responses to situations or problems at hand. The learning needs to be on both levels, as if we can’t solve the problem at hand with variety of tactical responses, chances are the strategy may not even see the light of the day. Learning strategy is required for a lot of areas where thinking over doing is more important like design/architecture
Mental agility — embracing complexity, examining problems in unique ways, making fresh connections, and staying inquisitive.
People agility — being open-minded toward others, enjoying interaction with diverse groups, bringing out the best in others.
Change agility — willingness to lead transformation efforts, continuously exploring new options.
Results agility — delivering results in tough situations, responding to challenge, inspiring others to achieve more than thought possible.
Self-awareness — being reflective, understanding strengths and weaknesses, seeking feedback and personal insight.
Mental Models - One of the most important learning structure which can help in many situations is to study, form & evolve various mental models which basically enables a person in different kinds of thinking & decision making, many times the data driven approach to decision making is good enough of situations but sometimes data might not be in right form (as data needs to be refined, data -> information -> knowledge -> insights or wisdom), various mental models can help short circuit & make the decision making faster but its important to know when & why that model works to apply it appropriately.
Decision Making - One simple framework to improve decision making is to move from How (Implementation) to What (Definition & Scope = OKR) to Why (Reason & Motivation). This movement basically increases higher order thinking & bring lot of flexibility in decision making, basically when focus is on what, the how becomes flexible & similarly when focus is on why, the what becomes flexible. Another important way to improve decision making is by doing incremental decision making using Hypothesis (Non-Deterministic) instead of Deterministic approach. When we use hypothesis, the possibility of being wrong is stated explicitly along with other assumptions while when we do deterministic decision making, being wrong is hidden and there can be lot of implicit assumptions. Hypothesis based approach also enable person to do evolve decision incrementally by qualifying & refining the hypothesis as more & more knowledge is discovered & understanding deepens.
