[…] walk us through a story where a new manager successfully performs every single common mistake in their new role. The New Manager Death Spiral is a cautionary tale full of good advice.

Meta

• You might also know @rands as the author of Managing Humans, Being Geek or randsinrepose.com
• Upon a quick raise of hands, he assesed the room to be ~60% full of introverts.
• His disclaimer: this hypothetical story is a worst case scenario.
• My disclaimer: following is a log of my personal notes; sometimes out of context, sometimes missunderstood.

The New Managers Death Spiral (or the insightful part)

Affirmation #1: "I can do it. I'm the Boss"

• You think you've been promoted!
• First, you sign-up for all the things.
  • Hey, it worked for you as an IC.
• You are instinctually reluctant to delegate to others.
  • Feels like giving away power.
• Your first failure mode
  • The quality of your work drops.

Affirmation #2: "I can do it all myself. I'm in control because I'm the Boss."

• The ineptitude of fake delegation.
  • Lacking context, goals etc.
  • "Go figure it out… or else."
  • Your job is to aggressively delegate.
  • You are not listening
    • So the team starts to talk amongst themselves.
    • You did not build trust.
    • Opinions become facts.
    • Poor communication
  • They think they have failed.
    • Irreparably harmed the relationship with your team.
    • "Hey Rob, your team is saying this thing about you."
    • And it hurts, it's toxic.

Affirmation #3: "This is not me."

• Teacup pigs. :o)
• Management is not a promotion.
• It's a totally different game/role.
• Management is career restart.

Lesson #1: Let others shape your thinking

• People disagree with you. That's great!
• Augment your obvious and non-obvious weakness with a diverse team.
• The first 30% of a project lifecycle.
  • "I surround myself with people that design […]"

Lesson #3: Delegate more than is comfortable.

• A vote of confidence in their ability.
• You build yourself by building others.
• Trust.
• The burden is on you to prove that you deserve.
• Start small.
• Am I building or am I erroding trust with this action that I'm about to take?

AMA (or the juicy part…)

• How do you identify early signs of "management" in engineers?

  • Empathy
  • Ability to read the room

• Managing up

  • The same rules apply
  • Clear communication
  • Constant communication
  • What do you worry about most as a compay grows? Politics.

• Biggest management mistake, in the last year?

  • I (Marius) chose to leave this out; if you're interested, ask @rands personally. ;o)

• Giving critical feedback

  • 1-1: every week, 30 minutes.
  • Feedback
    • You did this great,
    • This less great,
    • This is how I would do it.
  • Listen
    • Is this what you meant?
    • Paraphrase it.
    • Build trust.
  • Djoume: How can I be a better lead / manager for you?

• New managers, with friends on the team.

  • It's a difficult situation: void it, as much as possible.
  • Manager hat, friend hat.
  • "Speaking as your manager now […]"
  • Be deliberate about the role in the relationship.

• Managing up:

  • What makes for a "good" 1-1?
  • What are some quick wins on improving them?

• Key characteristics

  • Vision
    • Can you describe a compelling future?
  • Strategy
    • How are we getting there?
    • Can you build the roads and the roadsigns?
  • Tactics
    • Can you describe the growth path for all your direct reports?
    • Feedback for every 6 months
    • Judgement
    • Experience
  • Communication
    • Can you build the roadsigns
    • Can you read the roadsigns?

• Formal training is lacking. Where to get it?

  • External
    • Harrison Metal — Leadership training
  • How are we training the managers at Slack?
    • Internal talks
    • Mentorship circles

• Judgement

  • How do you interview for judgement?
  • How do you judge for judgement?
  • Look for a non-obvious judgement call, and the ability to explain it.
  • Can you walk me through your thinking?
  • Can you tell me why? Or was it just a coin flip?

• Self-management renders managers obsolete?

  • Holocracy?
    • Did it work at Zappos?
    • Did it work at Medium?
    • Managers are a force multiplication factor.
    • Information conduits.

• Coaching in a distributed team.

  • Biased towards face to face interactions
    • Lightspeed.
    • Read the room.
  • A lot of traveling.
  • Different cultures, being aware of that.
  • Remote people can be made to feel like second class citizens.

• Growth paths? It depends.

  • CEO
    • Move outside of engineering
    • Experience other facets of the business
  • VP engineering
    • People, process, etc.
  • CTO
    • Still coding
    • "Bringing the app back to life"
  • Chief Architect
    • Coding as well.
    • No direct reports?

• Failing…

  • …is where you can learn.
  • Managers fail just as much as everyone else.
  • Fail faster, feel safe.
  • "You screwed up, but I got you: we'll fix this."

