Organizational Structures

Career Frameworks

Link	Notes
Gergely Orosz What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not	Silicon Valley companies consistently "get" a few things that their traditional counterparts fail to either understand or implement in practice
Security Ladders	Open source security career ladders: a collection of documents to categorize the knowledge and experience expected of security experts at a given point during their careers
Engineering levels at Carta	Carta's engineering leveling guide
Dropbox Engineering Career Framework

Team Logistics

Creating and Running Teams

Link	Notes
Startup Engineering Team Organisation	Technical Teams Squads Chapters Dedicated Core Team One Shot Projects Staff Engineers + Chapter Work
Starting Software Teams: Avoiding Big Mistakes	Give teams clear missions that aren't grab bags, and make sure they have an engineering anchor and enough people to keep going in the face of inevitable challenges
Split Your Overwhelmed Teams	Two teams of five is not the same as one team of ten If your team is suffering from low morale and high stress, look at the cognitive load on the team, review its sources, and look for substantive changes that will have the desired impact The solution might not be splitting the team, but that could be exactly what is needed
Independence, autonomy, and too many small teams	The mission is diluted because most of the teams are now working on problems which are subsets of the original problem and as such not valuable in themselves Where a single team could have come together to solve problems of data delivery, now multiple teams with different managers and different roadmaps must come together to deliver anything to the customer A team is autonomous when it "delivers value to the customer" independently
How product engineering teams avoid dependencies -- the independent executor model	It is natural to need things from other teams. It can be tempting to wait for them or depend on them to provide something for you. This happens because they own the area you need to do work in This is an organizational trap. It leads to pain and misery
Would you like architects with your architecture?	Four archetypes: 🌕 Architect decides, team executes 🟢 Architect in the team 🟢 Architecture done by team members 🔴 "Implicit" architecture
Bottleneck Dirty Webs	Delegation, specialization, and federation are critical to scaling companies. But scaling doesn’t mean stepping back from everything. Especially for unsavory, cross-functional, time intensive tasks, leaders should position themselves as bottlenecks - owners that feel pressure when the work grows too much, forcing them to find ways to push back on the growth in time and effort
Synchronous Work, Asynchronous Work	We often talk about teams working "remote" or "in office", but leaving the discussion at that level misses some critical points of analysis--namely, that the real distinction is between "synchronous" and "asynchronous" work

Project Management & Planning

Link	Notes
Limiting Work In Progress	We can improve the output of a team or an organization by limiting work in progress
The work is never just “the work”	A deep dive on why projects always take longer and a framework to improve future estimation
Efficiency is the Enemy	There's a good chance most of the problems in your life and work come down to insufficient slack. Here's how slack works and why you need more of it
Software Development Waste	A taxonomy for any team that's trying to figure out how to be more efficient
Plan on a Page Checklist	A brief mission statement and vision for your team Short diagnosis statement Two single-sentence focus statements in the 3m and 12m time ranges A list of the key “workstreams” A suitably detailed 12-month initiative roadmap Upcoming key milestones Key dependencies and partners A list of non-goals A list of key assumptions A list of key risks you are managing
How to Make the Case for Slowing Down to Speed Up	Value-Driven Focus Leverage Blocked Work Figure Out Your Accountability Game Test Assumptions Identify the Wedge Pitch the Approach (and the Wedge) Smarter Trade-offs Visibility on Main Roadmap Pragmatic Solutions Put your pride to the side
Futility of Shortening Iterations	Shorter Feedback Cycles, Not Iterations
Inputs First. Bets Next	Instead of starting with a roadmap and tacking on measures, start with powerful ideas and a model Then target your work to influence parts of the model Rinse and repeat
How To Do Less	Make and broadcast cuts Handling Initial Disappointment Say No, early and often This isn't MAIN_PRIORITY, so we aren't going to do it until at least ESTIMATED_DONE_DATE Right now our priority is MAIN_PRIORITY because of ONE_SENTENCE_JUSTIFICATION, and this is 100% our shipping focus I agree this sounds like a really useful feature - once we finish MAIN_PRIORITY, should we consider dropping SECOND_PRIORITY and do it? How to correct distractions This isn't MAIN_PRIORITY, that we all said we're going to work on What if we don't do this? What can we do without it? Is this a requirement or a nice to have? Will it speed up MAIN_PRIORITY? Can we put this onto our (New Feature/Maintenance) Roadmap after our current priority finishes? I think we can finish MAIN_PRIORITY without this You have to finish work
How to Build Engineering Strategy	Tools and techniques to help you build a long-term engineering strategy
Team OKRs in Action	Common Pitfalls of OKRs in Practice

Meetings

Link	Notes
How to Troubleshoot Status Updates and Syncs	Some roadblocks to look out for
The work-centric standup	The problems with the people-centric standups, and how to replace them with work-centric ones
Why We Don't Do Daily Stand-Ups at Supersede	Daily stand-ups are not only a waste of time and make software development more expensive, but they demoralise developers

Company Culture

Link	Notes
The Pragmatic Engineer's Developer Culture Test	3 areas with 5 questions each for a healthy organization, where developers thrive
Avoiding Worry Driven Development	Necessary work avoided becomes a haunted forest in the codebase
The Detriments of Hero Culture	The recognition and celebration of work done in the face of ongoing disaster, and the ignorance or disinterest in work done that would prevent it from happening in the first place
Building a Healthy On-Call Culture	Companies that respect their engineers institute policies that enable those engineers to do their best work. Engineers who respect each other help each other succeed, and in turn, help the company succeed. This applies to on-call rotations as well as the wider engineering culture
Brilliant Jerks	Brilliant jerks are not brilliant, they are just jerks
Typical First Years of Startup Engineering Leadership	The different steps a decently successful, pretty typical, VC backed startup goes through until its Series A

Other

Link	Notes
CISO - Set expectations	To fix anything sustainably requires long term action
"I Wouldn'T Start From Here". How To Make A Big Technical Change	So much of the time, we have a vision for where we’d like our technology to be, but it sure would be nice to not start from where we are