Shared passwords are not collaboration.

I understand exactly why teams share passwords. In fact, I think shared passwords usually begin with a perfectly sensible instinct. There are two people working on something, both need access, and creating some elaborate permission structure feels absurd. Someone creates the account, sends the login in a message and says, “Use this one.” Ten seconds later both people can work. Nothing needed configuring, nobody had to think about roles and the product did not turn a tiny collaboration problem into an administration project.

For a while, it works extremely well.

That is probably why the problems appear later than people expect. Shared access does not usually fail dramatically on day one. It fails gradually as the number of people, actions and consequences grows around an account that still behaves as if one person owns it.

At some point someone changes a setting and nobody remembers who. A password gets changed and one person can no longer log in. A contractor finishes a project but may still know the credentials. Someone enables two-factor authentication using their personal phone. A notification arrives saying there was a login from a new device, and everybody spends five minutes in chat asking whether it was them.

None of these problems is especially exotic. They are simply what happens when several humans are represented inside software as one human.

Shared accounts work because the team supplies the missing context manually.

Imagine two founders running a small company together. They share one login for a support platform. One writes customer replies in the morning, the other checks conversations at night. They sit in the same room or talk constantly. If a setting changes, one probably knows the other changed it. If a customer receives a strange answer, they can ask each other. If the password changes, there are only two people who need the new one.

The account has no concept of two users, but the humans around it compensate. Their communication supplies identity, history and coordination outside the software.

Add another employee and this still works reasonably well. Add a fourth person working remotely and things become slightly fuzzier. Add somebody from an external agency who needs temporary access for one week and suddenly the invisible system around the shared login starts carrying quite a lot of weight.

The software still sees one account.

The business now sees five people with different responsibilities, different working hours and different reasons for being there.

Shared credentials do not remove the need for access management. They move access management into messages, memory and trust between people.

The first annoying question is usually “who changed this?”

This sounds almost trivial until the setting matters.

Maybe a notification email changed.

Maybe a support instruction was edited.

Maybe automatic top-ups were disabled.

Maybe somebody removed a knowledge source.

Maybe a billing setting changed.

Maybe the support agent suddenly started answering differently because one person modified its business context without mentioning it to anybody else.

The team sees the consequence. The account history says the account made the change.

That statement is technically true and operationally useless.

When every person enters through the same identity, the software loses the ability to answer a very ordinary business question: which person performed this action?

Identity becomes useful long before security becomes dramatic.

Team accounts are often discussed primarily as a security feature, which is fair. Individual credentials reduce password sharing and make access easier to revoke.

I think the mundane operational benefit is just as important.

If Anna changes the customer retention period, the activity history can say Anna changed it.

If Mark updates a support instruction, the business can see that Mark updated it.

If somebody accidentally removes a website, the team does not need to solve a small detective story before understanding what happened.

Identity gives actions ownership.

That becomes useful even inside teams where everybody trusts everybody.

Trust does not improve human memory.

“I think I changed that” is a terrible audit log.

People forget ordinary changes quickly because ordinary changes do not feel important when they happen.

Imagine someone adjusts a support instruction on Tuesday. At the time it seems like a tiny improvement. On Friday another person notices that customers have been receiving a different explanation for three days.

Nobody remembers the exact wording before the change. The person who edited it vaguely remembers doing something but cannot remember whether it was Tuesday or Wednesday. Another teammate thinks they may also have touched the same section.

A proper account history turns this into a thirty-second investigation.

Shared access turns it into group memory.

Group memory is surprisingly unreliable for things nobody expected to matter later.

Then somebody leaves.

This is where shared credentials stop being merely inconvenient and start creating genuinely awkward questions.

An employee leaves the company.

They knew the shared password.

What now?

Change it.

Fine.

Now every remaining person needs the new password. Every saved login becomes outdated. Maybe somebody stored the old credentials in a browser. Maybe a scheduled process somewhere used them. Maybe two-factor authentication belongs to another person. Someone needs to make sure all of this still works.

If individual accounts existed, removing one person could have been exactly what it sounds like: remove one person.

Shared access makes departure a credential migration.

Contractors make the problem obvious much sooner.

Permanent employees at least have an ongoing relationship with the company. Contractors, agencies and temporary collaborators expose the weakness of shared accounts almost immediately.

Suppose a company hires somebody for a two-week implementation project. They need access to the support dashboard to configure a website and verify that everything works.

With a shared account, the easiest thing is to send them the same credentials everybody else uses.

