Managing work in a startup

This article is part of a series about how to manage a small software start-up, the first article & overview is found here.

Photo by Glenn Carstens-Peters on Unsplash

In the previous articles, I wrote about most aspects I consider important to managing your company: recruiting, product management, business development — I didn’t mention the most fundamental part yet: managing the work itself.

For me, work management consists of the following aspects:

• Task definition: Splitting up the work into manageable tasks that can be assigned to team members
• Status alignment: Getting everyone on the same page about what has been done and will be done
• Resource planning: Making sure the time availability & task commitments match
• Feedback culture: Aligning performance expectations within everyone in the team

As with most aspects of start-up work nowadays, there are many great tools out there to manage your work. At my company, we chose Asana, which everyone in the team preferred to the commonly used alternatives Jira or Trello. Some reasons were:

• Simplistic design, most features you will be able to leverage even in a small team
• Overview of projects, personal tasks, and task descriptions all in one window
• Intuitive customization via tags, custom fields, timeline, and kanban/list view — easy to add filters as well
• Usually relatively fast and responsive

Photo by Eden Constantino on Unsplash

Working on Tasks

Task Definition

The first point to agree on is what gets into the definition of a task. There are many opinions in the “agile world” about the wording of so-called “user stories”; I prefer to just call it tasks and make sure that these points are included:

• Description: Describing the context and deliverable
• Related material: Any material needed to complete the task, links to mock-ups, code, interviews, etc.
• Acceptance criteria (if applicable): If not obvious from the description, a bulleted list of criteria for the task to be done
• Deadline (if applicable): Only set it if something bad happens if it’s not reached, not just to put pressure or as “convenience”. Otherwise, you create deadline inflation, and your peers won’t take these dates seriously anymore
• Workload: counted in full workdays (8h) dedicated to the task, independently of the person’s occupation. If not possible to estimate (for example bugs), explicitly put “Unkown”
• Priority: Should be a maximum of three levels (high/medium/low) just to give an order to assigned tasks

I don’t agree with some folks saying everyone in a team should understand the task. In my opinion, the tasks should be defined for the type of people who will complete them as well — so a marketer doesn’t need to understand every detail of a coding task, for example.

Task Culture

Everyone needs to have the same understanding of what it means to assign and work on tasks, some of our principles included:

• The person assigned to a task doesn’t necessarily do all (or indeed any of) the work; (s)he is just accountable for its completion.
• Tasks are not orders; everyone should always question the usefulness of each task.
• Every assignee should agree to the assignment, the workload estimation, and the delivery of a task.
• When a task is done, the assignee should create follow-up tasks directly if needed.
• The assignee is responsible for keeping the task status and description up-to-date.
• One should not take the acceptance criteria too literal and also do small related work (e.g., some code refactoring or some file renamings)

In general, the goal should not be to complete as many tasks as possible but to provide the most value. This is also why I find metrics about task completion quite dangerous for the work culture.

Task Review

Most tasks should be reviewed by at least one other person before being considered complete. Sometimes intermediate reviews should also be done to make sure there is agreement on what is to be done.

We used Asana subtasks for assigning reviews and just as with the task itself, all relevant information (e.g. Merge request links) should be included in this subtask.

The person assigning reviews should stop working on the deliverables once a review is assigned to reduce the back and forth during the process.

We also found it helpful to only have one reviewer at a time as multiple reviewers tend to duplicate efforts amongst them.

Project Structure

To have a good overview of each project, the tasks should be structured into different sections — we structured it as follows:

• Milestones (optional): Specific milestones that have to be reached on a specific date
• To do: Tasks that still have to be done next
• In progress: Tasks that are currently being worked on
• Review: Tasks that are being reviewed by another member of the project
• Done: Tasks that have been done and should be presented to a stakeholder
• Backlog: Tasks that are considered by the project owner for the current goals of the projects
• Incoming: Tasks that members of the group have added and the project owner still has to sort
• Future considerations: Tasks to consider for future goals or iterations of the project

We implemented a centrally mediated approach where the product or project manager would keep the backlogs relevant and in priority order. A more “radical” approach would be to have no backlog at all and each team member proposes tasks to the manager before the next sprint meeting.

I am a strong opponent of the backlog refinement meeting in general because you will just waste most of the team's time discussing sub-optimal task descriptions of things most colleagues won’t even work on.

Photo by Leon on Unsplash

Sprint Meetings

Sprints are simply a regular time interval with primarily defined work for team members. The first variable to determine is the cadence; Most teams (including ours) worked on sprints with 2 weeks duration, though I would consider longer intervals of 3 weeks or even 6 weeks in hindsight.

It’s a balance between the speed of learning from finished work and giving more autonomy to the team members — I recommend that every team try different cadences to find their optimal rhythm.

