“The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don’t identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We’ll call this general category of debt Type I.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. “If we don’t get this release done on time, there won’t be a next release” is a common refrain—and often a compelling one. This leads to decisions like, “We don’t have time to reconcile these two databases, so we’ll write some glue code that keeps them synchronized for now and reconcile them after we ship.” Or “We have some code written by a contractor that doesn’t follow our coding standards; we’ll clean that up later.” Or “We didn’t have time to write all the unit tests for the code we wrote the last 2 months of the project. We’ll right those tests after the release.” (We’ll call this Type II.)”

Lesson 1
Being responsible sometimes means pissing people off.

Lesson 2
The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help them or concluded that you do not care. Either case is a failure of leadership.

Lesson 3
Don’t be buffaloed by experts and elites. Experts often possess more data than judgment. Elites can become so inbred that they produce hemophiliacs who bleed to death as soon as they are nicked by the real world

Lesson 4
Don’t be afraid to challenge the pros, even in their own backyard.

Lesson 5
Never neglect details. When everyone’s mind is dulled or distracted the leader must be doubly vigilant.

Lesson 6
You don’t know what you can get away with until you try.

Lesson 7
Keep looking below surface appearances. Don’t shrink from doing so (just) because you might not like what you find.

Lesson 8
Organization doesn’t really accomplish anything. Plans don’t accomplish anything, either. Theories of management don’t much matter. Endeavors succeed or fail because of the people involved. Only by attracting the best people will you accomplish great deeds.

Lesson 9
Organization charts and fancy titles count for next to nothing.

Lesson 10
Never let your ego get so close to your position that when your position goes, your ego goes with it.

Lesson 11
Fit no stereotypes. Don’t chase the latest management fads. The situation dictates which approach best accomplishes the team’s mission.

Lesson 12
Perpetual optimism is a force multiplier.

Lesson 13
Powell’s Rules for Picking People: Look for intelligence and judgment and, most critically, a capacity to anticipate, to see around corners. Also look for loyalty, integrity, a high energy drive, a balanced ego and the drive to get things done.

Lesson 14
(Borrowed by Powell from Michael Korda): Great leaders are almost always great simplifiers, who can cut through argument, debate and doubt, to offer a solution everybody can understand.

Lesson 18
“Leadership is the art of accomplishing more than the science of management says is possible.”

While a Lean Product Development, evangelized by Eric Ries and Steve Blank, appears to be the latest business fad it has several key concepts that apply to any business. The Minimal Viable Product and Steve Blank’s Customer Development concepts are really common sense elements that many organization’s, large and small, ignore. Definitely check it out.

The paper Spamalytics: An Empirical Analysis of Spam Marketing Conversion is a fascinating (academic) read about spam conversion. I’ve always assumed that spamming must be profitable at least for the anti-spam industry. This paper not only outlines the underlying economics but the Storm Netbot spam system as well. In fact these guys actually hacked the spam system to carry out their experiments.

Highlights:

• It took 12.5 million emails to generate 1 sale
• After 26 days the botnet had sent out over 350 million emails and 28 generate a transaction
• Extrapolating the figures, they believe the network generated $3.5 million a year in revenue
• Researchers gained control of 75,869 hijacked computers
• One in 10 people clicked on links that normally download malware to turn their computer into a bot
• Between 3500 and 8500 bots are created daily