Working with Rik a user manual

About this page

Every new working relationship spends its first few months on the same discovery: how does this person like to get information, what do they mean when they push back, what will annoy them, and what earns their trust. This page shortcuts that. It started as a note for the people on my teams. I’m publishing it so anyone thinking about working with me knows what they’re signing up for.

It describes how I actually work today, including the parts I’m still improving. It’s a living document, versioned like software. If you find a bug, tell me.

The format is borrowed, with thanks, from Luc Levesque’s Blueprint for leaders and managers. If you lead people, I’d recommend writing your own.

About me

I’m an engineer who ended up leading engineers, and I never fully stopped building. I’m Lead Director of Engineering and Product at CVS Health, where my teams build the technology inside our stores and pharmacies: point of sale, pharmacy workflows, store devices, and the AI that is starting to run at the edge. That work reaches more than 9,000 stores, across core CVS locations and CVS pharmacies inside Target.

Much of my career has been about modernizing systems that can’t go down. One example: rather than rip out Toshiba POS, we rebuilt the pharmacy experience as a modern web platform that ran alongside it. Toshiba kept payments and front-store checkout. The prescription journey and health data sync moved to modern web apps and microservices. That bridge is what made the later POS migration safe, and I still approach most modernization problems that way.

Outside the day job I build things, mostly to learn:

• EzyUpload, an AI platform for eCommerce product images.
• RetailAgentOS, an open-source protocol for agent-to-agent commerce.
• ezyReminder, a calendar and reminder app for iPhone.
• The Custom Hub, a desi-themed merch shop that became an Etsy Star Seller.

I write about enterprise AI and retail tech on Substack and X, and I’ve co-taught hands-on AI workshops for non-technical audiences in my community.

My family is from Kolkata. I live in the Boston area with my wife and kid. My weekends are a mix of family time, coding sessions with AI tools, and adda with friends: the long, wandering Bengali conversations over tea that can cover cricket, politics and startups in one sitting. That circle of friends is mostly thanks to my wife, who has a huge social network. It brings a lot of positive energy into our lives, and a wonderfully diverse mix of people and perspectives.

What motivates me

I’ve always learned from people a few steps ahead of me. Since my engineering days, the case studies and life stories of great minds in technology, science and finance have been my main source of inspiration. In technology, Steve Jobs and Bill Gates inspired me then and still do today. From Jobs I learned to obsess over the customer experience. From Gates I learned how a platform can change the global tech landscape, the way Windows and Internet Explorer did, and how owning the operating system shapes the whole competitive game. “OS” is still my favorite word in technology. It’s no accident that my open-source project is called RetailAgentOS.

Some of my favorite lessons came from the cricket field. Sourav Ganguly’s stories showed me how a captain can turn a talented group into a team that believes it can win anywhere. Harsha Bhogle showed me how much a well-told story can teach.

What they gave me was more useful than any single technique: a growth mindset. In their stories, every failure was a lesson and every success rested on years of steady learning. That habit hasn’t stopped. Today it continues through podcasts. My favorites are Raj Shamani’s, Moonshots, and Nikhil Kamath’s.

In my own work, the moment I chase is a quiet one. Retail is the most honest place to build software. Nobody in a store praises the checkout system. A pharmacist with twelve people in line doesn’t care about our architecture. When the technology works, nobody notices it: the customer gets their prescription, the associate looks up and smiles, and the line moves.

That invisible moment is what I work for. Software so dependable that the people using it forget it’s there.

I moved into leadership because I wanted more of those moments than I could build by myself. I still build on the side because it keeps me honest about how hard they are to create.

My values

• Build to understandI learn a technology by shipping something with it. I expect leaders on my team to stay close enough to the work to hold an informed opinion.
• Context is the jobI call it the 85/15 principle. Most of the quality of any output, from an engineer or from an AI model, comes from the context and the brief. Execution is the other 15. When something goes wrong, I check the brief first, starting with mine.
• Respect the floorThe store, the pharmacy counter, the associate at 5pm on a Saturday. Every decision gets tested against real people doing real work.
• Say the true thing earlyIntegrity is mostly timing. A risk raised in week two is a gift. The same risk raised in week ten is a crisis.

What leadership means to me

Every autumn in Kolkata, neighborhoods build pandals for Durga Puja: temporary temples of bamboo, cloth and light, some as elaborate as a building. Nobody hands out a Gantt chart. Artisans in Kumartuli spend months shaping the idols. Carpenters raise the frame. Electricians string thousands of lights. Volunteers go door to door raising money. On the first night, the whole thing comes alive.

What holds that together is a shared picture of the festival everyone wants to stand inside. Each person can see where their piece fits, so they organize themselves around it.

Large IT programs work the same way. Modernizing thousands of stores means orchestrating dozens of teams at once: POS, pharmacy, network, devices, security, vendors and store operations. No project plan can choreograph every move. Orchestration works when every team sees the same finished picture and knows when its piece has to land. Painting that picture is what leadership means to me, and I hold myself and every leader on my team to three things:

• Leaders paint the pictureThe vision and the mission are clear enough that anyone on the team can find their part in it without being assigned one.
• Leaders write the briefContext, constraints, and what good looks like. Most of the “execution problems” I’ve seen were briefing problems.
• Leaders stay close to the groundWalk the store, read the incident report, use the product. Know what’s working and what isn’t, and adapt.

How I communicate and process feedback

