I started a mentorship with Vanessa Malerba through Elas São Tech 2026, and the first session already narrowed the focus more than I expected: translation work.
In this context, translation refers to closing the gap of meaning between what engineering produces and what other areas need in order to make decisions: product needs to forecast delivery, marketing needs to align campaigns, operations needs to plan execution, and UX needs to validate hypotheses. None of these decisions depend on access to the code itself; they depend on clarity around state, flow, and impact.
This kind of work tends to appear before any formal title change. My work routine already covers negotiating deadlines with areas that do not see the code, being accountable for deliveries that depend on multiple actors, and handling urgent requests that arrive without context. This is less about producing more, and more about coordinating better. Coordination, in turn, requires a shared language.
The first session of the mentorship was structured around this point. Leadership was framed as positioning, meaning the ability to influence decisions regardless of formal hierarchy. This positioning involves sustaining decisions, making consequences explicit, and introducing criteria where there was previously only reaction. When a new request appears as urgent, the question shifts from simply accepting or refusing it to understanding its impact on the rest of the flow.
Within this context, what I’ve nicknamed as defensive metrics come into play. Unlike traditional performance metrics, they serve to record exceptions: how often priorities changed, how many requests entered outside the planned flow, and how many interruptions occurred during delivery. Once organized, this data shifts the discussion away from individual perception and toward evidence. As a result, negotiation becomes more objective and less dependent on informal argument.
Without this type of record, patterns tends to repeat. Each exception is treated as an isolated case, even though recurrence gradually establishes a structural behavior. Over time, exceptions consolidate into routine, compromising predictability. From the outside, this appears as delay; internally, it manifests as diffuse overload. In both cases, what is missing is visibility into what actually happened.
Making the flow visible is a direct response to this problem. The goal is not to increase technical detail, but to build an interface that other areas can understand. At the moment, much of the work tracking still lives in the code: pull requests, commits, deployment history. While this is sufficient for those with access and already inside the technical context, it does not address the needs of those who depend on the outcome without participating in implementation.
The first practical task from the mentorship is to structure a kanban board in Notion with purpose of visibility. This shifts the construction criteria: columns are no longer shaped by internal convenience, but by what is readable to others. Instead of generic categories like “in progress,” it becomes more useful to define stages such as development, validation, testing, and deployment, since each signals a different type of risk and dependency.
The origin of each request also becomes relevant. Identifying whether a demand comes from product, marketing, or operations helps map workload distribution and supports prioritization discussions. When a new request appears, the decision involves what will be displaced to accommodate it, rather than evaluating urgency in isolation.
Another important point is delivery traceability. It is not enough to consider an item technically complete; it needs to be clear when it is actually available for use. This distinction avoids common ambiguity in deadline alignment and contributes to more precise communication.
Organized in this way, the board moves beyond an internal management tool and becomes a shared reference. It reduces the need for status update meetings, lowers communication noise, and exposes bottlenecks more directly. At the same time, it provides a more solid basis for negotiation across areas.
The mentorship lasts two months, with weekly sessions, and the initial focus is to consolidate this structure before moving on to other topics. There is also a guiding rule: finish what has been started before expanding scope. This constraint fits the current context, where the team is still small and much of the work remains individual contribution. The natural tendency would be to postpone structure in favor of immediate execution, which often creates additional friction once more stakeholders become involved.
Elas São Tech 2026 provides the space where this kind of discussion happens with a specific lens. The program brings together women working in technology and creates an environment for practice-oriented exchange. In its current form, it operates as a pilot, with close mentorship and an expectation of structured feedback from participants.
Vanessa Malerba leads the mentorship drawing from a background that spans administration, project management, and operations. This shows in how problems are framed. The focus shifts away from specific tools and toward the organizational dynamics in which those tools operate. That shift makes the interface between areas part of the technical work itself.
As this perspective settles, it becomes clear that code is no longer the only point of attention. At a certain stage, the main constraint on delivery becomes the level of shared understanding across areas. When engineering needs to repeatedly explain its own work so that others can act on it, the problem is already present before delivery.
The mentorship starts from that diagnosis. Adjusting how work is exposed, before increasing delivery volume, changes the quality of interactions and reshapes the kind of problems that emerge.