Created
March 29, 2019 19:22
-
-
Save dpaola2/6fcbc58f48ae5840673ed2e5a1879276 to your computer and use it in GitHub Desktop.
Managers Path Marginalia
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| The Managers Path Notes | |
| - chapter 1: management 101 | |
| - what to expect from your manager | |
| - 1:1s | |
| - feedback, workplace guidance | |
| - give it fast | |
| - manager needs to be number one ally | |
| - ask for stretch projects | |
| - shows you the larger picture of your work, provide sense of purpose | |
| - higher levels mean managing up becomes more important, manager spends less time on this outside of perf reviews | |
| - training and career growth | |
| - you are responsible for whatever type of training you want | |
| - promotions and comp | |
| - good managers know what the system is looking for re: promotions and can help you build those achievements and skills | |
| - how to be managed | |
| - spend time thinking about what you want | |
| - you are responsible for yourself | |
| - know yourself | |
| - go after what you want | |
| - bring agendas to 1:1s | |
| - ask when you want to work on projects | |
| - look for help elsewhere if your manager isn’t helpful | |
| - seek feedback, take it graciously | |
| - work-life balance is your responsibility, and sometimes not possible to do both | |
| - you will not get everything you ask for | |
| - give your manager a break | |
| - job is to do the best thing for the company and the thing, not to make you happy all the time | |
| - the only person you can change is yourself | |
| - provide feedback | |
| - resent your mgr? maybe move. resent every manager? maybe its you | |
| - bring solutions, not problems | |
| - ask for advice if you don’t know | |
| - choose your managers wisely | |
| - | |
| - assessing your own experience | |
| - have you had a manager you considered good? what did they do? | |
| - how often do you meet 1:1? | |
| - can you tell your manager about life events? | |
| - delivered good/bad feedback? | |
| - set any work-related goals with your mgr? | |
| - chapter 2: mentoring | |
| - the importance of mentoring to junior team members | |
| - part of healthy onboarding for both parties | |
| - being a mentor | |
| - low risk | |
| - mentoring an intern | |
| - have a project in mind | |
| - project manage | |
| - listen carefully | |
| - precursor to empathy | |
| - don’t get frustrated when they can’t communicate clearly. it’s hard. | |
| - communicate clearly | |
| - communicate what needs to happen | |
| - what do you expect them to do? | |
| - calibrate your response | |
| - mentoring a new hire | |
| - encourage them to ask questions | |
| - pair programming to learn the codebase | |
| - onboarding docs | |
| - bring them into your networks | |
| - technical or career mentoring | |
| - as a mentor | |
| - tell your mentee what you expect from them: time commitment, style | |
| - then be honest | |
| - dont’ say yes and then fail to be a good mentor | |
| - as a mentee | |
| - come prepared | |
| - know what you want | |
| - good manager, bad manager: the alpha geek: | |
| - often shows up when engineers first become mentors | |
| - tips for the managers of a mentor | |
| - set goals, guidance, provide structure | |
| - help a new person on the team | |
| - pairing jr and sr to expand skills on the team | |
| - additional responsibility for the mentor. good job means lower productivity elsewhere | |
| - treat it like any other new responsibility: look for someone you believe can succeed, who wants to distinguish themselves beyond coding ability | |
| - pitfalls: | |
| - viewing it as a low-status “emotional labor” position | |
| - make time for it if you’ve invested in it | |
| - assuming that “like” must mentor “like” | |
| - go beyond diversity | |
| - failing to use the opportunity to observe potential on your team firsthand | |
| - reward and train future leaders! | |
| - key takeaways for the mentor | |
| - be curious and open minded | |
| - listen and speak their language | |
| - make connections | |
| - chapter 3: tech lead | |
| - role clarity | |
| - continue to write code | |
| - representing the group to management | |
| - vetting plans for feature delivery | |
| - dealing with a lot of the details of project management process | |
| - learning how to scale themselves by delegating work effectively without micromanaging | |
| - focus on whole team’s productivity and strive to increase their impact | |
| - learning how to partner effectively with other teams | |
| - influence without authority | |
| - all great tech leads know this one weird trick | |
| - step away from the code and balance your technical commitments with the work the whole team needs | |
| - you must master your time | |
| - balance things you know vs. things you don’t know how to do | |
| - makers vs. managers schedule | |
| - being a tech lead 101 | |
| - main roles | |
| - systems architect and business analyst | |
| - have a good sense of the overall architecture, how to design complex software | |
| - understand business requirements and translate them into software | |
| - project planner | |
| - break down work into deliverables | |
| - parallelize! | |
| - apply agreed-upon abstractions | |
| - gather input from the experts on the team, start identifying priorities | |
| - software developer and team leader | |
| - write code, communicate challenges, and delegate | |
| - don’t be tempted to pursue heroics | |
| - continue writing code, but not too much | |
| - raise issues early | |
| - managing projects | |
| - you can’t use agile for everything | |
| - and you will always need project management | |
| - especially w/ projects that are infrastructure, platform, system projects that require significant advanced planning | |
| - the value of planning isn’t 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 to see what happens | |
| - managing a project | |
| - break down the work | |
| - and sequence it | |
| - push through the details to the unknowns | |
| - everyone hates it | |
| - run the project and adjust the plan as you go | |
| - real value of planning is to help you know roughly how far the project has come, and roughly how far it is from completion | |
| - things always slip | |
| - keep everyone apprised of the status | |
| - use the insights gained in the planning process to manage requirements changes | |
| - use new insights from initial breakdown and apply them to the changes | |
| - be clear about the cost | |
| - revisit the details as you get close to completion | |
| - run a premortem | |
| - celebrate! | |
| - stay on tech track or become a manager? | |
| - good manager, bad manager: the process czar | |
| - agile manifesto | |
| - individuals and interactions over processes and tools | |
| - working software over comprehensive documentation | |
| - customer collaboration over contract negotiation | |
| - responding to change over following a plan | |
| - look for self-regulating processes | |
| - as a manager, help process czars become comfortable with ambiguity | |
| - it’s safe to fail and to be imperfect | |
| - make sure they don’t punish their teams for failing to follow processes | |
| - how to be a great tech lead | |
| - understand the architecture | |
| - be a team player | |
| - lead technical decisions | |
| - determine which decisions need to be made by you, which to delegate, and which require the whole team | |
| - communicate | |
| - represent the team | |
| - communicate their needs | |
| - bring info back from that meeting to the team | |
| - chapter 4: managing people | |
| - starting a new reporting relationship off right | |
| - build trust and rapport | |
| - how do you like to be praised? in public or private? | |
| - preferred method of feedback? in writing? or is less formal OK? | |
| - why did you decide to work here? what are you excited about? | |
| - how do I know when you’re in a good mood or a bad mood? or annoyed? what puts you in a bad mood? | |
| - any management behaviors that you hate? | |
| - do you have any clear career goals that I should know about so I can help you achieve them? | |
| - any surprises since you’ve joined, good or bad, that I should know about? | |
| - create a 30/60/90 day plan | |
| - for new people: basic goals (like getting up to speed on the code, committing a bug fix, releasing, etc) | |
| - more senior = the more involved they are in creating this plan | |
| - create a set of realistic milestones based on your prior hires, current state of your tech and project, and the level of the person | |
| - this helps you catch bad hires | |
| - encourage participation by updating the new hire docs | |
| - delegate this to a mentor, buddy, peer | |
| - communicate your style and expectations | |
| - how often you want to meet | |
| - how you will share information | |
| - when and how often you’ll review work | |
| - how long should they work alone trying to solve a problem vs when to ask for help? | |
| - get feedback from your new hire | |
| - in the first 90 days | |
| - communicating with your team | |
| - regular 1:1s | |
| - start weekly | |
| - adjust accordingly | |
| - respect the maker schedule | |
| - tues,wed,or thurs are best | |
| - adjusting 1:1s | |
| - how often do you interact offhand during the week? | |
| - how much coaching does this person need? | |
| - how much does this person push information up to you? | |
| - more face-time compensates for this risk | |
| - how good is your relationship with this person? | |
| - don’t spend all your time with problem employees and ignore the stars | |
| - how stable or unstable are things in the team or the company? | |
| - company news | |
| - keep stability | |
| - slow down rumors | |
| - different 1:1 styles | |
| - the todo list meeting | |
| - professional and efficient, if cold | |
| - force the direct report to think beforehand | |
| - the catch-up | |
| - listen | |
| - driven by the direct report | |
| - give them space | |
| - creative discussion just as much as planning | |
| - downfall: it can turn into complaining session / therapy | |
| - empathetic leaders get sucked into unhealthy closeness | |
| - the feedback meeting | |
| - regular intervals | |
| - quarterly is frequently enough | |
| - more frequent for performance issues | |
| - document these meetings before firing | |
| - issues discussed | |
| - expectations set | |
| - in writing, and sent to them | |
| - don’t wait for a 1:1 to provide feedback on something that requires immediate attention | |
| - longer you wait, harder to bring up, less effective | |
| - same goes for praise | |
| - the progress report | |
| - managing managers | |
| - break their habit by asking them to prepare answers to questions that are unrelated to the current project status | |
| - or ask them to come prepare with questions for you to answer about the team, company, whatever | |
| - if there really is less to talk about, maybe meet less frequently | |
| - getting to know you | |
| - leave room to get to know them as a human being | |
| - don’t pry, but show them you care personally | |
| - family, friends, hobbies, pets | |
| - career so far, ask about long-term career goals | |
| - not just the next step | |
| - mix it up | |
| - walking | |
| - coffee | |
| - lunch | |
| - critical conversations require notes | |
| - keep notes in a shared document | |
| - manager takes the notes | |
| - notes, takeaways, todos | |
| - historical record | |
| - good manager, bad manager: micromanager, delegator | |
| - trust and control are main issues | |
| - don’t strip creative and talented people of their autonomy | |
| - delegating is not the same as abdication | |
| - delegating effectively means you’re expected to be involved as much as necessary to help the project succeed | |
| - practical advice for delegating effectively | |
| - use the team’s goals to understand which details you should dig into | |
| - when you feel the urge to micromanage, ask the team how they’re measuring their success | |
| - ask them to make that visible to you on an ongoing basis | |
| - wait a week or two and see what they give you | |
| - nothing to share = course correction | |
| - gather information from the systems before going to the people | |
| - check tickets, repositories, etc. | |
| - use a light touch when you ask the team for things | |
| - it’s just context, not the whole picture, and means nothing without the goals discussed | |
| - adjust your focus depending on the stage of the projects | |
| - early on, maybe more involved in order to facilitate good set of goals, system design | |
| - closer to delivery date, progress details become more important, more decisions to be made out of those details | |
| - normally, it’s enough to know what’s moving forward and what’s taking longer than expected | |
| - establish standards for code and systems | |
| - how much unit testing to do | |
| - when should decisions be reviewed by a larger group | |
| - treat the open sharing of information, good or bad, in a neutral to positive way | |
| - create a culture of continuous feedback | |
| - know your people (goals, strengths, weaknesses) | |
| - observe your people | |
| - provide lightweight, regular feedback | |
| - use coaching | |
| - positive: pair with a suggestion about what could’ve been done even better | |
| - most important for early career reports | |
| - performance reviews | |
| - do 360-degree reviews | |
| - writing and delivering | |
| - give yourself enough time, start early | |
| - collect feedback, digest it, summarize it well | |
| - read collected reviews, take notes, come back after some digestion to write the review | |
| - try to account for the whole year, not just the past couple months | |
| - easier if you take notes on what’s happened throughout the year | |
| - keep feedback and running summary in 1:1 doc | |
| - recognize early accomplishments, and the growth and change you’ve seen since | |
| - use concrete examples, excerpts from peer reviews | |
| - spend plenty of time on accomplishments and strengths | |
| - don’t skip this, it will be what you use to determine promotions | |
| - areas of improvement: keep it focused | |
| - <examples are in the text> | |
| - don’t just blindly report all grudges | |
| - no feedback on improvements = person is ready to be promoted or for more challenging work | |
| - avoid big surprises | |
| - if someone was promoted, make sure they’re prepared for higher standards | |
| - schedule enough time to discuss the review | |
| - printed copy | |
| - maybe the evening before, to come prepped in person | |
| - using a scale system is the hardest part for people who didn’t get the top rating | |
| - how could they achieve a higher score? | |
| - cultivating careers | |
| - it’s usually up to you as a manager | |
| - learn how the game is played at your company | |
| - identify promotion-worthy projects and give those to people who are close | |
| - assign directly, or encourage people to volunteer for stretch goals | |
| - challenging situations: firing underperforms | |
| - make expectations clear early and often | |
| - no surprises | |
| - pile of excuses means you haven’t been giving feedback early and often enough | |
| - don’t put anyone on a plan who you wouldn’t be happy to lose | |
| - OK to coach out: he’s been told repeatedly what’s expected of him to progress, and you haven’t seen that, so it might be the case that he won’t progress unless he moves somewhere else | |
| - retain good will, help him look, etc. | |
| - chapter 5: managing a team | |
| - JD (engineering lead) | |
| - spend less time writing code | |
| - still engage in small technical deliverables (bug fixes, enhancements) without blocking or slowing down the team | |
| - responsible for identifying bottlenecks in the process and roadblocks to success, clearing them | |
| - expected to have a large impact on the success of the organization as a whole | |
| - identify high value projects, keep the team focused on these projects | |
| - partner with product lead to manage scope, ensure deliverables are met | |
| - identifying headcount needs, planning and recruiting | |
| - independent manager | |
| - comfortable managing team members w/ different skillsets from their own | |
| - communicate expectations clearly | |
| - solicit and deliver individual feedback frequently | |
| - staying technical | |
| - engineering mgmt is a technical discipline, not just a set of people skills | |
| - technical instincts are very important | |
| - team must see you as technically credible | |
| - if you don’t stay in the code, you risk making yourself technically obsolete too early in your career | |
| - stay in the code to see where the bottlenecks and process problems are | |
| - w/ trivial programming tasks | |
| - identify what is possible and impossible (w/ product people) | |
| - project paths become your responsibility to see | |
| - debugging dysfunctional teams: the basics | |
| - not shipping | |
| - balance pushing them vs. holding them back | |
| - tools and processes make it hard to get work done? | |
| - infrequent releases can hide pain points: poor tooling, heavy manual QA, features that are too big, developers who don’t know how to break work down | |
| - releases cause resource contention, making them less scarce eases that | |
| - people drama | |
| - sometimes we let ourselves hang onto that brilliant asshole for too long | |
| - less severe: stirs up drama, dwells on negative experiences, bit too much time on gossip and us vs. them | |
| - be brave, nip people in the bud quickly | |
| - harder for your manager to do this, because they’re not as exposed to it (all they see is productivity) | |
| - make it clear: this must change, bring up examples, provide corrective feedback quickly | |
| - sometime they’re just unhappy and you need to help them leave on good terms | |
| - other times: no idea the impact they had, just a quick convo will help | |
| - best defense is a good offense | |
| - unhappiness due to overwork | |
| - instability in the system/process/tools?? fix that on a team-wide basis | |
| - sustainability instead of tech debt | |
| - when it’s time-related? | |
| - you should be playing cheer leader | |
| - support the team, by working yourself | |
| - order dinner, tell them you appreciate the hard work | |
| - make it clear they have explicit time break after the thing ships | |
| - make it fun, crunch period can be a bonding time | |
| - they’ll remember whether their manager was with them or off doing their own thing | |
| - learn as much as you can: cut features, push back on unrealistic dates | |
| - they’ll happen but they don’t need to happen frequently | |
| - collaboration problems | |
| - no quick fix, but showing willingness to improve goes a long way | |
| - gather actionable feedback from your team | |
| - make the situation worse by your peers in front of your team | |
| - so even when you’re frustrated, try to stay positive and supportive of their efforts in public | |
| - create opportunities to hang out when it’s not about work | |
| - take the whole team to lunch | |
| - leave early on friday to attend a fun event together | |
| - encourage PG humor in chat rooms | |
| - ask people how their lives are going | |
| - the shield | |
| - the team should not be distracted by things that don’t matter to them | |
| - but it’s unrealistic to expect that you can keep your team from being distracted by everything that happens | |
| - the goal is to not stress them out | |
| - context for goals is important, so they’ll be connected to those distractions | |
| - alleviate gossip quickly by communicating changes in a straightforward, low-emotion way so they feel in the loop | |
| - you’re not a parent. treat them with respect | |
| - how to drive good decisions | |
| - nature of leadership: you’re responsible for the outcome of decisions, but you don’t make the decisions | |
| - data-driven | |
| - give the product or business folks data | |
| - flex your own product muscles | |
| - develop customer empathy (even if it’s internal customers) | |
| - look into the future | |
| - think two steps ahead of the product roadmap (and tech roadmap) | |
| - ask the product team what the future might look like | |
| - projects will be judged on their ability to enable new features more easily | |
| - keep up on tech developments | |
| - review the outcome of your decisions and projects | |
| - talk about whether your hypotheses turned out to be true | |
| - make it a habit | |
| - run retrospectives for the processes and day-to-day | |
| - good manager, bad manager: conflict avoider, conflict tamer | |
| - creating a safe environment for disagreement to work itself out is far better than pretending that all disagreement does not exist | |
| - the dos and don’ts of managing conflict | |
| - don’t rely exclusively on consensus or voting | |
| - assumes everyone is impartial, has equal stake in outcomes, and equal knowledge of context | |
| - deliver the bad news yourself instead of having the team vote | |
| - do set up clear processes to depersonalize decisions | |
| - group needs a clear set of standards for how they make decisions | |
| - start w/ shared understanding of goals, risks, and questions | |
| - when you assign ownership of the decision, make it clear which members of the team should be consulted for feedback, and who needs to be informed of the decision or plan | |
| - don’t turn a blind eye to simmering issues | |
| - surprise feedback from peers of a direct report means you’re not paying attention, or not making space to talk in 1:1s about problems with colleagues | |
| - do address issues without courting drama | |
| - allow space for people to express frustration, but mind the difference between letting off steam vs. a real interpersonal issue | |
| - key questions | |
| - is this an ongoing problem? | |
| - is it something you’ve personally noticed? | |
| - are many ppl on the team struggling with it? | |
| - is there a power dynamic or potential bias at play? | |
| - identify problems the team is dealing with preventing them from working effectively and resolve them | |
| - don’t be their therapist | |
| - don’t take it out on other teams | |
| - do remember to be kind | |
| - not “nice” | |
| - don’t be afraid | |
| - do get curious | |
| - challenging situations: team cohesion destroyers | |
| - pizza test: if you bought pizza for the team, would they stick around to eat it for dinner? or would they all race out the door? | |
| - gelled teams have a sense of camaraderie | |
| - joke together, get coffee, share lunch, feel friendly toward one another | |
| - psychological safety is the goal | |
| - take risks, make mistakes in front of one another | |
| - underpinning of a successful team | |
| - cultivate relatedness | |
| - the brilliant jerk | |
| - fire them (but its hard) | |
| - don’t hire them | |
| - don’t promote them!!!!! | |
| - if they don’t see their behavior as a problem, they won’t fix it | |
| - openly refuse to tolerate bad behavior | |
| - rare exception to “praise in public, criticize in private” | |
| - “please do not speak to people this way. it’s disrespectful.” | |
| - have tight control over your reaction | |
| - it’s a fine line | |
| - it will undermine you if you seem emotional | |
| - first goal is to protect the team, second goal is to protect each individual, last priority is protecting yourself | |
| - the non communicator | |
| - information hiding on everything | |
| - nip it in the bud | |
| - make it clear he’s not meeting expectations | |
| - often a sign of fear | |
| - sometimes doesn’t respect manager | |
| - isn’t being collaborative which is toxic to team cohesion | |
| - address root cause of the hiding | |
| - is the team rejecting the individual? | |
| - move them, or correct the team’s habits? | |
| - the employee who lacks respect | |
| - you can’t have them working for you | |
| - why is she working there if she doesn’t respect the people around her? | |
| - ask if she wants to be working on your team | |
| - if yes | |
| - lay out what you expect, clearly and calmly | |
| - if no | |
| - help them out | |
| - advanced project management | |
| - need to decide which projects to take on, which systems to support, etc. | |
| - project mgmt rules of thumb | |
| - none of this is a replacement for agile project management | |
| - you have 10 productive engineering weeks per engineer per quarter | |
| - Q1 will be most productive, Q4 least productive | |
| - budget 20% of time for generic sustaining engineering work across the board | |
| - testing, debugging, cleaning up legacy code, migrating language or platform versions, doing other work that has to happen | |
| - if you don’t, expect feature development to slow down | |
| - as you approach deadlines, it’s your job to say no | |
| - the only way to hit them is to cut scope | |
| - which must-haves are not must-haves? | |
| - say no to both sides | |
| - use the doubling rule for quick estimates, but push for planning time to estimate longer tasks | |
| - be selective about what you bring to the team to estimate | |
| - distracting and stressful to have a manager constantly asking you for estimates | |
| - don’t be a telephone, but don’t be black hole either | |
| - try to get a process in place for talking about new features and customer complaints, and limit estimations that occur outside this process | |
| - chapter 6: managing multiple teams | |
| - director of engineering usually where you start managing multiple teams | |
| - tech leads report to you | |
| - ladder responsibilities: | |
| - not coding | |
| - responsible for significant area of the technology team | |
| - leads engineers across multiple product areas or technology functions | |
| - both tech leads + ICs report to them | |
| - responsible for their org’s overall technical competence, guiding and growing competence as necessary via training and hiring, | |
| - strong technical background and spend some time keeping abreast of newest technology trends | |
| - expected to help debug and triage critical systems | |
| - should understand systems well enough to perform code review, help research problems as needed | |
| - should contribute to architecture and design efforts by by serving as technically savvy voice that asks business and product questions | |
| - ensuring code matches product and business needs and can scale as needs grow | |
| - concerned with smooth execution of complex deliverables | |
| - continually evaluate and refine infrastructure / development standards and processes to create tech that will deliver sustained value to the business | |
| - high performance, high-velocity organizations | |
| - measuring and iterating on processes | |
| - leaders for recruiting, headcount management and planning, career growth and training for their org | |
| - manage vendor relationships and participate in budgeting process | |
| - impact spans multiple areas of tech org | |
| - create and grow next generation of leadership and mgmt talent in their org, teaching that talent to balance tech/ppl management and leadership | |
| - own retention goals | |
| - strategically balancing immediate and long-term product/business work with tech debt and strategic technical development | |
| - strong leaders, set example for cross-functional collaboration between engineering and other areas | |
| - combined roadmap! | |
| - strong communicator | |
| - create positive public presence | |
| - guide the goal-setting process for their team | |
| - stay hands on with the code somehow! but you’re too busy. code review is best way | |
| - we often dismiss these small efforts as not worthwhile (like small bug fixing) but they’re quite important | |
| - if you totally disconnect, at least make an hour per week creative time for blogging, researching, etc. | |
| - managing your time: what’s important, anyway? | |
| - importance vs. urgency | |
| - example of important but not urgent: preparing for meetings | |
| - your manager expects you to proactively deal with important but not urgent before they become urgent | |
| - be very careful about avoiding meetings that you aren’t sure you should be a part of, at this level | |
| - thinking about the future is important but not urgent | |
| - decisions and delegation | |
| - simple and frequent: delegate | |
| - attending daily standup | |
| - writing up summary of team’s work that week | |
| - conducting minor code reviews | |
| - simple and infrequent: do it yourself | |
| - faster! | |
| - complex and frequent: delegate carefully | |
| - project planning, systems design, being key person during an outage | |
| - biggest opportunities to grow talent while also making the team run better | |
| - goal is to make your team capable of operating at a high level without you | |
| - project management | |
| - onboarding new team members | |
| - breaking down roadmap goals into technical deliverables | |
| - production support | |
| - complex and infrequent: delegate for training purposes | |
| - have a tech lead sit with you to write a performance review for an intern | |
| - have a senior engineer provide feedback on how many new people he believes we need to support a project next year | |
| - ask for help from above on these tasks until you’re comfortable doing them, and then start pulling rising leaders from below to teach them | |
| - challenging situations: strategies for saying no | |
| - yes and | |
| - respond with positivity while conveying the boundaries of reality | |
| - create policies | |
| - when you start repeating yourself, you have the basis of a policy | |
| - hard requirements that must be met to say yes | |
| - help me say yes | |
| - curious interrogation of ideas can help you say no and teach at the same time | |
| - appeal to budget | |
| - work as a team | |
| - don’t prevaricate | |
| - say it quickly, don’t drag it out | |
| - technical elements beyond code | |
| - mistake: assume the job id primarily nontechnical | |
| - questions to ask | |
| - do i know what is expected of me at work? | |
| - do I have the materials and equipment to do my work right? | |
| - do i have the opportunity to do what I do best every day? | |
| - discern the answers to these questions through the speed/frequency engineers push code | |
| - measuring the health of your engineering team | |
| - not coding much, but it’s still your responsibility get the technical work done well | |
| - frequency of releases | |
| - frequency of code check-ins | |
| - frequency of incidents | |
| - good manager, bad manager: us vs. them, team player | |
| - the virtues of laziness and impatience | |
| - directed at processes and decisions, not at individuals | |
| - practice modeling: what’s most important? when to go home? | |
| - faster is NOT “harder, longer hours, to deliver on time” | |
| - faster IS “same value to the company, delivered in less time” | |
| - chapter 7: managing managers | |
| - context | |
| - coverage area for teams has increased | |
| - more projects and people than you could possibly manage yourself | |
| - larger scope of efforts | |
| - functions you haven’t managed before and don’t have a lot of expertise in | |
| - answers are less at your fingertips than they were before | |
| - hone your instincts, following up on things you sense are off | |
| - fallacy: open door policy. it’s your job to be proactive! | |
| - skip-level meetings | |
| - once a quarter | |
| - keeps them as humans (instead of “resources”) | |
| - they can ask questions they wouldn’t normally ask | |
| - provide prompts, remind them it’s largely for their benefit | |
| - each person should come prepared to focus on whatever they want to talk about | |
| - suggested prompts | |
| - what do you like best/worst about your project | |
| - who on your team has been doing really well recently | |
| - feedback about your manager? | |
| - what changes should we make to the product? | |
| - are we missing any opportunities | |
| - how’s the org doing overall? anything more/better/less? | |
| - areas of business strategy you don’t understand? | |
| - what’s keeping you from doing your best work right now | |
| - how happy (or not) are you about working at the company right now? | |
| - what could we do to make work at the company more fun? | |
| - to scale, do it as group lunch | |
| - what can i, your manager’s manager, provide for your team? | |
| - is this team working poorly, from your perspective, with any other teams? | |
| - are there any questions about the larger organization i can answer? | |
| - detect places where you’re being “managed up” well, to the detriment of the team below them | |
| - constant trade-off between investing in expensive engagements, that provide deep value but are costly, and casual engagements that are more efficient but less useful info | |
| - accountability | |
| - managers: they should make your life easier | |
| - sometimes they make your life easier by hiding problems, telling you what you want to hear | |
| - common scenarios | |
| - unstable product roadmap | |
| - errant tech lead | |
| - full-time firefighting mode | |
| - often they’ll need your help or support | |
| - clout, finding people, approve requests | |
| - they’ve done the hard work of identifying the problem, you should help them with the solutions | |
| - take time do give feedback in 1:1s, as always. easy to reprioritize this but it’s just as important | |
| - good manager, bad manager: the people pleaser | |
| - first-timers | |
| - you don’t know what you don’t know | |
| - upfront cost that pays long-term dividends | |
| - when people start quitting because their manager hasn’t given them a career path, it’s your responsibility | |
| - overwork is a sign of struggling first-timers | |
| - overwork also sign of a person who thinks she’s in control, taskmaster, making all the decisions | |
| - not just about making your life easier, but about being on top fo the team’s performance and delivery, guiding their focus / goals | |
| - it sucks a lot to promote the wrong person to management, but it’s a critical error to keep them there for long after you know they’re wrong | |
| - external training helps a lot | |
| - experienced managers | |
| - management tends to be a very culture-specific task | |
| - first challenge: culture fit | |
| - managers create subcultures, and an incompatible subculture is a problem | |
| - we overvalue product expertise, blinds us to culture and process mismatches | |
| - experienced managers often have different ideas about what management is, and you’ll have to work out what those differences are | |
| - be willing to learn from them, but don’t be afraid to provide feedback | |
| - collaborate on areas of difference | |
| - all managers should respect and nurture the kind of culture that you think is best for the team | |
| - difference between experienced manager and first timer is: managing independently | |
| - coaching is more about increasing impact | |
| - don’t forget to delegate to this person | |
| - hiring managers | |
| - first, make sure they have the skills you need | |
| - second, make sure they’re a culture fit | |
| - managers can theoretically bullshit you more easily | |
| - separate fear about downside of hiring them from what your’e trying to evaluate in your interview process | |
| - start with role-playing 1:1s: have people who’d report to them ask for help with problems they have now or recently, | |
| - manager must be able to debug teams. describe a time they ran a project that was behind schedule, or role-play with an employee who is thinking about quitting | |
| - how have they coached employees who were struggling, and great employees grow to new levels | |
| - ask about management philosophy | |
| - even more senior, maybe a presentation to a room of people | |
| - judge not the content, but the ability to command a room, answer questions posed by a group, structuring thoughts, getting in front of an audience | |
| - but don’t overvalue this | |
| - for someone who will need to write code, give abbreviated version of technical interview | |
| - for nontechnical, ask technical questions they should be able to address given their experience | |
| - design and architecture questions are good | |
| - make sure they can discuss tradeoffs they made and why | |
| - mediate a technical debate between two programmers who disagree on a solution to the problem | |
| - reference check | |
| - debugging dysfunctional organizations | |
| - best engineering managers are great debuggers | |
| - relentless pursuit of the “why” | |
| - have a hypothesis (minimally invasive) | |
| - check the data (same rigor as technical bug) | |
| - look at chats, emails, tickets, code reviews, commit messages, calendars | |
| - observe the team | |
| - boring meetings are a sign!!!!! | |
| - but be careful, your presence changes their behavior | |
| - ask questions | |
| - what are their goals? | |
| - who is the user? | |
| - did they have any part in deciding these goals? why? why not? | |
| - check the team dynamics | |
| - do people like each other? friendly? | |
| - collaborate? or solo? | |
| - good working relationship with adjacent teams? | |
| - jump in to help | |
| - it’s OK to jump in and help the team debug and fix issues | |
| - particularly when the manager is struggling | |
| - opportunity to teach manager and grow them | |
| - can also reveal more foundational problems, like lack of senior business leadership | |
| - be curious | |
| - setting expectations and delivering on schedule (cultivating team’s technical strategy) | |
| - frustrating: “why is this taking so long?” | |
| - good: things are slipping | |
| - bad: leadership didn’t like original estimate, or didn’t ask for it at all, now they’re upset, despite everything going fine | |
| - always be aggressive about sharing estimates and updates to estimates, even when people don’t ask | |
| - this means you must be aggressive about getting estimates | |
| - estimates are useful not just for time tracking but because they escalate complexity to the rest of the team | |
| - we’re not talking about an engineering team, we’re talking about a business that needs to plan and get ideas of costs for effort | |
| - goal setting, learning how to get better about understanding our software and systems | |
| - teaching teams how to hone their instincts about complexity and opportunity is worthwhile goal | |
| - make estimation a habit | |
| - cut scope towards the end of projects | |
| - be willing to take the fall on cutting someone’s favorite idea | |
| - challenging situations: roadmap uncertainty | |
| - be realistic about the likelihood of changing plans given the size and the stage of the company | |
| - break down big projects so you can deliver on something! | |
| - don’t overpromise a future of technical projects | |
| - dedicate 20% of your engineering time to “sustaining engineering” | |
| - refactoring | |
| - fix outstanding bugs | |
| - improving engineering processes | |
| - doing minor cleanup | |
| - ongoing support | |
| - take this into account in every planning session | |
| - understand how important various engineering projects really are | |
| - how big is it? | |
| - how important is it? | |
| - can you articulate the value to anyone who asks? | |
| - what would successful completion of the project mean for the team? | |
| - gather data! | |
| - talk about what will be possible once it’s done | |
| - help people feel capable of tying up loose ends, stabilizing current projects, easing into new work in a controlled fashion | |
| - you can and should push back | |
| - make sure your teams get adequate time to finish up current work | |
| - push for engineering involvement early in planning so people can get excited about upcoming projects | |
| - understand reasons for changing roadmap, convey to your teams | |
| - staying technically relevant | |
| - oversee technical investment | |
| - match proposed projects and improvements to the future of the product or customer needs | |
| - look holistically across the whole range of projects and products | |
| - ask informed questions | |
| - what are the current projects, and what surprises or bottlenecks have they uncovered? | |
| - how is the team thinking about the future of their systems? | |
| - which teams are asking for more engineers, and why do they need more people? | |
| - which teams are slow, but don’t want to add more people to increase throughput? | |
| - why are they advocating for this specific project right now? | |
| - analyze and explain engineering and business trade-offs | |
| - make specific requests | |
| - managers who don’t stay technical enough: instead of filtering requests, you relay them to the team and then relay the team’s response back up to management. NOT VALUE ADD | |
| - use your experience as a gut-check | |
| - read the code | |
| - pick an unknown area and ask an engineer to explain it to you | |
| - attend postmortems | |
| - keep up with industry trends in software development processes | |
| - not every trend is worth pursuing, but you want to keep your teams evolving | |
| - never stop learning | |
| - articles, tech talks, blog posts, videos, etc. | |
| - chapter 8: the big leagues | |
| - The CTO should be the strategic technical executive the company needs in its current stage of evolution | |
| - No matter what, CTO must understand current technology opportunities and risks for the business are and focus on capitalizing on them | |
| - Strong CTOs have significant management responsibilities and influence | |
| - CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and ideas | |
| - Changing priorities | |
| - The more senior you are, the more you need to focus on making sure the organization is moving in the direction it needs to move in | |
| - This includes changing direction when needed | |
| - Clearly communicate the direction to the teams, make sure they understand it, and are taking necessary steps to change course | |
| - Ask your teams for the list of projects the change will impact, so you can communicate it upward | |
| - This will force your leadership to actually think about the new initiative and start to plan for it | |
| - Ask for the goals of the initiative from its originator, and see how you can combine these goals with work already in-flight | |
| - Never underestimate how many times you need to communicate before it sinks in | |
| - Most people need three times | |
| - Create a communication plan, anticipate questions and pre-empt answers | |
| - Don’t forget to sell this as a good thing | |
| - Setting the strategy | |
| - Do a lot of research | |
| - Consider the team, the tech you’ve built, and the company | |
| - Ask the team where their pain points are | |
| - Ask several execs where they expect their growth to come from in the future | |
| - Ask yourself: | |
| - where are the scaling challenges now, where they might be in the future | |
| - examine engineering team, identify productivity bottlenecks | |
| - study technology landscape and wondered how it might change in the near future (personalization, mobile development) | |
| - Gather: | |
| - Conclusions about existing systems, teams, bottlenecks | |
| - Imagined places we could make things more efficient, expand features, or improve the business | |
| - Combine your research and your ideas | |
| - Use the data to come up with a rough idea for a possible future | |
| - Lock yourself in a room with a whiteboard | |
| - Draw out the systems in place at the company | |
| - Slice and dice the systems and teams across various common attributes | |
| - Backend vs. frontend | |
| - Technology must model most of the business data to operate | |
| - You have a unique insight into the way that data flows and changes, possible axes for evolution | |
| - Draft a strategy | |
| - Plan out actionable ideas to improve operational efficiency, expand features, grow the business | |
| - Consider places where you might want to potentially limit or expand information sharing between systems | |
| - Consider the structure of the business, the needs of the customer (internal and external), and possible future evolutions | |
| - | |
| - Consider your board’s communication style | |
| - Good technology strategy can mean: | |
| - technology architecture | |
| - team structure | |
| - understand underpinnings of the business, directions it was headed | |
| - “enables the many potential futures of the business” | |
| - enable the larger roadmap to play out successfully | |
| - Hardest part is getting started | |
| - Guess about the future with imperfect information | |
| - Reactive vs. forward-looking | |
| - Make plans to accommodate it | |
| - After clarifying it for yourself, leading became easier. | |
| - Vision of where we’ll go as a technology platform, not just what the product roadmap looked like | |
| - Architecture leads the technology organization, which leads the company organization. | |
| - Challenging situation: Delivering bad news | |
| - Don’t blast an impersonal message to a large group | |
| - Worst way is via email or chat, it should come from your mouth | |
| - Second worst way is in a large group, all at once | |
| - Do talk to individuals as much as possible | |
| - Tailor your message to people who will have the worst reactions | |
| - Talk to your managers first, give them talking points, then let them share with their teams before bringing the whole group together | |
| - Don’t force yourself to deliver a message you can’t stand behind | |
| - Do be honest about the likely outcomes | |
| - Do think about how you would like to be told | |
| - Senior Peers in other functions | |
| - let them own their areas | |
| - trust that they’re actively trying to do their best and not manipulating situations | |
| - respect the cone of silence (once a decision is made, even if you disagree, you commit) | |
| - keep disagreements on the leadership team IN THAT ROOM | |
| - the echo | |
| - a challenge can be shifting your mindset from “one of the team” to “the one in charge” | |
| - socializing heavily with your team is a thing of the past | |
| - you need to detach | |
| - you’ll be accused of playing favorites if you don’t | |
| - you WILL play favorites | |
| - learn how to lead effectively, which requires people taking your words seriously | |
| - throwaway comments can cause people to change focus | |
| - maintaining a “buddy” image makes it hard for DRs to distinguish between buddy thinking out loud vs. boss asking them to focus | |
| - be thoughtful about where you spend your time | |
| - Transparency that may have been harmless or helpful at lower levels of management become incredibly damaging to the stability of the team at this level | |
| - Care more about individuals in small ways, ask about families/hobbies/interests | |
| - Be a good role model | |
| - ruling with fear, guiding with trust | |
| - people afraid to take risks for fear of being blamed for mistakes | |
| - correcting a culture of fear | |
| - practice relatedness | |
| - cultivate sense of belonging and safety | |
| - let them get to know you | |
| - apologize | |
| - get curious | |
| - when you disagree, stop and ask why | |
| - learn how to hold people accountable without making them bad | |
| - doesn’t start with responsibility and end with consequences | |
| - how do you measure success? | |
| - do they have the capabilities needed to succeed? | |
| - are you providing feedback along the way? | |
| - are you holding yourself accountable for setting them up for success? | |
| - when everything is clear and you’ve all done your best, accountability comes with less character judgement because you all see clearly what has happened | |
| - true north | |
| - set the baseline for what excellence looks like in this function | |
| - core principles that a person in a functional role must keep in mind as they do their job | |
| - product: thinking of the users and their needs first and foremost, measuring and experimenting as much as possible, and pushing back on projects that don’t address the stated goals of the team | |
| - CFO: looking at the numbers, costs of work and potential value, making sure you’ve considered how the numbers work in the company’s favor, that the company isn’t accidentally spending more money than expected, that the team knows when it’s at risk of going over budget | |
| - technical leader: making sure you’ve done your job getting things ready to go into production | |
| - honored your agreed-upon policies for review, operational oversight, and testing | |
| - you won’t put something into production that you don’t believe is ready for your users to experience | |
| - creating software and systems you’re proud of | |
| - risk analysis | |
| - it doesn’t mean no risks | |
| - sometimes risks are ok under certain circumstances | |
| - having a single point of failure | |
| - having known bugs and issues | |
| - being unable to tolerate high load | |
| - losing data | |
| - putting out code that is under tested | |
| - having slow performance | |
| - when teams develop these instincts, they can be trusted to independently follow these guidelines without much direction or nudging | |
| - each functional area has it’s own true north, which results in tension within the org | |
| - staying technical early in your career helps you hone these instincts (critical) | |
| - chapter 9: bootstrapping culture | |
| - with skeptics | |
| - instead of talking about structure, talk about learning | |
| - instead of talking about process, talk about transparency | |
| - we set up structure and process to learn from our mistakes, and share lessons in a transparent way helps the org become more stable and scalable over time | |
| - early technical decisions will be undone a couple of times before they settle | |
| - pick a strategy and run with it | |
| - cultivate decisiveness in the face of a massive number of options | |
| - avoiding titles isn’t really a decision, it’s a decision to not build structure | |
| - the tyranny of structurelessness | |
| - pretending to lack structure tends to create hidden power structures resulting from the nature of human communication and challenges of trying to scale that communication | |
| - it can work when: | |
| - it’s task-oriented | |
| - relatively small and homogenous | |
| - high degree of communication | |
| - low degree of skill specialization | |
| - structure is how we scale, diversify, and take on more complex long-term tasks | |
| - we do it in our software, in our teams, and processes | |
| - strong technical systems designers are capable of identifying and shaping underlying system structures | |
| - strong leaders are able to identify and shape underlying team structures and dynamics | |
| - it’s all about long-term goals of the team and equips individuals to achieve their best | |
| - race car -> commercial flight -> spaceship | |
| - assessing your role | |
| - recognize the size of the vessel you’re steering | |
| - number of people, age of the company, size of existing business infrastructure, and risk tolerance | |
| - people | |
| - more people, more thoughtful structure to get everyone moving in the right direction | |
| - more structure = more control | |
| - modern companies focus on goals at the top instead of making decisions but that requires structure to set and communicate goals | |
| - age | |
| - older = more entrenched habits | |
| - older = more likely to survive | |
| - size of existing infrastructure | |
| - existing business rules = need more clarity on how to handle them | |
| - risk tolerance | |
| - more people depend on you = the less risk you’ll be willing to take | |
| - complex system evolves from simple system that worked | |
| - complex system designed from scratch never works and cannot be patched up to make work | |
| - when failures occur, examin all aspects of reality that contribute | |
| - patterns you see are opportunities to evolve structure by creating more / different structure or removing it | |
| - how often it happens, its cost, use best judgement | |
| - creating your culture | |
| - Culture is how things get done, without people thinking about it | |
| - unspoken, shared rules of the community | |
| - there’s no guarantee that a predetermined healthy culture will fall out | |
| - early employees form the culture, for good or for bad | |
| - the fit is never perfect, but it is very real | |
| - more like overlapping values | |
| - applying core values | |
| - define your culture | |
| - reinforce culture by rewarding people for exhibiting its values in positive ways | |
| - share core value stories frequently (at all hands or in slack) | |
| - shout-outs for going above and beyond | |
| - valuable use of performance reviews: evaluate alignment between team members values and company values | |
| - use it as part of your interview process, ask them to spot matches or collisions with values | |
| - culture fit is not about hiring friends! | |
| - don’t be vague about discussing fit, be specific | |
| - creating cultural policy | |
| - what works for one company does not always work for another, despite being similar! | |
| - writing a career ladder | |
| - solicit participation from your team | |
| - look for examples | |
| - be detailed | |
| - use both long-form descriptions and summaries | |
| - consider how the ladder relates to salary | |
| - provide many early opportunities for advancement | |
| - use narrow salary bands for early-career stages | |
| - use wide salary bands when and where you have fewer levels | |
| - consider your breakpoint levels | |
| - recognize achievement | |
| - split management and technical tracks | |
| - consider making people management skills a mid-career requirements | |
| - years of experience | |
| - don’t be afraid to evolve over time | |
| - cross-functional teams | |
| - helps w/ adversarial relationships and velocity across functional boundaries | |
| - conway’s law | |
| - will not necessarily produce the best technology! | |
| - structuring cross-functional teams | |
| - subtle implications | |
| - values of everyone in these teams will start to change | |
| - developing engineering processes | |
| - practical advice: depersonalize decision making | |
| - code review | |
| - be clear about code review expectations | |
| - use a linter for style issues | |
| - keep an eye on the review backlog | |
| - the outage postmortem | |
| - resist the urge to point fingers and blame | |
| - look at the circumstances around the incident and understand the context of the events | |
| - be realistic about which takeaways are important and which are worth dropping | |
| - architecture review | |
| - come prepared! | |
| - how many people on the team are comfortable using this new system/writing this new language? | |
| - do we have production standards in place for this new thing? | |
| - what is the process for rolling this out and training people to use it? | |
| - are there new operational considerations for using this? | |
| - be specific about the kinds of changes that need architecture review | |
| - value of arch review is in preparing for the review | |
| - choose the review board wisely | |
| - chapter 10: conclusion |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment