Playing on an Organic Team
The web is littered with articles on empowering employees and bottom-up management. Much of it feels like lip service, when in the end upper management hires, fires and controls the budget. True empowerment and bottom-up accountability are worth aiming for; yet on a day to day basis, decisions and goals need to be unified in order to accomplish anything.
WhatsCookin’ is not a typical top-down corporation, but neither are we a cooperative, with one person-one vote. Organic is a good descriptor for how we work, as ideas emerge and grow if they prove valuable, and those who prove themselves by working gain more say over time.
Here is how we currently approach the goal of vigorous and empowered team, and what it means to join us.
2. Commanders Community Intent
3. Transparently Seek Critique and Objections, not Permission
4. Check for Breadcrumbs, and Leave Them
5. Love your Children – But Not Too Much
6. Do, Document, Delegate – and Code
7. It Does Not Exist Unless You Measure It
9. Servant Leadership and Accountability
10. Responsibility of the Reviewer, and When To Be Noisy
Work Talks
Work is respected at WhatsCookin’ in a few concrete ways:
– budget is justified by placing amounts on peer-reviewed tasks that are transparent to all
– when big decisions are being made, we take a work-weighted vote (and may also take a per-person vote)
– work on approved tasks will be translated into voting tokens
We do have leads who have the authority to approve tasks, but as described below they have accountability to the team.
Rather than delegating tasks, leads may offer them in slack and you can volunteer (ie answer in slack and self-assign in Taiga). Since many of us are working for equity, people have a good deal of flexibility as to which tasks they want to take on.
Anyone may also propose tasks, that they think are useful and wish to do, and see if there is agreement that they are worth spending money or equity on. Your responsibility can grow organically, and if we have funds for it then your budget may grow as well.
Once a task is accepted it must be completed in the timeline or any blockers should be promptly brought up. Failure to do so may result in the reduction of the member’s budget.
Commanders Community Intent
I once worked for a startup that used the method “Commander’s Intent” which originated with the Israeli army. The idea was that the execs established the goals, and we had a great deal of individual flexibility of how to try to achieve them.
In the case of WhatsCookin’, our fundamental goal is to build community through real time events. Medium term, we have a roadmap for architecture, design and outreach objectives that keep us aligned. Fundamentally, we have some core “north star” values:
– service: serve our users’ intentions and larger goals – do not try to control them
– honesty: transparency with our team and our larger community
– inclusion: while keeping out bad actors and allowing private groups, generally we want all people to feel invited and included
– positive impact: we want to create connections and events that lift people up, enhance their lives, open opportunities, and empower them to achieve their goals
In addition, we should keep in mind essential objectives to succeed:
– reach and engage users: to do any of the above, we need to reach people
– earn revenue: to continue our work, we need a growing revenue stream
Within that framework, members are invited and welcome to propose what they think are the most useful next steps, to achieve the larger goal or the nearer objectives, or even to propose new objectives.
Seek Critique and Objections – not Permission
In an environment where anyone may propose a next step, it is especially essential to actively see critique. Any idea, to go forward, should receive critical feedback in several key respects:
– is it in line with our core values?
– is it advancing our core objectives, or is it a distraction?
– did you think about it from the perspective of the user?
– have you found the simplest possible way to try it out?
– are you doing it in a general way that is extensible?
– did you check if someone is already working on something related?
– will we be able to tell if it is useful? how will we measure it?
It is not necessary to get permission from a specific person to go forward with a new idea, but you should make sure that you got critical feedback from teammates and that leads had a chance to object.
Note that most members are self-assigning their budget onto the tasks they take on.
Check for Breadcrumbs, and Leave Them
When writing new code, one of the key questions is where does it go, and how will it be called? Existing code should always be searched and examined for similar work, and existing patterns should be respected.
When starting new projects, you should search for existing work in a few places:
– The wiki
– Taiga tasks
– Google drive (technical architecture docs may also be here)
– Github (if it is code)
– Figma (for designers)
Slack can also be searched but we are not paying to archive all messages, so it is less useful. Be sure to search for the general purpose and area your project pertains to. Be aware of the top level documents for your team – these are linked from the wiki.
Our goal is that everything you need to know should be findable by starting from the wiki.
This means, that when you start your project, it should also have breadcrumbs back. If it is a draft or proposal it may be a google document, but should be linked from a taiga task, and the document should be placed in an existing team folder or subfolder. If you are creating new methods or procedures they should be linked from the wiki.
This need not take long, but it is important that the next person with the same bright idea be able to find your implementation of it!
Love Your Children, But Not Too Much
In a peer-to-peer work environment, no one may be checking that your work is being used optimally – or even at all. If you have done work you think is useful, please pursue handing it off and ensure that it receives attention.
Designers may need to check with the development leads when they can schedule implementation of a design.
Marketers who create an event may need to ask others to help promote their event.
Developers who create a new feature may need to ensure that marketers know about it and communicate it to users.
Do not assume that others are aware of the neat new thing you just did. Tell them!
But don’t fall in love: Sometimes, an idea that seemed wonderful will just not prove useful. In this case it is important to accept that your idea may be axed and removed from the product or the plan. That is ok! We cannot advance without trying out many ideas, and only some of them will prove worth keeping.
Make sure your idea gets noticed and tested, but do not worry if it removed. A new feature that has no criticism probably was not noticed. Seek Critique applies as much or more after implementation as at the beginning of an idea. Only make sure it is not ignored!
Work only has value when it is delivered to the end user. Make sure yours is delivered.
Do, Document, Delegate – and Encode
Trying out new ideas requires close attention, a hands-on approach, and flexibility.
Once you have figured out a process and pattern, its time to document it so that others can follow the same approach – and possibly encode and automate it.
This especially applies to communications – we may often start by communicating directly with users, but may need to automate the flow in order to scale.
It Does Not Exist Until You Measure It
Astronomers looking for new celestial objects have a saying: if you did not record it when you observed it, it does not exist.
Similarly, features, events, or ideas are not fully realized unless we have a way to measure what the result was. Some possible methods:
– track in the user analytics if people are seeing it
– if the new feature was supposed to affect a user behavior, say creating twitter handles, see if this behavior increased
– check if it is annoying users – especially any “forcing” behavior, look for dropoffs, or make sure it is included in a user focus check. Try to avoid “forcing” users.
– ask at least 3 teammates to try out the feature, or event, and give quick feedback
– if a large change, did it impact overall user stickiness or virality?
– try it yourself – do not forget to exercise your own creations
This is currently one of our weakest areas. What can we do to improve it? Would it help to hold regular user focus sessions or regularly recruit new users to walk through the app and comment on usability? Can we gather more data?
Validate, Experiment & Learn Rapidly
Launching a startup is always uncertain. It is essential that we do not take any particular approach as dogma, though we should stay true to core values.
It is critical you understand what you are doing and how it will impact the user. We have less management layers than many orgs, so each person must take responsibility for questioning what you do not understand, and questioning anything that seems to not make sense!
If something is not working, try to think of what else we can try. If nothing comes to mind, look for resources we can learn from. Always try to talk to end users – people who might benefit from community, or are trying to build it. Ask them what their frustrations and pain points are, and what they would wish for.
Every one of us can be an ambassador and can bring in new ideas and learnings from our personal community and networks. Have you shown the app to your friends? Did it make sense to them? What actual problems or desires do they have, and how can we help?
When designing the architecture, try to plan points where experiments can be easily added and removed. Can we try new ideas manually before implementing them in code?
Improving our own work processes is also important! See recommended books for productivity and process. Pair with other team members to spread skills and learn from each other.
Servant Leadership and Accountability
Some people who join our team have great depth of experience and executive ability or talent, which is of course extremely valuable. However, our team is not a place for a new outside executive to come in and “reorg” everyone.
People with big ideas are absolutely welcome to share them, make proposals and seek critique. If they are good ideas likely they will gain traction and approval.
The job of a lead is to help team members work with maximum effectiveness.
Team leads do ensure that the agreed on objectives are being pursued, and are responsible for approval of tasks. Leads are expected to provide critical feedback and to often ask for improvement of tasks, or to redirect an approach to a better architecture, a simpler method. Team members who disagree with a lead should say so openly and give reasons, and others may weigh in, but generally the expectation is that the leads are providing experienced direction for a reason.
Leads/execs who assign budget or authority are subject to a vote of confidence. Currently leads and budgets are fluidly assigned by the execs but this may change; it has depended on which experienced people are available and are taking on responsibility. The executive assigning budgets must be accountable to the full team via a periodic vote of confidence.
Responsibility of Reviewer, Task Owner and Peer
Reviewing tasks promptly is as important as completing them. “Bottleneck at the top” is a real problem. In order that we do not get get delayed, the following are suggested:
– Task owner should ensure that the task aligns with current objectives. If not receiving prior approval, then be sure it is closely aligned.
– Task owner may solicit from critique from peers before submitting for review
– Reviewer should promptly review tasks same day if possible, within 2 days at most. If this cannot be done, please ask for help, or send unaligned tasks to backlog.
– Reviewer should be critical, not rubber-stamp, and freely send back for improvement
– Peers should be friendly, helpful and critical. Make yourself available for teammates with questions or needing peer reviews. Speak up and share your perspective.
– Task Owner should as ask again in channel if work is not reviewed
– Task Owner should ensure work is deployed or adopted after review
See “Seek Critique” above for criteria. Most important is to think from the perspective of the user, how will this appear to them or impact them?
What if We Succeed?
Our goal is to lift up all team members as the company grows. Equity is currently assigned as options and may be purchased and sold on a secondary market to cash in, while work-weighted team governance is retained. As the company grows we hope to increase budgets, salaries and benefits, as well as provide training to help everyone “level-up” to the skills needed in a large, fast-growing enterprise.
Eventually if we are successful, we may be able to spin off related entities that have shared principles and ownership, that can be independently run. Our long term goal is to spread principled, accountable, team run organizations that cooperate efficiently.
Now back to work…
