This document features some of my learnings and discoveries in game development work. I think about processes a lot so it’s about time I jotted them down.

Problem-Solving

I provide value by solving problems. This is my belief. The crux of this activity is determining an obstacle, its cause, and how to overcome it. This is done over and over again and unfortunately, it consumes mental energy. Mental energy is precious but more on that elsewhere. Breaking down the triangle of problem-solving:

• Obstacle: this is not the problem itself but the result of the problem; the perceived negative outcome if you will.
• Its Cause: this is the problem, the thing creating the obstacle. What needs a solution?
• Action: what we perceive to be the intended solution to overcome the obstacle. Note: it’s not THE solution but what we can do that we think will remove the cause of the obstacle.

So, one must perform an action to remove the cause of an obstacle. The action needs to be do-able immediately. If it doesn’t work, you try a different action. The ONE Thing book touches on this but the best action is one that addresses the most obstacles. If skilled and/or lucky, the first action taken is the solution that overcomes the obstacle.

During my tenure, I’ve noticed an interesting behavior. Many colleagues focus on the action without properly identifying the cause of the obstacle. They often see problems as a question/answer type scenario, like miniature tests. I blame scholastic conditioning for this. But problems are a three-pronged beast. One must understand the obstacle and its cause first. Usually, the obstacle is easier to identify (someone else might have done it for you). But the beauty of problem-solving lies in discovering what causes the obstacle. Of course, people do this but it’s often surface-level identification. We need to go deeper!! That’s how we get to the root cause of an issue. Or else, we just come up with band-aid “solutions.”

Delegation and Implementation

This might be reductive but in a typical workplace, we have those who manage and those who do the work. The former steer the latter into getting desired results. It’s an important relationship and like all relationships, trust is an important component. The one who delegates has to ensure the team achieves results. The details of the implementation should not be important to them. And the one who implements needs to focus on how well they perform their implementation. They should not worry about delegation or results. Supposedly, ideal work environments would have self-managing individual contributors. One person both delegates and implements. This takes a lot of effort and it’s easier said than done. A good producer once told me that a great manager strives to make themselves obsolete or redundant. Of course, this is also easier said than done.

One thing I’ve noticed is that teams often find fault in implementation. But delegation is rarely questioned. When results are not achieved, both aspects need evaluation. Yes, poor implementation occurs but what about poor delegation? Were the tasks possible to complete with the available resources? Lofty goals rarely produce good results. The delegator has no insight into the details of implementation. For them to make good decisions, they need good information from the implementers as well. It is a relationship, after all, so communication plays a crucial role.

Communication

Communication is difficult. We must accept this first. If you think it’s easy, you’re probably not good at it and most likely work alone or in a homogenous environment. And if you still think it’s easy, think about a time you had to give critical feedback to someone.

The challenge with communication is you cannot ascertain whether the listener has understood you. The listener might nod and say “understood!” but until they perform an action, you cannot be certain. A practice I sometimes do is re-iterate what I’ve been told so the other party can understand whether I understood what they told me. This is time-consuming and as humans, we like taking shortcuts. At the heart of most miscommunications is an error-prone shortcut.

Critical Feedback

Never give negative feedback. It’s harmful to all parties involved. The difference between critical feedback and negative feedback lies in intention. The intention guides the delivery which in turn affects the result. The intention of negative feedback is often to assert dominance or belittle. This leads to confrontation or humiliation which rarely addresses the issue at hand.

Critical feedback, on the other hand, comes from a place of empathy. Its intention is to improve results and make things better! It never gets personal. It stays factual and on topic. If a piece of feedback invokes an emotional reaction, it wasn’t delivered well.

Thinking back to times when I failed to give good critical feedback, the reason seems simple. I dwelled on the person instead of the results caused by their actions. Empowering the feedback recipient is better than pointing fingers at them. Pro tip: avoid shock or surprises (any theatrics); these will invoke emotional reactions.

I’ve found that feedback is effective when it is:

• Actionable
• Backed by Data
• Candid

Concluding Thoughts

Work processes are fraught with issues; the best way to unearth these is to ask questions, particularly the “why” questions. Some work environments thrive on stifling inquisitiveness and sometimes with good reasons.

Questions imply something is wrong and people don’t like wrong things. But if there are problems, they need solving lest they fester and mutate.

A very good question is “why are we doing what we are doing?” and like a petulant child, one must keep asking why until one drills down. It’s a fun thought exercise if nothing else!