• Headline first. Give me the answer, then the explanation. If I ask “did it ship?”, start with yes or no. I’ll do the same for you.
• Write it down for decisions. A one-page narrative with data beats twenty slides. Writing forces clarity, and it lets people who weren’t in the room catch up.
• Channels. Teams or Slack for quick questions, and email for FYI. Urgent means something hurting customers or stores right now, like a major outage or an issue spreading across locations. For that, call or text me.
• Feedback goes both ways. I mean it when I ask. Direct is good; cruel isn’t. The person receiving feedback decides what to do with it, but they close the loop with the person who gave it.
• Strong opinions, loosely held. I’ll share a view early. Push back with data and I’ll change my mind. When I push back on your proposal, it means I’m taking it seriously.
• Bad news early. I’d much rather hear “we’re red” in week two than in week ten. Nobody gets in trouble with me for raising a risk.

How I process information

• Macro before micro. I need to see where a detail fits in the larger system before I can engage with it. If I stop you to ask “what’s the decision here?” or “where does this sit in the architecture?”, I’m orienting myself, not dismissing you.
• I play it back. I’ll summarize what I heard to check I got it right. It can sound like I’m repeating you. I’m connecting the dots.
• I prototype to think. Sometimes I’ll show up with a working sketch, a script, or an AI-built mockup. Treat it as a question, not a spec.
• Under pressure, I stay calm and think. I keep the conversation within a small core team, lay out the options, and evaluate them together before we act. A calm room makes better decisions than a loud one.

How I work with my team

Trust by default

I assume you know what you’re doing. If something looks off, I’ll tell you what concerns me and may zoom in for a while to help. When things are back on track, I zoom out. Neither of us enjoys me being zoomed in, so if it keeps happening we’ll talk about why.

Decisions

Bring me a recommendation, not only a problem. I’ll usually ask what you’d decide and what you need from me to decide it. If a decision is reversible, make it and tell me after. If it’s a one-way door, such as a vendor contract, a platform choice, or anything touching patient data or payments, bring me in early.

Your first team is your peers

If you lead a team and report to me, the people beside you are your first team. Your own team is how you deliver on the outcomes that group shares. If we lose sight of that, I’ll say so and we’ll reset.

1:1s and meetings

I hold a short, informal weekly conversation with each of my direct reports. Status, decisions and blockers live in our team rhythms, so that time is about you: growth, obstacles, and anything on your mind. If you’d like a more structured 1:1, just ask and we’ll set one up.

Meetings are for decisions, alignment and ideas. Status belongs in writing. I’ll do skip-levels and keep open time on my calendar for anyone on the team. If someone brings me an issue about you, I’ll coach them to raise it with you directly, and I’ll have your back.

Growth

I care about where you’re headed, not only what you’re delivering this quarter. I never want to be the bottleneck. I run a team of teams, and I want each leader on it to be the face of their area. My job is to put you in front of the room, promote your work, and coach you in the background.

Learning runs both ways. I learn as much from my leaders as they learn from me, and with AI changing how all of us work, that two-way street matters more than ever. Whatever happens, I’ll be on your side.

I want you to have direct access to senior leaders, and I’ll create those chances. If a new delivery commitment comes up in those conversations, loop me in so we can plan it as one team and protect what’s already committed.

Where I need help

Fires from leadership come in waves, and a week of escalations can knock our planned work off track. Putting out fires while keeping the team running like a well-oiled machine is a balance I’m always working on. What helps me most is a clear plan for handling incoming fires: a simple triage path, a small group that owns them, and an early flag from you when the roadmap starts to slip. That way the rest of the team keeps moving.

How we use AI on my teams

I’ve spent the last few years deploying AI at enterprise scale, from agentic workflows to models running on store devices. These are the ground rules I set.

• Use itI expect everyone, engineers and non-engineers, to use AI tools in their daily work. Not using them is the bigger risk.
• You own the output“The AI wrote it” is never the answer. If your name is on it, you’ve read it, checked it, and you stand behind it.
• Share the briefWhen you share AI-assisted work, share the context and prompt that produced it. That’s the 85 percent, and it’s what the rest of us can learn from.
• Production is a systemA demo is a prompt. Production needs evaluation, guardrails, monitoring, and a path to a human, especially when it touches customers, patients or money.
• Agents will shopSoftware agents will soon buy and sell on behalf of people. Retailers need open standards for that, which is why I build RetailAgentOS in the open.

What I believe about product and engineering

• The store is the real production environment. Peak hours, flaky networks, a line at the counter. Design for offline, for speed at the edge, and for the associate’s next thirty seconds.
• Modernize with bridges, not big bangs. Wrap the legacy system, move one journey at a time, and retire the old platform once the new one has earned it.
• Speed is a feature. Ship small, ship often, measure. Then invest for the long term in what has proved itself.
• Fewer priorities, actually finished. Know the three things that matter most this quarter. Protect them from everything else.
• Platforms earn their keep. A platform is worth building when it makes the next feature faster. Experiments drive features, features drive the platform, and the platform makes the next experiment cheap.
• Automate the toil. If we do something by hand three times, we script it. Removing operational toil matters as much as removing user pain. It’s how a team scales.
• Engineers and product build it together. Engineers often have the best ideas for hard problems. Product and design turn them into something people love to use. All three matter.

How I define success

I’m not formulaic about it, but these are the qualities I look for and try to live up to myself.