I sat at the piano expecting a typical learning session that evening. Then I was hit with a surprise when Rajesh sir introduced me the notes of Tam Nam Tam Nam from the Kannada movie Eradu Kanasu. One of my favorite songs. I brightened up immediately :)

I started following him slowly, one note at a time. The tiredness from office just melted away. It took me a full week after that lesson to get the pallavi right. I didn’t mind and I was happy. To tell you why that one hour meant so much, let me take you back in memory lane, to my childhood.

I grew up in a small town in Karnataka. In those days, I didn’t know anyone who owned a piano. Not in the whole town, as far as I can remember. What we did have was music. Kannada, Telugu and Hindi film songs playing on every radio, TV, every day. I used to watch harmonium players at bhajans, flute players at weddings and keep running a small simulation in my head. “What if I could play something too?” For some reason that I cannot fully explain, the sound of piano keys always felt different to me than other instruments. I wanted that sound.

But piano was out of reach. Even if someone in town had owned one, it would have cost much more than my dad could have afforded on a hobby for his son. So I just let the dream sit there, quietly.

A few years later, I moved to Mysore for my undergrad. That is where I met Madhukar and we became close friends. Madhu played the mandolin and he was really good at it. He loved QSQT songs. “aye mere humsafar” was one he played often. Something shifted in me when I saw him pulling it off that effortlessly. Watching a stranger at a wedding play an instrument is one thing. Watching your own friend do it is a very different thing. The influence hits much harder. Years later, when I finally started learning, I surprised Madhu with the news and how I carried his influence.

Fast forward to September 2025. Deepa and I were visiting India. One evening we were standing at a roadside pani puri stall with Shravan and Sushmitha. Between bites, the chat turned to old memories, then to life in general, then to learning. Sushmitha said something that was inline with my beliefs. “It is very important that all of us keep learning something or the other. A skill, a book, anything”. I knew what I wanted to pick up.

Once I returned back to the Bay Area, I started to explore the path for learning Piano. I spoke to 3 institutes. Two of them were large chains where the tutor could be anyone from anywhere. That did not appeal to me. I wanted to learn Indian film music and devotional songs, taught by someone who understood that world. A friend here suggested Rajesh sir, a piano teacher based in Bangalore who takes remote lessons.

I was skeptical. Can you really learn piano on Zoom? Even if yes, will it work as well as sitting next to a teacher in person? I booked an exploratory class to find out. Rajesh sir and I clicked in the first 15 minutes. His approach, his politeness, and the Kannada between us made the decision easy. I told myself, let me try for 3 months and then decide. One year later, I am still with him.

The first few weeks were humbling. Learning the layout of the keys felt a lot like learning qwerty typing for the first time. My fingers did not know where to go. I was not frustrated as much as I was unsure. I kept feeling, was I too late to this?

The white keys came first. Then came the black keys and the left hand ornaments. I almost tapped out. Week by week, something shifted. My hands started moving a little more on their own.

He kept repeating a few things that I now treat like my own personal music phylosophy.

“You are not learning songs, you are learning notes.”
“The slower you play, the faster you learn.”
“Learn each line correctly before you move to the next. Don’t rush to play the full song on day 1.”

It has been a year now. I have learned about a dozen songs. Devotional pieces, Happy Birthday, Tum Hi Ho, Chalte Chalte, Bombe Heluthaithe, Tam Nam Tam Nam. I still don’t fully believe that number.

The Clavinova I play on was not bought for me. We got it for Rahul in his elementary school days. He moved on, the piano stayed. These days, it is mine :)

Deepa and Rahul have become my biggest cheerleaders. They walk past the living room and says things like “that was nice”, or “I am loving it”, or sometimes a very useful “practice a little more on that middle part”. I take all of it.

Life truly is a continuous learning institution. Picking up piano is one of the best decisions I have taken in recent years. If you have been circling a hobby for years and never taken the first step, I would say, just start. You may surprise yourself.

Until today, I had told only a handful of friends about this. This blog is the day I go public. Madhu, if you are reading this, thank you!

Over at VSF Tech Club, we’ve run five AI courses over Zoom in the past year and a half. Every time one wrapped up, people kept asking, “Okay, what’s next?”. So Srinivas, Veera, and I decided to experiment: a live, two-day workshop on building real apps with AI agents. Luis Ticas flew all the way in from Toronto to facilitate, and he brought a stacked agenda.

What clicked for me

