Your First Planning Role — Settling Roles and Responsibilities Before You Pick a Tool

Someone who had just been handed a planning role on the business side — the seat between other business teams and engineering — sent me seven questions. What format to keep planning history in, which tool to track progress with, how to log requests from different departments, what form to use when handing work to engineering, where the role boundaries sit, what to do when nobody replies. At the end: "and any advice you'd give, unfiltered."

Each one looks like a separate question. Read together, though, they were all circling the same thing — how much of this am I allowed to decide?

When people hear "settling roles and responsibilities," they usually picture drawing lines on an org chart. But for someone sitting where requests pile up, something else is more urgent: deciding for yourself what you're accountable for, and then making sure the people around you know it. Three things, in order — intake, judgment, record. The tool can wait.

Seven Questions, One Question

Write each one again in the next column and it shows up quickly.

The question as written	What's actually being asked
Who judges an ambiguous request	Can I decide this, or do I need to escalate it
What to do when nobody replies by the deadline	If they don't answer, can I just go ahead
How to resolve priority conflicts	Can I be the one who pushes someone else's item back
What format to keep planning history in	When someone asks "why is it like this," what do I show them
How to log requests from each department	How do I make sure nothing gets dropped

Only one of the seven is about a tool. The rest are about people, authority, and agreements. And yet when you first land in this seat, shopping for collaboration software is usually the first thing you do — I did exactly that. Get the order backwards and the tool's feature set ends up deciding your responsibilities for you.

1. Intake — Dropping One Hurts the Most

The first thing you lose in this seat isn't a reputation for being good at the work. It's the quieter belief that things don't vanish when people hand them to you. Unfairly, nobody remembers the thirty you handled well, and everyone remembers the one you dropped. So intake comes first.

Many ways in, one place it lands

Requests arrive by email, by chat, and from whoever catches you in the hallway. Announcing "please send everything by email from now on" rarely sticks, because from the other person's side there's no reason it should. (I do ask for email wherever I can — it's just that telling a client or someone senior to change how they reach you isn't always an easy thing to say.)

So instead of trying to force one channel, consolidate on the receiving end. Whatever you heard in the hallway goes into the same list once you're back at your desk. Many ways in is fine. One place it lands is what matters.

Four fields will do. Who asked, when it came in, one line of what they want, and where it stands now. Design ten fields on day one and you'll usually stop opening it by Thursday.

Say you got it, within a day

Being late with the work itself is mostly forgiven. But with no acknowledgment, the person waiting has to guess alone — is it coming, was it forgotten, should I go find another route? That uncertainty eventually comes back as chasing messages.

One line does it. "Got it. This week is tight, I'll come back to you by Tuesday." I made the same point in work email etiquette, and it comes down to one thing: the work can run late, but the acknowledgment goes out within a day, with a date on it.

2. Judgment — Sort Requests Into Three Columns

"Who judges the ambiguous ones" is the question that comes up most often. It's hard to answer head-on, but splitting judgment itself into three kinds makes far fewer of them feel ambiguous.

Column	Which requests	What you do
I decide	Answerable from standards already agreed	Answer now, just note it down
I escalate	Changes cost, schedule, or priority	Package two or three options and send it up
I send back	Something the requester should have decided is missing	Point out what's missing and return it

The third column is the hard one. When you fill in what the requester left blank, the moment goes smoothly — they're often grateful for it. But if the result later turns out different from what anyone expected, nobody can say who made that call. It helps to think of sending it back not as stalling, but as putting the decision back with its owner.

Decide your criteria, and say them early

What matters here is less how you draw the criteria than when you share them.

Say "that's not really mine to decide" after a request has landed and it tends to read as ducking. Say the same sentence while pointing at criteria you shared weeks earlier and it reads as procedure. Identical words, and the timing alone changes how they sound.

So share them as early as you can. From the moment they're out there, they start working like authority — without anyone having to appoint you.

3. Record — Write It for Yourself in Two Months

There's a small trap inside "what format should planning history be in." Decide the format first and you'll usually end up building a document, and documents stop the moment things get busy. Open one two months later and the last edit date is often a long way back.

What needs to survive isn't really a document. It's the decisions. One line is enough.

10/14 · Status changes on the list are limited to owner and admin — requested by sales, accepted by engineering. For non-owners the control is hidden entirely.

Nobody reads progress updates two months later. What does come up, almost without fail, is "why is it like this?" — and answering that takes one decision, one date, and one name. How those accumulate is in how to write a decision record.

The format of what you hand engineering follows similar logic. How much detail to include, and what you can safely leave out, is covered in how business planning and engineering planning differ — with a writing guide attached that you can download and use as-is.

