There are people who explain their field as if it were a purely technical subject. When Patricia Maier talks about her role as a software architect*, you can sense the interplay of responsibility, clarity and relationship. Perhaps this is also due to the fact that she knows another field in which orientation in complexity is important.
Patricia's entry into IT sounds very familiar to many. Starting with her early enthusiasm for computer games and, above all, the moment when games suddenly turned into questions: Why is exactly what is happening on the screen? At school, computer science became an elective subject, taught by a teacher who taught the subject in an infectious way. And at some point it was no longer just ideas, but the first real points of contact with code. With Pascal and Delphi, Patricia entered the world of IT, which has stayed with her ever since.
After her first experiences, it was clear to Patricia that she wanted to really get into IT. She completed her bachelor's degree at Esslingen University of Applied Sciences, where she deliberately chose a broad focus in software engineering. Electrical engineering, physics, network technology, software programming. Lots of practice, lots of trial and error and, above all, an understanding of how the individual gears mesh. She later built on this and completed a Master's degree at the Technical University of Munich, with a clear focus on software engineering and software testing.
And then came a moment that many people know after graduating: You have an idea of the environment you want to work in, but not yet a clear picture of the one company. Patricia came across QAware after completing her Master's degree. She quickly realized: the requirements are high and quality is not an afterthought here. This is exactly what she was looking for and she quickly realized that this understanding of quality is not just claimed, but is actually practiced in everyday life. This convinced Patricia and she has been an integral part of the QAware team for 8 years now.
When Patricia talks about her role, she dispels an image that is unfortunately still often bandied about in the industry: the nerdy programmer or software architect who makes decisions alone. She says it clearly:
"A software architect* is not the nerd in the basement. On the contrary, this role is at the heart of the action because it constantly mediates between people, requirements and technical possibilities."
This is exactly where quality is created. Her description of architecture is strikingly unagitated and therefore convincing:
She looks first at the customer problem. Then to technologies. Then she looks at the question of which architecture is suitable in the long term so that the system remains future-proof, even if requirements change or new technological directions are set. And while she maintains this technical view, she emphasizes the human factor as equally important.
This is not romanticism. It is practice. Because in the projects Patricia works on, software is not a package that you deliver and then tick off. They are processes that keep companies running, workflows that people use every day, systems that make value creation possible in the first place. If something isn't right, it's not just a bug in the log, but something that becomes noticeable. For teams, for customers, for end users*.
A long-term project at an international automotive group left its mark on Patricia. She describes how she developed over the years from a young professional to a software architect*. The project was ideal because it combined many facets and technologies. She mentions cloud, Java, microservices and Docker. In other words, things from her studies that have real applications in practice.
Then comes a sentence that sticks: If you build something wrong here, the car will drive on three tires. Of course, this is meant symbolically. But it describes precisely what it's about: it's not about three lines of code. It has an impact on the economy and the world.
And it is precisely in this context that it becomes clear why she also describes her role as a quality gate. As a responsibility in the system: she ensures that rules and intentions are right so that what the customer needs is created. She has the team's back when the customer is still getting their bearings. She leads, coaches, develops people, discusses reviews, goes into depth when a challenge is stuck. At the same time, she also asks how the team is doing. Because stable results don't just come from technology, but from a team that is doing well and can work well.
In another project at an insurance and asset management company, the initial situation was typical of sophisticated digitalization: there are many ideas, but not one clear definition. There are stakeholders, processes, documents, special cases. And there is a desire to get started quickly.
The first step was to hold many discussions to find out what the real requirements were. She describes the way there as a process in which the scope was sharpened during the ongoing project. With demos, feedback and decisions that ensured that an excellent software solution was created for the customer in the end.
The solution appears simple at first glance, but this is precisely what good architecture shows: an application that maps templates for contracts in such a way that content automatically appears or does not appear depending on the conditions. This keeps contracts consistent. Certain passages are fixed and cannot be changed by mistake. And instead of maintaining several Word documents plus attachments, the work is done in a clear process in one application.
The effect is visible and tangible: time savings in everyday life, fewer manual steps and more certainty that documents are correct and consistent. Patricia also explains how the team empowered two developers at the customer so that they could subsequently expand the software themselves. This shows that projects don't end with a delivery, but with connectivity.
When customers today say: We want software that works, that's exactly what they mean. A system that relieves people in their everyday lives and makes organizations more stable.
When Patricia talks about QAware, it's about two things that are mutually dependent: Humanity and quality awareness.
She mentions the sense of togetherness, humanity and psychological safety as important components. Quality is not only anchored in the code, but in many aspects: Communication, togetherness, corporate governance, and many more. Added to this is the opportunity to develop further, even beyond projects.
Flexibility is particularly important to her personally. It gives Patricia the opportunity to combine her job, her two dogs and rescue dog work. She works a lot from her home office or from her camper. And she recounts a scene from the job interview that shows how decisions at QAware sometimes start: She was nervous about broaching the subject of dogs in the office. QAware had no experience, but Bernd Schlüter, long-time Managing Director of QAware and now a shareholder, quickly eased her worries: "We'll just give it a try. And what was then a trial and error became a permanent integration. Eight years later, dogs have become an integral part of the QAware environment. For Patricia, this is a sign: People matter.
Why is this relevant for customers and (future) employees?
Because the quality of a software product rarely depends on a tool, but on the system in which people work together. A project's success can be recognized even before the first lines of code are written: by whether a team addresses problems early on. By whether quality is treated as an option or as a basis. And by whether professionalism and technology are really working together or at cross purposes.
This is exactly where Patricia's description of QAware becomes tangible. This collaboration at eye level, with a "we" that doesn't fizzle out after two sprints, but lasts for years. This ensures that a vague idea becomes a clear solution step by step. That decisions are made in a comprehensible way. That you don't slip into hectic rework because you didn't dare to ask uncomfortable questions at the beginning. And that people are allowed to develop because their strengths are recognized, not because they have to fit into a rigid role model.
What many people don't know about Patricia is that she is active in a rescue dog team that searches for people and trains one of her dogs. Her dog Finija learns to follow a specific human scent trail, even if there are other people and distractions around her. For example, this could be a person who needs assistance and has lost their way in the area. The person's trail is picked up with an item of clothing.
You could dismiss this as a private passion. Or you could see something in it that also explains her work as a software architect*: the calmness needed to pick up the right trail in a confusing environment. And the consistency to test this track with the team until it works.
Patricia talks openly about why women often feel a hurdle when entering IT. IT seems like a male domain, which creates respect as to whether you fit in, whether you have a place, whether you can do everything that is needed.
And then she puts a decisive thought against this:
"It doesn't matter what your gender is, whether IT is your thing. What matters is what you're passionate about, whether you're curious, whether you want to see yourself in it. Then you should go for it because you will find your place. And you don't have to know everything beforehand. Daring is the first important step."
Patricia's portrait shows on a small scale how QAware thinks on a large scale.
We want to lead technologically and be the most human software forge. Recognizable by satisfaction, reputation, increased productivity and a strong quality contract.
And this is exactly where the core lies: excellent software is not created from slogans. It comes from people who take responsibility, who are committed to quality, who like to think together and who are willing to pass on their experience.
If you're not satisfied with just the appearance of software, then it's worth taking a look at the people behind it. If you are a woman thinking about entering the IT world or staying in it, Patricia is a good counterexample to any doubts: curiosity is a start. Development is a path. And both can feel good.
If you want to talk to us about what a project with a high level of responsibility and genuine collaboration can look like, QAware has the right people to talk to.
*Gender, origin etc. are not evaluation criteria for us. The main thing is that you are just as enthusiastic about technology as we are.
