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:

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:

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:

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:

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:

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:

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

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:

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):

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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store