How four years at a startup changed the way I work
Reflections on my time at Amplemarket
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 made people productive, and what kind of role I wanted to grow into. I don’t think those assumptions were obviously 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 left less attached to my technical identity and more convinced that the work I enjoy most happens close to product problems.
Building product
At most of the software companies I worked for, product work was organized around specialized roles. Product managers owned product direction; engineers owned implementation. Engineers also tended to specialize in frontend or backend and 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 problems. Features were built from requirements they had defined, usually after a technical manager had already validated the technical approach.
As a backend engineer, I focused on the technical problems I had to solve. Things like designing systems with clean, maintainable architectures that could perform at scale; figuring out how to best model a feature for the current use case but also make it future-proof; identifying and tackling technical debt; ensuring the systems we maintained were observable; ensuring the system was properly tested.
Obviously I needed to ensure functional requirements were implemented correctly, but correctness was defined by the 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 that I often wouldn’t even need to run the frontend while doing my work and, naturally, I found myself not even knowing 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 trying to solve. Because I felt the abstraction was mostly caused by the hierarchy and specialization that bigger companies require, I started looking for an early-stage startup where I could build product and not just technical solutions.
At Amplemarket I had the opportunity to collaborate with the product team much more closely than ever before. I understood the product we were building and the problems we were trying to address. I talked with customers, I heard 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, thinking about tradeoffs, how the feature would integrate into the platform, what existing primitives could be reused 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, 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 planning session at the beginning of the sprint, multiple refinement sessions where tasks were estimated using story points and a retrospective at the end. Each sprint would have a set goal – either a set of tasks the team would work on sequentially until finishing or tasks assigned to someone from the start. With the odd exception, the goals would be very attainable and I would be able to finish my work rather easily and still find time for technical work that was of interest to me.
When I joined Amplemarket, I expected a smaller company to have a lighter version of the same thing. Instead, we had almost no formal planning process: there was an issue tracker, a daily sync and that was it. What a disorganized mess, 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 sprint. We picked the most important thing we knew about, worked on it and adjusted as we learned. We did not follow Agile, but it was the most agile working environment I’ve ever experienced. We could decide, build, learn and adjust quickly.
Maybe that only works in a specific setting: an experienced, capable, high-trust team and a product team that is not shifting priorities based on the position of the moon. But that was the setting we had, and I’d never felt so productive.
During my onboarding, I remember being very impressed by how such a small team had been able to produce so much in so little time. Since no one was working crazy hours, this suggested the team worked much faster than what I was accustomed to seeing. It’s hard to say exactly what the main factor contributing to the speed was, but it was likely a combination of talent, tech stack, and just enough process to stay aligned without getting in the way.
Once I realized that some teams could produce much faster than others, I started appreciating the value of intentionally trying to work faster.1 I also started being much more conscious of how processes could affect team speed. Paul Graham has used a metaphor that I haven’t forgotten, equating companies’ processes to the body’s scar tissue – too much of it, and you can no longer move. I’m especially wary of processes added after post-mortems or retrospectives. As the saying goes, the road to hell is paved with good intentions.
As the company grew and the middle management layer started forming, some of the practices of Scrum were implemented. The main argument was that the business needed more predictability and the lack of process was preventing that. I’m highly skeptical of the merits of predictability as the main goal. You can be predictably slow and that’s certainly no good. I’ve seen how teams start protecting themselves by bloating the estimates of tasks in order to have a little room for surprises. Committing to a goal for a sprint becomes a game of optics. There’s just no incentive in the process to go after more ambitious targets.
Building a great team
Amplemarket was the best team I’ve worked with professionally. The work was challenging, but people cared about delivering good work, they were nice to work with, and I got to learn a lot from everyone. I always felt like I was interacting with someone who was very good at their job and that felt great.
During my interview process I spoke with at least eight different people, which was at least ten percent of the team back then. There were multiple technical stages, a culture interview and a meeting with each of the three founders. As a candidate, I found the process long but enjoyable. I was interviewing the company as much as they were interviewing me and I ended up really impressed with everyone I met.
Seeing it from the inside, I realized having this kind of process in place requires a considerable investment from the company. Each stage would filter out candidates and I recall many technically sound candidates that were rejected at later stages. I often wondered if this was a good use of everyone’s time: shouldn’t we be doing real work instead?
Over time, I realized this was the reason why the company built such a strong and culturally aligned team. The process is designed not only to select good candidates but also to ensure poor fits are filtered out.
I’ve seen first-hand how much damage a poor fit can do to a small team. When someone can’t be trusted with certain tasks, reacts badly to feedback, is unreliable or simply doesn’t care, the team dynamics change and everyone does worse work.
Every time someone asked me why I liked working at the company or why they should join, my genuine first answer would be that the team is great. Everything else that is great about the company is a downstream consequence of that.
Why stack matters less than I thought
For most of my career, I worked with Java or the JVM. I had built considerable expertise with it and whenever I looked for a new project I was hesitant to change stacks. Wouldn’t I be throwing away my expertise just to start from scratch?
Some familiarity with the stack you’re working with does matter for the quality of the work you do: how to write idiomatic code, which tools exist around the language and which libraries are best for a particular task. But if you’re joining a team that built the product from the ground up, they’ll probably have deep expertise in the stack, and you’ll be able to learn from them.
At Amplemarket I found myself working on a Ruby on Rails monolith. It took me a while to get used to a dynamically typed, interpreted language, but I managed just fine. I had a bunch of assumptions about that stack: interpreted languages are not performant; maintaining any non-trivial codebase in a dynamically typed language will be an endless pit of bugs. Those assumptions turned out to be wrong.
I know engineers who would’ve outright refused to change jobs to work with a technology they don’t already know. I think that’s a disservice to themselves. You can build great products with any of the popular languages and stacks. I believe that having meaningful production experience with different stacks makes you a better engineer.
On being optimistic
One of the four Amplemarket company values is Curious Optimism. I wouldn’t say I’m a pessimist by nature but my programmer’s brain would usually get really focused on the edge cases of a lot of things. Looking at a project I’d tend to focus on how it could fail. That’s not necessarily a bad exercise – pre-mortems are useful after all – but I focused too much on it.
I’m happy to announce that I’m cured on that front! I’m only half joking. I’ve realized that optimism is required for doing anything meaningful and non-trivial. I’m not advocating for being a fool: not everything can be done and no amount of positive thinking will change that. But defaulting to pessimism is the easy way out: you avoid trying anything risky yourself; you try but sabotage your way into a self-fulfilling prophecy; or you play The Old Man of Restelo by becoming the pessimist in other people’s projects. Either way, there’s no fun in that.
What I want to do next
Four years ago I thought of myself as a very specialized software engineer, committed to staying on the technical track and aiming for a future staff or principal engineer role. I wanted to have more impact, and I assumed that meant going deeper in that direction.
I still care about the craft of building software, but I no longer want it to be an end in itself. The work I enjoyed most was the work that sat between understanding the problem, shaping the product and building the solution.
That is roughly the shape of what I want to do next. I’m mainly interested in work where I can help shape the product and also build it. That could mean taking a vague idea and turning it into a first version, joining an early team for a specific project, or helping an existing team get something important unstuck.
If you’re building something and think I could help, I’d be happy to talk.