The Work Life Balance Myth

One question I got asked the most is "How's your team's WLB?"

I believe the answer (about my team's WLB) would stay the same no matter where I go. If you think this statement makes no sense, please continue reading...

Introduction

Work life balance (or WLB) has become one of the most popular topics in the tech world. I'm a strong supporter for healthy WLB on a personal level because I believe it is the foundation for sustainable career and personal growth. Recently, I also wrote an article recommending Stop Working Hard talking about how we should grow by working more efficiently instead of working "hard".

However, mastering the skill to work more efficiently does not stop someone from falling into the WLB trap. Usually people like to ask the question (or at least want to figure out) if a "Team" or "Organization" or "Company" has a good WLB before they join.

The Myth of WLB

Most people say that WLB is a cultural thing. They tag WLB with the company, organization, or a particular team. Using that mentality, I would have been suffering from bad WLB because neither my previous company (Amazon) nor my current company (Facebook) is famous for good WLB. I just checked a platform called Blind where Amazon scored 2.6/5.0 on WLB and Facebook scored 3.2/5.0 on WLB (as of 9/22/2021). On top of that, before I joined Facebook, many of my friends told me that the org I'm joining (Facebook Ads) has the worst WLB in Facebook and asked me to consider carefully.

In the end, I still joined Facebook Ads while picking one of the most critical initiative (Aggregated Event Measurement or AEM) within Ads to support. Following the common WLB myth, the team I'm joining would have the worst possible WLB someone can ever imagine (Facebook + Ads + MOST critical bet within Ads) and my WLB would be doomed.

Myth Buster

In reality, I have never really experienced unsustainable WLB during my 8 years at Amazon (Prime Tech). After joining Facebook Ads, I never suffered bad WLB even though I am supporting the MOST important projects (AEM) I've ever worked on in my life.

If you don't trust me, I started writing this article at 6 PM on a Wednesday after enjoying my delicious dinner. I am drinking a bottle of tasty beer and typing on my couch. After finishing my writing, I plan to chat with my wife and enjoy some snack before bed. There is always work to be done, however, nobody is forcing me to work overtime so I am allowed to choose when to work on them. I believe this is a pretty good WLB! Not only am I doing this, I'm doing everything to make sure my team can work regular hours and enjoy their life.

Really?

Of course, I have heard numerous scary stories about WLB. I always consider myself as a lucky person who never had to suffer unhealthy schedules. In theory, bad WLB can happen anywhere, not just some of the "bad WLB companies" or "bad WLB organizations". I've seen teams turning the direction and drastically changed their WLB in the past. At the same time, regardless of which company, organization, or team, there exist good and bad WLB.

Nothing is absolute and everything is relative. However, people are biased, e.g. some said "I know WLB is bad at X and I won't consider any opportunity there" because they heard about it from their friends. Once such bias is formed, people tend to put a stamp on any team within the company or organization instead of looking at the specific group of people.

People Matters

Some people asked me, why am I so lucky all the time? Some even think I'm slacking or NOT doing my job. On the other hand, I believe I'm a high achiever in heart. However, I don't like to build my achievements by sacrificing my WLB or my team's WLB.

First of all, I do follow the recommendations in my own article of Stop Working Hard. I chose to NOT over commit myself on methods that do not scale or do not help with me or my team achieve long term growth. I might have burnt some mid-night oil once in a while myself when I felt it was absolutely necessary but I won't treat it as "normal".

Most importantly, I chose to work for and work with PEOPLE who share the same belief. Recently I made a post about finding the right leader which explained this philosophy.

Companies, organizations, and teams are abstract concepts that do not make sense without the people in it. The culture, ethics, methodology, and etc. are defined by the people. Therefore, as long as we have the right group of people, partners, and leaders, we are able to define, influence, and change anything, including WLB together!

This concept seems straightforward but is not commonly accepted or applied in practice. 99% of the time I was asked the question about "How is your team/org's WLB?". The more appropriate question should be "What is your team's opinion / your leader's opinion / your opinion and methodology on managing WLB?" This is why I said earlier that "I believe the answer (about my team's WLB) would stay the same no matter where I go". People matters, not the team!

How Did People Destroy WLB?

Balancing cost, scope, quality, and time

I'm going to borrow this image (on the right) from R. Max Wideman (link) to help illustrate the idea. This diagram has many different forms and it does not really matter which one I use.

The idea is that, when managing a project, we usually need to make trade-offs between multiple parameters. In this example, the parameters are: Scope, Cost, Quality, and Time (some of the diagrams combined scope and cost into a single parameter).

This concept of project management can easily translate into managing a team, roadmap, planning, and etc. When managing a team, we have to balance between the scope (e.g. how many features do we release), the quality of the deliverables (e.g. automated test coverage), the timing of the launch (e.g. Q3 vs Q4), and the cost (e.g. number of engineering hours to fund the project).

In most cases, cost is harder to manage comparing to scope, quality, and time. Most engineers are super talented people who are experts when thinking in terms of design, implementation, testing, and etc. but they rarely think hard enough on trading off the cost. There are different types of costs but most important, the cost of people (i.e. number of engineering hours) matters the most when we talk about WLB. Unfortunately, most of the time, WLB is doomed because team (especially the manager) chooses to focus on increasing the scope, quality, and time even though they are under funded (i.e. under estimated the number of engineering hours required to achieve them). Without breaking promises (that we will launch feature X by date Y with quality Z), the easiest way to make up for failed planning and project management to make the team work harder (i.e. increasing number of engineering hours). Kept on doing this (trading off cost for scope, quality, and time), WLB is going to be doomed!

How to Maintain Good WLB

While I'm not the expert, I can share how I manage WLB for my team and myself. You would be surprised on how simple it is. In fact, I would say 99% of the managers could do BETTER than me. The first secret is VERY simple: Underpromise and overdeliver

To have a perfect execution, first of all, we need to plan conservatively. If we have 10 people available and each of them can work 40 hours a week, the maximum we can plan is 400 hours per week. On top of that, we need to subtract planned vacations, possible sick days, meetings, oncall, reserved capacity on handling emergencies, buffer to make mistakes, time for people to learn new skills, try innovation ideas that might fail, and etc. After the subtraction we would only get X hours left (exact number depends on the team and project). When making a commitment, plan for X hours of work, not 400 hours! I have seen some aggressive planning examples in the past that did not reserve capacity for ANYTHING at all which completely destroyed either the project or the team's WLB.

The second step is to follow the basic project management concept of making trade-offs mentioned earlier. If we only can afford X hours, trade-off on the scope, time, and quality instead! We should never make up a bigger X than we have unless we get more people! I have seen people artificially making X bigger instead of following the basic rules. For example, "let's assume nothing goes wrong" or "in the best case scenario, this would only need half of the time". Making optimistic bets instead of doing the proper trade-off is another way to say "we can only afford X hours but let's assume people can work extra hours if anything goes wrong".

Even if we did everything mentioned earlier, things can still go wrong. For instance, we could have reserved less than expected amount of time for "something might go wrong" or "something that originally cost A hours now costs 5A hours and there's no room to drop anything". Other than always perform retrospectives on what went wrong and try to avoid the same mistake next time, the last secret is to know when to ask for help. Things can go wrong, almost all the time, and our leaders and partners usually stand behind us when we need them. If you don't have leaders or partners to support you, you might want to consider moving to a different place.

Recently, I was in a situation where my team could only offer X hours for something that required Y hours (where Y is about 2X) based on the timeline, scope, and quality required. When there's no room to trade-off further, the only option I had was to increase cost (i.e. we won't have Y hours even if we dropped all other projects we have). Having no tricks inside my pocket (I was not able to double my team size within a few days with new engineers ramped up and ready to work), I decided to reach out to my manager and partners for help. As a result, I was overwhelmed with the support I got. Engineers from my neighbor teams started to jump into our team's work by trading-off scope on the organizational level (i.e. they have to drop / delay projects on their end that is possible to trade-off vs the projects we have to launch). In the end, we were able to stay on track without forcing anyone on my team to work double shift while keeping the entire organization focused on the right priority on the organizational level. Again, I am a lucky person who is fortunately to work with such an amazing group of people!

