Never Been Tasked

For over 15 years in my career, I had never been tasked. Not even as a young engineer, straight out of school. Not even when I changed roles, nor during my first weeks at a new company. I have always had autonomy within an understanding of my role on the project and within the organization. When I first started as a Development Director in the video game industry, it was a strange feeling when I realized that I was expected to task my programming team. One of my programmers had 10 more years of experience than I had, plus I was new to the industry. It was an even weirder feeling when some years later, my boss sent us a task list. As a senior leader for a number of years, it certainly was the last thing I expected.

So how did I know what I needed to do? How did my team know what they needed to do?

Mission and Responsibilities

The first company I worked at infused us with the company mission and our roles in it from the very first day. Then, my Team Lead described my specific role, my customer, and my main mission. I was surrounded by experienced people I could observe and who would answer my questions. As I learned, I progressively took on more responsibility. Because I knew my role and my mission, I knew what I had to do day-to-day, was able to drive longer term strategies and could act quickly when things went wrong. I do the same thing with my teams, particularly the leads. They know their team’s mission, their own mission and what their responsibilities are, which I reinforce through coaching, guidance, feedback and discipline (the good kind).

Goals and Priorities

In the industries I worked in before video games, everything was communicated as goals and priorities. We set and measured ourselves on business and quality goals and we were expected to continuously improve on them. Meeting our customer commitments, in all respects, and keeping our customers happy were always top priority, so it was easy to prioritize as things came up. So, instead of tasking my programming team when I entered video game development, I applied the same philosophy. I worked with the team and our internal clients to build a prioritized list of deliverables. Sometimes those deliverables were specific, but often they were problems that needed to be solved. When we received a new request, we were easily able to weigh where it belonged in the priorities and update our commitments. I do the same with my content-creation teams today. We work together to set the goals and priorities for each milestone and the team handles the individual tasks to achieve them.

Ask, Not Task

Whenever someone needed something specific from me, they have simply asked. Even when deadlines were involved, I was asked. There is a big difference between being asked and being tasked. The former inherently implies a choice and an option to decline or redirect the request. If the work is accepted, then with it comes a commitment to deliver on a promise. Being tasked simply means you are being told to do something, whether or not you want to do it. The commitment is imposed, not derived from accepting a request.

As a result of never being tasked, I developed a sense of ownership, autonomy, and empowerment. I was able to prioritize and make decisions quickly because I knew my mission, goals and where my priorities fit in with the overall project and/or business. From there, I was able to build my leadership skills. Isn’t that what we want from all of our teams?