As I mentioned in my post about writing your self review, for many it's the season of performance reviews. I was recently part of a meeting where the process used at Personio was being explained, and it occurred to me that early in my career I had very little understanding about how the process worked at most companies. If I did, I probably might have approached it slightly differently, so for those who similarly don't know the process, let me offer some insights from my time in the technology industry.

Step 1: Self and Peer Reviews

This is the first stage beyond some kind of planning at the leadership level, and involves the most people, because it involves the entire company. Most companies give this a few weeks, but of course almost everyone leaves it until the minute.

In this stage, you're writing three types of review - a self review, a review of your manager (an upward review), and some number of peer reviews. This is also sometimes referred to as a 360 review.

Self review

In your self review, you write about your own achievements, as well as areas where you could possibly grown over the next 6/12 months. I've talked about it a good bit in the linked article so I won't dwell on it too much beyond reminding you that this isn't a place to be humble. You've presumably worked hard, make sure to celebrate your progress.

Upward reviews

The upward review is your chance to provide feedback about your manager. It is not always shared directly with manager, but could be. Instead it goes to your manager's manager. The questions will usually focus on how your manager is helping you with your career, leading your team and help you to achieve your goals.

Peer reviews

This is probably the most difficult part of the process - writing about your colleagues. I've two pieces of advice here.

First, be honest. I know it's tempting to embellish when talking about your co-workers, and there's a certain amount of selection bias in terms of who'll ask you to contribute a review, but there's a book called "Radical Candor" you can read which discusses the benefits of being direct and honest in feedback.

Secondly, don't expect to respond to all of them. Depending on the size of your company, you may well get several requests, and you won't get to them all. If you have, you've likely not invested enough time in each of them to give good feedback.

Instead, what you want to do is prioritise them. Consider who you've worked closest with, what projects you worked on together, and whether you have meaningful feedback. Order the requests from most impactful to least, then allocate some time for yourself and get as many as you can done in that timeframe.

For what it's worth, I tell my teams they should respond to no more than three requests and politely decline the rest.

Step 2: Manager reviews

Well if you're an individual contributor, the good news is that you're pretty much done with performance reviews now. At least until the very end anyway.

This stage of the process involves all the people managers taking the peer reviews, your self review, and their own thoughts and distilling it down into a single review, along with a provisional rating. If you're being considered for promotion, they'll also likely flag this with leadership at this point.

Depending on the organisation, your manager might discuss the review with you now, but more often than not they won't, because it's not final and there is very little worse in a performance review process than a surprise for the person getting reviewed.

Step 3: Calibration

Good organisations strive to run a fair process, where everyone at an equal level is treated the same, meaning that an engineer on the mobile team gets assessed the same as an engineer on the databases team.

The primary way this is achieved is through "calibrations". Calibrations involve all the managers in a given department/squad/group pool their reviews and compare them. The managers will have meetings, where they have discussions like - "Oh I see here you gave Susie an exceeds rating for X. I gave John on my team a meets rating for similar work. Could you explain your thinking, because one of us must be wrong".

The idea is that at the end of this process, everyone gets equal reward for equal work, because the whole point is to minimise bias. It's not perfect at it, but it's basically the performance management version of the software principle that "with enough eyes, all bugs are shallow". So once all the calibrations occur, ratings go up the org chart until they hit the leadership team, usually pretty aggregated, then those ratings are confirmed and filtered back down.

Having said that, this is also usually the stage where the idea of a "forced curve" starts to be discussed. If you're unfamiliar with this, it's the process whereby someone in leadership starts to question if a given group has "enough" people at each rating level, and suggests that maybe someone needs to be dropped down a level. If it's an actual forced curve, managers will be given allocations. So say your team has ten people on it, then some percentage of the team will have to get the lowest grade possible, regardless of their performance.

Most technology companies nowadays will tell you they don't do a forced curve, but most will have a performance curve they expect, and if a large enough cohort doesn't match that curve, they're going to start tweaking the ratings until it does.

Step 4: Final changes to your review

