Every experience teaches you something. The only question is what.

Notes from my first job: research, teams, and the things that actually mattered

Things I Learned in 3.5 Years at my first job

A little bit of slope makes up for a lot of y-intercept

Control Wipro smart plugs programmatically using TinyTuya and the Tuya IoT platform, with an example battery-based charging automation script.

Automating Wipro Smart Plugs with TinyTuya

Set up instant, end-to-end encrypted Obsidian note syncing across all your devices using a self-hosted CouchDB server exposed via a Cloudflare Tunnel.

Self-Hosting Obsidian Live Sync with Cloudflare Tunnels

Guide for downloading HTML presentations as PDF files using DeckTape.

Converting HTML Presentations to PDF with DeckTape

How to configure a Jupyter notebook server to start automatically at system boot using systemd.

Creating a Systemd Service for Automatic Startup

I have recently left Fujitsu Research India after 3.5 years. It was my first job out of a Master's degree in India. I was one of the first five hires when the lab was getting started in India. I worked as an individual contributor, then went on to build a [small research team](https://ast-fri.github.io/) with fresh Masters grads inside a large Japanese company, mostly working on applied problems with some direct connection to the business. I've since moved to an IC role at a startup, quite a deliberate change of environment. That's a very specific context and most of what follows is colored by it. 

This is less a guide and more a log. I wanted to write this down while the edges are still sharp, before memory makes it tidier than it was. Some of this might resonate if you're early in your career or figuring out what research in industry looks like in India, without a PhD. I'm writing this mostly for my future self!

