Q&A

Mastering the Human Factors of Software Engineering

• By David Ramel
• 12/04/2025

You've got DevOps pipelines humming, your tooling is best-in-class, and your processes are well documented. And yet, something's still off. Commitments are missed. Quality is inconsistent. Team morale dips. The software ships--but it's never easy.

According to Benjamin Day and Angela Dugan, the problem often isn't technical at all--it's human. In their full-day hands-on lab at Visual Studio Live! Las Vegas 2026, titled "Mastering the Human Factors of Software Engineering," Day and Dugan will guide attendees through the less-talked-about aspects of software delivery: team dynamics, communication habits, burnout signals, and the systems thinking required to sustain high performance.

Day is a veteran software consultant and trainer, while Dugan brings her perspective as a longtime Agile coach and product delivery executive. Together, they've worked with teams across industries to bridge the gap between process and people, helping organizations move beyond tools and into the realm of high-trust, high-impact collaboration.

Rather than focusing on any one framework or toolset, the lab emphasizes how process, metrics, and feedback loops can help teams navigate complexity and stay aligned. Drawing from their decades of experience, the pair will help attendees connect human-centered strategies with the tactical realities of modern software delivery.

In the Q&A below, Day and Dugan preview what developers and team leaders can expect from the session, including how to spot early signs of burnout, improve communication habits, and use metrics to drive both delivery efficiency and team well-being.

VisualStudioMagazine: What inspired you to present on this topic?
Day: After 28 years of consulting, I've noticed a pattern: companies call me for "technical" problems, but 80% of the time the real issue is human. The code isn't the hard part. The people are the hard part. Teams struggle with trust, communication, fear, and burnout--and those problems masquerade as missed deadlines and buggy releases. I wanted to create a session that addresses what's actually going wrong, not just the symptoms.

Dugan: Ben and I have been in technology for decades and met about 15 years ago through our early careers in the agile and scrum coaching space. Ben had been delivering a really fantastic workshop on some of the challenges of software that go beyond the basics of agile and DevOps tools and processes. I was sitting in the audience and realized I had some great techniques and experiences to share that would complement his content and would come at some of the human challenges he addressed from a slightly different angle. I suggested we join forces and that I could fold in some of my related workshop content around feedback, metrics, and developing an agile mindset. It felt like a perfect pairing of complementary workshop discussions and exercises around people, process, and tooling that allowed us to go both broader and a bit deeper on the underlying challenges of delivering software--namely the "messy people stuff" that often trips us up if we're not ready for it.

How can a tech lead identify early signs of burnout in their team, especially in a remote or hybrid work environment?
Day: Watch for the quiet ones getting quieter. In remote environments, burnout often shows up as cameras turning off, responses getting shorter, and people who used to have opinions suddenly having none. The dangerous signal is when someone stops pushing back--when they just say "sure, whatever you need." That's not agreement; that's surrender. Also pay attention to who's working weird hours. If someone's sending emails at 11 p.m., that's not dedication--that's a warning sign.

Dugan: This may sound obvious but really paying attention to your individual team members and how they are engaging on a day-to-day basis. In my experience, burnout isn't a thing that just manifests in super obvious ways overnight. There's no neon sign. It can start with occasional distraction, or missing a meeting here and there, slightly off interactions with other team members, things you can easily explain away if you're not really engaged with your team regularly.

You mentioned 'tracking the right metrics'--can you give a quick example of one metric that balances delivery efficiency with team health?
Day: Cycle time--how long it takes from starting work on something to getting it done. It's honest because you can't game it, and it naturally rewards the behaviors you want: smaller work items, fewer interruptions, less work-in-progress. When cycle time is healthy (days, not weeks), it usually means the team isn't drowning. When it balloons, something's wrong--either the work is too big, there are too many things in flight, or people are getting pulled in too many directions.

