Great stuff from Ed Batista about the many ways leaders fail to scale with the job.  Including the terrific concept of “Leader as Heroic Demotivator”.  If you are scaling fast, read it.

Similar to Paul Graham’s classic post on Maker vs Manager time: what’s the difference?  How to find time for both?  (And if you’re a Manager, you are still a Maker, even if you don’t code, by the way.  That’s how strategy, team growth, vision statements and all the rest happen).

Very cool interview with Michael Lopp - the early section on why delegation is so important is terrific.

Any set of people divides into tribes: red vs blue, engineering vs product, “our floor” vs “those people upstairs” and on and on and on.  Leadership contains a large component of getting tribes to work together.  Why do tribes form?  Take a read…

This is, well, epic.  Having spent a fairly large chunk of my professional life chasing down the elusive ghost of repeatable software process, it’s great to read a strong statement like the following…   essential reading…

“My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process”

A long, dense PDF, but paired with the post above, is your Critical Reading For the Xmas Break.  If you are managing software people, read them both.  From the summary:

“This reinforces the perspective that software engineering is a sociotechnical undertaking, and not just a technical one.”

Much less academic, but no less interesting.  Maybe if teams broke off smaller pieces, things would go easier, right?  So why don’t they??

Long read, but a valuable set of experiences to digest.

We always preach in Radical Candor workshops, the value of getting feedback to start building a culture of openness without rancor.  A nice short, practical post about how to start doing that.

An experience of integrating feedback into a group, starting with an open meeting encouraging the group to give feedback to the boss.  A good case study.

I have no idea if this is real, but it struck me as the perfect news story for the end of 2017, so here it is.

“Failory is a community where failed startup owners tell their stories and the mistakes they committed so that future entrepreneurs can learn from them”

Super interesting.  Take a look.

I once watched a future billionaire look pretty stupid.  I thought his product was kinda ‘eh, his presentation kinda lame.  Within three years he was massively successful.  How to tell when an idea is going to work?  When do you give up?  When do you keep going?

Julie Zhou on how we love the “idea person” (and the idea of beng the “idea person”), and love the “get stuff done” person less.  And why.  An older post, but a great read.

You have to respect somebody running 400 product managers successfully at Facebook.  I love the emphasis on “clarity as a service” that runs through this post: being always ruthlessly aware of the “why” of the work.

A little research about empowerment - who does it, whether they really do it, why it’s hard to get right.  Simple read, but useful (try and ignore the stock photo at the top).

A neat grab-bag of simple, practical leadership lessons.

“Don’t think that just because nothing appears to be awry that all is fine…”   Yep.

I love finding posts like this.  It’s very short, but introduces the idea of “necessary endings”, which nicely captures the difficult decisions we all have to make at times.  Take the one minute to read it, remember the concept of “necessary endings” - it’ll be helpful.

Always interested in different approaches to hiring great people.

Exactly what it says: a detailed rundown of how a two-year engineer went about preparing for interviews, and the exact details of the (many) offers he got.