I could have handled the above situation differently which won't end so well (from a WLB perspective). For example, I could have said "Hey team, look, this is SUPER important because ... and I know this is a stretch for us. Therefore, let's work hard and get through this together before we take a break". The result would be terrible WLB for the current period as well as significantly damage the team's moral or even creating retention risks. Besides, in reality, there won't be any break! There's always going to be more work for us to do! Having more work than we want to do than what we can do is usually true for 99% of the teams. Fortunately, I don't have to go through this because I am in the right place with the right group of people who understand that we need to prioritize ruthlessly.

The Last Trick

The last secret I have to offer today is that, if a team is constantly suffering from bad WLB, it is usually an indicator of under-staffing (or in other words, aggressively planning). Use the data point (of bad WLB) to indicate that the team needs more funding and either hire more people ahead of time or drop projects that cannot be funded instead of pushing the load to the team unrealistically. It is the job of a leader to hire and build a team that can grow in a sustainable way. The cost of bad WLB is MUCH HIGHER than sprinting through and achieve some short term goals in the long run.

Join Me

If you like my philosophy, you can always decide to JOIN ME! Regardless of where I am right now, as long as I'm still working in leadership, it means I'm HIRING!

Hung Nguyen

Software Development Engineer @ Amazon Prime Science

3 年

This is really a great article. With a good manager like you, any of your teams will have such a good WLB and that brings more productive to the whole department.

回复
Yin Deascentis

Product Operations @ Meta | Data Analyst & Project Management | Six Sigma Black Belt | Solving Product Development Operation Problems with Data Driven Strategies

3 年

??agree! With a supportive leadership and teammates, it will also make the WLB easier to happen. One more thing I learned from years of terrible WLB is that working with my strengths.

回复
Jerry Luan

"Life is either a daring adventure or nothing."

3 年

Strongly agree with everything you said! Except for beer and snack before bed. My WLB is also independent of company and team. I balance it myself.

回复

要查看或添加评论,请登录

Wolf H.的更多文章

  • Learn NOT to Say No

    Learn NOT to Say No

    In this article, I'm going to share my thoughts on how to be a Yes Man just like the 2008 movie. Most people hate…

    1 条评论
  • Stop Working Hard

    Stop Working Hard

    Really? What do you mean by stop working hard? Introduction In the software engineering world, I have seen statements…

社区洞察

其他会员也浏览了