7 Powerful Questions to Ask Your Development Teams — What We Learned from Philipp Dressler (MIC)

Why these seven questions matter

In the session “7 Powerful Questions to ask your Development Teams,” Speaker Philipp Dressler (MIC) lays out a compact, field-tested framework for improving software delivery. The emphasis is not on tools for their own sake, but on practices that tighten feedback, align teams with users, and protect the codebase from the slow creep of rework and technical debt. From our DevJobs.at editorial vantage point, this was a pragmatic tour through questions that reshape how teams think, talk, and build.

Across the talk, a consistent pattern emerges: small, deliberate adjustments compound into big outcomes when teams create room to practice, get closer to real users, favor examples over abstractions, and embed solid engineering routines into daily work. The seven questions below are straightforward to ask — and powerful to act on.

Question 1: Do you develop yourself?

Teams often talk about building software, but not enough about developing their own skills. Dressler’s starting point: teams need protected space to practice — continuously, not as a one-off. At MIC, that space takes the form of “Technical HR Enabling.”

What “Technical HR Enabling” means in this talk

• Technical HR coaches work closely with a development team for a defined period (for example, three months).
• They then switch to another team. The goal is to improve how code is written together — not just teach individuals in isolation.
• Compared to one-off trainings, continuous collaboration is more sustainable because it tackles real everyday problems.

There’s a cost and a payoff:

Intentionally slowing down to invest in design, shared standards, and repeatable practices increases future throughput. As leaders, it’s worth making this investment visible — not as a luxury, but as a strategic choice.

How to apply it

• Carve out coaching windows (e.g., three months) where real tickets are tackled with a focus on engineering practices, not just feature output.
• Use the period to codify team standards that stick (Definition of Done including tests, review patterns, pairing routines).
• Evaluate impact not only by velocity, but also by effects on rework, change effort, and defect cycles.

Question 2: Can you show me how your users work?

Dressler pushes for proximity to actual users. The litmus test: can developers operate the software like users do? Often, the honest answer is “not really.” When that happens, understanding of real workflows blurs — and teams ship features that are rarely or never used.

The core points

• Developers need access to user context. That’s how they deliver fit-for-purpose solutions.
• Many features across the industry get built and then barely used — a costly trap.
• If you can’t measure usage, ask your users. Direct feedback beats guesswork.
• Avoid “just-in-case” functionality; build what’s demonstrably needed.

Dressler also urges teams to test for product fit, not just technical correctness. We tend to “build the thing right,” but we have to keep asking whether we’re “building the right thing.”

How to apply it

• Set up regular sessions where developers walk through real user flows end to end.
• Measure what you can, then complement with qualitative interviews.
• Aggressively de-prioritize or remove unused features and reinvest the time into validated needs.

Question 3: Can you give me an example?

Dressler calls this one of the most powerful questions in software development. Why? Because human brains handle concrete examples better than abstract discussions. If a group gets lost in theory, ask for an example and you’ll converge faster.

He illustrated the point with a simple “cards” setup: blue cards for acceptance criteria and green cards for examples explaining them. Even in seemingly straightforward cases, the difference is obvious — examples anchor a shared understanding.

Once written down, examples double as test cases: first manually, then automated. That shifts misunderstandings forward — to the cheapest possible stage.

How to apply it

• Interrupt abstract debates with “please give a concrete example.”
• Record examples so they become stable project knowledge and tests.
• Bring those examples into discovery/refinement (see Question 5) to “test” requirements before any code is written.

Question 4: Do you share a common domain language?

MIC leans on Domain-Driven Design (DDD). For Dressler, the most important practice is a shared domain language. It underpins precise conversations and precise code. The challenge is to find the right words and learn to “speak business.”

An unexpected source of clarity can be the past. In a long-standing domain like customs and trade, older terminology often helps teams reason about processes. Dressler shared how the visual of a “stage coach” (in German, „Postkutsche“) helped the team sketch flows and land on the right concepts. Importantly, they did not promote “stage coach” into a domain concept in code; it served as a thinking aid.

How to apply it

• Build and maintain a domain glossary that guides both product discussions and code.
• Use historical or illustrative analogies to untangle processes — but only promote precise, durable terms into code.
• Practice strict language discipline in tickets and reviews to cut ambiguity and rework.

Question 5: How much rework do you see — and when do you test?

Rework is part of the craft, but timing is everything. Dressler’s telltale symptom is “Jira ping pong”: a ticket bounces from development to testing and back, maybe on to product — shedding time and context at every hop.

He offered three quick wins that shrink feedback loops and reduce rework.

1) Discovery meetings / requirements workshops

Before pulling a ticket into a sprint, discuss it deeply — including concrete examples. Doing so “tests” the requirement before any code exists. That’s the cheapest form of testing.

Practical pointers:

• Set explicit goals per session: which cases are understood, which examples represent them.
• Capture examples in a way that can be turned into tests later.

2) Test-driven development (TDD)

Dressler is a fan. Beyond higher test coverage, he emphasized the design payoff: TDD nudges code toward decoupled, sustainable structures. Tests become a design partner rather than an afterthought.

Practical pointers:

• Start small and get used to the rhythm (red–green–refactor).
• Don’t chase coverage for its own sake; watch for coupling and ease of change as the real signal.

3) Pair or mob programming

“I absolutely love this,” Dressler said — because it produces the shortest possible feedback cycle. Two (or more) developers think, type, and review together. Many reviews become unnecessary, tests are born closer to the problem, and the code becomes a team asset, not an individual’s.

