The part of consulting that cannot be reduced to code

Technical competence is necessary for IT consulting, but it is not the entire job. A consultant is often placed between technology, business requirements, organizational leadership, customers, and the people who actually use the system.

That creates a different class of problems. The client may be frustrated. The requirements may be incomplete. Two departments may want different things. Management may want speed while security wants control. A user may technically be able to use a system but strongly dislike the workflow.

None of these situations can be solved by simply writing more code.

ACM's "whole person" view of computing

The ACM CS2023 curriculum makes a particularly strong argument here. It says that a computer science graduate must be committed to the "whole solution", not only its technical aspects. It specifically identifies social, ethical, legal, and professional responsibilities as part of computing education. [1]

ACM also states that these professional capabilities are transferable between projects, jobs, and often even industries, particularly as a person's career progresses into project leadership and management. [1]

That is a major reason I want to deliberately develop these skills. Technical knowledge can help me build the system. Human and professional capabilities determine how effectively I can work with everyone surrounding that system.

Communication creates technical value

ACM's software engineering guidance calls effective oral and written communication critical to software engineering professionals. It expects engineers to communicate in both technical and non-technical settings. [2]

This becomes particularly important in consulting because communication is often how technical work becomes understandable to the customer.

A consultant might have to explain why a system cannot safely be delivered in two weeks, why a requested feature creates security risk, why a legacy integration needs additional work, or why a seemingly expensive architectural change will reduce long-term operational risk.

The engineer is therefore not merely transferring information; the engineer is helping people make decisions.

The "sales rep" side of consulting

I increasingly think of the consultant as having a partial "sales representative" responsibility.

That does not mean manipulating clients or exaggerating capabilities. It means being capable of presenting technical work as a solution to a real problem.

PMI's requirements guidance provides a strong basis for this interpretation. Michele Maritato describes enterprise analysis in terms of understanding the business need, defining an appropriate solution approach, considering constraints such as risk and cost, and connecting the solution to expected benefits. [3]

In other words, a consultant should not stop at: "Here is what we built."

The stronger explanation is: "Here is the problem we understood, here is what we changed, here is why this approach was chosen, here are the trade-offs, and here is the result the organization should expect."

That is a technical skill expressed through business communication.

Trust is part of the system

IBM Research argues that trust in AI depends partly on whether people can understand how the technology works and evaluate whether its decisions are fair, reliable, accountable, and safe. [4]

IBM's current AI transparency guidance makes a similar point: in higher-stakes applications, stakeholders need visibility into the model, its logic, evaluation, and the data used to train or tune it. [5]

This creates a consulting responsibility that goes beyond technical accuracy. People have to trust the system enough to use it, trust the organization operating it, and trust the people responsible for explaining it.

That trust cannot always be created by a better algorithm. Sometimes it is created by a human being who can listen to a concern, explain a limitation, acknowledge uncertainty, and take responsibility for the decision.

Emotion is not noise

Human emotion is often treated as something separate from serious engineering. In real organizations, it is part of the environment in which technology operates.

SAP's discussion of AI and customer experience explicitly describes the value of combining AI with human expertise. SAP highlights human specialists for complex exceptions, relationship-building, and empathy, while AI handles more routine interactions. [6]

SAP also discusses emotional sensitivity as one dimension organizations can use when deciding how work should be divided between humans and AI. According to SAP's framework, people are generally preferred for tasks that are emotionally laden or require building trust, while AI is better positioned for some repetitive and high-volume work. [7]

This does not mean humans are automatically better at every task involving emotion. It means emotional context can be an engineering and business consideration when deciding which parts of a process should be automated.

Human judgment is not the same as raw calculation

A technical model can optimize a measurable objective. A real organization may have several objectives that conflict.

Imagine a business choosing between two implementations. One is cheaper. Another is safer. A third protects employee relationships better but takes longer. A fourth has better long-term maintainability but requires a larger initial investment.

There may be no universal mathematical answer because the organization has to decide which consequences matter most and which trade-offs it is willing to accept.

ACM's Code of Ethics explicitly states that ethical decision-making is not an algorithm and that multiple principles may need to be considered simultaneously. It places the public good as a primary consideration. [8]