Luis kept hammering one distinction: an LLM answers your question but an agent takes a goal, plans, uses tools, and checks its own work. Vibe coding was a fun start, but agentic development is how you actually build software that scales.

Day 1 was focused heavily on that workflow: intent, spec, user stories, build, review, and merge. You need clear acceptance criteria and a solid definition of done because they are the key prompt instructions for your agent. Keep each branch scoped to a single story. And don’t confuse a plan (what you intend to do) with a spec (what “done” actually looks like). He also demonstrated what happens when you feed an agent a lazy prompt, it gets confused, tries to guess everything, and outputs bloated code that misses the true intent.

Then came the demo of BMAD, which was my biggest takeaway. It’s an open source framework where specialized agents — an analyst, product manager, architect, developer, and QA debate each other and flag risks before a single line of code gets touched. I have spent weeks sitting in corporate alignment meetings trying to accomplish that exact same thing. Watching a stack of agents hash it out in a few minutes was equal parts wild and deeply impressive.

Day 2 was all about testing and validation. A few of us ran evals against golden datasets to benchmark expected behavior, which is essentially unit testing for models. Luis walked us through tracing in MLflow, and then everyone wired up CI/CD pipelines so PRs couldn’t merge without automated checks passing. That is the piece that actually makes this viable for enterprise tech. Speed is great, but automated guardrails give the confidence to trust the output.

The honest scoreboard

During the kick off intro, I mentioned to everyone they would leave with a fully deployed app. Reality hit pretty quickly. Only about 30% actually finished end-to-end and went live.

The reason why is actually super insightful. Attendees tackled ambitious, real world ideas in fintech, internal operations, and edtech. Code generation and build cycles ended up taking way longer than anticipated. The bigger the scope, the longer the wait. If you’re trying this yourself, start with a small slice first and get that deployed before expanding.

Despite the hiccups, our post-event survey hit an 8.9 out of 10. People loved getting their hands dirty instead of staring at slides, and the energy of troubleshooting side-by-side in a room made a huge difference. One piece of feedback really stuck with me: “I totally enjoyed this session. I now have shed my fear about AI”. Since we run these events as volunteers, hearing that directly from attendees meant more than any rating scale.

We also got plenty of constructive notes for next time: send out setup materials and slides in advance, warn people about API token costs before they hit unexpected limits, consider splitting the content across two separate weekends, and keep the coffee flowing nonstop 🙂.

Participants also asked for a buildathon, deeper sessions on enterprise AI, security, governance, and evals, a track for folks who don’t code every day. We’ll explore these in the near future.

My takeaway

Vibe coding is fine when you are experimenting with a weekend side project. But if you’re building production software, give your agents a real spec, tightly scoped stories, and rigorous automated tests. The AI handles the heavy lifting, but the structure is what keeps things from falling apart. And always start smaller than you think you need to.

Huge thanks to Luis for flying in and delivering an awesome workshop, to Sravanthi, Manoj, Visu, and Shanthi for keeping everything running behind the scenes, and to everyone who spent their weekend with us.

Last Wednesday, a glacier broke off above a river called the Lhende Khola. The debris blocked the water until it couldn’t hold anymore, and then all of it came down at once, straight through the same crossing we had walked through two years before.

Hotel Kailash is gone. The immigration building we sat around is gone too. In the video someone sent us, it takes under a minute. In 30 seconds this solid building got smashed and became part of the water stream.

Someone from our old Kailash WhatsApp group forwarded the clip. Deepa and I watched it twice before either of us said anything. I kept trying to line it up with what I remembered, where we had sat and the photos that we took.

More than 1000 people are confirmed dead across Nepal and Tibet this week, and thousands are still missing. A lot of them were pilgrims doing exactly what we did two years ago. We exchanged a message with our tour company. Everyone who guided us in 2024 is fine. I don’t know what to do with that relief. It sits there next to knowing other families are still searching and I haven’t figured out how those two things are supposed to fit together in the same head.

It is a powerful reminder of our own insignificance in the grander scheme of things. No matter how powerful individuals believe themselves to be whether measured by wealth, status, position or any other axis, nature is infinitely more powerful. And when nature strikes, it does not distinguish. It does not care about our human divisions, accomplishments, or plans. We are all equally fragile.

