The Weekly Dependency Chart

In the last 5 years I as Product Manager, I often found myself disliking the common ways on how to express projust status and deadlines. They’d either hide important complexity or are a mess to keep up to date. Over time have grown a visualizations technique and meeting format I call the Weekly Dependency Chart. This helped me get structure and overview in projects I inherited, that were complex, late or required reliable schedules. I applied this in several private and professional contexts succesfully.

The idea is to have a quick high level overview of timelines, to-dos, blockers all lined up in a weekly calendar view. Each item connected to the items it’s dependent upon.
Over time this graph evolved into a meeting structure, you can use to keep the overview up to date while synchronizing the status with the people involved.


My setup is usually in Miro, Mural or any similar whiteboard software.

It builds on a simple table: week number and staring date in the column head and a lot of free space below. Within each columns are the items containing the actual to-dos. Ownership is communicated by color (or texture if the software allows which is better for color blind people). A Todo-Note is to be put into week, when it should be finished. Finished todos are made 50% transparent and remain in their week. This way it’s easy to see what was accomplished each week and what is in the weeks ahead.

Todo-Notes are then connected with each other reflecting their dependencies. These connections show the dependencies.
This follows these simple rules:

  • Any to-do can be required by multiple other to-do.
  • Any to-do can be dependent on multiple other to-dos.
  • A todo-note can only be finished if all it’s predecessors have been finished.
  • No to-do can have a predecessor in the future.
  • Any to-do has one ultimate owner.
  • The current week is highlighted.
  • Past weeks may only contain finished to-dos.

Additional I like to add notes to the chart to provide context. For example marking deadlines, vacation times, holidays or milestones.

On a complex project, with many dependencies, this can become crowded, in which case I started splitting the week columns into multiple rows reflecting main workstreams or departments.

This chart is with projects in mind who have a clear end. As such you could have a final end card, that is only finished, once all dependent to-dos are done. Realistically, in my projects, in the final phase, as to-dos moved from the project scope into continuous development, the Weekly Dependency Chart (and its meetings) just end as it outlived its usefulness.

Meeting flow

Originally, I only used this chart for myself to get structure and overview into complex projects. As I showed and discussed this with colleagues, we began to integrate it into our weekly Jour fixes. Everyone having tasks in the Dependency Chart would participate in this weekly update meeting, together we’d maintain it and use it as the jumping off point for discussions.

As moderator, in the first half, I’d update the current week and ask every participant about their updates. Either they already have their to-do cards up to date, or this is their chance to update it life quickly, before giving a short progress report. No open to-do cards should remain in past weeks. If the to-do is not finished its card either has to be moved to the current or a future week. Dependencies on the card will have to move accordingly, and prompt a discussion, what the consequences to the project down the line are. This way you have a very easy tripwire to recognize upcoming issues in your project plan early.
At the end of this half, all todos of the past week have been marked as done or have been moved.

In the second half, we look at the current week with the question “With all the tasks, that have been moved, is this realistic to finish this week?” Todos tend to bunch up in the current week and this is a great visual indicator to see, how a project is lacking behind. In this discussion everyone can reflect, if the expected tasks are realistic to finish. Ideally the moderator learns over several weeks, how reliable the participants are in terms of delivering their todos and how well they’re time estimations are.
If the bunch-up can only be resolved by moving tickets to the future or removing tasks. This may result in discussions outside the meetings about the project plan. This meeting format is for identifying risks early. Only in small scopes, it is the right place to also resolve these.
By the end of the second half, you have all the tasks for the upcoming weeks moved ahead reflecting an ideal implementation path.

  • A To-do cards being required dependency of many other to-dos indicates a high importance to the project, a bottleneck and is a natural candidate for a milestone.
  • To-dos bunching up in one week are a an indicator that a review of the projects timeline or scope may be required soon.
  • Having many to-dos in a week that are dependent on each other indicates, that this week is very risky as interruptions can lead to re-scheduling easily.
  • If most to-dos are of the same color, it means one person is responsible for all. Maybe split the work in your team better?
  • Cards without dependencies are great as jumpers who can be moved ahead if people are blocked by other to-dos.

After the meeting, I like to do a screenshot of the visualization. This is not mandatory, but allows later comparisons between the current document and earlier expectations. This can be used as evidence for a later retrospective to discuss on why certain tasks took different times to finish than expected.

I made good experience of this meeting format with 2-6 participants.


I regards this visualzation as one more option in your toolbox, it certainly does not fit every occasion. It’s an opinionated simplification focusing on delivering reliability and synchronization.

There are several things, this does not do. First and foremost, it does not indicate how long a task would take. It only shows by what time it will be done.
While similar in approach to Gantt charts, the level of detail in both visualizations is very different. Gantt is more detailed, but takes much more effort to setup and maintain. The Weekly Dependency Chart makes it easy to shift to-dos and dependencies – something often a pain in Gantt, discouraging changes.
To people looking at Gantt charts, the rigor of the project plan may suggest a maturity/stability, that is often not true (in software projects anyway). It is easy to interpret the given time estimations as promises. The Dependency Chart simplifies to the most important steps and highlights the agility of the plan.

