How do I run hackers or netrunners without splitting the party?

Keep the hack inside the shared scene

A hacker can work alone in the fiction without leaving the other players waiting. Avoid: several private hacking checks → invisible progress → private resource loss → everyone else waits. Prefer: specialist choice → visible consequence → crew decision → changed options for the hacker.

Keep the game's hacking procedure intact. Change how you frame the scene and cut between characters, not the specialist mechanics that make the hacker distinct. Shared play means the other characters get decisions and consequential actions; they do not all need hacking rolls. The hacker keeps ownership of the specialist problem.

Start with what the crew needs in the physical scene: a door opened, a camera blinded, evidence copied, or a lift released. Map only the network elements that can change play, then make those changes visible to the crew.

Use this scene loop

• Choose The hacker makes a meaningful specialist choice.
• Resolve Use the game's own hacking rules.
• Show Make the change visible in the physical or shared situation.
• Respond Let another character react or change access, security, or time.
• Return Go back to the hacker when that response changes their options.

Give the intrusion a shared objective and pressure

Before play, set four things the table can grasp quickly:

• The target Name the physical result the crew wants: open the archive door, copy a record, blind a camera, or stop a remote transfer. Avoid giving the hacker an unbounded goal such as taking control of the whole network.
• The obstacle Choose what makes the approach uncertain: missing credentials, a segmented system, an exposed access point, or security that notices unusual activity. The hacker decides how to tackle it using the game's rules.
• The response Put a visible response in motion: a guard checks the access panel, an operator reviews an alert, or evidence starts moving off-site. Use a clock or alarm track if the game has one; otherwise describe what changes as pressure rises.
• The result Decide what success changes and what failure or partial success risks. A denied door, a dead camera feed, a trace on the terminal, or an alert reaching a patrol gives the crew something to react to.

Cut between the hacker and the crew when the situation changes

After a hacking result changes the situation, turn to the crew while that change is live. An alert gives the scout a patrol to track; an unlocked door gives the infiltrator a route; a physical cable gives the technician a choice. Return to the hacker when the crew's response changes access or pressure.

Cut when a result creates a risk, reveals a choice, or changes what someone can do, not after every roll. Keep any structured hacking procedure or initiative order the game uses.

Give the physical crew ways to affect the hack

Give the crew consequential actions around the intrusion, while the hacker makes the digital choices:

• Create access An infiltrator can reach a terminal, steal a credential, or keep a service hatch open. That changes the hacker's options; it does not mean the infiltrator solves the digital obstacle with a second roll.
• Manage the physical response A face can misdirect the operator, a scout can track the patrol, or another character can hold an alarmed door. These actions change access, security, or time; they do not require another hacking roll.
• Protect the connection A technician can keep power on, hide the terminal, or choose whether to disconnect an exposed device. Give each option a consequence the group can weigh.
• Act on what the hack reveals When the hacker finds a route, name, or vulnerability, ask what the crew will do with it: use it, preserve it, or leave before security closes in.

Keep both competence and consequence in play

Let success matter: if the hack opens a route or exposes information, do not add the same barrier again to keep the hacker busy. Give the crew the next decision, such as which evidence to take or how to handle the person who noticed.

Let failure change the situation, not disappear into a private resource cost. An alert can bring a guard closer, a partial copy can reveal the missing file, or an access point can be burned. Follow the fiction and the system's rules; keep the hacker capable and let the player choose what to risk.

Use a solo hack when the result matters to the group

A solo hack is fine when it returns quickly to the group as a changed situation, actionable discovery, or shared decision. It can fit when only the hacker has access or the crew has another task under pressure. State what the intrusion can change and what is at risk, then use the game's procedure. If it takes more than one exchange, give the others concurrent work and cut in when their actions can change access or security.

Ask how much hidden information the players want before running private details. The hacker can keep a discovery from their characters without making the other players sit through a long sequence of unseen results.

Before you run a hacking scene

• What physical goal does the crew want, and what meaningful specialist choice can the hacker make?
• What obstacle makes the approach uncertain, and which game rules resolve it?
• What will visibly change in the shared situation after the result?
• How can another character change access, security, or time in response?
• What new options or risks should that response give the hacker?
• If the hacker acts alone, what actionable result will quickly return the scene to the group?