I wouldn’t worry about following any particular “agile framework” and try to understand the fundamental nature of your work. For example, you might have some more research-oriented tasks where a person needs freedom to work on a particular task for 3 months — in this case, I would still assign the task to that person and use sprint meetings to share work updates with the team.

As emphasized in the previous article, I always try to reduce meetings as much as possible. Instead of doing four separate meetings such as backlog refinement, sprint-retrospective, -review, and -planning, we would just have one session with a break called “Sprint Review & Planning”. We would first review what has been done in the last sprint, have a break, and then agree on the tasks to be done on the next sprint — quite simple, really.

What made the sprint meetings quite efficient for us was to have less of a flat hierarchy in a “sprint team” and have an assigned product or project manager that was responsible for:

• Proposing a feasible set of tasks for the team to be done
• Refining the tasks before the meeting and making sure the assignee understands what needs to be done
• Managing the roadmap and milestones and making sure the timelines are feasible
• Reviewing incoming task suggestions and propose a choice for the next sprint

We also had additional guidelines to keep the sprint meetings efficient:

• Always consider organizing a separate meeting about a specific task in a smaller group if there is a more extensive misunderstanding.
• Don’t use sprint meetings for feedback; one or two comments are acceptable, but a separate session should be planned if proper feedback is needed.
• It’s okay to create a task or clarify small things in the sprint meeting. If the discussions become too extensive, add a task such as “Clarify the description” and assign it to the right person, as the current task description is probably insufficient.

Regular Status Meetings

“If the information disseminated isn’t required to be absorbed by everyone at the exact same time, then let people absorb it when they’re ready to read it, vs. when you’re ready to tell them.” — Jason Fried

Another standard arsenal in agile work and a personal enemy of mine is daily standups. I urge everyone to consider Jason Fried’s advice and simply change to written status updates. People can write an update asynchronously when it’s a good time for them. Personally, I think it’s a good idea to write an update first thing in the morning:

• What did you get done yesterday?
• What is your plan for today?
• What is blocking or hindering you from completing this, if anything?

Mainly because people can help with blockages if they see the update and the person hasn’t realized that internal help is available.

Photo by Lukas Blazek on Unsplash

Resource Planning

Resource planning is the activity of estimating future workloads against the available time of your team members.

In principle, you could simply hold sprint meetings and make sure everyone can do the tasks they are assigned to — in this case, you would not need any kind of resource planning, in my opinion.

Unfortunately, though, sometimes you need to plan ahead with fixed milestones given by customers, for example, resulting in a waterfall model. We opted for a straightforward resource planning overview using Asana with a timeline showing all milestones and assigning workloads to each employee with simple thresholds: Low (<30%), Medium (40–70%), High (80%>), and the goal of not having employees with a planned occupation of 100%. At least for our case, it didn’t make much sense to be more detailed as plans sometimes changed daily, and we needed to react instead of updating a meticulously designed plan.

On a side note, even if you don’t do resource planning on a team level, I encourage individuals to create time blocks for tasks in the calendar instead of just tracking their to-do list (watch this explanation).

Giving & Receiving Feedback

Conflicts will inevitably arise during any working relationship. It is paramount that you understand the nature of conflicts and confusion and build a good feedback culture in your organization; people will improve tremendously and be happier as a result.

I love the mental models and processes of Jeff Hunter about giving feedback. If you are frustrated about someone’s behavior or performance, it doesn’t mean they did a lousy job, but your expectations didn’t match reality. A good stepwise approach to deal with this situation is as follows (see Jeff explaining this here):

1. Assume that people surrounding you want to be great and improve — if you can’t do this, fix your recruiting process.
2. State what you think good behavior looks like and make sure you agree on your standard.
3. Get in sync about what happened, first understand how they experienced the situation.
4. Agree on the gap between the standard of greatness and what actually happened.

Only when the gap is identified should you be talking about potential improvements to eliminate this gap. As in any communication, be aware that you don’t necessarily know the truth and just give your personal perspective on the other person’s work and behavior. Also make sure you have concrete proposals in HOW the situation can be improved, incite a feeling of empowerment rather than regret.

In addition, don’t forget to also give encouraging feedback if a person exceeds your expectations — very powerful and too often overlooked. Ideally, positive and negative feedback is matched both in number and detail.

When receiving constructive feedback, remind yourself that the intention from the other person is (hopefully) to help you become great in your position. If you feel otherwise, there is a bigger cultural problem.

When you get feedback, don’t defend your action or find faults in the other person. Always be grateful first and try to fully understand the feedback context using Jeff Hunter’s framework.

In the next article, I write about the organization of the knowledge that is continuously created in your team.