- Getting the right people from the beginning is important, since they’re not typically around long enough to change them
- Let people be themselves. Desired uniformity stems from unconfident managers not wanting to be surprised. “Professional” == unsurprising drones.
- Leadership is not top -> down. Nor is it “work extraction”, emphasizing quantity over quality.
- Leadership is a service to others. A catalyst w/ humor and goodwill.
- In interviews, ask for portfolio or sample code.
- A team’s goal should be the system or the team itself, not the company’s goals. Especially not the profit goals!
- Goal alignment, not goal attainment. Well-jelled teams need to align on a goal, even if arbitrary (“release working system by X”). Motivation and satisfaction centers on that, not profit.
- Those goals provide a strong sense of eliteness, identity, and ownership.
- Allow teams to make mistakes. Override rarely and only when necessary, as otherwise you convey a lack of trust.
- “Autonomous as long as ‘correct’” == not autonomous
- Early on, provide easy opps for the team to succeed together — even better if there’s no apparent management and its peer-driven.
- Be willing to trust and put your reputation in the team’s hands.
- Focus on allowing team members to work as uninterrupted as possible, shielding from as much distractions from clients as possible.
- Calling an imperfect product “good enough” kills teams and motivations
- Teams demand closure and occasional affirmation/confirmation that things are on target. Take care to divide work into pieces w/ completion points. The bits of closure from pieces are far better than everything incomplete till the end.
- Allow teams to be more productive and goal-directed, even if it means less-controllable! Can’t really control them anyway. Orient, fire up, and get out of the way.
- Try not to break up teams.
- Teams consist of peers. The manager should be on the outside!
- Major problems are not so much technological, but sociological
- More people worries than tech worries, but seldom manage that way, as if they themselves will do the work
- The entire focus of project management ought to be the dynamics of the effort. Pay more attention to how individuals fit into the effort, not what they can produce
- Pressure results in faster work, but not better work
- Quality standards should be set by the builders for reasons of self esteem and therefore productivity, not by the market, buyer, or time
- Allow dev team veto powers on delivery due to quality
- Parkinson’s law is ridiculous. Developers need the satisfaction of project completion. They are as eager as you are, as long as they standard of quality isn’t compromised
- Apply time pressure rarely and only when impeccably timed and justified. If it happens, sign that there’s a management problem.
- Managers job is not to make people work, but to make it possible for people to work
- Project risk indicates value
- The ultimate management sin is wasting people’s time
- When you over coordinate your employees, they’re likely to under coordinate themselves.