Review Of The Performance Review

For context, it’s best to read my initial blog on this topic: Appraisals

Our review system basically involves us stating some salient things we have done, and we have to rate it against a few categories of values, and rate it 1-4, but we are only really allowed to score it a 3.

So my Performance Review is complete. To nobody’s surprise; I was scored a 3. My manager asked if I was surprised by the score, and I said I wasn’t because that is what everyone else would have got. She said that some people did get a 4. Not sure how; it doesn’t make sense to me.

I think if I went above my role, I’d expect push back from someone. Imagine waltzing into another department like Support with the aim of being “collaborative” – and start demanding changes. Then they are like “who the hell are you? Someone call security!”. If a development manager went in there and started demanding changes, then people would listen. In reality, they would organise a meeting, but their meeting would be accepted, and mine wouldn’t. The reason is that I’m just a developer and have no authority. Yet, if it did happen, I can then tick the boxes of Collaborative Working, Initiative, Innovation etc.

Even trying to take the lead on a project is a tough one. People’s job title’s give a natural hierarchy. When you have a designated Lead, then some Seniors, what chance does a Developer have at even running a meeting, never-mind designing some architecture? The only time it’s gonna happen if people are on annual leave for multiple days or have extended leave. Then you have to spot the opportunity, and take it.

In another meeting, I was talking to a different manager, and raised my concerns about the review process. He then told me that someone in the team got scored a 2.

How? If you read my previous blog on Appraisals, I mentioned how I tried to score myself a 2 for some areas, and I got rejected. If you talk about your score with your manager in your monthly 1-to-1 meetings, even if they did tell you that you have scored a 2 that month, then you will just step up your game, or write more justifications on the sheet to make sure it doesn’t happen again. Even if you did score 2 for 3 months or so, then are scored 3 for the final 9 months, surely your overall score would become 3 anyway? So how can you end up with a 2 unless you have consistently under-performed, done nothing to correct it, and even agreed with your manager that it is fine to be scored a 2? Surely no one in their right mind would do that.

The only reason I can think of is if the scoring hasn’t been consistently applied. Now if you read my previous blog on Appraisals, I mention that we have arrived at this current process with the aim that it is the fairest way of assessing someone, and would be consistently applied.

So let’s talk about the consistency.

Firstly, the goalposts were constantly moved during the year. We were told to fill out a basic spreadsheet, then a month later, new columns were added, then the criteria was changed, then we had to add a personal objective in addition to the default ones. Then there was an additional sheet to fill in. Then near the end of the year, someone told me the criteria had changed, but yet my line manager never told me that. So by the end of the year, some teams were using a different system.

Secondly, sometimes people with the same line manager as me told me extra tips, or about approaching deadlines, but my manager had somehow forgot to tell me about it.

Thirdly, we were initially told our final score mattered and there was no chance of promotion during the year. Then half-way in, an email comes in from HR saying how there is a Mid-Year mini review where some people will be promoted, and we had 3 weeks to submit our forms. However, that same day, we get an announcement from a manager in the department stating that 3 people had just been promoted…but yet they hadn’t completed their forms; the Mid-Year review hadn’t happened yet. For the Mid-Year review, I was struggling to finalise it, and my manager said I had till the end of the week, and she would submit what I had by Monday because it’s a hard deadline. On Monday, when the deadline had apparently passed, I overheard her say to someone else that they had until Wednesday.

Fourthly, even though I said we have monthly 1-to-1’s where we agree a monthly score for the items we submit, one member of my team said he hadn’t done that since the Mid-Year, and he had to cobble something together to submit for the End Of Year Review.

The thing is, because of the poor management of projects this year, there’s been many moments where I have been idle. When we have had requirements, they haven’t been clear and there hasn’t been great scope to actually shine. So if you compare my productivity to previous years, maybe you would give me a 2, rather than 3, but that’s not even really my fault.

I also think any metrics shouldn’t change people’s behaviour. However there was one time where I heard someone say something along the lines of “I have been investigating TechnologyX but it’s not really feasible.” Her colleague then said “so are you free to pick something else up?”, then she replied “no, I’m going to investigate it further so I can add more detail to my appraisal documents”.

