Colin As Manager

It’s been a long time since I wrote about Colin, a pretty incompetent software developer that seemed to be good friends with one of the high-ranking managers that seemed to lead to some bizarre promotions: to Senior Developer, to Principal Developer, then eventually switching to a managerial role. Talk about failing upwards.

The thing is, he came across as a bit scatter-brained so couldn’t imagine him actually being a good manager.

Here are some random stories I found from my notes and chat logs about how he performed as a manager.

Salary

Mike said Colin began sharing his screen on a meeting, and had a list of salary changes in a spreadsheet. Interesting how they have salaries lined up BEFORE the reviews which we haven’t had. Just as I have previously suspected. I suppose other managers have messed up in the past when a promotion was announced a week prior to the performance reviews.

I can imagine Colin eventually getting sacked for that type of mistake. It’s classic Colin, and as I predicted, the mistake did happen again a few months later. This time at a meeting I was involved in. We were trying to hire new developers for Colin’s teams. Colin was sharing his screen and had a list of employees that were leaving and their salaries.

When it came to my reviews, Colin kept on saying I was doing a great job but then pointing out one thing that was holding me back. It always seemed like an excuse to not give me more money or promote me. When I did switch managers, my new manager promoted me within a few months and gave me a £14k raise due to how behind I was compared to my peers.

Arranging Meetings

Colin often arranged meetings then didn’t turn up, or turned up late. He was constantly saying he was busy all day with meetings so sometimes scheduled meetings at bizarre times.

I was particularly annoyed when he arranged a weekly update meeting during lunchtimes, then half of the time doesn’t even show up. The update was mainly for him to collate info then take it to his manager, but he said we had to give our updates to the other teams, much like an Agile Scrum of Scrums meeting. So regardless if he was there, he went ahead.

There were some other meetings which he arranged, and where he was an important attendee and he turned up 25 mins late.

One time, I was about to leave for the day, and Colin said he had an end of year review meeting with someone in Chennai. That would be 10:30pm on a Friday. Indians often have a dedicated attitude towards work. I think just because they would agree to something like that, doesn’t mean you should actually book it.

An example of scatter-brained or panicky behaviour was when he started a meeting, shared the wrong screen. He declares he is “sharing the wrong screen”, but instead of stopping ‘sharing’, he leaves the meeting, then takes him a few minutes to actually rejoin the call, where he carries on like nothing weird happened.

Informing & Criticising

Colin: "he is coming in as a Solutions Architect rather than Technical Architect" 
Me: "what's the difference in the roles?"
Colin: "I don't know, I'm just telling you the news"

I thought it was funny when he gave an update on the performance of the teams he was managing. “Last week was pretty bad for us. You guys don’t know this“, then says there were 8 Major Incidents, which got escalated to the Directors. What made it more funny to me was that the CEO had given out bonuses to his teams for apparently doing a great job. It was a fairly small bonus like a £50 Amazon gift card but still probably a regrettable action. I’ve said many times that managers seem to reward the wrong behaviour and struggle to identify the best performers. That’s another example. How can you go from doing a great job, to creating 8 disasters in one week?

I often found Colin to not practice what he preaches. So might lecture people about needing to improve code quality, but when he was a software developer, he was constantly cowboying solutions. Another example was that he says we should never put-off taking our annual leave because it can hide problems (it would illustrate a reliance on someone if they weren’t in), and show higher output for months then would suddenly drop towards the end of the year when people take annual leave at once. Then after his lecture, he then admits he hadn’t even taken 1 day off and we were 75% through the year.

Colin complained that Rob and I haven’t handled the project well, and it overran by over a month. A week or so later, the team was on a call with other stakeholders and he said “you guys have done a tremendous job”, then said the delay was caused purely by scope creep and nothing to do with the developers at all. I don’t know what to believe there. Maybe he did believe it was our fault but didn’t want to berate us publicly so was deflecting like a good manager. However, not declaring that to us meant we got mixed messages.

Near the end of that project, Colin showed me the items we had remaining and was like “you only have a few left to do…surely you can complete it all quickly”. I told Rob and he was as annoyed as me:

Rob: Its things like that that really make me nervous
Blind hope without actually looking into the problems
SURELY you can do it quickly right?
If not you must be crap!
Thanks for the morale boost!

The problem is, the project has dragged on due to complications, so the remaining work is probably quite difficult, but Colin is just seeing simple numbers. “3 tasks left; that’s not a lot”. But each task could take a week or two to get right. So even between 2 of us, it could take 2 weeks. Then Colin is setting the expectation it can be done within the week.

Closing Thoughts

When people have done a job for a while, then become a manager of those people, you would expect them to be great managers because they understand the work involved, the process, and problems they have faced with previous managers. However, time and time again, it’s like people forget their experiences and end up becoming bad managers.

Early Morning Meetings

We had our daily “Stand-up” meetings at 9:45, where the team states what they did yesterday and what they will aim to complete today. In our “Retrospective” meeting, where the team reflects on what went well and what didn’t go well over the last 2 weeks, and also what improvements could be made, one developer questioned why we have our meetings at 9:45 rather than 9:00.

Most people in the team start their day at 9:00, so to do a bit of work, then have to go on the meeting seemed like a distraction. After thinking about it, the longest serving team members said they might have set that time due to the previous Product Owner having several teams and it was the best slot for them to attend. Then no one questioned it and so it remained.

I suggested that we start at 9:05, given that if we turn on our laptops at 9:00, we will end up being late. Often if team members request help at the start of the day, they often reply “let me get my coffee”, so it made sense to allow people to finish their breakfast and get a drink. People seemed to think it was a good idea.

However, the next week, the meeting invite was set at 9:00. I questioned some of the team members.

[Monday 09:19] Me
has Sam ignored my idea of starting at 9:05 instead 
 
[Monday 09:20] Dennis
must've
 
[Monday 09:24] Dean
what was the 9:05 idea? can't remember that  
 
[Monday 09:25] Me
I said if we start at 9, it gives us a chance to get logged in, and you get your coffee
then everyone was like, "yeah dude that is sick idea mate", and you kicked off about being falsely accused of wanting coffee  
 
[Monday 09:26] Dean
haha  i don't fully understand
i get logged in and get my coffee based on what time the call is
T - 5 mins
doesn't matter whether that's 9am or 9:07

Dean had previously criticised me for being late to a meeting that was arranged for 8:30 (before my 9:00 start), and I had missed another that was arranged less than an hour’s notice. I felt like he was using this as another opportunity to question my attitude towards meetings.

On the third day, Dean then says he is finding it really hard to get used to starting at 9:00 and might consider asking for it to be moved back to 9:45. He finds it hard to wake up and be alert for the meeting. Some days he will be late from childcare because it’s a bit of a rush back and can be hard with the traffic.

Quite interesting how he made out he always starts working before 9:00, and made sure he is ready for any meeting 5 minutes before it starts. Then when it comes down to it, he admits he starts late some days due to childcare, and other days he isn’t fully alert to work efficiently. So when we had our meeting at 9:45, it seemed like he was never really working at 9:00 like he claimed, whereas I would be ready at 9:05.

Indian Expo

Recently, I blogged about how managers love any excuse to go to India to visit our office over there. Then they write a blog on their experience, stating how important it is for face-to-face collaboration in an office environment… before returning to the UK and telling us how working remotely from home is the modern way of working, and has no impact on efficiency.

They actually spend most of their blog writing about the local cuisine and the landmarks they saw; so it’s definitely a holiday and not a work trip at all.

I also wrote about The Expo, which is where the entire UK side of the company travelled to one location to watch many in-person presentations (which we could have just watched remotely like we normally do). Then when it is “business as usual“, managers are telling us to find ways to save money, and how we want to become a carbon-neutral business.

So after dumping loads of money into travel costs, hotel expenses, venue hire and catering for the Expo in the UK, they decide it would only be fair to host a similar thing in India… which means getting all the directors and senior managers to fly over there to do the presentations.

Obviously they used the opportunity to post a blog about the importance of face-to-face collaboration, Indian landmarks and cuisine.

Key phrases from their blog are as follows:

The India Office

“I am amazed at how much we were able to accomplish”
“India greeted us with its vibrant energy and diverse cultural heritage”
“The workspace was a fantastic environment, promoting team collaboration and productivity”
“Witnessing the teams working closely together was inspiring, and the entire place was abuzz with creativity and a real growth mindset”
“The office boasted excellent facilities, including communal work areas, private group session rooms, a gym, nap rooms, massage chairs, a food court, and garden”.

Expo Day:

“The Expo day itself was an exhilarating experience, with a buzzing atmosphere and a large number of attendees”

“Representing the team on the stands was a humbling experience, as engagement levels were high and the audience had a deep understanding of our work, asking probing questions around aspects of safety, governance and our products.”

Cultural Experiences:

Visiting the UNESCO heritage site at Mahabalipuram allowed us to witness the interplay between Hindu, Chinese, and Roman architectural styles in this historic trade centre.
Learning about the story of Draupadi and understanding the long history of international collaboration.
Our visit to DakshinaChitra cultural heritage site, highlighted the vastness of South India and its rich diversity.
Meeting the skilled craftsmen and hearing them describe their trades first-hand provided a deeper appreciation for the diversity of people and their skills across the country.
We learned about different rice and cooking methods for Biryani, and the amazing flavoursome vegetarian dish suggestions.

Printing Licence Key Expiry

My employer made the news recently after the deployment team applied the wrong config to several organisations which led to a heavy spike in network traffic and caused issues nationwide.

Sadly, we made the news again.

“We couldn’t print our forms for three hours. Someone had goofed and did not keep up with their subscriptions. For a company of their size; that is embarrassing.”
Customer quote

When users reported the issue, there was a call between a few managers. I was invited to the call with zero context by someone I had never spoken to before, so I thought there was a good chance they invited the wrong person.

The call was recorded so I just listened to it when I was free. They had invited me on the suggestion that I had worked on a feature in that area many years ago, and they had no other ideas. Also on the call, they called someone else and remarked how strange it was to the recipient because they had never spoken to him before. Why didn’t they learn and send some context? He didn’t join either.

Eventually, they found someone who belongs to the team that procures the licences. He explained that they purchase licence keys for this printing software, then send them to an internal support team to update the licence keys in the database. The team receives automated emails reminding them to renew the licence keys 3 months prior to expiry, and they act on it quickly to not risk them expiring.

“It takes a while to go through the purchase process, so I usually do it early, but sometimes it can “fall through”
Procurement guy

After going through some emails, they found the key had been promptly purchased, and the licence keys were sent to support, then they were not applied.

Another guy joined the call and said a total of 43 organisations have reported errors, but that’s the only ones we know about due to direct complaints we saw via Facebook.

“And then I need to understand exactly how this is happening, ‘cause this is the second time in two weeks that a licence key was sent to support and wasn’t applied.”
Angry manager

After the issue was resolved, another manager asked for a summary of the issue. One guy remarked

“just to say, the people invited to the call (16 invited in total), are not the ones that ended up being involved or resolving.”
Manager, reflecting on what a mess the meeting was

I don’t understand how all our departments are causing chaos all at once? We don’t seem to learn our lesson either, how can we make the same mistake twice in two weeks? It’s also been a problem for years – that we struggle to invite the correct people to major incident calls so issues take much longer to resolve.

The Expo

Despite other departments in our company arranging optional meetings to explain what they do, in a recent survey, colleagues had apparently said they don’t have visibility of the wider business. The directors decided to create what they called “The Expo”. This was a mandatory all-day event located about an hour away from our main office.

The Registration

We got told to sign up via an Events Company’s website and the instructions we were given didn’t match my experience at all. We were told by visiting the website via the link in the email, it would auto-populate with our names. Yet the first question on the page was to ask for my name and email, and only then did it display back to me. We were also told to ignore the displayed cost because it would be the company that would be charged and not us personally – yet it displayed as “free”. There was no information in the email about how we would travel, but then one of the questions on the survey was asking us how we would arrive at the venue. It was only when I tried the “coach” option did it then state it would pick us up from the office on the day, but didn’t state the time. I then expected that information in the confirmation email, but it was only a week before the event I was told the pickup was 7:50am which meant I would probably have to wake up at 6:30 to make sure I didn’t miss it.

Despite the usual reminders that travelling by personal car on company time would invalidate your insurance (since you need to be covered by business insurance), I suspect most people went by car because there were only around 20 of us on the coach.

The Arrival

As we headed towards the venue, some of the senior management handed out notebooks but no pen. The notepad did have the schedule printed on the front which was useful. Since they told us to dress smart, most of us didn’t bring bags, so we had to inconveniently carry a notebook around all day.

The Event

Most of the day was sat in a large meeting hall watching presentations from the heads of various departments and directors. They used the opportunity to present the Employee of the Year awards. The thing is, we periodically watch presentations like this remotely, so it seemed a waste to make people from across the country to travel to an event like this. Some people travelled hours, and stayed in a hotel on company expense, and I just didn’t see how it could possibly be worth it.

“can’t believe we have so many people turning up”
Event organiser

You invited the entire company and said it was mandatory, what did you expect?

The Call

As it approached lunchtime, during one of the presentations, I noticed a developer checking his phone and looking concerned and then he walked out. During lunch, I was talking to another developer in the team. He started looking at his phone, then handed me his plate and told me to hold it while he goes to take a call. Several minutes passed and he hadn’t come back, so I was there awkwardly holding 2 plates. There were no tables and the room was packed with people so there was nowhere to put it. Eventually, I just had to bin it. When I saw them later in the day, they said there was a Major Incident so were called to a room to investigate remotely. So a few developers and the directors were all gathered around 1 laptop, knowing there wasn’t much we could do.

That’s another disadvantage of one of these all-day events. No one is working, and urgent issues like this can’t be addressed and just adds extra stress.

The Stalls

Another part of the day was walking around some stalls. It was like a careers fair but you already work for the company that they are promoting. Also, since there were that many of us, we were split into 2 groups, and since I was in the second batch, all the free stuff was gone. I could have grabbed a free pen for the notepad.

I didn’t really get the motivation for actually approaching anyone on the stall to listen to them reel off a speech that they would have been saying on repeat hundreds of times throughout the few allocated hours. Wouldn’t it have been better if these were also presentations in the main hall, then they only have to do the presentation once, and everyone gets to hear it?

I suppose the more socially outgoing types might be in their element, but I was just walking in circles, pretending to look busy. Eventually, I got talking to some old team mates and we were commenting on how bizarre the entire thing was.

Software Development Stall

For Development, the manager who volunteered to run our stall said he planned on using a darts game but using “magnetic” darts so it wouldn’t violate Health and Safety. The “Fun Police” busted him though – Health and Safety deemed it unsafe since throwing something would involve swinging your arm back and that is dangerous.

I’m not sure if things have changed from a few years ago, but we have had office parties with a Bucking Bronco, Bouncy Castles and similar games. I think every year 1 person has had some kind of injury using those, but it never stops us organising things the following year.

The replacement game was a “guessing game”. It was a vague question like:

