How four years at a startup changed the way I work - Diogo Moreira How four years at a startup changed the way I work<br>Reflections on my time at Amplemarket<br>June 19, 2026 · 10 min read

I resigned from Amplemarket after four very fulfilling years.

When I joined, I thought I had a reasonable sense of what good work looked like: how teams should be organized, what<br>made people productive, and what kind of role I wanted to grow into. I don’t think those assumptions were obviously<br>wrong, but they were much more incomplete than I realized.

This post is a reflection on what made this experience different and how it changed the kind of work I want to do. I<br>left less attached to my technical identity and more convinced that the work I enjoy most happens close to product<br>problems.

Building product

At most of the software companies I worked for, product work was organized around specialized roles. Product managers<br>owned product direction; engineers owned implementation. Engineers also tended to specialize in frontend or backend and<br>usually did not cross boundaries other than for very trivial tasks.

Product managers acted as the interface with stakeholders and decided how our product would create solutions for their<br>problems. Features were built from requirements they had defined, usually after a technical manager had already<br>validated the technical approach.

As a backend engineer, I focused on the technical problems I had to solve. Things like designing systems with clean,<br>maintainable architectures that could perform at scale; figuring out how to best model a feature for the current use<br>case but also make it future-proof; identifying and tackling technical debt; ensuring the systems we maintained were<br>observable; ensuring the system was properly tested.

Obviously I needed to ensure functional requirements were implemented correctly, but correctness was defined by the<br>spec and not by understanding the problem and whether it was addressed.

Most of the time I would design an API the frontend would consume and then start implementing it. In practice this meant<br>that I often wouldn’t even need to run the frontend while doing my work and, naturally, I found myself not even knowing<br>how to use the product I was developing.

At some point I realized this process was too abstract for me and I wanted to understand the actual problems we were<br>trying to solve. Because I felt the abstraction was mostly caused by the hierarchy and specialization that bigger<br>companies require, I started looking for an early-stage startup where I could build product and not just technical<br>solutions.

At Amplemarket I had the opportunity to collaborate with the product team much more closely than ever before. I<br>understood the product we were building and the problems we were trying to address. I talked with customers, I heard<br>rough feedback about our product, but also saw their excitement when we were showing them features we were building.

I really enjoyed the process of building a feature end to end. Understanding the problem, exploring possible solutions,<br>thinking about tradeoffs, how the feature would integrate into the platform, what existing primitives could be reused<br>and which ones would need to be created.

I don’t see myself ever going back to a position where I don’t actively participate in exploring solutions to a problem,<br>end to end.

Agility, speed and processes

Most companies I worked for aimed to be Agile and used the Scrum framework. Usually in two-week sprints, with a<br>planning session at the beginning of the sprint, multiple refinement sessions where tasks were estimated using story<br>points and a retrospective at the end. Each sprint would have a set goal – either a set of tasks the team would work on<br>sequentially until finishing or tasks assigned to someone from the start. With the odd exception, the goals would be<br>very attainable and I would be able to finish my work rather easily and still find time for technical work that was of<br>interest to me.

When I joined Amplemarket, I expected a smaller company to have a lighter version of the same thing. Instead, we had<br>almost no formal planning process: there was an issue tracker, a daily sync and that was it. What a disorganized mess,<br>right? Wrong!

What a joy it was to work that way. We did not estimate task effort or try to fit a fixed number of tasks into a<br>sprint. We picked the most important thing we knew about, worked on it and adjusted as we learned. We did not follow<br>Agile, but it was the most agile working environment I’ve ever experienced. We could decide, build, learn and adjust<br>quickly.

Maybe that only works in a specific setting: an experienced, capable, high-trust team and a product team that is not<br>shifting priorities based on the position of the moon. But that was the setting we had, and I’d never felt so<br>productive.

During my onboarding, I remember being very impressed by how such a small team had been able to produce so much in so<br>little time. Since no one was...