In my early childhood, our days were shaped by the demands of that large joint family. But my mother’s vision extended beyond those walls. She knew that for my siblings and me to have a real shot at the future, we needed better education than the village could offer. There was no loud fight or sudden rebellion. Just a persistent, patient negotiation with my father. She pushed for us to move to a nearby town when I was five. My father eventually broke the news to the extended family. She was clearly the architect of that transition, moving us from the passenger seat of a traditional life into the driver’s seat of our future. She wasn’t executing a strategy. She was simply doing what felt right as a mother. The outcomes just happened to be brilliant.

People often assume that traditional Indian mothers aren’t suited for corporate or business thinking. One memory permanently changed how I see that. When my father came back from an important property negotiation, empty handed and resigned, my mother didn’t offer just comfort. She reasserted key points, analyzed the deal, and pushed him to go back to the table. He closed that deal the next day. That investment became the foundation of our family’s subsequent success. She wasn’t trying to be an executive. She was just being herself.

Persistence and Connection

This same clarity showed up every single morning during my high school years. Tuition classes started at 6 AM. In the biting cold of winter, that meant waking at 5. Every morning, my mother was already up, heating water on the stove and bringing it to me so I could start the day with some comfort. If I wanted five more minutes of sleep, she would wait and try again. She never showed exhaustion. Her goal was her children’s education, and it was so consuming that the physical toll simply did not register.

That grit is paired with a remarkable openness. About a decade ago, while visiting me in the US, she sat with my friend’s mother. My friend’s mom only spoke Hindi. My mom only speaks Telugu. No shared language. I watched them from a distance for two hours. They weren’t laughing or joking, but exchanging life stories through photos, expressions, and gestures. It was a quiet revelation: human connection is far more powerful than vocabulary. You don’t need words if you have the maturity to truly see the person in front of you.

This openness extends to everything. Whether picking up a table tennis paddle without hesitation, or sitting with me on our home karaoke set singing the Telugu duet “Edo Oka Ragam”, she has a no barrier attitude toward life that most people of her age tend not to lean on. New cuisines, new experiences, new people. As long as there is a vegetarian option, she is in.

The parenting bridge

I find myself repeating her lessons to Rahul all the time. The biggest thing I have carried forward is how she framed challenges, never as threats, always as things to be met with the best tools you have. I tell him the same thing: life will throw unexpected obstacles at us. We cannot escape them. What we can build is the maturity to acknowledge them and respond well. That is what makes life meaningful.

Whenever I ask her what she wants for Mother’s Day, she never asks for a gift. Her only request is that we visit India more often. When we attribute our success to her, she quietly dismisses it. She says, “I don’t think I have created any great legacy”, “It was just my Dharma”. None of us agree with her on that statement.

I have grown to deeply respect that level of contentment. A person who has shaped the trajectory of lives across two continents and two generations and genuinely believes she was just doing her duty. That is a kind of greatness many of us spend a lifetime chasing.

Same thing happened with spelling. Autocorrect made me lazy. I make the same typos over and over because I know the tool will fix them for me. The incentive to actually learn the spelling is just gone.

I am not anti tech at all. Innovation is a win for everyone. But every convenience has a trade off. It takes something from you in exchange for making life easier, usually a cognitive skill you didn’t even realize was slipping until it was already gone.

I am watching a similar thing unfold in software engineering right now.

AI coding tools are getting very good. So good that many engineers are committing a good chunk of code that is actually written by AI coding tools. They prompt, they hit accept, and they move on. Even system design reviews are getting a bit thin. Code comprehension is quickly becoming a secondary concern. I manage engineering teams at my work. While I want to be clear that we are not in a “crisis” yet, I can definitely see the trajectory. The muscle isn’t being used as much as it used to be.

Here is what actually keeps me up at night: What happens when the AI gets it wrong and nobody in the room is skilled enough to notice?

Because these tools do mess up. They will give you code that looks clean and runs fine, but it might have a subtle bug or a shaky architecture that doesn’t blow up until months later. Catching that requires a deep, gut-level understanding. That is the kind of knowledge you only get by writing the code yourself, debugging at 2 AM, and occasionally breaking things so you can learn how to fix them.

If engineers stop building that foundation, they lose the ability to be the last line of defense. They end up reviewing work they can’t truly evaluate. That is a dangerous spot. I have mentioned this before in my previous blogs: we are moving from an era of writing to an era of oversight. But oversight without deep understanding is nothing more than rubber stamping.

