Managing Success in Devil’s Triangle of Software; Projects, Project Managers and Developers
I am not a project manager of any kind and never interested to be one. I am not a huge fan of non-tech posts and talks but just had an incident which gave me the idea to post my thoughts and experiences.
First what is project management? Since there are projects we do need project managers and management right? But what about those github projects or hackathons which has rock solid outputs in lightning strike time where most real paid projects fail miserably. So do we really need project managers? Let’s start with describing the verb ‘manage’.
Clearly we need something to control or direct to manage it. Can we control the projects or can we direct them? Apparently not, but we can control and direct people! So project management is actually not a real fact at all but the team management is.
So how do we manage teams? First thing we need is a team to manage. Let’s describe the ‘team’.
Clearly a team does not mean just a bunch of people who is just standing next to each other. A team must be competing and working together! Just like the third meaning above if the group who is pulling the wagon is not moving the same direction then that would not form a real team.
So first we need to do is to form a real software team who will work, act and develop together which can be managed. So next question how do we manage a technical team?
Technical people love and respect great technical people, you need to be more technical than them. If you ask who I respected most in my whole my career, was someone who was much more technical than me. I could easily accept his decisions and happy to see him as a boss or manager. So want to control the team? Be technical, learn the technologies you are planning to use. Try to stay one step ahead but not just show off, the team will respect you if they know they can get your advise and trust what you say.
Don’t start with overriding them. Be open to every approach, decision or idea. Give them space to prove what they think by a small project or prototype. Challenge different ideas, let each party to agree on the best one. Accept good ideas, never hesitate to step back from yours. If someone else has a better approach accepting his way does not make you weaker. It just means he had a better solution but you are wise to see his approach is good. If you just override for the sake of keeping control in hands you will only lose respect.
The leader may need to give up some of his technical work hours to keep the team away from non tech details. The leader needs to be a leader not only be respected but also be trusted. The best way to achieve this status is to keep developers free of non technical duties and knowing them you will handle management pressure and their non technical problems. The more the team knows you are putting yourself between them and management to watch their back, they will watch your back! You may be surprised how tight and even impossible deadlines can be achieved if you are working with a bunch of friends who trying to watch your back instead of just professional developers. If the team doesn’t want to log work and the management asks for it, either make the management accept it or do it on your own. You will be surprised how the team will fight back for you either keeping the deadlines or start logging. Just make them see you are there for them.
If you will be responsible for a team, it would be best if you hire that team which may not be possible most of the time. Still if you have any chance to meet, interview or decide who is going to be hired, take your part. I have seen lots of examples where non technical people hiring technical people and ask the team to work with them. Try to be a part of the hiring process and also let other members of the team join you. Let the team decide who they want to work with not the managers!
It is best to work with the best team but you can’t always have a choice. If possible work with the best, if not it is ok. Each project will have different needs and roles, just try to give responsibilities according to the skills and interests. You can easily find something suitable to someone which would let other engineers to work more efficiently while getting input from everyone. One of the best team I ever been in had different level of engineers. Yet we could always find a way to split responsibilities and keep everyone busy and engaged. Good engineers don’t like the repeated works and not so good ones may find it hard to invent new stuff, just do a fair share.
Next make your team feel special, for working with you and with each other. You probably may have heard how Steve Jobs canibalized Liza with the team of pirates he formed for the macintosh team. Although I have never been a fan of competition in a team, it is great when its between teams. Make your team feel special like the pirates of Jobs, let others see how you and your team feel special. One of the best team I worked with, we used to call ourselves as the A team, we designed special tshirts for the whole team and let everyone in the company know how good we were and enjoying what we do. Basically what we were doing was just a simple web app.
Being professional is not enough, be friends with the team. Go out drinking, or talk on not work related stuff. Want them to talk about their problems? You talk about yours first and once they do, try hard to help them. Who would watch your back? a friend or a perfect professional. A great developer may just stop delivering his work if he is not happy with management but a friend would not do that just not to put you in trouble. I have seen several examples where a developer was about to leave but still delivered his best just to help his friends in the team.
Still not convinced and believe the projects needs to be managed to get estimations and decide on timelines? First if you already have solid deadlines in your or management’s head and not even consider team’s estimations, please just cut the crap and don’t even ask for estimations!
Else just let the team prepare a queue of tasks (sure you/they can use scrum way of backlogs, poker games…). Let developers to make estimations, preferably just units not time. Let them deliver tasks on intervals like sprints. Try to have working prototypes as much as possible. Start with pen and paper wireframes, working mockups, half functional products and let everyone see what is working.
Don’t just put developers under ruling of someone filling an excel sheet or drawing bars on microsoft project and expect them to accept they will be paid less and respect him/her. Instead find or be a technical leader for the team which the team will respect the fact he/she should be paid more than them.
Reference: | Managing Success in Devil’s Triangle of Software; Projects, Project Managers and Developers from our JCG partner Murat Yener at the Developer Chronicles blog. |