IT manager role consists, among other things, to improve team productivity, product quality and to help the teams to get things done. That should sound basic but for me the only way to reach that goal is to focus on the human side. There’s no rocket science here, but behind each line of code there's a developer in a certain mood, working in a certain condition.
We are using Scrum and some of the XP practices, which means that the business value and the agility is already in our principles. But here I’ll go through some measure I took with my teams during the last few years to improve their working conditions and put the human in the top priorities on top of existing agile methodologies.
Flexible working hours
In Europe, flexible working hours, 24/7 office or telecommuting are not (yet) normal practices. Culturally, we are more used to see traditional 8 to 5 working hours, and we are not an exception.
The majority of my team lives in france near the luxembourgish border in within 40 kms. They are crossing the border everyday to come to work, spending in average 30-60+ mins in the traffic jam. You could imagine the stress level and the mood you are in when you start the day by that adventure. Requiring all of them to be in the office at 08 a.m. on the dot is like to ask them to waste another additional hour in their car.
I know that they decided to stay in France, but giving them the flexibility to modulate their day by few hours make their travel a bit easier. They decide when it’s the best moment to leave home to optimise their journey. Even with this shift, they remain available for the rest of the company most of the day. Since it does not impact our organisation and does not cost us a penny, this is a 100% winning solution.
The side effect (or by-product) of this is that we have increased our hours of operation from the usual 9 hours to 12. Now I always have someone in the office in case of emergency between 7 a.m. to 7 p.m.
Keep the team fresh
Part of the traditional working hours, we still have this assumption that working more than 8 hours a day shows your commitment to the company and gives you the hard worker “title”.
After some analysis of previous sprints, I can confirm teams which accumulate overtime hours are not as fresh as usual. Basic tasks take longer to achieve, bugs on new features increase as the time spent to understand the “yesterday evening code”. On the long run, burning the midnight oil is anything than productive for the company.
Since we agreed that we use overtime only for exceptional events (none in 2012), the time spent in maintenance decreased significantly, and the on-call interventions due to bugs is closed to null. And the side effect of that is that the team is in a way better mood and this is reflected in the general atmosphere.
Good hardware and furniture.
“Hardware is Cheap, Programmers are Expensive”, that’s why is better to invest in good hardware and renew often than having developers waiting while their program compiles. It’s important for our brain to prevent interruptions, and this kind of break kills our thoughts flow.
Another important point is comfort, we spend at least 8 hours in front of our desk, good chairs, tables and screens are mandatory.
We chose Dual screen setup to spend less time switching between apps, for example having the editor side by side with the browser. Concerning the screen size with opted for a minimum 24” full HD to maximise the context visualisation while coding by seeing more lines and being able to open 2 editor panes side by side.
Here’s some facts about our configs:
- Dev on Linux: 24” Dual screens + desktop
- Dev on Mac: iMac 27” + 24” external screen
- Scum masters: Macbook pro 15” + 24” external screen
- Everybody: 12-16go of ram, 500go disk
- Machines renewed every 4 years
Operating System, IDE, editors, keyboard layouts … ? Excuse my French, but we don’t give a S**t! A developer should be free to make his own platform choices if they are compatible with the company’s goals. Im not saying here let them try and wast company time learning the Dvorak keyboard on a blank mechanical keyboard, but let them use what they are familiar with and let them get things done.
My teammates are under unix based systems, 80% macs 20% Linux, and that’s their choice not company’s. Why should I bother them and myself with another layer of rules when I consider that each developer should be free to use the tools he’s the more efficient and productive with. Aren’t they supposed to be power users ? They are professionals of the field, supposed to know what they’re doing and capable to justify choices if needed.
I know that some corporation need have homogenous workstations to ease the system administration of hundreds or thousands workstations, but startups and SMB have no excuses, and should let developers be administrator of their own machine. Why can’t we trust a developer on his own workstation, when we give them production and/or database access or simply let them commit to the core business system, that’s a little bit too tricky for me.
We should not see any differences between the code written on different machine since we have common formatting and encoding rules and every line of code is reviewed by peer before push. At the end that’s the only thing that matters!
I never start a day without walking around our team to greet them and to see how people are doing. This give me an early notice if something is bothering them, for then having a quick chat about it.
This should sound naive and maybe a bit cliché, but I always try to take the time to thank people personally. I’m always making this sarcastic joke to my guys “Thank you for doing the job your paid for!” but I was disappointed to see that’s the way some people think. This affects directly the team’s motivation when this behaviour is shared and repeated.
I’m not saying that the relationship should become aristocratic, but you will be surprised the effect on the team building and the collaboration a simple “hello” and “thank you” could brings.
Quiet working condition
The quite working environment is for me a top priority impediment. Knowing the cost of interruptions on your brain when you are focused on a task, this is for me the biggest issue that limits and slows down the productivity. I should confess that this is still the hardest to get installed when your are working with 100 people in an open space.
Comings and goings in an Open Space lead to a lot of low priority interruptions. My team mates and I tried several technics like wearing a headset while doing a pomodoro, but it’s always matter of how the requester considers his question or remark pertinent.
Sometimes, the noise is coming from an improvised meeting near the coffee machine, laughs from your neighbour department or simply loud phone calls from a colleague, for this there’s no other solution than asking people to make proof of common sense and respect against there co-workers.
One of our scrum master, pointed me out that there’s several kinds of “noises” from his point of view: there’s noise and there’s signal. Signal, coming from teammates talking about programming and business analysis, and the noise which is not familiar to him directly (sales on phone, trade of preparation meeting, …). I could get this, but we should try to keep targeting the ”Library rules” as described Jason Fried.
Decent salary, that’s a vague term. Decent salary, in my vision, is not the fact that you have more money that the average wage, but an overall of your working conditions and the value of each. If for a higher salary or advantages, you have to do things like :
- be connected 24/7 on your smartphone
- work late, nights to finished
- never take rest from work
- barely see your family
… then your hourly rate and conditions are far from being optimal, it’s all about life balance.
Developers already came to me to tell me frankly that they received higher offers elsewhere but the flexible working conditions is really something valuable in their package.
But we try anyway to keep salaries aligned with the market to keep our team attractive and retain our existing team. I’m happy to see that the current team have in average 4 years of seniority (between 3 and 6 years). The global package makes them loyal to the company.
Developers are part of this few percentage that choose their job by passion. They love what they do and feel committed to provide a better product unless you apply with them Micro management. With this kind of profile it breaks completely their creativity by showing them only the top of the iceberg when they need to see the big picture. Give them more flexibility, you will see the benefits shortly.
By the way, if what I’m describing is interesting you, we are hiring, so feel free to send me your application ;)