It's rare that the review packet your manager wrote going into calibration will be exactly the same as the one coming out of the calibration. Sure, the level they recommended might be the same, but there's a chance that after seeing some feedback from other managers, they've refined their own thoughts about your review.

So at this stage, they'll probably tweak and redraft the review, but as I said, the final rating is locked. This is all about how they convey your review to you.

Step 5: Delivering the review

This is the point where individual contributors come back into the process, because it's also the point where you find out how you've done.

This stage almost always consists of a 1:1 meeting. In fact if it doesn't, something's probably gone really wrong. In this meeting, your manager will share the results of your review with you. That review should have a section about past performance, a discussion of areas for growth (and how the organisation will help you with that growth), and finally the actual rating, which is usually somewhere on a scale from "you are not doing anything expected" to "you are vastly exceeding our expectations".

The impact of this rating can vary from company to company, but it's pretty standard for it to have a financial rating like a better pay rise, or larger bonus, plus it also gives another data point for demonstrating a trajectory towards promotion.

Speaking of promotions, this is also usually where you'll find out if you've gotten a promotion, as most companies pretty logically tie promotions to outstanding performance at your current or next level, which has just been reviewed, so they have all the relevant data fresh.

And that's it for performance reviews. Congratulations, because if you've gotten to this point in the process, you're done for another cycle. And in the next cycle, something will likely change about that process. I don't know why, but performance cycles seem to be one thing that folks in organisations like to fiddle with, and they're also usually universally dreaded by ICs and Leaders alike, which is kind of a shame, because they're important to your growth. But I don't know of any organisation that has this process perfect. Hence I guess the constant tweaking. Maybe the next iteration we'll get it right. Right?

Yep, Apple’s breaking iPhone web apps in the EU

Apple says web apps from third-party browsers are a security risk.

The Verge

Emma Roth writing for The Verge -

Apple is officially axing support for progressive web apps for iPhone users located in the European Union. While web apps have been broken for EU users in every iOS 17.4 beta so far, Apple has now confirmed that this is a feature, not a bug.

Apple relationship with the EU, particularly in regards to iOS, is truly becoming one of malicious compliance.

Posting to Instagram, Mark Zuckerberg gives his thoughts on the Vision Pro. I haven’t used it myself, so I can’t really say whether his comments are fair, but for me what’s notable is that this is possibly the most authentic bit of content Zuck has put out in quite some time.

Like look, clearly he didn’t post it on a whim and there’s a certain amount of post production happening, but when I say authentic I’m talking about how he’s just a tech nerd offering his thoughts, pretty unvarnished, and it makes me nostalgic for my time at Facebook, when Mark would do a weekly Q&A with the company and give his thoughts on the industry news of the week.

I don’t recall a single significant leak from those meetings during my time and I can promise he was very frank and honest during them. I’ve heard the tone has changed significantly since those days, which is a shame cause he frequently offered some real insights.

I think those meetings had a real impact on me professionally, and to this day I still try to prioritise work with people who are much smarter than me.

Apple won’t be forced to open up iMessage by EU

The DMA’s interoperability requirement won’t apply.

The Verge

I'm sure this decision may surprise some folks in the US, but it's entirely consistent with my experience of iMessage as a European.

In the US, iMessage would appear to have damn near a stranglehold on instant message, to the point where "green bubble" is derogatory term used to describe someone who doesn't use it. As if people needed another way to exclude others.

Compare that to Europe where I honestly don't know a single person who relies on it day to day. Looking at my message inbox, I have only one message in it that uses iMessage. Everything else is SMS, and they're almost exclusively marketing messages, or systems like PagerDuty. WhatsApp is where almost all my personal messaging happens, and as far as I know, that's the experience of every european adult I've met.

The Digital Markets Act is far from perfect, but it exists to prevent large players from abusing their market position, and in the EU, when it comes to the messaging space, not only is iMessage not a monopoly, it's not even an afterthought.

It's February, which means that for many technology companies, you're either just starting or well into the first performance review cycle of the year. This brings self-reviews, peer reviews, and promotion packets. I've worked everywhere from tiny startups to some of the largest companies in the industry, and there's a relatively common theme. People dread performance review season.

Despite the universal sense of dread associated with performance reviews, these processes are integral to working at a company of any significant size. Therefore, it's crucial for everyone, both managers and individual contributors, to understand the process. In this article I share some of the tips that I've given to my various teams over the years, and used myself.

Before we start, let's dispel one myth. These processes are not 100% objective. Most managers would prefer them to be, if only to reduce the number of meetings and paperwork involved, but the reality is that humans wrote the guidelines, humans run the process, and humans decide on the outputs, so there will be some amount of bias.

Tell a story

Given that almost all performance reviews are about more than an objective review of metrics, at some point, someone in the process will be telling a story about you. In the case of a self review, that someone will be you, but it could also be your direct manager, but either way, there's a story to be told, so treat it as such.

The story you're trying to sell is that you have had a productive quarter/year/whatever, and you're a valuable member of the team. The STAR method is traditionally recommended for answering interview questions, but can also be valuable when crafting your story. Managers writing reviews for their teams can also rely on frameworks like "Situation. Behaviour. Impact." to help with the narrative.

The other thing to remember is that a self review of your performance is not a place for humility. You've hopefully got some great wins, and now is the time to be proud of them.

Track your achievements

A frequent problem with performance reviews is recency bias. When you sit down in front of a blank screen and start to write out your achievements, of course you'll better remember what happened last week instead of what happened six months ago.

One way to counteract this is to write a brag document. There's a lot of excellent detail in that link, but the short version is that every week you should write down your big wins and areas to work on. Maybe you unblocked a team mate, or shipped a feature, or got traction on a project. Doesn't matter, write it down.

Then, when months later you go to start writing your performance review, you suddenly have a wealth of material from which to draw from. Now the amazing win you had months ago isn't lost, it's there in your review. A brag document also helps you identify things you're struggling with over time, and hopefully correct them before review season.

Understand your impact

Every company and department has a way of talking about impact. If you work in Sales, that's almost certainly deals closed or revenue generated. If you work in Product Management, maybe that's features shipped and the speed in which that happened. If you work in Infrastructure, maybe it's users served, load time or lowering the cost of your infra.

If your company is in anyway organised around performance, they likely have a document outlining what's expected at each level. It's called different things at different companies, but it's probably one of "Career path", "Signal matrix", "Expectations grid", or "Levels document".

Whatever it is for you, find that document and weave it throughout your story. Doing this will allow leaders who are removed from your day to day work to quantify your impact and compare it to others in the company. It's important to combine the language from this, with the current focus of the company. An L5 might be expected to "independently ship code", but your company might currently be obsessed with "reducing page load time". So make sure to talk about how the code you "independently shipped" also "reduced the load time".

To show you what I mean, consider these examples

In Q4 2023, I shipped 24 pull requests against the widgets product, removing 2,000 lines of code from the codebase and adding 24 new tests

versus

In Q4 2023, I shipped 3 new features. I did it while making the codebase smaller and easier to debug, plus I made sure I code coverage stayed above 90%, leading to less downtime in the Widgets product.

Tell basically say the same thing, but the story they tell is very different. The first is just a recitation of metrics that might mean something to someone with context, but the latter makes sense to folks across the company, technical or otherwise.

Be proactive about feedback

One big part of telling a story, is having other opinions that validate your own. This is usually achieved through peer reviews, which is a fancy way of saying "how your co-workers think you're doing".

But at review time, lots of people are sending and receiving requests for this kind of feedback, to the point where many companies dictate a maximum number of peer reviews to avoid overloading the organisation.

This means that you might not get the input of people who you've worked closest with, and even if you do, they're writing so many of these that they might not include everything they should. And there's the recency bias we spoke about.

To counteract this, you should be proactive about getting feedback. Don't wait until review season, incorporate it into your brag document writing by asking colleagues for feedback as you're updating it. Then you can ask for targeted feedback.

Consider these two requests for feedback

Hey Jane, It's review season. Earlier this quarter we worked together on Project Raven. Any feedback you had would be appreciated!

versus

Hey Jane, since it's fresh in your mind, if you had any feedback on the planning session I ran for Project Raven this week, I'd appreciate it. Specifically I'm looking to get better at how I run these meetings, so any advice you have there would be great.

The first example is sent weeks/months ago, and is pretty vague, which makes it hard for your colleague to provide concrete feedback. The latter one is timely, clarifies the request you're making by asking for specific feedback, and is therefore much easier to respond to.

You should be able to show your data

Whilst it's important to write a concise narrative, it's also important to have the data to back it up. In the example above, I would make sure to have links to some PRs, details of the test coverage, graphs of the uptime for the product etc.

You don't need to include them in the actual performance document, but have them to hand for yourself.

Think of it as "Trust, but verify". Most people might not ask for it, but it's good to have handy, and it shows you're prepared when you do.

For promotions, hold yourself to the bar you're aiming for

When you're going for promotion, one thing I've seen people do over and over again when writing their review is to focus on how they're exceeding at their current level. That's obviously important, but for a promotion, I think it's more important to tell the story of how you're already meeting the expectations for the level above. It creates a narrative where of course you should be promoted as they're only recognising what's already happening. And in the case where you don't get the promotion, you're setting yourself up for a really strong rating at your current level, as well as demonstrating a pattern of achievement, which will help land that promotion at the next review.

Keep a copy for yourself

One last suggestion I have, subject to your company's policies, is to always keep a copy of your performance review documentation. Your self review, your peer reviews, your actual performance review from your manager, it's all important to keep a record of. And I don't mean "Oh I can get that anytime from the HR system", I'm talking about a copy somewhere you access them after you leave that company, like your Google drive, or even just emailing it to yourself.

It's unfortunately all too common these days for people to lose access to company systems without notice, and these documents will contain concrete examples of your impact which will help you understand your trajectory, prepare for interviews, identify growth opportunities, and more, so it's really just good practice to keep them safe and to hand. You'll never know when you might need them.

One of the big winners from this years Consumer Electronics Show (CES) was the Rabbit R1, a handheld device that uses AI to automate tasks like playing music and booking travel.

But as I read more about how it works under the hood, I learned they don’t use the LLMs we’ve all become familiar with from ChatGPT and Github copilot, but instead rely on what they’re calling Large Action Models, or LAMs for short.

Essentially they train the model by performing a task like booking an Airbnb, then the model can replicate the task based on the training data, using I assume some kind of headless browser.

And when I saw this, my mind immediately went to “surely you could use this for QA”. Train the model once using your happy path, then give it all your test cases as prompts. and funnily enough, in this scenario, one of the bigger flaws in LLMs know as hallucinations (basically making up stuff), could actually be a strength because it will start to use your software in unexpected ways.

Of course, this could end up being more noise than signal, but it's interesting to see the continued application of LLM style technology and considering how it applies to software development.

As someone who’s been in the trenches of hiring for several years, I’ve seen the recruitment landscape as a hiring manager, an interviewer, and as a candidate. One recurring theme in this journey is encountering fantastic candidates and not being able to extend an offer due to limited headcount. It’s a tough pill to swallow, both for the hiring manager and the hopeful candidate.

In these instances, it’s not a reflection of the candidate’s abilities or potential. Rather, it’s a stark reminder of the practical limitations and constraints within which we operate. Budgets, team sizes, and project scopes can shift, often leaving us with difficult decisions.

Another aspect of hiring that’s often overlooked is when we bring someone on board, and it doesn’t work out. This can happen for various reasons – sometimes, it’s a mismatch in skills, but more often than not, it’s about fit. Fit with the team, fit with the company culture, or fit with the role itself. It’s important to recognize that the interview process, no matter how thorough, isn’t infallible. It’s a snapshot, a brief glimpse into a candidate’s capabilities and how they might align with a role.

