What can we change in MadSkillz to make it clear that the bulleted items are not prescriptive?

[WillRay]

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?

[WillRay]

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]

My opinion is that ReadiMe should be modified to make it clear they are just examples and that the most important thing is the defining characteristics.

…

-- On 16 May 2018, at 8:44 am, Will Ray <notifications@github.com<mailto:notifications@github.com>> wrote: 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FReadify%2Fmadskillz%2Fissues%2F102%23issuecomment-389358827&data=02%7C01%7Crob.moore%40readify.net%7C30513be44ae643f8901408d5bac622bf%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620282508477233&sdata=%2B6Y%2F30vL5gnwAUd14HeikKJBmpRkMUEAmIK3fxf6BS4%3D&reserved=0>, or mute the thread<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAjBXw8P6k-z9hUpa-JMvVJtciCitAr0ks5ty3ZWgaJpZM4UAeS6&data=02%7C01%7Crob.moore%40readify.net%7C30513be44ae643f8901408d5bac622bf%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620282508477233&sdata=uzrfpiyBQQhR%2FOdiLQxcNSx2AlJwwKN3WcP6NXytnLM%3D&reserved=0>.

[GianLorenzetto]

+1 to Rob’s comment. Regardless of how you write it in MadSkillz, if the tools we use for retro don’t emphasise the same point, then it will never be aligned. — Gian Lorenzetto gian.lorenzetto@gmail.com On 16 May 2018 at 8:46:12 am, Rob Moore (notifications@github.com) wrote: My opinion is that ReadiMe should be modified to make it clear they are just examples and that the most important thing is the defining characteristics.

-- On 16 May 2018, at 8:44 am, Will Ray <notifications@github.com<mailto: notifications@github.com>> wrote: 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub< https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FReadify%2Fmadskillz%2Fissues%2F102%23issuecomment-389358827&data=02%7C01%7Crob.moore%40readify.net%7C30513be44ae643f8901408d5bac622bf%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620282508477233&sdata=%2B6Y%2F30vL5gnwAUd14HeikKJBmpRkMUEAmIK3fxf6BS4%3D&reserved=0>, or mute the thread< https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAjBXw8P6k-z9hUpa-JMvVJtciCitAr0ks5ty3ZWgaJpZM4UAeS6&data=02%7C01%7Crob.moore%40readify.net%7C30513be44ae643f8901408d5bac622bf%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620282508477233&sdata=uzrfpiyBQQhR%2FOdiLQxcNSx2AlJwwKN3WcP6NXytnLM%3D&reserved=0

.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#102 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbJGTdavKKbBf-bp4PuMto8mFkelUJYks5ty3bUgaJpZM4UAeS6> .

[WillRay]

@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.

[GianLorenzetto]

I think that new Readifarians should be guided through their first retro and if the person facilitating the retro doesn’t understand that these are just examples, then changing the wording isn’t going to help all that much. Having said that, I do really like you’re change, especially to the phrasing of the examples. I’d be happy to take a stab at some of the others if you like. Gian — Gian Lorenzetto gian.lorenzetto@gmail.com On 16 May 2018 at 8:53:04 am, Will Ray (notifications@github.com) wrote: @robdmoore <https://github.com/robdmoore> @GianLorenzetto <https://github.com/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#102 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbJGZDHO8peVmnYpWvw36OIXmKkrsnlks5ty3hwgaJpZM4UAeS6> .

[robdmoore]

No, I agree with you that it could be clearer here, but that in ReadiMe it’s actively unclear and making it clear there will go a long way towards fixing the problem as people start to use it. That may make it a moot point then.

…

