zlib.pub_the-managers-path-a-guide-for-tech-leaders-navigating-growth-and-change
by Camille Fournier · 164 highlights
the value of planning isn’t that you execute the plan perfectly, that you catch every detail beforehand, or that you predict the future; it’s that you enforce the self-discipline to think about the project in some depth before diving in and seeing what happens. A degree of forethought, in places where you can reasonably make predictions and plans, is the goal. The plan itself, however accurate it turns out, is less important than spending time on the act of planning.
Project management is the act of breaking a complex end goal down into smaller pieces, putting those pieces in roughly the most effective order they should be done, identifying which pieces can be done in parallel and which must be done in sequence, and attempting to tease out the unknowns of the project that may cause it to slow down or fail completely.
Work through the unknowns until you really feel that there is no more value to be gained in spending time on them.
As things slip (and they always do), keep everyone apprised of the status.
Decide where the line for “good enough” is, socialize it, and commit to it.
Make a launch plan; make a rollback plan.
For every project there’s the period where you have the idea and you’re selling it to people, trying to convince them that it is the right approach.
more than making decisions yourself, you’re helping the team make decisions.
You realize that authority requires more than a title. You find yourself scrambling to motivate them through tough periods when the projects aren’t going well, or when you have to tell individuals that they aren’t ready to be promoted just yet, that they aren’t getting a raise, that there’s no bonus this year. Some of them don’t bother to tell you when they’re unhappy; they just get fed up and quit before you’ve noticed there’s anything wrong.
When the company is doing well, and you have lots of money to pay, and there are plenty of exciting projects, life is great; but when things are stressful, you see how little power you have to make people happy.
most people are not as good at following processes as they are.
Engineers who believe in the “right tool for the job” sometimes turn into process czars when they become tech leads, seeking out the right tool to solve all issues with planning, focus, time management, and prioritization. They try to stop all work while they search for the perfect process, or constantly push new tools and processes on the team as solutions to the messier problems of human interactions.
Agile Manifesto are a great summary of healthy process leadership: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
it is impossible to do quality, thoughtful work for too many hours a week.
Everyone in your organization knows who you are, understands how valuable your work is, and is deferential to your opinions.
you can switch tracks if you want. It is common for people to try out management at some point, realize they don’t enjoy it, and go back to the technical track.
go in with your eyes wide open.
process itself can be changed to be easier to follow. It’s a waste of your time to play rules cop, and automation can often make the rules more obvious.
Understand the Architecture If you go into a tech lead role and you don’t feel that you fully understand the architecture you are supporting, take the time to understand it. Learn it. Get a sense for it. Visualize it. Understand its connections, where the data lives, how it flows between systems. Understand how it reflects the products it is supporting, where the core logic for those products lives. It’s almost impossible to lead projects well when you don’t
If you go into a tech lead role and you don’t feel that you fully understand the architecture you are supporting, take the time to understand it. Learn it. Get a sense for it. Visualize it. Understand its connections, where the data lives, how it flows between systems. Understand how it reflects the products it is supporting, where the core logic for those products lives. It’s almost impossible to lead projects well when you don’t understand the architecture you’re changing.