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