Mental models

Here’s a nice collection of mental models:

These are some mental models I find useful. They’re rooted in decades of experience of thousands of experts – a modern equivalent of folk wisdom. Mental models are useful to quickly and correctly reason about seemingly intractable problems. They require quite a bit of intuition to properly internalize, but once you’ve internalized them they’re relatively easy to apply. They’re also easy to forget in the moment – use this post as a checklist when thinking about complex problems.

Of those that I read through so far, I found the Planning fallacy the most useful:

Planning fallacy – the observation that humans are overly optimistic when predicting success of their undertakings. Empirically, the average case turns out to be worse than the worst case human estimate.
Corollary: Be really pessimistic when estimating. Assume the average case will be slightly worse than the hypothetical worst case.
Corollary: When estimating time, upgrade the units and double the estimate (e.g. convert “one week” to “two months”).

 

You fired your top talent. I hope you’re happy.

You fired your top talent. I hope you’re happy.” is a response to “We fired our top talent. Best decision we ever made.” article.  It’s one of the best things I’ve read all through last year.

Multiple Perspectives On Technical Problems and Solutions

Multiple Perspectives On Technical Problems and Solutions” is an interesting take on engineering in general and software architecture in particular.  It starts off with:

Fundamental: engineering decision-making is a socially constructed activity

[…]

In other words, engineering (as an activity) does not have “correct” solutions to problems. As an aside, if you’re looking for correct solutions to problems, I’d suggest that you go work in a different field (like mathematics); engineering will likely frustrate you.

It then goes into dialogues and discussions, architecture review meetings, and provides a few pointers on how to get the best of those.

Seven Reasons IT Projects Fail

While reading through “Seven Reasons IT Projects Fail“, I came across an interesting statistic (source):

By categorizing documented causes of IT project failure, a majority—54 percent—are attributed to project management. Surprisingly to some, technical challenges are the least-cited factor at 3 percent.

For me, this is just a confirmation of the gut feeling I had for years.  It doesn’t really matter which technology stack you are using for your project.  The reasons for success or failure are usually somewhere else.

The article  lists the following seven reasons for IT projects failure:

  1. Poor Project Planning and Direction
  2. Insufficient Communication
  3. Ineffective Management
  4. Failure to Align With Constituents and Stakeholders
  5. Ineffective Involvement of Executive Management
  6. Lack of Soft Skills or the Ability to Adapt
  7. Poor or Missing Methodology and Tools

 

The Engineer/Manager Pendulum

The Engineer/Manager Pendulum” is a great article about a career shift from engineering to management.  Anybody who’s in engineering now and plans or even just wants to become a manager should read this.  Anybody responsible for “promoting” engineers to managers must read this too.