“Guess how many minutes were saved in a 2 month period during our “COVID” release?”

The manager was insistent that everyone should guess, and was demanding I submit a number. I didn’t understand how people were coming up with the numbers. I kept on asking questions but I got the impression even the figure they had was some exaggerated figure. I asked

what was the feature?
how was it measured?
Why are we measuring in minutes when the figure appeared to be large like 20 mill minutes.

After the event they announced that guesses ranged from 100 minutes to 2 billion minutes! The correct answer was 31.9 million minutes.

Evening Meal

Another part that wasn’t well thought out and a waste of money, is that they provided food at 4:30 but there was nothing scheduled afterwards. The coach was at 5:30 so I had to stay, but most people had no incentive to stay. So when food was served, there were probably only 20% of the people there, but they would have paid for food for everyone.

Feedback

I did wonder if people would give negative feedback for the event. It seemed rather pointless to me; a complete waste of money, and not really that feasible to try and bring the entire company in one building like that. I suppose the main COVID days are behind us, but it’s probably a bit of a health risk. I knew a few people that were ill after the event.

Loads of people actually stated positive feedback, but it was on Yammer, and people seem to use it to post overly positive statements. The only negatives were:

All I used the notebook for was the agenda on the back, which could have been printed on the back of the pass.
no pen
carrying around the notebook all day
restricted interactions,
lack of space while eating

Yet the positivity was flowing:

It was great to put faces to names – especially when it’s a team that you work closely with. It was also really nice to see people that I’ve not seen in over 3 years. Overall, a great opportunity.

I was reminded of the value of face to face interactions with colleagues across the business. Will be looking forward to future opportunities to meet in person.

I learnt more in one day about our business/products and services than I have in the year that I’ve been at the company. What an amazing ‘sheep dip’ opportunity to immerse oneself in the ‘what we do’ and ‘why we do it’ for our end Customers – fantastic !

Seeing people, I have not seen in over 3 years since working from home was great, as was meeting people I have never met in person before. Getting to meet them in the flesh and build further bonds was a great experience.

Having the opportunity to network on such a mass scale and learn about other departments that we may not have regular touch points with was invaluable.

It helped me appreciate how each and every department is working towards the same goal, and that we have a lot of exciting tech-for-good products!

Being just 5 months into starting with The Company I found The Expo a real success. Not only did it serve to educate as to the breadth of offering across the wider business but also reinforced the value and absolute quality of our portfolio. The insights to the wider business has reinforced key messages around data quality relevant to my customers within their world and how our unique offering can support and accelerate the valuable research they provide. This event really encouraged me to reach out across the wider business and was indeed an excellent platform for building an internal network. The Expo gave a real feeling that top down and bottom up you would get support.

Sometimes, being bogged down in the day job, it’s common to be disheartened by the day-to-day challenges we face and getting mired in the weeds: a classic case of not being able to see the forest for the trees. The Expo was a great opportunity to get the big-picture view and see how, by succeeding in the daily challenges, we are improving healthcare for huge numbers of people.

I’d been fortunate to have attended two other great opportunities to meet up face to face and network already this year, and still found this another great one to see even more people and catch up on common themes across the whole business. I always learn something both personally and about our products, on this occasion improving my knowledge of Project X particularly. The overwhelming reminder at the beginning of why we do it, the impact it has and why we should feel proud of where we work, is a welcome prompt to look up from the day to day challenges more often.

I met many more people face-to-face for the first time than I’m able to remember now and got a real insight from generally chatting to others around what different teams actually do, how and why. With the number of acquisitions we’ve done over the years it also helped me learn what some of the products we’ve acquired are as well as how they add value to our customers. It was great to see some of our Chennai colleagues at the event and hear how the services I work on day-to-day are used in the real world.

Hang on, they flew people from India over to England just for the event!? What a waste.

Delayed reporting of Major Software Incidents

Process Problem

A few years ago, there was a period of time where I ended up being on the calls after a Major Incident (MI) with our software was declared. I was amazed at the clear failings with the process. There were all kinds of various managers, then maybe a few people from Deployment, but then barely anyone from Development.

Then you’d have these managers just theorising if the Incident was caused by hardware or software, and if it was software – which enhancement/bug fix could have caused the issue?

It was pure guesswork of course, and occasionally they were right, but what is the point theorising when you could just get the people involved that can actually investigate it?

Sometimes I would hear about a Major Incident and then see that it was actually logged days ago. I think a problem is all the process between Support and Development. Support log incidents in their system and talk about “customer reference numbers”, but we need it in our system which is currently Azure DevOps and we talk about Work Item numbers.

So sometimes there might be a delay even logging it in Support, and then there is a delay until it actually gets transferred over to our system. Often we are on these calls and we ask for a Work Item number so we can read information rather than just waiting for someone to mention it on the call… and then we are told that they haven’t created a Work Item yet.

I remember a time when users complained to Support, then they logged a Bug straight away, and did really good investigation. Then it would come to us with full details. Now, users complain for weeks, it gets escalated up to the Directors, then comes down the Development managers to Colin, then we have barely information to look into it because the users haven’t provided it, or is just “Chinese Whispers” and the information gets lost.

