The key to being a good manager is keeping the people who hate me away from those who are still undecided.

Engineering management is the application of the practice of management to the practice of engineering.

Details!

• Located between engineering/software development and management
• Mostly counts for middle management
• Often staffed with engineers
• No more coding! No more coding?
• Lots of soft skills, less hard skills

You don't lead by hitting people over the head - that's assault, not leadership.

Possible activities

• Technical planning
• Resource planning
• Human resources
• People ops
• Interfacing development and management

Confusion of ideas

• Project manager
  1 team, focus: resources
• Team lead/lead developer
  1 team, focus: technical mentoring
• Engineering manager
  multiple teams, focus: people ops, mentoring
• Head of/director/vice president
  multiple/all teams, focus: organisation

A picture is worth 1000 words!

Project manager

Project managers have the responsibility of the planning, procurement and execution of a project, in any undertaking that has a defined scope, defined start and a defined finish.

Team Lead / Lead Developer

A lead programmer […] is responsible for the underlying architecture for the software program, as well as for overseeing the work being done by any other software engineers […]. A lead programmer will typically also act as a mentor for new or lower-level software developers or programmers, as well as for all the members on the development team.

Engineering Manager (example GitLab)

Managers in the engineering department at GitLab see the team as their product. While they are technically credible and know the details of what developers work on, their time is spent hiring a world-class team and putting them in the best position to succeed. They own the delivery of product commitments and are always looking to improve productivity. They must also coordinate across departments to accomplish collaborative goals.

Head of/Director/Vice President

"When I grow up, I want to be a reproach", said the expectation.

Explanation

• Everybody has expectations
• There are at least two variants:
  • Explicit expectations
    contracts, company handbook
  • Implicit expectations
    what is 'common'
• Consequences when failing to fulfil

Manager ↔ Company

• Manager → Company
  • Compensation
  • Information
  • Work environment
  • Freedom of decision
• Manager ← Company
  • Fulfilment of tasks
  • Reporting
  • Entrepreneurial thinking

Team ↔ Manager

• Team → Manager
  • Information
  • Guidance
  • Mentoring
• Team ← Manager
  • Fulfilment of tasks
  • Information

Consequences when failing to fulfil

• Tensions
• Open disputes
• High employee turnover
• Terminations

How to avoid

• Implicit zu explicit:
  • Codification
    handbook, wiki, videos
  • When starting: onboarding!
• Communication
  • Periodical meetings
    1:1, team meetings
  • Fast feedback
  • Workshops on expectations

Software is the invisible writing that whispers the stories of possibility to our hardware.

Soft? Hard?

• Distinction is more or less arbitrary
• Communication is foundation of all skills
• Sarcasm is a sign that coworkers are not used to express negative feedback in a constructive fashion

Work environment

• Move fast intelligently, fail fast intelligently
• Emotional security
  
  • It's save to make errors
  • Try to lower stress
    stress induces errors
  • Competition inside the team is harmful
  • Don't work in "survival mode" (cf. empathy)

Stress and pressure

• "Work hard, play hard"
  Bullshit!
• Respect the flow:
  • Mihály Csíkszentmihályi
  • No interruptions outside the breaks
  • Plan meetings at the edges of working hours or around lunch break!

Organisation

• Processes can ease work, but only if they don't prevent thinking
• In software teams "process" is the sum of all communication about work and progress
• When official processes don't work: don't hide your working process

Team culture

• All successful teams in organizations have their own culture
• Large organizations can not adapt this culture company-wide (or don't want to)
• All they copy are less important things like processes

Empathy

• Task: find and releave pain points
• Important: Values! Make money while respecting your values, not despite of them
• Glorification/reframing psychological and social tensions as "war wounds" is harmful
  → software developers are not Klingons!
• In "survival mode" you can't see other people's pain ponts

Hard Skills as empathy

• Writing good, readable code is empathy with your future self and your team
• Teams only focussed on velocity will not have respect for empathy
• Empathy with old code: even code now seen as being bad has been written for a reason

Radical acceptance!

Everything happens for a reason, even if you can't understand it right now.
Step back from fighting what you don't like.
This leaves room for curiosity!
Curiosity leads to explanations.

Change management

• When you are part of the system you try to change, you also have to change yourself.
• Self organized / agile teams can only be successful, when they can effect changes in their environment.
• If change can not be accomplished:
  You have two choices: change the team or change the team (but first try to improve!)

Part 1

• GitLab Team Handbook:
  https://about.gitlab.com/handbook
• Michael Lopp, Rands in Repose:
  http://randsinrepose.com

Part 2 - special recommendation

Part 1

• Michael Lopp:
  "Managing Humans"
• J. Hank Rainwater:
  "Herding Cats: A Primer for Programmers Who Lead Programmers"
• Camille Fournier:
  "The Manager's Path"

Part 2

• Julia Evans:
  "Help! I have a manager!"
• Patrick Kua:
  "Talking with Tech Leads"
• Tom deMarco:
  "Slack - Getting past burnout, Busyworks and the myth of total efficiency"

Part 3

• Tom deMarco:
  "Peopleware - Productive projects and teams"
• Johanna Rothman, Ester Derby:
  "Behind Closed Doors - Secrets of Great Management"
• Brian W. Fitzpatrick, Ben Collins-Sussman:
  "Team Geek - A Software Developers Guide to Working with Others"

Part 4

• Chad Fowler:
  "The Passionate Programmer"
• John Z. Sonmez:
  "Soft Skills - The Software Developer's Life Manual"
• Sandy Mamoli, David Mole:
  "Creating Great Teams - How Self-Selection Lets People Excel"

Part 5

• Gene Kim, Kevin Behr, George Spafford:
  "The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win"
• Frederick P. Brooks:
  "The Mythical Man-Month. Essays on Software Engineering"

Part 6

• Lars Vollmer:
  "Wie sich Menschen organisieren, wenn ihnen keiner sagt, was sie tun sollen"
  (only available in german: "How people organize themselves when no one tells them what to do")

Part 1

• Camille Fournier - Rebooting Culture
  https://vimeo.com/173328699
• Camille Fournier - Cloning yourself is not an option
  https://vimeo.com/139907569
• Coraline Ada Ehmke - Diversity in OSS
  https://vimeo.com/176695449

Part 2

• Patrick Kua - What I wish I knew as a first time Tech Lead
  https://www.youtube.com/watch?v=CjgWwmBW-bc
• Patrick Kua - The Constant Life of a Tech Lead
  https://www.youtube.com/watch?v=9jd_vpcLK50
• Patrick Kua - Geek's Guide to Leading Teams
  https://www.youtube.com/watch?v=a_IYL_aU7HQ

Part 3

• Laura Paterson & Patrick Kua - Technical Leadership
  https://www.youtube.com/watch?v=k_nti-mk5IY
• Camille Fournier - Building and Motivating Engineering Teams
  https://www.youtube.com/watch?v=7R-Y2DwWOr0
• Dave Thomas - Agile is Dead
  https://www.youtube.com/watch?v=a-BOSpxYJ9M

Part 4

• Patrick Kua - Why Technical Leadership Matters
  https://www.youtube.com/watch?v=_6BKK1SPAVI