People are social. I'm particularly social and need real human connection at work. Assigning me a Jira ticket describing a task that you think is doing fails my needs of connections on so many levels that I needed to stop working and start writing.
The Communication
I appreciate every colleague that drops in (even virtually) and talks to me like people talk to one another. They tell about a problem they have, an aspiration they have, a wish they have in hopes of influencing me to do something for them or rather with them to make the world a better place. I could not be happier.
Surely there are too many things. There is uncertainty. But as we connect, we establish what other things I may have on my mind. We may agree that while they were hoping that they could just dump the work on me, I may be busy elsewhere and this stuff is too important to wait for me, and the person trying to do the dumping could even do it themselves. Sometimes we end up doing it together enabling the idea that I don't need to be the only one doing things like this. All through the connection.
This human to human communication seeking mutual benefits instead of assigning tasks is a source of happiness. The opposite is a source of unhappiness. And Jira tickets where someone is hoping to dump the work on me will never do the same thing as that person talking to me, caring about my response.
"What's the status with ABC-123?" is not how people talk to people they like, value and appreciate.
The Decomposition
When we have a goal to achieve, different people can achieve the goal differently and it does not mean that one way is ultimately the best one. Usually the best ways to achieve goals are ones that teach us the most and help us stay honest about where we really are with the end result. At least personally I'm not happy that we built the perfect "smart inventory" as we imagined it, if it does not serve purposes we had in mind for creating it and I don't see a change in behaviors with use of products with such a thing. I recognize however that other people see success already with accomplishing a task, not assessing whether the outcome is that we are in a better place for it.
When I am given a task in Jira that someone else wrote, I find I treat it as decomposition of a goal. I first spend time recomposing the tasks to the goal, and then re-decompose to ensure I can also feel that the original decomposition is high enough quality that I find my sense of purpose in doing the work assigned to me. This is a lot of energy used.
But it is not just the energy drain that is a problem. It is also the fact that more often than not, I find there are tasks in the negative space and we would end up delivering with quality below standards I can find myself comfortable with. I could do what you asked, but I wouldn't do what you wished and intended. So instead, why tell me the task, tell me what you wanted in the first place before you decomposed it for me as your decomposition isn't helping me.
If you decompose for me because you think I cannot, how will I learn when you always chew it for me? You may think I should be grateful for the work you do for me to help me but really: nobody's job should be to think for others but to grow others to think. Be there to support, give me feedback but let me do the work that makes me grow.
The Sense of Ownership
As a tester, I have grown to think that I look at things with an end in mind while people working with requirements often look at things with the beginning in mind. We both look all the way, but our emphasis in a different place, and because of it we see things differently.
A value item is not done for me until I have tested it in multiple ways, as per risk unique to each item. There is no recipe I follow for every single one, but there are patterns and heuristics that help me make those decisions. I look at the features we do in production, not only up to production and I learn of what I could improve on my work months, even years after first doing the work harvesting patterns that would prove me I am wrong now - like a true tester, seeking to falsify hypothesis is the way to get closer to being right about things.
I have grown a sense of ownership. I don't seek to avoid blame "I did what ticket ABC-123 said and it did not say to do X" but to learn from mistakes we made. FAIL is a First Attempt in Learning, and we are in it together. Someone else's plan that was wrong was my mistake on not decomposing the plan to find out how it was wrong and I may learn to make my choices differently or accept that the choices I made under conditions I was are choices I would do again, regardless of the result being less than perfect. Who seeks perfection anyway?
For me a ticket in Jira, closed without doing anything after six months, is an indication I created waste not value in writing that ticket. I don't believe there is inherent value in remembering all the ideas we have had that we did not act on. And looking at the tickets closing, the evidence still suggests that I need to look more of rejecting the hypothesis.
People, as per Pink's book Drive, are creatures looking for Autonomy, Mastery and Purpose. Sense of ownership is how I frame those in my work.
The Communication
I appreciate every colleague that drops in (even virtually) and talks to me like people talk to one another. They tell about a problem they have, an aspiration they have, a wish they have in hopes of influencing me to do something for them or rather with them to make the world a better place. I could not be happier.
Surely there are too many things. There is uncertainty. But as we connect, we establish what other things I may have on my mind. We may agree that while they were hoping that they could just dump the work on me, I may be busy elsewhere and this stuff is too important to wait for me, and the person trying to do the dumping could even do it themselves. Sometimes we end up doing it together enabling the idea that I don't need to be the only one doing things like this. All through the connection.
This human to human communication seeking mutual benefits instead of assigning tasks is a source of happiness. The opposite is a source of unhappiness. And Jira tickets where someone is hoping to dump the work on me will never do the same thing as that person talking to me, caring about my response.
"What's the status with ABC-123?" is not how people talk to people they like, value and appreciate.
The Decomposition
When we have a goal to achieve, different people can achieve the goal differently and it does not mean that one way is ultimately the best one. Usually the best ways to achieve goals are ones that teach us the most and help us stay honest about where we really are with the end result. At least personally I'm not happy that we built the perfect "smart inventory" as we imagined it, if it does not serve purposes we had in mind for creating it and I don't see a change in behaviors with use of products with such a thing. I recognize however that other people see success already with accomplishing a task, not assessing whether the outcome is that we are in a better place for it.
When I am given a task in Jira that someone else wrote, I find I treat it as decomposition of a goal. I first spend time recomposing the tasks to the goal, and then re-decompose to ensure I can also feel that the original decomposition is high enough quality that I find my sense of purpose in doing the work assigned to me. This is a lot of energy used.
But it is not just the energy drain that is a problem. It is also the fact that more often than not, I find there are tasks in the negative space and we would end up delivering with quality below standards I can find myself comfortable with. I could do what you asked, but I wouldn't do what you wished and intended. So instead, why tell me the task, tell me what you wanted in the first place before you decomposed it for me as your decomposition isn't helping me.
If you decompose for me because you think I cannot, how will I learn when you always chew it for me? You may think I should be grateful for the work you do for me to help me but really: nobody's job should be to think for others but to grow others to think. Be there to support, give me feedback but let me do the work that makes me grow.
The Sense of Ownership
As a tester, I have grown to think that I look at things with an end in mind while people working with requirements often look at things with the beginning in mind. We both look all the way, but our emphasis in a different place, and because of it we see things differently.
A value item is not done for me until I have tested it in multiple ways, as per risk unique to each item. There is no recipe I follow for every single one, but there are patterns and heuristics that help me make those decisions. I look at the features we do in production, not only up to production and I learn of what I could improve on my work months, even years after first doing the work harvesting patterns that would prove me I am wrong now - like a true tester, seeking to falsify hypothesis is the way to get closer to being right about things.
I have grown a sense of ownership. I don't seek to avoid blame "I did what ticket ABC-123 said and it did not say to do X" but to learn from mistakes we made. FAIL is a First Attempt in Learning, and we are in it together. Someone else's plan that was wrong was my mistake on not decomposing the plan to find out how it was wrong and I may learn to make my choices differently or accept that the choices I made under conditions I was are choices I would do again, regardless of the result being less than perfect. Who seeks perfection anyway?
For me a ticket in Jira, closed without doing anything after six months, is an indication I created waste not value in writing that ticket. I don't believe there is inherent value in remembering all the ideas we have had that we did not act on. And looking at the tickets closing, the evidence still suggests that I need to look more of rejecting the hypothesis.
People, as per Pink's book Drive, are creatures looking for Autonomy, Mastery and Purpose. Sense of ownership is how I frame those in my work.
