The [Tech Bro CEO] Strikes Back

What Elon Musk is doing to Twitter right now is what happens when someone with the same ideology and worldview as James Damore has enough power and money to be in charge of a company instead of just a worker. When I first wrote about Damore a little over 5 years ago, I wrote about the ways in which the ideas in his muddled, poorly-written manifesto were easily disproven. Subsequent years have demonstrated that Damore’s worldview has plenty of representation not merely within the rank-and-file of tech companies, but at the very top as well. While Damore did not use this term in his manifesto, with today’s perspective it’s clearly recognizable as an a long accusation about the ways in which the Google in 2017 was too “woke”. His manifesto is still available online, along with much of the criticism of it, but for the purposes of this piece I will summarize the tech bro worldview this way:

  • The status quo composition of our companies, with its relative lack of women, black people, brown people, etc is the “natural order” of things
  • Diversity initiatives require a “lowering of standards” and are therefore not meritocratic 

The tech bro worldview bears enough similarities to the worldview of those who lead businesses outside of tech, hold political office, lead certain of our religious institutions, and those who populate newsrooms and shape popular opinion that Damore’s manifesto even found a defender on the opinion page of the New York Times. Despite Brooks’ call for Google CEO Sundar Pichai to resign, the National Labor Relations Board found the company acted lawfully in terminating Damore’s employment for violating the company’s code of conduct (an unsurprising outcome in my view, given the way at-will employment works).

There is plenty of evidence to debunk both the “natural order” and “lowering of standards” assertions (to say nothing of the idea of meritocracy itself). Nor can the timing of this particular conflict realistically be separated from what was happening in our politics at the time. But let us proceed to another example of how these false assertions nevertheless shape the thinking and actions not just of rank-and-file tech bros, but of those who typically lead them.

Fast-forward to April 2021, and I’ve been asked to be a co-panelist for a discussion on the intersection of race and technology. This discussion occurred just a day after Jane Yang (a now former employee of Basecamp) wrote an open letter to the founders while on medical leave. Yang was responding to the decision of the CEO (Jason Fried) to ban “societal and political discussions” from the company’s internal chat forums. Yang’s letter painted a picture of Basecamp’s leaders that looked very familiar to me from my own experience with similar people in the industry. The letter is well-worth reading in full, but here is paragraph that makes it clear Basecamp’s leaders were no different than those at other companies they’d criticized for years:


“But there were also some yellow flags. Whiffs of smoke that I was starting to pick up on. Your disproportionate, chilling response to a retrospective that you asked for. The whispers of how you had handled a prior company discussion when someone raised the able-ist language in the title of a recently published company book. The continued mourning years later of an executive who had centered the employees as her job, and then was summarily fired for not living up to the additional expectations of working miracles in marketing. The quiet departures of women and people of color, all of whom held their heads up high and left a better place behind than they found it.”

from Jane Yang’s open letter to Jason Fried and David Heinemeier Hansson

Fried and Hansson also announced the end of committees (including a committee for diversity, equity, and inclusion) and the end of 360 reviews (among other changes). As it turned out, Fried and Hansson were dealing (quite poorly) with an internal reckoning over a long-standing company practice of maintaining a list of “funny” customer names. The founders knew about the existence of this list for years, and predictably, the names that Basecamp customer service reps found ripe for mockery included Asian and African names. Particularly because of how public and opinionated Fried and Hanson have been regarding workplace culture–to the extent of having written five books on the subject, including a New York Times bestseller–and held up their own company as an example of how to do things better, it was (and still is) quite difficult to ignore the rank hypocrisy of their choice to shut down internal discussion of a significant cultural failure that they allowed to persist for years. The company all-hands called by the co-founders to try and mitigate the blowback from their decisions instead resulted in the departure of one-third of the entire company.

Over time, marginalized groups (and some of their allies) have mastered online tools and social media and leveraged them to amplify their voices. We saw that mastery at work in the responses to Damore’s manifesto. At Basecamp, marginalized people used these tools to challenge the worldview of the company founders. Fried and Hansson’s attempt to squash the backlash by fiat failed miserably.

While Coinbase didn’t figure prominently in our panel discussion at the time, that’s one of a number of companies whose lead Basecamp was following in being “mission-focused”, and supposedly apolitical. So discovering that barely two years later, CEO Brian Armstrong has decided that politics is ok when it comes to tracking the “crypto-friendliness” of politicians prior to the recent midterm elections here in the U.S. was … interesting to say the least. People and companies advocating for cryptocurrency have been far from apolitical when it comes to targeting black and brown investors, so the same groups targeted by unscrupulous operators in the mortgage space prior to the crash of 2008 have piled into crypto in disproportionate numbers relative to other investors–and have taken disproportionate losses as cryptocurrencies have plunged in value and multiple crypto companies have gone bankrupt.

