Years of Experience Do Not Tell You Which Experience Someone Has

I know excellent engineers who have spent five years inside one company, built strong careers, and become genuinely good at their jobs.

Yet when some of them want to create a product from scratch, they message me for help.

That does not make them bad engineers, or make me a better engineer. It means the work they want to do now calls for experience that differs from the work they have been doing.

What was already in place?

Inside a large organization, an engineer may become exceptional at a difficult part of an established system. The business direction, architecture, deployment process, and surrounding team may already be there.

Working deeply within those conditions can be exactly what the organization needs. It can also involve substantial decisions and responsibility. The company’s size alone does not tell you what someone owned.

Starting a product presents a different set of questions. Before implementation, someone has to understand the business problem, decide what the first version should achieve, and work out how the parts should fit together. After launch, that person may need to reconsider those decisions as users reveal what the plan missed.

The useful distinction is which decisions a person has made, under which conditions. Counting years without that context hides the experience you are trying to evaluate.

Why I kept working beyond the technical task

Throughout my career, I have worked with more than 15 teams, starting as a freelancer. My level of involvement differed from one company to another, but I consistently wanted to work close to founders and stakeholders and understand the complete product.

• How does the business make money?
• Who will use the product?
• What should we build first?
• And how should we design and build it?

I could not treat those questions as somebody else’s world and limit myself to an isolated development task.

Across those projects, I gained experience with decisions before the first line of code, through launch, and into what needed to change once real users arrived. Moving between companies also meant learning a new business context rather than assuming the previous product’s choices would fit the next one.

That is the experience I can bring when someone asks me how to start. It became one of my biggest motivations for building Codisar: bringing together a team that can help with that whole journey.

Match the evidence to the responsibility

Breadth does not guarantee excellence. Someone can touch many areas without learning to own any of them well. Equally, a specialist can bring deep judgment that a broad generalist does not have.

If you need someone to improve a difficult part of a mature system, ask about comparable systems and the specific decisions they made there.

If you need someone to turn an unclear idea into a first product, ask for evidence of that journey:

• What was still unknown when you joined, and which decisions did you personally own?
• How did you decide what belonged in the first version?
• What changed after users arrived, and what did you do about it?

All of those roles can be valuable. Your hiring decision depends on which one you need someone to take responsibility for now.