It’s so frustrating because how can you attempt to diagnose anything without all the required information? So the call is pointless, but when you do have the information, then you don’t want to be on a call – you want to go and start looking into it because you want to diagnose it then fix it.

So let’s look at one of the last examples I was involved in…

Example

Colin messages me about a Major Incident.

“I need some investigation…”
Colin

Apparently 179 sites are complaining about this problem and threatening to leave. Despite being complaining since the Friday release, Colin only knows about it Wednesday. Classic. Not the first time this has happened.

So what can I investigate? What is even the problem? All I know is there is a problem with a certain feature, but the thing is, we integrate with several third party API’s and I haven’t been told which one it involves, and I don’t know what the problem the users are seeing is.

I ask Colin to elaborate:

“not sure which provider. Can we look into all of them? So one of them may be broken, but we need to look at them all and hope we find it”
Colin

Wut. You want me to test them all out and hope I notice a problem? But it could involve just one and require specific steps.

When I finally got some information, it was pretty sparse.

“between 2 minutes and 12 minutes for the dialog to pop up”
the problem

I told them I would have to see it happen, and see if there is anything different the user is doing to make it go from 2 minutes to 12 minutes. It sounds like a network issue, or not our fault.

“we will test it with a happy…well not a happy user, but an ‘engaged’ user”.
Manager’s suggestion of arranging a call with a user to witness the problem

I was then on a call with all kinds of random managers, all chipping in speculative accusations. “It’s a problem with the deployment“, “it’s a problem with the amount of data in their Tasks module“, “it’s a problem with the number of user-created resources“.

Colleague Opinion

I was discussing this with one of my colleagues and he re-iterated my views:

"they red flag anything nowadays - they just wave their flags around
It’s always the case that someone knew several days ago, but now it needs fixing immediately and it’s the first time any developer has heard about it

why can it not go:
Problem logged by customer -> Support discuss with Release Management -> Release Management arrange call with the correct Team Leader -> Prioritises the work with a developer and tester

I don't see how that's difficult

What actually happens:
Problem logged by customer -> sits in a list for a while
Problem management person looks at issue -> sits in list for a while
Someone kicks off and escalates the issue -> Director gets it in the neck -> Release Management notified
Release Management hold a call -> float many theories about what the issue is about
Developer randomly hears about issue -> mistakenly joins call mid-flow -> explains that it's probably related to the work item with the same keywords as the issue in the title
Developer now late with their own work
Release management say they'll prioritise the issue, but asks if you could start working on it -> Developer says no because you are busy working on 8 different things -> everyone in a huff
Team Leader nowhere to be seen -> likely watching the TV"

Apparent Analysis

A manager recently posted an update with facts that I was sceptical of:

“Analysis conducted into 2 years worth of Major Incidents

Some interesting trends have appeared and I think it’s worth discussing:

Data shows that most of the MIs are caused by either a 3rd party or tech debt/ops related issues. The number attributed to code change is pretty low.
We are lacking ownership around domains for existing products so not obvious which Engineering Manager is accountable.
We don’t have enough SQL skills to manage our complex DB
We rely upon a small number of people to investigate MIs.
MIs should be owned with the right teams.
Further investigation required on this and changes to ownership, structure, investment needs to happen.”

Release at Pace

Another interesting claim was made by another manager:

“There’s lots of interesting developments going on at the moment; we’re delivering more than ever before.”
Manager claim

I message the Software Delivery Manager to ask if there is any truth in that, because I thought we were releasing at the slowest pace.

“Who knows? I reckon one of those blaze statements that people just say to make it sound good”
Software Delivery Manager

On a recent Development meeting, one person posed a question to the Head of Development:

“Deploying software at speed is ultimately what we want to do as a business. However, this can come at a cost. We have had more Incidents in Q1 caused by software defects than we did in the whole of last year! How do we ensure the deployed code is at the quality required if we are going to deploy at speed?”
Staff member’s concern about software quality

If we deliver more changes, I suppose there is more risk of introducing more bugs. If you are rushing, then you are more likely to create Major Incidents. I suppose you can say it is fine if there’s more bugs in general, but all considered low severity.

The Rapid Responders Group

As a response to this, I think Colin came up with the idea of the “Rapid Responders Group”

“We are deploying our software at a pace we have never done before, so we can miss scenarios that could happen in the production environments as we have seen in the last two MIs. If we can get information straightway, we can investigate the issue straightaway. We all have access to the Live environment. With our technical ability, we might be able to see things that other people might not, so this is why I have assembled this team.”
Colin on his new idea

However, it was quickly shot down by one of our architects and never mentioned again.

“With one of the MIs, there was absolutely nothing we could’ve done between the people in this channel to anticipate that as it relates to a combination of live configuration and state that can’t be replicated.

In general the problems we have with the MI process is making changes takes too long due to processes and permissions, noise from the non-experts present (it’s hard to get a word in edgeways with some people), and multiple people bugging those performing the fixes/changes for updates (when it should be one person who fronts the technical team working on sorting it out)”
Architect