In a similar fashion, there are plenty of times in the stand-ups where people say “today I am updating my documents” or “I am doing personal development”. The fact that people spend entire days updating a document instead of doing actual work – is a massive problem.

I also think people try and introduce ideas just so they can tick some boxes for innovation on their documents. I don’t see any reason why teams would switch from Code Build, to GitHub Actions, then Jenkins unless there is some extra personal incentive.

I think if the review system was consistently applied, was set-in-stone rather than constantly evolving, and we had no surprise deadlines spring up on us; then the review system would be acceptable. I feel like I can only give this system a 1 out of 4.

Hopefully it will be better next year.

Enforcing The Quality Process

If you find a bug, you are supposed to log it. Simple logic. However, people get annoyed when they log a bug, then the developer just tells them it’s a simple configuration option they have missed, or they don’t even have the latest version. It can take time filling in the Bug report, and it’s annoying when you have to almost instantly close it.

So then you get the attitude where people will rather email the problems, and hold off logging it until a developer confirms that it’s probably a valid bug. If the developer doesn’t actively check, then bugs can go unreported; which can be a disaster.

The other day, a Senior Tester posts a massive stack-trace in Slack. I have a quick look and realise it is a bug. As I was about to reply, another Senior Tester, (who is about to be promoted into some kind of Quality Process Manager or some nonsense; or maybe that is a rumour), tells him to repost it on Microsoft Teams. But not just one post, she wants it posted across two channels for “maximum reach”.

Or maybe maximum annoyance.

It’s really dumb, we have this process, and someone that is supposed to enforce the process – and definitely someone that will be enforcing the process in her new role – is coming out with nonsense like posting in informal channels.

If there is a Bug, then log it. It can always be closed with a valid explanation; which can help others in the future if the same problem crops up again.

Team Velocity

In Agile Development, you have a concept of Story Pointing and Team Velocity. Most people hate coming up with time estimates. If it is in hours, it is too specific, and then you feel under pressure to meet the exact timescales. With bigger work, it’s quite hard to measure things in days. The idea of Story Points is that you can just gauge items in comparison with each other, so you think about your smallest piece of work, then benchmark all other work against it.

Although teams may roughly have the same scale, and you could roughly map Points to days; the scale only truly makes sense within that team. So 5 points for Team Badger, may be a different size to 5 points by Team Snake.

The amount of Story Points you complete in a “Sprint” (often a 2 week period), becomes your Velocity. Well, the Velocity really makes sense as a moving average across multiple sprints, because in Sprint 1 you may go through 20 points, but Sprint 2 may achieve 35 points. If you analyse it, it may be because people understand the project and are working better together, so improved in the subsequent weeks.

We had a meeting today. One of the questions was

“What’s your team’s velocity? If you don’t have one – then pick a suitable number“.

A) What are we doing with these numbers? Comparing them between the 3 teams? It’s nonsensical.

B) It turns out people haven’t been working in this Agile style anyway, and haven’t Story Pointed their work. But if Velocity is a sum of completed work that has been estimated, how can you estimate how many points you have completed by estimating what you think your estimations would be?

I’m sure managers are getting dumber.

How To Assign A Bug

I was asked by Simon to check source control to see if there was an obvious cause of a problem reported by a customer. I looked through the code and couldn’t find anything that stood out.

I heard Simon talk on the phone and it sounded like it was an important issue. I asked him if this was high priority and he said it was.

So I did a bit more digging, then Colin came over. Simon had also asked Colin to look into it, and Colin said to me “don’t worry about it, I’ll look into it.” So I went back to my normal project work.

An hour or so later, I heard a tester talk about the issue. I was interested in how the situation was progressing, so I went over to ask them about it. He said he had just started looking into it, but wondered if I had recreated it yet. I tell him; “I’m not looking into it, Colin is”. Simon then says “you have to look into it, Colin’s manager won’t let him work on it”.

