Tales from the Machine Room


Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register


Techs or Manager

Warning: this is not a "tale". In the sense that I'll write about my previous workplace and will refer to fact that did happened, but there is no 'story' behind.

I'll explain a bit better: as you had probably understood (sic) I wasn't much of a fan of the guy that was acting as my "boss", but he had his own reasons to do what he was doing. Reasons that explain his actions, but are no justification. If you decide to rob a bank, you can explain that with "I wanted the money", but that doesn't justify you. It simply explain why something is done the way it is done.

And to explain why my "boss" wasn't doing anything "boss-like", we have to go back in time and talk about how, in general, a firm is created and come to exists. Every firm, not just IT companies.

When the place that would have been, one day, the company I was working for, was created, it was because of an agreement between two peoples. The one that would have been the Big Boss (BB), that had money and saw a way to get even more of them, and the one that would have become the CTO that had lots of technical knowledge and wanted to keep playing with his toys: BSD and computers. The two reached an agreement.

BB began to put together a group of software developers, project managers and graphics and put them to work building websites, CTO began to build the infrastructure where the websites built by the other side would have "lived". When CTO realized that the amount of work was too much for just one person, he hired a few peoples, but kept doing the technical stuff and basically trusted the other peoples in doing more or less the same.

Now, if you are smart, you should have realized the difference in the approach of the two. One was acting like a manager, the other one as a technician. CTO remained a techies at the core. When a problem was presented he was thinking how to develop or twist software around it, while BB was thinking more in the line of "who can we hire to tackle this? do we need to do it? what does the contract says about this kind of things?". It's a completely different way of thinking.

Attention: I'm not saying that one is correct and the other is wrong, but they are really different and depending on the circumstances one of the two works better than the other.

Then, one day, BB decided that it was time to take a step forward, he joined forces with a few other peoples with money, and the whole thing turned into an Holding. Basically, they started buying whole companies, acquiring the whole customers base and the personnel that was included with it.

CTO suddenly found himself no longer at the "head" of an half a dozen techies, but at the head of several departments, with about an hundreds peoples that he never saw before. And discovered that he really needed to start doing CTO stuff and stop playing.

At the same time, somebody had to step up and take the "leadership" of what was the old group.

That somebody was DB, that was (I think) the one that was hired first in the original company.

Now, putting DB in charge was a logical action, unfortunately, more than the logic of the action CTO should've checked if the thing could work in practice. The problem is that the job of a techies and the one of a manager (or Team Leader, that is the same at the end) are very, very different.

Long, long time ago, I read a fantasy book, don't remember the title but it doesn't matter. In the book at one point the old wizards that was training his apprentice told him "if you want to be a wizard, you must to be a wizard". The sentence doesn't make much sense at first sight, but the meaning is clear. If you want (or must) be a certain figure, you must begin to do whatever came with that figure. The task of a soldier is to fight the enemy, the task of a general isn't to fight the enemy, is to tell the soldiers where to go, and who to fight and for how long.

The task of a manager is to manage the work and give orders to the personnel, not to do the work. That's the personnel work.

A manager must:

  1. decide which activities have to be done and the priorities.
  2. decide who of his personnel is better to assign to which tasks and with what priorities
  3. get the fuck out of the way and let the people do the work
  4. check if the tasks have been completed, what problems there are and who to kick in the ass
  5. goto 1.

Having been a "team leader" and "lead developer" for some time, I can say without doubt that... IS NOT FUCKING EASY!

Seriously, the work of a manager is a lot more stressful than the work of a techie and it requires a lot of discipline to be done successfully. You have to be able to organize your own work, and the work of everybody else in such a way that every task connect with every other tasks in a perfect Tetris game to maximize the score.

You have to take care of every possible thing and the way they can (and probably will) go pear-shaped and how to minimize the problems.

You have to consider how to have your personnel "grow" without pissing them off or frustrate them uselessly and without disrupting everybody else's schedule.

And you have to keep repeating yourself that NO, YOU SHOULD NOT DO THE JOB, YOU HAVE TO HAVE SOMEBODY ELSE DO IT. It's too tempting and easy to say "I'll do this, it will take less time". If nobody else is in the condition of doing it, it's time to spend some time sharing some knowledge or thinking about extra training for the rest of the team beacause YOU ARE NOT ETERNAL.

