shuchita

Random soliloquies of a faineant.

[claire vo 🖤 @clairevo]

Almost everything about growing the size and scale of your team has immediate and detrimental impacts to the thing that matters the most: building awesome products.

Unless you actively fight against these effects, you’ll wake up one day with a very effective bureaucracy machine and a very poor product (and a slow moving product delivery machine.)

What are some of the worst offenses?

MEETINGS
- steal builder time
- incubate consensus cultures
- slow cycles (“let’s follow up next week”)
- 1:1s silo decisions
- bias teams to value presentation & argument over delivery & outcomes

PROCESS
- slows cycles (follow the gates)
- diffuses ownership
- creates overspecialization (and it’s partner, over- hiring)
- abstracts away decision making
- errs to complexity vs simplicity

POLICY
(I mean this generally, across everything from HR, finance, security, IT, etc.)
- encourages risk aversion
- keeps teams from exercising risk-adjusted judgement
- slows cycles (blocks & reviews)
- dampens innovation & the art of the possible
- can hurt top talent retention (too structured comp/review cycles)
- can make your hiring process slow and less competitive
- makes experimentation too hard

OPERATING
- people start to play for promotions, not company growth
- talk more about the how of the work, vs the what and why if the work
- leaders lose track of the details
- teams lose track of the bigger picture
- customers become data points and % rates, not real people with real problems

All of these things: meetings, process, policy and operating models are necessary for high scale and trusted delivery AND YET teams that forget to actively and aggressively prune the worst effects of these things out of their company will soon regret it.

Watch out for these effects. Immediately intervene. Don’t reward these behaviors explicitly (promos/levels) or implicitly (culture.) Be ruthless. Try things that feel a little bananas (cancel all the meetings! yolo into prod every now and then!) Show AND tell.

Stay a startup.

Stay an owner.

[Shreyas Doshi @shreyas]

Mission conveys Why it is worthwhile

Vision conveys What the world will look like

Segmentation conveys Who you will serve/not serve

Strategy conveys How you’ll differentiate to win

Roadmap conveys When you’ll ship the big stuff

Metrics convey How Much progress you are making

[Charity Majors @mipsytipsy]

Maybe something like @jeli_io that gathers and stores information about incidents and outages, and how people respond to them.

Anyone have other tips for how devs can support production?

[Alex Cohen @anothercohen]

Every company is a mess internally, you just need to decide which people you enjoy working on the mess with

[Packy McCormick @packyM]

What's your favorite essay/blog post of all time?

Looking for >2 years old, and that you think will be as good in a decade. Instant classics.

[Ray Stings @Purba_Ray]

Kids in their 20s claiming mentally and physically they feel like they are in their 50s have no idea that most 50 year olds still feel like they are in their 20s.

[@norootcause.surfingcomplexity.com on Bluesky @norootcause]

Develop a deeper understanding of a system that you now work on but didn't build. 27/

[@norootcause.surfingcomplexity.com on Bluesky @norootcause]

Advocate for reliability-related work, since it will never be driven by customer asks (although they will be upset if the service goes down). 13/

[George Pointon @GeorgePointon_]

I asked a group of 6 year olds 'What's the most important thing in the world'
Here is my analysis
A THREAD

[Charity Majors @mipsytipsy]

you need to be looking at your code in production every day even if it's *not* paging you constantly. exploring production is an important part of understanding if your code is doing what you expected it to.

it's not just about the bugs and the outages and the downtime,

[Erica Van Houten @epvh]

@fullstacktester @mipsytipsy The automated tests are there to catch the disasters that we could imagine or managed to encounter and characterize after the fact. Auto tests are just telling you it’s not *too* broken.

[Gergely Orosz @GergelyOrosz]

The "traffic cop" engineering manager via
@johncutlefish:

"If you're the only one talking with the product manager, then allocate tasks and tickets to your engineers: get out of this business. You're not developing engineers. Your engineers are getting learned helplessness."

[I Am Devloper @iamdevloper]

“you look tired” thanks i stayed up all night obsessing over fixing a bug in my head

[shuchita @sdm___12]

“Math is not thinking. Math is procedure. Memory is not thinking. Memory is storage. Thinking is thinking. Problem, solution." -> from Project Hail Mary

[Gergely Orosz @GergelyOrosz]

4. The largest challenges both for staff engineers and eng managers are the same: people. Except staff engineers have no authority to wield: they need to influence.

5. Leading a large project like this is like herding cats. People, misunderstandings etc cause the most pain.

[Ellie Schaffer @EllieOnSoftware]

Instead of "we work hard," I would love to see "we learn how to do awesome things together"

[shuchita @sdm___12]

@evolvable Lodgement reference = pay me now

[shuchita @sdm___12]

@evolvable I still use that pattern when generating test data for my payment services ☺️ and BSB is usually 969800