“What the hell? Why wasn’t I told?” I then asked if there was a work item with information about the bug. “No” replies Simon.

Back in my day, we were told that we couldn’t work on anything without a bug being logged. It makes sense, all information goes in the item, and then if you are off sick, another person can easily pick it up.

If there’s no bug report, how do I know what the problem is, or perceived to be? Anyway, I ask the tester, and he shows me a Slack conversation from Simon. If I was always supposed to be looking at this issue, why weren’t I added to this Slack conversation?

I begin setting up the data to try and recreate the issue, when Colin comes over. Even though he isn’t working on it, he wanted to give me some advice. He starts talking about a recent project that was completed. I ask:

“What are you on about? Is this relevant to this issue?”.

“Yes, it’s in the email thread”.

“What email thread?!”

So even though it was decided that Colin couldn’t look at this issue, he was involved in an email thread. The tester was involved in a Slack thread. I’m not involved in either of them.

Again, how can I be expected to recreate an issue, when I don’t know any of the details? Also, it is pretty urgent. There’s a call tomorrow with several people from other departments; support staff, important managers etc. I’m supposed to explain my theories of how this problem was introduced.

Absolute farcical.

Later on, I’m at a different manager’s desk, and he has an email open. It’s an email thread between a few managers discussing if Colin can look at the issue or not. It’s not just Colin’s line manager, but other important managers within the department.

So much time wasted trying to decide which person should do the work, meanwhile there’s no process that is followed to actually assign the work properly. It’s thrown between verbal, email and instant messaging.

How difficult is it to log the issue properly, then find a developer that is available to look into it? It’s not like we’ve never seen a bug before. What happened to the “tried and tested” process?

Full Regression

Several months ago, a project was completed (let’s call it Project X) that must have contained the biggest impact to our software. What I mean is that the scope impacted a lot of features, and therefore to sign it off, the testers ran an insane amount of regression tests. The Project X team ended up running these tests with the help of other teams, and many hours of overtime was needed.

A release was being planned that involved more bug fixes than usual. I think one of the Test Managers had suggested that we run a full regression test to ensure the changes made by Project X hadn’t been effected. Marcus, a tester involved in Project X stated that this was an “unreasonable request, and we need to do a more focussed, targeted test”.

The next day, a Test Manager came up to Marcus and said she had asked someone to give estimates of a full regression and she had been quoted 6 weeks. She said it was absurd and wanted Marcus to confirm it. Marcus stated once more that he had already highlighted it was an unreasonable ask. He explained that she is requesting that 4 people run the tests over a two week period, when the original team had three weeks and around 20 people were involved. This is why Marcus rejected the proposal in the first place.

Another day passes, and another Test Manager announces that, after much debate – running a full regression isn’t feasible, so they will do a targeted regression.

No doubt there were one or more meetings to discuss this, when Marcus had already told them how unfeasible it was a couple of days earlier. It’s just that people with the authority to make the decisions, and the people that actually have the knowledge of how things work – are completely different people.

Manager Step Down

Our team was initially managed by Jane. A few weeks into the project, Jane explained to a colleague that she was leaving the team. Only when she noticed I was eavesdropping did she then tell us that I probably need to listen too. She told us which team she was moving to but she didn’t even give a date when this would happen. I thought it was bizarre that she announces it so casually rather than having a formal meeting.

The next day, when we were on a conference call with some remote workers, they were waiting for her to join and didn’t want to start the meeting without her. Jane did join on request, but she still didn’t tell them she wasn’t in charge, or even had left the team.

Afterwards, a team member in our office was outraged about it, because he wasn’t aware. She claimed it wasn’t her responsibility to tell people; the responsibility should fall with the new manager, Adam.

I’m thinking it totally is her responsibility. Adam shouldn’t just state he is in charge now – it should be announced by Jane, who then explains we need to listen to the new guy. It wouldn’t be her responsibility to hand over if she had been fired; only then you would expect the new guy to announce he is in charge, or someone further up the hierarchy to announce and introduce the new manager.

