Author: Edvaldo Freitas
-
Dealing with Production Incidents and Postmortems in Growing Teams
When the engineering team is small, dealing with production incidents usually feels simple. A few people who know the system well jump on a call, figure out what’s wrong, and deploy a fix. The process is fast, loosely structured, and relies on the experience of whoever is there. This works for a while. But as…
-
Feature Flags and gradual rollouts: releasing software safely at scale
Shipping a large change to a production system with a big user base creates a very familiar kind of stress. The business wants to move fast, but engineers know that “big bang” deployments carry a disproportionate amount of risk. A single bad deploy can mean a major incident, a complex rollback under pressure, and a…
-
How to keep engineering and product teams aligned
As a company grows, the way engineering and product teams work together begins to wear down. What used to be quick hallway conversations and shared assumptions turn into missed deadlines and runaway scope. You start seeing features shipped without the user impact everyone expected, and the engineering team begins to feel like a feature factory,…
-
Optimizing CI/CD as the development team grows
The first sign of trouble is usually the build queue. A few developers join the team, commit frequency goes up, and suddenly the CI/CD pipeline that used to feel fast turns into a 45-minute wait for feedback on a small change. Developers start context-switching while they wait for tests to pass or, worse, they start…
-
Monorepo governance: module best practices and code ownership
At the beginning, the idea of a monorepo is quite appealing. Having all the code in one place, centralized dependencies, and the ability to change multiple parts of the system at once simplifies a lot of things. This works well while the team is small. As the team grows, however, that simplicity starts to fade.…
-
Ensuring Software Quality at Scale: Automated Testing and QA in Large Teams
When a team is small, keeping software quality under control feels intuitive. You can review every pull request, you know the history of the more “risky” parts of the codebase, and the feedback loop between writing code and seeing it running in production is short. But as the engineering team grows, all of that starts…
-
Implementing Domain-Driven Design in a Growing Company
At a certain stage of growth, the codebase stops making intuitive sense. Logic that used to be simple becomes spread across multiple services. A change to the “user profile,” for example, starts affecting five different parts of the system, each with a different definition of what a “user” is. This happens when the original, shared…
-
When should you invest in Developer Experience?
At a certain point in a company’s growth, you start to notice some strange things happening. Adding more engineers doesn’t seem to make the team any faster. The first month of a new hire is spent just trying to get the local development environment running without errors. Simple bug fixes that should take an hour…
-
How to Identify (and Fix) Bottlenecks in Your Code Review Process
As an engineering team grows, the code review process is often one of the first things to show signs of strain. What used to be a quick, collaborative check turns into a queue. Pull requests start to pile up, delivery slows down, and you can feel the impact on the team’s pace. The default assumption…
