The Ray King Blog: Developer Manager Divide

Something inside of me was stirred recently when I came across a blog by Rob Walling, clearly Rob is an experienced and insightful developer which is passionate about his work, further he has experience the many sides of our industry.

One particular post 'An Open Letter to Software Managers of the World' really got me thinking. I have hinted at the conflict issues before in my posting that can arise between managers and developers, I feel that I have some experience in this having been on both sides of the fence.

What got me in particular about the above post was that Rob lays out a dozen or so responsibilities that managers and developers need to accept. This is great starting point, but it still has the under tones of us and them, which is the reason the list sits sightly uneasy in my mind. This all in all is not a bad thing because it has acted as a catalyst of thought and the reason for this posting.

After much consideration I have decided not to approach this issue as a developer, manager or architect, rather as a human being with a vested interested in the industry and in software engineering. So I hope to share from my perspective as that person whom has enjoyed a good living from this industry and wants to continue to do so. Firstly you would be a fool not to accept that there has been historical conflict between developers and managers.

Clearly the solution of eliminating one group is just not viable, in the words of A.Cockburn development is a game, a game that needs a group of people with various skills to work together to make things work. We need participants to map out a path ahead, others to manage clients, others cut code and ride the small details, others to deploy and integrate, others to manage and take the damage when we slip up. The reality is when the participants do act together as a team the game can be profitable and rewarding to all.

Therefore this is the first premise that needs to acknowledged, that this game take various participants with diverse skills working in concert to win. The alternative is that one can play with ones self and maintain an illusion that you are taking part in the big game, which clearly you are not.

Acceptance of the first premise leads to the question as to how do we optimize the roles and interactions between the team members?

This is where I think a common set of rules or principals might work better then a list for this type of person and another for other type. So here is my attempt to list my three key rules, explain why they are important and how it relates to the list in the open letter.

1. Understand what the other team members do.
Understand their constraints and how they do their job and what they produce when they have completed their job. For example a developer looking at a sales or business development person, needs to understand that he is out their fighting for a contract that will put food on the table of the developer, that he needs to deal with all different personality types which are receiving alternative offers. He is reject hundred of times and totally shutdown most of the time, this is clearly a hard job, he is at risk of losing his job if the contracts are not delivered and further is at risk of burning is reputation if the software is not delivered.
From the perspective of the business development guys he needs to understand that the developer has to pay the price emotionally and physically for the constraints established within the contract. It is the developer which is not going to go home at night to see their family it is the developer which is not going have time to spend they pay packets because of the unreal expectations that have been set. This applies to all the roles with in team,
If understanding and balance is not achieved between all team members, ultimately it is the stakeholder who pays the price. It is only when we don't attempt to balance profit against the human factors does the scales default back to profit, but that is not say that a profit will ultimately be delivered.

2. Take Personal Responsibility to empower other team members.
Clearly if everyone is operating at optimum levels the team overall have a better change of winning the game. I can already hear some people say but what power do I have, I am just the newbie tester. Well we all have power in a development team, and we need to use that power to ensure that our team mates can do their job better. For example, as tester I can empower a developer by really working with him to help him improve his code, I can do this not only by doing my job well but also taking responsible to communicate openly and directly and respecting the other person at all times.
As a Business Development person I can talk to the developers, architects etc before the terms of engagement are in stone and ask them how would they like to see the engagement carried out. As a developer I can work with architects, project managers and business people to come up with innovative solutions that the business development team can take to clients. As someone who has budget and resourcing responsibility over developers I can ensure that they have the best tools so they can perform at their optimum.

3. Communication and Ethics
Despite the best efforts and good intentions of all team members, there will be conflicts, stuff-ups and less then ideal situations. It is how we overcome these event that determines if we are winners or losses in the game over the long term. Communicate everything without fear of judgement or retribution, if you hear something you consider stupid it does not tell you anything about the other person who said it rather it tell you that you have failed to empower that person and bring them along with you.
Communicate in an open manner not to position others or cover your own short comings, this is the only way to build trust. If there are short coming never lie about them, highlight them, find a solution, fix it and move on.

That is it! Probably sounds very idealistic but it is applicable. Let show you using the list in the open letter.

Developers List

We will do what it takes to get the job done without being asked, including working extra hours (as long as it does not violate clause 1 in the section below).

An issue of understanding, no one should burn themselves and extra hours should be so unusual one should have trouble remembering them. (You can see the agile guy in me coming out), Communication leads to understanding of work loads and they are what they are, you can not change the laws of physics.

We will not complain when we are assigned boring tasks, bad problems, or have to maintain someone else's code (as long as it does not violate clauses 4 or 5 in the section below).

Task 'niceness' is in the eye of the beholder, I personally think maintenance work is one of the most challenging jobs one can do. Anyhow can write a connecting pool-er but it takes skill to retro fit a new database into a old one without breaking it. The key point here is understanding and communication, one just should not commit to delivering something unless you can get someone to signed up to do it. Respect means influencing and not forcing.

We will bring issues to your attention constructively and with proposed solutions.

Does not need discussion, it is about communication and ethics.

We will seek to understand a decision before questioning it.

To question is good, but understanding and empowerment would cause you are apart of the decision if it effects you.

We will build the best software we are able to.

Does not need to be stated, no person wants to do a bad job, we all need to feel proud of our work.

We will be loyal to the company and our team.

Loyalty comes as part of trust, and the only way to build that is communication and ethics.

We will be passionate about the software we build.

Needs not be stated.

We will be available when you really need us.

I will alway be available to empower a team mate

We will fully document our code and designs.

A professional would not do anything else

We will happily coach and mentor new developers.

I know I was a newbie too many moons ago.

We will tell our friends how cool it is to work at our company.
I will always to tell the truth

Managers List

You understand that "crunch time" is an unexpected part of software development. Unless we have substantial equity in the company, crunch time will not exceed 3 weeks during any 6 month period.

If I have created crunch time I have failed to understand what others do and have not communicated adequately to explain work loads etc. Just because someone has substantial equity does not mean I can drop the ball.

You will give us powerful, best-of-breed PCs, huge hard drives, large monitors, and the latest development software.

I understand that tools does not make it the programmer but they sure as hell improve productivity and I want to empower developers to be their best, for that matter I want everyone to be the best they can.

You will listen and take action when we constructively bring a problem to your attention.

Does not need discussion, it is about communication and ethics.

You will ensure that at least 80% of our time is spent on good problems.
It is in my interest to get involved with everyone and sign up for things that I think I can do well. If I have accepted a task and it turns out to be a bad situation I need to take responsibility to complete it and ensure that i does not happen again by empowering those around me with the knowledge and understanding as to avoid the situation.

If you plan to call us when software breaks, we will be given time to refactor and stabilize it as needed.

I will clearly set the expectations when I am asked to sign up for a task.

You will not ask us to serve as technical guides for highly paid contractors only to be held responsible when their code single-handedly brings our operations to a grinding halt.

So Obvious it does not need an answer.

If marketing is allowed to set our deadlines based on their knowledge of software projects, we will be allowed to set their budget and/or revenue expectations based on our knowledge of marketing.