#type/weeknotes #max/lessons-learned #path/career

Weeknotes (2023)

I started Weeknotes about a year or two ago but I haven’t been keeping up with it very well. My job has been extraordinarily busy — more than we’ve experienced in my decade with this group. We used to have downtime, now I don’t know what that word means anymore.

It took a while to get into the groove of these reflections. What do I write about? How do I keep myself from complaining too much or upsetting myself? I have anxiety; how do I keep myself from catastrophizing? Instead of posting them online to share those struggles I’ve been keeping the log privately.

Recently, I started having more official conversations with my boss about the future of my job after it became clear to both of us that I wasn’t in alignment with her vision. The future I was promised by my bosses before her were no longer possible.

These conversations made me want to start writing Weeknotes again more seriously. Now I have a goal! Find what brings me the most joy and try to understand how we can fit that stuff in whatever the position becomes. I’m not very consistent, as it depends on how much mental energy I have at the end of the week whether I’ll do this reflection, but I’m hoping I can pull some insight out from batches of reflection.

To kick this off, my first batch lasts through the end of the year, including Weeks 42, 43, 47, 48, and 51 in 2023.

Observations:

I’m dedicating extra time and energy into the job (working late, working through lunches) to make time for the things I like to do the most because they are not my priority, but I still want to do them.
I really need to teach people how to fish! For a while the team leaned on me for insight because we had lost a few long-term team members due to bad management (that person is gone now). I held most of the knowledge because I wrote the docs. Now we are not short-staffed and there’s more time to slow down and explain.
My imposter syndrome is not justified. It’s interesting to see when the learning technology and documentation clash/combine and I’m confident the documentation is detailed and thorough, but I don’t know if the information is what they asked for. I had to write a retirement impact analysis for the university’s syllabus tool without any guidance, and I couldn’t find an applicable template online. I pieced together all of the information I could think of and apparently that was so impressive I got a shout out from someone 4 levels above me!
I’ve been doing really well with letting go of stuff that’s not in my scope. When I started here I was in a ticketing support role and it was part of my job to hunt down information and educate people, but now I’m an “expert” and I work with other experts and I can say “go to that other expert” if someone asks me a question in their scope. That part is easy, but the aftermath isn’t always. Experts are too busy to answer questions, but I always make time to address what comes my way, so people often return to me when the expert doesn’t respond. I still don’t know the answer, but this makes me feel like I should. I still have that support mindset of picking up the slack when my teammates are too busy.
I am on top of my shit. The more I work with larger teams and new people, the more I see it. I don’t wait until the deadline week to get started. I schedule meetings way ahead of time so they’re on the calendar. I contact people early when I have questions and communicate when I won’t meet my deadlines. I haven’t seen much of this (what I consider) basic work etiquette, and rather than being confused and frustrated about other people, I’ve decided to be proud and loud about how amazing I am to work with. You can always rely on me if you put something on my plate (as long as it’s in scope — otherwise I’ll tell you to go to that other expert).
This was resolved earlier this week, but it was an observation I made throughout this time period: There wasn’t a good intake process for the support team documentation. It’s a huge library of information and for the most part when people have questions they post in the Teams channel and someone addresses it. I go through and revise the docs every 2-3 years. Otherwise, I don’t get much feedback. Everyone is so blown away over how informative the docs are they forget to provide feedback on whether it’s easy to use, understand, or has the information they need. (We’re working on it.) Recently, we got a new support person who I call a “friend of the docs” — she reads the words and provides feedback when it doesn’t make sense. I love her. However, it became quickly obvious that her comments got lost in the abyss of work. If documentation were my focus this wouldn’t be an issue, but unfortunately it’s the lowest priority on my list. I worked with the support team manager and together we came up with a feedback process that keeps things fair and easy, without putting too much pressure on one person (me).

Doc work done during this time:

Created a migration plan for the department’s Sharepoint stakeholder self-service website. This site used to be maintained by a former colleague and I took over. Shortly after, our stakeholders changed, so I’ve been slowly working to revise the site, update for currency, and retire or move content for our old stakeholders. I’m co-leading this project with one other person and since I have some experience with migrating doc content already, I took the lead on laying out the plan.
Created a publishing process for the release notes on the stakeholder site. Even though it’s in revision, we’re still putting our sprint announcements and demo videos up, so they needed a place to live. Four different people will be posting about multiple types of releases so I tested, typed up instructions, made a video, and administered a training.
Designed templates and navigation/architecture for the stakeholder site. Previously, all content was listed under each platform and little thought was put into where future content would go so it was difficult to add sections. Now the instructional guides are divided from platform information and release notes, so you have a go-to spot for your information depending on why you’re there without having to wade through the stuff you don’t care about.
Began revision of the support team documentation library. Currently, the information is organized by platform or tool, but after the revision it will be organized by process with platform instructions separate. Also, about 25% of this content will probably end up on the Sharepoint stakeholder site as it’s useful for multiple audiences. Over the course of these weeks I eliminated 20 pages of content.
Researched Sharepoint content filtering to get the most out of the highlighted content webpart. Our Sharepoint site will have a lot of guide content once it’s done and I learned how to create columns, add tags, and filter by page properties.
I’m part of an initiative where a team of cross-functional experts are meeting to determine the university’s content ingestion and publishing processes. These guidelines were formulated years ago but there has been a lot of reorganization since then so we’re reviewing and updating. I volunteered early (and quickly) to create and update the process and standards doc. During these weeks, the scope of the initiative changed, so I had to follow through and update the guide. It’s so beautiful now! I generalized it from “asset ingestion” to “content ingestion,” added information about file name standards, versioning processes, content strategy, and more. The audience is the technology team, our partners, and our partners’ vendors, so I finally get the opportunity to write for audiences outside of the one I’ve been writing to for 8 years.
In addition to the process and standards doc, I’ve been making some infographic job aids related to the content ingestion initiative, and as we approach the end of the year, I had to rush on them. I still managed to get out two (I think) lovely graphics — one for the content ingestion lifecycle depicting each party’s role in the process, and the other giving at-a-glance details on which content storage solution to use when ingesting content.
At the very end of the year with no meetings and everyone on vacation, I finally had time to focus on updating the (published) support team docs (this is separate from my revision project — standard maintenance). I had collected four updates required and then another one fell on my plate on Tuesday, an update with the Service Desk team that impacted how my support team processed tickets. It was invigorating to spend the entire day focused on these updates, like I was hanging out with an old friend.

The stakeholder site and support documentation revision are my two lowest priorities, so they’re both slow going, but in progress! Despite being my lowest priority, this is the work I’m the most excited about doing.

Accolades: I got tons of good feedback on work done related to the ingestion initiative and a shout-out from a top-tier person for my work on the syllabus evaluation project.

Created: 12/22/23