7 ms·

Minimal Project Management

91 points by WA9ACE 7y ago

zigzaggy 7y ago
Good write up. I manage multiple ongoing projects and my company is growing a team under me. This is a great approach that I will put in my toolbox.
chiefalchemist 7y ago
"That is, again, why I hired them." 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.
- abraae 7y ago
  I've experienced the office of about 6 people (mentioned in a post on Epic Games) as an ideal environment for software development, better than cube farms or single person offices. 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.
  - akeck 7y ago
    I've always considered 5 the max, because each person tracks four [1] others. [1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2864034/#!po=1.66667 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2864034/#!po=1....
    - dodobirdlord 7y ago
      This reminds me of Amazon's beloved 'two pizza team' idea. https://zurb.com/word/two-pizza-team https://zurb.com/word/two-pizza-team
      - fredsir 7y ago
        Hopefully that is family-sized pizzas.
  - madhadron 7y ago
    > 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. How do you coordinate the six person teams, prevent them from ending up in contention, etc.?
    - downrightmike 7y ago
      user stories and delegation
      - madhadron 7y ago
        Ah, the innocence that thinks that is enough.
        downrightmike 7y ago
        The title is minimal :)
    - dodobirdlord 7y ago
      The Amazon model to addressing this problem is to minimize to the greatest extent possible both team size and inter-team communication. The ideal team is characterized by 5-8 engineers who collectively design, build, test, deploy, and own in production a service exposed to the rest of the company only through API calls over the network. This mostly addresses the coordination problem because teams shouldn't need to coordinate, and it mostly addresses the contention problem because almost every decision is entirely owned within a particular team with no expectation that they consider external input.
- paulcole 7y ago
  This also caught my eye, “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.
flyinglizard 7y ago
Make sure to issue a summary email after each weekly meeting, in a broad circulation and including multiple stakeholders that should be kept informed. Have all owner/action/date triplets clearly marked. Don’t be shy on the formatting, important points need to pop out clearly. Bullet points are your friends. 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.
jupp0r 7y ago
Is this article satire? (some quotes) > 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.
- geertvanbommel 7y ago
  I wouldn't judge too much, but it's a shame the article is 3 years old. I would have loved to hear what he has learnt/adjusted in the meantime.
lifeisstillgood 7y ago
My secrets of project mgmt - 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

91 points by WA9ACE 7y ago

Good write up. I manage multiple ongoing projects and my company is growing a team under me. This is a great approach that I will put in my toolbox.

chiefalchemist 7y ago

"That is, again, why I hired them." 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.

abraae 7y ago
I've experienced the office of about 6 people (mentioned in a post on Epic Games) as an ideal environment for software development, better than cube farms or single person offices. 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.
- akeck 7y ago
  I've always considered 5 the max, because each person tracks four [1] others. [1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2864034/#!po=1.66667 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2864034/#!po=1....
  - dodobirdlord 7y ago
    This reminds me of Amazon's beloved 'two pizza team' idea. https://zurb.com/word/two-pizza-team https://zurb.com/word/two-pizza-team
    - fredsir 7y ago
      Hopefully that is family-sized pizzas.
- madhadron 7y ago
  > 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. How do you coordinate the six person teams, prevent them from ending up in contention, etc.?
  - downrightmike 7y ago
    user stories and delegation
    - madhadron 7y ago
      Ah, the innocence that thinks that is enough.
      - downrightmike 7y ago
        The title is minimal :)
  - dodobirdlord 7y ago
    The Amazon model to addressing this problem is to minimize to the greatest extent possible both team size and inter-team communication. The ideal team is characterized by 5-8 engineers who collectively design, build, test, deploy, and own in production a service exposed to the rest of the company only through API calls over the network. This mostly addresses the coordination problem because teams shouldn't need to coordinate, and it mostly addresses the contention problem because almost every decision is entirely owned within a particular team with no expectation that they consider external input.
paulcole 7y ago
This also caught my eye, “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.

flyinglizard 7y ago

Make sure to issue a summary email after each weekly meeting, in a broad circulation and including multiple stakeholders that should be kept informed. Have all owner/action/date triplets clearly marked. Don’t be shy on the formatting, important points need to pop out clearly. Bullet points are your friends. 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.

jupp0r 7y ago

Is this article satire? (some quotes) > 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.

geertvanbommel 7y ago
I wouldn't judge too much, but it's a shame the article is 3 years old. I would have loved to hear what he has learnt/adjusted in the meantime.

lifeisstillgood 7y ago

My secrets of project mgmt - 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