• Delegation

  • Rework, book by Jason Fried
  • Do you triple down on their strengths?
  • Or delegate it to Julia who's going to get a B on this?
  • Try to work towards a growth mindset.

• Being able to read the room: how do I improve? A

  • A lot of introverts run companies…
  • Listen, get people to talk to you.
  • Conversation about how to get better.

• Quitting my job

  • Every 3 years.
  • The moment I get bored… deathly afraid of becoming irrelevant in this industry.

Disclaimer: Remember that you have been forewarned: this was just a log of my personal notes; sometimes out of context, sometimes missunderstood.

Now, if you've read this far, what are your thoughts?

We each get through our everyday TL lives with our own bag of best practices, life hacks and mindful habits. We’ve collected those from books, blogs, mentors, and our own hard-earned experience.

Now it’s time to share!

We’ve gathered a small panel of folks with team lead experience to share some of the strategies they use to do their very best TLing.

The Panel

In the order in which I was seeing them from my seat, the panel was composed of:

• Ofer Guttman - Director of Software Engineering, Points
• Luke Reeves - Developer Lead, Shopify
• Ash Christopher - Director of Engineering, Wave HQ
• Ania Halliop - Development Manager, Freshbooks
• Will Harford - Integrations Architect, Unata

The Topics

The original plan was to as many of the following topics as we could

• How do you give positive/negative feedback?
• How do you deal with inter-team conflict?
• How do you run your one-on-ones?
• How do you deal with a frustrated person who reports to you?
• How do you deal with complaints from people who report to you about your superiors/the company?
• How do you deal with complaints about people who report to you from others in the company?
• How do you help your reports plan their career growth?
• How do you manage high performers vs low performers?
• How do you onboard new employees?

In the light of what happened about week ago, I wished I knew how other people handled issues like that. So I joined the meetup, went, and I even took notes.

My notes

• Ash: Defensive versus heroic
• Ash: tactic versus strategy
• Will: People are not mathematical models. The sum of the inputs doesn't always equal the sum of the outputs.
• Ania: Trust — if you go in good faith, 99% of the people will match that. Similarly about respect.
• one-on-ones
  • This is their time, not yours: you put yourself out there, be there to help them, let them own the conversation.
  • Luke: Notebooks, no computers.
  • How are you? versus What's on your mind? Either as soon as you walked through the door, or since the beginning of the week.
  • What do you want to do in three years. blank
  • If you were to leave Freshbooks today, what would make you go?
  • Luke: There is no book, no Wikipedia page on what to do in one-on-ones.
  • Ania wrote an internal handbook in mentoring, one-on-ones etc.
• Performance
  • Luke: What is your impact? How do you make it broader?
  • Anonymous feedback: How is your manager doing?
  • Low hanging fruit.
    1. Be clear with your expectations.
    2. Document them. Easy to come back and keep track.
  • How do you define a performance metric?
• Paul: Experience working with someone with Asperger / autism
  • Very performant, maybe difficult to deal with socially.
  • In the majority of interviews, it's teamwork that is sought after.
  • Remote work? Not accepted in some companies.
  • Building rapport, safe to ask for help.
• Depression, social anxiety, mental health
  • Build a safe environment.
  • James W: employee assistance program (EAP).
• Ania: the Turn the ship around book
• Ash: Humility is a very heroic human trait

David Marquet's book, plus many of the topics that were touced, they all remind me of this article about creating not a sense of urgency, but fostering a sense of purpose instead.

These were my notes on Day to Day team leading practice. And yes, it’s time to share! Which practices managed to catch your attention?

1. There are no methods in Elixir—just functions:

   There are no objects in Elixir (nor methods). If they are about structs, then they should be referred to as structs (or generally as data) (and use "functions" instead of "methods").

   –José Valim

2. List comprehension

   • create a list based on existing lists
   • distinct from the use of map and filter functions

3. We played with Lists, let's learn about Tuples:

   • "like an array, where each index has a very special meaning"
   • the ordering / contract is in the developer's head!
   • can be seen as a key/value pair, where the key is the index

4. Pattern Matching

   • "Elixir's replacement for variable assignment"
   • Elixir, as a language governed by its design
   • = starts the pattern matching sequence
     • create a mirror structure on the left hand side
     • matches the data structure
     • matches the number of values / elements
   • enables you to avoid writing if statements
     • pattern matching in case statements
   • pattern matching can also be done directly in the argument list

5. The Elixir Ecosystem

   • Code we write »
     • fed into » Elixir »
     • transpiled into » Erlang »
     • compiled and executed on » BEAM
   • leveraging underlying Erlang modules:
     • :erlang.term_to_binary/1
     • :erlang.binary_to_term/1
     • :file.format_error/1 —thanks @pragdave
     • :egd —the erlang graphical drawer

