Management

(Reorganize this to be more topical)

"The Worst Tool for the Job": if you need a tool, buy the cheapest one you can find. If it’s inadequate, or breaks, or you use it a lot, then buy the best one you can afford. If you follow this strategy, you’ll sometimes waste a little money by buying a cheap tool before buying a good one. But you won’t waste money buying expensive tools that you rarely use. And you won’t waste money by buying a sequence of incrementally better tools until you finally buy a good one.

Servant Leadership - Jason Malmstadt

Questionable Advice: “How can I drive change and influence teams... without power?” - Charity Majors

A few words on communication - Oskar Dudycz

Engineering Leadership Tactics: Finding Focus - Francisco Trindade

10 Best Innovation Frameworks - JD Meier

Biases and Fallacies Lead to Smol Thinking

Culture

Building a Healthy Startup Engineering Culture

Project Management

Project Management Antipatterns (I don't think this is a list of project management antipatterns as much as a general list of project antipatterns. AND they forgot to credit Neal as the source of the term Blowhard Jamboree.)

Organizational Design

Building Organizational Resilience through Documentation and InnerSource Practices

What Shape is Your Engineering Team

Engineering Management

"Boost Developer Productivity by Reducing Their 'Paper Cuts'": "A poor developer experience is death by a thousand paper cuts. That’s why Jason Kennedy and his engineering experience team at One Medical are looking to remove the sources of each little pain in the cut."

"A Simple Framework for Software Engineering Management": Responsibilities (people management, delivery leadership, technical system ownership) in a 2-axis grid with priorities (issues, things that are OK, ideas/aspirations). "To sum up, we can look at software engineering management as a combination of three areas of responsibilities: people management, delivery leadership, and technical system ownership. Paying attention to all three responsibilities is important. However the amount of attention each responsibility should get depends on the team, the organisation, the product, and other factors. It also changes over time. Within each responsibility area we can identify issues, things that are okay, as well as ideas and aspirations. Things that are already okay only need to be acknowledged. Issues need to be prioritised and promptly resolved. Ideas and aspirations should be evaluated and, if deemed relevant, executed or put on the roadmap."

"Engineering Management Checklist":

"This list isn't meant to be exhaustive, nor is every item listed here applicable all the time. It's meant to give a basic framework to help managers, particularly less experienced ones, think about balancing their responsibilities."

  1. Section 1: Managing the team

    1. every member of the team knows what they should be working on
    2. every member of the team knows what to do if they finish a task, or get blocked
    3. every member of the team has had a meaningful career conversation within the last six months
    4. every member of the team receives timely, meaningful, actionable performance feedback
    5. work that needs to get done aligns with work that is rewarded by the promotion process
    6. performance reviews never contain surprises
    7. team members are able to express ideas for new projects or changes to the way the team works
    8. the team is able to give input on roadmaps and plans
    9. the team is staffed adequately and work is evenly distributed
    10. the team, overall, has the level of functional expertise required to do the work, and a reasonable number of stretch goals are available
    11. conflicts are resolved in a fair and respectful way
    12. diversity is represented and embraced; a broad spectrum of views are considered

  2. Section 2: Managing peer relationships

    1. key team peer relationships are identified and regularly maintained through regular healthy, productive meetings, and effective written communication
    2. groups dependent on team's work can trust the commitments the team makes
    3. key peer teams have a clear idea of how they can request work to be prioritized by your team, with transparency into what the tradeoffs are
    4. team is able to get work required from dependency teams prioritized with a reasonable expectation that commitments are honored
    5. agreements are documented in writing
    6. progress and set backs are reguarly communicated to key stakeholders
    7. when collaborative projects are completed, credit is shared among the contributors
    8. there is a clear, mutually-respectful escalation path for issues that cannot be resolved between peer managers/engineers
    9. managers are able to discuss issues privately in a psychologically safe manner

  3. Section 3: Managing senior mgmt relationships

    1. direct management has clear visibility into the progress of the team
    2. direct management/management chain is appropriately involved in issues requiring special attention
    3. you are able to advocate for specific prioritization decisions; priorities are set with transparency
    4. clear agreement on goals and definition of success

  4. Section 4: Managing yourself

    1. Your own work-life boundaries are respected
    2. Your immediate and long-term career goals are documented in writing
    3. You are not stagnating, even if your immediate career goals don't involve a promotion
    4. impact is primarily expressed in achievements of the team and the growth of the team members

"Effective Technical Leadership": What makes a badass TL is broken down into three A's: attributes, activities and actions.

Why Executives Leave

What Team Structure is Right for DevOps to Flourish?

5 Tips for Being an Effective Tech Lead

What It Takes to Be a Great Technical Lead

Looking at the team as a whole

"5 Things High-Performing Teams Do Differently"

  1. High-Performing Teams Are Not Afraid to Pick Up the Phone (communicate more frequently)
    1. High-Performing Teams Are More Strategic With Their Meetings (avoid poor meetings by requiring prework from participants; introduce an agenda; begin with a check-in that keeps team members apprised of one another's progress)
    2. High-Performing Teams Invest Time Bonding Over Non-Work Topics (high-performing team members are significantly more likely to spend time at the office discussing non-work matters with their colleagues (25% more) — topics that may extend to sports, books, and family)
    3. High-Performing Teams Give and Receive Appreciation More Frequently (within the best teams, appreciation doesn’t flow from the top down. It’s a cultural norm that’s observable in peer-to-peer interactions)
    4. High-Performing Teams Are More Authentic at Work (high-performing teams were significantly more likely to express positive emotions with their colleagues; interestingly, however, they were also more likely to express negative emotions at work. Why would expressing negative emotions at work yield more positive performance? It’s because the alternative to expressing negative emotions is suppressing them, and suppression is cognitively expensive. It involves expending valuable cognitive resources attempting to hide emotions from others, leaving less mental firepower for doing the work.)

What Google Learned From Its Quest to Build the Perfect Team (New York Times)

Leadership/You as the leader

"5 Things That Change When You Become a Leader" (HBR, Jan 18 2022):
* People don't work as much as you think:

Know how your org works: "Social media, blog posts and conferences amplify aspirational ideas. There’s nothing wrong with this in my opinion — it’s important to constantly keep pushing the envelope further, after all. Your organization, however, rewards what you actually get done that benefits the organization, which might be a very far cry from whatever might be de rigueur on social media. ... One of the most effective things you can do to be successful at your job is to understand how your organization works. ... Managers need to deal with these skills as a part of their job description. So do ICs at the very senior levels, but it’s never too early to start cultivating this knowledge. In fact, a core part of mentoring engineers needs to be schooling them in how the organization works, which will then enable them to build a successful track record of getting things done. Shielding non-senior engineers from organizational politics not just stymies their growth but also hinders their visibility into the skills they’d eventually need to learn the hard way, skills for which there exists no easy playbook, even if some managers and senior ICs might take a more short-sighted view and see this as a way to help other engineers “maintain focus”. The most important skill for any engineer to posses is the ability to learn quickly.

Managing People: In short:

Meetings

"The Remote Pop-In Meeting": "The pop-in, back before open floorplans, is when you physically walk into someone's office to ask them a question or spitball an idea. In an open floorplan you can instead swivel your chair or walk to their desk. The pop-in is valuable because it's as informal as email, but as high-bandwidth and low-latency as meetings. It's interruptive to be popped in on, but that interruption power is self-limiting: the effort of physically going somewhere is high, and the tools available to the target like doors, signs, and social cues are numerous and don't require much thought to implement. ... There's really no remote equivalent to the pop-in. There are products that help you "hang out" like Facebook Portal, but nothing that implements the pop-in. ... In our company Discord server, we give everyone one voice channel of their own. This is your "office". When you are online and able to be disturbed, you join your office, alone. You stay in there as long as you are "in". When someone wants to pop in, they join your voice channel. The chime plays, they say hello, you unmute and turn on video if you like, and have your pop-in. And that's really it."

Meet is Murder (New York Times, 2016)

"Making Better Meetings"

1:1s

Plucky 1:1 Starter Pack | Plucky 1:1 Manager Pack: "Conversation cards" for those awkward moments of silence in a 1:1. Highly recommended.

9 Questions for 1:1s (by Claire Lew, CEO of KnowYourCompany):

  1. "Are you afraid of anything at work?"
  2. "Have you seen something recently and thought to yourself 'I wish we'd done that'?"
  3. "Is there something we should measure in the company that we currently don't?"
  4. "Is there any part of the company you wish you were able to interact with more?"
  5. "Are there any benefits we don't offer that you'd like to see us offer?"
  6. "Is there an area outside your current role where you feel you could be contributing?"
  7. "Is there anyone at the company you wish you could apprentice under for a few weeks?"
  8. "Have you seen someone here do great work that's gone unnoticed?"
  9. "Are there things you don't know about the company that you feel you should know?"

Ashlee Clifton's (Rocket Mortgage) Guide to 1:1s

Organizational structure

"The myth of the flat start-up: Reconsidering the organizational structure of start-ups": "My study cautions against [the myth that start-ups should be flat], suggesting that adding a few hierarchical levels of mangers can substantially help start-ups achieve commercial success and survive in their hostile environments, albeit at a potentially marginal cost of creativity."

Interviewing/Hiring

"Are Emily and Greg More Employable than Lakisha and Jamal? A Field Experiment on Labor Market Discrimination": "We perform a field experiment to measure racial discrimination in the labor market. We respond with fictitious resumes to help-wanted ads in Boston and Chicago newspapers. To manipulate perception of race, each resume is assigned either a very African American sounding name or a very White sounding name. The results show significant discrimination against African-American names: White names receive 50 percent more callbacks for interviews. We also find that race affects the benefits of a better resume. For White names, a higher quality resume elicits 30 percent more callbacks whereas for African Americans, it elicits a far smaller increase. Applicants living in better neighborhoods receive more callbacks but, interestingly, this effect does not differ by race. The amount of discrimination is uniform across occupations and industries. Federal contractors and employers who list Equal Opportunity Employer' in their ad discriminate as much as other employers. We find little evidence that our results are driven by employers inferring something other than race, such as social class, from the names. These results suggest that racial discrimination is still a prominent feature of the labor market."

"Does Stress Impact Technical Interviews?": "Software engineering candidates commonly participate in whiteboard technical interviews as part of a hiring assessment. During these sessions, candidates write code while thinking-aloud as they work towards a solution, under the watchful eye of an interviewer. While technical interviews should allow for an unbiased and inclusive assessment of problem-solving ability, surprisingly, another possibility is that technical interviews are instead a procedure for identifying candidates who best handle and migrate stress solely caused by being examined by an interviewer (performance anxiety). To understand if coding interviews—as administered today—can induce stress that significantly hinders performance, we conducted a randomized controlled trial with 48 Computer Science students, comparing them in private and public whiteboard settings. We found that performance is reduced by more than half, by simply being watched by an interviewer. We also observed that stress and cognitive load were significantly higher in a traditional technical interview when compared with our private interview. Consequently, interviewers may be filtering out qualified candidates by confounding assessment of problem-solving ability with unnecessary stress. We propose interview modifications to make problem-solving assessment more equitable and inclusive, such as through private focus sessions and retrospective think-aloud, allowing companies to hire from a larger and diverse pool of talent."

Is Blind Hiring the Best Hiring (New York Times, 2016)

Meta/People

T-Shaped People and Academia: "... academia is doing a disservice to ‘T-shaped persons,’ i.e. persons combining deep expertise in one or more fields with an ability to collaborate across areas. T-shaped persons are often contrasted with I-shaped persons, commonly known as experts. Given the state of the art in the software industry, T-shaped people are a sought-for commodity: the current ‘framework du jour’ might be obsolete in a few years, but the horizontal bar of a T-shaped person ensures that they can also contribute to other aspects of a project, and quite likely will develop new vertical bars, i.e. new expertise over time."

People don't work as much as you think

A fractal of lies: Dr House was right: everybody lies. (More to the point, studies are often built off of interviews and interrogation, and people have a habit of telling interviewers not-entirely-truthful things for a variety of reasons.) "Whenever there is an advantage, or a power gradient, or a political agenda, or people just want to fuck with you for their own amusement, probably there are lies. And then people repeat those lies - sometimes purely innocently, sometimes adding their own lies on top."

Rethinking the Work-Life Equation (New York Times, 2016)

The Robots Are Coming for Wall Street (New York Times, 2016)

The Post-Cubicle Office and its Discontents (New York Times, 2016)

The New Dream Jobs (New York Times, 2016)

Trouble in programmer’s paradise: gender-biases in sharing and recognising technical knowledge on Stack Overflow: "This paper examines gender-biases on Stack Overflow, the world’s largest question-and-answer forum of programming knowledge. Employing a non-binary gender identification built on usernames, I investigate the role of gender in shaping users’ experience in technical forums. The analysis encompasses 11-years of activity, across levels of expertise, language, and specialism, to assess if Stack Overflow is really a paradise for programmers. I first examine individual users, asking if there are gender differences in key user metrics of success, focusing on reputation points, user tenure, and level of activity. Second, I test if there are gender-biases in how technical knowledge is recognised in the question-answer format of the platform. Third, using social network analysis I investigate if interaction on Stack Overflow is organised by gender. Results show that sharing and recognising technical knowledge is dictated by users’ gender, even when it is operationalised beyond a binary. I find that feminine users receive lower scores for their answers, despite exhibiting higher effort in their contributions. I also show that interaction on Stack Overflow is organised by gender. Specifically, that feminine users preferentially interact with other feminine users. The findings emphasise the central role of gender in shaping interaction in technical spaces, a necessity for participation in the masculine-dominated forum. I conclude the study with recommendations for inclusivity in online forums."

Articles

Detail Pages:

Last modified 16 December 2024