First Engineer to Organization

Being the first hire for a product nobody local had built.

The technical story of what we rebuilt is told elsewhere. This is the story of how a team capable of rebuilding it came to exist at all.

The situation

In February 2013 I joined VMware as the first engineer in Bangalore for vRealize Operations. The product had come in through acquisition. The people who built it were in Palo Alto and Armenia. There was no local team, no local knowledge, and no track record for the site to point at.

The unstated question was not whether I could write code. It was whether this location could be trusted with a complex, business-critical product. Everything about the next three years followed from how that question got answered, and it was going to be answered early.

What made it hard

Strategically. New sites do not get the benefit of the doubt. Work is allocated where it has succeeded before, which means a new site needs a result before it is given the work that would produce one. Breaking that loop was the actual job.

Technically. I had to become competent in a large system I had not built, without a formal knowledge-transfer process, fast enough that my questions sounded informed rather than expensive. Every hour of a senior engineer’s time in Palo Alto spent explaining basics to Bangalore was an argument against Bangalore.

Organizationally. Growing from one engineer to around a hundred people while the product itself was being re-architected meant everyone joined a moving target. And for a long stretch there was exactly one person who knew both what the product currently did and what it was becoming.

What I did

I reverse-engineered the product rather than waiting to be taught it. I read the code, traced behaviour, and started contributing to releases before any formal transfer had happened.

The first two quarters were not glamorous and they were the right work. Within three months I was building the licensing capability for the vCloud Suite Standard and vSOM SKUs, on my own, to a Product requirement. Nobody gives that to a new engineer at a new site unless they have already decided he can be relied on. I worked through security fixes. And I did performance work on large relational datasets for customers who could not wait out a re-architecture that would take more than a year.

Somewhere in that period I started finding faults in the product and fixing them, and then challenging the engineers who had built it about the ones I could not fix alone. That is a strange thing for a new person at a new site to do. It was reviewed properly by the teams in Palo Alto and Armenia, and I had backing from the VP and the Chief Architect for doing it. That is the actual reason the work started coming here. Not because I was careful. Because I was useful and willing to be uncomfortable.

Then I hired. The team went from one to four to ten, and I was closely involved in choosing every one of them at both experience levels. As the site grew toward a hundred across engineering, QE, support and documentation, I worked on knowledge transition as an explicit activity rather than a side effect, and on partnering with the teams at headquarters so the relationship ran on work rather than on process.

I also pushed prototypes through to production, which mattered beyond the features themselves. Each one was evidence that ideas could start here and survive.

The decisions

Wait for transfer, or reverse-engineer

The fork. Wait for structured knowledge transfer and start contributing once properly onboarded, or work it out independently and start immediately.

The call. Reverse-engineer.

The cost. Exposure. Working from inference rather than instruction means being confidently wrong in public, and I had no credibility banked to absorb it. Getting something visibly wrong in the first month would have cost the site more than it cost me, because I was the only evidence about the site that existed.

Hire experienced, or build through campus

The fork. Experienced hires would contribute sooner. Campus hires would take longer and be shaped by the product.

The call. A deliberate mix, hand-picked at both levels.

The cost. Near-term velocity. New graduates took quarters to become independently productive, and those were quarters where the site was still being evaluated. I spent capacity I did not obviously have on people who would matter later.

Concentrate on the rebuild, or split my own time

The fork. Hand sustaining to the new team and put myself entirely on the re-architecture, or split my time — mentoring them through the minor versions while staying hands-on with the rebuild.

The call. Fifty-fifty, well past the first six months.

The cost. Neither track had my full attention. The re-architecture moved at roughly half the speed it could have. And the engineers on the minor versions learned alongside me rather than by owning the work outright, which made the eventual handover slower than giving it away would have been. A split role buys continuity and spends velocity, and the bill arrived on both sides.

Hold the knowledge, or distribute it

The fork. As the team scaled, product knowledge could stay concentrated in the earliest engineers, or be deliberately spread through knowledge-sharing sessions and structured onboarding.

The call. Distribute it.

The cost. The experienced engineers spent time teaching and transferring context instead of solving the next problem themselves — which, in a team where there were very few of them, was the scarcest thing we had. And there was an unavoidable ramp where new engineers had breadth before they had depth. For a period the team knew more collectively and less deeply, and the hardest problems still came back to the same few people.

What changed

1→4→10→~100

One engineer became a team, then an organization of roughly a hundred across engineering, QE, support and documentation, inside a global product organization of around two hundred. Work stopped being allocated to Bangalore because there was capacity and started being allocated because it was the right place for it.

What I carried forward

My scope expanded before my title did, and that stopped being an accident. I was doing hiring, knowledge architecture and site-building for years before any of it was formally mine. What I learned is that the responsibility is usually available before the role is, and that taking it is how the role eventually arrives.

Seven years later I was the first engineer on another organization. I knew what I was doing the second time because of what this cost me the first.