AI only hurts us if we allow it to change our habits. I don’t have a perfect answer yet and I don’t think even the industry has it yet. But I do think we should think of this before the muscle memory is gone for good.

I have spent a good chunk of my career building data solutions and platforms, centralized orgs, decentralized ones, and the messy in-between. I have seen both models work. I have seen both models fall apart. And after all of it, my take is pretty simple: centralized model wins at scale. But it comes with real catches that are worth talking about. Before I defend anything though, let me set some context.

First, know which Org Design you actually need

Not every org needs a centralized data platform. Forcing one scheme on the wrong org is its own kind of disaster. Here is the rough rubric I use:

Decentralized design makes sense when:

• You are at an early stage. Speed is everything. Org design can surely wait.
• Your engineering org is small. A few hundred people, give or take.
• You are still figuring out what your data needs even are. No point centralizing chaos.

Centralized design makes sense when:

• Your engineering org is large. I put the rough threshold of 1,000 engineers. No science behind that number, just pattern recognition from what I have seen.
• You have a multinational presence. Data flowing across regions, compliance zones, time zones.
• You are starting to notice the same solution being built independently in three different teams.

See where your org sits before picking a model. Everything I say after this should be processed through that lens.

The Federated Model

Before making my case for centralized, I want to address the answer most org designers reach for first: the federated model.

The idea is elegant. A central platform team owns the infrastructure, governance, core datasets. Individual business units own domain pipelines, products, use cases. Best of both worlds. Sounds clean on a whiteboard, right? But gets messy fast in the real world.

Who owns the identity layer? Who governs the shared feature store? When a business unit wants to deviate from the standard stack, what is the process? These questions do not resolve themselves. Without very mature engineering leadership on both sides, the federated model just drifts. And eventually “federation” becomes a label stuck on what is really just fragmented systems with extra meetings.

I am not saying it cannot work. I am saying it requires organizational discipline that is genuinely rare.

Why Centralized Model wins at scale

The strongest argument for centralized is not cost savings. It is the platform as a product mindset that centralization forces you into.

When one platform org serves the entire company, the incentive shifts. You are not building for your immediate team anymore. You are building for internal customers such as product, finance, marketing, operations etc. When this is done well, it produces something valuable: shared infrastructure that kills duplicate tooling, eliminates point solutions, and gives the whole company a unified tech stack and a coherent cloud strategy.

What does that look like in practice? One data catalog. One observability framework. One set of ingestion patterns. One identity and privacy standard that applies everywhere. Engineers can move across orgs without relearning the entire stack from scratch.

The hidden cost of decentralization, on the other hand, is genuinely staggering. In my experience the waste factor runs anywhere from 0.3x to 2x depending on the org. Meaning what should cost $100 ends up costing $130 to $300 once you factor in duplicated cloud infrastructure, redundant tool licenses, siloed knowledge, onboarding friction, and wastage of engineering resources. Not a theoretical number. I have watched it happen, more than once.

The Catch: Roadmap prioritization is a real problem

Let me be honest about something most people do not say out loud. When one platform org serves twenty internal teams, someone always feels underserved. And the teams that get served best are not always the ones with the most legitimate need. More often, it is the teams with the loudest push from stakeholders.

I saw this most sharply at Meta. We were running a centralized data platforms function per family of app (Facebook, Instagram, Whatsapp, Infra) and hit a point where we simply did not have the bandwidth to serve all product surfaces equally. The tempting move was to spread the workforce thin, show up everywhere, make everyone feel heard. We did not do that. We prioritized ruthlessly, went deep on the highest ROI functions, and accepted that some teams would get less attention than they wanted. A hard call.

It worked! For the platform org and for the company’s overall data outcomes. But I want to be honest about what that felt like on the other side. The deprioritized teams didn’t feel good. Engineers questioned whether the platform org actually understood their problems. Some of that frustration was completely fair. When you are consistently at the bottom of someone else’s roadmap, it erodes trust.

This is the necessary evil of centralized done honestly. You cannot serve everyone equally all the time. The key is transparency: being clear about why certain priorities were made, having a framework that stakeholders can actually see, and rotating focus over time so no function is permanently left behind. Permanently underserving the same teams is not a prioritization strategy. It is just neglect with a roadmap attached.

So where does this leave us?

Centralized data platforms produce better outcomes at scale. The efficiency gains are real. The “platform as a product” mindset is real. The compounding returns of a unified tech stack are real.