The funny thing is, months later, Adam suddenly leaves the business. His replacement started joining the stand-ups but didn’t speak for a few days, didn’t even introduce himself. When he finally introduced himself on the fourth day, he then had the awkward task of telling us Adam’s last day is today and will leave after he completes his handover.

Innovation Day

Every so often, people raise the idea of tech companies having an Innovation Day. So maybe every Friday, people can put down their usual work, and do a personal project instead; maybe using a language they aren’t familiar with. Sometimes we have explored this idea, but usually just for one or two days.

I’m always skeptical, because I often find fixing a bug, or making a simple feature will take a day or two, often even longer. To expect some kind of prototype in such a limited time always seems an impossible ask to me.

Recently, a group of people have been allowed to have a full Innovation Day each week. I was speaking to one of the guys and he was saying that they plan to stop it since one day a week isn’t enough time. A month quickly goes by and that’s only 4 days work.

When the innovation is supposed to be meaningful and integrated into new projects, these new projects will have come a long way and then it’s awkward to utilise it. Recently there have been projects that have been scrapped or required a major overhaul because of ideas that have either come out of the Innovation Day, or by some idea someone suddenly had. The earlier people know about requirements, the easier it is to integrate into the project. Trying to implement it later is hard, or even impossible; so the project gets scrapped and they all start again.

Another problem with just having a single day is that you could book that day off as annual leave, or maybe you are ill. If it is a team thing, what happens if someone has the day off and you end up being on your own?

Anyway, I was low on work, so thought I’d pay a visit to a particular pair of developers that were working on a feature relevant to my project. Turns out one of them was ill, and one of them had some important meetings in the morning so would be a few hours late.

Anyway, I end up meeting him and we had problems getting the previous week’s changes to build. There were quite a few people missing from the overall group too, and some developers seemed to take an overly long lunch break – like 1.5 hours. Then when they did return, they ended up switching conversation between work and banter, so much so; that I reckon they only were productive half the afternoon.

So how much benefit can a day a week really be? It’s seems unreasonable to expect zero complications and 100% efficiency, so it seems a waste of time.

I was speaking to another colleague about the Innovation Day and he was surprised that it was limited to a select group of people. He said entire teams should be innovating so they buy in to the ideas, rather than someone else saying “I did this in the Innovation Day, so your team should do it too”. It also links back to the comments on time; that you don’t want a team to have got so far into the project, then be told to rewrite it with a different style architecture.

Slack inconsistencies

Recently, we started using Slack due to someone waxing lyrical about how all the cool tech companies are using it. Here are my top things I hate about how my colleagues use Slack:

1. Inconsistent use of threads

When we used Microsoft Teams, people were mocked when they posted a brand new message instead of replying to the previous one. However, even though it’s the same people using it, replying to a message seems to be uncool in Slack, and it seems encouraged to post a brand new message even though you are referring to a previous post. This causes people to act all irrationally, because then they get confused if they should either simply post, @ the person, reply and repost etc.

When you get two questions in a short space of time, people have no choice but to “create a thread”. This gets confusing because part of the conversation then appears as replies, but the start of the conversation were separate messages. Sometimes people still won’t start a thread, then just keep @’ing them instead.

When you want to find previous conversations, you end up having to scroll through all that crap which may have been a conversation between 2 people and no one else cared. If it was a thread, it would just be collapsed into one message.

There is also a Thread section which shows you threads you are involved in, but then they are incomplete because people’s inconsistent use of threads, so that feature is frustratingly useless.

2. Going off on a tangent of memes

People seem to see Slack as a casual way of communicating. Maybe because it has the name “Slack” which doesn’t sound as corporate as Teams or Skype. The level of professionalism dips to the point that people are just replying with a GIF, then someone else replies with another GIF. Maybe the GIF had some relevance, but the reply would probably just be a GIF that the person liked. Maybe they didn’t understand why the first GIF was chosen and thought it was a great opportunity to reply with a cute cat. Sometimes you have gone so far off on a tangent, you don’t even know what triggered a response

