Logo Beyond Now

Beyond Now

Established Company

David Kolb-Zgaga, Scrum Master bei Beyond Now

Description

David Kolb-Zgaga von Beyond Now redet im Interview über seinen Background wie er zur aktuellen Arbeit als Scrum Master gekommen ist und gibt Tipps was seiner Ansicht nach wichtig für Neueinsteiger ist.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In "David Kolb-Zgaga, Scrum Master bei Beyond Now," David Kolb-Zgaga outlines his path from studying software development/economics and starting as a Technical Consultant to becoming a certified Product Owner and ultimately a Scrum Master, a role he has held for nearly four years at Beyond Now. He supports two R&D teams by ensuring Scrum is practiced, moderating meetings, improving processes, and scaling best practices through role-based Communities of Practice, valuing the role’s blend of technical and social, human-centered work. His advice: certifications and a degree matter (especially in Austria), but communication, proactivity, and understanding team needs are more important than reading code.

From Customer-Facing to Team-Centered: David Kolb‑Zgaga’s Journey to Scrum Master at Beyond Now

Highlights from the session “David Kolb-Zgaga, Scrum Master bei Beyond Now”

In the session “David Kolb-Zgaga, Scrum Master bei Beyond Now,” speaker David Kolb-Zgaga shares a concise, human-centered career arc: he studied software development with a business focus, started out as a Technical Consultant, moved into a Product Owner role with a certification, and then transitioned to Scrum Master. For nearly four years he has been a Scrum Master at Beyond Now, supporting two teams in R&D. What stands out is how he consistently orients his work around relationships—first with customers, and then, even more importantly to him, within the team.

From our DevJobs.at editorial lens, three themes anchor his story:

  • A constant dialogue between technical interest and social impact—and the drive to combine both.
  • A progressive shift from external to internal relationships: from customers to the company’s teams.
  • Turning insights into practice: moderating meetings, introducing best practices, improving processes, solving day-to-day team problems, and building Communities of Practice.

Below, we unpack these milestones and extract pragmatic takeaways for developers, product folks, and aspiring Scrum Masters.

Choosing between two poles—and bridging them

David frames his early decision plainly: he was torn between a technical path and a social one. He opted to study software development with a business component. The business side, as he notes, did not yield the social dimension he had anticipated, yet the choice set the tone: pair technical understanding with an orientation toward people and value.

We see this as an early indicator of fit for roles that live at the intersection of technology and collaboration: the combination matters more than its exact proportions at the start.

First step as a Technical Consultant: customer contact as a catalyst

His first job as a Technical Consultant was “super,” in part because it involved significant customer interaction. That phase appears to have sharpened the very muscles that later define his work: listening, translating needs, and anchoring solutions in real expectations. Yes, technical depth is important—but the practice of forming shared understanding with users and stakeholders is what accelerates learning.

For career builders, a few implications are clear:

  • Customer contact refines language, prioritization, and empathy.
  • Technical arguments land better when tethered to concrete user needs.
  • Consulting experience prepares you for interface-heavy roles—Product Owner or Scrum Master among them.

Product Owner: certification, responsibility—and even more proximity to needs

David moved into a Product Owner role and obtained a related certification. Again, the strong customer touch was a positive for him. This stage underlines what he later emphasizes explicitly: relationships and communication are not add-ons. They are central to shaping direction when problems are fuzzy and diverse voices need to be reconciled.

To us, Product Ownership often teaches the vocabulary of need, value, and focus. For some, it’s a destination. For David, it became a bridge—toward the internal relationships and team dynamics he values even more.

Turning inward: why Scrum Master?

David crystallizes the key pivot: “A customer relationship is never the same as an internal team, company-internal relationship.” That realization led him to the Scrum Master role, which he has held for nearly four years at Beyond Now. His motivation is apparent: he wants to work creatively with people, in a team, in a human-centered manner. The allure is not the framework on paper, but the collaboration it enables in practice.

This shift suggests a different set of questions:

  • How do we design meetings to be genuinely useful rather than procedural?
  • Which best practices fit this team’s context, not a generic template?
  • How can everyday team problems be solved quickly, pragmatically, and together?

Scrum Master at Beyond Now: making the framework work for teams

David sums up his day-to-day succinctly. He supports two teams in R&D, ensures that “the Scrum framework is executed,” moderates meetings, introduces best practices, improves processes, and resolves everyday team problems. It’s a service mindset: hold the frame, remove friction, and enable focus.

We hear several anchors in that description:

  • Clarify the frame: the Scrum framework isn’t ornamental—it provides orientation for who does what, why, and when.
  • Moderation as a service: it’s not a show; it’s structuring conversation so outcomes can emerge.
  • Continuous improvement: best practices are introduced, tested, and adapted.
  • Solve the everyday: small frictions matter; addressing them consistently makes teams more effective.

The tone across his account is pragmatic. The role is steady and active—less about being in the spotlight, more about enabling others to succeed.

Beyond the teams: Communities of Practice and company-wide initiatives

