GOP state officials threaten legal action over company diversity policies

A group of Republican U.S. state attorneys general on Thursday warned the country’s largest companies that certain workforce diversity policies could be illegal in light of the U.S. Supreme Court’s decision effectively striking down affirmative action in higher education.
— Read on

Not even a full month after this post suggested affirmative action in employment would be the next thing the Supreme Court majority would rule unconstitutional, GOP state attorneys generals have threatened to sue companies they assert (without evidence) have used race-based practices in hiring. Notable among the companies these attorneys general have singled out are Apple, Google, Microsoft, and Uber. The tech industry is an interesting target for these state attorneys general given it’s historically-poor track record on diversity across any number of metrics.

A brief look at Apple’s inclusion and diversity results show a workforce that is still 2/3rds men over the 7 years (2014-2021) for which they’ve provided data. Asian representation in their workforce has grown the most significantly over the same period, from 15% to 27.9%, while the percentage of black and Hispanic employees have grown by much smaller rates. Of the remaining highlighted companies, only Uber employs a workforce fewer than 60% male, and their ethnic diversity numbers have actually gotten worse in some respects (over 10% of their workforce was Black or African-American in 2021, while barely 9% of the workforce is as of the latest metrics published this year). But in the post-affirmative action American landscape, we can now expect even the good-faith efforts of companies to diversify their workforces to be challenged in court and for those workforces to be less-diverse as a result. We will learn the hard way that diversity isn’t just a “nice-to-have”; the increasing lack of diversity will result in worse products from companies.

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.

Résumé Shortening (and other résumé advice)

I saw a tweet from one of the best tech follows on Twitter (@raganwald) earlier today about the difficulty of shortening your résumé to five pages. While my career in tech is quite a bit shorter than his (and doesn’t include being a published author), I’ve been writing software for a living (and building/leading teams that do) long enough to need to shorten my own résumé to less than five pages.

While I’m certainly not the first person to do this, my (brute force) approach was to change the section titled “Professional Experience” to “Recent Professional Experience” and simply cut off any experience before a certain year. The general version of my résumé runs just 2 1/2 pages as a result of that simple change alone.

Other résumé advice I’ve followed over the years includes:

  • If there is a quantitative element to any of your accomplishments, lead with that. Prominently featured in my latest résumé are the annual dollar figures for fraud losses prevented by the team I lead (those figures exceeded $11 million in 2 consecutive years).
  • Don’t waste space on a résumé objective statement
  • Use bullet points instead of paragraphs to keep things short
  • Put your degree(s) at the bottom of the résumé instead of the top
  • Make your résumé discoverable via search engine. This bit of advice comes from my good friend Sandro Fouché, who started the CS program at University of Maryland a few years ahead of me (and has since become a CS professor). I followed the advice by adding a copy of my current résumé to this blog (though I only make it visible/searchable when I’m actively seeking new work). His advice definitely pre-dates the founding of LinkedIn, and may predate the point at which Google Search got really good as well.

Speaking of LinkedIn, that may be among the best reasons to keep your résumé on the shorter side. You can always put the entire thing on LinkedIn. As of this writing, the UI only shows a paragraph or so for your most recent professional experience. Interested parties have to click “…see more” to display more information on a specific experience, and “Show n more experiences” where n is the number of previous employers you’ve had. Stack Overflow Careers is another good place to maintain a profile (particularly if you’re active on Stack Overflow).

Managing Your Tech Career

Episode #980 of .NET Rocks was an excellent 52 minutes on career management for developers.  Since turning 40 this year, I’ve been thinking a lot more about my career and where I want to take it from here.  The entire episode is well-worth listening to, but I would distill the essence of the advice from the guest (John Sonmez) down to this: market yourself.

When I gave a talk to some software engineering students back in February, I encouraged them to start blogs, give presentations and talks, and start podcasts (so far I’ve only done the first two myself).  I suggested all of these things primarily as a way for them to improve their knowledge, but a higher profile on the internet is certainly a positive side-effect of doing those things.  One point I didn’t add (which Sonmez brings up in his interview) is that consistency is very important.  He recommends a blog post every week.  That’s a goal I’m striving to meet (though not always succeeding).

Another related point Sonmez made is that developers need to set aside regular time to manage their career.  The amount of time averaged something like an hour every two weeks.  Consistency is especially important here as well–if not mandatory, given how quickly technology advances.  I’ve recently started reading The Pragmatic Programmer, and it makes a similar point but uses investment terminology.  Section 5 of the first chapter (Your Knowledge Portfolio) make this point:

“Your knowledge and experience are your most important professional assets.  Unfortunately, they’re expiring assets.”

Knowledge about specific programming languages, databases, etc can age very poorly.  Failing to consistently add new assets to your knowledge portfolio, to diversify and balance those assets among various technologies (of varying maturities), and to “re-balance” that portfolio over time can result in obsolescence.  Given the prevalence of ageism/age discrimination  that already exists in information technology, having old or irrelevant skills is a quick way to end up at the margins of IT, working in companies that are yoked to technologies that will make it increasingly difficult for them to serve their business goals (much less to serve your goals of having a fulfilling technology career).

I saw this first-hand in an unexpected way when I attended South by Southwest in 2013.  One of the shuttle bus drivers I rode with regularly between my hotel and the various conference venues was actually doing it for income between short-term software development gigs all over the country.  He was an older gentleman whose skills (at least on the Microsoft stack) hadn’t advanced beyond VB6.  While there are still a ton of software systems built in VB6 (I certainly built my share of them in the late 1990s and early 2000s), his knowledge portfolio means that contract work maintaining VB6 code may be all that’s available to him.

