zlib.pub_the-managers-path-a-guide-for-tech-leaders-navigating-growth-and-change

This role requires you to have a good sense of the overall architecture of your systems and a solid understanding of how to design complex software. It probably also requires you to be able to understand business requirements and translate them into software.

Project planners break work down into rough deliverables. With this hat on, you’re learning to find efficient ways of breaking down the work so that the team can work quickly. Part of the challenge here is getting as much productive work done in parallel as possible.

You will also want to start identifying priorities as part of this process. Which pieces are critical, and which are optional?

You will also want to start identifying priorities as part of this process. Which pieces are critical, and which are optional? How can you work on the critical items early in the project?

In your position as tech lead, you should continue writing code, but not too much. Even if you are tempted to pull a rabbit out of the hat yourself, you must communicate this obstacle first. Your product manager should know as early as possible about any possible challenges.

in the process of being a tech lead, you have to act as a software developer, a systems architect, a business analyst, and a team leader who knows when to do something single-handedly, and when to delegate the work to others.

Why is the tech lead role such a heavy burden? The tech lead has a much wider scope of responsibility than the senior engineer in an individual contributor position. The tech lead is called on to help architect a project, and then to go through the steps of actually planning out the work. The tech lead is expected to make sure the team fully understands the project requirements, the work is planned, and the team is effective and performing well, all without necessarily having any management responsibilities and usually without any specific training.

How would we make it work in the complex testing framework we depended on? How would we deploy it? When did we need to order hardware to test it? How long would integration testing take?

Doesn’t agile software development get rid of the need for project management? No. Agile software development is a great way to think about work because it forces you to focus on breaking tasks down into smaller chunks, planning those smaller chunks out, and delivering value incrementally instead of all at once. None of this means that you don’t need to understand how to do project management.

I want to be building and getting value, not trying to think about how to break down a project that still has very fuzzy implementation details.

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.

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