Adding manpower to a late software project makes it later.
Development managers often win their management roles primarily from having been stellar coders while displaying a modicum of people skills.
Programming teams can tell management that the product is one week from being functionally complete every week for the months.
A program can produce the desired results and be so poorly designed and/or executed that it cannot realistically be enhanced or maintained.
For too many managers (especially less technical managers, such as CEOs or CFOs) prototypes appear to be “done.”
Express enthusiasm while privately checking the facts.
In Dilbert, the PHB isn’t respected because he does not understand, or care to understand, what Dilbert and his cohorts do.
The single biggest key to successfully managing programmers is to have the technical respect of those you manage and your peers. Without technical respect, every attempt to manage will be thwarted actively or passively.
We recommend that you staff different programmers for each of these different types of activities and don’t expect any of your programmers to span more than one of them, but reward handsomely those blessed few who do span the spectrum of understanding.
Some managers try to dictate decisions and activities. That may be appropriate on occasion. However, a manager is maximizing his time and skills when he facilitates getting the right decision, rather than dictating it.
In smaller companies and organizations you may be the only defense against the flood of sales-driven opportunities, customer-driven issues, and management-driven ideas that challenge your teams. Make sure that your staff is aware of the extent of your efforts to protect them from the murky stream of requests.
Contingent rewards (if you do this, you get this) turn play into work and drain motivation.
To delegate work, you have to be willing to let go—you have to accept that tasks will be done in ways different from how you would have tackled them.
If they know you’ll make them your top priority when they drop by, they’re more likely to drop by sooner when things are about to go very wrong.
A manager who gets agreement by dominating conversations ends up not with a team but a coalition of the coerced.
Firefighters who get rewarded carry matches. What you should avoid at all costs is a culture that overly rewards heroes.
Promotions are generally not rewards for past performance. Instead, management uses promotions to advance those who display the potential to tackle the next level of bigger, tougher problems.
It’s not my job to motivate players. They bring extraordinary motivation to our program. It’s my job not to demotivate them.
Always make a deal when offering a quick and dirty solution so youd don’t end up maintaining a mess.
Without requirements or design, programming is the art of adding bugs to an empty text file.
Customers will grade you more harshly on poor quality than on missing features.
There is so much that can never be scheduled that goes on, like testing new compilers or OS versions, that trying to track everything is hopeless.
There is no such thing as a short-term fix in our business. There is never a way to improve productivity in the short term.
In applications with high technical debt, estimating is nearly impossible.
Think of a jelled team—ready and willing to take on a new effort—as one of the project deliverables.
Being smart as a manager is not about how quickly you can find the answer, but about how effectively you can mentor your staff to do so.
Really like this mashup... 👍