The Tool Comes Third

Pick the tracking tool first and its status values quietly become how your team works. If the tool has an "Under review" column, every ambiguous item ends up there, and a few weeks later nobody can tell you who owns the things sitting in it.

Once intake, judgment, and record are settled, the tool is just the container — a single spreadsheet will carry it. Leave them fuzzy and no amount of tooling stops the same questions from coming back. I've yet to see a responsibilities problem get solved by switching tools.

So start small. One table, five columns: requester, date received, request, status, next action. If it survives two months, go pick a tool then. If it doesn't survive two months, a new tool won't change much.

Share Progress Before Anyone Asks

Behind "how should I track status" there's usually "people keep asking me." But often they ask because progress is invisible, not because it's slow. Make it visible and the asking drops off.

Once a week, one line per requester. Write more than that and you'll skip it next week.

Your three requests from last week — two are with engineering, reply expected by 10/20. One is waiting on your confirmation.

One thing worth adding: don't sit on the ones that are stuck. The most expensive mistake in this seat isn't being late — it's saying you're late too late. Early, it's a schedule conversation. Late, there's something to clean up.

The same goes the other way. Ask engineering for a check and then wait quietly for their answer, and from the requester's side it looks like nothing is happening at all. Waiting is a status too, so put it in the list and share it.

Roles and Responsibilities Only Work Once People Know Them

Settle all of this and keep it to yourself and very little changes. Authority in this seat comes less from an appointment than from predictability. It starts working the moment people around you have a rough idea of what happens when they send you something.

One page is enough. Where to send requests, roughly when the acknowledgment arrives, which things get answered directly and which go up, and what happens if nobody replies. Write those four down, share them, and attach the link whenever you take something in.

Then revise it after about three months. Your first three columns will be wrong in places. Some of what you put under "I decide" should have gone up, and some of what you escalated you could have handled yourself. That correction is where the real learning in this role happens — it isn't a line you draw once, more something that settles after a few passes.

When Nobody Replies, and When Priorities Collide

Two situations that follow this seat around, and the fix is similar for both: instead of notifying people after the fact, tell them the rule beforehand.

• When nobody replies — include "if I don't hear back by the Nth, I'll proceed on the basis of X" in the original request. Saying "you didn't answer, so I went ahead" afterward sounds like a notification; following something you wrote down in advance is closer to a shared agreement. It's safer not to apply this to anything hard to reverse.
• When priorities collide — don't set the order yourself. Show the current list as it is and let the requesters choose. "Doing A first pushes B to next week. Which way would you like?" Decide for them and whoever got pushed brings their disappointment to you; show them and let them choose and the decision belongs to them.

That said, pulling out the rule the moment the deadline arrives can feel a little cold. Putting one more step in between makes it much softer: resend the same email with a Gentle reminder line on top.

Gentle reminder — just following up on the item below. If I hear back by the Nth, I can still hold the schedule.

It reads less as chasing and more as "in case this got buried." As I mentioned earlier, chasing a client or someone senior is awkward, and this one line takes a lot of that awkwardness out. The record helps too: if you do end up proceeding by the rule you published, it's no longer "I asked and heard nothing" but "I asked twice and heard nothing."

Putting off the ones you can't take usually makes the cleanup bigger. How to actually say it is in deadline negotiation.

Nobody Asked, But — Two Traps I've Walked Into

The last item on the list said "advice, unfiltered," so I'll put two things there.

First, don't answer confidently about things you don't know. Sitting between engineering and requesters means both sides' questions arrive at your desk. Answer "is this possible?" with a gut-feel "probably, yeah" and that one phrase starts traveling as a requirement — coming back weeks later as "but you said it was possible." "Let me check and come back to you today" is plenty for that moment. Admitting you don't know rarely costs you trust; giving the wrong answer costs it far more often.

Second, don't become the person who absorbs everything. If the "send back" column stays empty, you're not coordinating anything — you've become a pipe things pass through. Pipes accumulate work, not authority. Six months of kindly deciding what the requesters should have decided, and the accountability for all of it ends up in front of you. Sending things back is less a discourtesy than a part of the job.

Wrapping Up

• Intake — many ways in, one place it lands. The work can run late, but say you got it within a day.
• Judgment — sort into decide, escalate, send back, and share the criteria early. The same sentence reads as ducking after the fact and as procedure beforehand.
• Record — keep decisions rather than progress. The question that comes back in two months is always "why is it like this?"

If you only do one thing this week, draw the three columns on paper and sort last month's ten requests into them. It gets surprisingly clear which decisions you were already making, and which of those you shouldn't have been. Roles and responsibilities usually start from that one page rather than from a grand document.