“We had first-hand experience of this on the last Major Incident call. We could have fixed it within 30 minutes but was on a call discussing it for hours.”
Colin

Architect:
It's usually the fault of those running the call or lack of confidence in Dev.
I will say when we have enough information to make a fix - that I'm departing the call to concentrate. As you say, it will otherwise go on for hours, with multiple people fronting opinions on the cause of the problem, unless someone identifies it with confidence and takes the initiative.

When an MI occurs, it's always the same group of people, which is often a pretty good mix, but first we need to identify the cause.

Usually it takes a long time for the details of the MI to be logged, particularly somewhere Development can all access such as a Work Item. If you miss the start of the call, it's difficult to know what the details of the original issue were: you can guarantee you missed something of importance.

I would suggest the following to help the diagnosis run more smoothly:

When a release is made, it must identify a point of contact for each change, preferably the team email address making the change.
When an MI is started, a brief description must be provided in written form and a source-of-truth record started (such as a Work Item).
The Release Point Of Contact list is emailed with details of the MI starting.
They might not need to join the call unless there is something they can add, but at least if they feel their input valuable to the diagnosis they can join or reply with details.
After identifying the team/person working on a fix, they are protected by a single manager. The manager will be responsible for communicating with the techies and the outside world, so they can concentrate. They will update the Work Item and email those who need to know progress, what the fix entails etc.
Work out a way to expedite changes to live and retrospectively log change requests

Principal Developer:
From the MI's I've been involved in, they mostly run smoothly - the only disruption is (as Mike said) people "sticking their oar in" and having a guess at what the problem might be - sometimes forcefully.

They are not always wrong, but sometimes it can distract from getting to the route of the issue, you need to have the confidence to talk over them and get the information you need, correct misunderstanding, and to keep the discussion on track. A lot of the time the initial presentation from support can be way off the mark, but that is true of most bugs we get due the lack of technical skill in support. Only the developers on the call are going to be able to diagnose a fault as a result of a code change.

The primary focus of an MI call is to restore service ASAP, exploring workarounds is part of the developers role on the call - can we change a stored proc / setting to improve things now? This helps users and gives development more time to work on a fix. Another role is to assist the wider business (especially those in the Safety and Governance roles) to understand the issue - is it as bad as initially reported, or is it worse!?

Once we know what the problem is, and how we will resolve it, then it is OK to drop off and work on the fix.

Conclusion

I think it is clear that too much time is wasted discussing the problem with the wrong people. Managers need to find the correct group of technical people, give them all the information they need, then give them time without hounding them – in order to actually fix it.

Office Tales

Introduction

Going to the office 5 days a week for my Software Engineering role was such a standard thing until the whole Coronavirus and lockdown became the new world. It’s crazy that my employer doesn’t have any interest in us returning to the office other than for optional collaboration. I mean, it does make sense, but it’s a complete u-turn on their previous ideals. We used to have a few offices nearby, but I think we only have 1 now. They redecorated the remaining office, cutting down the number of desks, and we are allowed to book time in the office if we wish, either individually or as an entire team. I have never been in though, and have only seen a handful of colleagues on a recent night out.

Things I miss about the Office

I think I miss the conversations you overhear from nearby desks, and communication is much more efficient when you can just walk over to someone’s desk. There will be people that you don’t need to interact with for your current work, but will acknowledge them as you walk about the office (often going/returning from lunch breaks). So it’s much more social when working in the office. I think there is a general awareness of what things are happening across the business, because you see people moving about and hear them talking about work. Now I only get that information if people post on communication software such as Slack/Yammer.

It seems I have quite a few draft blog posts that aren’t that exciting on their own, but I’ve put together a collection of ideas to reminisce about office life.

I’ve just discussed some things I miss about the office in this introduction, but the rest of the blog is basically “Things I don’t miss about the office” and “Other tales”.

Things I don’t miss about the office

Moving Desks

Every so often, managers decide to reassign loads of people between projects. Then, if the team sizes aren’t the same, they have no choice but to rearrange the desks, or simply relocate teams. This meant the entire department would move, even if the new desk is just 1 desk away. It was a major disruption and was basically a waste of half a day. People tended to unplug their PC a bit too early, but you did have your PC, 2 monitors, keyboard, mouse, drawer unit, then loads of cables and other items. It’s a big chain of moves though because you can only move if your new desk is free, but it is only free if the current person’s new desk is free and so on.

There was supposed to be a big move shortly before the lockdown happened. We were told that it was coming but then seemed to get delayed but no announcement (so no one knew what the holdup even was).

I was told I was moving desks by my manager. An entire month went by with no update. I ask my manager what is going on. He says “I’ve been asking many times and I don’t get a concrete response. If you hear anything before I do, then tell me“.

A few days later, I heard another team talking about the new seating plan. I told my manager as requested.

He says he has the seating plan “but I need to spend some time to digest it“.

What are you on about? Just send it to me.

It’s a seating plan that has been released, and many developers were already reading it. Why is he making out it’s something he has to analyse then explain to me?