But it is not a free lunch. The prioritization problem is genuine. And if leadership is not mature enough to handle it transparently, centralized just becomes a different kind of dysfunction: slower and more political.

Know your org. Pick the model that fits your reality, not the one that looks best in a presentation.

I am not here to prescribe a one size fits all solution. I am just sharing my thoughts as I observe the machine to human code ratio is increasing by the month. Historically, we have relied on engineer’s “activity” as a proxy for “impact”. We looked at PR counts, sprint velocity, lines of code, and number of design docs churned out. But in 2026, these are really “low signal” metrics.

If an AI can draft a 5 page design doc or a 500 line Python script in seconds, we cannot measure an engineer’s output by the volume. We are now moving from an era of Writing to an era of Oversight.

The Metrics That Actually Matter Now

1. Systemic Leverage

In today’s world, I do not care much about the lines of code an engineer ships individually. I care about how much faster the rest of the team moves because of that engineer.

• Some Metrics to Quantify: Tooling Adoption. Did you build a prompt library, a data wrapper, or a framework that 10 other people are now using? That’s real impact.

2. The Human Filter

AI is a world class intern! It is fast, but it is confidently wrong sometimes.

• Some Metrics to Quantify: Review to Revert Ratio. If an engineer “rubber stamps” AI generated code that blows up a day later, they failed the judgement test. We have already seen such incidents coming to light. Eg. AWS incident in Q1 of 2027.

3. Decision Velocity

Coding is now becoming the cheapest part of the process. The real bottleneck is the “Discovery” phase, navigating ambiguity and turning a messy business requirement into a clean technical spec.

• Some Metrics to Quantify: Time to Spec. How fast an engineer can provide the “Why” and the “How” so the machine can handle the “What”?

My take on Incidents

I’ve had some coffee chats where people ask if we should judge engineers on having the “least number of incidents.” This is a clear NO for me.

If we were to prioritize this metric, number of incidents fall to near zero. If your incident count is zero, you are not innovating, you are playing it safe. In my teams, I would rather measure MTTR (Mean Time to Recovery). Break things, but build the architectural “fireproof walls” so you can fix them quickly.

Looking Ahead

I have a feeling that in 2 or 3 years, I’ll look back at this post and smile. The world is changing so fast that these “new” ideas might look like ancient history by then. But for now, this is how I’m navigating the shift.

Cartagena presents a few challenges: it’s noisy and intensely hot. But after seven days of living the experience, I can tell you, this place has a nice soul. Let me walk you through our experiences and observations.

When we started from SFO airport, we had a playful thought. We decided to give Spanish names for ourselves during this trip and made an attempt to address each other with that name during our trip. I chose the name “Vanessa” for her and she chose “Gabriel” for me :)

The “Vibe” Architecture

Cartagena is a collection of a few attractions when looked at with a tourist lens.

The Walled City (Centro Historico): This is a polished area, beautiful, and runs smoothly. We spent hours walking the colonial streets, and every corner looked like a postcard. We learned early on that the massive wooden doors and sea facing windows were not just aesthetic choices by the Spanish, they were the original air conditioning system. There are a lot of commercial outlets for a tourist to have an unlimited shopping experience.

Getsemani: This neighborhood is raw, vibrant, and refuses to use its “indoor voice”. We had a choice to stay at either Walled City or Getsemani. We chose Getsemani. While the Walled City goes to sleep early, Getsemaní parties until past midnight. The noise pollution was real (we could hear the bass thumping while we tried to sleep), but the energy at Plaza de la Trinidad made up for it. It’s where life happens, kids playing, street attractions, and street food frying. All of these happening at the church steps.

Castillo de San Felipe Fort: Towering over the city, this Spanish built fortress is one of the greatest military structures ever constructed by the Spanish colonies. We understood from the guide that this fort served as a key defensive point against land and sea invasions. This fort has a complex system of tunnels. The view of the city from the fort is beautiful.

The Milestone (“the anniversary”)

Our main reason for this vacation was our milestone anniversary. We decided to go off grid to the Rosario Islands, specifically a beach club called Bora Bora.

The logistics were interesting. We took a speedboat that carried about 30 people. This wasn’t a cruise, it was a physics experiment. The boat launched itself 3–5 feet into the air and slammed back down, repeatedly, for an hour. We took “salty showers” the entire way. It was terrifying, but looking over at Vanessa laughing through the sea spray, I realized this is exactly what our time together has been about: hanging on tight when things get choppy.