They now have whatever access that account has.

Perhaps that includes billing.

Perhaps customer transcripts.

Perhaps private knowledge.

Perhaps team settings.

The contractor needed one part of the product.

The shared account gave them the whole account because there was no other identity available.

This is where permissions stop feeling like enterprise bureaucracy.

Permission systems can become ridiculous. I have used products where inviting one teammate feels like configuring access to a nuclear facility. There are fifteen roles, dozens of toggles and enough terminology to make you wonder whether you understand your own company.

That is not what I mean by useful team access.

Small businesses often need something much simpler.

This person can manage the account.

This person can work with support conversations.

This person can edit knowledge and configuration.

This person should not change billing or remove other team members.

The exact categories depend on the product, but the basic idea is ordinary: people should receive enough access to perform the job they actually have.

Shared credentials make that impossible because everyone becomes the same user before the product even begins thinking about permissions.

One shared password quietly creates an administrator out of everybody.

This is one of the stranger consequences.

The company may have clear roles in real life.

One person handles billing.

Another manages customer support.

A developer only touches implementation.

A founder controls account ownership.

Then they all sign into the same software account.

Inside the product, every distinction disappears.

Everyone can usually do whatever the original account holder can do.

The software has accidentally flattened the organisational structure of the company into one universal administrator.

Most people do not misuse access. Mistakes are enough.

Security conversations sometimes make permissions sound as if the primary concern is malicious employees intentionally doing terrible things.

That can happen, but ordinary mistakes are much less dramatic and much more relatable.

Somebody believes they are editing a test website and changes production.

Someone removes something they thought was unused.

A person unfamiliar with billing turns off a setting because they do not understand what it controls.

Somebody exports customer data while trying to find a single conversation.

Permissions can reduce the number of dangerous buttons presented to people whose job does not require those buttons.

That is useful even in the friendliest company in the world.

Individual accounts make mistakes easier to fix too.

Knowing who performed an action changes the recovery process.

If a setting suddenly looks wrong and the history says Alex changed it fifteen minutes ago, somebody can ask Alex what they were trying to achieve.

Perhaps the change was intentional.

Perhaps they misunderstood the setting.

Perhaps another related change still needs to happen.

Identity provides context around the action.

Without it, the team knows only that the account changed.

Repair becomes harder when you do not know the intention behind the thing you are repairing.

Two-factor authentication becomes weird very quickly on a shared account.

Shared passwords already create coordination overhead. Two-factor authentication adds a physical person back into the login process.

The verification code goes to somebody’s phone.

Now a teammate trying to log in at home sends: “Can you send me the code?”

The account owner is in a meeting.

The code expires.

Another one is requested.

The phone receives three notifications and somebody wonders whether one of them is suspicious.

Security technology is doing exactly what it was designed to do: tie access to a real identity or device.

The shared-account workflow is fighting that design every time another person tries to enter.

Then someone starts sharing the second factor too.

Humans are excellent at removing friction from systems placed in front of their work.

If two-factor authentication makes the shared account annoying enough, the team will naturally look for ways around the annoyance.

Maybe backup codes go into a shared document.

Maybe everybody uses the same authenticator seed.

Maybe authentication is disabled because coordinating it became too irritating.

The security feature did not fail.

The account model created incentives to weaken it.

Individual identities align the security model with how the team actually works. Each person authenticates themselves instead of collaborating on pretending to be one person.

Password managers improve sharing, but they do not create identity.

A good password manager can make shared credentials much safer than passing them around in Slack, email or some ancient document called “COMPANY LOGINS FINAL”.

It can control who receives the credential. It can generate strong passwords. It can revoke access to the stored copy when someone leaves.

These are real improvements.

The application still sees everybody as the same account.

Its activity history still cannot identify the person.

Permissions still cannot differ by teammate.

Sessions still belong to the same identity.

Removing somebody from the password manager also does not guarantee they never memorised, copied or saved the credential elsewhere.

Password managers solve password handling extremely well.

They cannot add a team system to software that only understands one user.

Collaboration needs identity because responsibility needs identity.

When several people work in the same system, there is usually some concept of responsibility even if the company is very informal.

Someone answered this customer.

Someone updated this policy.

Someone invited this teammate.

Someone changed this configuration.

Someone approved this action.

Individual accounts let the software preserve those relationships.

This becomes increasingly useful as work moves asynchronously. If everyone is standing around one desk, you can ask who changed something. If the team spans cities, countries or time zones, the person who made the change may be asleep.