Now we’re just over a month into Twitter’s takeover by Elon Musk–a takeover entered only because he faced certain defeat in Delaware Chancery Court. Musk has fired half the staff in layoffs so haphazardly executed that he ended up trying to rehire those not correctly identified as critical. He undermined the company’s current verification scheme by pushing the launch of a feature enabling anyone to be verified by paying $8/month, only for numerous pranksters to pay the fee and impersonate numerous brands on Twitter like Eli Lilly. Musk’s ultimatum to remaining Twitter staff to be “hardcore” or be gone resulted in a wave of resignations much larger than anyone anticipated, not unlike Fried and Hansson’s attempt to mitigate the damage from their attempt to squash internal dissent. The same thin-skinned reaction to criticism displayed by Fried and Hansson has been even more on display from Elon Musk. He’s fired those who tried to correct his ill-informed assertions regarding the ways the tech behind Twitter actually works–and mocked the skills and intelligence of the people he fired after the fact. Musk blames “activists” for the precipitous drop in ad revenue instead of being accountable for his own poor decision-making.

The reaction in various quarters to Musk’s floundering incompetence as CEO of Twitter has been very telling. According to the reporting of Casey Newton and Zoe Schiffer, some tech CEOs are hoping Musk succeeds. The same Hansson who not long ago “encouraged employees to read Between the World and Me, a memoir by Ta-Nehisi Coates, and The New Jim Crow, Michelle Alexander’s exploration of the racist nature of mass incarceration”, is now writing tributes to Elon Musk cheering the likely end of affirmative action in higher eduction. Hansson even touts John McWhorter’s Woke Racism these days, and speaks favorably of the likes of Glenn Loury and Bill Maher. Loury and McWhorter are regularly quoted by white conservatives too cowardly to share the stereotypical views of black people they already believed anyway without a black conservative to hide behind. We’re already starting to see layoffs across tech, and as economic conditions change and COVID-19 (hopefully) recedes, these CEOs almost certainly see an opportunity to re-establish their worldview within their spheres of control without having to account for marginalized people. That desire is almost certainly behind the persistent belief in some quarters that what Elon Musk is doing is on purpose.

There is plenty of criticism that can and should be leveled at Mark Zuckerberg (particularly his continued pursuit of the failed metaverse strategy and cavalier approach to customer privacy). But when it comes to how to handle layoff news, he delivered a masterclass in how to handle layoffs professionally not long after Musk’s deliberately cruel and haphazard ones. Other tech CEOs rooting for the man who treats his employees the worst will definitely be a trend to keep an eye on as time progresses.

Tell Me About Yourself–Engineering Leader Edition

The following tweet starts an excellent thread of questions that I’m taking as a starting point for this post looking back over the past 5 years with my current company:

When was the last time you promoted someone on your team?  How did it happen? My organization works in a way that promotion decisions are actually approved (or rejected) at a much higher level than mine.  But I’ve advocated successfully for promotion for two of my direct reports, both during the pandemic.

The first was a recent college graduate who spent the 18 months of his professional career on my team.  While I wasn’t his manager for the entirety of that time, I encouraged him to work on communication across various channels (Slack, email, documentation, pull request comments, etc).  I did what I could to put opportunities in front of him to grow and showcase his skills.  What he did on his own (in addition to pursuing a master’s degree in computer science on the side) was earn AWS certifications.  He passed 4(!) in a single calendar year.  So when it came time to year-end reviews, there were a lot of accomplishments to point to as well as positive feedback from people outside our team from their experiences of working with him.  He was the first direct report I had who earned the highest possible year-end rating: exceptional, and the first promotion (to senior engineer).  He’s still with the company today, and received another promotion (to principal engineer) in the same cycle I received a promotion to senior manager.

The second promotion was for someone who had been with the company longer than I had.  From what I was told she had been submitted for promotion once or twice before but had not been selected for promotion.  She was (and is) one of those engineers who leads much more by example than by talking.  Having observed over the years that the review process tends to overindex on software engineers that present well, I became the person in meetings who consistently pushed people to consider written communication as well as presentations in judging the quality of an engineer’s communication.  I also recommended she take the technical writing courses offered by Google.  These steps, plus highlighting her numerous critical contributions to the team’s success during another year-end review cycle appear to have been enough to get her promoted to principal engineer.

Why did the last person in this role leave?  It’s been long enough that I don’t actually recall why the previous leader of the team moved on.  I presume they found an opportunity with another company.