3. Replying to yourself multiple times like its some kind of instant messenger client and you think you need a second by second update about what you are doing

People seem to view Slack as an Instant Messaging client, whereas with Teams they viewed it as a Message Board. People tended to write longer messages on Teams, and if they needed to post some additional information, they tended to edit the original post.

Since Slack is perceived as Instant Messaging, people often post quick messages one after another, so it’s like:

Tim: “Can you give me access to this repository”

Mark: “Hang on”

Mark: “You should have access now”

Mark: <thumbs up emoji>

Tim: I have access now

Tim: thanks mate

4. replying to a thread but also posting it to the channel even though no one cares

This is very much like point 1, but I think it deserves a special mention. Sometimes a thread has formed and may have several replies in it. I am happy, several people are using the software as it is designed. Then boom! Someone comes in with a basic comment like “I agree with this” and then they tick the box to repost it to the channel. It’s like they think their opinion is so important, they have to make sure everyone sees it.

5. Too many channels.

We have so many channels, many teams have a private channel just for them, and a separaate channel for outsiders to ask questions. Some teams even have a third channel where only bots post the main content. They link it up with GitHub so that any Pull Request or Issues are just reposted to the channel. I guess they have disabled their email alerts and prefer to get the messages in Slack. Often, people go into the channel then say “@here ^” to cause an alert to everyone to check it. Surely the Slack channel was created to avoid the email alerts, then people are replacing them with a Slack alert.

6. people using @channel @here as it if it is important

That brings me onto the next point, people using @channel and @here tags. Normal messages give you an unread notification, @ tags give you a desktop alert like it’s important.

@everyone notifies every person in the #general channel

@here notifies only the active members of a channel

@channel notifies all members of a channel, active or not

If you look at Slack’s official documentation https://get.slack.help/hc/en-us/articles/202009646-Notify-a-channel-or-workspace, they say “We suggest using @here, @channel, and @everyone sparingly.”

An example when to use them:

@everyone – Alert everyone in the company about the emergency evacuation drill.

@here – You’re locked out of the office and need help from someone already at work.

@channel – Update a project team’s channel about a last-minute change in deadlines.

But people use them daily. It’s like “@channel can you tell me where I can find the specification”, “@here can you tell me who knows most about automated testing?”. I end up “muting” most channels to prevent these alerts from showing. It is never that important.

7. You can only have 15 participants on a conference call.

Most teams only contain several members, so team calls are usually fine. Recently, teams have been doing demos, or individuals have been attempting to share their knowledge via a live tutorial; and we have hit the limit. Even when people know there’s gonna be more than 15 participants, they will still host the call on Slack. Why? Because Slack is what the cool kids use. What you gonna do? Post messages in Slack asking the presenter to record it? Slack doesn’t have that feature. Here’s a GIF of a child crying.

Appraisals

We have tried different ways of appraising developer’s performance, but I think it’s pretty impossible to measure. As my Lead Developer always says: “you get what you measure”. For example, you wouldn’t want to measure someone by Lines of Code because this will lead to verbose, inefficient solutions, and would encourage bugs because then the developer can write even more code to fix it. You won’t want to measure by Code Coverage of tests, because you can achieve 100% Code Coverage, but still have bugs in your code.

We have tried teams filling in a form to give feedback to their peers. This was deemed unfair because people didn’t like saying negative things about others, and it wasn’t beneficial praising colleagues because you were competing with them.

We have tried just leaving it up to Managers to put people forward when they perceive them to be doing well. This was deemed unfair because some managers would be more vocal or lenient than others.

We are trying another form filling task, but you write about your salient experiences, then come up with a score 1-4. When I looked at the scoring system, I felt you couldn’t put the highest score without justification that your actions were way above and beyond your role. I thought that no one will put the lowest score because it’s supposed to be a form that highlights your abilities, not weaknesses. So I ended up putting 3 next to the really good ones, and 2 next to the decent ones.

Anyway, I was discussing my form with my manager, and they said to me that we can’t submit scores of 2 because that means I am under-performing. My options were to either change them to a 3 and submit them, or just remove them from the form.

