Minimal Project Management
hiltmon.com
hiltmon.com
That's easy to say when there's only five. The problem is, that doesn't scale. At some point you need to proactively implement a culture (and M&Ps) that does scale. If you wait til you need then you run the risk of having waited too long. Veteran team members will be put off, new hires will be updating their CV.
Maybe instead of struggling to apply management concepts to the development process, companies would achieve more by breaking things up into 6-person sized teams.
[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2864034/#!po=1....
How do you coordinate the six person teams, prevent them from ending up in contention, etc.?
“Developers with nothing to do become disruptive or lazy.”
So the trick is to pat yourself on the back for being so good at hiring (but please recognize that if your genius hires aren’t worked to 100% capacity they will suddenly become a problem) and then make sure they never have any downtime.
Seems easy enough.
> They do not need to be micro- or even macro-level managed
> Developers with nothing to do become disruptive or lazy.
> With all this advice and help, I can easily determine what work needs to be done first, what next, what can remain on-hold, and can assign work to the team.
> Once the Statement of Work is completed (and reviewed, filed and approved by me), the person starts executing the tasks and we move into a work and review phase.
If this isn’t micro management, what is? Where is the team empowered to improve their process? Where is tech debt addressed? Is estimation really so easy? Ever heard of pair programming?
Note to myself: never work for that person.
It’s great for the team to use as their own reference, it keeps outside people generally informed and it’s an immediate springboard for next week’s discussion.
- write down and agree what we intend to do - (auto)record what I actually did - review why there is such a big gap - fix something, keep processing