Artykuł Scaling simplicity – Cascading control and permission management in Kanbanery pochodzi z serwisu Kanbanery.
Merging complexity and ease of use is always challenging. At Kanbanery, our aim has always been to create a product that is easy to use, and yet can scale with our clients’ businesses. In the early days, many of our clients were startups, and we know that startups aspire to greatness and some will achieve it. They need an agile project management tool that doesn’t get in the way of a small team building a great minimal viable product. When they become successful, they shouldn’t have to change their toolkit for some ungainly enterprise tool that requires a full-time administrator just to manage accounts, permissions, and workflows. One of the primary tools that we used to achieve flexibility was Principle-driven Design, which I described in an earlier blog post. A startup that chooses Kanbanery because they share our principles of transparency and collaborative learning will grow to become an enterprise that continues to share those principles.
An illustration is our permission management system.
At one time in a past life, I was a Jira system administrator for a large IT company. We had dozens of teams supporting or building dozens of products, each with different workflows. We had layers of management and stakeholders in various departments who had roles to play in multiple projects. The result was many groups with hundreds of overlapping permissions and every day I was adding and removing people from groups, defining new groups (never removing them), adding (but never removing) group permissions, and adding (never removing) workflows. Some companies think they need that level of control, but I didn’t want to do that to any of Kanbanery’s clients.
I knew that plenty of large companies use physical kanban boards. You can’t hide a physical board from someone who has a key to the room. You can’t show anyone some columns but not others. You can’t control who can move tasks or in which direction. And yet it works. That’s because people are basically good and most are pretty smart (they call it knowledge work for a reason), and when you trust them, their natural inclination is not to let you down.
So When we designed the Kanbanery permission system, we kept it simple. There are three roles: viewer, team member, and manager. A viewer can see anything, including comments, attachments, and reports. They see all the same things that a member of the team would see when they look at a board, but they can’t move task cards, create task cards, or change anything on the board. The physical analog is looking at a task board through a window. They see the same things the team sees. No secrets. That’s how we build trust.
A team member can add and move cards around and add comments and attachments to a card. They can also edit anything on a card.
A board manager (there can be several) can do everything a team member can and they can also change the board layout and settings and manage board users.
Personally, I use only the board manager role, giving all the control to everyone on my teams. No one has ever made a mistake or abused their power. People don’t have to ask me to add them to a board or to change a board’s settings or layout since anyone on the team can do all that by themselves. I had enough of that back when I was a Jira admin.
At the higher level, we have account and workspace management. The one thing that I do feel pretty strongly about controlling is my clients’ costs. The person who creates a company account and pays for it is the only person who can change the plan level, upgrade to the Pro plan, or add team members over the plan limit. The person who pays the bill, or who entered the company credit card should never be surprised by an invoice. So when someone creates an account, paid or not, they own it. In the account is one workspace. If they have a pro plan, then can create more workspaces.
Workspaces can be handy when you need to control access by product, team, department, or client. A workspace can have many managers, assigned by the account owner. These managers can do anything within a workspace that the account owner can, except things that would cost more money. They can create and delete boards and manage those boards and all their members.
It sounds complex, but after hundreds of thousands of clients using Kanbanery over almost ten years, I can only remember four times that we got a support request to clarify how something works.
Because from the standpoint of a person adopting Kanbanery for their company, the workflow is natural. They create an account, then perhaps they rename the workspace or create a few workspaces. They automatically are the workspace owners for all workspaces in their account. Perhaps later they want someone to help, and then they just add that person as an additional workspace manager. The account owner or their workspace managers then create new Kanbanery boards, and they are automatically managers of those boards. Again, if they want someone else to manage a project board, they just make them a board manager.
Only twice in Kanbanery’s history has this caused a problem. Both times it was because an engineer or project manager created an account for their team and paid with a company credit card borrowed for the purpose. In both cases, other teams in the company saw Kanbanery and liked it, and Kanbanery use grew from the original team to other departments. Later, the people who created the accounts left the companies and we’d start getting requests from accounting for invoices, or we were asked to update the credit card on file. So we’d migrate the account ownership to someone higher in the organization or in accounting and the problem was solved.
A student who created a free Kanbanery account for managing their coursework can assume it’s as easy to use as Trello because they never have to see the power that’s under the hood until they need it. A large corporation using Kanbanery in multiple departments for sales, marketing, legal, recruitment, and of course product development just sees a simple tool that scales intuitively. So by giving account owners total power over everything in the account and the ability to easily share that power, we have a simple system of automatically cascading responsibility that just works, because it’s based on maximizing simplicity and assuming trust and transparency.
Artykuł Scaling simplicity – Cascading control and permission management in Kanbanery pochodzi z serwisu Kanbanery.