### Be obsessed with the problem, not the solution
With a few exceptions, most people I've met in academia had a solution-first mindset -- drawn to a technically interesting method rather than problems worth solving. Difficulty was rewarded over usefulness, a good portion of that was driven by what top-tier conferences valued. Michael Black's essay on [Novelty in Science](https://medium.com/@black_51980/novelty-in-science-8f1fd1a0a143) articulates this tension better than I can. 

I spent my first year in industry doing exactly what I had done during my Master's. A paper got accepted. I couldn't answer the question that kept nagging me: who actually cares about this? Not in a nihilistic way. The work existed in a closed loop: researchers who wanted to get papers accepted wrote it, reviewers evaluated it. A handful of other researchers might cite it, the loop was self-referential.

To be fair, that loop served me well. Publishing is what got me noticed, what helped me land this job in the first place. Early in your career, it has to be done and I don't regret doing it. But once I was inside an organization with real problems, continuing to publish for its own sake felt increasingly hollow. I wanted out.
 
This discomfort turned out to be one of the most productive feelings of my career. It pushed me to ask my manager if I could try something different, something where people actually use what I built. I decided to start with a problem, not a technique. 

What I found, slowly, was that the opposite instinct of everything academia trained me to do was just as satisfying sometimes more so. Starting with something messy, finding the most direct path through it and resisting the urge to make it more sophisticated than it needs to be. Complexity is something to manage, not to optimize for.

 Most of the research I've done in the last two years came from this approach. The first-order question (FOQs) for every project became: "What problem is it solving and for whom?". The "who cares" question became a useful heuristic. If we can't answer that question crisply, no amount of technical sophistication will save us, and that became the filter we applied to every new project.

There's a pattern I kept noticing once I started paying attention to it: the solutions that eventually worked often felt obvious in hindsight. Not because they were simple, but because the problem had been understood clearly enough that the solution had nowhere else to go. That clarity doesn't come from being clever. It comes from spending enough time with the problem before reaching for an answer.

---
### Learn to pick what to work on
Early in my research career, I picked problems based on what's publishable. It helped me get a job I wanted, and it had to be done back then. The way I picked problems has changed in the last two years and the calculus in an industrial research setting is different and the shift in thinking is rarely made explicit

I found it useful to think along three axes: does this connect to revenue or a real customer need? Does it push the state of the art in a way that matters? And does the problem genuinely excite you?

The best stretches of my time were when I was working on something that sat at the intersection of at least two of these. The worst stretches were single-axis work, usually innovation alone, with no clear connection to anyone who'd use it. You don't always get to choose. But when you do, it helps to be deliberate about it.

---
### The interesting work lives at the boundaries
The most interesting problems I worked on didn't come from reading papers. They came from conversations with people who weren't researchers at all: business folks who described customer pain points and constraints on what was feasible and what wasn't in ways that immediately suggested technical directions. People in other geographies who saw applications we'd never have imagined from our desks.

Every meaningful project I was part of started with one of these cross-functional conversations. Not a literature review. A conversation. In a large org, these collisions don't happen by themselves. You have to go looking for them, set up the meetings nobody asked for, build relationships across teams that don't normally talk to each other. It takes effort. But the problems you find at those boundaries are sharper, and the solutions are more grounded.

---
### Writing is the skill that multiplies everything else
I used to think writing was something you do after the real work is done. I've since changed my mind. 

When I started a team, I was looking for ways to communicate ideas more clearly and get sharper feedback. I came across the writing culture Amazon and Stripe have popularized and wanted to give it a shot. That's when I started taking writing a bit more seriously in my day-to-day work. 

Writing sharpens and crystallizes your thinking. It forces clarity of thought and clarity of thought makes everything else easier. It gives others something concrete to push back on. At some point I wrote a document making the case for a significant shift in our team's direction. That piece of writing shaped what we did more than any paper we published. It forced me to think clearly about positioning and what problems align well with the setting we operate in. The ability to make someone with fifteen minutes and competing priorities understand why your work matters is a skill that compounds quietly over time.

Something I've been trying lately: explaining your thoughts to an LLM exposes gaps in your thinking fast. If your input is vague, the output is vague. The tool reflects your clarity back at you, tools like WisprFlow make this easier for me. In an age where AI can write code, draft documents, and generate ideas, the ability to articulate what you actually want is a useful skill. I believe people who can think clearly and communicate precisely will get disproportionate value from these tools.

I'm still working on becoming a better writer. I wish I had started earlier. The compounding would have been worth it.

---
### Communicate. Seriously, just communicate.
Communication isn't one thing. It's an act of translation, and the translation changes depending on who's in the room. 

Same substance requires a different entrypoint and different language based on who you are talking to. Learning to calibrate your explanation to your audience isn't dumbing things down. It's respecting them enough to meet them where they are. This took me longer to learn than I'd like to admit, and I still catch myself defaulting to the technical framing when the room doesn't need it.

The failure mode on the other end is people simply not talking to each other at all. Someone makes an assumption instead of asking a question. Two people work on the same thing because neither mentioned what they were doing. A decision gets made in a DM and the rest of the team never hears about it, and a silos form that cause confusion weeks later. I've watched this pattern repeat more times than I can count.

The fix is boring: default to shared channels. Say what you're working on, what you're stuck on, what you need. If it feels too small to mention, it probably isn't.

Ask questions, about the project, the team, the vision, the reasoning behind decisions. Not asking signals either confusion or indifference, and both are costly. Curiosity is free.

---
### Understand where people come from
I worked with colleagues across India, Japan, and Europe. The single most useful thing I did in navigating those relationships was just trying to understand people's backstories. Not strategically. Just trying to understand what brought someone to where they are, what they care about, what pressures they're operating under.

Most friction I encountered across teams had less to do with the idea on the table and more to do with histories I hadn't taken the time to learn. When you know that someone spent years building a particular thing, their resistance to your untested new proposal stops looking like stubbornness and starts looking like reasonable caution. Understanding context doesn't mean agreeing with everyone. It means disagreeing more productively.

---
### Take bets on people
When I moved from IC to Team Lead, I had the chance to hire people. We hired fresh graduates with no publication record. The assumption in research is usually that you need experienced people to produce competitive work. I'm not sure that's true.

Given real problems, autonomy, and the trust to figure things out, these people produced work I couldn't have predicted. A [paper](https://arxiv.org/abs/2508.05053) received a [SAC highlights award](https://2025.aclweb.org/program/awards/) at ACL 2025. [Another](https://arxiv.org/abs/2510.27287) was nominated for best paper at EMNLP-25 in the resources category. A [third](https://arxiv.org/abs/2508.21141) got featured as a [top paper](https://x.com/dair_ai/status/1964727762658455744) in AI in the Sep-2025 and was [#1 on Hackernews](https://news.ycombinator.com/item?id=45094421). I list these not to claim credit but because the people who did this work deserve the record.

The bet isn't just about capability. It's about environment, and a big part of that environment is whether people genuinely believe they can do something hard. That belief doesn't arrive on its own. It gets built, slowly, through the small moments. Leading this team taught me more than I taught them.

Not every bet pays off. That's okay. The ones that do will change what you think your team is capable of, and more importantly, what they think they're capable of.

---
### Don't let measurement become a gatekeeper
Metrics matter. You need them to know if something is working, to compare approaches, to make decisions. No argument there.

But I've watched "how will you measure the impact?" become a way to kill ideas before they've had a chance to breathe. Some of the best projects I worked on had fuzzy metrics at the start. We built the thing, saw that it worked, and figured out how to measure it properly afterward. If we'd waited for a clean evaluation framework before starting, none of it would have happened.

In research specifically, this shows up as: "how do we evaluate this? We don't have a benchmark. We don't have a dataset." These are real questions. But most of the time, people treat them as terminal. The question stops the work rather than shaping it. The evaluation problem is almost always solvable once you have something worth evaluating. Starting is usually what unlocks the answer.

There's a related trap When a metric becomes the goal, it stops being a good metric, the Goodhart's law. You'll meet people who optimize for publication counts, or meetings logged, or whatever the organization happens to track, treating the measure as the target. Measures are instruments, not objectives.

---
### Think in timeframes
You can solve most problems in one month, three months, or one year. The approach changes completely depending on which you pick, and many people, at least in research, default to the longest one without really thinking about it.

A one-month solution is scrappy and limited. But it exists. It can be shown to someone. It generates feedback you can't get any other way. A one-year solution might be comprehensive and elegant, but it also might never ship because priorities shift, people leave, or the problem evolves underneath you.

I've come to think that the one-month version of almost any idea is worth building, if only to learn whether the longer version is worth pursuing.

This calculus is shifting with LLMs. Coding agents have made it cheap enough to build a rough version of almost anything in a day or two. A design document with a working prototype attached used to be unusual. It's increasingly the baseline. If the cost of a one-month proof of concept keeps falling, the case for defaulting to the longer timeframe gets harder to make.

---
### Your job description is the floor, not the ceiling
The most successful people I've worked with shared a habit: they didn't treat their role as a boundary. They noticed things that needed doing and did them, regardless of whether it was technically their responsibility.

I tried to practice this. Some of it was unglamorous: setting up servers, writing docs, building some basic tool because I could see we needed them to operate efficiently. None of it was in my job description. Most of it mattered more than I expected.

One thing I came to believe in strongly: try to do a fractional part of the job of the person you report to. Not to overstep, but because understanding the problems one level above you changes how you do your own work. When I understood what leadership needed to show their leadership, my decisions got sharper. I stopped optimizing for things that didn't matter and started anticipating what would be needed before anyone asked.

The same logic applies horizontally. The researcher who understands deployment constraints makes better research decisions. The engineer who understands the drawbacks of an approach builds robust systems. Think about the full stack, not just your layer.

There's a version of professionalism that treats your role as a boundary: this is my job, that is not. I understand the appeal. But "this is not part of my job" is a sentence that has never led anywhere good.

---
### Your work is not a finite game
There's a temptation early on to treat every project like something with a clear end state. Ship the paper. Hit the deadline. Move on to the next thing.

But the most meaningful work I did didn't have a finish line. Building a team culture. Establishing credibility with people in other functions. Developing a technical direction that could hold up over years. These things compound, and they don't resolve into a single win.

I've started thinking about my career less as a sequence of achievements and more as an ongoing practice. The papers and products and demos are milestones, but they're not the point. The point is the compounding: of skills, relationships, judgment, and the ability to take on bigger problems over time.

---
### Loose threads

Not everything I learned fits neatly into a section heading.

Sometimes the room is wrong and you need to build the thing anyway. Most pushback comes from reasonable places, but people reason from their own experience and their own blind spots. I've seen conviction paired with a working prototype change minds that no abstract argument could.

Pedigree signals less than the field assumes. Strong credentials attached to a poorly chosen problem lose their shine quickly, and good work from unexpected places tends to find its audience, just more slowly.

There are others I'm still working through: the gap between what organizations say they value and what they actually reward, reading the intent behind someone's words, knowing when to sheve a project. Maybe another post...

---
_I'm moving to an IC role at a startup. Less leading, more building. Fewer layers, faster feedback loops._

Part of the reason is something I kept noticing over the last year: my best weeks were the ones where I got to do hands-on work on problems that sat at the intersection of research and engineering, and where what I built actually reached people. In a large organisation, you have to orchestrate those collisions. In a startup, they're the default. I wanted that density.

There's a practical side too. This kind of leap gets harder to make as life fills up with other commitments, so the window felt right.

The shift also changes how I expect to find good problems. For most of my career, the direction has been bottom-up: pick an interesting research problem, solve it, then find someone who cares. I want to try the other direction. Build things people actually use, develop real engineering instincts, and let the research problems surface from that. I suspect the problems you find that way are harder to ignore.

_I've joined [Ema](https://www.ema.ai/) as an ML engineer, and I'm looking forward to finding out if I'm right._

---

_Now for the part that matters most. None of this happened in isolation._

To the leadership at Fujitsu, Vivek Mahajan, Seishi Okamoto , Toshihiro Sonoda, John Walsh and Ken Toyoda: thank you for trusting an early-career researcher with the freedom to build something. The autonomy you extended, to pursue a research direction, hire a team, and pitch ideas that were probably more ambitious than they had any right to be, is not something every organisation offers. It changed what I thought was possible. That freedom is why most of this post exists at all.

To my managers in India, Manohar Kaul and Mahesh Chandran: you shaped how I think about research and what it's for. Manohar, you gave me room to work on problems I genuinely cared about and cleared the path when things got stuck. Mahesh, you taught me how to manage a small team without losing the ability to stay close to the work itself. You also taught me something harder to name: when to speak, what to say, and how to read a room before you open your mouth. That balance is harder than it looks, and watching you navigate it was its own kind of education.

To Hiromichi Kobashi and other Senior project directors and Managers in Japan, Masahiro Fukuyori, Koichi Shirahata, Genta Suzuki, Kaoru Yokoo, Kosaku Kimura : thank you for the collaboration, the patience, and for helping connect the work to people and contexts beyond what I could see from my desk.

To my team: Parth Thakkar, Pranoy Panda, Vartika Sengar, Suraj Nagaje, Ankush Agarwal, Harsh Vishwakarma, Ajay Sastry, Shrey Satapara, Prasad Kasu, Pranav Bhagat and Ujwal Sai, Ganesh and to the interns, Ojas, Pulkit and Raghav. You showed up, took ownership of hard problems, and produced work that got recognized well beyond the walls of the lab. A special mention to Pranoy, Ankush, and Shivangana, who said yes when I walked up to them and said "I'm starting a team, I'm barely a year ahead of you." That kind of trust goes both ways, and I hope I earned it.

Leading this team taught me more than I taught them. I suspect that ratio is how it's supposed to work.

And to CK Jagadeesha, Pooja Ranjan, Shahla Sultana, Tohru Tsuruta, Milind Kulkarni and many others: you made the lab a place I actually looked forward to walking into. Some of the best days at the lab had nothing to do with research.

To Fujitsu Research India as a whole: from naming meeting rooms after Turing Award winners and Nobel Laureates to doing research that opened real business opportunities and won awards, this was where I figured out what kind of work I want to do. The foundation is strong, the talent density is exceptional, and I hope it grows into the innovation centre it has every reason to become.

_Three and a half years. My first job. On to the next one!_



Every experience is a lesson. The only question is whether it's teaching you how to do something or how not to. The trick is to stay curious long enough to figure out which kind of lesson you're in the middle of.

A great manager shows you what good leadership looks like up close. A bad one is harder to sit through, but if you pay attention, you walk away with something equally useful: a clear picture of the manager you never want to become. 

No place is all good or all bad. Most sit somewhere in the middle. The trouble starts when the negatives outweigh the positives, and what was once a learning environment starts to feel like a tax you're paying just to stay.

I recently discovered Prof. John Ousterhout's ["Thoughts for the weekend" playlist](https://www.youtube.com/playlist?list=PLcs1ZorNr2uTGPZPZnBa408qLVHjbMTzT) and one metaphor about learning and growth resonated: **A little bit of slope makes up for a lot of y-intercept**. He expressed the concept of growth mindset in an elegant, simple and mathematical way. 

![slope_image](/api/image?path=slope_image.png)
Source: [https://www.youtube.com/watch?v=mE98Is1quwY](https://www.youtube.com/watch?v=mE98Is1quwY)

The idea is straightforward: Plot two lines with different slopes -- the one with steeper slope will eventually surpass the one with higher starting point (y-intercept). Applied to life, this means how quickly you learn matters far more than how much you know at the outset.

Your y-intercept is where you begin: your initial knowledge, credentials, or experience. Maybe you graduated from a top college, or you've already worked in a field for years. This gives you an early advantage.

Your slope is your learning rate -- how quickly you acquire new skills, adapt to challenges and grow. This determines your long-term trajectory. The person who learns faster will eventually overtake the person who merely started ahead.

**Slow and steady slope wins the race!**