Practical pointers:

• Introduce pairing with light guardrails (role switches, focus slots, brief retros at the end).
• Use mob sessions for gnarly refactorings or knowledge transfer.

Question 6: Is it easy to modify or extend your software? (Technical debt)

Technical debt accumulates and slows teams down. Dressler referenced studies quantifying productivity loss at 23% and, in other cases, 42%. In many teams, it feels even higher — that’s normal. The real question is how you respond.

He warned against two common reflexes:

• Adding more people: it rarely helps. The metaphor makes the point:

• Paying down debt while running at the same feature cadence: this grinds teams to a halt. Small changes take forever. And relying on long hours? As Dressler put it succinctly, “Working long hours is 1990s.”

Better approaches to technical debt

• Double down on good engineering practices: refactoring, sound design, deliberate architecture decisions.
• Live the Boy Scout rule:

Every ticket improves the code just a bit — small, steady refactorings beat heroic overhauls.

• Aim for sustainable software development: for Dressler, that means automated testing and good design principles. Together they lower fear of change and enable lasting speed.

How to apply it

• Allocate explicit capacity for refactoring in regular work. If debt handling is “extra,” it won’t happen.
• Pair up on legacy hotspots to build safety nets (tests) and unwind risky coupling.
• Attach architecture choices to examples (see Question 3) so intent stays clear.

Question 7: Are your teams happy?

Dressler closes with a people-first question. Drawing on research by Nicole Forsgren, he notes that satisfaction and well-being correlate with productivity. That’s intuitive — and actionable. A good working environment isn’t a perk; it’s a performance factor.

How to apply it

• Create an inspiring environment — what that looks like will vary, but it should enable focus, learning, and pride in outcomes.
• Use the previous six questions as levers for satisfaction: user proximity, shared language, fast feedback, and solid engineering practices are strong motivators.

The “architecture” of collaboration

Even without code demos, the session points to a clear architectural stance: system design emerges from practices, language, and feedback loops. Three patterns stand out:

• Cooperative architecture: pairing/mobbing and TDD move design decisions into collaborative execution.
• Language architecture: a shared domain language becomes the scaffold for conversations and code.
• Feedback architecture: discovery workshops, examples, and early tests are structural components that prevent drift.

This “architecture of collaboration” is what makes systems changeable — and changeability is Dressler’s yardstick for technical quality.

A 4–6 week action plan

• Weeks 1–2: Start discovery meetings ahead of each sprint. Capture at least three concrete examples per ticket.
• Weeks 1–4: Introduce pair programming with simple guardrails (e.g., two 2-hour slots per day). Aim at tricky areas.
• Weeks 2–6: Begin TDD on small, new components. Don’t chase coverage; watch for decoupling and ease of change.
• Ongoing: Maintain a domain glossary, audit wording in tickets/code, and add examples whenever terms feel fuzzy.
• Ongoing: Practice the Boy Scout rule — small refactors on every change.

The key learning from the session

• Teams need space to practice, not just a feature treadmill.
• Proximity to real users is the best antidote to unused features.
• Examples beat abstractions — and become tests.
• A shared domain language glues business and code together.
• Rework shrinks when feedback is early and collaborative (discovery, TDD, pairing/mobbing).
• Technical debt demands disciplined practices, not more heads.
• Satisfaction and productivity are correlated — build environments that foster both.

Conclusion

“7 Powerful Questions to ask your Development Teams” by Philipp Dressler (MIC) is a crisp, practice-first blueprint for better software. Each question targets a bottleneck: learning time, user understanding, clarity through examples, shared language, early testing, changeability under debt, and team happiness. Teams that act on these levers create the structural conditions for sustained speed and quality — now and in the future.

• 

  

  Technical Agile Enabling

  Pia Otter-Bäck von MIC gibt in ihrem devjobs.at TechTalk Einblick darüber, wie im Unternehmen das Thema Technical Agile Enabling umgesetzt wird.

  Watch now
• 

  

  The MIC Tech Radar

  Wolfgang Gassner von MIC zeigt in seinem devjobs.at TechTalk die Herangehensweise, wie im Unternehmen die riesige Zahl an verwendeten Technologien überschaubar gehandhabt werden.

  Watch now
• 

  

  Organization for Fast Flow

  Gerald Schweizer von MIC beleuchtet in seinem devjobs.at TechTalk die wesentlichen Gedanken, wie und warum die Organisation der Development Teams im Unternehmen verändert worden ist.

  Watch now
• 

  

  How our career paths help you grow as a Software Engineer

  David Theil von MIC erläutert in seinem devjobs.at TechTalk die grundlegenden Gedanken, welche hinter den verschiedenen Rollen als Software Engineer im Unternehmen stehen.

  Watch now

• 

  

  Clemens Kriechbaumer, Team Manager Data Science bei MIC

  Clemens Kriechbaumer von MIC spricht im Interview über den Aufbau des Data Science Teams und dessen Themenschwerpunkte, die dort eingesetzten Technologien und wie dort das Recruiting gestaltet ist.

  Watch now
• 

  

  Wolfgang Gassner, Director Produktentwicklung bei MIC

  Der Director Produktentwicklung bei MIC Wolfgang Gassner gibt im Interview Einblicke über das Team, wie der Recruiting Prozess abläuft und wie das Unternehmen die technologischen Herausforderungen meistert.

  Watch now