Anyway, the conclusion is that desk moves are very disruptive, managers find it a really hard task and they change their minds about it, then this makes it seem like a bigger event than it needs to be.

Sounds Of The Office

When I need to concentrate on programming, I often put my headphones in and listen to music. Drowning out all the random talking really helps you focus on your work. If people are talking, I’d often want to listen just in case it is something interesting and work-related, or maybe some funny casual chat that I want to hear.

Periodically, I’d take my headphones out, or maybe I would have to because I want to speak to someone or have a meeting.

Although the general sounds of the office were fine, there were some sounds that would do my head in.

Many people also used headphones to listen to their music, but there was one woman that often had her music on really loud. One time I looked over and saw that she had hair covering her ears, a beanie hat over that, then the headphones were placed over that. So the speakers have to go through a hat and her hair to reach her ears. No wonder she has it that loud. Also, I found it more distracting if I recognised the song. When Tool’s highly anticipated Fear Inoculum came out, she was listening to classic Tool every day and it went on for well over a month.

There were a few people with really exaggerated laughs. In previous blogs, I have mentioned one guy which I nicknamed Beavis for his style of laugh, but there were plenty of others that often did a fake laugh. One person sounded more like they were in pain rather than having a good time. It stressed me out.

There was one person that coughed a lot but it was more like a “ah mmm” like a stereotypical teacher would do to get a student’s attention. It wasn’t aggressive enough to actually clear her throat so it just seemed pointless to me, and extremely annoying.

Maybe the worst thing is this next subject, because I wouldn’t ever consider doing this whilst at work. I didn’t realise until I heard these sounds in the office, but I think it is a sound where it’s very satisfying to hear when it involves you, but hearing someone else do it; then it is vile. There were 2 managers sitting a couple of desks behind me, the woman was filing her nails and the scraping sound was very distracting. The worst thing that had me cringing though – the male was clipping his nails. Like I said, really satisfying if I am clipping my nails, but hearing that “click” sound on someone else’s; it had me cringing. I had to put my headphones on and crank up the volume, and try to not imagine those fingernails fly across his desk.

Kicked out of large meeting room

Meeting rooms were a really in-demand thing. Managers do love meetings, especially pointless ones. Then when you really do want a meeting, you just can’t get a room.

There were two meeting rooms next to each other, located near my desk.

Meeting Room A holds about 8 seated people, but you can get more people in if standing
Meeting Room B holds 3 people but you can get more people in if standing

I was called for an ad-hoc meeting with 3 other developers. Both rooms were free at the time. We take the larger room (Room A), since there’s 4 of us.

5 minutes in, someone knocks on the door

“Sorry, I have a one-to-one and have booked this room“

My fellow developers didn’t seem interested in arguing, so I followed suit and kept quiet. It’s a one-to-one so it’s a meeting for 2 people. Room B is perfect for them.

So after moving to Room B, we were trying to crowd around a laptop – crammed awkwardly in our seats. Meanwhile 2 people were sitting comfortably around a large desk in the opposite room. It looked ridiculous.

Office Tales

Empathy Lab

As I just explained, Meeting rooms were in high demand so we needed more of them. Of course, we like cutting down the number of meeting rooms for some cool initiative. One of them was the “Empathy Lab”.

“We were inspired in part by Facebook’s empathy lab which shows how people with impairments may interact with Facebook using assistive technology.
However, when building our accessibility empathy lab, it was important to us that it had a dual purpose: To raise awareness about accessibility, but also be an assistive technology testing space.”

I never saw it get used, but I did see many people get frustrated that they couldn’t find a meeting room.

The Recruitment Letter

Beavis gets a hand-written letter delivered to work written in a green pen. I don’t think I’ve seen anyone get anything delivered with their name on it that wasn’t a package, mainly from Amazon.

He opens this suspicious letter, and it is from a recruiter apparently from LinkedIn.

She explains that the unconventional approach to contacting him is due to the fact that his profile lacks detail and therefore that signals he doesn’t want to be contacted by recruiters.

<Sure, that makes sense.>

She likes the lack of detail in his profile though; it’s the kind of person she is looking for, so she wants to meet in person and talk at a Café.

I’ve never heard of this before? Is it a weird scam?

AWKS

Years ago, I wrote about how I was working in a team that was making the framework for a new application. One of our developers, Timothy, got moved to a team known as “Solutions Team” who were making a framework for the new application. I had asked him how his team differed to mine, surely we were doing exactly the same work? He said he was just doing what the managers told him.

A new developer, Nina joined the Solutions Team.

She comes over and asks Timothy to send her some documentation so she can understand what they have done over the last few months. (The correct answer is “nothing really, just messed about and partially duplicated another team’s work).

You could see the absolute terror in Timothy’ face. I think at that point, he was probably realising that I was right all along and their team was pointless.

Nina detects the panic and says in a concerned tone “are you okay?”

Timothy says “yeah” dejectedly, and then mumbles about “maybe he should update the documentation.”

Nina says she will come back later

It was the most awkward situation in a long time.

Just Paste It In

William has been working closely with a Junior developer. The Junior had a list of objects and needed a simple sort.

