The ongoing pandemic has forced almost every company to change how they work. How information moves, how to work with other teams, what is the progress, what is expected of people are just a few things that come into play.
When in a normal office environment people can interact more, gather info from informal talks, then when people are all working remotely this becomes challenging. And particularly in these times processes that help people get the info they need and get their work done becomes crucial. At Fortumo, we are fortunate to be able to continue operating our business without interruptions despite shifting to fully remote work, something which we have never done before.
Interruptions haven’t occurred not just because of the digital nature of our business. We want to think it’s also because we are efficient and productive in how we do things. This starts with the processes that we use in our organization that should work in both good times and bad. Here’s how we approach and build up processes at Fortumo.
What defines a good process?
A process is defined as “a series of actions or steps taken in order to achieve a particular end”. Within the organization, the goal of processes is to help advance the organization and support people in achieving their goals. We don’t implement processes to micromanage, control people or create bureaucracy. We implement them because it makes progress transparent and work easier for everyone.
How do we know if a process is good or bad? Here is a list of criteria that a good process should meet:
- Self-regulated: works without external (e.g. team lead) input
- Transparent: everyone involved knows why the process is used
- Lean: the process makes work simpler, not more complicated or bureaucratic
- Predictable: following the process means specific input having a known outcome
- Sustainable: the process survives stress situations, such as the current crisis
- Supportive: the process guides team members in doing things that are most important
- Adaptive: parts of the process can be changed without the system breaking down
- Controlled: the process provides visibility and possibility to change it to them team lead
As an organization, the processes we create are designed to simplify how input for activities is gathered, how the delivery of tasks happens and what the output of the work is. Team and companywide processes are complex as they involve many moving parts, so let’s break them down into pieces.
Processes for input: defining the input channels
It would be great if all input for work that needs to be done came from one single source of truth. This is rarely the case. Most people get their input from three types of people: external stakeholders (customers and partners), internal stakeholders (team lead and colleagues from other teams) and input from within the team (e.g. people in the same sub-team).
In addition to different people requesting things, the input arrives through different channels: direct e-mails, mailing lists, phone calls, meetings, Slack chats, informal discussions, gossip, alerting systems, Jira boards, Confluence etc.
When creating a good sustainable process, the team lead is responsible for deciding which channels are used for input so that the information flow can be organized and controlled. For example, if feature requests are expected to be added to a Confluence page, people who write about it in Slack chats should instead be directed to the Confluence page.
These channels should be adaptive as the team changes: input for a team of 1-3 people can be done via e-mail while the same approach breaks down once the team grows to 10 people, for whom using Jira or Confluence would be much better.
Processes for input: organizing the information
Once the input channels are defined, the input can be organized. If the input is given with an expectation that work should start immediately, there must be an explanation on why that task is important and urgent. While such tasks are prioritized, most teams have more work coming in than they are able to complete. This creates a backlog.
For the backlog, supporting processes should be in place to keep the backlog relevant. Is the input given regarding the tasks clear and finalized? How do the tasks stack up in priority? Can something be eliminated? Has something not urgent suddenly become urgent and should be escalated?
A good backlog also contains the team’s internal activities. For example, while the majority of engineering time is spent on feature development, the internal improvement ideas should not be tracked separately from the regular backlog. Keeping a unified backlog ensures important internal team topics have the visibility so that the team’s needs don’t get overlooked.
Processes for input: delegation and improvements
When the channels for input are defined and the backlog is organized, work needs to be divided up between team members: delegated. The most common is to use a rule-based approach (e.g. everyone is working on a certain number of tasks) or rotation based approach (e.g. a specific person is responsible for monitoring and incident management during a certain week) approach. For small teams, manual delegation works as well.
Having a good process in place for gathering input should result in more automation (input arrives in a suitable format in the right place) and easier decision making (clear shared knowledge on which tasks are important). It should also support giving visibility to tasks related to internal team improvements.
Since processes should be adaptive, it’s useful to have dedicated “boost sessions” for reviewing the input process, where team members can share thoughts on how to make things more effective. At Fortumo, we find brainstorming sessions, roadmap planning meetings and retrospectives useful for achieving this.
Processes for delivery: ensuring support and quality
Once the input channels are clear, the backlog is organized and tasks are distributed, work can start. A good process also defines how the work is done. In the delivery phase, a good process is supportive and helps validate the quality of work.
For a process to be supportive in the delivery phase, the team lead needs to understand what people need to get their work done and provide them with what’s missing. Which tools are needed? What knowledge is needed? Which guidelines need to be followed? What is the capacity of the person to handle the task?
Secondly, validation during the delivery phase ensures that work is predictable. This can be achieved through testing (for software), double control (teammates reviewing each other’s work) and self-regulation: checklists, acceptance criteria, automated tests and proofreading are some examples of validation.
For both supportive and validation processes, “boost sessions” are again useful to review whether the team lead has created an environment where people are able to do their work in the most efficient way possible.
Processes for delivery: communication with stakeholders
Just as important as the delivery itself is the transparency of how work is being delivered. If an important customer requests a feature and it goes into development but takes a month to ship, the customer will be unhappy for those 30 days if they don’t know that it’s being worked on. Stakeholders don’t expect just the final result, but also want to know what’s happening with their input.
There are two ways how to keep stakeholders in the loop on the delivery process: either push (pushing information out to them) or pull (the stakeholder has a channel where they can find the information on their own).
Examples of the push approach can be recurring updates or meetings and e-mails based communication, where the person responsible for the delivery reaches out to the stakeholders. The pull approach uses formats such as dashboards and pipelines, where the stakeholder can instead check on the delivery in a channel agreed beforehand.
If stakeholders constantly ask, “what’s the status with my task?” then communication is not working and neither the push nor pull approach is being correctly applied. In the delivery phase, the visibility of the work being done should be automated through push or pull, so less time would go on managing expectations and more on actually getting the work done.
The same logic should be applied to the communication between the team lead and the team members for the delivery of work. At Fortumo, we use a combination of OKR-s (objectives and key results), PPP-s (weekly progress, plan and problem updates) and face-to-face meetings to make sure people have the resources to do their work and that things get done on time.
Processes for output: the documentation is just as important as the work itself
Whether input and delivery phases are set up properly becomes apparent in the output phase: either things are shipped that meet stakeholder expectations and they arrive on time; or they don’t work as expected or arrive later than needed.
Just as important as what is shipped is also whether it is predictable and organized. For the output phase of any work, this means that the final result of the work should also be documented and communicated. This allows stakeholders to get a better overview of what is being done, makes life easier for the team (things can be recycled) and also ensures people get credit for their hard work.
Is the process sustainable?
Mike Tyson has famously said: “Everybody has a plan until they get punched in the mouth”. Processes are only good if they also account for the risks that can potentially mess them up. The most universal risk for any company that messes up processes are related to people: vacations, leaving the company, role changes, illnesses, laziness, work overload or human error. A good process should be designed to continue working if any of these situations occur.
Something that helps validate whether a process is sustainable is stress testing. The current pandemic is a real life stress test which has made faulty processes within organizations clearly visible. But under normal circumstances, things can also be thought through on a theoretical level.
Let’s say you want to introduce a new process to the team. How do you normally communicate that to the team? Probably at a team meeting. But is the decision also written down somewhere permanently, so that it can be accessed later? If a new person joins the team, does their on-boarding plan include the introduction to the process? If a specific person is assigned to a process, who is the back-up person? Does the back-up have the knowledge needed to continue the process and the tools to continue work? Last but not least, what happens if the internet connection in the office goes down?
Just like good work itself, good processes are also documented and communicated.
The process is in place, my work here is done?
If a process is well thought through, it should not require constant input from the team lead to keep running. However, that doesn’t mean the team lead’s role stops once the process is put into action.
Good processes are also measured to make sure that things are working as intended. For this, we use analytics, KPI-s (key performance indicators), and measuring capacity, trends and performance. As processes should be adaptive, this is the time to again use those “boost sessions” to push for improvements to the processes based on the data collected.
A good team lead makes sure whatever tasks they give their team have all these components covered. The list isn’t perfect, we haven’t written any books on the topic but this is how we get things done.
And to sum it all up, here’s a cheat sheet on our approach: