Select Page
The Software Engineer as the Product’s Core

The Software Engineer as the Product’s Core

by | May 14, 2025 | Concepts, Reflexions

The Software Engineer as the Product's Core

Why reducing the Software Engineer to just a “code writer” is a strategic mistake

Before discussing leadership—a topic I’ll cover in the next post—it’s essential to understand the teams that will be led. In this particular case, I want to focus on a key figure within any tech organization: the Software Engineer. Leadership will be addressed in the next post.

Throughout my experience, I’ve witnessed how their role has evolved, as well as the expectations regarding their skills and responsibilities.

The software industry has undergone profound transformations—largely thanks to thought leaders who redefined how we develop digital products and services—and, as a result, the expectations for Software Engineers have changed.

Although some corporations still attempt to rigidly dictate what an engineer should do or code, the reality is that their role has expanded: today, they actively participate in decision-making and solution definition.

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

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

Soft Skills 
    • Teamwork and collaboration
    • Adaptability and change management
    • Effective communication
    • Critical thinking and problem-solving
    • Proactivity and autonomy
    • Feedback and continuous learning
    • Customer and value orientation
    • Time management and prioritization
Hard Skills 

    • Programming and language proficiency
    • Administrative and documentation tools
    • Version control and repository work
    • Automation y DevOps
    • Testing and QA
    • Cloud Computing
    • Architecture design
    • Secure development
    • Databases and data modeling
    • UX and accessibility

A programmer’s work goes far beyond just writing code. In addition to programming, they engage in essential activities to ensure the team continuously delivers business value. This ranges from collaborating with stakeholders to the ongoing evolution of the team and the product.

If we were to imagine the weight of each of these areas in their daily work, coding would likely occupy only a portion. The rest is distributed among design, validation, communication, support, technical decisions, and product evolution.

Software Engineer Task Distribution (Percentages)

1. Programming and Development (30%-40%)

    • Writing and reviewing code.

    • Implementing features based on sprint requirements.

    • Code refactoring to maintain quality standards.

    • Automated testing (unit, integration).

2. Refinement and Discovery (15%-20%)

    • Participating in refinement sessions to understand and break down user stories.

    • Requirements analysis with the Product Owner and stakeholders.

    • Engaging in discovery to research technical solutions or alternatives.

    • Validating and clarifying technical doubts during the planning phase.

    Ingeniero de Software Coding

    3. Communication and Collaboration Meetings (15%-20%)

    • Daily stand-ups: Reviewing progress and coordinating with the team.

    • Planning and retrospectives: Defining sprint goals and improving processes.

    • Synchronization with other areas: Collaborating with UX designers, DevOps, QA, etc.

    • Communicating with stakeholders to align the technical vision with business expectations.

    4. Testing y Control de Calidad (10%-15%)

      • Desarrollo basado en pruebas (TDD/BDD) para asegurar un código robusto.
      • Code reviews para mantener estándares de calidad y compartir conocimiento.
      • Corrección de bugs detectados en ambientes de prueba o producción.
      “Su labor comienza desde las etapas más tempranas del ciclo de vida del producto: participa en el descubrimiento, colabora en el diseño, comprende las necesidades del negocio, conceptualiza soluciones viables y se hace responsable de su calidad y mantenimiento”

      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%)

        • Optimization of development processes.

        • Contributing to improved development practices within the team.

        • Monitoring and adjusting CI/CD tools to streamline workflows.
      Developer Creating

      Conclusion

      A Software Engineer should not be reduced to an operational role limited to writing lines of code. Their work starts from the earliest stages of the product lifecycle: they participate in discovery, contribute to design, understand business needs, conceptualize viable solutions, and take responsibility for their quality and maintenance.

      They must be invited to engage actively in business rules, hypothesis validation, and technical decisions that directly impact the product. In this sense, they should be treated as value creators and co-owners of the outcomes—not just the deliverables. With this recognition also comes the duty to take responsibility—positive or negative—for their involvement or absence.

      They should not be assessed solely on their ability to write code or based on raw productivity metrics. Their real impact is reflected in how they contribute to business understanding, team engagement, continuous product improvement, and shared ownership of quality.

      Treating them as co-responsible for success means broadening how we evaluate them. It’s not about controlling their output, but observing their growth as well-rounded professionals: How do they add value? How do they adapt? How do they improve? How do they collaborate?

      Therefore, evaluations should focus on quality of work, technical maturity, team collaboration, and the ongoing improvement of their processes—without neglecting the shared technical responsibilities of the team.

      Traditional or Agile Management?

      Traditional or Agile Management?

      by | May 14, 2025 | Concepts, Leadership, Management, Reflexions, Tools

      Traditional or Agile Management?

      Why does the type of problem matter?

      Did you know that over 70% of projects following a traditional approach fail in environments with high uncertainty or constant change?
      Studies like the Chaos Report have shown that failure often lies not in execution… but in choosing the wrong approach.

       

      What if the real issue isn’t the method you choose, but not understanding the kind of problem you’re facing?

      Before deciding whether a traditional or agile approach is best, it’s essential to understand the nature of the problem.
      To do this, we rely on two complementary frameworks:

      • The Stacey Matrix

      • The Cynefin Framework

      The Stacey Matrix is an analytical tool developed in the 1990s by Professor Ralph D. Stacey, a specialist in organizational management and complexity theory.
      It emerged in response to a common problem in business environments: the tendency to always apply the same management approach without considering the nature of the issue.

      This matrix has become especially relevant in contexts where innovation, digital transformation, or product development require adaptive responses rather than strictly procedural ones.

      Stacy Matrix
      Cynefin framework

      The Cynefin Framework was created in 1999 by Dave Snowden, a Welsh researcher in complexity theory and knowledge management.

      This framework is a decision-making tool based on the nature of the context or problem. It is widely used in business management, strategy, leadership, and the resolution of complex problems.

      Both frameworks help diagnose what you’re dealing with by evaluating two key dimensions:

      1. Certainty – How clear is the problem and its solution?

      2.Agreement – How much consensus exists among those involved?

      Stacey Matrix

      This matrix crosses certainty and agreement to classify the type of problem and suggest the most suitable approach:

      High Agreement Low Agreement
      High Certainty Simple Problem: known solutions, repeatable processes.
      Traditional approach      		 Complicated Problem: requires expert analysis.
      Detailed Planning

      Low Certainty

      		 Complex Problem: many variables, unclear relationships.
      Needs short cycles, trial and error.      		 Chaotic Problem: no time for analysis.
      Act, contain, then reflect.
      The Cynefin Framework

      It reinforces the idea that not all problems should be approached the same way:

      1. Simple (Clear)

      Approach: Standard procedures, best practices.

      2. Complicated

      Approach: Expert analysis, robust planning.

      3. Complex

      Approach: Experimentation, short cycles, continuous learning.

      4. Chaotic

      Approach: Immediate action, containment, stabilization.

      Conclusion

      It’s not about being a fan of agile or traditional methods.
      It’s about understanding the problem before applying the solution.

      When the environment is stable and predictable, a traditional approach may work.
      But in uncertain, changing environments with multiple actors and viewpoints, you need flexibility, adaptation, and short cycles.

      The approach shouldn’t be a dogma.
      It must be a conscious response to the context you’re facing.

      Comments