The activity history becomes part of team communication.

Support conversations make ownership especially useful.

Consider a customer conversation that spans several hours.

One teammate answers the initial question. Another handles a technical follow-up. A third person later reviews the conversation because the customer asks for a billing adjustment.

If every message appears to have been sent by the same shared account, the internal history loses information about how the conversation actually moved through the team.

Individual identities can show who participated and when.

This can help somebody reviewing the conversation understand why the style changed, who already knows the technical background and which teammate should be asked about an earlier decision.

The customer does not necessarily need to see every internal detail.

The business benefits from having it.

“Who is handling this?” is another question shared accounts answer badly.

Imagine two support employees open the same new conversation around the same time.

Neither knows the other is looking at it.

Both begin writing a response.

One sends.

The other discovers the conversation was already answered.

At small scale this is mildly annoying.

At larger scale, teams start inventing external coordination systems.

“I’m taking this one.”

“Anyone responding to #184?”

“Leave the billing ones for me.”

Proper team identity creates room for assignment, presence and ownership features later. The product can understand that different humans are participating instead of forcing the humans to coordinate around an account that pretends they are one.

Individual access does not need to make support less collaborative.

I think some teams resist individual accounts because a shared login feels communal. Everybody sees the same thing. Nobody owns a conversation too strongly. Anyone can jump in.

Separate identities do not have to destroy that.

The shared workspace can remain shared.

Everyone can still see the conversations their role allows.

Teammates can still help each other.

The difference is that the workspace knows which person is doing the work.

Collaboration should mean several identified people working on shared things. It does not require several people impersonating the same account.

Roles are most useful when there are only a few of them.

Permission systems tend to grow because every customer eventually asks for one more distinction.

Before long, the product has twelve roles with names such as Administrator, Manager, Editor, Operator, Analyst, Contributor, Viewer and Limited Viewer, and nobody remembers whether a Manager can remove an Editor.

I think simple software should resist this until complexity has earned its place.

A small team may only need a few meaningful boundaries.

Someone who owns and manages the workspace.

Someone who can work with support and configuration.

Perhaps somebody who can view conversations without changing the account.

Start with distinctions users can actually explain.

Fine-grained permissions can grow later if real businesses reveal real reasons for them.

Permissions should follow consequences.

A useful way to decide what deserves a separate permission is to ask how much damage or confusion an accidental action could create.

Reading an article draft and deleting a workspace are very different actions.

Editing support instructions and changing the company’s billing method have different consequences.

Viewing a conversation is different from exporting thousands of them.

Products do not need a permission toggle for every button.

They should pay attention to actions that change ownership, money, security, customer data and critical configuration.

That keeps the permission model connected to actual risk instead of turning it into taxonomy for its own sake.

Billing is one of the easiest boundaries to understand.

Plenty of people need to use software without needing to change how the company pays for it.

A support employee may need conversations and knowledge.

They probably do not need to change the company card.

A developer implementing the widget may need site configuration.

They probably do not need to cancel the subscription.

When one shared administrator account is used for everything, the product cannot represent these perfectly ordinary boundaries.

Proper team access lets boring business structure remain boring.

Customer data is another obvious boundary.

Support systems naturally contain information about customer conversations.

Depending on the business, those conversations may contain account details, transaction questions, contact information or whatever customers decide to paste into a text box that afternoon.

Not every person who needs access to configure the product necessarily needs access to all of that history.

An external developer may need to verify installation.

A designer may need to adjust the widget appearance.

Someone managing invoices may need billing access.

Giving everyone a shared owner account eliminates the possibility of making these distinctions.

Access minimisation is useful even when every person involved is completely trustworthy. People should not need to receive sensitive information merely because the product bundled unrelated responsibilities into one login.

Temporary access should feel temporary.

I like systems where inviting somebody for a short job does not create a cleanup problem six months later.

An agency helps with implementation.

Invite the relevant person.

Give them the access needed.

The job finishes.

Remove them.

The remaining team continues with their own credentials unchanged.

No global password rotation.

No wondering whether somebody saved the old login.

No breaking everybody else’s sessions because one relationship ended.

This is a much cleaner mapping between the real-world relationship and the software relationship.

Offboarding is boring until the day it suddenly matters.

People naturally spend more time thinking about how someone joins a product than how they leave.

Invitation screens are visible during growth.

Removal is an occasional administrative task.