This brings me to a crucial point for those in the #opentowork crowd: the imperfection of the interview process. If hiring were an exact science, layoffs and let-goes would be non-existent. But that’s not the case. The process is fraught with variables, subjective judgments, and sometimes, just plain luck.

If you find yourself missing out on an opportunity, it’s essential to remember that it might not be about you. Sure, it’s a competitive market, and yes, there’s always room to grow and improve. But often, the reason you didn’t get the job could be as simple as the company reaching its hiring limits or the process failing to capture your true potential.

This is not to say that you should brush off every rejection with a shrug. Reflect on your interviews, gather feedback if you can, and always look for ways to improve. But also, know that your worth and capabilities extend far beyond the confines of an interview process.

In closing, to all those navigating the tricky waters of job hunting: keep your chin up. Your value isn’t defined by a job offer or a rejection email. It’s defined by the skills you bring to the table, the experiences you’ve accumulated, and the unique perspective you offer. Stay persistent, stay positive, and remember that the right opportunity will come along – it’s just a matter of time and fit.

As Halloween decorations start to be put up in various places around the world, many folks are setting their various online identities to “spooky” names like JenniFear or Lucyfer and it always reminds me of my favourite incident of unintended behaviour in software - specifically, the Legend of Ghoulian Brophy.

One year at Slack (the company) everyone got really into this meme of spooky names and loads of staff updated their internal display names on Slack (the product) to something spooky. We had a good laugh about it and thought nothing more of it.

But what of the unintended behaviour? Well, at that point in Slack the company’s life, your Slack profile was considered a system of record for a lot of internal systems. Including…our billing systems. For context, at Slack, you’re generally one of two customer types. Self-serve (so like you pay with a credit card), or managed (so you purchase Slack via a Salesperson, you get an invoice etc).

These invoices would be sent out via email and would include friendly notes along the lines of “For more information, contact your dedicated Slack account manager Jane Doe”.

But where was that name pulled from? You guessed it, the relevant Account Manager’s Slack profile. Which meant, for a few glorious days, Slack (a multibillion dollar company by then) was issuing invoices, for hundreds of thousands (if not millions) of dollars, encouraging customers to contact people like “Ghoulian Brophy”.

Stressful and embarrassing for our customer facing teams? No doubt. Utterly hilarious for the rest of us? You know it. So remember kids, make sure you know what your systems of record are, lest you become part of the legend of Ghoulian Brophy.

In further proof that you’re never too old to learn a new trick, I was reading about the new Spotify TypeScript SDK, and amongst the various code snippets was this:

const items = await api.search("The Beatles", ["artist"]);

console.table(items.artists.items.map((item) => ({
    name: item.name,
    followers: item.followers.total,
    popularity: item.popularity,
})));

Like many, I’ve been using console.log() for years, but I’d never heard of console.table(). Turns out you can pass it an array of objects, and it’ll render them as a table in the console. Whilst the Spotify example goes further and runs a map() over the array to extract the properties it wants to display, you can just pass the array directly to console.table() and it’ll render the whole thing.

That would have been handy to know a few years ago, but better late than never!

Here’s the MDN docs if you want to learn more.

Salesforce Tells Employees It Will Donate $10 Per Day to Charity if They Come Back to the Office

Salesforce co-CEO Marc Benioff has complained about loss of office culture due to WFH, though some workers have reportedly said layoffs hurt that culture more.

GizmodoThe A.V. Club

Kyle Barr, writing for Gizmodo:

Salesforce confirmed with Gizmodo that the company was hosting a global program to incentivize workers to come into the office, called “Connect for Good.” Fortune originally reported Tuesday based on an internal Slack channel that each employee who decides to actually come to the office between June 12 and 23 will make Salesforce donate $10 to a local charity.

Honestly, it’s hard to see this as anything other than emotional blackmail to get people back into the office, an initiative which clearly isn’t working out as Salesforce leadership had hoped.

Consider this reported quote from a Salesforce executive in their Slack instance:

