The Journey of a Philologist in IT
May 12, 2020
Ioana Miron

Have you ever been on the receiving end of micromanagement? You know, the MO of strictly controlled, rigidly hierarchical structures.

It usually goes like this: you get to work, ping your badge, trudge your way around cubicles, drop your stuff. Turn on your computer, log into the five different systems that track your time and your work. You let the system know when you’re on a 10-minute break, a 30-minute break, when you give or receive feedback – there’s a dropdown with all these options.

Big Brother knows or can infer when you use the john, smoke half a cigarette or gobble down your lunch. IngSoc would be proud.

In the opposite corner, we have the utopic picture of a fully autonomous team, a well-oiled, well-managed, delivering machine that doesn’t even need a manager that much. And then we have, of course, everything else in the middle.

It’s hard work to even get on the radar of such idealism and it’s not a clear-cut matter of culture or leadership. In, I believe culture plays a major part, but it also depends on what values of that culture are understood and reflected by the leaders of each team, and how team members resonate with them. Below is my journey from this point of view, with its most important milestones.

Bye-bye ComfortZone

Changing jobs is one of those things that grabs you by the neck and hurls you miles away from your comfort zone, especially if you’re a creature of habit or a perfectionist. Or both.

We’re talking about trivial stress triggers, one the one hand, such as finding the optimal route from home to the office, or matching the face with the name of tens of different people every day. On the other hand, you have the major stress triggers, such as …uhm, not having a clue how anything works.

However, you learn and adjust and six months later (or sooner) – you’re on a roll. You no longer twiddle your thumbs awkwardly by the coffee-machine because you have no idea what is wrong with it – you fix it, and occasionally pull off one of those three-layer affairs.  

Latte in hand, you crack five different inside jokes with people from different departments on your way from the kitchen to your desk. On your computer, everything is neatly stacked away in Quick Access folders or bookmarks. You no longer ask fifteen hundred questions an hour – you answer them these days. You’re knowledgeable and efficient, and honestly, that’s where most companies want you to stay: on the plateau of your recently rediscovered comfort zone and productivity.

Autonomous teams, however, don’t shy away from threatening the comfort zone, because for all its coziness, that’s exactly what it is – a plateau. Learning, experience and ultimately, personal development, come out of those slightly uncomfortable and high-strung times when you jump at an opportunity not knowing for sure what lies ahead. And the leaders of autonomous teams will encourage that – will encourage you – over the security that your plateau brings to the company. The second team I worked in constantly challenged me, at the same time backing me up and offering advice from their experience.  

Own It, And Some More  

Moving from autocracy to democracy, first thing you do is bask in the light of your new found freedom and enjoy being treated like an adult. Soon enough, however, the rude wake-up call happens, in the voice of Uncle Ben: with great power comes great responsibility.

You have to do your job without micromanagement, and come what may, own it, right? This is continuous ownership, the traditional concept of “job description” – devs gonna code, QAs gonna bug, BAs gonna analyze.

However, one of the things I’ve noticed makes a team more autonomous is when team members take turns with ownership for other things, on the fringes (or 50 light-years away) of their job description – why don’t you organize that meeting? Why don’t you give a kind reminder for people to do code review, or put a counter on DEV environment until go-live, just in case people forget (as if they could)?

You can start with baby steps,like above, and then move to bigger things, like throwing your job description out the window and defining your own unique role in the team – devs not only gonna dev, they can also do professional handover to support teams and constantly document useful scripts,procedures, corner cases. QAs not only gonna bug, but also do demos, write release notes, user guides, training materials. All three teams I’ve been in give free reins to this – you just have to pick them up and steer your career in the direction you’ve always dreamt about.


Meet John Doe, star of the team: experienced, efficient, multi-tasker. His credentials give access to GitHub, BitBucket, Azure and about 5 different servers, his knowledge spans from business to technical and he tops it all up with a great attitude.

However, he can also be a light-headed, clumsy fellow at times, so next thing you know he falls off his bike and breaks his leg. Comes round the office once so we can all autograph his cast and then medical leave ensues for the next two weeks.

Autocratic teams are dealt a real blow at this point, because there aren’t many people who can do all the things that John could. In an autonomous team, however, Jane Doe steps up and with the help of other team members, takes over John’s tasks. This is because autonomous teams encourage continuous learning, knowledge sharing and deputizing.

This means that occasionally, two people will be doing a job for which only one would have been enough, and it can potentially take longer, too (what with the supervising and explaining). However, in the long run, this translates into more knowledgeable and independent team members and into allowing people to grow out of their current position. Deputizing can also tap into unknown potential and bring it to the surface. You never know when a QA with great business understanding might slide into BA, or when your UX Designer picks up on Angular.

Talk to the team