Every once in a while we get an email from a customer asking about how permissions work with our products. They’re almost always asking how to prevent someone from doing something. “How do we prevent someone from posting a message or adding a to-do or downloading a file? How can we make our project site read only except for a select few?”
When we set out to build Basecamp we decided that it was going to be about communication, not control. It is our belief that when you collaborate with trusted parties it’s important for people to be able to communicate any way they see fit. Preventing someone from saying or doing something often breaks these free flowing communication channels and introduces miscommunication or silence—two cancers of collaboration.
We do have some permissions in Basecamp. There are some basic controls over who can do what, but as far as products like Basecamp go, Basecamp would be considered among the least controlling. If we started all over today we’d probably have even less permissions and less controls. Some of the controls we’ve put in place have turned out to make collaboration harder, not easier.
Back to the customers… When they ask how to prevent people from doing this or that I usually reply with something like “Have you tried asking them not to do this or that? If you don’t want them to upload files just ask them not to. If you don’t want them to create to-do lists just ask them not to. Communicate with them as you would if you weren’t using software.”
And to my delight, their replies are usually “Great idea! I hadn’t thought of that. I’ll try that and see how it works.” Follow-up emails usually come back as success stories.
Simply communicating with people about your expectations of their behavior is often the simplest and most effective solution. It’s respectful, it’s kind, it’s fair. And if someone does something you didn’t want them to do just remind them politely that they weren’t supposed to do that. They’ll almost always get it the second time.
So next time you are looking for more control, consider more communication. It may surprise you.
Merul
on 15 Feb 07I’m almost 99.999% certain your posting is in connection with my email yesterday.
I’d also be entirely happy to agree for you, except for one thing. Basecamp currently doesn’t inform anyone, anywhere of changes made to the date or details of a milestone. Heck, I can even delete complete milestones/todos and no visible notification seems to exist.
It’s great to see when To-Dos/Milestones are done/completed in the Dashboard, but it’d also be good to know about changes to the important info.
After all, there’s no way you can communicate with someone if you don’t know there’s something that needs communication about, no?
Jason
on 15 Feb 07Here is a basic problem with that approach: effort.
Effort is needed to communicate that fact, and that usually only comes AFTER an inciting incident.
Permissions are a rather critical aspect to most systems, especially business (re: enterprise) systems. I do realize that basecamp is in no way enterprise ready, but you should not trivialize the need for permissions simply because you eschew the corporate viewpoint.
Your overall point is a great one: communication is key. However, the approach you chose is one that does not scale and does not allow for growth. Basecamp basically is setting companies/people up to NOT grow/succeed. Think about that for a minute.
Cid
on 15 Feb 07I agree with this approach. I’ve found that communicating these things are essential. Other tips I have for increasing communication: 1)Tell people what ‘to-do’ for the project (they can write it on a notepad!) 2)Have them just tell you how much time they spend on project tasks and milestones (you can write that on a notepad) 3)”Messages” and “comments” are best conveyed in person, face to face or in team meetings (have pizza!) 4) Put files and data on a CD and walk it over to people. This way you ensure only the intended recipients get it.
Simple!
Eddie
on 15 Feb 07That last sarcastic remark was by me, not “Cid”
JF
on 15 Feb 07However, the approach you chose is one that does not scale and does not allow for growth. Basecamp basically is setting companies/people up to NOT grow/succeed. Think about that for a minute.
I’m not sure where you are getting your information, but plenty of companies are succeeding with Basecamp. That’s why people use Basecamp—to help them succeed with their projects. We hear from them all the time. Basecamp allows them to grow and take on more work than they could without Basecamp. Basecamp helps them grow their business.
Our attrition rates are very low by all standards and the vast majority of our business comes from word of mouth referrals. If we were setting our customers up for failure I don’t think we’d be hearing what we’re hearing, seeing what we’re seeing, and growing how we’re growing.
A final note: We’d rather our customers eventually grow out of our products than never be able to grow into them in the first place.
Michael
on 15 Feb 07That’s a great philosophy when everyone you are dealing are mature adults. Basecamp and similar products are used by such individuals.
Throw in some people who do not respect or understand boundaries (i.e. kids and immature adults) and you are going to have to rethink that position.
Scott
on 15 Feb 07Sorry, but that’s a bit naive in the real world, especially when dealing with clients remotely whom you may never have met in person. Account managers give access to PAs, PAs go home and access with the family computer, Junior logs on later because of browser autofill and makes a mess of the Basecamp files.
It happened to me exactly that way. It is never as simple to just say, ‘please don’t’. The more people with access, the less one can always feel confident that ALL information in Basecamp retains its integrity. There definitely needs to be the ability to grant some people read-only.
Offices are filled with politics, and uncontrolled access to ALL files and information is simply foolish. Some people may need review rights, but they don’t need write rights.
’’Just say ‘no’’’ doesn’t work.
Dan
on 15 Feb 07Michael, I wouldn’t want to create a product to work in an environment where people do not respect boundaries. That’s a people problem. You can’t solve that with technology.
brad
on 15 Feb 07I agree that communication is intuitively an easy way to deal with this issue, and yet in my experience people frequently forget. Not only that, but if there’s a lag time between when you communicate your “rules” to them and the time they actually get around to using the site or product, you can pretty much guarantee they’ve forgotten.
I work with a team of other consultants on a project and we’ve been using Lotus QuickPlace for sharing files (because my company already uses QuickPlace, as does our client in this case). I gave everyone very clear instructions about how to post files and how not to post them, and I’d say half the people have posted them the wrong way, simply because they don’t use the site often enough to remember my instructions (even though they are included at the top of every page on the QuickPlace!).
Controls can be a benefit to busy users because they don’t have to keep instructions in their head. In the old days of DOS, everyone had these weird arcane instructions in their heads, “autoexec bat” etc., and there were commands that they had to remember NOT to use because they could accidentally wipe out files if they invoked them. The reason the Mac (and later Windows) interface was such an improvement was because it allowed the computer to remember all those commands. You the user didn’t have to keep them in your head. And users became more productive and less error-prone because of it.
Frankie Roberto
on 15 Feb 07Great post. Complicated permissions would be inappropriate for tools like Basecamp and would just make it harder to use.
Indeed, one question I’ve been meaning to find out is why it’s sometimes impossible to edit someone else’s todo – ie when you get a red dot rather than a checkbox?
I do agree that there needs to be more version-tracking though. If various people move a milestone over the course of a project, perfectly legitimately, it would be good to know what the original date was (so we can keep track of just how late a project really is ;-) )
Frankie
Anonymous Coward
on 15 Feb 07Post Script: I can’t count the number of times I’ve avoided Basecamp because I can’t control read-write permissions. I’ve used it with very small companies with whom I have a personal relationship with each individual, but for bigger companies scattered remotely, forget it. Reality requires permissions.
Eddie
on 15 Feb 07reality…and sometimes Audits and lawyers and the like, especially when dealing/collaborating with anyone outside your company.
JF
on 15 Feb 07a bit naive in the real world
Ahh, the real world. I assume that’s your world. I must live in the fake one.
The actual reality is the all our worlds are the same. People are people. Be cool with with them, treat them with respect, communicate clearly, be polite when you ask them to do (or not to do) something and you may be pleasantly surprised.
When you treat people as enemies and adversaries right off the bat (“remote clients I’ve never met” must be evil terrible thoughtless people who would never listen to anything you have to say) then you are going to get exactly what you think you are going to get.
Scott
on 15 Feb 07JF: The real world of corporations is one in which ‘just say no’ doesn’t work. Trust me. I’m an optimist and a believer in people. But I have worked with large corporations and the reality is the projects are political footballs, and many people have agendas that could affect files in Basecamp.
Moreover, if you’ve ever worked on an international project involving people from half a dozen widely divergent cultures, the issues of permissions is absolutely essential. ‘Just say no’ assumes certain cultural premises that don’t exist universally.
Take, for example, a technical project that requires the marketing department to keep track of work so that they can modify their own timelines. They should have read permission. It just takes one idiot (or someone who feels it is their right to modify files) who is not involved in the technical project to mess up a critical document that affects all work. This is especially true if Basecamp is being used as the repository for master versions.
B
on 15 Feb 07If you are using Basecamp as a broadcast tool then you are using it for the wrong thing. Basecamp is a collaboration tool. It’s mean to be used by the people participating in a project, not just read by casual bystanders.
For those clamoring for READ-ONLY-ACCESS (loud echoing sound in the corridors of the BIG CORPORATION): Don’t fault the tool if you are using it for the wrong thing. And certainly don’t fault the tool for your own personal communication shortcomings. Blame the people not the software. Software doesn’t cure people of their immature attitudes.
RS
on 15 Feb 07This seems to be a lively topic :)
It’s true that some people find themselves in an environment full of politics and mistrust. Fortunately a variety of products exist to serve those who want to stay on that path.
If someone works in an environment of mistrust, it’s natural for them to bristle at a tool built to share and communicate.
It remains open to every person and every organization to set their priorities and choose tools that fit them.
Chris Carter
on 15 Feb 07I think the bottom line is something that the folks at 37 signals have harped on time and time again – their products are meant for THEIR use. If your use happens to match their use, then they’ll work great. 99% of the time this works for small companies or small teams. Otherwise there are plenty of other fish out there.
If your business model is such that you want to store sensitive data in a segregated and secure manner, Basecamp probably isn’t for you. But realize that the vast majority of companies really don’t need that level of control.
However, there are still those that do. My company creates such a product for large companies who have a high risk of corporate espionage or deal with plenty of third parties who absolutely cannot be allowed to view or use each other’s data. It has nothing to do with “protection from evil”, but rather eliminating any chance that the wrong information can make it into the wrong hands, whether by accident or malicious intent.
JF
on 15 Feb 07Chris Carter, AKA “The Voice of Reason”
Thanks for chiming in Chris.
And just to be clear, Basecamp does have basic permissions. You can specify who can see which projects and what clients can do in those projects. So if you don’t want a client to know about a project you are working on you can make sure they don’t see any trace of that project. You can even make some basic information inside a project private to someone who has access to the project as a whole.
My point was more about more granular permissions and relying too much on software for control. Demanding control. Saying you can’t get anything meaningfully done without such controls. Suggesting that in the “real world” there’s only one way of doing things and it involves software dominating personal interaction and common courtesy. Suggesting that the bonds between people are too weak to be trusted by default.
In our eyes communication trumps control most of the time which is why we build Basecamp upon that foundation. Your mileage may vary, of course.
Anyway… Back to finishing that product we’re working on.
brad
on 15 Feb 07Totally agree with Chris—in fact I use Basecamp for one project where we have open communication and a tight team, and it’s perfect for that. I use other Quickplace for projects where I need more flexibility and more control, and it works perfectly for that.
When you need a hammer, use a hammer, when you need a screwdriver, use a screwdriver. Don’t try to talk the hammer manufacturer into turning it into a Swiss Army Knife.
beto
on 15 Feb 07For me, it all comes down to scale. Your philosophy, being yourselves a small team, no doubt works wonders when dealing with a few people on your organization where everyone gets to see face to face everyday and anything can be quickly solved with a little chat in the kitchen. But what do you do when you have to deal with hundreds, if not thousands of employees? Things suddenly get out of hand. And what’s the typical answer to this issue? Rigid control schemes. Ask any PM of a mid-sized company about managing employees and he may tell you something about herding cats.
On a side note, this is precisely the kind of thing that attracts me to small teams – once you stop being able counting a company’s members with your fingers, it is in most cases when everything that is cool and nice of working at a given place begins to fade away. Then again, this may not be the kind of market Basecamp is aimed to.
John G
on 15 Feb 07I think you buried the lede. The second to last paragraph is so well done, it should be first.
Stacy
on 15 Feb 0737s has their heals dug in to support small boat captains only, and they are VERY focused on that fact. The people who grow their business to point of needing functions beyond that of a small boat captain must jump ship to another product. Otherwise 37s would have to serve two masters – small boat captains and big boat captains. And this would make the product not serve either master well, a competitive disadvantage.
So if you EXPECT to have a chain of barbershops (SuperCuts) one day, you might want to start off with a big boat product to avoid the disruption in your growth. However, if you’re gonna be the neighborhood barber for the next 25 years, then 37s offers you a compelling advantage similar to Southwest Airlines.
Merul
on 15 Feb 07Jason,
I actually think Basecamp stands up quite well to many, many other so called ‘enterprise’ ready products. It’s actually something that I can reasonably expect all my colleagues to use.
However, it is important to know what’s being done, and that applies equally well to changes/deletions as well as completion updates.
As for the ‘effort’ required to communicate changes, all that’s required is really the same level of notification as is provided by the Dashboard at present.
Going back to your original post and as I already said, I do agree with your stance about trusting people to do the right thing. If the notification that they’ve done something remiss comes after they’ve done, big deal. I can live with that. Wouldn’t require any complicated permissions changes either.
Anyway, keep up the good work.
Simon
on 15 Feb 07I’ve come round to this position over time, having started off from a more authoritatian position.
Now, however, I’d like Basecamp to have looser permissions than it does; specifically in the area of ToDos. The restrictions on people completing tasks nominally assigned to others seems a little irritating at times… otherwise, keep up the good work!
Anyway… Back to finishing that product we’re working on.
Brilliant… looking forward to seeing more.
Brad
on 15 Feb 07You mean:
See: Amount vs. Number.
Anthony
on 15 Feb 07Cool post. Do you ever consider giving new project members full permissions by default? Instead of having to grant them permission to add to-dos, milestones, etc.
I was confused at first why my teammates couldn’t add to-dos. I explained how to do it, but they had no clue what I was talking about.
Eventually I realized you had to grant them access.
eggs
on 15 Feb 07we have a team of thirty working in basecamp and everyone is an admin. it’s just better that way. we use it to communicate, not to carry eggs.
we have another system that has all the document control super-permission stuff. we chose not to use that system because it is no fun. not only no fun, but anti-fun.
Grant Hutchins
on 15 Feb 07Brad, see this Language Log article for some dicussion on the myth that less and fewer should only be used the way that Strunk & White specified.
In the end, it’s always best to write clearly in a way the reader will understand. Language evolves.
Anyway, no hard feelings, I hope I haven’t triggered a flamewar!
JF
on 15 Feb 07Do you ever consider giving new project members full permissions by default? Instead of having to grant them permission to add to-dos, milestones, etc.
Everyone in your company has full access. Clients have to be enabled to do more than the basics (posting messages, commenting, and uploading files).
If we could do it all over again we’d give clients full access by default too, but we had some legacy rules in place before we pumped up permissions a little so we didn’t have as much legroom.
Jeff
on 15 Feb 07Your overall point is a great one: communication is key. However, the approach you chose is one that does not scale and does not allow for growth. Basecamp basically is setting companies/people up to NOT grow/succeed. Think about that for a minute.
Interestingly, since we started using Basecamp at my company, I’ve doubled the size of the organization and our growth last year was 400%. I’m not suggesting that this is entirely due to Basecamp, but the application has certainly enabled us to stay organized, collaborate better with clients and coincidentally, increase profits. This is a good thing.
jacob
on 15 Feb 07hi
Dawud Miracle
on 16 Feb 07Really nice post. We should all remember this with the ones we love – our kids, our spouses.
Richard Bird
on 16 Feb 07The more Control that’s put in place, the more Control that’s required, from everyone. And, it’s a great way to burn time better spent in so many other ways.
Believe me, I’ve tried the “enterprise” systems where every conceivable level of users, groups and privileges could be managed down to the single document level. That availability soon became a management nightmare. Ultimately, no single person in our organization could say how and why any given level of permission originated or was required.
Ryan Allen
on 16 Feb 07Hear hear! I love lofi solutions like talking to people. It requires less code :)
Jamie Stephens
on 16 Feb 07Good post. Gives me more fodder for fighting against role-based authentication in projects. :)
Also piques my interest in Highrise a bit more. While discussing the UI, you mentioned:
Of course, you also mentioned that Highrise has changed since the idea was originally conceived. I’m curious to see how it all plays out. I guess we’ll all see soon enough.
Scott Meade
on 16 Feb 07Like anything in life, it’s all about priorities. If you want a system optimized for sharing and collaboration, then obviously you want to remove controls and limits. If you want a system the manages sensitive data such as salaries, then you need controls. Simple as that.
Neil Wilson
on 16 Feb 07Got to agree about permissions. Everybody always wants to try and control behaviour via technical means when by far the most powerful mechanism is via social means.
After all that is how the law and society in general functions.
NeilW
Kevin
on 16 Feb 07it’s so easy to push the control-freak’s buttons. I see they are coming out of the wooodwork in the comments. How do you argue with respect, kindnesss, fairness? Geez!
Anonymous Coward
on 16 Feb 07Sure! Your users are all idiots, posting replies like above one, and you’re world champion as usually. This conversation example must be a joke.
Anonymous Coward
on 16 Feb 07... and do something with comment ajax posting, by example disable submit button after clicking on it. Its like one can create empty writeboard if disables javascript in browser.
Anonymous Coward
on 16 Feb 07I may be missing something in Basecamp, but if it is build for inclusion, why is it so hard to add people to a large number of projects?
Why can’t you add projects to PEOPLE. Rather than going into each and every project, permissions, find their name, click their name, click save.
mandy
on 16 Feb 07I’m a Creative Director at a large publishing house and we’ve been using Basecamp almost since it first came out. It started with just a few of us, and has grown such that we now have circa 60 projects and nearly 150 people actively using it. Those people range from senior managers to lowly editorial assistants, and everyone in between. We have authors, editors, proofreaders, software developers, designers, copywriters, marketers, and others all using it. I provide a minimal amount of training for those people who ned it, but otherwise everyone is just thrown into it and expected to figure it out.
I can’t “control” this many people, and I don’t want to. (In fact, I don’t even know many of the people who are using our Basecamp today.) Despite this, I have had no occasion to berate anyone for “misuing” Basecamp or “doing things the wrong way.” In fact, despite the fact that I make no effort whatsoever to manage the way people use Basecamp, it has proved to be remarkably helpful in everything we do. If I gave people instructions or rules to follow, they would just break them, or worse, become so focused on the rules that they were no longer paying attention to the work. I’d rather people just talk and collaborate freely, and get their work done as efficiently as possible. And our experience has been that Basecamp has allowed us to do exactly that.
We are not a small company (circa 400 employees); our people are not, for the most part, technologically savvy; and if there exists any dogma about how to get things done around here, it’s much more rooted in centuries-old methods of book making than in any web two-point-doh mentality. We’re about as different a company as 37s as can be. And we love Basecamp.
Adam Perlow
on 16 Feb 07- Anonymous Coward said “Sure! Your users are all idiots, posting replies like above one, and you’re world champion as usually. This conversation example must be a joke.”
We created a software product for large field sales forces and during the implementation of our product we often have a similar conversation about the “To Do” feature of our software – which enables communication between sales reps in the field and management. The conversation usually goes something like this:
They say: “We need to control who can assign To Do’s to other people.”
We say: “Why?”
They say: “Because we can’t just let people tell other people what to do. It’s got to be controlled.”
We say: “Are they able to email each other currently?”
They say: “Yes.”
We say: “Do they abuse that?”
They say: “No.”
And then we discuss how our software is meant to enable communication rather than stifle it and if you’ve got people making unreasonable requests then you’ve got a people problem, not a technology problem.
I think the conversations Jason described are totally realistic.
Alex Bunardzic
on 16 Feb 07While I fully agree with what Jason wrote (in terms of trusting people wholeheartedly), I’d still like to point out a very glaring error in thinking that everyone in this thread seems to be a victim of. It has to do with the modern day tendency to view everything in terms of black-and-white. A sort of George W Bush-ism, if you will: “Either you’re with us, or you’re against us.”
People seem very prone to this type of mechanical thinking. In this particular case, Jason took two concepts—control and communication, and pitted them against each other. He never stopped to examine his starting premise. Why are these two concepts so antagonistic? Are they really?
So he goes on to calmly declare the ‘control vs. communication’ war. Why? Are these two really at war with each other?
What he fails to recognize and acknowledge is that control and communication are inexorably tied, are weaved into one seamless process. You communicate by controlling and you control by communicating.
Of course, such a blatantly obvious thing would never occur to most people, but there you have it.
CJ Curtis
on 16 Feb 07Once someone is part of a project team, they should have full access to, and be able to communicate 100% freely about, anything within the project.
Anything less is “I’m the boss, your not” bullshit.
I work in a company where (in most projects) title and ego and “experience” rule over all else. The projects in which this is NOT the case are ALWAYS those which enjoy the most success. The work is simply better.
And to answer the concerns about some random idiot changing or deleting a “critical” file and other similar situations…
First, in an environment where a project team communicates freely, I don’t know that there’s such a thing as that one “critical” document or to-do list.
Second, if you are the project manager and such a document DOES exist, and you don’t have a copy of it somewhere other than an open collaboration tool such as BaseCamp, then YOU are that random idiot.
Michael Zuschlag
on 16 Feb 07Communication is indeed the key, but it needs to be two-way. When you’ve a (real, not hypothetical) problem with how users are using a tool, your first question should not be, “How can we force them to stop?” but “Why are they doing that?” Is it just a matter of education or reminding them? How’s the best way to do that? Maybe the users’ actions effect something very useful that you never anticipated. Maybe you should encourage more users to do it and just deal with it. Or maybe you can provide users a means to accomplish the same goal without cause a problem by changing how they use the tool or providing a different tool. Find out from your users why they’re doing it, then figure out the solution. Maybe you can best handle it with policy or maybe there’s a technical solution, which may or may not involve more control.
Ben Haldenby
on 18 Feb 07Jason, when you reply to customers do you provide the backstory about the original design decisions of Basecamp? How much of an ‘explanation’ do you first provide as to why Basecamp doesn’t have the features that are being requested? Do you feel that you need to ‘justify yourself’ first? cheers Ben
Todd McKinney
on 20 Feb 07The idea of making this design tradeoff decision explicit is a great one. My key takeaway from this post is that you should consider communication as a really effective way to shape interaction with software. It’s a first-class tool that should be leveraged in the design, rather than an afterthought that goes in a readme file.
Using and maintaining software is hard enough already, and we have a strong tendency to add features and complexity. It wouldn’t be so hard to write the code to add a feature, but the costs of adding a feature can be huge. It’s not just the people who have to maintain and test the code that have to pay the price. Added complexity means each user has to figure out how to deal with it when they come across it.
I appreciate the approach that says “hold on here, maybe the software is beter if we don’t add that”. Thanks for the post, and keep up the great work. It’s inspiring to see something relatively simple succeed because it’s executed well.
This discussion is closed.