Balance between sharing creative control and leading the project

Question

I've been working on a project for almost a year now as the Project Manager. Initially, it was just myself. Over time, several others have been engaged in the project on a much smaller scope.

The project is relatively heavily modularized, primarily to accommodate this type of an environment.

In my experience, I really appreciate when people share creative control. It makes you feel like you're an important part of the project, you're contributions are more than just repetitive to-spec coding, and you get to have a little fun playing around with ideas. As such, I try to grant those I work with a heavy amount of creative control on their parts of the project.

I'm beginning to think this is back-firing on me because there are some tasks, which should be relatively simple, that are turning out to be huge burdens because of the amount of discussion expected. I don't want to be a project dictator but when we are in "crunch time" and somebody goes off on a tangent with an idea and reports back that he doesn't think my solution is ideal, I find myself becoming aggravated. I am almost always an extremely laid back person so this is surprising to me. I don't let my professionalism slip and try to hide any negative notions to keep everyone happy.

Many of these issues are more related to "personal taste" (think Design) than a technical, provable problem. As Project Manager, I am really dealt the burden of making sure this project is completed successfully. Overall, I just want to find a way to balance letting my fellow programmers have fun and enjoy their work but also move forward faster than a snail's pace.

Can anyone recommend some ways to establish a balance between letting the developers enjoy themselves while continueing to push out a product I feel comfortable delivering?

Answer 1

TL;DR

[T]here are some tasks...that are turning out to be huge burdens because of the amount of discussion expected.

It isn't really the discussion that's inherently problematic; it's the intersection of discussion with Parkinson's Law. Or, to put it another way, you have rediscovered the reason that agile frameworks like Scrum rely so heavily on time-boxing.

Over-Engineering: The Enemy of Productivity

The agile community is full of pithy aphorisms that all boil down to the idea that productivity is about riding the line of "good enough." Some examples include:

• YAGNI (You Aren't Going to Need It)
• The simplest thing that could possibly work.
• Deliver working software frequently.
• Working software is the primary measure of progress.

Scrum enforces time-boxing on both meetings and iterations, so that discussions that need to happen have a place to happen, but also a built-in time constraint that encourages selection of workable solutions over "perfect" solutions. In addition, the iterative nature of Scrum development lends itself to acceptance of "good enough" solutions that can always be improved further in later iterations if there's actual value in doing so.

This isn't the same thing as cowboy coding or deliberate technical debt. Rather, it's simply a formalized awareness that shippable features are the goal, rather than perfection for its own sake.

Introduce Time-Boxing and Set Expectations

Even if you aren't an agile shop, you may find the following steps useful in reigning in the tendency towards over-engineering.

1. Clearly communicate the objectives and time constraints.
2. Make "good enough" an explicit criteria.
3. Be clear that no one will be blamed if something isn't "perfect" or needs to be refactored in the future—and mean it!
4. Reward on-time delivery of "good enough" features.
5. Set the expectation that a team decision made within the time-box will set the bar for the feature, but you will make a decision by fiat if the team can't reach consensus before the time-box expires.
6. Treat the time-box as inviolate; don't make exceptions.
7. Use a kitchen timer to help remind the team of the time-box.
8. Never hold individual developers accountable for features that are good enough but not "perfect."

The key here is to make the objectives clear, and to communicate effectively about how the team's performance will be reviewed and rewarded. Developers are rarely rewarded for "good enough," but frequently punished for imperfect work. You will need to work hard to build trust in a process that values and rewards alternative team strategies.

Answer 2

I think it depends on the phase/mode your team currently is in based on your organization's (and more specifically your ongoing project)' climate/weather report. There's a fantastic book that speaks to this exact kind of confusion.

To mildly paraphrase, you are either in

• Survival Mode (no time to learn, just do!)

• Learning Phase (team is learning to solve their own problems, cleaning up debt, grooming new team members effectively, exploring creative ideas / prototyping)

• Self organizing (The holy grail! Team rarely needs your help, period. You could fall sick for a week, come back and your project is still on track!)

You would constantly (daily standup meetings etc.) let the team know where they're at based on stakeholder needs and really establish ground rules / working agreements as to how much of a dictator you're going to be in each of these 3 modes (It should be obvious which one has you laying down the law more in, doesn't it?).

Your soft skills would then go on over-drive to earn your team's trust that you are going to pull them out of the "not all that fun" survival phase and into the other two where they have more power/control and say over how things are done, creative license and ownership.