Engineering Management Reading List #2

Management / Leadership

• From Code to Conference Room -
  How to mix Engineering and Management at a Fast-Scaling Company. A must see panel talk with super useful insights from Alex Roetter (VP Engineering Twitter), Mike Curtis (VP Engineering, AirBnB), and Jeff Huber (SVP, Google X).
• Why this Engineering Leader thinks you should not aim for zero regrettable attrition.
  In this article Boufford (CTO, Greenhouse) reveals why he’s no longer hung up on attrition numbers. In sharing his take on what the industry’s conversation on regrettable attrition gets wrong, he makes the case for why we should all be talking about healthy and unhealthy turnover — instead of aiming for zero. “When you create a new team or company, it’s a chance to design the group you always wished to be a part of.” A common mistake early-stage startups make is trying to hire every engineer that passes the technical bar. Instead, work to figure out whether your vision matches what the candidate is looking for. Misalignment between what you’re selling and what they think they’re buying inevitably leads to turnover down the road. This also tells you about a culture you need to build to make people stay: A culture of respect, support professional growth, establish fairness and transparency. Accept that people will leave and support them in doing so by not blocking them in their own career paths.
• Kim Scott: On Leadership and Radical Candor
  This is a nice intro into Scotts leadership model: Radical Candor. I really hope this would be applied in all companies as the core leadership model.

Organizational and Team Development

• Mentorship, Coaching, and Sponsorship — A Powerful Framework for Building Resilient Teams
  Lara Hogan, who was Engineering Director at Etsy and VP Engineering at Kickstarter started wherewithall to offer 1:1 coaching services for managers, wrote a guidebook for engineering leaders and those who want to become one: It is called Resilient Management … This article contains an excerpt of her approach, which focuses the differences between three different styles: Mentorship, Coaching and Sponsorship.
• Capability Mapping
  Capability Profile Mapping is a powerful approach for organizations, individuals and teams to create a shared understanding of their current capabilities and gaps and direction, against delivery needs and organizational direction. It also allows people to take a proactive role in their own capability growth. If organizations ask about skills at too high a level, with consequences like pay or access to training, then the responses can vary wildly. This over-reporting doesn’t help anyone know where to put their training budgets, what capabilities they need to grow, or who to hire. Understanding the difference between skill and capabilities is key! Skills are abilities people can learn, develop and demonstrate. Capabilities — the application of knowledge, skills and experience to achieve an outcome. Knowledge = understanding theories, Skills = practical application of those theories and experience = doing that in a lot of different circumstances and environments. We use capabilities in order to achieve outcomes. It is not about collecting skills and making everyone an expert in everything.
• Bridging the Leadership Gap between tech and business
  To enable transformation, business and tech leaders alike must take bold action. Perhaps worst of all, the persistent separation of the IT function as a far-off, siloed corner of the company where decisions around technology are made perpetuates outdated ideas about the role of technology in an organization. This limits the reach of technology, and it sets up a false dichotomy between IT and the business. For so many organizations today, technology is the business. These rock stars (tech leaders who partner with the business) tend to have several things in common. First, they don’t hide out on a separate floor or building designated for IT. They walk the halls, and they engage with internal and external customers. They may have workspaces in different locations so that they can also embed themselves with their teams, but they know that the best way to keep stuff from being thrown over the wall is to remove the wall. Another key behavior involves raising the conversation from lower-level technology concerns like systems and servers to business outcomes. But questions won’t go the whole way — managers need to build strong teams and foster a sense of engagement, intellectual curiosity, and cross-functional collaboration within them. Finally, transformational technology leaders take ownership, not blame.

Technology

• Why I write dirty Code: Code quality in context
  It’s all about using data to guide when and where to invest in higher code quality, and how it can be a long-term saving to compromise it. Code quality is all about understandability. The reason being that code is read exceedingly more often than it’s modified. A hotspot is code with high development activity and frequent churn. It’s code that’s worked on often, and hence code that has to be read and understood frequently, potentially by multiple authors. The interesting thing with hotspots is that they make up a relatively minor part of the code, often just 1–3% of the total code size. This implies that any code quality issues or technical debt in the hotspots, however minor, are likely to be expensive: This is where code quality matters the most. Knowing the health of your code — at any time — is key. Once you have that knowledge, you can start to use technical debt in its original sense. Write a test for most new code.
• Advice to Less Experienced Developers
  Some useful advice for Junior SW engineers or those who think about starting a career as a coder: This is hard stuff and takes many years to master. It takes time to find a good job. Don’t let your employer treat you bad. Interviewers oftentimes are not experienced with interviewing. Find out what is really expected from you — job postings are lies. Your ability to reason is as much important as your coding skills. Ask for help. And many more.
• How to invest in technical infrastructure
  Will Larson about how Stripe invests into their tech infrastructure: Tools used by many teams for critical workloads (e.g. Cloud Services, Dev Tools, Messaging, Data Infra, Productivity).
• 7 years as a developer — lessons learned.
  The most important language in programming is … English/Spanish/Chinese/German because talking to humans is way more important than talking to machines. Communication skills can make or break a project. Soft / Professional skills can be more important to a project success than purely technical ones. Have a deep understanding of what you are building and why! It is your job to solve problems with code — however code is just one part of many. If code reviews are stressful you do it wrong. Something will go wrong, be prepared. Say No if you don’t know. Con sider to learn in public (write posts, tweets, give talks, tell your co workers).
• Making technical decisions
  A collection of learnings for making good technical decisions: High Level first, Design matters, beware of over architecting, be agnostic about technology, assess your team, test!
• AI in 2019
  A review, Events and new developments in 2019

Startup Life

• What your Startup can learn from Astronauts, The Daily Show, and the Coach of the Boston Celtics
  The writers’ room of The Daily Show is a great source of inspiration for being creative while being super fast paced. This well oiled comedy generating machine makes a show from scratch in less than a day: Focus on improving your brainstorming, encourage bustiness, create psychological safety and design for diversity. You need to create a culture of criticism and reduce the need to impress. Move from proving to improving mood. Don’t mistake humility for weakness, because this will point you to the horizon. And many more insights.

Books

Coders, by Clive Thompson

I really enjoyed reading this book about how coding as a profession developed. It tells the stories of hackers and engineers in the early years of the internet, how the well known facebook like button was developed, and her nerd culture differs from actual coding jobs.

The last one is a good reason for Managers in Engineering as way too often people tend to treat software engineers more like factory workers. But neglecting their creativity, their never-seen-before problem solving skills, and most importantly their ability to see the world as a system.