Share a reflection that you wouldn't normally report on as part of your job. It can be an internal-facing post or any kind of documentation as long as it is shared with at least some team members.
When we share our thoughts, it's often in a one-to-one conversation, a verbal debrief, or notes sent in pieces--each piece sent to different team members. But, documenting thoughts as a whole reflection in one written place, is a way to save those thoughts long after the moment you shared them. It's also a way to invite other teammates to weigh in and/or reference the documentation. We never know who might benefit nor at what time, so open documentation can be a game-changer practice.
About New Practice November 2022:
Each week during November, we prompted this group to adopt a work behavior for that week. At the end of the challenge week, we shared our reflections in the post's comments.
Even though the prompts for the month are over, feel free to continue sharing your reflections as this discussion will be available well after New Practice November 2022. Thanks to all who have and will participate!
Based on the CTA in this post I decided to break the self-imposed shackles I have placed on myself and send Slack message to all of my direct reports with my thoughts on the annual review process we run as a company. All of the recipients of the message are either being reviewed by me or having their reviews approved by me. The process is an imperfect one, and I wanted them to know how I approach it so that they can feel more confidence about how they are handling it. It will also help set the tone for my 1:1 conversations with them when their reviews come up - and knowing how I think about the process and the advice that I shared will hopefully help them be more prepared when we enter the room for the review. I've always hated that aspect of the process - one of us enters the room in total control, the other has no idea what to expect. I am hoping that by sharing my thoughts it has evened the playing field.
I can't report back on the effects it may have until the process has run it's course, but will be more mindful of how it may change based on sharing my thoughts prior to the completion of the process for this year.
What a great use case, @Andy Gladstone.
My knee-jerk reaction is documentation that people access on a rolling basis. But directing thoughts to specific people is really smart, too! I imagine that personal notes carry more weight, too.
@Christine P. Dela Rosa fair point. My intention is that this should be something we do refer back to so we can understand where the process was at this point in time and work on improving it before the next time the process needs to be executed.
Ooh, I like this one. Going to have to have a think about what to share and whether to do it as a slack message or a blog post. Hmm... decisions
It is interesting! By getting to do this, we get to understand and keep the memory of things we document.
This has been in my practice for past year since WFH started
I have documented the Implementations best practices, configurations, and help required for engineers to start thier support to customers with hierarchy of Confluence pages.
I personally love to document the things which I learn as well and this keeps me motivated to learn more and motivate others by sharing the learnings.
Thanks,
Pramodh
Ooh, what's an example of something you've documented this week (or at least recently) that are not part of your day-to-day role?
As and when the new technical evaluations are going I have the practice to document them.
One such tool is Beacon which I am very fascinated with. So I did document the tool usage and it was very fun!! which usually has access to internal employees.
Thanks,
Pramodh
@Christine P. Dela Rosa yes this is good idea,
recently, I decided to paste all the teams chats with my team memebrs along with users, when we discuss to help users in calls.
Really the whole chat messages and discussion points helped us to bring one process for all of our X-ray test issues, I reviewed the the points with my team members.
It helped a lot for our team members.
Vikram P
Ooooh, I like! I think there's a lot of decisions or even themes that arise when you look through conversations that we lose without saving the chats.
Great idea, @vikram!
This is such an important one that we normally don't think about. I'll be honest, I always don't.
I decided to do this yesterday after I saw your post, and I provided some written guidance about how I saw our team working on certain types of calls/issues that we would get. So I briefly summarized the pattern I saw, explained what our normal procedures should be. I also opened it up so the team could share feedback regarding reasons why this pattern was emerging.
Definitely something I will try and force myself to keep in the forefront of my mind.
I definitely liked the idea that @vikram
This example gets at the heart of sharing observations impromptu, @Jonathan V_! We often wait for a formal time to provide analysis but I like that you were able to share thoughts closer to when the pattern was happening in real time.
Yea, I definitely agree for the impromptu aspect. I feel like if you wait to put something together and over due it, it is either forgotten, de-prioritized in favor of something more important, or loses it's light-hearted aspect and becomes work instead of just observations.
Hi @Christine P. Dela Rosa - I read this suggestion yesterday and put it into action! Thanks for the reminder to do this. I typically do not do this as much as I should and when I do I find it valuable!
Last week we did an Agility Health Radar assessment. If you don't know what this is, it is a tool that allows you to measure and visualize the health and morale of your team. The assessment includes each team member taking a survey that includes various questions across numerous subjects, which are used to uncover the status quo or "health" of the team as well as important developments or changes from previous years. After all team members have answered the survey, we get together as a team with an agile coach and go through the assessment and set some goals for improvement for the next 1/2 year.
This morning I took the time to write up a summary of our health team meeting. It included highlights from the assessment, some quotes from team members that were said during the meeting, some kudo's we gave each other during the meeting, some things we can improve on and a plan to do so, and an outline of the goals we set together. I shared it as a Word document in our MS Teams team this morning and I have already received some pretty great feedback on it. One of my team members said as a response, "This is a great summary of our assessment meeting Summer! I find this valuable because we can read through it before our next assessment to see where we were at this point and use that as a "radar" for going into the next one 6 months from now. Thanks so much for doing this!"
Thanks for sharing this, @Summer Hogan! After have such rich conversation I'm so glad (and it sounds like your teammates are, too), that the value of from the Agility Health Radar was documented. 🙂
Every team is different, but for many of the teams I've been on, "if it's not documented it's not real." That's a bit more extreme than the reality, but the documentation is what makes insights seem more official + it's a way to capture periods of time as our memories get lost in whatever becomes the latest thing to remember.
Our team has monthly retros to reflect on the team's health status. This way, we can see the evolution of the "health score" month by month and check if the proposed actions have a positive effect.
Besides that, we're trying out Atlas to keep each other informed of project insights.
Totally. Check-ins and status updates are great ways to bring alignment with teams!
Have you written up observations or thoughts outside of regular rituals? Something you aren't expected to write up but do write up because you have thoughts that might be of value to others? It's not a common thing folks do but a great challenge for us all to try :)
The most common observations I have is to document more on preparation and WBS, actions taken, lessons learned and share these experiences with the team.
There's so much we can learn from things that didn't go as expected, f.e. with a Cloud migration.
I did something like this the other day when I noticed in our ticketing system that some tickets were open for a long time. Upon further investigation, our engineers had started "@mentioning" users, but while the user got a notification that they had been tagged, they didn't have access to view the comments on the ticket (weird licensing thing). Long story short, I used this opportunity to write up some norms and post them in a location that everyone could see them. This will help us as a team to adhere to best practice, but also anyone new who joins can just be directed to that information. It felt good to knock out a documentation task!
I like the immediacy of your "writing up norms." Documentation at any time is good, but doing so, so quickly, really makes an impact I think. Great stuff, @Mike Hunsberger !
I have created a confluence page with my experiences so that my colleagues feel comfortable in the office.
Sharing a part of it here.
These sound like you documented some working agreements. I wonder if other folks will add on or comment on the Confluence page. Because by simply sharing, you're not only spreading awareness, but also inviting conversation.
I've started by changing the team’s workflows and procedures making everything more public and transparent.
They were either missing or old and restricted.
While making them public, we managed to change them in a more transparent and convenient way. From now on, everyone will be able to see customer feedback without permission. They will also see the Support rotation roster where the developers who will help support engineers as 3rd-level support and their activities are listed. All releases and who worked (tech writer, release manager, support engineer, etc) in each release are documented with a simple Confluence template.
I will try to continue and expand this practice.
Ooh I'm interested to see how folks interact with the (now more accessible) documentation. Kudos to you for making all of these processes more clear as you never know who wasn't clear or who had a different idea of a prorocess before!
This week I've been doing quite a lot of process improvement along with some extra sales type activities (which is not normally my remit) as we are winding down the year.
As the sale leads are not something I normally run with, I thought I would share a post with the team talking about what I had learned from the experience and own up to the fact that I am struggling with the very manual/hands on approach to this temporary task.
It illicited some really great conversation and one of my colleagues was able to share a similar experience. Long story short, I now have a much better process to use for lead tracking.
Team work makes the dream work. 🙂
Yes, love to hear it, @Lauren Allen!
This is regarding the team's health.
Based on the roles and responsibilities, the team health report (consolidated Sprints) is shared to the program manager who then presents to the leadership with his analysis. For a change and with permissions, the same report was presented to the team during a retrospective session to know their reaction. Well, given the report's visual view coupled with insights (the below list we use on Team Retro tool) like-
served as a self-assessment tool for the members who started taking it as a reference point (base line) for their work progress in the sub sequent Sprints.
What's in it for the team (WIIFT): Improved team collaboration, given them the base line track, list of key dimensions been tracked and performance measures.
I like a good debriefing session, @G subramanyam! In this case, I like that yours was specific to your team (as opposed to the standard attributes in Atlassian's Health Monitor.
Was this team health report documented in a way that is unusual for the team? Week 4's challenge was to see if we could document an observation or collection of insights that are not part of our usual documentation rituals.
Curious if you did something with your team different than normal, and if so, might you share how that went with the Teamwork Lab group?
One thing I would say is Atlassian products are like an open platform giving much needed ideas and use cases to the Atlassian marketplace. And they build their plugins "intune" to the product to make it seem less.
Given our client's Enterprise planning, they have been using this Team retro tool integrated with Confluence and Jira software. Here are the snapshots from the official website:
We usually share the similar attributes (listed on the Atlassian Health monitor) to the team members while the above listed health check details will only be accessed at program/ portfolio level management.
And yes...this entire team work is done at the "program/ portfolio level management" virtually still following that Atlassian health monitor guidelines, like:
Model example of using multiple tools in the role they're best suited--from pulling insights to documenting work. Thanks for sharing your specific team's artifacts with us!
My organization started doing retrospectives and documenting them. I have done them with teams for product delivery. It's been equally helpful to observe and see the benefits of them in the service delivery side which I hadn't experience before.
One of the things I started to document more is technical tip and tricks document that I share with team mates. Helpful tips I learn along the way whether it's OS commands, DB queries, or scripts. Recently, I just documented how to bypass the bastion host on AWS to get to the Jira and confluence instance directly. Shared that with my team and the overall the response was that it was helpful.
Overall, I do notice that when you give, it tends to open up more conversation of teammates sharing also useful tips.
-Ben
Love it, @Benjamin. The ProTips we pick up often stay just with us. So this knowledge-share of personal hacks is awesome, and what better way to share than through documentation?
Thanks @Christine P. Dela Rosa for putting together all the challenges this month.
One other thing, having live demos helps with spreading knowledge.
Ooh I like!!! I think we should do a round two of new practice challenges to do as a group. If it happens, maybe the organizer (whether me or someone else) crowdsources ideas, and at the same time, asks for demos! Could also be good to have demo variations alongside the challenge.
I try to offer at least one observation/hint or new tool every week in every team I work with and encourage others to do the same. Not everything has to be written down in Confluence or discussed on Retrospective - there are always small things we can share everyday :)
Documentation is a lost art in certain circles! As a manager, I don't often get to document the way something works for the team, but when I set aside time to do it, I find it not only helps the team, but also it helps me to focus and hone my own understanding, so I can more easily explain it in other contexts and to other audiences!
I am a relatively new Product Owner and already see the value in solid documentation (also helps with onboarding). Next to the documenting itself, I would also like to motivate colleagues more to check the existing documentation or to document themselves.
Documenting an observation about the team's health, the way the team works, etc., doesn't necessarily have to be a criticism. Always looking on the positive qualities and showing appreciation will always have a big impact towards any recipient.
MMM to Document or start the next task .
I appreciate the importance of documentation but alas trying to get everyone to even open Confluence is a burden. I smell some sort of incentive aka carrot to get a little more out of the team.
Interesting, @grao. Whether it's Confluence, another digital tool, or even the old printed memo or notes on a physical piece of paper, how do your teams document lessons learned?
Thanks for sharing!
This is a great idea!
love this :D
awesome :)
Whether you like it or not, you need to train your replacement if you plan on growing. Otherwise you get promoted, nobody is able to take over your previous responsibilities and now you're stuck doing both jobs.
How much knowledge is lost when your senior people retire. That knowledge needs to get documented somewhere or it's going to take much more energy and effort to track it down after they are gone. I would say a company can expend unnecessary resources when this happens trying to recover the data.
Recommended Learning For You
Level up your skills with Atlassian learning
How to Shape Effective Teams
Define your team's purpose, clarify roles and responsibilities, and create healthier communication and relationships.
How to Build Strategic Guidance
Designed to help leaders create compelling strategies to achieve better outcomes for their teams and customers.
How to Run Effective Meetings
This course gives you the latest insights, tips, and best practices to help you run better meetings.