career
Navigating the Great Delayering as a Senior Manager or Individual Contributor
The recent Wall Street Journal piece titled Your Boss Doesn’t Have Time to Talk to You describes the past year-and-a-half of my life as a senior manager on the software side in a financial institution very well. My “roll up”–the number of people who report to me directly–is 14 today, but has been as high as 21 within the past month or two. The delayering happening across corporate America is making workplaces worse for managers, for individual contributors (ICs), for the products companies put out, and ultimately for consumers.
The push from Wall Street to turn management into a job where you just “push the work forward”, as Beth Steinberg says in the WSJ piece, is short-sighted. Leaders must also be about helping their directs become more effective in their roles and leveling up to be capable of taking on more scope successfully. This is how a smart organization builds the next generations of leaders from within. One of the ways I tell people I mentor to judge hiring managers is by whether or not it seems clear that the professional growth of their direct reports is a top tier priority. Delayering is causing that answer to be “no” for a growing number of leaders.
A corporate America that already does a substandard job of training leaders has further broken the leadership growth ladder with delayering. In my organization, that means people leadership doesn’t start until you become a senior manager—with responsibilities for 2 separate engineering teams. Gone are the opportunities to create stretch roles managing a small number of direct reports or contractors and coaching aspiring leaders through successes and setbacks. Gone also are the opportunities for an IC to test out if leadership is for them on a small scale, and to change career tracks if they have a good experience. Failing to develop new leaders internally while stretching and burning out existing leaders with additional responsibilities heaped on them will contribute to poor decision making, organizations losing direction, perhaps even negative P&L outcomes until the leadership gaps are filled.
Delayering doesn’t only worsen life for ICs by reducing the amount of 1:1 time with their leader for feedback, it makes that feedback less-likely to be tactically useful because that leader’s broader scope necessarily puts them further from the tactical work. When I led one team of engineers, my scope was narrow enough to review PRs and provide comments to help subsequent work improve. I could question individual design choices and shape them for the better. I could work individually on helping my directs communicate more effectively. 14 directs is too many people for one manager to coach and guide directly that will yield significant professional growth.
Delayering may have improved the profitability and stock prices of most FAANG companies (and Microsoft) in the near term, but the trend has not improved these companies’ products at all in my experience. Google Search results are noticeably worse. Meta’s product newest product offerings still look very similar to features pioneered by much smaller companies and platforms. Their GenAI advances also appear to have stalled relative to their competitors.
How does a people leader who still wants to prioritize the growth of his direct reports mitigate the downsides of delayering? Three approaches I’ve been taking are: (1) 1:1s every 2 weeks instead of weekly, (2) requesting weekly reports wins, planned work, & risks, (3) delegating more tactical mentoring to my most senior ICs. Approach 1 just accepts the reality of a limited number of hours in a day and a limited number of days in the week. My burning out would serve no one’s interest. I still maintain a weekly cadence for ICs where I have performance concerns, but a longer cadence for consistent strong performers still gives us both enough touch points beyond the usual scrum ceremonies for now. Approach 2 (not the stupid and deservedly panned “5 things” emails demanded of federal employees by Elon Musk) has enabled me to see and respond to risks more quickly—-and escalate them to my director if and when needed. They will also provide a great resource for performance management when it’s time to talk about the accomplishments of my directs in future review cycles. Approach 3 expands the scope of responsibilities for senior ICs from just an owner of technical scope, to an exemplar for less-senior teammates.
ICs in these delayered workplaces must consistently look beyond their managers to mitigate the downsides of this flatter organizational model. I’ve worked in tech long enough to remember very infrequent 1:1 time with my manager and having to make the case in writing for conferences I wanted to attend and training I wanted to take. Those relatively new to the tech industry will have to exercise the muscles of owning their professional development early and often now.
Whether we like it or not, the delayering of corporate America is changing the workplace in ways we don’t control. We still control our effort, and must mitigate the downsides of delayering so we can further grow ourselves professionally and those we work with. Regardless of the organizational design fads of the present, people matter. Professionalism matters. Treating people like they matter and being professional will outlast every trend.
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: twitter.com/lilykonin…
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.
- 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.
- 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.
- 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,
- 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.
- 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.
- 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.
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 www.reuters.com/world/us/republican-state-officials-threaten-legal-action-over-company-diversity-policies-2023-07-13/
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.