Some time ago, I was discussing with a developer friend who is bored at work. He confided that he had been working on the same things for years and was fed up. He had been thinking about leaving the company he was in for several years. Why do you stay? I asked him. He replied that the salary wasn’t too bad, the employee benefits were rather good, and that with his house loan, he couldn’t be too picky.
How sad! Me, who spends my time trying to move walls, even tear them down (as a good messenger of DevOps culture), I have a hard time understanding how one can stay in a position that doesn’t please them, dragging their feet every morning to come to work. How has IT in general, which was a field of passionate people, evolving in proportions that no other field knows, been able to create subsistence jobs, to which we cling out of fear of not finding better?
What can we do about it?
The first question to ask is “How can an IT job be boring?”. Let’s look at the case of developers: What creates their boredom at work?
A large part of developers embraced this profession by vocation. They were geeks who embarked on the adventure with the promise of learning lots of things every day. Except that since then, something went wrong. They stopped finding in the profession what made their hopes. Many of those I met started full of enthusiasm, proposing all sorts of things to improve things. But they encountered walls of:
- “We don’t have the budget this year”
- “It’s not possible, it won’t work”
- “It’s not in the technically validated technologies”
- “We don’t have the skills to maintain that”
- “With everything we’ve already spent on the current tech, it would be a shame to change!”
The bitter manager when we propose an innovative idea
Their enthusiasm was dampened by the inertia of corporate decisions.
The same goes for sysadmins. How to get passionate about infrastructure that is content to reproduce the same patterns for 15 years? What’s the point of trying to innovate in a field where no one wants to change? So we resign ourselves, we give up. We content ourselves with doing what is expected of us, even if it means waiting for the evening to work on things we like.
That’s where we need to change things. Because on the contrary, I’ve known a team where all major innovations and good ideas had the right to their prototype. The members of this R&D team were all super enthusiastic guys (and girls). In the end, the team was trying out all the cool technologies in a generalized good mood but produced nothing, because each prototype, once completed, was made obsolete by a new technology on which the team switched. This amusement therefore cost very expensive for very few tangible results (the prototypes still served as a basis for some projects).
So, from my experiences, I realized that freedom in technologies must be dosed to work. An excess in one direction or the other, and productivity suffers.
Freedom or no freedom?
We must therefore find a middle ground. And this middle ground, I found it in a company where I worked for two years. Teams and sub-teams by profession were made responsible for their productivity. They had technology freedom in their respective domains, but had to expose the reasons for their choices to the whole team (~30 people), when it came to bringing new ideas into the IS. Most of the time, choices were reasoned and motivated by positive evolutions and were validated with full confidence.
Teams thus worked on technologies and concepts they appreciated and were convinced of their effectiveness. Productivity was at its maximum: I remember having merge conflicts with a colleague, while we were working on the same branch, at 1 AM, each from home via our VPN connections, just because we both had ideas to evolve the infra. When we talk about maximum productivity… Working at night for fun, that would make more than one pale!
There was also in this framework time arranged for ideas that could benefit the business, in the form of half-days where everything was possible, where anyone with an idea was free to propose it. Any idea that convinced at least three people had carte blanche for its development on these half-days.
Everything was done in trust and we encouraged team members to bring things rather than forcing them to do what had been decided without them.
One of the keys to happiness at work?
When we appreciate what we do and have freedom, we learn new things. And when we learn things that interest us, we don’t get bored.
- We stay alert and eager for new skills.
- Time passes faster.
- We don’t look out the window.
- We don’t complain when a new task appears.
- We come home in the evening exhausted, but satisfied with our day.
In the morning, when we wake up, we already have new ideas in mind, often arrived during the night, to solve a problem encountered the day before at work.
In short, we create happiness at work, which is no longer seen as a burden, but as a game. A responsible game, of course, with rules and business and commercial objectives, but a game nonetheless.
Think about adapting this reasoning to your team.
All teams are not alike. The backgrounds of its members, their age, their aspirations mean that there is no method applicable everywhere without adjustment. Some may not want what I propose here, or may not be aware of the interest it would bring them. Others won’t dare say it.
The framework in which I had a happy experience of this idea was a framework where most people were under thirty for most, with also some people over 45, but with a playful child’s soul always very present.
You can propose things, and this regardless of the size of the company. You don’t have to be a team manager either to have ideas. Good ideas come indifferently from hierarchy as from teams and those who compose it. Waiting for everything from your hierarchy is more a source of frustration than anything else.
In any case, of all the environments where I worked, those that applied these principles are those in which I spent the best years of my career. And also the most productive.
I found it useful to share this with you.