The Software Engineer at the Core of the Product

Before talking about leadership—a topic I’ll cover in my next post—it’s essential to understand the teams being led. In this case, I want to focus on a key figure in any technology organization: the software engineer.

Throughout my career, I’ve watched this role evolve, along with the expectations around its skills and responsibilities.

The software industry has gone through profound transformations—largely thanks to thought leaders who rethought how we build digital products and services—and, as a result, what we expect from a software engineer has changed too.

Although some corporations still try to rigidly dictate what an engineer should do or code, the reality is that the role has expanded: today, engineers actively take part in decision-making and in shaping solutions.

The modern software engineer is a key collaborator—the technical heart of the product.

It’s essential to recognize that their impact doesn’t depend solely on technical knowledge. To deliver real value, they need to develop both technical skills (hard skills) and interpersonal and organizational skills (soft skills).

A developer’s work is much broader than writing code. Beyond programming, they take part in essential activities that ensure the team continuously delivers value to the business—from collaborating with stakeholders to the constant evolution of the team and the product.

If we imagined the weight of each of these areas in their day-to-day work, the act of coding would likely take up only part of it. The rest is spread across design, validation, communication, support, technical decisions, and product evolution.

How a software engineer’s time is distributed

1. Programming and development (30%–40%)

• Writing and reviewing code.
• Implementing features based on sprint requirements.
• Refactoring code to maintain quality standards.
• Automated testing (unit and integration).

2. Refinement and discovery (15%–20%)

• Taking part in refinement sessions to understand and break down user stories.
• Analyzing requirements with the Product Owner and stakeholders.
• Joining discovery work to research technical solutions or alternatives.
• Validating and clarifying technical questions during planning.

3. Communication and collaboration meetings (15%–20%)

• Dailies: reviewing progress and coordinating with the team.
• Planning and retrospectives: defining sprint goals and improving processes.
• Syncing with other areas: collaborating with UX designers, DevOps, QA, and others.
• Communicating with stakeholders to align the technical vision with business expectations.

4. Testing and quality control (10%–15%)

• Test-driven development (TDD/BDD) to ensure robust code.
• Code reviews to maintain quality standards and share knowledge.
• Fixing bugs found in test or production environments.

5. Research and continuous learning (10%–15%)

• Exploring new technologies or patterns that add value to the team.
• Training in best practices and development tools.
• Documenting processes and continuous improvements.

6. Continuous improvement and automation (5%–10%)

• Optimizing team processes (automation, scripts, pipelines).
• Helping improve development practices within the team.
• Monitoring and tuning CI/CD tools to improve the workflow.

Their work begins at the earliest stages of the product lifecycle: they take part in discovery, collaborate on design, understand business needs, shape viable solutions, and take ownership of quality and maintenance.

Conclusion

The software engineer shouldn’t be reduced to an operational role limited to writing lines of code. Their work begins at the earliest stages of the product lifecycle: they take part in discovery, collaborate on design, understand business needs, shape viable solutions, and take ownership of quality and maintenance.

It’s crucial to invite them to engage actively with business rules, hypothesis validation, and technical decisions that directly affect the product. In this sense, they should be treated as a source of value and as co-owners of the outcome—not just of the deliverable. That also comes with the duty to accept the consequences—positive or negative—of their involvement, or their absence.

They shouldn’t be evaluated solely on their ability to write code or on numeric productivity metrics. Their real impact shows in how they contribute to understanding the business, in their engagement with the team, in the continuous improvement of the product, and in shared responsibility for quality.

Treating them as co-owners of success means widening the lens we measure them with. It’s not about controlling their output, but about observing their growth as well-rounded professionals: How do they add value? How do they adapt? How do they improve? How do they collaborate?

Evaluations should therefore focus on the quality of the work, technical maturity, teamwork, and the continuous improvement of their processes—without neglecting the technical responsibilities the team shares.