Here at the Kalido office, we find many people from all walks of life — entrepreneurs, consultants, managers, and others — who are interested in how and why we structure our work and processes the way we do. Some of our practices come from standard Agile processes (though we are not strict adherents) and elsewhere, while others were organically developed. Collectively, they work extremely well for us. And for a small, cross-functional team based in multiple geographies, with both full-time and part-time members belonging to multiple companies, it also reflects the modern workforce quite well. So, in the hopes that it will be equally useful to you, here are some of the principles we follow, along with practical details of how we implement them day-to-day.
The Principles
- Do the work. Divas, and those who wait for instructions, are unlikely to help a small company succeed. Recruit those who do the work, and cultivate a low tolerance for those who do not.
- Make sure every task has a single owner. Without ownership, mistakes and confusion are guaranteed.
- Let teams shape delivery dates, and the culture. You’ll often get better (and faster) results by trusting people to estimate their own work capacity.
- Share as much as possible. Transparency about everything, from strategy to finances to bottlenecks, creates a team that is tightly aligned and can share triumphs and challenges alike.
- Plan with flexibility in mind. Block time every week for the unforeseen, and make time to negotiate what will be delayed if new things are added to the plan mid-week. Otherwise, your long-term plans will creep further away from you each week.
The Details
1) Do the work
In a startup, there are always side tasks which don’t clearly fit into anyone’s job description. There are also mind-numbing or menial tasks that no one wants to do. But, if you have capacity, something needs to be done, and you are capable of doing it, do it. Whether it’s cleaning up that spill in the kitchen, or re-running the fifty acceptance tests that everyone dreads for a new feature, someone has to do it — why not you? If you have capacity and don’t know what needs to be done next, ask how you can help. Also, remember that the people who don’t speak up, or feel that certain tasks are beneath them, are almost always people you should have let go already.
How we do it
This principle applies primarily to things that don’t fall in the plan (we’ll talk about the plan itself later). Focus on what you’ve committed to for the week first, always. But inevitably, you’ll hit a point in the day where you’re not productive or creative anymore. That’s a good time to figure out how you can be helpful in uncreative, but valuable ways that require time and physical presence (like running an errand to pick up supplies), or straight-up grunt work (like doing some spreadsheet formatting).
Restrict this work to things that fall firmly within one of two scopes: 1) things that someone else was going to do anyway, or 2) things that no one has thought of doing yet. In both cases, check with the relevant team to make sure it is the best problem to address right now, to avoid ownership confusion, and so you build social credit for doing a good thing. Tasks that require cross-team problem solving or resources belong in the plan, not here: using spare capacity for those tasks will inevitably slow everyone else down. Finally, if there is truly no way you can help right now without pulling someone else in, or creating future work for others, it’s probably time to take a walk outside, go for coffee, or grab a nap. That way, you’ll be able to recharge, and will be of more value to your team when you return.
Side note: This often leads to a discussion about when and why to delegate an activity to someone else. In most cases, delegation makes sense only when: you don’t have the skill, and the other person does; you don’t have the capacity, and the other person does; or both. Returning to where we started, if you have both the capacity and the skill, you should do the work. That way, the rest of your team can also concentrate on creating value in the way that fits them best.
2) Give everything an owner
For each deliverable (e.g. a new feature) at a given stage (e.g. design), we have a clear owner: one person who is ultimately responsible for its execution. Team leaders still review everything, but all discussions about a deliverable require the owner.
How we do it
Owners should come from the team relevant to the task, and are almost always volunteers (if volunteering is always a problem, you likely have deeper culture and hiring issues to solve). If no one volunteers, the team leader must take responsibility, or designate someone who verbally confirms ownership. Anything not assigned an owner is by default the responsibility of the relevant team lead. The specifics of how we do this are below. While some things are quite focused on building software, the general rules apply no matter what you are building.
We use Trello and Google Sheets to track all of our deliverables, and use the following rules to manage them:
- One-time process tasks (like designing and developing a specific feature) have individual Trello Cards.
- Content that is updated has a row in a Google Sheet. Every Sheet (and often every row in every Sheet) and every card has an owner.
- Owners may change over time, as a card moves through a process, or the team itself changes.
- Each team has a Backlog List, and a Sprint List in Trello.
- When one team is done with a piece of work in their Sprint List, they move their card to the next team’s Backlog List.
- Our lists (and teams) are set up so that everything follows a clear path from left to right in a Trello board: Copy*->Design->Server**->Front End->Testing->Released.
- Cards that fail testing are sent back to the appropriate Backlog List.
- All tasks should have cards, no matter how simple. Failing to do so increases the likelihood of a task being forgotten, and creates a false view of individual workloads.
- If someone asks you for something mid-week, and you agree to do it, add a card for it.
- Never add cards to someone else’s Sprint without asking.
- Every week, review progress against Sprint plans via Trello (we run one-week sprints to coordinate teams as quickly as possible).
- If something absolutely must be fast-tracked, use a topic-specific channel in Slack, link it to the relevant Sheet or Trello Card, and record the decision in Slack.
- Propose urgent changes to things affecting multiple teams (like data models) only via polls in a specific Slack channel that require agreement from all parties to proceed — verbal agreement is not enough.
- Finally, ensure all designs are reviewed by every team for technical feasibility and efficiency, given operating constraints (like programming language restrictions). This way, every team can shape the final product, and redesigns that could have been identified earlier are limited.
*Copy and Design will often collaborate in a given Sprint if required because their work is often so deeply integrated.
**Our Server team is actually split into sub-teams for things like Analytics. They maintain separate Backlog Lists, but use the same Sprint List. This is because all Server team members are capable of helping each other out as needed.
3) Let teams shape delivery dates, and the culture
Poor managers dictate arbitrary deadlines without understanding the work required. At Kalido, we trust that people work hard, and know how their ability and capacity translates to deliverables. So, instead of assigning tasks, we collectively agree to them each week. The leader of each team proposes a scope of work that team members agree is feasible. Each individual has extreme autonomy about when and where they work, with two exceptions: all teams sit together at least one day a week, and every team sits with our founders at least one other day per week (two days for designers).
This creates personal flexibility that allows people to get the work they committed to done, while also living full and healthy lives. Because we all know each other’s capabilities reasonably well, over-promising and under-promising can be called out quickly. Less experienced team members sometimes also need help setting achievable goals, and the entire team contributes to this as well. We also encourage everyone to speak out about inefficiencies or practices that make people unhappy or uncomfortable, and we try to adopt suggestions immediately. That way, everyone shapes the culture, no matter how new they are to the team.
How we do it
Every Tuesday morning (Monday or Friday morning all-hands meetings create an unhealthy amount of weekend stress), we have a meeting to plan next week’s Sprint. This includes design, development, and marketing, so that all teams are aligned. We start with a session called “Start, Stop, Continue” where we review any recently adopted practices, and ask for suggestions on what to stop, start, or continue (which can include anything from how we deal with bugs on the app, to what the lunch menu looks like).
After taking stock of our current position (upcoming features, current growth and usage statistics, and finances), each team reviews their accomplishments from the prior week, notes anything that carried over, and proposes the Sprint for the coming week. Each card is assigned to a team, and the team agrees which individual will carry it out. Any bottlenecks or straightforward cross-functional technical challenges are called out, and discussed to a decision point immediately.
Complex engineering questions that require an agreed direction, but do not have clear actions that can be owned yet, are set aside for a separate discussion by relevant teams later in the day.* If something has carried multiple times, or has delayed us significantly, we discuss until we have: agreed a root cause; defined a process we think will eliminate the cause in the future; and assigned people to implement the process. Finally, new processes are monitored for the first few weeks during the “Start, Stop, Continue” section at the beginning of each Sprint.
*We keep a separate Engineering board for all discussions of this type, split into three lists (Do Someday, Do next, and Do now.) As soon as something moves from a discussion to a decision, the card is archived and translated into one or more task cards in our primary activity board.
4) Share as much as possible
Sprint cards in Trello can be seen by everyone, and all tracking tools must be visible to everyone as well. That way, accountability is public, so if you decide something needs to be tracked, no one feels inaccurately monitored. This helps everyone plan their work, and establishes a shared record to facilitate problem solving discussions.
How we do it
We have one simple rule: no private Trello boards, and no private Google Sheets, unless you never intend to use what’s in it to facilitate a discussion with anyone else. Private Slack channels are fine, as long as they are not used for cross-team discussions. In this way, we track individual designs, every string of copy in Kalido, the state of every single release test, and more.
5) Plan with flexibility in mind
Despite the best laid plans, nothing ever goes exactly as expected. Which means that despite our weekly sprint, unexpected things crop up, from emergency coffee runs to last minute architectural redesigns. As we discussed above, our plans are always specific and transparent, but we also bake in three additional and critical elements: absolute specificity, fair re-planning, and space for the unforeseen.
How we do it
Like a good Agile team, we have daily stand-up meetings with all team leads in attendance, lasting no longer than 15 minutes. Each lead covers yesterday’s achievements, today’s plan, and flags any challenges so that expectations are managed, and other teams can help out where useful. Over the course of the week, we occasionally add cards to a team’s sprint, but in such cases, each team always has the right to ask for a card of equal weight to be moved to their Backlog List.
In addition, because no plan can perfectly anticipate everything, we ask all teams to block 20% of their time for last-minute requests, bug fixes, and so on. Having a small margin to deal with unexpected things means you almost always achieve most of what you set out to do today, which means tomorrow will run that much more smoothly.
Finally, as noted previously, we ask everyone to always make sure that their entire task list is on Trello at any point in time, and encourage people to make cards to document any last-minute requests, no matter how simple. This ensures that during any workload discussion, everyone has an accurate view, so that if someone is overloaded it is both obvious and quick to reprioritise appropriately.
As a small team with lots of work, we appreciate that efficiency is key to survival, and we hope sharing some of our techniques will help you, too.