Eng Management for the rest of us - raw notes

eng-mgmt-book.md

How to use this

• A leader creates ==clarity== where there is none
• enabling others - it's the whole gig
• model the behavior you want
• gratitude journaling
• LEARN: OKRs and figure out the milestones needed via data and then being able to measure the actual impact

Raw notes

your work is now about enabling everyone around you.

coordination is your job.

The culture and morale on your team is a large part of your responsibility.

"A leader creates clarity where none exists."

In order to make real change, we need to connect ppl to the 'why.'

treat all feedback exchanges, as much as possible, as though they were a partnership.

Give praise in public, feedback in private

It's important to be honest with ourselves; what we work on is an expression of our values.

It's only a boundary if the other person hears it. ^ Boundaries are only boundaries once tested.

Gratitude journaling - try it

ch9 - communicating as a manager

• your job is to align ppl with outcomes rather than how it should be done
  • instead of telling what to do, ask questions, ex: "is this API definition the best we can offer our users?"
  • more than anything, we have to be clear
• align with the why - if you can properly address the reason, you'll have a lot more buy-in b/w engineers
• skill - conveying the same message in 10,000 diff ways.
• be transparent and speak in plain english

ch14 - managing conflicts "you have to know your preferences well, bc no matter what you do, someone will tell you you're wrong."

• you need conflict to challenge and flesh out an idea, consider risks, and allow everyone to see the size/shape of the thing at hand

productive conflict is an opportunity for growth - this can save your sanity

if there is a conflict, you need to address it immediately rather than letting things slide or fester

when you're leading a team, they're looking at you to model good behavior. you prob want a team that's open and collaborative, you wanna embody those qualities first.

ch16 - prioritizing your teams work

OKRs - objectives and key results

• objectives - high level goals that inspire a picture of the future (ex: Chrome - make the browser an OS")
• key results - specific measurable pieces of data over time
  • "111M WAU by year end"

70% rule - be ok with only succeeding 70% of the time.

OKRs are defined by top-level biz goal/strategy. These should clear and easy to find/reference. OKRs should make you a lil uncomfortable in their aims/reach, but not insane.

1. Define OKRs - look backward and look forward:
   1. look forwrd - what's the big picture? What could the co do to make waves in the next few years
   2. look backward - what does the data say about this direction, what's the pace of growth for this idea currently? What are the unknowns, risks? If you've got a data team at the co, this is a great time to use them.
2. Break down OKRs into something tangible
   1. ex: in order to increase signups - look at what has historically impacted your co (any spikes in data should give you clues), ex:
      1. big feature releases
      2. good seo
      3. repair of broken/confusing flows
      4. funding announcements
   2. ^ Now you can't do all these things, but you can do some, right? ex: imagine the greatest impacr made was feature releases, case studies, and funding announcements. YOu're a dev so feature releases are your most relevant thing to focus on. historically every bump from a feature release has increased signups by at least 50%.
   3. SO NOW we can walk backward from our target into how many release we need to get over the line, in conjunction with other initiatives. Imagine its 3, 3 feature releases...we'll then find a pace that seems reasonable given the allotted timeframe, and then break down those feature releases even further (ex: milestones/phases/workstreams)
3. Creating a quarterly planning spreadsheet
   1. OKRs are often defined over a 1 year span and its HARD to keep up momentum
      1. make sure everyone can see it - spread awareness so they are NO SURPRISES TO ANYONE!!
      2. guard like fuck against scope creep
      3. afterwards - share the results...what actually happened?

You can measure engineering throughput during the span of a quarter (ex: LinearB for PRs merged, issues closed, etc)...though understand that eng throughput metrics can be easily games (ex: tons of small issues, only work on the easiest PRs, etc)

If everything's important, nothing is. - You'll need to cut some shit

ch.19 - splitting time between product and engineering work

tech debt - the challenge as an EM is to notice larger patterns, like when many folks complain of the same thing, rather than 1 dev w/ a strong opinion.

sometimes tech debt is found via large refactors for small stuffs, ex: "does this css need to be updated in 200 places? really?"