Then I thought “hang on, we score them 1-4, but are only allowed to score them a 3”. Okay, maybe a 4 at a push, but still, that’s only two options.

I’d imagine they wouldn’t want to read everyone’s forms; they just want an overall rating. So they would just add up the scores and come up with an average; then use this value to compare people. But everyone in the company will have a rating of 3. So how do you know who is performing well, or who is under-performing? Well, you would have to read all the texts! Which is what the scoring system aimed to avoid.

I reckon when they had a meeting to come up with this ridiculous proposal, it would have gone like this following scene from the absurdist comedy “Nathan Barley”. There’s a meeting to brainstorm new ideas for their magazine.

Note: Dan is the only level-headed one, and he thinks he is working with a team of idiots (which obviously they are).

Rufus: We should give Nathan Barley a column.
Ned: Yeah, we should give Nathan Barley a column.
Rufus: Yeah like call it…”Nathan Barley’s Column”?
Ned: Hey, let’s just call it “Barley”, yeah.
Rufus: Yeah, man, or like “Nathan”.
Ned: Yeah, cause like, that could be like two columns.
Dan: (in disbelief) Two columns?
Rufus: Yeah, and like maybe one would be better than the other one.
Ned: Yeah, yeah, and you’d only read the good one.
Dan: How would you tell which one was the good one?
Ned: Check ’em out. Direct comparison.
Rufus: Like, you’d read them both to find out which is the best one.
Ned: Yeah, and then you’d just read the good one.
Dan: Are we gonna’ do this?
Jonatton: OK.

Or in my case:

Rufus: We could give the employees forms to fill out and they score themselves 1-4 Ned: But you are only allowed to score yourself a 3
Dan: How would you tell which employees are the good ones?
Rufus: Like, you’d read all the forms to find out who are the best staff.
Ned: Yeah, and then you’d just promote the good ones.
Dan: Are we gonna’ do this?
Jonatton: OK.

Innovation

Recently, we were told about a culture change to one of innovation. Our new philosophy is that people need to explore different technologies to work out which ones would benefit the company.

When investing time into this research and coming up with a prototype, obviously many experiments won’t bear fruit. As long as we document our thoughts; why the technology isn’t suitable, what scenarios it could be suitable etc., then it won’t be a waste of time, because we have learnt from it and educated others.

One team did a presentation on cloud computing, and the differences in performance when it comes to running severless functions. They reported that using languages such as Java and C# will be a poor choice due to “cold starts”. Better languages would be Go or Python that have a speed benefit. See Cold Start Comparisons for comparison tables and charts.

When the time came around to do more presentations, a different team talked about severless functions and how they encountered a problem called “Cold Start”. I was face-palming. What’s the point in these presentations if teams aren’t gonna listen to each other? Sharing knowledge and learning from each others mistakes or findings make teams progress quicker. It’s a waste of time repeating what other teams have already done.

Anyway, when the next presentations came about, we were all eager to hear about something different. But up stepped a team to talk about severless functions. The presenter explained that they knew about the “cold start” problem due to the other presentations over the previous months, but they wanted to witness it for themselves rather than just go by what they were told. I couldn’t believe it; why wouldn’t they invest their time in something new, and then come up with a presentation that people can learn from. Just churning out the same content was a waste of everyone’s time.

This week, I overheard a couple of developers talking about their experiences with severless functions.

“I’m finding Go really difficult to code in, so I might just use C# instead”
“What about the cold starts?”
“Well, it will be Microsoft’s priority to fix it, so by the time our code goes live, it probably won’t be a problem”

There are many programming languages around, and they are created for a purpose. As a developer, you need to use the correct tool for the job, and shouldn’t just use a language just because you are familiar with it. If you look at the findings in Cold Start Comparisons, maybe Microsoft could improve efficiency slightly to Java levels, but surely you can’t expect Python performance. It’s a completely different style of language. Also, it’s a bit of a gamble hoping that performance will improve by the time you rely on it.