Alongside the team work, David highlights a company layer: “We have a Community of Practice for every role. In my case, all Scrum Masters meet. We talk about everyday problems and how to fix them, and sometimes larger problems turn into an initiative that is rolled out company-wide.” He notes that this cuts “across all roles” and is implemented jointly across the company.

We see three noteworthy dynamics in this:

  • Routine exchange: role-based communities provide a safe space to surface problems and refine solutions.
  • From problem to initiative: recurring issues deserve structure; initiatives bring scale and visibility.
  • Cross-role bridges: change sticks when it’s carried broadly—David calls this out explicitly.

He also mentions that this company-level contribution is “aside from the teams,” while reaffirming that the main focus remains on the teams. In practice, effectiveness emerges at both the micro (team) and macro (company) levels; they reinforce each other.

Why he remains a Scrum Master: technical meets creative, centered on people

David describes Scrum Mastery as uniquely combining technical and social dimensions. Working jointly and creatively with a team, in a human-centered way, is what draws him to the role—and what he wants to continue doing. You can hear the fit in how he speaks about it.

That, to us, is an invitation to assess personal alignment:

  • Do you prefer moderating to coding? This role might be your lane.
  • Do you enjoy shaping processes and bringing people together? That’s central here.
  • Are you comfortable creating impact without being center stage? That’s the sweet spot of the role.

The Austrian context: certifications, education—and what really matters

David is candid about the market reality: “Certifications are still important” in Austria. A Scrum Master certification is “certainly not a bad thing.” He adds that “some form of higher education” will likely be needed—though not necessarily in a technical field. He himself studied software development, yet he works with colleagues “from very different backgrounds.”

Then he draws the crucial line: what matters more is being communicative, always having an open ear, being proactive, and—most importantly—understanding the needs of a team. For the role, you don’t need to read code; you need “entirely different strengths.”

Practical takeaways from that emphasis:

  • Certifications: helpful where formal proof is expected; they can open doors and provide orientation.
  • Education: valuable, but not necessarily technical; the key is professionalism and fit to context.
  • Core skills: communication, listening, proactivity, and understanding team needs.
  • Technical literacy: it helps to understand the language, but active coding isn’t required for the role as he presents it.

Actionable guidance for aspiring Scrum Masters and team-centric engineers

If David’s journey resonates with you, consider the following moves—grounded in what he highlights:

1) Seek proximity—first to users, then to your team

  • Customer-facing work sharpens judgment and prioritization.
  • Turning inward deepens your understanding of team habits, dynamics, and expectations.

2) Learn to moderate—outcome over performance

  • Aim for decisions and clarity, not ceremony.
  • Make goals, timeboxes, and roles transparent in meetings.

3) Treat best practices as starting points, not dogma

  • Introduce, evaluate, adapt: practices must fit the team’s reality.
  • Simplify processes; don’t add friction.

4) Take everyday problems seriously

  • Small issues compound; resolving them consistently lifts team effectiveness.
  • Keep the team’s needs front and center—David underscores this repeatedly.

5) Build a Community of Practice

  • Establish regular exchange with peers in your role.
  • Turn recurring problems into initiatives that reach beyond a single team.

6) Use certifications strategically

  • Where expected, they open doors; they’re a means to an end.
  • They do not replace the core skills David names: communication, listening, proactivity, and team understanding.

Quotes and lines that stick

I always wondered whether to do something technical or something social.

A customer relationship is never the same as an internal, company-internal relationship.

I make sure meetings are moderated, best practices are introduced, processes are improved, and everyday team problems are solved.

We have a Community of Practice for every role … larger problems become initiatives rolled out company-wide … across all roles.

This Scrum Master role combines both [technical and social] in this environment … human-centered.

Certifications are still important … It’s much more important to be communicative, to have an open ear, to be proactive, and above all to understand a team’s needs.

What we took away at DevJobs.at

  • Balanced role: a tangible way to unite technical understanding with social competence.
  • Relationships first: from customers to teams—the work succeeds through relationships.
  • Everyday impact: meetings, practices, process improvement, and problem-solving add up to real effectiveness.
  • Community at scale: Communities of Practice and cross-role initiatives help good ideas travel.
  • Certifications as door openers, soft skills as engines: that’s the ordering David suggests.

Closing: A people-first path—pragmatic and sustainable

“David Kolb-Zgaga, Scrum Master bei Beyond Now” is not a one-size-fits-all playbook. It’s an invitation to define your role through relationships. David’s trajectory shows how technical literacy and social skill can reinforce each other—first outward (consulting, Product Ownership), then inward (Scrum Mastery within teams and across the company). If you’re weighing a similar path, his cues are clear: proximity, moderation, improvement, community—and the sense to treat certifications as tools, not trophies.

What resonates most is the grounded tone of his account. No buzzword fireworks, no sweeping promises. Instead, a real day-to-day practice: uphold the framework, moderate meetings, introduce best practices, improve processes, solve everyday problems, and institutionalize exchange. That’s the kind of leadership work that moves modern tech teams forward—human-centered, pragmatic, and durable.

More Tech Lead Stories