Engineering Manager Reading List #1

Everything Engineering Management

Performance Management / Feedback / Career Development

• Career Development at Etsy -
  How Etsy developed an Engineering specific career ladder to be more specific with expectations, support meaningful career growth, recognize the variety of valid paths, limit the room for biases … (Result is here)
• Disrupting bias in feedback -
  One of the best things we can do for our unconscious biases is to identify them by name so that we might disrupt them. Lots of typical patterns and how to disrupt them. Would I give this same feedback to someone of a different gender (or race, etc)? Am I asking someone to be something they are not? Have I made a statement about who someone is or who they tend to be? What feedback should I be giving others, too?
• Software Engineering Promotions —
  A process to manage your career from an ICs perspective. Quite good to coach employees towards career ownership.
• A forty year career — In tech startups there is no 40-year career anymore. We hop from job to job, looking out for the next IPO and see early financial independence as the ultimate goal. The author reflects on this perspective. What would happen when you measure your work not in IPOs but in decades? “As you invest into your pace, the people you know, the prestige you build, the profits to fuel financial security, and your deep and broad learning, something magical starts to happen: each of these makes the others easier. This to me is the joy of a forty year career: things that seem hard early on become easy a decade in, and I can only imagine what it will look like two or three decades.”
• A review process —
  A nice description for how the performance and development review process works at BuzzFeed Tech.
• Building careers with empathy (Video) —
  In this month’s episode, Steve Carroll, the director of development for the .NET team, interviews Scott Hanselman the Community Program Manager Lead for the .NET team about his career. Scott is a big believer in using the power of empathy and in this conversation he uses that power across the various skills necessary to be a successful programmer and program manager.

Organizational Leadership / Scaling Organizations / Agile

• Scaling organizational empathy —
  Abstraction (distance between people and teams within org structure) kills execution and empathy. Empathy is within a managers domain. Managers need to maintain connections. It is all about seeing the human beings and not just the work. Talk about strategy and goals again and again and again …. Hire for character over competence.
• Whats wrong with best practices? —
  The term “Best Practice” became popular from 1910 to 1930 during Taylorism. But since the 90s it skyrocket and is still around. However, it is used to mask uncertainty and anxiety. But the world is to complex to try to solve problems using the same approaches from the past. Quite a nice piece about complexity, context and general leadership.
• The yogaable index (Fun) —
  !!!
• Cultivating Highperforming Teams in Hypergrowth (Video) —
  A must view from Patrik Kua about scaling teams.
• The flavours of agile —
  A nice overview about different Agile flavours: Scrum, XP, FDD, ASD, DSDM, Crystal, LSD, Kanban, Scumban, SAFe, LeSS, Scrum@Scale, Nexus, DAD, Modern Agile, Heart of Agile … Every EM should know about those!

(Engineering) Management Practices

• Skip Level meetings — What are they and how to run them. If you’re a manager of managers, skip level meetings are your lifeline. A skip level meeting is a meeting where you, as a manager, meet one-on-one with the direct report of a manager who you manage. Purpose: get out of your good news cocoon. The employees are reporting to your managers — not to you. They should be meeting most frequently with their managers and not with you. In SLMs: No decisions, no problem solving, no escalation, no refute,
• Essential Meetings to have with your people — Quite some good advice on 1:1 meetings, skip level meetings, career conversations, goal reviews, performance reviews.
• Mentoring Developers — Best practices from Uber —
  Some useful advice for how to mentor developers, from directing, to guiding and coaching. Think about the skills the mentee shall develop. Create a win-win relationship. etc.
• Authority alone won’t get leaders very far —
  If you want to be a real leader, one with voluntary followers, remember that you must earn and keep your people’s trust. They will carefully assess your attitude and actions, in particular whether you look out for others in addition to yourself. If their assessment is that you are trustworthy, they’ll stick with you.
• I know the salaries of thousands of tech employees —
  Pay equity requires transparency, so I’m revealing what I know
