I read John Doerr’s “Measure What Matters” recently in which he introduced the notion of “CFR"s (Conversations Feedback and Recognition). I was intrigued that there’s not much written about CFRs around on the net (I think he means good one on ones essentially). Here’s one summary I found.

Super-cool twitter thread on how simple changes in asking questions can make a huge difference to the resulting conversation.

My brief notes on the fundamentals of story-telling. A few basics: character, specifics, what is the barrier and how did your character(s) overcome it - make a huge difference.

This is a good, practical list. Specifically the tips about character are useful in the business context. Think through who the story happened to (“we went for funding and…” - who’s we?), what barrier the character(s) had to overcome, and how they were different afterwards.

An interesting model for avoiding decision paralysis. Has a flavor of being too directive, or specific (37% exactly? really?), but definitely a useful way of thinking about where you are in a decision process.

A pretty interesting description of what it takes to be a “senior” developer: the ability to move context from very broad (“does this product match the market?”) to incredibly narrow (“can I be sure that traffic on these ports is blocked on that VPC?”).

This is also, I think, what distinguishes people with real “vision”: the ability to see that this technology will be viable for this usage at this time - it’s a combination of very wide vision (eg: people will carry handheld computers disguised as phones) with a very critical technical understanding (eg: networks will be fast enough, storage cheap enough, touch screens workable enough to make handheld computers disguised as phones really viable).

This is just great. Things like: “… I have noticed something: the longer I spend chasing it, the more likely it becomes that the fix is a one-liner”. And: “insidious bugs come from inaccurate assumptions”.

There’s a lot more. For more junior developers, this should be absolutely required reading. If you’ve been around a while, read it anyway.

“What if the concept of “bad hires” is more harmful than helpful?” Marcus, with an interesting take on the cost/benefits of the hiring process.

My notes from a few months ago, on a recurring issue I see with my VPE clients: waiting too long before tackling hiring. Hiring is a Big Rock and needs a Big Machine. Building the machine takes a while. Start now.

Easy read, useful stuff. Exactly what it says - ways to start the “I want feedback” conversation with your team.

Some good things in here (“the idea of grading on a curve is crap” and “When managers are prompted to recall past negative behaviors (or areas for growth), they will remember those things more accurately and tend to weight them more heavily”).

Also ways to include getting feedback for yourself during the review process. Practical. Good.

“I’ve said what I want - why don’t they do it??” - the cry of the frustrated manager. “They” are people, and they have their reasons - a simple, but useful post about what might be going on.

This seems so simple, and yet is at the core of how companies evolve: “When one person learns how to do something, and when he or she can and does communicate that knowledge to others, the others can quickly benefit from that knowledge, and the group advances”

Learning, and the communication of learning, determine how fast we grow. The article is more about economics than company structure, but its lessons are fundamental.

Noticed that the pics of folks in your blog posts/marketing material/website all look kinda the same? A super nice set of resources, including stock photos of all sorts of groups, from Better Allies (worth signing up for the newsletter, too).

A whole ton of detailed experience and advice on working remotely - managing meetings, the use and misuse of synchronous communication and more.

“Slack is very powerful, and we can use it really well or really poorly,” Kammah says. “By default, it’s easy to use it poorly—as in, use it as a synchronous tool"

A super-useful drill-down on asynchronous vs synchronous communication. Some of the stats in here are hair-raising, the solutions thoughtful.

“This trend toward near-constant communication means that the average knowledge worker must organize their workday around multiple meetings, with the time in between spent doing their work half-distractedly with one eye on email and Slack”

Do we need another piece on how to run meetings? Well, sure, turns out we do. Clear, specific advice, nicely articulated (yes, it’s a bit of a marketing piece for the app but it’s still well worth reading).

The balance of “top down” vs “bottom up” is always a trick in a planning exercise, so it’s neat to see an approach which has a clearly defined point of view on the problem. Pretty fascinating.

Outlines three personas that can show up in discussion: the Historian (“how did we get here!?”), the Observer (“what’s going on?), the Strategist ("what should we do now??”). Identifying who has which persona can help get a stuck conversation back on the road.

Neat model.

A cool, practical post outlining specific ways to notice, and then disrupt our own biases when giving feedback. Great piece.