What can we change in MadSkillz to make it clear that the bulleted items are not prescriptive?
Opened this issue · 16 comments
The second line of our README states:
[MadSkillz] seeks to describe some defining characteristics about each role, and provide some concrete examples along the way.
The bullet points are examples to provide direction in conversation; they are not a checklist to be ticked off.
We continually have to explain this point in retrospectives. I am continually explaining it to other Readifarians, some of whom have been at Readify for years.
A great example of this confusion is our application, which is designed for retrospectives, quite literally turns it into a checklist:
Which then iterates through each one, again reinforcing the wrong message:
This widespread misunderstanding indicates that we are not doing a good enough job of making MadSkillz GitHub documents clear in their intent.
While we have a sentence that attempts to clarify this, the document itself is structured in a way that encourages the opposite. Someone who has never seen MadSkillz before should be able to open up
a page and understand intuitively that the items are examples.
What can we change in MadSkillz to make it clear that the bulleted items are not prescriptive?
Here is one idea of how I think we could re-arrange the Graduate Developer role. It changes the examples to avoid using declarative emphasis (I am this, I am that, I do this), and emphasizes the important parts first.
I post this for conversation - I don't think it's the final answer.
Graduate Developer
I am a committed student of Readifarian values.
- I write good quality code that can be shipped to production.
- I show great enthusiasm and initiatives.
- I am an egoless, team oriented developer.
As someone who is a committed student of Readifarian values, I may:
- Be learning how to use a build and delivery pipeline.
- Be learning how to convert client requirements into deliverable units of work.
- Be competent with the tools and core building blocks used by our team.
- Understand the value add of different types of testing such as automated and manual testing.
- Be learning to implement design patterns that are widely used.
- Be learning about the infrastructure my code runs on.
- Be understanding the importance of PD and recognise the role it plays in my progress.
- Be learning the concepts of agile development and try to apply them within the project they are allocated to.
- Be aware of agile practices, and are actively learning how to apply them day to day.
- Be self-directed in my learning of technologies that interest me and seek guidance on technologies they should learn to progress my career.
- Be a team player who adheres to the team's conventions and processes.
- Not be afraid to provide my thoughts and insights to the team.
- Be professional and friendly to all my team members and fellow employees.
- Other team members genuinely want me on their team.
- I avoid going dark and I know when to call out for help.
- I am learning about all processes of the team and try to follow them (like maintaining accurate documentation, adding tests and so on).
- Continue to work enthusiastically, even when I disagree with something, while learning from the others in the team.
- Try to develop a friendly and professional rapport with my customer and their team members.
- Have net-positive, informative and helpful contributions to team discussions.
@robdmoore @GianLorenzetto are you suggesting that this repo is clear in it's intent? That new Readifarians, by and large, understand that these are examples, without needing another to explain that to them?
My experience at Readify - and what I am trying to illustrate in this post - is that it is not. ReadiMe is a symptom of that.
I have the same conversation with many peeps when doing retrospectives (around checklist approach) and I agree very much with what has already been said.
However, I do find many people want and require a 'checklist' approach to easily measure and gauge what is required to 'progress' for themselves. I find articulating how to do it without a checklist mentality is sometimes not received so well. Sort of like, 'last retro I had this "score" (for want of a better term) and now my "score" is better'. An easy, simple approach to "How do I demonstrate I am ready to promote" is sometimes the preferred way. Not saying it is a good approach or the right way, but am trying to say that many want/need it that way as the ambiguity (for them) they find exceedingly difficult. Different cultures and personalities play a part here.
My point is, I think it will be difficult to change in the short term, especially given the fact that ReadiMe is structured in exactly that way as Rob has mentioned. Even if we change the text (and agree that the suggestions are definite improvements), I believe it will go largely ignored if the process advocates the exact opposite and requires measurement against each check.
This then leads into a larger process change with requisite tooling changes. Given ReadiMe is in early stages this is a good time to do it (IMHO) so would prefer we try and change that first as the text can easily follow in conjunction. As a secondary point, providing structure in improvement/goals without that checklist approach is way overdue and necessary IMHO.
However, I do find many people want and require a 'checklist' approach to easily measure and gauge what is required to 'progress' for themselves.
@glav
In Vic ... they tended to rate themselves against the “examples” and for some people this is a preferred option much for what Paul said around people find it easier to measure across retros.
@wtulloch
We do have a checklist of prescriptive items in the document - the defining characteristics (as @robdmoore has mentioned). And we do encourage rating against those.
From this item in the README:
- Consider rating ourselves at the defining characteristics level so it's not too hard to maintain over time
- The examples could be used as a frame of reference for the rating.
A Graduate Developer should:
- Write good quality code that can be shipped to production.
- Show great enthusiasm and initiatives.
- Be an egoless, team oriented developer.
You can demonstrate that you are ready for promotion by scoring well against the defining characteristics of the role you want to be promoted to.
We're just learning that MadSkillz pages tend to imply that the examples are the checklist - but we can fix that. Let's fix that!
Even if we change the text (and agree that the suggestions are definite improvements), I believe it will go largely ignored if the process advocates the exact opposite and requires measurement against each check.
@glav
I think you have a fair point, and I'm glad that you like the suggestion!
I would posit that ReadiMe has been structured to follow MadSkillz, not the other way around. Changing this document would only be the first step, but we could use it as a reference point to give direction for future ReadiMe updates.
As a secondary point, providing structure in improvement/goals without that checklist approach is way overdue and necessary IMHO.
@glav
I think the People Lead initiative is one good step in this direction. I've received a lot of positive feedback about it so far, and we've set some concrete goals that align with both them and Readify.
I would posit that ReadiMe has been structured to follow MadSkillz, not the other way around. Changing this document would only be the first step
@WillRay
Yep that is certainly true and is definitely a much easier path to address right now. I certainly do not want to discourage that. I would like to use it as a sort of vehicle to prod the ReadMe future updates in that direction.
I think the People Lead initiative is one good step in this direction. I've received a lot of positive feedback about it so far, and we've set some concrete goals that align with both them and Readify.
@WillRay
Good to hear Will, glad it is working well.
"You can demonstrate that you are ready for promotion by scoring well against the defining characteristics of the role you want to be promoted to."
Just a point of clarification. The Mad Skillz are part of showing you are ready for a promotion (by doing them against current role and next role), but this is only one part of showing you are ready as per the promotion process documented in Readdit.
Re: rating against examples I think it should be up to the person whether or not they want to rate against that level of detail or not (keeping in mind that they are not an exhaustive list of examples and they may not all be relevant).
Whenever someone rates themselves at that level, as a retro partner I reinforce that's optional and the thing that matters is the defining characteristic. We can do the same emphasis both here and in ReadiMe to drive that home.
Examples I often give to people of when rating at the example level may be useful include:
- It's the first time you've done the retro process so are finding your feet - the examples provide more concrete examples to guide the direction of conversation
- You are going for a promotion and it's the first time you are doing a retro against a role and you don't have a good feel for what the defining characteristics are yet
- You are focusing on a few of the examples specifically so want to dedicate some time to rating and commenting on them specifically
From my POV I always understand that Mad Skillz was a supporting document for retros and promotion and not something that drive it.
Maybe that's what we are missing when used it to create ReadiMe.
The purpose of doing retros is to evaluate ourselves, and for that, the first thing to do is define a goal. At the moment the goal is imposed my ReadiMe as one of the Mad Skillz roles, but what if my goal isn't that?
Suppose that I'm doing a retro where my goal is to become a speaker at a large conference, then Mad Skillz is not the right tool to help me, but ReadiMe should continue to be the tool for this, where the retro partner will help me to achieve this goal by defining targets and evaluate my progression next time and adjusting as needed.
At the same time I can do another retro where the goal is to achieve a promotion, then my retro partner could be someone else who will help me to make it.
In this case, Mad Skillz will be an excellent tool to be used to measure and define the targets.
Removing that ambiguity from Mad Skills and retro is not only to prevent it to be used as a checklist but also not to limit our retrospective process to be a checklist as well.
Not to dive too deeply into this can of worms, but linking MadSkillz to both personal growth and to promotion is not a good idea. People are not going to engage with it openly and honestly if they think they are putting future promotion / salary / career at risk, and that will really hamper true growth.
As @robdmoore said - MadSkillz (and therefore ReadiMe) is a small part in the overall promotion process - Go to Readdit > The Way We Work > Career Development and find the link to the Promotions page for detailed information on this.
MadSkillz and ReadiMe are first and foremost about growth, so any changes to it should be focused on that. If people don't like that because they want some sort of easy rubric for promotion, that's too bad.
As @glav and a few others have mentioned, some of us want the convenience and structure that a checklist such as the one now part of ReadiMe provides. I totally appreciate this. Allow me to quote from one of my favourite books: The Checklist Manifesto - it defines two kinds of checklists: Plan-Do and Do-Confirm. In my opinion, when someone is looking for a structured approach to grow themselves, what they are looking for is a Plan-Do checklist. With that bit of context, here's what I propose:
At the beginning of the quarter/retro cycle, those who prefer could agree on a checklist in the spirit of Plan-Do - here's what I'm planning to do this period of time. This is then a goal-setting exercise driven by the one who's planning their retro. This checklist may be inspired by MadSkillz but must be flexible enough to accommodate individual plans. At the end of the retro cycle, these people can then run through a retro and talk through how they did on the plan.
For others who want to adopt a different approach, the initial session could be used to set goals in a format they prefer - e.g. identify an area that they wish to work upon, a set of skills to learn - you get the idea.
A few thoughts on why I'm with @WillRay and see the current systems a tad limiting: while doing a retro recently through ReadiMe, I found it quite hard and overwhelming to go through each MadSkillz heading and sub-points and decide what do with it. It may not be intended but it felt like ticking boxes for the sake of it.