“By showing up in the office (or for events), you’re strengthening connections and creating a positive wave of change in your community,” the senior executive wrote. “Are you ready to make a real impact by simply showing up?”

RTO is a solution desperately looking for a problem, but if you want to force people back into the office, at least be honest about it and not try to hide behind a veneer of corporate philanthropy.

Home | Spotify for Developers

Spotify for Developers

Just a delightful little bit of Developer Experience from the Spotify Developer Relations Team. Simple and to the point.

Demonstrates four different things you can do with the API, and combines them to also demonstrate how you can use them together for a practical benefit.

Just perfect, no tweaking needed. Everyone there should be proud of this.

SVB Races to Prevent Bank Run as Funds Advise Pulling Cash

Unease is spreading across the financial world as concerns about the stability of Silicon Valley Bank prompt prominent venture capitalists including Peter Thiel’s Founders Fund to advise startups to withdraw their money.

BloombergKatie Roof

Katie Roof, Hannah Miller, Gillian Tan and Priya Anand writing for Bloomberg:

Unease is spreading across the financial world as concerns about the stability of Silicon Valley Bank prompt prominent venture capitalists including Peter Thiel’s Founders Fund to advise startups to withdraw their money.

You have to imagine that on the streets of Palo Alto this morning, it feels a bit like Bedford Falls. The only question is, will Silicon Valley’s modern day Mr. Potter try to buy up more of the town?

People, and the media in particular, seemed to think that after Twitter did the first round of mass layoffs, that it would just…stop working.

That clearly hasn’t happened, and it was never a super realistic expectation. These systems are designed to be robust against “one big thing”.

What a large scale system like Twitter falling over looks like is exactly what we keep seeing, week after week. It’s failed image previews, timelines not refreshing, notifications not working, and so on. How many more times will it need to break in critical ways like this before we accept the narrative that there isn’t going to be a single moment where Twitter just stops working.

It’s going to be a slow, gradual decline, which someday will end in 404s or 500s, but the rot has already set in and it’s hard to see it coming back from it.

Access Denied - Work Chronicles

Work Chronicles is a light-hearted webcomic featuring funny, relatable and amusing tales from the modern-day office. Made with love & lots of coffee.

Work Chroniclesworkchronicles

This cartoon by Work Chronicles is I assume designed as light humour, but think how far we’ve fallen as an industry when it’s a reality for many that they will find out they are laid off when their access to the company’s systems is revoked.

It wasn’t all that long ago that it was considered disgraceful to announce layoffs over zoom. Now it’s done with Okta.

The Scoop #39: Changes in the tech job market

Also: a historic pushback on RTO at Amazon, Big Tech job-switching stats, and more.

The Pragmatic EngineerGergely Orosz

Gergely Orosz, writing for the Pragmatic Engineer newsletter:

Thanks to verbal assurances, several employees I talked with said that they thought their work location in the contract is not relevant. Well, with this change, people will need to report at their official workplace 3 times per week, starting May, which is not what many of them signed up for.

If there’s one thing to be taken away from this Amazon RTO situation from a individual perspective, it’s that when you’re signing a new employment contract, you need to assume the company will enforce every single clause in it. If the company didn’t want to enforce something, they wouldn’t have put it in the contract in the first place. If you doubt that, just ask them to insert some clause that you think is ridiculous but that you swear you’ll never enforce, and see what they say.

I recall a situation when Salesforce acquired Slack, and we were all being told to sign new contracts to make us Salesforce employees. There was a clause which stipulated that if the company decided to close operations for the Christmas / Holiday period, you wouldn’t be required to work, but said shutdown would be deducted from your time off allowance. I was of the position that it was up to me when to choose my time off, so I asked for it to be struck from the contract. Salesforce HR insisted that there was no way the clause would ever be enforced, but not a single one of them could give me a reason why it was in the contract in the first place. I dug my heels in, and eventually they agreed to remove it.

It was a minor thing, and I didn’t actually imagine them ever enforcing it, but as the Amazon situation shows, you can’t assume things like that.