How do you nurture psychological safety in your team?  Regular one-on-ones (I follow a weekly cadence for these) has been important to nurturing psychological safety.  Because I joined the team to lead it after work-from-home began, Zoom meetings were really the only avenue available to build the rapport necessary for my team to trust me.  I also started a technical book club with the team, with the intention of giving my team exposure to software design and implementation principles outside the scope of our current work, along with providing opportunities for each member of the team to lead discussions and explore ideas.  It seems to have had the additional benefit of building everyone’s comfort level with, and trust in, each other along with all the other things I’d intended it for (including ideas originating from book club showing up as production enhancements to our software).

When was the last time you supported a direct report’s growth, even if it meant leaving your team or company?  In my previous department, I had staffing responsibilities for two teams for awhile: one composed entirely of contractors in addition to my own team.  In helping a scrum master friend of mine diagnose the causes of the contractor team struggling to be productive, I concluded that the main issue wasn’t technical expertise but the lack of a leader to help remove impediments and connect them with others in the organization who could help their tasks move forward.  I proposed this as a leadership opportunity for one of my direct reports and got buy-in from higher-level management.  He was so successful in the stretch opportunity I created, he got promoted after leaving my team.  Not long after that, he left our organization to join Amazon as an engineering team lead in Seattle.  He’s currently a principal software engineering manager with Microsoft in Atlanta.

Can I speak to some women on the team to hear more about their experience?  Two of the engineers on my current team are women.  If all goes well, another one of them will be promoted to principal engineer by virtue of her performance over the past 18 months.  While it will likely mean losing her to another team, her getting promoted and gaining new opportunities that my team’s scope doesn’t provide is more important to me.  I see it as another opportunity to build up another engineer in her place.

Software Development Roles: Lead versus Manager

I’ve held the title of development lead and development manager at different points in my technology career. With the benefit of hindsight, one of the roles advertised and titled as the latter was actually the former. One key difference between the two roles boils down to how much of your time you spend writing code. If you spend half or more your time writing code, you’re a lead, even if your business cards have “manager” somewhere in the title. If you spend significantly less than half your time writing code, then the “manager” in your title is true to your role. When I compare my experience between the two organizations, the one that treats development lead and development manager as distinct roles with different responsibilities has been not only been a better work environment for me personally, but has been more successful at consistently delivering software that works as advertised.

A company can have any number of motivations for giving management responsibilities to lead developers. The organization may believe that a single person can be effective both in managing people and in delivering production code. They may have a corporate culture where only minimal amount of management is needed and developers are self-directed. Perhaps their implementation of a flat organizational structure means that developers take on multiple tasks beyond development (not uncommon in startup environments). If a reasonably-sized and established company gives lead and management responsibilities to an individual developer or developers however, it is also possible that there are budgetary motivations for that decision. The budgetary motivation doesn’t make a company bad (they’re in business to make money after all). It is a factor worth considering when deciding whether or not a company is good for you and your career goals.

Being a good lead developer is hard. In addition to consistently delivering high-quality code, you need to be a good example and mentor to less-senior developers. A good lead developer is a skilled troubleshooter (and guide to other team members in the resolution of technical problems). Depending on the organization, they may hold significant responsibility for application architecture. Being a good development manager is also hard. Beyond the reporting tasks that are part of every management role, they’re often responsible for removing any obstacles that are slowing or preventing the development team from doing work. They also structure work and assign it in a way that contributes to timely delivery of functionality. The best development managers play an active role in the professional growth of developers on their team, along with annual reviews. Placing the responsibility for these two challenging roles on a single person creates a role that is incredibly demanding and stressful. Unless you are superhuman, sooner or later your code quality, your effectiveness as a manager, or both will suffer. That outcome isn’t good for you, your direct reports, or the company you work for.

So, if you’re in the market for a new career opportunity, understand what you’re looking for. If a development lead position is what you want, scrutinize the job description. Ask the sort of questions that will make clear that a role being offered is truly a development lead position. If you desire a development management position, look at the job description. If hands-on development is half the role or more, it’s really a development lead position. If you’re indeed superhuman (or feel the experience is too valuable to pass up), go for it. Just be aware of the size of the challenge you’re taking on and the distinct possibility of burnout. If you’re already in a job that was advertised as a management position but is actually a lead position, learn to delegate. This will prove especially challenging if you’re a skilled enough developer to have landed a lead role, but allowing individual team members to take on larger roles in development will create the bandwidth you need to spend time on the management aspects of your job. Finally, if you’re an employer staffing up a new development team or re-organizing existing technology staff, ensure the job descriptions for development lead and development manager are separate. Whatever your software product, the end result will be better if you take this approach.