It's not something I think people often think about.
I'm sure everyone thinks the way they are at work is 100% genuine (with a few caveats of course) and any deviations from a 100% authentic behaviour is expected because there are social norms to uphold and you don't want to make people uncomfortable when you don't abide by them.
Right? Sure.
So this week this idea of "Bringing your whole self to work" came to mind because of my new 100% remote-first team.
I recently started mentoring a young junior developer who wanted to learn about DevOps and Cloud Infrastructure Engineering.I heard the saying "teach once, learn twice" where in teaching something, you learn the subject better yourself once from my martial arts teaching long ago, and I agree.
The mentoring experience gave me an opportunity to dive into and examine what DevOps is, how it's supposed to be used and more importantly in my opinion, how and why it fails out in the real world.
Projects have a lot of moving parts. This definitely includes the technology landscape (understatement of the year), but also a big human resource factor as well. I think if you've followed any of my writing and experiences you'll know that "people" are (always) often the big under-estimated factor in my whole I.T. career - but that's probably a post for another time.
I've worked in the Project Delivery space for almost 10 years now. I'm not even sure that's an official "space".
All I know is, for almost a decade I turn up to the office (remotely more recently) to work on projects the company is trying to get to market.
Projects are a funny phenomenon in business, and I'm not sure everyone has the same take on them.
To tell you the truth legacy systems have been the bane of my career. The technology is outdated, limited, often restricted by surrounding legacy systems and then vulnerable security-wise. Often in my role I'll be tasked with figuring out and delivering a re-configuring, upgrade, migration of old applications, using old software running on outdated operating systems.
What often makes it worse is that the system you're looking at won't have any internal documentation about how it was setup. No worries, I'll Google a manual or the vendors documentation. This usually turns out to be either non-existent, outdated, limited to the point of being completely useless, or the wrong i.e. the documentation doesn't line up with what you're running.
This is usually only the beginning of the challenges you face dealing with legacy systems.
So, why. Why is it like this?
Balance is good. Balance is also a myth.
You need to work.
More than just to pay the bills, you need fulfilling work. There's a healthy amount of blogs out there explaining why the work needs to be fulfilling, but I'd like to just look at work as the thing you do during your day.
Life. That's the thing you do when you're not doing work.
So we're clear. On one side you have work. On the other is "life" (no in speech bubbles so you know I don't mean living and breathing).
One thing I used to see a lot of when I was a permanent employee, and experience myself, was the pressure to deliver some pretty crazy project requirements in a short amount of time and the stress management that needs to happen alongside it.
By "time", I mean the 40 hours a week you are paid for. This lead to people working some crazy extra (read "free") hours worked to deliver things. I put free in quote marks because while the project and the company might think they got a massive amount of work for half price. But there is always a cost to anything, it's just not always money up front.
Having worked in I.T. for over a decade, in my experience ego is very much part of the technology landscape. I've had the privilege of working with and learning from some really smart people.Unchecked egos and badly managed expectations create a hostile workplaces people who could knew the ins and outs of obscure Unix systems and could work out IP ranges with a subnet mask or slash notation (I still suck at this).
If you work in an office, especially in I.T., a big part of your day is problem solving and trying to do some "deep work".
You don't need a study or a statistic to know that there are an ungodly amount of interruptions that take place in your average work day. But here's an excerpt from a study anyway:
A recent ethnographic study in an IT support organization revealed that workers spent an average of just 11 minutes on a task before being interrupted or moving on to a new task, and more than half the interruptions (57%) were unrelated to the task at hand.
Nothing achieves getting less productivity out of your workplace like being constantly interrupted by emails, instant messaging, phone calls or the (not all the time) dreaded "shoulder tap".
But it's a 2 minute question, you can just get back to it straight away right?