6. Atoms

   • personally, I prefer the definition from Programming Elixir 1.3

   Atoms are constants that represent something’s name. […]
   
   An atom’s name is its value. Two atoms with the same name will always compare as being equal, even if they were created by different applications on two computers separated by an ocean.

7. Unused variables

   • Elixir provides a friendly warning at compile time
   • Solution: underscore them: _ or _reason

8. The Pipe operator

   • the key is to write functions that take consistent first arguments
     • the return of the previous function gets applied as the first argument in the subsequent function
   • Joe Armstrong's explanation of the pipe operator made the most sense for me:
     

   This is the recessive monadic gene of Prolog. The gene was dominant in Prolog, recessive in Erlang (son-of-prolog) but re-emerged in Elixir (son-of-son-of-prolog).

   x |> y* means call x then take the output of x and add it as an extra argument to y in the first argument position.

   So

   x(1,2) |> y(a,b,c) 
   

   Means

   newvar = x(1,2); 
   y(newvar,a,b,c);
   

9. Documentation

   • ExDoc
     • @moduledoc for module documentation
     • @doc for function documentation
     • mix docs to generate

10. Testing

    • first-class citizen: fully featured out of the box
    • mix test
    • Doctests
      • write docs and tests at the same time
      • examples in documentation stay up to date
      • Scenario: explain to another engineer the simplest case of using a given function
      • Additional assertions are possible, but you generally want to make only one assertion about the very last line: this is a documentation test about the contains?/2 function, and not about create_deck/0. So in practice we want to have just one, very small, very targeted assertion about the given function.
      • Ran by the doctest Cards line inside out test file
      • parse the module
      • run any examples as an actual test
    • Case Tests
      • What behaviour do we want to test?
      • assert versus refute
      • Elixir's functional programming style makes it so easy to test
      • create basic object, representing our working data
      • pass it off to the function we're testing
      • do some basic checks on the returned object

11. Maps

    • key-value stores, similar to Ruby hashes, or Javascript objects

        colours = %{primary: "red", secondary: "blue"}
      

    • accessing properties

      • dot notation
      • pattern matching

    • updating values

      • immutable data: to update means to create a new data structure with the modifications
      • two ways of achieving this:
      • with a function: Map.put/3, etc

      • leveraging the built in syntax —similar to Elm

        %{colours | primary: "green"}
        

        • only works for existing keys:

        the VM is aware that no new keys will be added to the struct, allowing the maps underneath to share their structure in memory.

12. Keyword Lists

    • List and Tuple merged into one
      • lists: like arrays, can be used for an arbitrary number of elements
      • tuples: like arrays, where each index has a special meaning to us
    • versus Map: there can be duplicate keys

    • a list that contains tuples

      colours = [{:primary, "red"}, {:secondary, "blue"}]
      # or
      colours = [primary: "red", secondary: "blue"]
      

13. Identicon Image Manipulation

    • describing the business logic
      • one root object / piece of data
      • gets passed around through a Main Pipeline
      • a series of small functions, that transform the data

14. Data Modeling

    • Struct
      • it's just a Map plus
      • compile-time checks
      • default values
      • Looks a lot like a Map; why would we use a Struct over a Map?
      • a Struct enforces that the only properties that can be stored are the ones defined in the module
      • a normal Map is happy to let you insert any different property that you'd like
      • Why not add functions (methods / properties / instance methods) to structs? From an FP perspective
      • it's a Map under the hood
      • has no ability to attach any functions to it
      • it can only hold some primitive data
      • A single location to store all the data inside of our app
      • The update syntax works best, as properties on a Struct are already defined
    • List
      • Acessing the first X values from an arbitrarily long list
      • the head and tail split pattern [h | t]
      • extended to [a, b, c | _tail]
    • Tuple
      • use a Tuple instead of a List when the index has particular semantic

15. First-class functions

    • in Elixir, referring to a function—mirror_row—it will call it by default
    • to pass a reference to a function, we use a special syntax
    • Elixir provides guidance even through its compile error

    […] invalid args for &, expected an expression in the format of &Mod.fun/arity, &local/arity or a capture containing at least one argument as &1

16. Anonymous Functions

    • we can't mix clauses that expect a different number of arguments. A function always has a fixed arity.
    • anonymous functions are closures, similar to lambdas in Ruby

17. A working Identicon program

    • the pipe operator
    • working with Erlang (egd)
    • Enum
    • anonymous functions

The second part will cover Phoenix. Back to the bootcamp now!