tl;dr: “When you’re staring a huge, challenging project in the face, don’t align your team around just getting it done. Instead, align your team around continually reducing uncertainty…” James advises us to prioritize the most uncertain parts of the project and focus efforts on getting answers. Answers fall into two broad categories: that it is possible, as proved by code, or that it’s not possible, but yields another avenue to try. You repeat this process until you’re done, or until you think it’s best to stop. “Focussing on reducing uncertainty builds momentum and trust both inside and outside of the team.”
tl;dr:"You reduce uncertainty until the software exists. You reduce uncertainty by doing: prototyping, designing, writing code, and shipping. Each of these actions serve to reduce the uncertainty about what is left to build." James discusses different methods of reducing uncertainty across a project, at various stages.
tl;dr:"In a world of continual context-switching and distraction, if you’re able to make it as easy as possible for others to understand what you want, what the next steps are, and whether or not you have a strong preference, then you’ll find that your interactions are far, far better." James digs into this with examples and the following framework: (1) Make it clear up front what you want. (2) Make the next steps obvious. (3) If you have a recommendation, say it up front.
tl;dr:James advices ICs and Managers to bucket their time: (1) Map out how you’re spending your time into daily, weekly, monthly and quarterly buckets. (2) Identify which of the tasks are repeated and which are one-offs. (3) Are all of your one-offs strategically important or are they busywork? (4) Is there anything that you can delegate to others or automate? (5) Is there anything that you can remove completely?
tl;dr:Monday to Wednesday are high energy, productive days for James, but Thursday is an inflection point where he's tiring. James discusses how he's trying to rectify this: (1) Purposefully trying to work 10% slower. (2) Being stricter with notifications so there's less context switching. (3) Limiting checking messages to within working hours. (4) Deferring non-essential requests and tasks into the following week. (5) Pomodoro technique.
tl;dr:"Hybrid work only works when all employees are treated as remote employees. To do this, companies need to do five things: embrace asynchronous communication, make communication boundaries clear, champion documentation and the production of artifacts, share information widely, and provide the right tools for employees to succeed." Each are discussed in this post.
tl;dr:"Progressing, in general, is a two-stage problem: you need to discover where it is that you’d like to go, and then you need to take positive action to work towards it. In my experience, many people over index on the prescriptive “how” before spending enough time on the “what”. The search space of possibilities for your career trajectory is effectively unbounded, and can rarely be predicted over long enough periods of time. This is a feature, not a bug, and should be embraced."
tl;dr:(1) Start with a "micro-yes:" e.g. “I’ve got a couple of ideas for how we could improve. Can I share them?” (2) State your data point: e.g. "we said we’d ship this change by midday, but it’s 4pm.” (3) Make your impact statement: e.g. “our support staff are getting inundated with tickets because we said that it would be fixed earlier.” (4) End on a question: e.g. “what are your thoughts?” As a rule of thumb, most feedback should be positive.
tl;dr:Focus one-on-ones on coaching, less on status updates, which can be done asynchronously. Coaching should gravitate towards your report's conscious or subconscious interests in a situation and push them to answer the questions they raise themselves.