If you spend enough time working with IT system houses, integrators, vendors, and end customers, you start to notice something strange: the job titles on business cards often say surprisingly little about what a person actually does. Consultant, System Engineer, Specialist, Architect, Technical Account Manager, Presales Engineer, Implementation Engineer – sometimes it feels as if every integrator invents its own vocabulary. Even within the same company, two people with the exact same title can have completely different responsibilities. For outsiders, for HR, for recruiters, for customers – and often even for the employees themselves – the line between these roles becomes blurry.
The team behind Darkgate has been in close contact for years with some of the most renowned IT integrators across the entire DACH region and beyond. In almost every briefing, we hear new definitions of what a System Engineer is, what a Consultant is, and why these two roles are supposedly very different. Interestingly, these definitions regularly contradict each other. This is precisely why it makes sense to take an objective look at these positions, detached from internal titles and org charts. What is really behind these roles in practice? Where are the real boundaries? And why are these differences crucial for customers, projects, and the economic success of system houses?At the core, we are looking at two fundamentally different ways of thinking. The System Engineer thinks in technology. The Consultant thinks in solutions. The Engineer operates deep in the implementation. The Consultant operates between technology, the customer, and business processes. The Engineer asks, “How do I build this?” The Consultant asks, “What should be built in the first place, and why?” These perspectives are complementary, but they are not interchangeable.
A classic System Engineer is operational. This is the person who sets up the firewall, implements the SD-WAN structure, migrates an Azure tenant, plans the WLAN coverage, or integrates a backup solution. They work deeply with vendors such as Fortinet, Palo Alto, Cisco, Extreme Networks, Microsoft, VMware, or Veeam. They know the CLI, the GUI, the best practices, the firmware versions, and the typical failure scenarios. When something doesn’t work, they are the ones diving into logs, debug outputs, and configurations. Their focus is technical correctness and functionality. They measure success by whether the system runs reliably.The Consultant, on the other hand, operates earlier and alongside the project. They talk to the customer, analyze requirements, translate business processes into technical concepts, and create designs, architectures, and presentations. They explain to the customer why one solution makes sense and why another might not. They are usually less deep in a specific CLI, but very strong in understanding the bigger picture. They understand how networks, security, cloud, compliance, and operational models interact. Their focus is not primarily the configuration, but the right decision.
A simple example from real life: A customer says, “We need a new network.” The System Engineer immediately thinks about VLANs, routing, firewalls, switches, WLAN controllers. The Consultant first asks: How many sites? Which applications? What compliance requirements? What growth plans? What bandwidth? What security policies? Only from these answers does a technical design emerge, which the Engineer later implements.
In many system houses, this boundary blurs because experienced Engineers naturally grow into consulting tasks. And Consultants with a strong technical background are often pulled into implementation. This is where the confusion begins. Titles stay the same, but roles evolve. Suddenly you have “Consultants” who mostly implement, and “Engineers” who handle complete customer advisory.Another major difference lies in communication. The System Engineer communicates technically. The Consultant communicates understandably. The Engineer can explain to a colleague in three minutes why a BGP route fails. The Consultant can explain to a managing director in three minutes why the current IT landscape is a security risk. Both are extremely valuable, but they are very different skill sets.
For the customer, the Consultant is often the face of the system house. They sit in workshops, talk to IT managers, CIOs, and departments, create concepts, and moderate meetings. The Engineer often appears later, when things become concrete. In the project phase, the Engineer becomes the hero because they “make things work,” while the Consultant ensured in the background that the right things were built in the first place.
Presales is where these roles intersect. The Presales Consultant creates the design and argumentation. The Presales Engineer checks whether it is technically realistic. In some companies this role is called System Engineer, in others Consultant, and in others Specialist. This is where the title chaos truly begins.Economically, these roles are also different. An Engineer generates billable revenue through implementation days. A Consultant generates billable revenue through workshops, concepts, and architectures. For the system house, both are essential, but they generate value in different ways. The Consultant ensures projects exist. The Engineer ensures they succeed.
A common misconception is that the Consultant is automatically “more senior.” From a technical perspective, this is incorrect. An outstanding Engineer with deep expertise in Fortinet, OT security, or Azure networking is just as critical to a project as an excellent Consultant. These are different expertises, not different hierarchies.In daily practice, it often looks like this: The Consultant comes back from the customer and says, “They need segmentation because of KRITIS and want to move to the cloud long term.” The Engineer asks, “Which firewalls? Which switches? Which topology? What latency?” Both perspectives are necessary and interdependent.
Why is this distinction so important? Because many projects fail when either too little consulting or too little engineering is involved. Without consulting, technology gets implemented that does not fit the real need. Without engineering, the most beautiful concept remains a PowerPoint slide.For recruiters, HR departments, and customers, understanding this difference is crucial. If you are looking for a Consultant but hire an Engineer, you may get someone technically strong who struggles to moderate complex customer requirements. If you are looking for an Engineer but hire a Consultant, you may get impressive concepts but limited hands-on implementation capability.
The reality inside system houses shows that the best teams are those where these roles are clearly defined and respected. The Consultant thinks strategically. The Engineer thinks operationally. The Consultant talks a lot. The Engineer types a lot. The Consultant plans. The Engineer builds.
In the end, they are two sides of the same coin. And this is exactly why so many misunderstandings arise. Both are technically skilled, but they operate with completely different focus points. Once you understand this, you can immediately recognize who you are talking to in a conversation – regardless of the job title on their business card.This deep dive aims to create exactly that unified understanding. Not based on internal titles of individual integrators, but on the actual function these roles serve in projects, for customers, and in the economic structure of system houses. Only when we clearly see these differences can we staff projects correctly, build effective teams, and truly understand what customers need.