And you have to know your personnel, know who is good at what and not-so-good at what, know what much you can ask and when. And you have to learn how to distribute tasks between different peoples.

And lastly, if you ask one of your techies a technical opinion about something, FUCKING LISTEN TO HIM. Maybe his opinion is exactly the opposite of what you want to ear, but maybe he is right.

All this is, in one word, "do the manager". And as you probably understood, it's the opposite of what DB was doing/wanted to do.

So... What happens when a techie is moved to a "management" role and he doesn't understand that his role now is not to do the techie with a different name? Well... It happens what happened to me.

I'd report to the "manager" problems that were related with organization and so "management" (task X wasn't done and now we are behind schedule, task Y need to be re-done because it sucks and nobody checked) while DB was looking for technical solution (we can use that tool to organize the tasks, we can use that software to check that thing...) instead of applying organizational, so management, solution (assign the task to somebody and CHECK IF IT IS DONE, if not, KICK HIS ASS).

The end result is that somebody, at some point, decide to get out of the door.

One of the funny (in the not-funny sense of the term) thing was that at one point DB asked -me- what he should have done about a problem. To which I replied that he had to do his job: do the manager. And to his comment that wasn't that easy I replied, deadpan, that "if you don't want to do the manager, go to YOUR manager (that I've no idea who is and I am also not interested in knowing) and tell him that he have to pick somebody else for the job".

Because that is the only logical thing to do if you get tasked with an activity that you can't do and you are not interested in learning.

Davide
02/07/2017 13:36

Previous Next

Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.

6 messages  this document does not accept new posts

Bio

By Bio posted 02/10/2017 18:43

Citando questa frase:

E' troppo facile dire "questa cosa la faccio io che ci metto di meno"

Non posso far altro che confermare tutto quello che hai scritto..gestisco i miei 3 colleghi quando il mio DB é assente (ormai é da 3 mesi in trasferta da un cliente, cosa successa anche negli anni passati) e ogni volta mi accorgo sempre più che il lavoro di gestione non riesco a farlo...

bio -- Bio


Il solito anonimo codardo

By Il solito anonimo codardo posted 03/10/2017 10:51

Va anche detto che manager si nasce, non si diventa. Puoi farti tutti i corsi che vuoi; mi pare che ci sia perfino la laurea in mannaggiament... ahem, in management aziendale; ma se non hai i proverbiali attributi - soprattutto per quanto riguarda organizzare il lavoro degli altri - non sarai mai un man(n)ag(g)er.

-- Il solito anonimo codardo

Francesco

By Francesco posted 05/10/2017 09:48

Ciao Davide,

    di questa vicenda ha colpito una cosa: la sensanzione di un ambiente senza compunicazione tra livelli non contigui della primaramide, una dei peggiori sintomi di disorganizzazione di una azienda.

 

 

Ciao

  Francesco

 

   

-- Francesco

Grogg

@ Francesco By Grogg posted 07/10/2017 14:57

    di questa vicenda ha colpito una cosa: la sensanzione di un ambiente senza compunicazione tra livelli non contigui della primaramide, una dei peggiori sintomi di disorganizzazione di una azienda.

 

 

Compunicazione???????frown

-- Grogg

Guido

By Guido posted 09/10/2017 08:40

Il compito di un Manager, e' gestire il lavoro e dare ordini al personale, non fare lui il lavoro. Quello e' il compito del Tecnico.

Verissimo, pero' un manager che non sa una cippa del lavoro che deve dirigere e' peggiore quanto (se non di piu') di un tecnico che si mette a fare il manager...

-- who uses Debian learns Debian but who uses Slackware learns Linux

Anonymous coward (yep)

By Anonymous coward (yep) posted 19/12/2017 10:29

AKA il Principio di Peter (Peter Principle)

Lo trovate nelle migliori wikipedie ;\)

« In una gerarchia, ogni dipendente tende a salire di grado fino al proprio livello di incompetenza »

CYA

-- Anonymous coward (yep)

6 messages  this document does not accept new posts

Previous Next


This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.


This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.

This site isn't optimized for vision with any specific browser, nor it requires special fonts or resolution.
You're free to see it as you wish.

Web Interoperability Pleadge Support This Project Powered By Gigan