Jessica Joy Kerr Profile picture
Oct 26 27 tweets 11 min read
In which @mipsytipsy speaks up about the Engineer<->Manager Pendulum

#QConSF Image
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.

@mipsytipsy #QConSF
And each of us deserves a long, interesting career.

Trick: don’t self-identify as a manager OR as engineer.

Look at yourself as a Technologist
Or Technical Leader
… who needs engineering AND management skills.

@mipsytipsy #QConSF
The best line managers have written serious code within 5 years or so.
The best tech leads and staff engineers have spent time as people managers.

Being a manager helps you get better at wielding influence without authority.

@mipsytipsy #QConSF
You can’t get better at being an engineer and at being a manager at the same time.

Engineers need focus time; management is all about interruptions.

@mipsytipsy #QConSF
Don’t let anyone make you a manager before you’re an experienced senior engineer.
You need 7-10 years as an engineer first.

You don’t need to be the BEST engineer; you do need to develop judgement and perspective.
Try management for at least 2 years
But fewer than 5.

Swing back before you become unhirable as an engineer.

You get worse as engineering manager as your tech skills deteriorate.

@mipsytipsy #QConSF
Management skills are stickier than engineering skills (they last longer)
But even more localized (particular to a company).
As a manager, stop writing code _in the critical path_.

Do contribute in small, supportive ways.
Fix some low-priority bugs.
Be the on-call backup of first resort.

@mipsytipsy #QConSF
In software:

Management is organizational leadership with technical aspects.
Engineering is technical leadership with an organizational aspect.

There’s a lot of overlap, so moving between them is useful.

@mipsytipsy #QConSF
As a senior manager… swing back to engineering, or move toward director or VP?

Everybody starts out thinking they want to climb the ladder.

Until they do the job of management ;-)
The role-based power of management, it’s a weak power: you don’t take it with you.
Technical and personal influence, that’s about you, not the title.
When management is not a promotion (it’s a change of career)
then engineering is not a demotion.

Choose the job that brings you joy, not status.

@mipsytipsy #QConSF
Career advancement is about luck and opportunism.

For success:
Lean into the opportunities that cross your path,
don’t get your heart set on a particular outcome.

@mipsytipsy #QConSF
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.”

@mipsytipsy #QConSF
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

@mipsytipsy
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.

@mipsytipsy
Management != Leadership

Tech leadership matters just as much!

alternating between them gets you better management _and_ better technical execution.

@mipsytipsy #QConSF
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.

@mipsytipsy #QConSF
If you go into management to know what’s going on and have influence,
Ok… but do you perpetuate that reason? Do you hoard knowledge?
That part is bad.

@mipsytipsy #QConSF
Command-and-control is toxic to creative flourishing.

@mipsytipsy #QConSF
a healthy hierarchy takes transparency seriously.

Don’t build a system where people have to be a manager to be a loop or have a seat at the table.

@mipsytipsy #QConSF
Management is overhead. It is a support function.
Your company exists because of the contributors.
Visualize your hierarchy upside-down.

@mipsytipsy #QConSF
Only you get to say what success looks like for you.

It doesn’t look the same at the beginning, middle, end of our careers.

Don’t have a goal; do have a direction. Go in a direction that stimulates you and makes you happy.

@mipsytipsy #QConSF

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Jessica Joy Kerr

Jessica Joy Kerr Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @jessitron

Oct 27
Software is magic because it scales so well.
I can take the output of my brain and scale it to the world.

@KentBeck
If we go from Idea to Behavior change to new Idea…
how quickly we can do that depends on the structure.
@KentBeck Image
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 Image
Read 14 tweets
Oct 26
SRE teams try to keep toil under 50%.

Only 50% of work that has no enduring value...

@DivineOps #QConSF Image
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

@DivineOps #QConSF
Read 19 tweets
Oct 25
How to build reliable systems under unpredictable conditions

@MrBWilms is excited to be at #QConSF :-) Image
Normal testing is happy-path testing.

@MrBWilms #QConSf
Reliable: consistently good in quality or performance.
Reliable: able to be trusted.

@MrBWilms #QConSF

Note that he doesn’t say “perfect.” Good isn’t perfect, but it can be _real_.
And trust is not assuming perfection.
Read 15 tweets
Jul 19
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
Read 22 tweets
Jul 18
The cycle of no-improvement:
Bad estimates? get better at estimates!
Unclear requirements? get better at requirements!

Most things we deal with as problems are not actual problems.
They’re indications of problems. @WoodyZuill #Agile2022 ImageImageImage
If you can’t solve the problem, maybe you can overwhelm it.
Focus on what’s good. Make that bigger! ImageImageImage
the pictures are worth it alone. Andrea Zuill’s pictures are the best ImageImage
Read 4 tweets
Jul 10
A ten-principle checklist for socio-technical design

by Albert Cherns, quoted by Jackson in Critical Systems Thinking

paraphrased by me, with commentary for software teams 🧵
Compatibility
the process of design is compatible with its objectives. Want democracy? use participative design.

The means match the ends.
You don't get autonomous teams by specifying Scrum.
Minimal Critical Specification
of the who and how of carrying out the work, only the essentials are decided up-front.

Figure out the basics, and plan on figuring out more later, within the team. Keep detailed decisions near the work.
Read 11 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(