Skip to content

Organizational Structures

Career Frameworks

Link Notes
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
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

Team Logistics / Culture

Link Notes
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
Limiting Work In Progress We can improve the output of a team or an organization by limiting work in progress
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
The Pragmatic Engineer's Developer Culture Test 3 areas with 5 questions each for a healthy organization, where developers thrive
CISO - Set expectations To fix anything sustainably requires long term action
Avoiding Worry Driven Development Necessary work avoided becomes a haunted forest in the codebase
Will Larson The rush to "show value." Setting clear expectations and establishing quick feedback loops to support new leaders
"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
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
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
Short Term Focus Can Be A Distraction Long-term initiatives may take years to show profitable results, and in the short term they can create drag
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
The flying wedge Most folks who operate this pattern have adopted a closed mindset about the industry's talent, but hiring from outside your existing network is not only a great way to find strong candidates, it's also a powerful way to advance your long-term career
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
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
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