Really great article Steven. Your strategy is so counter, in the best way, to modern dev organizations. Refreshing.
I'm curious – have you spoken to your team members on this? Do they experience your "slowness" as you do? Also, do you and your team plan sprints or work differently because of your strategy? And if so, how has that affected overall team culture and work?
I am a pretty open book when it comes to my struggles - I've definitely talked about this with many teammates over the years. Most of the feedback I get is supportive and positive, and many have pointed out (as many have in these comments) that in the long run, what I feel is "slowness" leads to work being fully complete faster. On the other hand, I've also gotten feedback to show my work more often and communicate progress better, and I'm working on those improvements.
I do think work is planned differently based on who is leading it. Projects that I'm leading end up with the more difficult challenges split into their own stories instead of rolled into others. If we're building an interface that has 5 subsections to it, some projects will have all 5 rolled into one story. If it's a project I'm leading, my preference is to break that into at least two stories: one that proves the connectivity end-to-end (and includes 1 of the 5 sections), and one or more stories for the remaining 4 sections. In contrast, I've taken a more supportive role on projects led by others where all 5 were rolled into one story, and that's definitely a place where I've struggled with my slowness and felt like progress is hard to show until it's basically almost done.
"how has that affected overall team culture" - that's a very interesting question. Autonomy is very important to me, and it's something I push for on every team I'm on. This means different projects can be worked in different ways, based on who is leading them. I could see a lack of uniformity being frustrating for people who like consistency. I like my teams to feel like people have control over how they think about a problem or build something, though.
That makes total sense. A huge and hard lesson of leadership is removing yourself from how people get to solutions – a lot of folks have a penchant to control the whole process versus managing the solution.
I'm interested to see how organizations and cultures start to evolve for all kinds of work methodology and speed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Really great article Steven. Your strategy is so counter, in the best way, to modern dev organizations. Refreshing.
I'm curious – have you spoken to your team members on this? Do they experience your "slowness" as you do? Also, do you and your team plan sprints or work differently because of your strategy? And if so, how has that affected overall team culture and work?
Thanks!
I am a pretty open book when it comes to my struggles - I've definitely talked about this with many teammates over the years. Most of the feedback I get is supportive and positive, and many have pointed out (as many have in these comments) that in the long run, what I feel is "slowness" leads to work being fully complete faster. On the other hand, I've also gotten feedback to show my work more often and communicate progress better, and I'm working on those improvements.
I do think work is planned differently based on who is leading it. Projects that I'm leading end up with the more difficult challenges split into their own stories instead of rolled into others. If we're building an interface that has 5 subsections to it, some projects will have all 5 rolled into one story. If it's a project I'm leading, my preference is to break that into at least two stories: one that proves the connectivity end-to-end (and includes 1 of the 5 sections), and one or more stories for the remaining 4 sections. In contrast, I've taken a more supportive role on projects led by others where all 5 were rolled into one story, and that's definitely a place where I've struggled with my slowness and felt like progress is hard to show until it's basically almost done.
"how has that affected overall team culture" - that's a very interesting question. Autonomy is very important to me, and it's something I push for on every team I'm on. This means different projects can be worked in different ways, based on who is leading them. I could see a lack of uniformity being frustrating for people who like consistency. I like my teams to feel like people have control over how they think about a problem or build something, though.
That makes total sense. A huge and hard lesson of leadership is removing yourself from how people get to solutions – a lot of folks have a penchant to control the whole process versus managing the solution.
I'm interested to see how organizations and cultures start to evolve for all kinds of work methodology and speed.