When somebody actually leaves a company, though, the product needs to make the answer clear.

Remove their account.

Their access ends.

Their previous actions remain attributed to them in the history.

The conversations they worked on remain part of the workspace.

Ownership of anything requiring an active user can be reassigned if necessary.

The business should not have to erase history in order to remove future access.

This distinction between identity and content matters.

Suppose an employee answered five hundred customer conversations and then leaves.

Removing their access should not make those messages appear anonymous.

The historical record still benefits from knowing who handled them.

Their account can become inactive while their past actions remain part of the workspace history.

That is another thing shared logins cannot express.

There was never an individual identity to disable while preserving attribution.

Team access makes notifications much less ridiculous.

Shared accounts often produce shared notification problems.

Which email address belongs to the account?

The founder’s?

A generic support inbox?

Whoever happened to create the account two years ago?

One person gets every notification and forwards the relevant ones.

Or everybody accesses the generic inbox.

Or notifications are disabled because the wrong people keep receiving them.

Individual accounts allow notifications to become personal preferences.

The person handling support can receive support alerts.

The account owner can receive billing and security notifications.

Somebody who only checks analytics does not need to hear about every new conversation.

This seems like a small quality-of-life improvement until the company has enough activity for notifications to become real noise.

Security notifications become useful only when identity means something.

“New login from Chrome on Windows.”

Shared account.

Four people use Chrome on Windows.

Great.

Now the team begins the ritual: “Was this anyone here?”

Individual accounts make the event understandable.

“New login to Anna’s account.”

Anna can recognise it or report that it was not her.

Security monitoring depends on knowing which identity is expected to perform an action.

A permanently shared identity weakens that signal.

Session management becomes useful for the same reason.

Suppose one employee loses a laptop.

With individual accounts, revoke that person’s sessions.

Everybody else keeps working.

With one shared account, the business may need to log everybody out and rotate credentials because there is no way to separate the lost device from all the legitimate devices.

Again, the technical problem comes from the account model representing several people as one.

Shared passwords also create very strange ownership.

Who owns the account?

The person whose email address was used?

The company paying the bill?

The person with access to the two-factor authentication device?

The person who knows the password?

Usually everyone involved understands informally that the account belongs to the company.

The software may still be anchored to one person’s email and recovery methods.

This becomes particularly awkward when the person who originally created the account leaves.

A proper workspace model lets the organisation remain while individual members come and go.

That feels much closer to how businesses actually exist.

The workspace should outlive any individual user.

I think this is the conceptual shift that makes team software much cleaner.

The company has a workspace.

People belong to it.

Websites, conversations, knowledge, billing configuration and other shared resources belong to the workspace.

Individual people receive access according to their role.

One person can leave without taking the workspace with them.

Another person can become the owner.

The business remains the stable object.

This architecture sounds obvious once a product has teams. Shared accounts often begin precisely because the original product was designed around one user before the business using it grew beyond one user.

Team features reveal whether a product thinks in people or companies.

A single-user product naturally asks: who are you?

A business product eventually needs another question: which organisation are you acting inside?

One person may belong to multiple companies or workspaces.

An agency employee may manage several clients.

A contractor may temporarily belong to one project.

A founder may own one company and be invited into another.

Once identity and workspace are separate concepts, these situations become possible without credential gymnastics.

This matters even for very small companies.

Team access can sound like something a company needs after reaching fifty employees.

I think two people are already enough.

Two people can make different changes.

Two people can need different notifications.

Two people can leave at different times.

Two people can benefit from knowing which one answered the customer.

The feature becomes more valuable as the company grows, but the underlying distinction appears the moment a second human needs access.

Small teams deserve simple team management.

The danger is responding to all of this by building an administration console that becomes more difficult than password sharing.

If inviting one teammate requires reading documentation about permission inheritance, the product has solved the original problem badly.

A normal setup should be obvious.

Enter email.

Choose an understandable role.

Send invitation.

The person creates their own login.

Done.

Complexity should appear only where the business genuinely needs more control.

The default path should beat sending the password in a message, otherwise people will keep sending the password in a message.

Good security often succeeds by being easier than the insecure workaround.

This is an important product lesson beyond team accounts.

People are trying to get work done.

If the secure path creates too much friction, they will invent another path.

If inviting a teammate takes ten seconds, there is little reason to share a password.

If revoking access is one click, there is little reason to postpone it.

If each person can set up their own authentication, the team does not need to coordinate codes through chat.