-- On 16 May 2018, at 8:53 am, Will Ray <notifications@github.com<mailto:notifications@github.com>> wrote: @robdmoore<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frobdmoore&data=02%7C01%7Crob.moore%40readify.net%7C47399c1a62e94ee1ebcb08d5bac7631b%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620287885543877&sdata=VxldSRJuTn9nMzWf5G8Nn5MAMRm4%2BxecKbee9wqal6Y%3D&reserved=0> @GianLorenzetto<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGianLorenzetto&data=02%7C01%7Crob.moore%40readify.net%7C47399c1a62e94ee1ebcb08d5bac7631b%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620287885543877&sdata=kokZrQ5qCH9c%2Fyy%2Fn1vgQybJL2GHOsnZGvEhwvYNd4A%3D&reserved=0> 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FReadify%2Fmadskillz%2Fissues%2F102%23issuecomment-389360146&data=02%7C01%7Crob.moore%40readify.net%7C47399c1a62e94ee1ebcb08d5bac7631b%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620287885553876&sdata=Ep9Xp5O5dRMGAKw06z6TJ8YT2uCx%2FMO7D%2FTuMK2FlEM%3D&reserved=0>, or mute the thread<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAjBXzosnfQj3RAnom79FkQZZ275JxcOks5ty3hwgaJpZM4UAeS6&data=02%7C01%7Crob.moore%40readify.net%7C47399c1a62e94ee1ebcb08d5bac7631b%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620287885553876&sdata=4bmPU%2B1LnuexSqYY23DSFVNcbiRscimhNB4%2BRhWhwZY%3D&reserved=0>.

[glav]

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.

[wtulloch]

Part of the problem has been that depending on the state the approach has been different. In Vic, especially when people pulled the defining characteristics out of Madskillz into something like excel, 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. Another thing is not everyone is comfortable with a more open ended approach. On the other side of the coin I agree that a “checkbox” approach can create the mistaken idea that the retro process becomes a career scorecard and the process becomes an exercise in ticking the boxes (and this wasn’t just with consultants). The first iteration of ReadiMe tried to accommodate the different approaches of each of the states but in trying to be flexible it has obviously introduced some confusion that needs to be addressed. Sent from Mail for Windows 10 From: Rob Moore Sent: Wednesday, 16 May 2018 10:57 AM To: Readify/madskillz Cc: Subscribed Subject: Re: [Readify/madskillz] What can we change in MadSkillz to make itclear that the bulleted items are not prescriptive? (#102) No, I agree with you that it could be clearer here, but that in ReadiMe it’s actively unclear and making it clear there will go a long way towards fixing the problem as people start to use it. That may make it a moot point then.

…

-- On 16 May 2018, at 8:53 am, Will Ray <notifications@github.com<mailto:notifications@github.com>> wrote: @robdmoore<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frobdmoore&data=02%7C01%7Crob.moore%40readify.net%7C47399c1a62e94ee1ebcb08d5bac7631b%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620287885543877&sdata=VxldSRJuTn9nMzWf5G8Nn5MAMRm4%2BxecKbee9wqal6Y%3D&reserved=0> @GianLorenzetto<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FGianLorenzetto&data=02%7C01%7Crob.moore%40readify.net%7C47399c1a62e94ee1ebcb08d5bac7631b%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620287885543877&sdata=kokZrQ5qCH9c%2Fyy%2Fn1vgQybJL2GHOsnZGvEhwvYNd4A%3D&reserved=0> 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FReadify%2Fmadskillz%2Fissues%2F102%23issuecomment-389360146&data=02%7C01%7Crob.moore%40readify.net%7C47399c1a62e94ee1ebcb08d5bac7631b%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620287885553876&sdata=Ep9Xp5O5dRMGAKw06z6TJ8YT2uCx%2FMO7D%2FTuMK2FlEM%3D&reserved=0>, or mute the thread<https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAjBXzosnfQj3RAnom79FkQZZ275JxcOks5ty3hwgaJpZM4UAeS6&data=02%7C01%7Crob.moore%40readify.net%7C47399c1a62e94ee1ebcb08d5bac7631b%7C413504eb862247d2aa72ddbba4584471%7C0%7C0%7C636620287885553876&sdata=4bmPU%2B1LnuexSqYY23DSFVNcbiRscimhNB4%2BRhWhwZY%3D&reserved=0>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[WillRay]

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!

[WillRay]

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.

[glav]

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.

[robdmoore]

"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.

[robdmoore]

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

[luizbon]

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.