In December 2016, I was talking with Ethan at Aaptiv about a product and technology role. He asked about one of the engineering leaders at Reonomy and whether I had hired him as a manager.
I had not. He joined as an individual contributor and developer. He proved that he was capable, and I promoted him when the engineering team needed more leadership and the product organization required more of my time.
In fact, I had not hired any managers into Reonomy during my time there. I hired individual contributors and developed managers from inside the team.
For a while, the management work reported directly to me along with product and engineering. That was manageable when the group was small. As the company added people and product work, I could not be the decision point for every technical issue, every hiring question, every performance conversation, and every product priority.
I tried to account for that when hiring. I looked for people who could do the job we needed immediately but also had room to take on more responsibility. Strong technical work mattered. I also paid attention to judgment, communication, and whether somebody helped other people get work done.
The original plan assumed Reonomy would grow into a much larger organization within eighteen months. That plan changed, and we eventually had to make the organization smaller instead.
That made the management path less predictable. I could tell somebody that I saw leadership ability. I could not promise that the company would create a particular team or title on the original schedule. Startup hiring plans move with revenue, fundraising, product direction, and the needs of the business.
Growing leaders during a contraction was also different from doing it during expansion. When a company is growing, new teams and management jobs appear naturally. When it is getting smaller, someone may be asked to lead while priorities narrow and people leave. The work still needs an owner, but the context is harder.
I continued to prefer internal development where it made sense. Reonomy’s product and technical history was complicated. We had to keep the existing commercial real estate product running while building toward a national data platform. A developer who had already worked through those systems knew the tradeoffs and had credibility with the team.
That did not mean every strong engineer should become a manager. Some people do not want the job. Technical skill does not automatically make somebody good at feedback, hiring, or difficult conversations. We had to look at what people were already doing, not only what their next title might be.
I paid attention to the people who could make a technical decision and explain it clearly. I noticed who gave useful feedback, handled disagreement without stalling the work, and cared about the customer and company result. Those were signs that someone might be ready for more responsibility.
Once we promoted someone, the role needed real authority. It would not help to give a person a manager title while I kept every decision. It also would not be fair to hand over all of the hard people problems without giving that person room to lead.
The product side was taking more of my attention by then. Promoting an engineering leader created space for me to work on the product organization while technical ownership stayed close to the engineers doing the work. The person I promoted had joined as a developer and shown the team what he could do before his role changed.
I would not turn this into a rule that companies should never hire experienced managers. Sometimes a team needs management experience it cannot develop fast enough. Sometimes the right internal person does not want the role. At Reonomy, though, developing people already on the team was the approach I used.
That was my answer to Ethan: I had hired individual contributors, watched who grew into leadership, and promoted managers from within the team.