This is an important distinction for me. Human judgment is not valuable simply because it is "human." It is valuable when it contributes context, accountability, ethical reasoning, stakeholder understanding, and responsibility to decisions.

AI makes this human layer more important

IBM's Responsible Technology Board describes AI as something that should augment human intelligence rather than operate independently of or replace human responsibility. IBM recommends balancing human oversight, agency, and accountability throughout the AI lifecycle. [9]

IBM's current human-in-the-loop guidance adds that human oversight is particularly valuable for ambiguity, bias, edge cases, and technical, ethical, legal, and operational risks. [10]

SAP makes a related point from the enterprise side. In its discussion of modernizing SAP environments, SAP states that while AI can analyze information and recommend actions quickly, people remain accountable for strategic decisions, especially when outcomes can affect quality, customer commitments, regulatory requirements, or employee safety. [11]

This gives me a more precise view of the AI question. The goal is not to compete with AI at every task AI can perform. The goal is to become the person who can effectively direct, validate, explain, govern, and apply AI within a real organization.

The human becomes the bridge

This is where I see the combination of software engineering + consulting + business understanding + communication becoming valuable.

The engineer becomes the bridge between systems and people:

Business needs → requirements → technology → implementation → human adoption → measurable business result.

AI can increasingly assist with parts of that chain. It can generate code, summarize documents, analyze information, suggest designs, and automate repetitive work.

But the organization still has to determine what problem matters, what constraints are acceptable, which stakeholders must be protected, who is accountable, how the change should be communicated, and whether people will actually trust and adopt the result.

Why I want this skill set

My goal is therefore not to become "the developer who knows everything." That is unrealistic.

I want to become an engineer who can understand technology deeply enough to build it, understand business well enough to justify it, communicate clearly enough to sell the solution, and understand people well enough to deploy it responsibly.

That includes learning technical architecture, but also studying business processes, project management, communication, law, regulation, policy, professional ethics, negotiation, and human behavior.

Those areas may not look like traditional programming skills, but they directly affect whether technical work succeeds in the real world.

What I learned

ACM's curriculum, IBM's AI guidance, and SAP's enterprise discussions all point toward the same broader direction from different perspectives: technology operates inside human organizations, not outside them. [1] [9] [6]

As AI becomes better at technical and analytical work, I do not think the answer is to ignore AI or try to compete with it at everything. The better strategy is to become stronger at the human and organizational layer around technology: judgment, communication, trust, business reasoning, ethics, stakeholder management, and responsible decision-making.

That is the professional direction I want to build: not just a software developer, but a software engineer who can operate at the intersection of technology, business, and people.

References

1. ACM Computer Science Curricula. "CS2023: Society, Ethics, and the Profession."
   https://csed.acm.org/wp-content/uploads/2025/11/CS2023-Report.htm
2. Association for Computing Machinery (ACM) CCECC. "Software Engineering."
   https://ccecc.acm.org/guidance/software-engineering
3. Project Management Institute (PMI). Michele Maritato, "Mastering the project requirements."
   https://www.pmi.org/learning/library/mastering-project-requirements-assessing-good-5942
4. IBM Research. "Trustworthy AI."
   https://research.ibm.com/topics/trustworthy-ai
5. IBM. "What Is AI Transparency?"
   https://www.ibm.com/think/topics/ai-transparency
6. SAP. "The service revolution: How AI and human expertise are redefining customer experience."
   https://www.sap.com/blogs/ai-and-human-experience-redefining-customer-experience
7. SAP. "Six Dimensions for Smarter Work Redesign in the Age of AI."
   https://www.sap.com/blogs/six-dimensions-for-smarter-work-redesign-in-the-age-of-ai
8. Association for Computing Machinery (ACM). "ACM Code of Ethics and Professional Conduct."
   https://acm.org/binaries/content/assets/about/acm-code-of-ethics-and-professional-conduct.pdf
9. IBM Responsible Technology Board. "Best practices for augmenting human intelligence with AI."
   https://www.ibm.com/think/insights/ai-best-practices
10. IBM. "What Is Human In The Loop (HITL)?"
    https://www.ibm.com/think/topics/human-in-the-loop
11. SAP. "Modernizing SAP ECC for an AI-driven, Agentic Future."
    https://www.sap.com/blogs/modernizing-sap-ecc-for-erp-in-production