Thoughts on Some Surprising Feedback I Received in the Pub
Posted by Paolo on 7.7.23 in Ways of Working
Recently I attended a department all hands in the office and it was a pleasure to catch up with some colleagues in person. At the end of the day we were invited for a drink in a nearby pub. During the course of the evening I had a chat with someone, a couple of levels higher than me, and he took me a bit by surprise when he gave me some feedback about a recent interaction we had on Teams.
I won’t go into too much detail, but, basically at Yell, the engineering team follow the Agile development methodology which means we work in Scrum teams dedicated to specific areas. We agree at the beginning of each Sprint (usually a period of 1-2 weeks), what our goals will be and we try our best to ensure we achieve what we set out. During the course of a work day, it’s inevitable that you will get questions from colleagues outside of your team and it is quite challenging to manage some of these requests when trying to focus on the tasks we have committed to as a team. I think there is a balance between being helpful, trying to understand how much effort a request will take to look into, and completely ignoring it. If I have an answer off the top of my head, obviously I will share it, but other times finding the answer may require more effort that will detract me from the tasks I should be focusing on. In an ideal scenario, when something requires further investigation, I raise it with my team to see if we can find time to help. This type of research activity is usually time boxed and is referred to as a Spike. That means that after working on an issue for the agreed amount of time you share your findings and if you need more time, you agree with your team if you should work on it any longer.
During a recent sprint, a colleague from another team reached out to ask for some data from a tool they knew I had access to. In reality, I wasn’t too familiar with it, but, I offered to jump on a call so that I could understand a little more about what they needed and to see if we could find that information together. It turned out that using the tool’s interface we couldn’t get exactly what we were looking for, but I suggested that I could post a message in a group Tech chat to see if anyone else could help.
One of the senior managers a few levels up from me responded explaining that they also had access to the tool and seen as it is a browser based tool, they opened up the developer tools to look at the network requests being made by the tool to see if they could find the relevant information in the responses for those requests. I should probably add at this stage that, as a web developer, I spend a lot of my day using the developer tools in Chrome (at the time of writing), looking at network requests, inspecting DOM elements and CSS styles and stepping through JavaScript code with the debugger. On this occasion however, I didn’t want to provide a one off answer, not so much because I was afraid of setting a precedent that I could retrieve this information, but rather to give my colleague the flexibility and convenience to access the data herself whenever she needed it rather than having to rely on me. The other concern I had was that I was fairly sure I only had access to the QA system, so any data I provided wouldn’t reflect what was actually happening in production.
When the senior manager sent me the details of the network requests, I wanted to express my gratitude that he invested time in looking into it. I was honestly surprised that someone at that level would get involved and perhaps even more so that they would be thinking of a short term solution of looking at browser requests rather than exploring a longer term way that people interested in this data could self serve. What I was really after was just to know if there was already a way that we were collecting this information before I invested any more time looking into how we could provide it. In the past I have been involved in building a dashboard to surface information about our systems and the third party ones we rely on, but, before getting involved in something like that I wanted to make sure there wasn’t something already in existence and also get the buy-in from the rest of the team that we could commit to it. I replied to the message saying thanks and at the end I wrote:
“Had not thought of checking the XHR requests, that’s some good ethical hacking 😉”
Me
Looking back at this, some doubt is starting to creep in. Is it something I should have done? It’s not that I don’t know how to do it, it’s just that I generally prefer to use a public API before spending any time in building a solution to essentially scrape data from another system. On some level I wanted make them feel they had not wasted time in providing me this information, but in reality I should have replied something along the lines of:
“Thanks for looking into this. I wrote the message on the tech chat in the chance that someone had already worked on a similar problem, to avoid wasting effort on the same thing. Writing a script to scrape data from our third party tools would probably be a last resort in lieu of a supported public API and it’s not something I would undertake without talking to the team about it. My aim was to find out if there was an existing method that people could find this information.”
Should have been me
I think it comes down to being more assertive. It’s true that I hadn’t thought of looking into the XHR requests, but the reason for that is because at that stage it would have been a bad idea. Getting involved at such a low level so early on, before even understanding the requirement properly is not a good idea in my opinion because it leads to wasted effort on assumptions around what people need and how urgent it is to them. It’s particularly important to consider this when as a team we have planned our work and committed to some goals because any external factors that could affect this should be mitigated.
So why have I been thinking about this at all? Well, during the the company drinks, my colleague explained that he was upset about our exchange on Teams and disappointed that I hadn’t thought of looking at the network requests. In addition he also made some comments about not wanting to feel he knew more than the developers because in the past he worked with developers that didn’t show much initiative. That’s putting it quite nicely, what he actually said is that he would ask them questions and they would respond with a “huh?”. He said this in an exaggerated tone to make them sound intellectually inferior.
I can explain why I had not thought of digging around in the developer tools to find the data, ultimately I didn’t think it was a useful exercise at that point. What I’m trying to understand is why someone in a leadership position would approach the conversation this way. Surely before drawing conclusions it would have been better to ask why I had not thought of looking into the network requests? From there I could explain my thought process. Starting with expressing his disappointment, triggered my guards to go up and I don’t think as a consequence I did a very good job of explaining my thinking. The thing is, I need to take responsibility for how I react in these situations and quite often I have a hard time separating the emotional reaction from the rational reasoning. My aim is to try and maintain my composure and not to become too defensive because I feel that leads to lines of communication closing down. I wasn’t sure whether or not to post this and why I would want to. I think that publishing something for others to see shows commitment to your ideas or at least a willingness to discuss them, but maybe that’s a topic for a different blog post…