A product can encourage better behaviour simply by making better behaviour the obvious option.

Activity history should answer questions, not become surveillance theatre.

Once individual identities exist, it becomes possible to record enormous amounts of activity.

Every page viewed.

Every button clicked.

Every minute online.

That does not mean a useful audit history needs all of it.

I care about meaningful actions.

Someone changed a critical setting.

Someone edited business knowledge.

Someone invited or removed a teammate.

Someone changed billing.

Someone performed an action affecting customer support.

An audit trail should help reconstruct important events.

It should not become a creepy productivity tracker simply because identity now makes tracking technically possible.

Accountability works better when it does not feel punitive.

“We log who changed settings” can sound like management watching employees.

In a healthy team, the main benefit is often collaborative.

You see that somebody changed the setting.

You ask them why.

They explain the customer problem they were solving.

Maybe the change was correct.

Maybe the documentation also needs updating.

Attribution creates a path to context.

It does not have to create blame.

Support content especially benefits from knowing who edited it.

Knowledge changes over time.

Somebody updates a cancellation rule.

Someone rewrites a plan explanation.

A new internal instruction is added.

If an answer later looks strange, knowing when and by whom the underlying information changed is extremely useful.

The editor may remember why.

There may have been a product change not yet reflected elsewhere.

A typo may have introduced the problem.

Shared accounts erase this breadcrumb.

Team access also makes approvals possible later.

Small companies may never need an approval workflow.

Larger teams sometimes do.

Perhaps junior support staff can draft changes to public knowledge while a manager approves them.

Perhaps certain customer actions require a person with a higher role.

Perhaps changing billing or deleting a workspace deserves additional confirmation from an owner.

None of this can exist sensibly until the product knows which human is which.

Identity is foundational infrastructure for collaboration features the business may not even need yet.

The goal should still be to keep most work unrestricted.

Permissions can make teams safer.

They can also make software unbearable if every ordinary action requires an administrator.

If someone has been invited to handle support conversations, they should be able to handle support conversations.

If every useful action produces “Ask your workspace owner,” the permissions are protecting the product from its own users.

Restrictions should focus on boundaries that genuinely matter.

Everyday work should remain everyday work.

Invitations should not create mysterious half-users.

Team systems have their own little edge cases.

Someone is invited.

They do not accept for three weeks.

Does the seat count?

Can the invitation be cancelled?

What if the wrong email was used?

What if the person already has an account?

What if they belong to another workspace?

These details become part of the product experience once team access exists.

Good implementation should make the states obvious: invited, active, removed.

People should not need support to understand whether somebody currently has access.

The workspace owner needs a recovery path.

Individual accounts solve many problems, but they also introduce the need to think carefully about ownership.

What happens if the only owner loses access?

What happens if their email is no longer available?

Can ownership be transferred before they leave?

Can a company have more than one high-trust administrator?

These questions are less visible than the invite button, but they matter because the workspace represents business property.

A good team system should avoid making the entire company dependent on one fragile personal login while still protecting ownership from casual transfer.

Team access is partly about continuity of the business.

People change jobs.

Contractors finish projects.

Founders hand responsibilities to employees.

Employees go on holiday.

Agencies are replaced.

The software should survive these ordinary organisational changes.

If every transition requires sharing, rotating or recovering one master credential, the account is tied too closely to an individual identity.

Workspaces let the company remain stable while the people around it change.

This matters for support because support rarely belongs to one person forever.

A founder often handles early support personally.

That makes sense. Early customer questions are valuable product research, and the founder knows the product better than anyone.

Then the company grows.

Somebody else begins helping with conversations.

Eventually support becomes part of another person’s job.

Maybe a small team forms.

The support system needs to survive that evolution without forcing the original founder to remain the permanent password distributor for the company.

Team access is part of allowing a product to grow with the business using it.

This is why team access belongs in Reesponder even though it is less exciting than AI.

If you make a list of features that sound impressive in a demo, individual team accounts are not going to beat an AI support agent answering a difficult customer question.

I still consider them important.

Reesponder is supposed to be used by real businesses. Real businesses eventually have more than one person who needs to see conversations, adjust knowledge or manage the workspace.

If the product forced all of those people through one owner login, it would undermine a lot of the control we are trying to give the business elsewhere.

So the workspace should remain shared while the humans inside it remain identifiable.

It is one of those features that should feel completely unsurprising when it works properly.