William is new to Javascript, but the syntax is exactly the same as C#. He looked at the method signature and didn’t understand it, so he told the Junior to google it.

The first solution they stumbled upon on Stack Overflow had an overly complex solution, but the original poster did request he required only one method that can handle sorting various items. Therefore it required an elaborate solution.

In the Junior’s case; he just wanted to simply sort a list; therefore this code wasn’t appropriate.

William told him to paste the complex method in and “it will work”. The Junior challenged him on it, asking if the algorithm sorted the items in ascending/descending order, and asking him to explain how the code worked.

William then just reads the name of the method and the parameters, trying to say some words in a confident way to blag that it was the correct thing to do: “It’s a dynamic sort, you just pass in the list, along with the name of the property you want to sort by“.

The Junior asks again if it sorts in ascending or descending order.

He then says “yeah you are right, this might not work“.

He had no idea what that code did, he was just hoping it worked – so was just confidently telling him it would work if he just pasted it in.

I ended up telling him how to do it. It’s a one line solution; not a 30 line method.

Crisis Meeting

Apparently my employer has recently made a big deal and sold our software to a large group of users, but the users now want to reverse their decision based on other customer’s opinions of our software. Not sure why this group of customers only found out these opinions after making the deal.

We had a meeting with the new Head Of Development to discuss what we can do about it. The overall aim is that we need to repair our reputation: fixing major bugs, improving performance, improving the user experience in general, and making it clear to our customers that we value their opinion.

He initially stated that he wants more bug fixes, especially performance improvements and delivered in smaller, but frequent releases. He states that the current process doesn’t work and we should ignore it and come up with a new one.

Sounds great in principle, and a desired philosophy of Agile Development. However, Release Management stated it wasn’t possible to update the entire customer-base so quickly. This is partially due to the way some users work, and some contractual obligations. Both of these problems pretty much come down to the idea of essentially wanting close to zero downtime, so they want to choose a specific time to accept our updates, and they like this to be around once a month.

So the discussion turned to the development side. It seemed we were in agreement that we need higher-skilled staff to target these important bugs (we love throwing Juniors at these important issues), and we would also like to work in Domain based teams. Examples of this team idea is that you’d have one team that exclusively handles the Reporting module, and another handles Registration module etc. This way you can have a fuller understanding of all the configuration, features and the codebase; so can fix/enhance the software faster. Essentially you specialise, rather than going with the jack-of-all-trades master-of-none style. We also wanted more Testers since some teams have produced a lot of fixes recently but the Testers couldn’t get through it. To be honest, I expected that some Testers were just working slow and the fix isn’t necessarily to throw more staff members at the problem (just have a stern word).

The response from the Head of Development was that “the business” has decided on the team sizes and who is in those teams – and they won’t change.

So to summarise – we are asked how we can make dramatic changes to the way we work, ignoring the current process… then get told we can’t do our ideas. We’d shot-down his suggestion, then he shoots down ours.

I think he shot down our suggestion because he is too focussed on the current process and structure, and he isn’t taking his own advice by ignoring it and coming up with a new idea. To be honest, it is easier said than done, and I think his way of thinking is – how to preserve the current in-flight projects? You can’t simply restructure the entire department without dealing with the current projects.

What you can do is just make the current project teams bigger and let them take the project and some bug fixes. With a bigger team, they can easily carry on with their project work, and with the extra people, they take on live Bugs, fixing “Technical Debt”, adding more automated tests etc.

I get confused how we get told these “Service Improvement” teams (teams that deal with bug fixes only) are the most important, yet it’s the Project teams that get the most experienced developers and the most attention. He has limited the “Service Improvement” teams to 20 developers with only 4 with Senior rank, one of which isn’t good enough to be Senior. Then most of the other developers are essentially Juniors.

How can you deal with important bugs with a lack of talent? It’s frustrating that he arranges a meeting to ask how we can solve our way of working, but then he doesn’t listen to the feedback.

If he wants a quality product and to deliver faster, then we need the staff and process to actually achieve it.

Protected Time

We often find that managers will arrange meetings when everyone appears to be free, but they don’t consider if it is actually a good time. So they often arranged meetings during lunchtimes. After our Head Of Development announced that he wanted to ban the practice, many managers seemed to ignore this and carry on. It eventually got flagged to HR who then declared it was going to be a group-wide process, and we can no longer have meetings between 12-1.

I know many people who like to have their lunchtime at 1, but I guess they should adapt for convenience. I guess you cannot block meetings between 12-2 to cover all possibilities.

Our new CTO arranged an hour-long training session 12-1. It wasn’t that he wasn’t aware of the policy; he declared that he knew the policy – and was deliberately violating it.

“We have deliberately scheduled it within protected time as this is exactly what we should use our protected time for – a chance to learn and develop ourselves.”
CTO

I stated to a colleague:

“I thought the protected time was protected so we can actually eat… I’m currently developing myself with a sausage and egg sandwich”
Me

I don’t get why he thinks the protected lunchtime should be used for training. It was specifically to ban meetings during this time. If we had food ready, we could eat while listening. However, others may need to cook, want to go out for food, or like to eat with their family.