Why do we work remotely?
At the time of writing it is year 2019. Yes, 2019. Not 1819 – the middle of Industrial Revolution, not 1919 – when the Hours of Work (Industry) Convention was established, but 2019.
It was just few months ago when we celebrated the 50th anniversary of the first man landing on the Moon. World Wide Web was invented 30 years ago, and Internet has been publicly available and commonly used for about the same time. Today, 99,9% of European households have access to broadband Internet. Google is over 20 years old, Skype – over 15 years, Slack – 5 years. Over 85% of population in Europe has a mobile phone and the average mobile penetration rate is near 125%. And on my phone alone I have more than 10 communication, messaging or videoconferencing apps. Communicating on a distance has never been easier.
At work we rather use a laptop, which is today a small and relatively inexpensive device, rather than operate a power loom or other heavy machinery of prohibitive price. Yet there is still a widespread concept of coming to
a factory an office, as it used to be 200 years ago, and spending there 8 hours per day – a limit commonly adopted around 100 years ago.
To be fair I acknowledge the fact there are some companies which core business is to build, program or use sophisticated machinery or specialised equipment which is available on-site only. Even then not all the work requires continuous access to the said equipment. If we think of startups this case is rare and I was not be able to find more than very few examples. Some others may need to physically limit access to their computer systems due to security or confidentiality reasons. This is more subtle. Sometimes it is perfectly well justified and I personally worked in few places of this kind and know of few others. However, they were all industrial or production plants of some kind. Often, security and confidentiality are used as a mere excuse for not setting up a VPN access and I have seen these examples as well.
The companies, especially startups, in order to attract best software developers compete in “what cool amenities we have in the office” and the “modern, open-plan office” phrase still appear in job ads. I admit, the latter phrase seems to be less often these days. It does not change the fact that “an office” in most cases means “an open-space office”.
If we think of software development (data engineering, data science and business intelligence are or make heavy use of software development), and put aside the above mentioned exceptions, what can really be the reasons to do it in the office?
I bet most of answers to this question would mention either productivity or communication. Or both.
Both of these answers are wrong.
Being in the office is not the same as working
I suppose the conviction of higher productivity in the office may come from making (unconsciously) equality between “being in the office” and “working”. Or rather the other way round: “NOT being in the office” and “NOT working”. Interestingly enough in the office amenities competition companies seem to acknowledge the fact that people will not work all the time they are in the office (which, of course, makes sense). One of the adds coming from one of the quite successful Berlin startup says: “Hang-out in one of our many shared spaces, playing games with colleagues or enjoying a full range of events, including workshops, on-site meetups, guest speakers, and fun events (…). Sharpen your PlayStation, ping pong, and kicker/fußball skills during breaks in the day.” In fact what they say is: “we want you to be in the office, you can do other things than working there”. Presence is not equal productivity.
People can efficiently perform mental work which require high focus for a limited amount of time. Then a break should be taken. Different sources give different numbers for this limit, but certainly there is a limit. And it is much lower than the total of 8 hours per working day, even if split into to slots of ~4 hours each. After this time is exceeded the efficiency drops drastically, and on longer term so-called burn-out appear. Of course, we can make a stretch and work hard 8 or 10 hours per day, for a day or maybe three. We would need a relax after each of these stretches though, so the consecutive days we would work either shorter or less efficiently. The average gain on a longer run will be around 0 and may be even negative.
So, if one requires people to come to the office for 8 hours it is wise to assume they will not be working all that time or will not be working efficiently. And it is also due to the fact the most popular open-space offices decrease the productivity. But why to require people to spend 8h in the office then? This looks very much as an XIX century concept of 8-hours working day. Except we do not work physically in factories, in XXI century we do completely different work. XIX century ideas, commonly adopted in industry 100 years ago, do no longer apply.
Instead of saying “come to our cool office and stay here 8h or longer, play kicker or PlayStation” it would make more sense to say “use your 5-6 hours of productivity best you can, when you like, where you like and do whatever you like with the rest of your time”.
It is trivial to calculate that people who stay home save 1-2h per day on commuting to and from the office. They can use this time to do whatever they like. Obviously, this would improve so-called work-life balance and generally make them happier. And with positive attitude comes better productivity. Win-win situation. But there is more. Many of these people spend some of the additional time on… doing more work. And this is an instant gain.
Fortunately, there is more and more organisations which realised the need for a change and the clear benefits coming from flexible work arrangements. We want to be in forefront of that change and that is why why adopted fully remote working style. It is just better for everyone that way.
Don’t expect magic from dbt and don’t expect it will fix all your problems. Instead, expect to get a stable framework that makes your project as simple as possible. The only side effect of simplification I noticed is that I face much fewer problems and the ones I encounter are usually simple to debug. Bear >>
That’s dbt? WOW!
If you’re data enthusiast, it’s definitely worth trying. DBT (data build tool) is relatively fresh (v. 1.2) and open-source tool that perfectly fills the gap in data engineering stack. It’s dedicated for data engineers that love to code and hate to drag-and-drop. Particularly, for analytics engineers that work somewhere between data engineers and data analysts >>