When one evolves through a variety of roles in the games industry, it is hard to know exactly what's expected and what's realistic. This line of questioning possibly encompasses all roles where it is possible to acquire strategic responsibilities and even jobs that require some level of autonomy. Whether you're an entry-level QA, a seasoned veteran developer, or an executive producer, I believe the same core questions apply on a daily basis:

• What should I be doing
• What should I NOT be doing (either something I need to delegate, or communicate that it is unlikely this will get done given the other priorities, etc.)

This duality is strong: as one acquires more responsibilities, one would expect more to be done by said person, but there isn't ever any more time. Rather, what should happen is that the person should refocus their priorities in such a way that everything they're responsible for gets done, but not necessarily by them. For example: A QA Engineer should uncover issues, and likely report them upstairs so that their lead can assess the validity and priority.

Likewise, a lead QA shouldn't put as much time into testing and insure they have a better traversal understanding of the bug base at any given point. The same principles apply to a programmer vs lead programmer or artist vs lead artist roles. But when on enters such a 'new position' there's no quick guide on how to juggle with all of these priorities.

IF lucky, all one has is a job description that lists what is now expected of them, but certainly not what they're expected to delegate. Being responsible for the development of a game certainly doesn't mean you have to do everything on your own, but how can you figure out what you can and can't do? Introducing, the 'One-page mentality'.

I used to be the guy that would take a lot of notes in a small diary. Too many notes in fact. And at the end of every day, I would transcribe to a new page only that which was actionable, because parsing through 20 pages for a single day's notes in a QA capacity was simply not efficient. And thus, at the end of every day, I forced myself to summarize all of these notes to as little as possible (oftentimes, 1 or 2 pages).

Unbeknownst to me, this practice was actually solving a lot of the common challenges coworkers were having, and it took close to a decade to figure out that this very process (although a bit raw) was a large reason for my relative success. But why?

Quite simply because an individual's level of responsibilities in any particular project is inversely proportional with their strategic role. For example, a lead programmer does a lot less development than a developer. His level of responsibilities in the project is much lower because his strategic role comes with a lot of overhead which limits his productive time. It reaches a point where a lead that has 8+ developers basically never has any time to code anything in many cases, but he still remains very active in any conversation that involve architecture, etc.

So why does the one-page mentality help? A sheet of paper has a fixed surface. You can't fit more than its size no matter how hard you try. So if you start listing everything that you HAVE to do, and then start listing things you'd NEED to do, and end up taking more than one page, it is time to reassess all of these items to see who you can delegate them to, or how you can shift your perspective.

Let's take an example. Let's assume I'm the lead developer on a game, and a part of my 'page' looks like this:

• Make this fun feature
• Integrate the UI
• Integrate SFX
• Verify this is in-line with the recent changes to the sound manager
• Refactor core class to make it work with new tech specifications

Now, if it fits on my page, then no problem, it means I likely have the time to do this (even though it is a largely imperfect metric). If it doesn't however, and everything else looks more important, then perhaps I should better rephrase this as:

• Assign Fun Feature to Tom
• Code Review Tom's progress
• Followup with QA feedback on Tom's work

I'm now empowering someone on my team to make this feature, and to make the right decisions. I'm not telling him exactly what's required (I can give him a hint that it needs the sound and UI, but he could just as well read the GDD). It is also no longer my job to insure that my feature does what the GDD stated, but as his lead, it is my responsibility to see that his code makes sense, so I'll provide code review time to make sure that's the best possible code to make this work, provided Tom explains what he was attempting to do. I'm trusting Tom because I don't have the time to do it on my own, so it is just as critically important that I delegate the full understanding of the feature to Tom, not me, else he's just executing the work and still relying on me for everything else.

I put a note to followup with QA, and I'm assuming here that QA has a transversal white box role where they know what the feature should be, so that I don't need to have a thorough understanding of the feature's implementation to address this. If it appears the code is unstable, I can address the situation with Tom, but if it is not answering the feature properly, then Tom and I can have a chat on the expectations vs results and I can help reassess the scope.

Maybe Tom missed some of the feature, but that's a perfect moment for me to bring up that Tom should take more initiative and talk directly with the Design team, and the QA team, etc. I should foster this level of open communication because, as a lead programmer, given my current role, if I let it fall unto me, it won't get done as it won't fit my plate.

Another positive outcome of fostering open communication is that I'll end up with fewer items dropping onto my list as fewer people will feel they need to reach out to me specifically, and they will grow into more autonomous cells (artist reaches out to Tom regarding the feature, Tom inquiring to the designer, and I only ever intervene when Tom or someone else asks for my input).

Now, there are a lot of exceptions to this example, and it's just that, an example. It is perfectly possible that Tom is a junior developer, or someone that requires more followup, so in this case, I may need to break down my involvement with Tom into more steps, and see what else on my list I can reprioritize to invest move time in Tom.

As a person in a key position, my role is not to do more work, it is to insure that the others on the team get better and fill in the role I likely used to fill. But how can I correlate the time I have with the physical surface of a sheet of paper? You can't, but you can rephrase until the perceived effort of a task matches its relative footprint on the sheet of paper, and that's also good practice.

If you suspect a task will take you 5% of your time, it wouldn't make sense to break it down any further in your one-page roadmap. Any additional information stored there likely shouldn't be there, and it just makes it harder to efficiently communicate to anyone what you expect to have done in any single day. Keep it simple, bullet points.

As an example, my most recent one-page looked like this:

[PROJECT NAME] 
- Task 1: A couple words to describe the scope. (one-line) 
- Task 2: A couple words to describe the scope. (one-line) 
[PROJECT NAME] 
- Task Funnel: Task 1 => Task 2 => Task 3 (one-line) 
[PROJECT NAME] 
- Complex Task 1: List of items to consider along with a few pointers on how to best tackle this (three lines) 
- Task 2: A couple words to describe the scope. (one-line) 
- Task 3: A couple words to describe the scope. (one-line) 
- Task 4: A couple words to describe the scope. (one-line) 
[PROJECT NAME] 
- Task 1: A couple words to describe the scope. (one-line) 
	- Sub-Task 1A: A couple words to describe the scope. (one-line) 
	- Sub-Task 1B: A couple words to describe the scope. (one-line) 
		- Sub-Sub-Task 1BA: A couple words to describe the scope. (one-line) 
		- Sub-Sub-Task 1BB: A couple words to describe the scope. (one-line) 
[PROJECT NAME] 
- Task 1: A couple words to describe the scope. (one-line) 
[PROJECT NAME] 
- Task 1: A couple words to describe the scope. (one-line) 
- Task 2: A couple words to describe the scope. (one-line) 
- Task 3: A couple words to describe the scope. (one-line) 
- Open Question: Something I'm still debating whether I should be handling it, or perhaps delegate. 

This should represent the work you're expecting to get done in any single week. Personally, I edit this sheet weekly and then print. For the remainder of the week, I just annotate with a pen, and at the end of a week, I revise the original file based on what's left, what's new, etc. I always keep a 5 days outlook on what needs to get done and clean it up every Friday to avoid visual clutter from taking over. Some weeks, I clean it up twice (when things derive dramatically from the original plan for example).