How involved with project development should a programmer be?

Question

Given that there is no hierarchy in my poject team, i.e. customer liason, project manager, architecture consultant, developers are just different roles. Everyone listens to everybody, and we move forward by agreement not by executive command. We're working on a new product and the atmosphere is very positive.

I previously worked alone, so am used to doing all project management by myself in conjunction to coding. Now that I have a team, which aspects of project management should I keep doing, and which should be done by the others?

My current worry, is that I'm spending too much time in meetings and doing high-level things(budget, product definition, customer analysis), and I want to refocus on coding, without losing the direct influence on making project decisions that I have now.

Particularly later during the project, how much % of my time should I expect to be able to code, and how much effort should I continue to spend on project management?

(In development efforts, I currently have 95% of my work time allocated, but if I spend 5-10 hours in meetings per week that will bring me down to 60%-70% of my work time available for coding, which translates to slower product development, but perhaps more aligned project management. I'm not sure if that's a good or bad trade-off.)

Answer 1

I'm going to use some Agile terminology in this, because I think it's relevant to what you are doing, but it isn't the only way of doing this.

In Scrum (one type of Agile) there is a role called the Scrum master. This isn't really a project manager (as the team are self managing, like you are doing), but their role is to keep moving things along, helping to clear impediments/ambiguities, and should be a technical person, not a PM.

Have a look at this: Scrum master on Scrumguides

Normally you would want to have a full time scrum master, but it is possible to share out the role, I'll explain:

• I'm assuming you aren't doing some big 6-12 months delivery without a PM, that's good, Scrum works in short (2-4 weeks) intervals. If you are doing a 12 month delivery, break it into 2-4 week timeboxes.
• When you plan the work you are going to commit to delivering in this time (timebox planning), work on the basis of 3 (or 3 1/2) devs, the rest of the time is for the scrum master role.
• Now take it in turns to do the scrum master bit for that timebox, you should soon see why having someone to do this helps, and see how the others avoid spending lots of time in meetings etc, plus one person dealing with issues can smooth things with the business etc.
• Next timebox, someone else takes the scrum master role, and you get to spend the whole timebox coding.

You may think you are losing dev effort by only having 3 devs per timebox, but the time saved by the scrum master running offence for the others will be recouped by the other three. My agile teams spend 90-95% of their time coding, sometimes meetings run to max 15 mins a day for the standup (the daily update on progress for the team and scrum master), the scrum master deals with just about all the rest.

There is more to it (books, web sites etc) if you want to learn more, but even at this basic level you'll see how to do this in a flat structure.

Answer 2

I would leverage the talents of the other members of your group since there's not a specific manager.

Since you're acting like a PM then use that current pseudo-role to offload some of your non-development load on others so they can share it with you. I would identify as many specific non-development tasks as you can that a PM would normally do, that you're doing. Then I'd "assign" a proportionate share to the rest of the team. The reason I put assign in quotes is because it sounds like with the type of team you have, you wouldn't have a huge problem getting volunteers for many of the tasks.

Since you've got a good amount of experience with this, I'd take on the role of "shepherd" for the 10% or so that you would take on and help others do the other bits. That way you can make sure that it's done correctly without having to do it all yourself.

If you get some pushback, I'd equate it to other parts of our lives where we do things that aren't necessarily "our job" but that we do for the betterment of our group. It sounds like a good team so if you propose these changes in that light, you probably won't have many problems getting help with the non-development related tasks.