As an Agile Coach at PagerDuty, I facilitate the majority of my development team’s core agile ceremonies. One of my main responsibilities is to challenge my team’s ways of thinking by asking them thought-provoking questions, which can possibly lead them towards uncovering a key underlying assumption about the topic of team discussion.

Therefore, I am no stranger to the potential negative consequences of treating misconceptions to be reality.

I’ve noticed engineering students don’t necessarily learn the skills required to succeed in the workplace from their time in the classroom. As such, they may take their academic lessons at face value. Thus, they approach problems in professional work under the misconception that they can fully replicate the problem-solving methodologies learned in academia to solve real-world problems.

Let’s explore some of the greatest misconceptions that I’ve come to fully realize through serving as an Agile Coach at PagerDuty.

Misconceptions—Where Engineering Can Be Misleading

Misconception 1: You always know a problem’s knowns and unknown
We live in an ever-changing world, be it emerging technologies, rapidly shifting weather patterns, or trends observed in the workplace. Thus, life is full of unknown variables that can seemingly appear out of nowhere, without anyone noticing until it’s too late to pivot on already-made decisions.

To name a few examples of unknown variables, when my development team began planning a new project, they understood the customer problem(s) they intended to solve, but they had no idea what roadblocks may come up. Only after we began working on the project did these roadblocks surface.

Those roadblocks later turned out to be how much time my development team went on call, how much code from other development teams they had to review, and the fact that some team members got diverted to work on another project. These roadblocks all contributed to the most important unknown variable—how does this impact my development team’s ability to deliver on their own project?

In contrast, engineering students are spoon-fed problems while they’re in the classroom. Nearly everything about the problem is known, except for the variables students are asked to solve for. Thus, when they approach real-world problems, they aren’t aware of the existence of these unknown variables, nor do they have a logic structure for attempting to take these unknown variables into account while solving these problems.

The takeaway: Instead of focusing on what information is known about a situation, challenge yourself to think at least one step ahead of the situation playing out in real time so you’re constantly in a more proactive position.

Misconception 2: Technical problems > people problems
Math and science are hard subjects and many companies used to look at GPAs and other educational achievements during the recruiting and hiring process. However, when it comes to job-searching and recruiting today, increasingly more emphasis is placed on a candidate’s cultural fit with the organization, as well as their soft skills.

From personal experience, I’ve discovered that listening to others (rather than speaking) has greatly benefited collaboration with colleagues in the workplace. By listening, I can better understand the needs and motivations of an individual or an entire team, which directs me to support them in how they want to be supported—rather than how I think that they want to be supported.

The takeaway: I recommend taking an in-person or online introductory psychology course. In doing so, my perspective about people, motivations, and collaboration is better informed. Consequently, I’m more aware and intentional in my interactions with others.

Misconception 3: Don’t ask questions—accept and move on
While working with the Agile Leadership Team, I’ve found that asking questions is typically a sign that you’ve given critical thought to the system, process, or topic you’re trying to understand. It means you’ve identified gaps in your knowledge and are motivated to fill them.

For example, when I encounter a new situation with my development team that doesn’t require an immediate response from my end, I turn to my mentor and the other Agile Coaches to solicit their advice and understand the rationale behind their suggested courses of action.

The majority of university students can count on one hand the number of professors they’ve had who are able to pass along their knowledge to them at their level of understanding. When students approach their professors with questions about lecture content, they typically either leave the conversation feeling more confused than they were going into it or dissatisfied with the professor’s response that usually ran along the lines of “That’s beyond the scope of this course.”

The takeaway: To increase my chances of eliciting a response I can understand, I’ve found asking the individual to explain their answer to my question differently to be fairly successful. For example, I may ask them to draw a diagram, explain using an everyday analogy, explain like I’m a five-year-old, etc. Experiment with which line of questioning works for you.

Misconception 4: Self-care comes second to productivity
At PagerDuty, our development teams have structured channels for monitoring and reflecting on their health:

• Team retrospectives. On a biweekly basis, a retrospective provides the development team with a channel to inspect itself and create a plan for improvement for the next iteration of work (and beyond).
• Team health checks. On a quarterly basis, one of the goals of the health check is to enable the development team to foster awareness and encourage discussion within the team about how they work and what pain points they experience.
• Metrics pertaining to team health. On a weekly basis, the development team reviews how many hours the team’s on-call responder had to work during business hours and off-hours in the past week. This empowers them to make decisions on prioritizing and scheduling in proactive maintenance work to minimize interruptions to the on-call responder.

The takeaway: Beginning in May 2019, I made a conscious effort to take off Friday evenings from doing any schoolwork. Not only did I get to relax, I also wasted less time mindlessly scrolling through my social media feed. Keep a block of your calendar free at least once per week to focus on you!

Misconception 5: You can do it all and don’t need to prioritize personal improvements
Many people, including myself, have definitely fallen into the trap of wanting to make improvements in multiple aspects of life, even though it may not be realistic.

For example, some engineering students feel obligated to work out six times a week and prepare an entire week’s worth of lunches and dinners in bulk—all while studying 60 hours a week, working on side projects, and trying to launch their first startup. But is this realistic?

If you can do all that, hats off to you! If you’re like me, however, reviewing that to-do list is already intimidating enough—let alone attempting to do it all.

While facilitating retrospectives for various teams at PagerDuty, I aim to get the team to converge on one or two action items they think will greatly improve the way in which they work. By being selective and intentional about action items, the team can harness their focus and get things done more effectively—versus trying to boil the ocean.

The takeaway: Prioritize what you want to accomplish so you can sustainably deliver on your commitments without sacrificing quality.

Studying Engineering Is Valuable, and..

The exact same misconceptions I outlined from observing engineering students in the workforce may not resonate with you. However, chances are that you picked up a concept, theory, or principle from a traditional learning channel that you later discovered wasn’t wholly applicable in the real world.

I challenge you to reflect on your own life experiences, how they may be limiting your thought process or perspective, and how you may work towards overcoming your own learned misconceptions. Share your reflections and experiences with the PagerDuty Community—we’d love to hear from you!