#119 - 2 Jul 2022
How ICs get stuck; Don't fight fires; Bare-bones project management
Managing Individuals
How Do Individual Contributors Get Stuck? A Primer - Camille Fournier
Fournier lists some common places for individual contributors to get stuck - such as when they need to:
Finish the last 10–20% of a project
Figure out where to start: Starting something from scratch, or working with unfamiliar code or systems or teams
Do a different kind of work like project planning or navigating the organization or coordinating with external partners
Ask for help
Deal with surprises or unexpected setbacks
Pull the trigger and going into prod
Say no
And that they can sidetrack themselves by:
Brainstorming/architecture
Researching possible solutions forever
Refactoring
Helping other people instead of doing their assigned tasks
Jumping on fires even when not on-call
Working on side projects instead of the main project
The problem with Fighting Fires - Ed Batista
It’s worth hearing this simple message from time to time. Fighting fires feels great and important - it’s very satisfying! But as managers and leaders our job is to coordinate firefighting and - more importantly - fire prevention efforts. Constant firefighting is, too often, a symptom of valuing activity over effectiveness.
Learn the weekly rituals you should master as a software project manager - Jade Rubick
Project management, like people management, is something we’re typically thrust into without any training. If we came from research, we have some experience of managing research projects, which is good - but there the timescale is longer and no one is depending on our results month-to-month. The projects we’re responsible for now are different.
Rubick writes something that squares with my experience working with people who have come from research:
I see most engineering managers gravitate to two extremes with project management: either they don’t do much at all, or they go all-in on traditional project management approaches.
They outlines pragmatic, aggressively simple, approach to project management of the kinds we’re usually involved in; the context is in software development but it applies more broadly:
Identify the next milestone - go from milestone to milestone, the next never any further than a month off
Update your project plan - weekly, spend an hour or so doing this: not in any fancy tool, just a document
Update your risk registry - again, not in any fancy tool
Send a weekly project update - a clear update to those involved in the project.
They argues that this should only take a couple hours a week for the kinds of projects we’re most likely leading. (Obviously we might be involved in more elaborate projects but we’re probably not running them!). Once that’s done there will be other things to do to coordinate the actual work that the plan’s for. But higher-level planning, Rubick argues, doesn’t have to involve huge tools and long documents. Project planning is to support the work and the people doing or relying on it, it’s not an end in itself.
Random
Sketching methods are becoming widely used in large scientific data science, led in no small part by bioinformatics. Here’s a good overview of doing a min-hash similarity join - the code is in Scala for Spark, but the explanations are very clear and apply more broadly.
The challenges of running and steering Atari.
Why not just use an ad-hoc dewey-decimal type system to organize all your stuff? Johnny Decimal.
That’s it…
And that’s it for another week. Let me know what you thought, or if you have anything you’d like to share about the newsletter or management. Just email me or reply to this newsletter if you get it in your inbox.
Have a great weekend, and good luck in the coming week with your team,
Jonathan