Check this 4 little advices from an IT project manager to its fellow colleagues
All professional from IT sector, developers, system administrators, tech urbanist knows that every classic IT department work…quite bad after a while.
If the people who build roads had exactly the same professional behaviour, half of the roads would end nowhere and the rest will have issues serious or not.
I have never seen an IT department working like we wanted to run it. Never.
The best IT department I have personally seen are decentralized ones who bet on the people inside their organization and not in process or “management theory”.
When I was a simple developer, when I was a manager – and I am -, when it was my company or when I was head of this department. In 17 years now, never from basic php content management system to high-level financial trading system.
Then what ? all IT men don’t know to work?
No, it’s not that. They are working bad when the fuel is not trust.
Sure.. but how we can manage then IT department?
First, I strongly believe that classic project management cycle is not efficient with an organization who are acting online because the market is changing too fast.
We knew that old project management frameworks are putting at risk online project by lack of flexibility.
Indeed an IT department sinks with maintenance aspect.
When your 4 developers are taken in 50% of their time trying to figure out why this new bug is coming, with “demand rain” from different others departments asking different things coming in various form, you are only a dead man.
This “rain of demand” plus “the maintenance” just explode your everyday work schedule. You are not able anymore to develop somethings in good basis and things are getting worst.
The first, and worst, classic answer would be to rigidify the acceptation of the demand from others departments like marketing developing norms, papers and a whole package of tools which will only slow down all the processes without adding any business value.
Transforming your sinking IT department in a new bureaucracy is not perhaps the best thing to do but it’s the easiest solution for lazy minded manager because there is always something comfortable to write papers and search for approval instead to be creative.
You need, then, to understand the 4 key points for an IT manager:
How to anticipate risks, avoid the “Fort Alamo Syndrom“, kill the “alone developer problem” and be able to do a good forecast of time development.
1 ) How to anticipate and mitigates risks?
The science of risk had in France a very good teacher named Georges-Yves Kervern who created the “Cyndinic”. He applied this science to big industrial compound like nuclear’s one but his lessons can be applied to any organization or industry. For us at our IT level, it could be presented as a series of a binary answer which predicts a root — cause events and the needed answer to it.
If A happens then B will occur then we will react with C. It could be very simple but you need to think about it.
Where are your big risk(s) in an IT department?
What I have seen during my career is that, for IT, the risk is people dependent. It’s the guy who wrote this 10 lines of code where all payment pass trough, “who knows” who is the risk.
More this guy or girl is concentring information, more your system is becoming weak.
And more he/she knows, and more he/she attracts new projects and grow its own (intime) dependency to the system.
Then you need to
- To hire and run teams with similar level: No superstar, no “full beginners” or beginners who want to learn
- Be sure that no project will be done alone. At least you need to explain to a second person what you do.
- Detect people who don’t know to call alert when they reach their level of incompetence
- Trust them giving the maximum of decision level to the maximum of people involved in development.
- Put developers close to business owners or business “orders”.
The Key Factor is the interpersonal relationship first based on trust.
It’s why organization based on trust succeed so good in the IT world.
All the Open Source movement is based on it. The second key factor is at the core of the sense of the mission.
Developers need to understand why they are doing something and what are the business consequences involved.
You need to trust the people you are working with and grant them their own expertise to move forward.
Any other “top-down” organization with developers will lead to a Soviet-like organization where the less creative, the less skilled will command. This organization fail and will produce bad results even with very good developers.
2 ) “The Fort Alamo Syndrom”.
When IT is not the core business of a company. The native developers will begin to think marketing, think sales and think what they have to think outside their own field of expertise. It’s the classic state of mind of any developer. All people who worked with IT DPT knows that the bad CTO is a CTO thinking at the place of the CFO, the CEO or others sales person. They have “a magic power”.
They are the Harry Potter of the house while the others are all villains. “We know” what is good for all this dumb people from Marketing…Ok. nice.
Any developers will do that after a while and if they are confirmed in this position with a guru-like mind, they will cause to your organization big troubles.
The “Fort Alamo Syndrom” is when the IT department loses the connection to reality producing projects only for internal need focused on tools instead to focus on business goals.
Be aware of that, detect the Fort Alamo syndrome in your team and react: not with react.js, please.
Mix developers with other colleagues from others department even if they don’t drink beer and are not able to produce strange jokes.
3 ) “Alone Developer Problem”
You have ever seen such situation: one developer is fired because he produced a ton of shit and he’s replaced by a new one who will stay alone on the project with nobody understanding nothing to what he does. Being lucky this guy successfully reduce the tons of shit but produce himself a new stack of shit. Yeah.
By default, being alone is not good. We are social animal and we need interaction to make progress. What it’s true for hunters in the wild is also true for developers in a very dark open space – yes, like vampire, they hate natural lights too.
Then if you are more than 1 developer in the team, be sure that they will speak, at least, each other of what they are doing.
The best is to plug one of the team as “production leader” with the ON button of the Git or SVN-like production chain final erection…people will have to explain what they do. The exercise is always profitable.
4) The Forecast.
Forecast right because it’s the basis of the trust with non-technicians.
It’s better to be slow than fast but inaccurate on the delivery date.
Remember that you are the magician of tomorrow then hide your trick. Magicians don’t show their trick …remember.
Finally, everybody doesn’t care how you did the stuff and how hard it was then don’t lose time to explain the mechanics. Just let final users dream.
In the same mood, you will never be “too early” to launch something. Shut up and Launch…be close to people who use really the software you did and work with them before to make any fancy press release with strange GIF. If they adopt what you did before any official announcement, it will be easier for you later and your GIF may be understood by someone “of the other team”.
Finally, you can be ITIL certified, PMP master or lord of PRINCE2 but if you don’t base your management on a simple and natural gentle behaviour based on trust, you won’t get anything from your developer team. Train them to be mutual coaches more than basic colleagues and don’t be a “chef”, they, really, don’t need it.
