More than code: Measuring sales and customer contact in training

Author

Category

Estimated reading time

Programming is only half the battle

A persistent misconception about IT professions: Anyone who becomes an IT specialist types code all day long. Headphones on, world off, line by line.

The reality? Programming accounts for perhaps half of the work – often less. The rest is communication, coordination, listening. Understanding what the customer really needs. Explaining why something is taking longer than expected.

These skills are not part of any curriculum and do not appear in any examinations. Nevertheless, they determine who is successful in this profession.

At erminas, we take this part of the training just as seriously as the technical part.

Communication: Talking to people, not just machines

The first shock for many trainees: how much talking there is. Meetings, votes, short questions, long discussions about solutions.

This is because of how modern software development works. Hardly anyone builds a product alone from start to finish anymore. Teams work together – and teams have to communicate. If you build an interface, you have to talk to the people who use it. Anyone developing a feature has to understand what the customer actually wants – rarely what they say first.

With us, you learn this right from the start. You sit in meetings, first as a listener, then with your own contributions. You talk to colleagues from other departments who bring a completely different perspective to the table. You learn to ask questions that really help instead of just saying something.

At some point you realize: Communication is just as trainable as programming. Listening is an active skill, not a passive one.

Customer contact: Sooner than you think

In some companies, trainees are kept away from customers. Too risky, too inexperienced. We do things differently.

On the first day, you don’t go into the customer meeting alone. But you are there. You observe how experienced colleagues record requirements, ask questions and deal with misunderstandings. You learn the unspoken rules: When do you interrupt? How do you formulate concerns without offending the customer? What do you do if the customer wants something that doesn’t make technical sense?

Over time, you will be given your own tasks. You may be asked to explain a technical detail or summarize what was discussed after a meeting. Small steps, but real responsibility.

If you don’t learn customer contact until after your apprenticeship, you will have a backlog that is difficult to catch up on.

Requirements analysis: The art behind the technology

One of the most common mistakes in software development: you build exactly what the customer has said – and he is still dissatisfied.

Why? Customers often don’t know exactly what they want. They describe a problem, but their idea for a solution is not the best. They forget important things because they take them for granted. Or they change their mind as soon as they see the first result.

With us, you learn to scrutinize requirements instead of simply implementing them. Why do you need this? What happens in this scenario? Who works with it? Questions that are often worth more than any technical solution. You will also learn how to document requirements – not as a bureaucratic obligation, but as a tool against misunderstandings.

Requirements analysis is detective work. You find out what is really needed, often against the resistance of unclear statements and contradictory wishes. If you do it right, you will save yourself and everyone else a lot of trouble.

Self-organization: Nobody tells you what to do

At school, you are given tasks and complete them. At erminas, things work differently over time.

At the beginning, tasks are clearly defined. Later, they become more open: “We need a solution for problem Y – think of something.” And at some point: “Here’s the project, here are the goals – manage your time.”

This is a culture shock for some people. Suddenly you have to decide for yourself where to start. You have to estimate how long something will take, prioritize when there are several things to do, recognize when you need help.

You have contacts, get feedback and can ask questions at any time. But you learn to organize yourself – because that’s a skill you’ll need your whole professional life. Nobody will tell you what to do next when you’re 30.

Giving and receiving feedback: Harder than it sounds

The weekly Azubi Weekly is not just about project status and vocational school. It’s about how things are really going. What is working well? Where is there a problem?

Getting feedback is unpleasant at first. Someone tells you that your code is difficult to read, that you don’t say enough in meetings, that you underestimate tasks. That feels like failure at first.

The perspective changes over time. Feedback is information, not an attack. Someone shares an observation so that you can improve – not to beat you up. It takes time to internalize this, but it changes everything.

It is even more difficult to give feedback yourself. Telling a colleague that their explanation was confusing. Telling an experienced developer that her code is unclear in one place. This requires courage and tact – qualities that can only be developed through practice.

For us, feedback is part of everyday life. Not once a year in a formal meeting, but regularly and directly. This is sometimes uncomfortable, but it ensures that problems don’t escalate.

Present: Your knowledge is only worth as much as you can convey it

You can build the best feature in the world – if you can’t explain what it does, nobody will understand it.

Presenting is therefore part of the training. You learn to explain technical issues in such a way that even non-technicians can understand them. You learn to give demos that show what a system can do without getting bogged down in details. You learn to present your work in meetings without being boring.

It starts small – explain what you are working on in the Trainee Weekly. Over time, it becomes more challenging: an internal presentation about a technology, a presentation to a customer, a workshop in which you teach others something.

You learn something every time. That brevity is better than completeness. That the first thirty seconds decide whether people listen. That questions from the audience are not a threat, but an opportunity.

These skills are underestimated. They often make the difference between working well and being known for working well.

Taking real responsibility

“Taking responsibility” sounds like a job advertisement phrase. For us, it means something concrete.

If you take on a task, you are responsible. Not someone else who pays attention. You get in touch if something doesn’t work out. You ask if something is unclear. You deliver what you have promised – or let us know in good time if this is not possible.

Many people have never learned to take real responsibility. They are used to someone cleaning up after them, that there is always a higher authority.

With us, you get this responsibility early on. Graduated, of course, with a safety net, but real. You realize that your work has consequences, that commitments count. This forms an attitude that lasts far beyond your training.

Vocational school: theory meets practice

You spend one or two days a week at vocational school. It has a mixed reputation – some things are outdated, others are fundamentally important.

In the Trainee Weekly, we regularly discuss what is going on at school. If anything is unclear, older trainees or trainers help. We classify outdated material – sometimes it is still relevant for the exam.

The real advantage of theory is that it helps you to understand new things more quickly. Why do networks work like this? What happens in the computer when you start a program? If you know the principles, it is easier to familiarize yourself with the unknown.

What this means for your career

Communication, customer contact, self-organization, feedback, presenting, responsibility – these skills are not optional. They are often what makes the difference.

An honest truth: A good developer who can’t explain what he does remains invisible. An average developer who is good with people will be promoted. This may seem unfair, but it reflects reality.

The good news is that all of this can be learned. These skills do not fall from the sky and are not innate. You need the opportunity to practise – and someone to show you how to do it better.

This is exactly what we offer. Not as an additional program, but as an integral part of the training.

 

If that sounds like an apprenticeship that suits you, apply here.

More articles

Published on