The destination justified the journey. We had a private gazebo facing the Caribbean, and for a few hours, the world stopped. The ocean water is relatively warm and it felt good to be in water for 2+ hours.

When we returned to the hotel from the island visit, we cleaned up (after several showers to remove the salt) and headed to Maria Rosa for dinner. This was surely a highlight of the trip. Perhaps it was a slow Tuesday, but we ended up having the entire second floor to ourselves. A private 5 course meal, surrounded by roses, with just the two of us. It was a serendipitous moment that no amount of planning could have engineered better.

The Food

Being a vegetarian in a city famous for seafood is a challenge. For the first few days, we felt like we were hunting for a software patch that didn’t exist. But then, we found a few outliers.

We bumped into a Pizza Cono. Yes, a pizza in the shape of a cone. I’ve never seen geometry applied to dough like this before, but it solved the problem of the “floppy slice” perfectly.

There are a lot of really nice coffee shops, each offering its own collection of beverages and nice interior decors. Colibri Café became our favorite to the point that we made two visits. On the same lines, there are a lot of roof top bars that are a must to visit.

And finally, the chef at Maria Rosa. When we booked, I added a note about being vegetarian. I expected a salad. Instead, the chef took it as a personal challenge, designing a full tasting menu just for us. It was a reminder that sometimes, constraints drive creativity.

The “Human” Latency

I had to make this as a section. If you come here expecting Silicon Valley efficiency, you will be disappointed. Service in restaurants is slow. But I realized there is a good rationale for this. In the Bay Area, we optimize for speed. In Cartagena, they optimize for connection. The waiter isn’t ignoring you; he’s giving you space to have a sobremesa (the conversation after the meal).

The people are incredibly humble. We met locals who apologized for their bad English, while we were the ones fumbling with Google Translate. That vulnerability bridged the gap instantly.

We even got into the local spirit ourselves. On Day 6, despite the heat, Vanessa decided she wanted to film a Reel to a Telugu song. There we were, sweating in the humidity against a 100 year old colonial wall, lip syncing to Tollywood beats. It was chaotic, hot, and absolutely enjoyable at the same time.

Tips for Future Travelers and Some Observations:

If you’re planning to deploy yourself to Cartagena, here are a few specs from my field notes:

1. The currency is in the thousands (e.g., 50,000 pesos). When you hand a vendor your calculator app, they sometimes struggle with the number of zeros. Be patient, and double check the math to avoid any conflicts later.
2. We visited the Castillo de San Felipe fortress at 7 AM. By 8 AM, it was hot. By 10 AM, it was a solar oven. So, do not sleep in, beat the sun.
3. Street sellers are aggressive. Reply with a firm, polite “No, gracias” without breaking your stride. Eye contact is an invitation to negotiate.
4. Every 4th store is a liquor store here or at least they sell liquor. Most coffee shops also serve liquor!
5. Cartagena is a small city. A taxi from anywhere to anywhere in the city is between $2 to $7. So, unlike most other tourist places, we don’t really need to optimize the route. Just visit any spot that you want to and then jump to the next one without worrying about the efficiency.

This trip was a welcome departure from the “relaxing, predictable vacation” model we might have chosen a decade ago. More importantly, as we tried to recall the last time it was just the two of us, we realized this was our first proper bonding trip since Rahul’s birth.

When Deepa randomly picked the alias ‘Gabriel’ for me for this trip, I had no idea I was stepping into the shadow of Colombia’s literary giant, Gabriel García Márquez (Nobel Prize Winner). It was a pleasant coincidence that felt like a tribute by the end of the week. If this blog captures even a tiny fraction of the storytelling magic he gave to this city, I’ll consider myself lucky.

Sitting in our hotel room last night, watching a movie while the Colombian humidity pressed against the window, I realized that we hadn’t just visited a city; we had lived in it.

Here’s to the next set of happy years ahead. Hopefully, the boat rides are smoother, but the company remains exactly the same.

Fast forward a couple of decades to my life here in the Bay Area, and my perspective has flipped.

One of the most consistent feelings I have living here is gratitude. I feel very fortunate to be exposed to such a rich diversity of cultures, even within the Indian community itself. Living here has gotten me close to different flavors of the same festival, and this year, we celebrated Sankranti in two very distinct, memorable ways.