Dugan: We love this question because we'll talk at length in our workshop about how there is not one single metric that can do this. If there was one theme to focus on, team health and engagement is a good place to focus. Having a scorecard that sums up the team's excitement, engagement, and happiness with the work they are doing is a fantastic way to get leading indicators of future performance, efficiency, and quality. The kinds of things reflected in this scorecard include ease of deploying code, quality and stability of the code base, having work that is fulfilling and challenging, and having regular opportunities to learn and grow. If you're really looking to hone in on team efficiency and effectiveness, don't ask tools, ask people.

What's one low-effort communication habit a team can adopt this week to reduce friction or misalignment?
Day: Replace "don't forget" with "remember." It sounds trivial, but the language you use shapes how people think. Negative framing ("don't miss the deadline," "stop introducing bugs") makes people defensive. Positive framing ("let's hit this target," "let's keep quality high") enlists them. This week, catch yourself before you say "don't" or "stop" and flip it around. You'll be surprised how much less resistance you get.

Dugan: Focusing on WHY and not just what and how. It can be easy to get into an execution rhythm and build the items in front of you every day. Where we can get into trouble is when we stop asking WHY are we building this thing? Why does the user want to do this thing, this way? Understanding the why helps us understand the root of the real problems we are trying to solve, and the experiences the user wants to have. When we stop asking why we risk building a lot of individual components, that may be well crafted, but when added together don't truly provide the value that was being sought out. Asking why allows us to question assumptions, validate understanding, and always saves time in the long run by keeping our perspective and focus rooted in building the right solution.

In terms of team dynamics, how do you suggest handling a team member who consistently resists Agile or DevOps practices?
Day: First, get curious instead of frustrated. Resistance usually means something--maybe they've been burned before, maybe they see a real problem you're missing, or maybe they just don't understand the "why." Ask them: "Help me understand what's not working for you." Often the problem isn't that they resist change--it's that they resist being told to change without being consulted. If you enlist them in solving the problem instead of imposing your solution, you might find your biggest critic becomes your biggest advocate.

Dugan: In all my years of coaching, I've never found someone resisting good practices because it is something labeled as "Agile" or DevOps." Not really. What people resist is change that they don't understand, where there is no clear advantage or gain for them, if the change feels forced or unnatural, sometimes a little of all those things. Any change, not just the ones involving process and tools, requires thoughtful messaging, communicating the WHY, WIIFM ("what's in it for me"), and being transparent about how people will be impacted. The best approach, and one that if done well typically avoids resistance, is following good change management practices here. Change management reduces resistance by aligning people, processes, and communication to build shared understanding and commitment throughout the transformation, not just at the beginning. It minimizes pushback by preparing teams for the change they are about to experience, addressing concerns openly and proactively, and fostering a culture of collaboration, trust, and shared success.

Can you briefly explain the 'theory of constraints' in a way a non-technical stakeholder could understand--and why it matters for team performance?
Day: Your system can only move as fast as its slowest point. If you have a five-lane highway that narrows to one lane, it doesn't matter how wide the rest of the highway is -- you've got a traffic jam. In software teams, we often try to speed up the parts that are already fast (more developers! more features!) while ignoring the actual bottleneck (testing, deployment, unclear requirements, waiting for approvals). Find the constraint, fix the constraint, then find the next one. Everything else is theater.

How can attendees learn more about this topic and also prepare for your session?
Day: Come with a story. Think about a project that struggled or a team that didn't gel -- what actually went wrong? Not the technical stuff, the human stuff. Who was afraid? Who wasn't communicating? Where was the trust missing? If you come ready to share (even just with yourself), you'll get more out of the session. And if you want a head start, I've got a YouTube series on flow metrics and project management fundamentals.

Note: Those wishing to attend the session can save money by registering early, according to the event's pricing page. "Save $500 when you register by the Year-End Savings deadline of Dec. 19," said the organizer of the event, which is presented by the parent company of Visual Studio Magazine.