Cloud-first, people-first: What “Walter Huber, CTO von KaWa commerce” reveals about team culture, AWS sandboxes, and engineering growth

Key takeaways from the session “Walter Huber, CTO von KaWa commerce”

In the session “Walter Huber, CTO von KaWa commerce” with speaker Walter Huber from KaWa commerce GmbH, we saw a compact organization run on flat hierarchies, practical agility, and a distinctly cloud-minded engineering approach. From DevJobs.at’s editorial vantage point, the message is clear: this is a place where developers get real ownership, room to experiment, and a well-defined path to grow—from tackling simpler tasks to assuming customer-facing architecture responsibilities.

Two technical pillars structure the company’s work: Magento for e-commerce and Amazon Web Services for cloud solutions. KaWa commerce combines these pragmatically—from hosting to extending monolithic shops with microservices in AWS. The underlying theme in Huber’s remarks is a deep sense of how engineering and business intersect: project-driven, customer-focused, and still leaving space for internal initiatives and training.

This agility is lived, not postured. Small teams, cross-functional by design, learn from one another through regular sharing. And solution architects in AWS also write code—from Lambda functions to CloudFormation templates—bridging architecture and implementation.

Small company, flat structure—clear accountability

KaWa commerce purposely operates with a “flat” structure. That translates to proximity, transparency, and short decision paths. Day-to-day, it looks like this:

• “Classic” developers write code, test, and deploy—owning quality and runtime outcomes.
• Solution architects in the AWS space also code, for example to produce Infrastructure as Code (CloudFormation) or serverless components (Lambda).
• Role boundaries blur where it makes sense. The goal is to anchor responsibility where the expertise lives—and keep expanding that expertise.

Flatness is not an end in itself; it’s a lever for ownership. If you build a feature, you think through deployment. If you design architecture, you guide its implementation. The lines between development and operations intentionally fade in the right places—bringing DevOps responsibilities as a natural extension of the work.

Project business, small learning teams

KaWa commerce runs a “very project-driven” business. Typical delivery happens in small groups of two to three people. This brings tangible advantages:

• Focus and speed: Less coordination overhead; tighter feedback loops.
• Visibility: Contributions are clear. Everyone sees the impact—internally and with customers.
• Learning curve: Moving across projects broadens skill sets and exposes engineers to varied customer contexts.

Crucially, when there’s a lull, internal work steps forward. The team builds internal tools for training and self-development—and runs them on AWS. Slack time becomes learning time, not drift.

From junior to senior: turning learning into a system

Career progression at KaWa commerce is practical and explicit. Juniors start with “simpler tasks,” largely “in the background.” As their experience grows, so does customer exposure and architectural responsibility. This isn’t a rigid ladder; it’s an expanding circle of influence and accountability.

• Early stage: Get familiar with context and tooling; contribute confidently to well-scoped tasks.
• Build-up: Assume responsibility for discrete topics and take initial steps into customer-facing work.
• Seniority: Engage directly with customers; make architecture calls and guide implementation.

All of this sits within a structured learning environment: internal trainings, certifications, and—in Huber’s words—strong support that comes with being an AWS Partner. The company receives training resources from AWS and can tap AWS Solution Architects “to learn things.” For engineers, that means learning is entrenched in everyday practice, not left to chance.

Hiring reality: team fit over years of experience

How do you hire for such an environment? Huber is candid: keeping a robust candidate pipeline is important and difficult because “good people are scarce.” What matters most is fit and the ability (and will) to learn—more than a long list of past roles.

• Solid fundamentals—yes.
• Extensive specialization—secondary.
• Curiosity, learning drive, team fit—central.

The culture supports this stance. Huber describes a young team that “welcomes” new colleagues, making onboarding “relatively good and simple.” Even for more reserved “coders,” the environment encourages people to surface at their own pace. If someone fits the team and covers the basics, they’re “onboarded relatively quickly and easily”—and are likely to feel at home fast.

Remote work, two locations, and intentional onboarding

KaWa commerce operates in Vienna and Carinthia. Home office and telework are “very strong,” yet thoughtfully managed. It works especially well for people who self-organize and can acquire knowledge independently—Huber stresses from experience that juniors, in particular, need to be deliberate about this self-directed learning.

At the same time, in-person connection remains part of the culture. People travel between the two locations to meet, build relationships, and strengthen team cohesion. Remote is not an autopilot setting; it’s one component of a consciously maintained collaboration model.

Technology DNA: Magento + AWS

Huber frames the company’s technology focus in two large topics:

1. Magento for e-commerce—building and operating online shops for customers.
2. Amazon Web Services—applying cloud technologies for customer needs.

The two are often combined—especially for hosting, “particularly for larger customers.” Beyond that, the team handles classic AWS migrations and develops cloud-native microservices. The e-commerce context makes the cloud choice especially apt: “traffic spikes” are common; scalability is mandatory.

Extend the monolith, don’t bloat it: microservices on AWS

A core pattern stands out: for a running Magento shop, when a new feature is needed, the team asks whether to implement it as a decoupled microservice in AWS—rather than expanding the monolith. It’s a modern, pragmatic approach with clear benefits:

• Decoupling: New functionality ships independently; deployments and scaling are isolated.
• Stability: The core stays lean. Changes carry less risk when implemented outside the monolith.
• Scalability: Resources can be tuned per feature—matching the realities of e-commerce load profiles.

For engineers, this requires a “cloud mindset”: modeling state, events, and service boundaries; choosing AWS building blocks wisely. Huber explicitly mentions Lambda functions and CloudFormation—tools that keep infrastructure reproducible and runtime efficient.

Freedom with responsibility: language choice, DevOps, ownership

KaWa commerce pairs autonomy with accountability. Engineers building microservices can choose their language—Node.js, Python, or PHP when Magento alignment is useful. But the freedom comes with responsibility: DevOps is part of the role.

In practice, that means bringing up the AWS environment, automating infrastructure, and considering operability from day one. For many engineers, this blend is compelling: fewer handoffs, more end-to-end impact, and faster learning cycles.

Sandbox accounts: experiment, automate, reuse

One of the strongest cultural markers in Huber’s insights is the sandbox model. KaWa commerce configures AWS Organizations so that “everyone … gets a sandbox account.” Ideas move quickly from spark to tested artifact:

1. Try things: combine services; validate hypotheses.
2. Capture infrastructure: create a CloudFormation template for reproducibility.
3. Implement functionality: add code via Lambda functions or other AWS components.
4. Test and harden: validate behavior and non-functionals.
5. Roll out: deploy to the customer account—and reuse across customers where it fits.

Practically, this means ideas don’t stall at approval gates. They progress through a realistic path of prototyping, automation, and production-aligned validation. Learning happens where it matters—on the system, with real service interactions, in the cloud.

Good tools are not a luxury: hardware and IDEs

Huber frames it as a credo: with the right tools, you can work well. KaWa commerce doesn’t skimp on laptops, displays, keyboards, or on the licenses developers rely on.

• Capable laptops and monitors—to split windows sensibly and keep workflows fluid.
• JetBrains tooling such as PhpStorm and PyCharm—“used very strongly.”
• Efficiency over frustration: no “heavy breathing because the laptop doesn’t have enough room.”

It’s more than a perk; it’s a signal. The company invests in people—and in their tools. Together, those investments drive productivity and satisfaction. For engineering teams, it reads as everyday respect.

Collaboration that makes knowledge visible

At KaWa commerce, knowledge isn’t a private stash; it’s a team asset. Work is structured in small teams, and peer learning is encouraged through presentations—people show what they’ve built, why decisions were made, and how solutions operate. This lowers the barrier to knowledge transfer, raises the collective bar, and makes progress visible.

That practice directly supports onboarding: newcomers don’t just receive documentation; they see architecture and implementation explained by the engineers who built them. It accelerates understanding of both the decision-making and how those decisions surface in code.

Why KaWa commerce stands out for tech talent

From the session “Walter Huber, CTO von KaWa commerce,” several strong reasons emerge for engineers who want a growth-oriented, practical environment:

• Flat hierarchies with real responsibility: short decision paths, visible contributions, ownership up to deployment.
• Small, agile teams: less coordination noise, more focus, clear impact.
• A learning system that works: internal training and certifications with AWS Partner support—including access to AWS Solution Architects to learn.
• Clear growth logic: from a junior with solid fundamentals to a senior with customer exposure and architecture responsibility.
• Cloud-first practice: AWS as both playground and production—microservices, Lambda, and CloudFormation in everyday work.
• Sandbox accounts for everyone: validate ideas quickly, automate, test, roll out—and reuse.
• Purposeful tech freedom: choose Node.js, Python, or PHP based on the use case—not dogma.
• DevOps as part of the role: bring up environments, automate infrastructure, think about operations.
• E-commerce with real-world stakes: Magento shops and cloud scaling for “traffic spikes.”
• Remote-friendly by design: strong home office culture; in-person touchpoints between Vienna and Carinthia to support team bonding and onboarding.
• Tools that respect the craft: strong hardware, quality displays, and professional IDEs (JetBrains) as standard.
• A welcoming culture: a young team that “welcomes” new colleagues; onboarding is “relatively good and simple.”

The mindset that ties it together

A few attitudes consistently surface in Huber’s remarks:

• Pragmatism over ceremony: small teams, direct ownership, and iterative delivery beat overhead.
• Learn on the system: sandbox accounts and microservice experiments generate speed and depth.
• Ownership fuels excellence: those who build also operate—learning to make well-calculated decisions.
• Invest in people and tools: solid equipment and training are not indulgences; they’re fundamentals.

These principles aren’t abstract. They add up to a workplace where talent can feel effective from day one—and where seniority is earned not by title inflation but by responsibility and contribution.

Conclusion: Ownership, a cloud mindset, and real growth opportunities

The session “Walter Huber, CTO von KaWa commerce” presents a company that turns its size into an advantage: agility, proximity, and a learning culture embedded in day-to-day work. If you see technology as a lever for customer outcomes, view “traffic spikes” as an invitation to scaling intelligence, and enjoy cloud-first, reusable solutions, this environment points in the right direction.

KaWa commerce blends Magento expertise with AWS practice, treats microservices as amplifiers rather than buzzwords, and pairs autonomy with accountability. The result is an engineering setup that challenges and supports talent—with clear steps from junior to architecture responsibility, solid tooling, and a welcoming culture that goes beyond slogans. For engineers who want to grow—technically, methodologically, and in their impact—this is a compelling proposition.

• 

  

  Event Driven Architecture in AWS

  Walter Huber von KaWa commerce zeigt in seinem devjobs.at TechTalk eine Herangehensweise an die event-driven Basics einer microservice Architektur in AWS.

  Watch now