In my own career, I’ve been working to broaden my own knowledge portfolio beyond the Microsoft stack.  Microsoft itself is doing some of this by adopting external technologies like JavaScript, jQuery, and knockout.js for web application development.  Angular.js is a framework strongly supported by Google that Microsoft has made sure plays very well with ASP.NET MVC.  So building my knowledge of JavaScript, and platforms like node.js are also goals for me in doing what I can to remain an attractive candidate for hire–whether as an employee, or for a future of self-employment.

Another Year Gone

It’s annual review time again, which means this year has gone by even more quickly than usual. Filling out my self-assessment was a good reminder of all the work I had a hand in completing.  I’m still deciding on goals for 2012, and I’m posting all of them here so I can look back on them over the course of next year and track my progress.

  1. Learn jQuery.  I got a bit of exposure to it this year through a couple of projects that I worked on, and a .NET user group presentation or two, but haven’t done the sort of deep dive that would help me improve the look-and-feel of the web applications I build and maintain.
  2. Learn a functional programming language.  I’ve been thinking about this more recently since some of our work involves the implementation of valuation models in code.  I also came across this article in the November Communications of the ACM advocating OCaml.  Since I work in a Microsoft shop, picking up something like F# might have a slightly better chance of making it into production code than OCaml or Haskell.  Part of my objective in learning a functional programming language is to help me recognize and make better use of functional techniques in a language like C#, which has added more and more support for the functional programming style of the years.
  3. Give a few technical talks/presentations.  This year, I presented on NuGet at my job, and on Reflector at RockNUG. Having to present on a tool or technology to group has always been a great incentive to do some deep learning of a subject.  It’s also a chance to exercise some speaking skills (which developers need a lot more than they might think in order to be successful) and to handle a Q & A session.  I haven’t developed any new presentations yet, but some prospective topics include: LINQPad, elmah,
  4. Take more online training. We have access to Pluralsight .NET training through work.  I watched quite a few of their videos over the course of the year.  2012 shouldn’t be any different in that respect.  I recently came across free webcasts on a variety of topics from DevelopMentor.  Since they’re downloadable as well as streamable, I’ll definitely use my commute to watch some of them.
  5. Write a compiler. It’s been awhile since I’ve cracked open “the dragon book”, so I’m probably overdue to exercise my brain in that way.  I found that suggestion (and a number of other very useful ones) here.
  6. Practice.  I’d heard of the “code kata” idea before, but hadn’t really explored it.  Dave Thomas of Pragmatic Programmers has nearly a couple dozen here.

The problem with exit interviews

The biggest problem with exit interviews is that they’re too little, too late. I had an exit interview recently (since I accepted an offer to go elsewhere), and there wasn’t anything wrong with the questions–it was just that nothing could be done about any of the concerns I raised.

The second major problem with exit interviews is that they focus too narrowly. All the feedback from exit interviews comes from people who’ve decided to leave. Assuming a company has had relatively low turnover for awhile, the feedback could be leaving out information from as much as 90% of its workforce.

If a company is serious about employee retention, they need to get feedback from as much of their workforce as possible on a regular basis. In my exit interview, I got questions about benefits, commute, holidays, and other issues. Regular, anonymous surveys on those issues would probably reveal a lot of useful information about ways benefits could be improved. Gathering this kind of information regularly will mean that at least some (if not most) of the answers you get will be from people who still have a stake in the company’s future.

Can Google Find You?

Recruiters use Google.  Whether you’re actively seeking a new job or not, it’s important to use this fact to your advantage.  My friend Sandro gave me this advice years ago, when he told me to put my resume online and make it “googleable”.  For me, the result was contacts from recruiters and companies I might never have heard of otherwise.  In addition to putting your resume online, I would recommend blogging about your job–within reason.  Definitely do not write about company secrets or co-workers.  Putting such things in your blog doesn’t help you.  Instead, write about what you do, problems you’ve solved, even your process of problem-solving.  At the very least, when you encounter similar challenges in the future, you’ll have a reference for how you solved them in the past.  Your blog post about how you fixed a particular issue might be helpful to someone else as well.

There are many options available for putting a resume and/or blog online.  Sandro hosts his, mine, and a few others on a server at his house.  But for those of you who don’t have a buddy to host theirs, here are a couple of readily-accessible free options:

There’s a ton of advice out there on what makes a great resume, so I won’t try to repeat it all here.  You can simply put a version of your 1 or 2-page Microsoft Word resume on the web, or you can put your entire career up there.  Having your own blog or website means you aren’t subject to any restrictions on length that a site like Monster or CareerBuilder might impose.  Consider linking your resume to the websites of previous employers, technologies you’ve worked with, schools you’ve attended, and work you’ve done that showcases your skills (especially if it’s web-related).  I don’t know if that makes it easier for Google to find you, but it does give recruiters easy access to details about you they might have to dig for otherwise.  Doing what you can to make this process easier for them certainly can’t hurt.

Don’t forget to Google prospective hires

One of my colleagues reminded me of that today.  The developer we’re interviewing tomorrow was the #1 result from Google when I searched on his name, thanks to his blog.  This works a lot better with uncommon names, of course.

My name (Scott Lawrence) is fairly common, so it’s only the #6 result on Google.  The result is probably that high because one of last month’s blog posts referred to Scott Hanselman.