Nat’s 2022 Technical Link Pile: Management
December 30, 2022 – 7:15 pmSee the Intro for context.
[20221231] Four Day Work Week Going Well — 97% of the 495 respondents want to stay with a four-day workweek and so do the 27 companies that responded.
[20221223] 20 Great Open Questions — for coaching and more.
[20221221] Engineering in a Hybrid World — At the time of this report,
over 50% of respondents had no definitive plan to return to the office. As companies scale, more time is spent on improving existing products whereas earlier stage companies can afford to spend more time on building. In the last year, time spent on building new capabilities declined from 61% to 56% of total elective investments. More engineering organizations are starting to track developer productivity, with the top metrics reported on being number of bugs, % of committed software, working software, and PR to release time.
[20221221] Andy Grove’s High Leverage Activities — Task-Relevant Maturity (people are good at some things and worse at others); No issue should be discussed in a group unless it affects more than two people; A decision backed by a veto may be fair and well-reasoned — but it won’t look that way to other members of the group over time; All your decisions should be made by considering six questions: What decision is needed? By when? Who should be consulted? Who decides? Who ratifies or vetoes? Who needs to be informed? Planning should focus on weekly or monthly cycles rather than quarterly or annual ones.
[20221211] To Find Meaning in Work, Change How You Think About It — Connect work to service; Craft your work – and make work a craft; Invest in positive relationships; Remember why you work.
[20221211] How to Run Customer Feedback Sessions — what it says on the tin.
[20221211] The Engineering Manager’s Toolbox — useful tips for moving systems, people, and rewards.
[20221211] Technical Debt and Productivity — summary of a paper. Developers waste 23% of their working time due to technical debt; Wasted time is most commonly spent performing additional testing; Code related issues, testing issues, and architectural issues are most strongly correlated with wasted time; Developers are largely aware of the amount of time wasted due to technical debt. However, managers are not as aware.
[20221211] Investing in Documentation — Model good writing habits; Get in the habit of editing; Make writing part of the job ladder; Focus on quality not quantity to set the bar; Act as a journalist; Empower your senior engineers; Assemble your list; Identify ownership; Assign a rotating docs czar; Don’t be afraid to delete; Level up with landing pages; Take a snapshot.
[20221210] Startup Restructuring 101 – all the advice on layoffs.
[20221210] Company-Team-Self – folks will accomplish more if you let them do some energizing work, even if that work itself isn’t very important. […] What folks may not understand, is that for a certain type of person, strictly adhering to the correct path is very energizing. That kind of person, a person who I used to be most of the time (and still revert into today when particularly frustrated), doesn’t need to do sub-optimal energizing work, because doing the correct work is inherently energizing.
[20221127] Spit Your Team and Make Them Happier — when breadth of responsibility makes a long learning curve and inhibits feeling competent.
[20221119] The Seven Levels of Busy — Michael Lopp breaks “busy” down into different degrees. Tag yourself.
[20221107] Collective Decision-Making with AHP — pair-wise evaluation of options against criteria.
[20221107] How to Plan — Kellan’s advice lands. I’ve experienced about 80% of his lessons, e.g. planning is the wrong time to introduce new things. This list helped me put words to some of the failures I’ve been a part of.
[20221107] CTO Field Guide (For the First 90 Days) — ebook made from blog posts. How to figure out where to start.
[20221107] Kickstarter Addresses Technical Debt — look at pull requests merged/day, look at busiest pull requests (ones with most comments/go-arounds), and cycle time. Simplistic story but useful opening context.
[20221003] Engineering Manager’s Bill of Rights – rights and responsibilities between org and managers.
[20221003] All Hands Meetings Strategy – balance between learning, progress, and culture.
[20221003] Platform Engineering KPIs – digging into the metrics around delivery, stability, etc.
[20221003] Multicloud Strategy – through a farm metaphor.
[20221003] Interviewing to Assess Ability to Deliver Impact – structure for interviewing engineers.
[20221003] Creating Clarity in Competencies and Ladder – visualising ladders and skills then workshopping.
[20221003] Deployment Infrastructure for a Webapp – I use 2 VPS (virtual private servers) running on DigitalOcean; The database is Postgres and is fully managed by DigitalOcean;
I use a blue-green deployment; Deployment is done via git and ssh; No CI/CD; No containers; Absolutely no Kubernetes. HN Discussion has links to interesting utilities.
[20221003] A CTO Should Be Technical – educated tradeoffs is the best reason. (HN Discussion)
[20220922] Rituals at Engineering Teams – not sacrifices.
[20220922] How to Create Psychological Safety – Approach conflict as a collaborator, not an adversary; Speak human to human; Anticipate reactions and plan countermoves; Replace blame with curiosity; Ask for feedback on delivery; Measure psychological safety.
[20220922] This is Why You Should Not Accept Unlimited PTO – Company leaders shirk responsibility; Managers and teammates bear the burden; Everyone suffers from unfairness. “Since those in an unlimited PTO organization do not accrue any time, they are typically not paid out for that earned time if they leave the company.”
[20220922] Writing Software vs Building Systems – senior engineers.
[20220922] A Development Process to Ship Features Faster – Avoid Feature Branches; Automate CI/CD pipeline; Use a monorepo; Break features into small, incremental changes; Use feature flags; Define owners; Request at least one demo per week; Deploy weekly; Freeze the code before release; Write tests (or not?).
[20220922] Inherited Worst Team and Code, How Do I Fix It? – comments are good. Exec buy-in, low hanging fruit (step 1: add version control), the Pivotal method.
[20220910] One on Ones with Executives — different types of meetings and what you should do in each. Sound advice.
[20220901] Organizational Boundary Problems — Open cultures can have a dark side too, though. Openness doesn’t come for free, and without structure to enable participation, a culture that calls itself “open” can easily evolve to increase the feelings of exclusion it was trying to avoid.
[20220901] Debugging Your Teams — based on the type of failure, what could be going on that isn’t blaming the individuals.
[20220901] Change Management for Tech Leaders — lots of things that I’ve learned the hard way, and some I now don’t have to.
[20220802] A Staff-Shaped Hole — how companies fail staff engineers. “Self-directed” doesn’t mean you can abandon without onboarding and support. “Lead with influence” often comes from those with structural power. Let leaders lead (don’t micromanage). Not coding is still doing real work. Any time you hire a great leader and they don’t deliver the magical result you expected and leave burned out, it’s basically always the organization’s fault.All men. The most senior person you have is not a de facto leader/principal. You need architects around 150 people. A custom ladder is a shitshow because it takes you out of sync from every other company. Bored at smaller companies. Promotion without a change in tasks.
[20220726] How to Quickly Onboard Engineers Successfully – it starts before day one; track it in a task; pick the right onboarding buddy; pair, pair, and more pairing; all the coffee chats; tailor the experience to the role; ship some code in a week or less; give and get feedback.
[20220718] Scrum Teams are Often Coached to Death While the Problem is with Management – points the finger at: Telling teams what they should do and by when; Telling teams to commit to the work planned, not the outcome; Continuing to have individual appraisals that conflict with the team goals; Continuing praising teams that break their sustainable pace; Continuing to expect teams to work on multiple things at the same time; Continuing to see the output as a measure of success, not the outcome; Continuing to ignore organizational impediments.
[20220629] How Individual Contributors Get Stuck – noticing how people get sidetracked and stuck is a superpower.
[20220624] Biggest Temptation of a Software CEO — throwing more bodies at problems. High velocity within the engineering team is often less a function of what a company agrees to build, but is more a function of what a company declines to build.
[20220624] Replatforming — all the hard stuff about changing your platform. Replatforming or re-architecting production software is a complex, expensive, risky proposition. Most of the challenges are around dealing with internal expectations and paying external customers, not the underlying technical details. So let’s not think of these as development-only exercises and assign sole responsibility to Engineering.
[20220624] How Engineering Managers Fail — Continuing To View Their Role Mainly as a Maker; Assuming Everyone Knows What You Do; Taking Extreme Views; Feeling the Need To “Shield” the Team; Optimising the Parts Instead of the Whole
[20220624] Code Freezes — code freezes aren’t change freezes, as hotfixes happen. Freezes reflect risk that should be removed every day, not just the days you don’t code.
[20220624] Decision Making — not “don’t be wrong”, but instead “how can I adjust course gracefully”? I needed to adapt to changes instead of assuming they wouldn’t happen.
[20220624] Know How Your Organisation Works — get comfortable with the mess.
[20220624] Strategies and Visions — really good advice on how to make useful strategies.
[20220529] Lessons Learned on the Journey from Developer to Project Manager — identify and document the context and constraints first; write everything down; The scope of the project and what needs to be done should be clear to everyone. If the methods used to support the mission get in the way or provide no immediate tangible benefits to the project, they should be removed; Your role is ultimately to cut through useless and irrelevant tasks and time wasters and focus on what will actually bring a benefit to your customers whomever they are; have contingency plan roadmaps.
[20220527] Restructuring Engineering Teams with Team Topologies – first was to stream-aligns and enabling teams; then to a platform.
[20220527] Docs for Personal Impact – prioritise the things you’re trying to achieve, understand if you’re making progress, and more. Shit that’s a lot of meta-work, tho.
[20220527] The Feedback Fallacy – questioning the value of feedback, which is premised on (1) the observer is actually seeing something accurately; (2) the observer’s suggestions for what to do more of are right. Both get shot in the knees by this article. But obviously *my* feedback is awesome and the exception here.
[20220526] Stripe’s Writing Culture – Leaders must demonstrate quality writing; Exemplify quality writing in everything you and your leadership team share; Make writing the default method of sharing knowledge; Give teammates a starting point with sample docs; Know when to standardize and when to give autonomy; Make your documentation easy to read; Create a support system; Building your culture of writing and documentation.
[20220525] When Everything is Important But Nothing is Getting Done – prioritise, minimise WIP, remove dependencies.
[20220505] Preventing Burnout: A Manager’s Toolkit – Reduce the number of hours worked by agreeing to reduce effort. Managers can ask team members to identify things that are likely to fail.
[20220504] See and Resolve Team Dependencies – blog post series with meat.
[20220406] Merge Code Every Week – reduce time to feedback.
[20220406] The Danger of Software Prototypes – sunk cost fallacy, insufficiently precise requirements (“plausible but wrong”), overzealous belief in iterative development (some architectural decisions like thread safety and 1:1 vs 1:n vs n:m schemas are hard to correct later). “Gather enough requirements to know when to throw your prototype away.”
[20220404] Scaling Engineering Teams – SWOT focused on future growth vs current status; clump them into “domains”; write a one pager for each clump w/current status, problem statement, goals; pair engineers and team leads as a designated task force for each domain; grant each task force a month with up to 20% designated time to create a structured plan (Research; Goal; Timeline & milestones; Resources); document what you learn and share it; enable and guide.
[20220404] What Makes Developers Happy at Work – salary, work-life balance, flexibility, productivity, and growth opportunities. “Feeling productive at work plays a much more critical role in team happiness than we probably realize. It shouldn’t be as surprising as it is,” said Matt Kiernander, technical advocate here at Stack Overflow. “When I code, I don’t like disruptions in my flow state. Constantly stopping and starting makes me feel unproductive. We all want to feel like we’re making a difference, and hitting roadblocks at work just because you’re not sure where to find answers is incredibly frustrating.”
[20220404] How GitHub Does Take Home Technical Interviews – nice use of GitHub’s tools. The pull request includes automated tests and a rubric so that interviewers know how to mark it and each submission is evaluated objectively and consistently. The tests run through GitHub Actions and provide a base level for the reviewer.
[20220404] End to End Feature Development – genericontent for engineering blog. Take a moment for a quiet vom at managers being called “People Empowerers”.
[20220330] Rules for Cooperative Efforts — nice series of principles by Stephen Walli.
[20220330] Continuous Documentation – incorporating documentation into the dev workflow.
[20220324] Clear Expectations – “I expect you to”, follow up (“if you walk away, I will follow”), don’t rush to reset expectations. “I expect [name] to do [thing] by [timeframe] within [constraints].” If there are action items after a meeting, you can list the items as “[name]: [timeframe]: [thing] within [constraints].”
[20220324] Technical Debt Balance Sheet – I can’t tell if this is an exercise in angels and pin heads, or if it’s seriously useful.
[20220308] 25 Microhabits of Successful Managers — close to my approach.
[20220308] Managing Technical Debt in a Microservices Architecture — really about mapping the tech capability plan. List of tech options with Preferred/Acceptable/Discouraged/Unacceptable, then three years of quarter-by-quarter Plan/Deprecate/Migrate/Use/Remove with risk estimation. Bottom-up generation from engineers who know the problem space.
[20220306] Stop Paying Down Technical Debt, Start Maintaining Code — Stop paying down tech debt and start actual software maintenance. That’s the real term we should all be talking about.
[20220303] What is Developer Productivity and How to Measure It? – SPACE framework = Satisfaction, Productivity, Activity, Communication & collaboration, Efficiency & flow.
[20220225] QRF — quick reaction force, aka “the team that it’s okay to interrupt”.
[20220225] Managing People — your job is not to manage people, but to manage processes and lead people.
[20220225] Technical Product Managers — what do they do at different companies and stages, how does the role sit vs project manager or product manager. The TPM owns the ‘when?’ and ‘who?’ questions. The PM owns the ‘why?’ and ‘what?’ The EM and the engineering team own the ‘how?’
[20220225] Desperation-Induced Focus – a nice piece against process. Big companies suck. At some point they were just like you. A startup fighting for product market fit or creating predictability in go-to-market or expanding geographically or something else that actually matters. They were focused. Focused on hiring trajectory-changing people and giving them more responsibility than they knew what to do with. They were working their a**es off to create something out of nothing. They had desperation-induced focus. But now they are different. Most big companies aren’t focused on creating things out of nothing. Someone else made the magic money-making machine, and they assume that it will just keep working. With the one thing that actually matters taken care of, they care about luxuries like making sure as high a percentage of the company as possible feels included in the planning process. Or creating performance review frameworks with an ever-increasing number of boxes and categories. Or something else that matters even less than that. This lack of focus is a luxury and a disease.
[20220224] Failed Squad Goals – post-mortem on Spotify’s famous but failed “agile at scale” model.
[20220219] Making Room for New Things — interesting breakdown of work. “Reactive fixes, heroics, adhoc work, silver bullets, and chasing the latest “great idea”. This work can be especially draining!” And a good point that we can end up doing low-value things on autopilot.
[20220218] Game Project Anti-Patterns – based on 600 post-mortems.
[20220217] Delegation — plot on urgent/important and do urgent+important, delegate urgent+!important, schedule or delegate important+!urgent, ignore !important+!urgent.
[20220217] Charity Majors on Careers — Most of us hate feeling like beginners. We associate it with anxiety, with failure, with not being good enough. If you want to have a long, rich, rewarding career in tech, the best thing you can do is consciously retrain yourself to lean into curiosity and its discomfort.
[20220217] Starting with Nonviolent Communication — key points are
- When ____[observation], I feel ____[emotion] because I’m needing some ____[universal needs]. Would you be able to ____[request]?
- observe, don’t evaluate/judge (“when you are late returning my book” vs “when you are a thoughtless git”)
- emotions, not thoughts (“I feel sad” not “I feel like you’re a thoughtless git”). Go beyond “anger” to “shame” or “fear” or …
- universal needs, not strategies (don’t tell them what to do, tell them what you need: “I need transparency” vs “I need to be copied on every email”)
- requests, not demands. Make it specific, say what you want (not what you don’t want), and treat a “no” as an opportunity to find out what it will take to get to “yes”.
- appropriate consequences are those whose purpose is to protect your needs, not to punish the other person
[20220216] That Wild Story – designing a human process around pathological cases leads to processes that are themselves pathological.
[20220216] Technical Decision Making – the standard process (define problem and criteria for evaluating solutions; go wide to find possibles and evaluate them; make the decision).
[20220213] Reasons Not To Be A Manager — many good reasons, and I particularly liked “Your time doesn’t belong to you”..
[20220213] Before You Quit Your Job — six core needs from work: BICEPS = Belonging, Improvement, Choice, Equality, Predictability, Significance. Which needs does your job fulfil, and where are your gaps?
[20220213] Onboarding — a summary of where I’m heading
[20220208] Never interrupt a programmer – cartoon.
[20220208] Four Hour Work Week – 100/80/100 (100% of the work, 80% of the time, 100% of the pay) means squeezing out breathing time, chit-chat, and so on. And customers still call on Friday. I think we do it right – if you want to work four days, work four days and be paid for four days.
[20220207] Managing People — There is no point being angry at your team – ever. You are in charge of processes and people. And you got more information than they do, always. You either created the processes where this outcome happened or you hired (or did not fire) the wrong people. Ultimately everything is your fault
[20220206] Feedback Conversations — Strategy = Anything that contributes to potential behavior change. Self expression = Everything else you should not say. Feedback is about Strategy. Self-expression is why most feedback conversations fail. Mentally forgive the person, Identify what will motivate them to change, Say only the 10% that will actually change behavior.
[20220206] A Better Way to Do Self-Evaluation and Give Feedback
- STAR: Situation, Task, Action, and Result
- SBID: Situation, Behaviour, Impact, and Desired outcome
- INDL – Impact, Numbers, Descriptions, and Links.
[20220203] Hacks for Engineering Estimates – estimate/target/commitment/plan; establish extremes; note the precision; ask for confidence levels over time.
[20220203] Mistakes First-Time Leaders Make – 👀
[20220202] What happens when colleagues know each other’s salaries – pay gaps close, and it becomes disconnected from performance.
[20220131] How to Mentor Software Engineers — more than code review.
[20220131] Software Engineering Culture Questions — lots of ways to assess different aspects of a team’s culture.
[20220131] How to Write a Strategy That Anyone Can Remember — “even over” statements. I’m a fan of the opposite: two metrics at once, one you want to maximise and one you don’t want to hurt.
[20220130] Prioritization, Multiple Streams, and On Call — advocates for what we call Support Supporter as rotating role
[20220128] How to Decide When It’s Time to Stop Designing and Start Coding – heuristics
- There are enough known unknowns (“if you have something you can ship with low risk, do it”)
- There are no more known unknowns
- There are far too many known unknowns (prototype to focus effort)
- You stop learning new things (discussing same point over and over)
- Falling down the rabbit hole (things start getting too complicated and abstract / imaginary problems).
[20220128] How to Beat Burnout – things you can do for yourself. (Not replacing structural changes to work)
[20220201] How to respond when someone leaves (a subtweet)
[20220201] Stop Being the Hero (practical -> emotional -> narrative; ppl want to be the hero)
[20220201] Death to Tribal Knowledge – good list of dev things to document
[20220201] Manager’s guide to holding people to account
[20220201] Heuristics (a credo)
[20220201] Avoiding technical bankruptcy (technical debt = symptom of flawed dev mgmt)
[20220201] Technical design review process
[20220201] Example of a technical design review document
Then, rather than allowing everyone to comment directly on the document, create a blank Google doc where everyone lists their questions about the design alongside their name. This will serve as the agenda for the upcoming design review.
[20220201] Common management failures in developing ICs
- Doing all the technical design work yourself
- Doing all the project management yourself
- Neglecting to give feedback
- Hoarding information
- Focusing too much on your personal output
[20220201] Productivity Text File
[20220201] Bets, Success Metrics, and Roadmapping
[20220201] Lessons from my PhD
- Lead or be lead
- Outline with topic sentences
- Get excited
- Unmotivated details
- Slide vs Speaker-led presentations
- Managers are Input/Output machines (get feedback)
[20220201] Planning sessions
[20220201] Incident Review Best Practices
[20220201] “Incidents are Unplanned Investments”
[20220201] Types of Waste in Software Projects (paper)
[20220201] Software Development as a Wicked Problem – good description of wicked problems
[20220201] http://en.wikipedia.org/wiki/Situational_leadership_theory
[20220201] http://wimvdd.blogspot.com/2007/05/what-is-situational-leadership.html
- Competence vs. Commitment Matrix gives you a quick and easy view and clear understanding of four basic types of leaderships.
- The 4 types of leadership has been defined by Hersey and Blanchard which they named S1 to S4:
- S1: Telling – one-way communication. Leader defines the roles of the individual or group and provides the what, how, why,when, and where to do the task
- S2: Selling – two-way communication. Leader is still providing the direction and providing the socioemotional support that will allow the individual or group being influenced to buy into the process.
- S3: Participating – shared decision making about aspects of how the task is accomplished. Leader is providing less task behaviors while maintaining high relationship behavior.
- S4: Delegating – the leader is still involved in decisions; however, the process and responsibility has been passed to the individual or group. The leader stays involved to monitor progress.
- The Situational Leadership Theory:
- developed by Paul Hersey, professor and author of the book “Situational Leader” and Ken Blanchard, leadership guru and author of “The One Minute Manager”
- introduced in 1st edition of “Management of Organizational Behavior” as “Life Cycle Theory of Leadership”
- renamed to “Situational Leadership theory” in mid 1970s.
| DEVELOPMENT LEVEL | APPROPRIATE SUPERVISORY STYLE |
| D1 Low CompetenceHigh Commitment | S1DIRECTINGStructure, control (telling people what to do, how to do it, where to do it) and supervision of performance |
| D2Some CompetenceLow Commitment | S2COACHINGDirect and Support |
| D3High CompetenceVariable Commitment | S3SUPPORTINGPraise, Listen, Encourage, Facilitate involvement in problem solving and decision making |
| D4High CompetenceHigh Commitment | S4DELEGATINGTurn over responsibility for day-to-day decision making |
* Competence (encompasses education, training, experience, etc)
* Commitment (combination of confidence and motivation)
[20220201] Structural lessons in engineering management (IC vs mgmt isn’t clean-cut)
[20220201] Doing too much work before looping in others
- Encourage engineers to show their work as quickly as possible, never > 1w without showing something.
- Can show a design doc, PRD, prototype, anything that enables meaningful feedback.
- If an engineer is unclear on a first deliverable, help them with what and when.
- Encourage engineers to get end-to-end deliverables asap.
- Develop behind feature flags so features can be checked in incrementally.
- Demo repeatedly as the feature gets fleshed out.
- Encourage everyone to give constructive feedback, and beware overly negative or toxic feedback.
[20220201] How to Improve Time Management
- Planning Fallacy: tendency to underestimate the time required to finish a task or overestimate our ability to complete it within a set amount of time. This fallacy is partly due to reliance on overly optimistic performance scenarios without the help of reliable data.
- if a task is overly complex and contains multiple steps, the chances that one of them will hit a snag and impact your timeline will increase. Even worse, if you aren’t tracking your time consistently and flagging the issues quickly, minor delays can add up to a substantial impact.
- It feels good to check an item off a todo list so we can be trapped into chasing menial wins.
- The pain of doing the work is more than the pain of delaying it.
- Responsiveness and Throughput are rivalrous because being interrupted increases your WIP (and you pay a context-switching price)
- The Zeigarnik Effect states that we’re more likely to remember incomplete or interrupted tasks than finished ones.
[20220201] 7 Productivity Methods
- Tackle biggest and most important first.
- Time blocking.
- Pomodoro.
- Schedule to your biological energy levels.
- Zen To Done (ZTD) has 10 “habits” you pick and choose from:
- Collect: Write down ideas, tasks, and thoughts as they come to you to get them out of your head and onto paper.
- Process: Make decisions and answer emails quickly, so that it doesn’t pile up, procrastinating for later.
- Plan: Write down your biggest must-do’s for the week, schedule them out, and do them first every day.
- Do: Focus on one task at a time—turn off your phone and don’t check emails or task switch until a set time or it’s done.
- Simple Trusted System: Keep simple lists, check tasks off as you go, and stick to your daily lists.
- Organize: Declutter and organize your space, your inbox, and your mind—that means dealing with action items as they arise and deleting the rest.
- Review: Do a weekly review of your goals and your progress, adjusting your systems and objectives accordingly.
- Simplify: Reduce your tasks and goals down to the bare essentials and focus on them.
- Routine: Set and keep a daily routine that gives you time to be focused and productive and recharge.
- Passion: Seek work that you’re passionate about or love and notice how little you procrastinate (and how happy you are).
- Don’t break the chain
- Commitment Inventory
- List: Write down a complete list of how you spend your time (including chores, family time, meetings, exercise, and task breakdown).
- Combine and categorize: Narrow the list down into categories and assign a percent of time spent on each. Visual pie charts are helpful here!
- Review: Ensure that important commitments have enough time to do it well, cut the rest, and adjust your totals to equal 100%.
- Schedule: According to how much time you want (or need) to spend per category, schedule out your day.
- Checklists: Work in checklists, rather than to-do lists, because they are more granular, breaking down tasks into smaller parts with less resistance.
- Work in bursts: Focus on one thing for a set amount of time before switching to another, switching between work commitments and play.
You must be logged in to post a comment.