In February 2015, while I was considering a job at Reonomy, I made a deck called “Teams and Organization.” I was still at Shutterstock and had not accepted the role.
Reonomy already had a product, customers, engineers, and a couple of years of decisions in the codebase. I was not starting with an empty organization chart. I was trying to work out how product and engineering could grow together if I joined.
The deck centered on cross-functional product teams. Each team would own a customer or product area, such as user value, major accounts, APIs, or data. The people needed to handle that area would work together instead of passing work between separate product, design, engineering, quality, and technology operations groups.
The teams did not have to look identical. A group responsible for data systems might need a different mix of skills than one working on the user experience. The point was to give each team enough range to solve its problem without waiting on several other teams for every release.
Functional leaders still mattered. They would be responsible for people management, design quality, engineering practices, operations, and the growth of each discipline. Technical leads would work inside the product teams and help with daily decisions.
I wanted the product team to own the customer result. I wanted functional leaders to help people improve at their craft. That sounds obvious, but it can get confused quickly in a matrix organization. If everyone is consulted on a decision, nobody may be clearly responsible for the outcome.
The deck assigned teams responsibility for planning, prioritizing, sprinting, and delivering. It also said they should own the success or failure of the sprint and change the approach when something did not work.
I listed results, value delivery, positivity, and participation as ways to assess teams. For individuals, I included teamwork, bias for action, customer obsession, values, and results. Some of that language came directly from what I had seen work at larger product and engineering organizations.
I did not want product managers to hand requirements to engineering and then wait for the finished work. I also did not want technology operations sitting outside the product as a service desk. The team working on a problem needed enough authority and technical range to make decisions and ship.
The values section was also plain: act; offer ideas and speak up; support diversity and positivity; focus on the customer; try things, learn, and iterate. Positivity appeared again in capital letters in the recruiting section. I cared about whether people made a team easier or harder to work in, not only whether they could pass a technical interview.
The hiring plan involved several people from the team. Candidates would be evaluated in their main area and in any additional areas where they could contribute. The group would discuss the hiring decision together. Skills mattered, but so did ethics, values, and how the person worked with others.
Onboarding was part of the same plan. New employees needed clear expectations, a clear understanding of the company values, and work that matched the skills we had hired them to use. Hiring quickly would not help if people spent their first months figuring out who could make a decision.
The deck assumed Reonomy might grow quickly. If that happened, many new employees could arrive before the existing team had a strong way to explain how work got done. I wanted the recruiting and onboarding process to carry that information instead of leaving it with a few founders or managers.
There were still a lot of things I did not know. I had not worked in the codebase or with the team. I did not know which parts of the structure would fit the company and which would need to change.
The deck was my starting point: small cross-functional teams, clear ownership, functional leadership, group hiring, and deliberate onboarding. It was also part of how I decided that I wanted the job.