#1: The Intimate House Party: This was a gathering of five families at a friend’s place. Our hosts, who are from the state of Andhra Pradesh, had transformed their home. The backdrop was stunning, reflecting the true theme of the festival, but the highlight for me was the “bhogi mantalu”

For those not familiar, this is a ceremonial bonfire usually lit on the first day to symbolize burning away the old (negativity and bad habits) to welcome fresh energy. I admit, I wasn’t familiar with this specific tradition until I moved to the US! Seeing the “bhogi mantalu” setup, enjoying the delicious food, and making Reels while laughing with friends gave the whole evening such a warm vibe. It truly amazes me how much interest people here take in the decor and cultural presentation, sometimes even more than we did back home.

#2: The Community Picnic: Then came the big one: a celebration with a community of 30 families. A handful of enthusiastic folks conceived the idea to host this in a park, and the planning was intense, from debating dress codes to lining up an awesome, festival appropriate menu.

A key part of Sankranti is flying kites to welcome the sun god as winter ends. I couldn’t remember the last time I flew a kite in the US. It was pure nostalgia. The weather was perfect, the wind was on our side, and seeing those kites high up in the sky was pure joy.

But the real surprise was the lunch. Someone had suggested “banthi bojanalu” (a traditional style of communal row dining). When I first heard the idea, I mentally dismissed it. Traditional sit down dining in a public park? I was wrong. The organizers didn’t just talk about it, they made it happen right there on the park tables. If you believe in a tradition strongly enough, you can make it work anywhere. Between the ladies creating stunning Rangoli patterns, the kite flying, and a fun session of Antyakshari and Karaoke, it was a perfect day.

As Deepa, Rahul and I drove home, I couldn’t help but reflect on how lucky we are. We are thousands of miles away from where these traditions started, yet here we are, keeping them alive in parks and living rooms in the Bay Area.

It is not just about the food or the dress code, it is about the effort everyone puts in to create a “home away from home”. These celebrations bridge the gap between our past and our present. That is a privilege I don’t take for granted.

Most tech companies have career ladders that clearly spell out expectations for every level. Generally, these fall into two buckets: core engineering skills and behavioral skills. While the technical side depends heavily on your specific stack (Full Stack, AI, Security, etc.), the behavioral expectations are fairly universal. In this write up, I want to focus specifically on the behavioral shifts that happen when moving between these two critical levels.

The core distinction between a Senior Engineer and a Staff Engineer isn’t just about coding speed or technical knowledge, it centers on the shift from reliable execution to organizational leverage.

Impact and Leverage For a Senior Engineer, success is about consistent delivery. They are the force multipliers within their immediate team, ensuring a project moves smoothly from concept to completion. Staff Engineers, however, play a different game. Their goal is to generate multiplicative effects that span across multiple teams. Their success isn’t measured just by what they build, but by how their work enables other teams to be more effective.

Ambiguity and Problem Definition Senior Engineers excel at taking a well-defined problem and crushing it. They bring clarity to their workstream and execute autonomously. Staff Engineers, on the other hand, have to walk into the fog. They thrive in undefined problem spaces, taking a vague requirement like “our service is too slow” or “we need a new platform”, and turning it into a concrete strategy. They don’t just solve the problem, they define it.

Mentorship: While everyone is expected to mentor, the scope changes. A Senior Engineer provides direct, hands-on help to unblock junior engineers on a daily basis. A Staff Engineer thinks broader. They build programs for knowledge sharing across the organization and coach Senior Engineers on how to align their technical decisions with the company’s long-term business goals.

Communication Senior Engineers keep the team in sync, communicating technical details and blockers clearly to stakeholders. They focus heavily on the how. Staff Engineers need to be translators. They synthesize complex technical topics into clear narratives for executives or non technical partners. They spend a good amount of time aligning people, focusing less on the how and more on the why.

Org Impact This is where the Staff role really differentiates itself. Beyond the code, Staff engineers must integrate themselves into activities that lift the whole organization. This is their avenue to build culture. It could be refining the hiring process (not just doing the interviews), or identifying investment areas to boost team morale. The “blast radius” of their contribution needs to extend beyond their immediate desk and reach the broader organization.

It is at the Staff level that specific archetypes really start to emerge, the Tech Lead, the Architect, the Solver, or the Right Hand. While the behavioral baselines I’ve outlined above are universal, the way you apply them will shift depending on which archetype fits you best. You don’t have to be all things to all people, but you do need to consciously “place your chips” on the behaviors that align with the specific type of leader you want to be.