The team deserves someone
who wants to manage people.
who is not bitter about meetings
who is interested in sociotechnical systems and nurturing careers
whose technical skills are strong enough to evaluate their work.
Maximize your options in the future:
* keep your technical skills fresh (and your interview skills)
* Make friends: know people outside your work
* speak andwrite: people know you
* be T-shaped: googleable on one topic, hold conversations on many
and…
* change your role (if not your job) every 2-3 years
“I’ve got it all under control, that’s a terrible spot. You’re not growing.”
Choosing only management narrows your options:
* there are fewer job openings as you climb
* Your skill set is more local
* so job tenure lengthens; you can’t leave as easily
* your ability to succeed is dependent on the company
Execs be like: “What? Managers moving back to eng? Wasted investment!”
But it is not a loss! This is how you cultivate great eng leadership,
and retain top talent (plus institutional memory). Keep them in the zone of “still learning, it’s hard but I can do it”
The way you become an amazing engineer is by working around amazing engineers.
Demystify management:
Decompose it into constituent skills.
* Running a meeting <- a skill every contributor should have
* Planning
* Recruiting and hiring
* Interning (being responsible for others’ success)
(What else?)
Access to information about the business is not a privilege of management.
It’s a right for every contributor.
If we go from Idea to Behavior change to new Idea…
how quickly we can do that depends on the structure. @KentBeck
If we go Idea to Behavior to Idea to Behavior
as fast as we can,
it’s gonna get slower and slower and then the developers will get frustrated and leave and the new developers will be even slower…
So sometimes, we make a structure change before the behavior change. @KentBeck
SREs in the audience? (Dozens of hands)
Experienced SREs? (Like 2.5 hands)
We @RedHat used to ship products. Build a thing, package it, send to customers. Then it was their problem. Customer hires a consultant or figures it out.
Now we mostly ship services. Now it’s our headache, reliability and uptime etc. It’s different
We have known how to build software for a while now, and the question is,
Why don’t we? @bethcodes#Agile2022
I look at SAFe and I see us reinventing Taylorism from first principles. @bethcodes #Agile2022
The alternative typically presented is structurelessness.
Let every team do exactly what it wants, whoever keeps doing it longer without getting fired wins the argument.
People don’t feel safe without structure. @bethcodes