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. I’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 aspect 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:

In our company, we experimented the last year with various setups of Cross-functional teams. These teams consist of members from different departments for a limited time to implement a specific goal. They do not have to be IT-focused, but coming from an IT background my experience is from being in and leading IT- and Product-focused teams.

If you are reading this setup guide, chances are high that you want to set up a new Cross-functional team. Awesome! This guide should give you a hand in where to start and what the main questions you and your team should discuss are.

Goal

What is the goal of the team? Most likely, it’s an implementation requiring close communication and high-level understanding of a specific domain.

When organizing the team, be clear what is expected of the team. The scope needs to be known by all in the team and by all external stakeholders.

In the first two weeks, bring it up often and repeat, so everyone can align on this. Repeat one time too often, rather than not enough.

Depending on how clear the goal is, it can be helpful to define a mission statement everyone can agree on. In discussions about the team’s direction, this can serve as a compass.

What is the goal of the team?
What are the must-haves and what are nice-to-have’s?
Which deadlines exist?
When does the team regularly end and how?
Under which circumstances can the team end without reaching its goal?
Can the goal be summarized with a generic mission statement?
And lastly, the fun part: what’s the team name going to be?

Side topics

When defining the scope, you will find topics that are core to the implementation and topics that are on the side — still on topic, but not required in the MVP. Identify those and put them on the side. It helps being aware of these topics and in discussions about scope, it is good to be able to point to this list to not get distracted. Over the course of the team’s existence, these topics may be revisited, as they gain more importance or as they become valuable as filler work in case the core functionality requires waiting periods.

Where to draw the line between core goals and side topics?
What freedom has the team in defining or redefining the scope?

Organization

Past cross-functional teams in my company have all tried to follow an agile approach, but it was up to each team to define what they meant by this. Some teams chose a structure like Scrum, others went for Kanban. If the team’s goal is well-defined with a deadline, even an approach similar to Waterfall is possible and can serve the purpose. Of course, hybrids can also be discussed. This can be interesting when it comes to communication and rituals. More on this later.

Does the team want to work towards one big goal?
What milestones can be identified?
Can the work be broken into iterative steps?
What steps depend upon each other?

Reporting

The team was set up for reaching a goal and somebody is interested in the progress towards this goal. There may be multiple stakeholders that need to be kept in-the-loop:

departments and their heads requesting the feature
management or execs
maybe a department is affected in case of success which is otherwise not involved over the term of the cross-functional team

Identify who needs to get what kind of updates and how frequently they should be updated. Schedule regular updates, so they don’t have to ask and can trust to get informed as the team moves ahead. This can be meetings, but — if agreed — updates by mail or other means may be fine as well.

If your IT developers have Sprint Reviews, ask to use this platform to inform a wide range of people about your updates.

Who requires knowledge of the progress of the team? Which departments, heads, management members?
How often should they be informed?
In what format do they want the updates?
Can the work presented in the IT Sprint-Review?

Roles

Whether the team is set up with one Tech Lead coordinating its strategy and implementation or with a flat hierarchy may be outside of the scope of the team. If this was not defined, it is up to the team to agree if they want to have a layered or flat hierarchy. In smaller teams, flat structures proved working fine.

One recommendation for teams with flat hierarchies is to define roles within the team. Roles may emerge automatically from the tasks, i.e. Developer and Project Manager. Even within a group of developers you will find small-scale responsibilities that are worth talking about in the team.

Either way the hierarchy is set up, the team should have one person who is the first contact for outside stakeholders. She should receive and distribute messages from and to the team. This does not mean, other team members are asked to not directly communicate to outside stakeholders, just that the team contact should be aware of the communication. Summaries are best practice.

The team can decide to assign one member to attend the stand-ups of the IT-Dev teams to be aware of their topics and identify when topics of both teams intersect. We are going to talk about the importance of retrospects below, organizing them could be another task for one team member. Another role could be somebody to remind updating tasks and tickets.

During the existence of the team it may happen that somebody goes on vacation. Remember to prepare handovers and assign replacement(s) for the roles in vacation.

