https://blog.interviewing.io/how-much-have-2022-layoffs-affected-engineers-vs-other-departments-we-dug-into-the-data-to-find-out/
How to plan?
“This interview was for one of those jobs leading product and engineering which are coming back into vogue” - a good thing! But the article is about planning. And it’s one of these genuine articles, not one of those copied and pasted by someone without a clue that plaster the top of the Google search results. While I don’t agree with everything, I love the article.
https://kellanem.com/notes/how-to-plan
Brex layoffs
It is beyond me why everyone needs to publish their internal lay-off message on their blog. Isn’t this something between you and your employees? I’m not publishing my love letters, sorry. Every time I encounter this I think the employees left will feel a breach of trust reading details on a blog. Just as if one partner goes to the press and you’re damned to stay silent. At least this is presumably after the email was sent internally. I sometimes had to read news from outside to learn what was going on inside (For Germans: Handelsregister is your friend to learn about founders shifting around). Trust is hard to earn and easy to lose, so why do this? But this one is even worse (as are most) - it’s so wrong on many levels “Today is a difficult day for Brex.” no it’s a difficult day for those being laid off who fear their future. Why always the “we”? It was the CEO that made the decisions. If you screwed up, say so, and don’t use “we” everywhere to deflect the blame. Don’t whine “While impossibly hard”, think about those laid off. “We want to be as thoughtful as possible” who is “we”? “To those who are leaving: we are so grateful for the energy, ingenuity, and commitment you brought to the company. Brex wouldn’t be here without you.” - so we fired you, and close the door on the way out, thank you! I’d suggest not publishing such a post, and in the email, you wrote, don’t make it about how hard this is for you.
https://www.brex.com/journal/message-from-pedro
Self-healing systems for CTOs
Yours truly wrote an article myself about self-healing systems. The article’s main point is how they help the CTO save time and be able to focus on more important things than dealing with outages.
https://www.amazingcto.com/self-healing-for-cto-solo-founder/
How Equifax used employment records it collects from 2.5 million companies to fire dozens of its own employees for working second jobs
There is a paywall but I’m sure the is some kind of archive. “In one of the latest signs of corporate America trying to regain control of an increasingly remote workforce, CEO Mark Begor this week informed employees that some of their “teammates” were fired for having “a second full-time job while maintaining their full-time role at EFX,” which is the ticker symbol for Equifax.” With remote work going to stay this will touch every company. I’m sure there are already startups looking for funding for a business to find people with two jobs. Have you experienced someone already who had another job besides working in your department? (I have)
https://www.businessinsider.com/equifax-fires-employees-for-working-two-jobs-2022-10
Code Review Handbook
Most code reviews I have seen in startups and with coachees are determined by what the reviewer thinks they should look like, without the CTO giving some guidance. But you should give guidance, e.G., add security, otherwise, people will look for the wrong things (“I would have done this differently”). Here is a good start, a code review handbook.
https://www.sledgeworx.io/code-review-handbook/
(as the site seems Slashdotted, the archive link is https://web.archive.org/web/20221014021506/https://www.sledgeworx.io/code-review-handbook/)
Toyota Accidently Exposed A Secret Key Publicly On GitHub For Five Years
“The code was made public from December 2017 through September 2022. […] This incident adds Toyota to the list of companies that have had similar exposures; a list that includes Samsung, Nvidia, and Twitch […]”
My productivity system in 2022
A GTD - getting things done - a trainer who stopped using strict GTD “But the fact that I stopped teaching people how to do GTD – which obliged me to follow it strictly as well – opened up space to explore new ways to do things. […] So I adapted and changed and, eventually, ended up with my own version of a great productivity system.” The reasons why I’m skeptical of trainers, including you, Scrum trainer! They take money for things they don’t believe in.
https://www.nunodonato.com/my-productivity-system-in-2022/
The book that triggered my introduction this week is “Junior to Senior” by David Glassanos. There are many good points in it, and I would buy one for every junior on my team. It is a good guide - although a lot of what’s in the book should have been explained to the junior in 1:1s - you do have 1:1s that talk mostly about development and expectations, don’t you? I did like the chapter “What Makes You a Senior Engineer?” most, especially, because we do not have enough discussions around that topic.