I would summarise this week as writing and reporting. A week of less meeting and more in IC-mode. I find the flexibility to spend some weeks going deep on certain areas to be very useful.
-
I started the week re-reading the corporate blog to get a better feel for the content. Aside from the usual product marketing I think it’s important for engineers to contribute to an organisations public output, as it’s something that helps instill good writing practice and explaining complext technical topics in a straightforward way to a diverse audience. I was reviewing the content from different engineers to get an idea about the types of content we were publishing but also the style, both visual and written. I enjoyed spending the time reading some of the posts I’d missed when they were originally posted and it was an opportunity to work with out marketing team to think more about the guidelines we use to provide consistency the the editing and output. I am also going to be taking away some ideas about how to encourage more engineers in the organisation to write down their ideas and things they have been working on.
-
As my journey with product development continues, this week I was working with one of our teams who develop the “Fusion” tool we use to link different ITSM solutions. This is a tool that is a key part of both our internal operations but also our customer experience and how we integrate our customers tooling with our own. My job this week was to speak to the team developing it, review all their content and write it down into a more formalised service description that makes it easier to sell and understand. This is a good example for me of learning-by-writing.
-
I also continued writing reporting code this week for out cloud environments (both AWS and Azure). The aim of this reporting is always to make sure we’re doing all the things we should be doing as part of the service, but also providing reporting that helps us assess the impact to existing customers of adding new things. This week I was focused on “missing tags”. You could argue that this is pretty basic, but actually, the APIs for this are not great and there are are lot of taggable resources (like policies) that are easily missed by a tagging standard. This type of reporting allows us to make sure out tagging standard is rolled out consistently but also find taggable resources that we may not have included in our standard yet. Given this sort of thing is a bit of a moving target, it’s important to be always looking at it.