• The myth of time estimations —
  As a company policy, we do not provide or deal in software development time estimations of any kind, and we view such a practice as harmful to the overall development process, and to the industry as a whole. So what to do instead?

(Tech) Recruiting

• 21st century recruiting -
  Why is it so hard to recruit engineers? Maybe we are all doing it wrong. We still hire as we would for assembly lines: replaceable workers doing tasks. Are job descriptions even useful? Do you really need 10 developers next year? Instead of setting a target quota for hiring, we can allocate a budget for hiring, and whenever we encounter an individual who can bring value to the company, we create a position for that person and hire! Instead of looking for the “right fit,” we should instead ask ourselves how will the company be changed by the addition of this person, and is that adaptation something that will bring value to the company? Do you really care about “experience using K8 and Docker?” Your current developers didn’t have this experience two years ago; and chances are your company won’t care about “strong familiarity with Jenkins” in five years (will you still be using Jenkins?). So why do we have job requirements filled with such transitory criteria? CULTURE in biology means: conditions suitable for growth.

Technology / Architecture

• Software architecture is overrated, simple and clear design is underrated —
  Even in big design creations most teams do not use any of the design tools taught in school: UML, ADR, 4+1 model, etc. In those projects there was also no architects owning the designs and models. Neither Uber nor Microsoft /Skype have hands-off sw architect positions. No references to the common architecture patterns. Based on asking FANG (Facebook, Amazon, Netflix, Google) engineers there is quite common approach to design: Understand Business Problem, Brainstorm, Whiteboard, Write simple doc with simple diagrams, talk about tradeoffs and alternatives, circulate and get feedback. The goal should be simplictly. …
• Stop calling it bad code —
  “bad code” is a lazy expression. It’s not specific and means different things to everyone. Be specific, Give a specific suggestion, talk about future implications of code when not changed, involve the person who produced that code. From Bad Code to how make this better.
• 5 Data Stores and when to use them —
  Nice little overview / reminder for when to use which type of Data Store: RDB, NoSQL (Document Store, Wide Column Store, Key Value, Full Text SE, Message Queue,
• Goodbye microservices — from 100 problem children to 1 super star —
  Our initial microservice architecture worked for a time, solving the immediate performance issues in our pipeline by isolating the destinations from each other. However, we weren’t set up to scale. We lacked the proper tooling for testing and deploying the microservices when bulk updates were needed. As a result, our developer productivity quickly declined. Moving to a monolith allowed us to rid our pipeline of operational issues while significantly increasing developer productivity. We didn’t make this transition lightly though and knew there were things we had to consider if it was going to work.

Self Mastery / Self Development

• Have coffee with an engineer —
  If you want to grow reach out to people you do not know: An engineer or manager from another company, with the aim to learn about their way of working, thinking.
• SRE as a lifestyle choice —
  SRE described from a quite different angle. Nice read!
• Your Story — from building a SMS based product to leading a big tech centre —
  His 11-year-long experience as a tech entrepreneur has many lessons — on failures, entrepreneurship, and leadership — for anyone aspiring to strike out on their own. Still, if there’s one overriding takeaway from his story, then it’s undoubtedly Sidu’s relentless drive to successfully build and scale his company, until his eventual exit to Indonesia-based on-demand multi-service platform GoJek.
• Why asking for advice is more useful than asking for feedback —
  Research suggests that feedback often has no (or even a negative) impact on our performance. This is because the feedback we receive is often too vague — it fails to highlight what we can improve on or how to improve. Our latest research suggests a better approach. Across four experiments — including a field experiment conducted in an executive education classroom — we found that people received more effective input when they asked for advice rather than feedback.
• Why time off actually improves Life AND Work —
  Creativity, health, having a life outside work!
• The real reason why people behave badly and what to do about IT -
  A quite long read about emotions, empathy, negativity and how to deal with those (especially in the work place).