# Holistic, Agnostic & Specific at solving problems — Icalia Labs Blog > Why being holistic, technology-agnostic and industry-specific makes software engineers and teams better at solving problems. Pre-AI era · 2020. Written before AI was part of how we build. The fundamentals still hold; tooling and workflow advice may be dated. Originally published on [Medium](https://medium.com/icalia-labs/holistic-agnostic-specific-at-solving-problems-2a6a58702d5f) on April 20, 2020. Lightly edited for clarity. 1. [Home](/) 2. / 3. [Blog](/blog/) 4. / 5. [Forward-Deployed Engineering (FDE)](/blog/topics/forward-deployed-engineer.html) [Forward-Deployed Engineering (FDE)](/blog/topics/forward-deployed-engineer.html) [Software Development](/blog/topics/software-development.html) # Holistic, Agnostic & Specific at solving problems Why being holistic, technology-agnostic and industry-specific makes software engineers and teams better at solving problems. ![Eduardo Lopez De Leon](/assets/eduardo-lopez.webp) Eduardo Lopez De Leon · Co-Founder & CEO April 20, 2020 · 5 min read ![Team at a window covered in sticky notes, labeled customer, operations and industry experts, UX designer, software engineer](/assets/blog/holistic-agnostic-specific-problem-solving-cover.webp) _How these characteristics fit into the modern role of software engineering and elite software teams_ Solving a problem can be done using different tools, knowledge, and a set of practices. The complexity of that problem determines how you will start to figure out how to solve it. The way to do it is by understanding the problem from the beginning, thinking about the potential benefits and impacts of solving it, and translating that into a solution. The same happens with software development — you need to cover a wide range of steps in the problem-solving process, and you need to jump into different layers of abstraction, implementing the most suitable and feasible tools to accomplish the objective of that particular problem. Many problems a developer wants to solve can be solved with particular programming languages, existing tools, and APIs. The person in charge of solving them can decide which programming language is most suitable, with the right set of practices for that particular challenge. To solve problems, it is not enough to say that you know a particular tool or a single practice. Being Holistic, Agnostic & Specific at this moment in the software discipline stands out and is highly valued. ## Holistic in the entire process Holistic means covering the different steps of the problem-solving process: from the business problem or opportunity, to translating it into architectural pieces, identifying where and when to optimize, and executing and deploying the solution. It comes from understanding why the problem I want to solve is really a problem, for whom, and why it is worth tackling. From the beginning, it helps to empathize with and clearly understand the dynamics around that problem, and to start thinking of great technical ways to approach it. Even when building the tech solution, that early involvement will keep resonating and should be part of the thinking process, as a reminder of what is crucial to solving that problem. ![Hand-drawn sketch of five boxes, context, problem, design, tech and check, with a double arrow spanning problem to tech](/assets/blog/holistic-agnostic-specific-problem-solving-2.webp) _A holistic approach to a generalized problem-solving process_ ## Agnostic in technology implementation The technology can be executed with different paradigms and languages, depending on the problem to be solved. Again, it is not enough to say you will solve all potential problems with a single language all the time. Every programmer knows there are programming languages with a specific purpose, and there are also general-purpose languages. But when it comes to choosing the right language, you will decide which one is best based on the attributes needed to solve the problem: flexibility, manageability, maintainability, writability, resilience, [and so on](https://en.wikipedia.org/wiki/List_of_system_quality_attributes). What does the tech solution need in the short and long term to make sense from a product, business and market perspective? Those decisions will impact the potential technical debt to be handled and managed in the product as it grows. It is not an easy task to be a polyglot, touching every new technology that appears in this fast-moving industry. However, there are ways to shortcut the path: talking to colleagues, reading, exploring, testing. This says a lot about a curious engineer, as curiosity is part of the core value of the problem-solving process: curiosity to know how to solve this particular problem. ![The same sketch with the span labeled holistic and a red column of technology options under the tech box labeled agnostic](/assets/blog/holistic-agnostic-specific-problem-solving-3.webp) _Expansion of tech choices, as part of the agnostic mindset_ ## Specific to the served industry This means using the same language and context as the business counterpart and understanding the dynamics of the industry where the software is going to be implemented. Being empathetic while deploying technological solutions becomes a differentiator, since the perspectives and needs of users, customers and the market itself are considered as part of the problem-solving process. Also, understanding the business or organization implementing the solution leads the software engineer to introduce elements that fit the right business objectives. The environment of trust that can be created is powerful. An engineer capable of jumping into different vocabularies and contexts may be proactive enough to generate other paths and alternatives to the problem at hand. Being able to align with that industry context will help not only to solve the problem in the present but also to think about how to adequately grow that solution. ![Sketch framing the holistic and agnostic process in a blue box, with an arrow to three industry variants labeled specific](/assets/blog/holistic-agnostic-specific-problem-solving-4.webp) _Being specific according to the industry and stakeholders’ positions_ ## A merge of the above The combination of these characteristics will be a definitive mix for any software developer and any software team using technology to solve problems. Teams unable to implement a solution without constraints in terms of the holistic process, understanding the industry where the solution is supposed to be used, and choosing from all the available tools will be limited and might not reach the best potential long-term solution from all angles. Being **holistic** is tough, especially for a software developer. Being one myself, I typically wanted to be coding all the time, in front of the terminal, seeing how through that canvas I would create a solution to the problem. This is not enough to solve the entire problem. You need to grasp every aspect of the problem and be able to see it implemented to polish the solution and enhance the outcome. Being **agnostic** is demanding, especially in an industry that changes every single month or even every week: new practices, programming languages, frameworks, and tools. As an engineer, you need to be curious and passionate enough to forget (for a while) all your current knowledge and be open to reading about a new trend or a group of avid cool kids working on a fun new project — and maybe you might think of joining them too, betting it will be the next [most used (loved) programming language in the world](https://jaxenter.com/stack-overflow-dev-survey-2019-157815.html). Being **specific** requires empathy and a high level of learnability to understand the factors involved in the industry where the solution being built is supposed to be used. Nonetheless, acquiring these capabilities both individually and collectively is powerful. There should be a homogeneous conversation, where most of the people involved can understand the others' perspectives and have a strong opinion about the design of the solution. There might be some concentration of accountabilities, but the more common language the team can share, the better. Users and customers will benefit the most from this combination — and it is not far-fetched to think the economy itself will too, when you realize that [we still fail as a discipline in building the right things, right](https://www.zdnet.com/article/study-68-percent-of-it-projects-fail/). Avoiding silos and misunderstandings, as these teams will, is crucial for productive and meaningful work; therefore, all parties will see the progress and benefit. Building software has never been easy. These are the kinds of challenges the discipline demands today. Problems today are harder to solve, so the approach to them should have a versatile intention and purpose behind it. ![Eduardo Lopez De Leon](/assets/eduardo-lopez.webp) Written by Eduardo Lopez De Leon · Co-Founder & CEO Strategy, brand presence, and partnership development at Icalia Labs. Startup and corporate experience. YC Founder. [LinkedIn](https://www.linkedin.com/in/elopezdeleon/) [X](https://x.com/edolopez) [GitHub](https://github.com/edolopez) ## Related reading [ ![](/assets/blog/monterrey-office-overhead.jpg) September 22, 2026 ### How to Hire Software Engineers in Mexico: A US Guide A practical guide for US companies hiring software engineers in Mexico: hiring models, legal setup, vetting, onboarding, and the mistakes to avoid. Nearshore Hiring ](/blog/how-to-hire-software-engineers-in-mexico.html)[ ![](/assets/blog/blur-1853305.webp) September 15, 2026 ### AI-Augmented Engineering Teams: What Buyers Pay For Every engineering partner says it uses AI. Three metrics, five questions and the review standard that separate delivery outcomes from AI hype. AI Engineering ](/blog/ai-augmented-engineering-teams.html) [![](/assets/blog/distributed-software-teams-in-management-consulting-cover.webp) Pre-AI era February 26, 2021 ### Adapting a distributed software team capability in Management Consulting Argues that management consulting firms need a software development practice and explains how distributed teams help them win deals and scale. Nearshore Hiring](/blog/distributed-software-teams-in-management-consulting.html) ## Need engineers who already ship like this? We embed senior nearshore engineers directly into your team — same time zone, same standards, no ramp-up theater. [Book a discovery call →](/contact.html#book) [Embed an engineer in your team](/contact.html#book)