What is the hierarchical structure?
Is there one Tech Lead or a flat structure?
Who is the first contact in the team?
Who organizes meetings like retrospectives?
Is somebody interested in attending the Sprint Standup?
Who is responsible for taking care the team keeps updating their todos and status?
Does anyone have leave planned during the existence of the team?

Documentation

Setup a Confluence/wiki page describing who is in the team, what the goal is, and how you organize yourselves. Any decision the team makes about its structure can be noted there.

After the team is done, this page is also helpful for documenting how the team was set up and about the learnings of the speedboat.

Who is responsible for taking care about the care setting up and updating the team’s Confluence page?
What topic should be documented?

Meetings

Be aware that different team members work on different schedules. People with Manager’s Schedule have their day split into many blocks due to meetings and context switches. People in Maker’s Schedule tend to have an empty calendar with long blocks working on one subject without distractions.

The team should discuss which regular meetings it deems useful.

Perform regular retrospectives within the team, to have a safe place where anyone can bring up a topic.

If your team lacks people experienced with facilitating this kinds of meetings, think about calling in outside help to get you started.

What daily or weekly update meetings does the team want?
How regular should retrospectives be scheduled?
Who wants to facilitate the retrospectives?
What meetings of the IT-Dev team does the team want to attend?

Codebase ownership

This topic very much depends on how the IT-Dev team and the cross-functional team are aligned on their goals.

The recommendation is to separate the codebase the team has to touch from the codebase the ongoing IT-Devs will work on. For the duration of the project your team may get temporary ownership of the codebase. The Dev-team may still do changes, but has to check-in with the team to ensure their changes don’t interfere.

Circumstances may demand both teams to work on the same codebase, which should be reflected in closer communication between the two teams. This includes talks about intentions (what does each team plan to do next) as well as review (reviewing each other’s contributions). Think about attending each other team’s standups, sprint plannings and inviting members of both teams to pull requests.

Which applications are included in the project scope?
Can the cross-functional team take ownership of these projects for the duration of the project?
How should the two teams announce, review and publish their work when working on the same codebase?

Communication

In the last few sections many aspects of communication were already addressed. The experience with previous teams was that this is the topic that can cause the most friction within or outside the team and motivated this document in the first place.

Difficulties within the team can be around ticket status or their lack of updates. Depending on the structure, pair programming may be encouraged to share knowledge and help problem-solving. Mix the pairs frequently, if two strong programmers pair often, they may progress rapidly ahead of others, making it hard for the rest of the team to catch up.

Define with your team how to handle people working remotely.

Make it clear, who to report to in case of sick leave. At the very least HR needs to be informed, writing to other team members is a courtesy.

Summaries (for example in confluence) of what happened when team members were out due to vacation or sickness are generally appreciated.

What are the expectations about announcements and visibility of Home office?
Who takes care of writing a summary when members return from leave?

Ending the team

The nice things about temporary cross-functional is their limited length. You can specifically plan the teams deadlines and use the last week for cleanup, handovers and documentation.

Have one final retrospect about the term of the team — and make sure you have a nice party! Document the topics the team worked on and the lessons learned in your team’s Confluence page. Talk with the IT-Dev-team, as they are likely interested in a summary of the team’s experience.

Similar to the beginning, it is important to align with the stakeholders again. Have meetings with the relevant departments to present how the team’s goals were met.

The scope of these presentations depends on your audience. Most departments are fine with a higher level explanation, while the IT-team will appreciate technical details.

Evaluate if the cross-functional team was worth it — afterall it is an expensive approach and answering this questions helps to make the decision, to setup a new team, easier next time.

Was everything done as expected?
What might be missing?
How do you deal with remaining side-topics?
What changes had to be decided on?
What departments should be informed about the results of the cross-functional team?
What are the lessons learned (technical, data or process-wise, organizational)?
How was the mood in the team?
How did the other team feel with you gone?
Was the team worth the effort?

Final remarks

Take everything I described here as a recommendation. The team you setup will be unique and is free to make their own choices. Feel free to come up with ideas that are not documented here.
Cross-functional teams are a great way of experimentation!

Tag: Product Management

The Not-Always-On Manager