The less interesting a team feature feels, the better it may be doing its job.

Nobody wakes up excited to revoke a former employee’s access.

Nobody buys support software because the invitation screen is beautiful.

Nobody wants to spend Friday afternoon designing a permission model.

These are background mechanics that keep the interesting work from becoming messy later.

Invite a teammate.

They use their own login.

Their actions have their name.

They receive the access their work requires.

When they leave, remove them.

The workspace continues.

If the team barely thinks about any of this, the product probably got it right.

Shared passwords often survive because nobody feels the pain at the same moment.

This is why the habit can last for years.

One person gets annoyed by two-factor codes.

Another notices the missing audit history.

Someone else worries about the contractor who still knows the password.

A fourth person gets logged out after a credential rotation.

Each individual problem is small enough to tolerate.

The total system is worse than any one person experiences at once.

Team accounts collect those scattered annoyances and solve them at the model level: each human becomes a human.

The security benefit is almost a side effect of making the model honest.

Four people use a product.

Give the product four identities.

Now access can be granted individually.

Authentication belongs to individuals.

Sessions belong to individuals.

Actions belong to individuals.

Removal affects one individual.

Permissions can differ by individual.

Security improves because the technical model finally resembles the real situation.

A lot of good security comes from accurately modelling who is actually doing what.

There is still room for shared resources.

Individual identity does not mean every part of the product becomes private.

The knowledge belongs to the company.

Conversations belong to the workspace.

Website installations belong to the workspace.

Business configuration belongs to the workspace.

The team works on these things together.

Individual accounts answer a different question: which member of the team is currently acting on the shared resource?

That is collaboration.

Shared object, separate people.

The distinction becomes obvious if you imagine a physical office.

A company may share a meeting room.

That does not mean every employee uses the same name badge.

People share documents.

They do not need to share identities.

They work on the same customer account.

The company still knows which employee spoke to the customer.

Software sometimes makes shared identity feel natural simply because passwords are easy to copy.

The real-world equivalent would look ridiculous.

This is one of those features you appreciate after the first awkward incident.

Before anything happens, a shared account feels simpler.

Then somebody leaves and you have to rotate the password.

Or somebody changes a configuration and nobody knows who.

Or a contractor still has access three months later.

Or a security notification appears and four people all say it was not them.

Suddenly the apparently boring team system starts looking less like unnecessary complexity and more like basic plumbing.

Good plumbing is rarely exciting.

You notice it when it is missing.

I would still choose simplicity over maximum control for most teams.

There is a danger in learning all these lessons and deciding the answer is a giant enterprise identity system for a three-person business.

That would miss why shared passwords were attractive in the first place.

They are simple.

Team access needs to preserve as much of that simplicity as possible.

Invite somebody.

Give them an obvious role.

Let them work.

Record meaningful actions.

Remove access cleanly when necessary.

Add complexity only when the business has a reason to ask for it.

If the team-management feature needs its own training session, something has gone wrong.

A good collaboration system should disappear into ordinary work.

One teammate answers a conversation.

Another sees what happened later.

Somebody updates knowledge and their name appears beside the change.

A founder manages billing without exposing billing controls to everyone.

A contractor receives temporary access and disappears from the workspace when the project is finished.

Nobody has to coordinate a master password.

Nobody has to ask which phone received the login code.

Nobody needs a Slack poll to identify who changed a setting.

The team thinks about the customer and the work instead of the mechanics of being several people inside software.

Collaboration begins when the product understands that a team can share the work without sharing an identity.

The password was never really the problem.

That is probably the part I find most interesting.

You can make the shared password incredibly strong.

Store it in an excellent password manager.

Rotate it regularly.

Protect it with two-factor authentication.

None of that changes the central mismatch.

Several people are working.

The software sees one person.

Once the product understands the team properly, many of the surrounding problems become much easier to solve because they finally belong to the right identities.

Shared passwords are a shortcut that eventually reveals what the product was missing.

I do not think teams should feel stupid for using them.

They are often the most efficient answer available at the beginning.

A two-person company does not need to stop working while somebody designs a permission strategy.

The shortcut becomes a problem when the product keeps requiring the shortcut after the organisation has clearly outgrown it.

At that point the business needs individual access, understandable roles, attribution, clean removal and a workspace that belongs to the company rather than whichever person happened to create the original login.

None of this is especially glamorous.

That is fine.

Some of the most useful software features are the ones that prevent a very boring problem six months before anybody knows they are going to have it.