Lastly, the chart is best for a project with defined end over a span below 9 months with below 8 managing people. For bigger projects, it could be worth trying to break the project into smaller parts, that could fit the format again, but I haven’t tried that yet.
This is best used in a waterfall project, but can also applied iterative projects.
I wouldn’t use it for Agile projects or in combination with Scrum.


The Weekly Dependency Chart is a cheap visualization of tasks and their dependencies in a project. It’s best for projects of 6 people over up to 6 months. The chart offers a great basis for weekly jour fixes on the projects and gives a great basis for timeline discussions in risky projects.

  • Meeting format offers structured way to request weekly updates
  • Tripwires to discover when projects plans are at risk of running late
  • Easy updates encourage more reliable project status

The Not-Always-On Manager

Sunset over Etosha national park

When I started my first job I had a colleague who only worked 4 days a week and I knew, this is something I want to try too. So when I interviewed in my current company, a 36-hour workweek was one of the first conditions we agreed on. Working in Germany, this used to be a regular week length, but for over a decade 40 hours have become the norm. It was a agreed. As a developer, this never posed an issue. As I switched into Product and Project Management, I resisted the expectation to go full-time. What this decision meant for my work, I’d like to share with you.

Reduced time as a developer

Doing a 36 workweek as a developer was easy, because you can work quite independently. As long as everyone could retrace where I am, it was no topic. So I created my “Availability calendar” and put any home office or off hours at least a week in advance in there.

Getting asked if I want to extend my working hours became an annual ritual with my bosses with everyone knowing I wouldn’t do it. Everyone was happy with the arrangement, so why change what’s working.

When I became a Senior Developer I was cautioned — moving into a position of higher responsibility would also mean having to go full-time. We would talk about it when it becomes necessary.

It never happened. I became a Product manager on my 36 hour work schedule. Granted, I’m new to Product management with only 2 years experience at this point, and it was a gradual switch from engineering — no one questioned the existing setup. Eventually, before anyone could ask again, I’d shown the job can be done with my established time management.

Mini vacation once a week

I usually take my four free hours as a block. It’s easier to switch off for me and also for the company to track my work hours. The timing switched over the years though, it was Wednesday, then Thursday, now Friday. It depends on the sprint rituals and other recurring meetings I have to consider.

And of course it also depends on my hobbies. Or when I want to get a good sleep in. Or when I really need to do some household activities, or administrative duties. Being able to manage my private life’s necessities in the 4 hour I take “off” from work, means I have much less disruptions in my work schedule than the average colleague.

The effect of having a mini vacation should also not be forgotten or understated for that matter. I realize after working in this setup for years now, I feel much more refreshed and can perform better over the duration of the whole week compared to when I put in overtime and end up working the 40-hours. It makes a noticeable difference to me, and my company benefits from it too. Burnouts and keeping good mental health in creative jobs are recurring topic nowadays, and having shorter weeks can really help with this too. Everyone wins, yay!

What about my manager job?

It’s important for me that my personal values are reflected in my workplace and my position. Independence is one of those — for my own work and also my colleagues working proficient and autonomous.

As a manager I see myself as the one who enables other people to build awesome things. My task is removing any road blocks my colleagues may have. Being unavailable for a few hours every week, requires them to foster this independence. My colleagues can rely that I’m available on the given times. Outside of work, I leave my phone and Slack off.
If something is blocking them, they know when they can get their answers, or they are creative to work around it and find their own solution that they check with me later on.

This off-time actually helps to find these blockers and eliminate them, thereby growing independence and autonomy in the team.

Another aspec is Parkinson’s law. If you have a work and a given time slot, the work will expand into the time available. Working slightly less hours, forces me to do the job in shorter time and thereby focus on the priorities. And don’t even get me started on the negative effects of working beyond 40 hours.

Crunch time

This all sounds nice and well, but what about deadlines and launch dates? The usual craziness that can be product — I hear you asking.

Let me tell you about the flexibility that comes with a 36 hour arrangement. It’s actually like having a load balancer — when a big release is coming up, of course I pull my part and go 40 hours. I log these as overtime that I take off when times are calmer again. Again, this is about transparency, expectation and supporting the team the right amount at the right time.

From a company point of view, this load balancing has another effect: they have me as a quality employee slightly cheaper, since they pay less hours in total.

Studies have shown, that extra hours per week do not increase the actual valuable output. So I get paid for my working time and not for the additional hours, that creep in during a week. Meanwhile reducing time actually shows many welcomed side effects from health, productivity to traffic.

When does it end?

My current setup is comfortable and privileged. I’m aware that with rising responsibilities it may not hold up forever. At a certain management level, you are expected to be always on and as you care for your projects, you may want to be. Something is always in need of support and you do want to provide that. My goal is to keep on working on strategies to keep my arrangement for as long as possible.

Is this a privilege? Hell yes!

In my working live I inspired at least three colleagues to reduce and be more flexible about their working hours. I have two more Product management colleagues who work only four days.

When I’m talking with Engineering students and mention this, I can see their eyes lighten up. They never considered this option for themselves before. I know for most people in many industries it is not so easy to negotiate their hours. I hope by being transparent about it, I can help make it become a new normal.

So consider this as a topic for your next negotiation. It’s not always about the money, your time is valuable too!

Something to read on: