The last couple of years I have tended to write blog posts at the change of the year. One to summarize the year that is ending and one to list the things I am looking forward to in the coming year. This time it is different. It feels different.
Changes
Much has happened this year. As I was considering how to encapsulate it, I read over the posts on changing from 2011 to 2012. I must admit, I had to smile. Much has happened, still much remains to be done.
What has happened? Well, in August I submitted my resignation to the company where I was working. My "old company" had been bought by a much larger competitor and I found myself in a struggle to keep myself focused on what my goals and values were. I was a little surprised because I had worked for large companies in the past - most of my working life in fact, had been with large companies.
The surprising thing to the person I was a few years ago, was that I resigned without a "company" to go to. I went independent. I struck out on my own with a letter of marque sailing against any and every - oh, no, umm - that is being a privateer - not a working independent test professional. Meh, whatever.
But, that is what I did. The roots for this lie in this post I wrote late in 2011. Looking back, it was the natural progression of where I was going from and where I was going to.
Now, I did have a contract lined up - which has since been extended. This made the opportunity a little easier than jumping in cold-turkey - or deciding to go independent after being let go. I concede this was an advantage.
Of course, now I am working even harder - not simply at "the day job" but in my writing, my learning and my attempts to understand things better. The push from being sacked, as described in the blog post mentioned above, seems to have led me to the point where I hoisted my own flag, and have so far, avoided being hoist with my own petard.
People
I have been very fortunate in my meetings and comings and goings this past year. Given the opportunity to speak in Portland at PNSQC and then in Potsdam at Agile Testing Days, I met a massive number of people I had only read of, or read their words. It was inspiring, encouraging and humbling all at once. In both instances, I found it easy to not be the smartest person in the room. I had a pile of people there I could relate to and learn from.
To each of you, I am deeply indebted. Its a long list - let's see. There's Matt Heusser, who is still a bundle of energy and ideas. Michael Larsen, who is really amazingly smart. Bernie Berger, Markus Gartner, Janet Gregory, Gojko Adzic, Huib Schoots, Sigge Birgisson, Paul Gerrard, Simon Morley, Jurgen Appelo, James Lindsay, Michael Dedolph, Linda Rising, Ben Simo, and.... the list really does kind of go on.
The people I continue to find to be wonderful teachers and gentle instructors (sometimes not so gentle as well) sometimes through conversation, emails, IM/Skype chats, blog posts and articles. They include, in no particular order, Elizabeth Hendrickson, Fiona Charles, James Bach, Paul Holand, Michael Bolton, Cem Kaner, Jon Bach, Catherine Powell, Griffin Jones. There are others, but these folks came to mind as I was writing this.
Community
Wow. This year has been amazing. The local group, the GR Testers, are meeting every month, with a variety of people showing up - not "the same folks every time" but people wandering in to check it out. I find this exciting.
AST - Association for Software Testing
What an amazing group of people this is, and is continuing to develop into. The Education Special Interest Group (EdSIG) is continuing to be an area of interest. Alas, my intention of participating in "more courses" has been impacted by life stuff. I've been able to assist with a couple of Foundations sessions for the BBST course, and offered ideas on some discussions but that is about all.
This past August I was honored to be elected to the Board of Directors of AST. My participation continues to be as much as I can give on a regular basis - including monitoring/moderating the Forums on the AST website (a really under utilized resource, perhaps we can change this in the coming year) and the LinkedIn AST group's discussion forum (mostly whacking spam).
A new and exciting development is the Test Leadership Special Interest Group - LeadershipSIG. This new group is looking into all sorts of interesting questions around Test Management and Test Leadership and - well - stuff - including the interesting question of the difficulty of finding and recruiting Context Driven Test leaders, managers and directors.
CAST is scheduled for August in Madison, Wisconsin. This is going to be good.
Other Conference / Community Stuff
Conferences coming up include STPCon - in San Diego in April. Also in April is GLSEC - Great Lakes Software Excellence Conference - that one is in Grand Rapids. QAI's QUEST conference is also scheduled for the Spring.
There are several conferences I've considered submitting proposals to - and I suspect it is time to do more than consider.
Writing - Oh my. I have several projects I've been working through. I am really excited about some of the potential opportunities. I'm pretty geeked about this.
Overall, I am excited about what 2013 may hold. It strikes me that things that have been set up over the last several years are coming into place. What is in store? I do not know. I believe it is going to be good.
After all. I am writing this the evening of December 23. According to some folks, the world was supposed to end a couple of days ago. What those folks don't understand is that everything changes. All the time. Marking sequences and patterns and tracking them is part of what every society does. They don't end. Simply turn the page.
Let us rise up together.
Showing posts with label leadership. Show all posts
Showing posts with label leadership. Show all posts
Monday, December 24, 2012
Tuesday, May 1, 2012
On Managing Testers, or Being a Coach
I had a revelation recently that I wish I could have had some time ago, like years. It may have made me a better employee, and in my forays at lead and manager roles would have made me better at both.
While my thoughts here probably don't rise to the level of great writing that can be found for the betterment of leaders everywhere, it represents the sum of experience and belief demonstrated by many managers and leads I have worked for and with. I trust that some may find it useful and help them manage testers perhaps better than they might without such thoughts.
1. Encourage Learning. This is important. There is a significant difference between "training" and "learning." Encourage your staff to look for ideas new to them and try things they have read about. Don't bog them down with mandated, "This is the only way things are done" type of rote memorization. Allow them to explore areas of interest to them, then gently guide them with how these can be applied to their current and future work.
2. Discourage Self-limiting Behavior. Kind of a contradiction, eh? But really - anyone who has been around the block more than once has seen more than one person set themselves up for failure. Maybe they like it. Maybe they don't know any other way of doing things. Help them discover what they are good at, what they enjoy doing and what they want to do and maybe other ways of doing things.
3. Encourage Participation. I have found that one great way for people to learn and appreciate things, is to have a hand in the doing of it. I know everyone is busy and is scheduled at 110%. Well manager, MANAGE - encourage your staff to get involved - then make sure they have the time to do it without missing their kids school programs and family vacations and trips away and holidays and... right. You get the idea. The hard part about being a boss is telling other people "No." And yet, we need to do that all the time, right? This is just one more reason why you must tell someone "No," or if that makes you uncomfortable, try my favorite alternative "We can not work on that right now. We should be able to start on it by ..."
4. Discourage Lockstep Conformity. I know we must all follow the process or whatever is in place at the company. Sometimes it takes people with a lot more pull than we have to change the rules. Well, sometimes bending the rules to let your people flourish is important too. Allow them the space to be creative in approaching problems. Allow them time to THINK. Remember when you'd think about something deep and technical? I still find a proper cup of tea, with a bit of sugar and a little milk, just sitting and sipping it, can help my brain unravel a problem that is in my way. Allow your people the same room for creativity and innovation - particularly if there is no Time Reporting Code for that on their time sheets.
5. Encourage Innovation. I find this tends to flow from what happens in number 4. Sometimes thinking leads to a new approach. This approach can take a little tinkering to get sorted just to see if it will work. Give your people, that's what they are after all, people, the flexibility they need. Don't force it on them, but if they want to try - let them. Then help them learn and clear the path of roadblocks in ways only a Manager can.
6. Discourage Disparaging Comments. Negativity can be a serious drain on energy and morale and productivity. If one of your people is down, a lot - see if you can help. It might be nothing you can fix, but maybe just letting them know you are concerned is a help. Then lighten their load, if possible, so they have the energy to deal with whatever is weighing them down. If they are just being, well, negative for the sake of being negative, talk with them about that too. Everyone gets down. Everyone has a bad day (sometimes a week!) Everyone has times when they'd rather be at the beach or the woods or... whatever. We just need to get the job done. Then let them go to the woods or beach or wherever. Just keep an eye on folks - If they know you have their well-being in mind, more than just what they do at work, they may turn around and surprise you.
7. Encourage Growth. This one is a mix of "mentor" and "coach." I know some people look to mentors for some level of guidance and teaching. If you can do that for your people - fantastic! Otherwise, keep an eye out for people who CAN do that - then get the mentors and students connected and allow things to happen - don't force them. One thing I have learned is this. Most technical professional types have a failing, somewhere. One common one I have found is how they relate to other people - technical peers and non-technical as well. It is amusing that so many people consider testers "non-technical" still, compared to some, most of us are. Compared to others, we're technical rock stars. Help them to navigate these waters. Help them to learn to do them better. Help them to learn to be a better team, and give them transferable skills they can use anywhere.
8. Don't be the Control freak. Like this guy. If you're my boss and you do those things, I'll quit. Promise.
Lessons Learned - I've seen these ideas applied often at various shops. Where two or three are used effectively, the result has been stupendous. The staff revel from one positive experience to another, the software gets better from one project to another, practices improve and, surprisingly at some shops, customer satisfaction went up - way up.
Remember: Managers are the oracles of the Truth, but the people working for them are the spirit that make that truth relevant. My wife used to say (when the kids were younger, at least, not in their 30's) "If Mama ain't happy, nobody's happy." You can set the tone - will you be happy and uplifting or a burden to be endured? By setting an example in attitude, work, learning and life balance, a good manager can do more than simply qualify for stock options and large bonus checks.
While my thoughts here probably don't rise to the level of great writing that can be found for the betterment of leaders everywhere, it represents the sum of experience and belief demonstrated by many managers and leads I have worked for and with. I trust that some may find it useful and help them manage testers perhaps better than they might without such thoughts.
1. Encourage Learning. This is important. There is a significant difference between "training" and "learning." Encourage your staff to look for ideas new to them and try things they have read about. Don't bog them down with mandated, "This is the only way things are done" type of rote memorization. Allow them to explore areas of interest to them, then gently guide them with how these can be applied to their current and future work.
2. Discourage Self-limiting Behavior. Kind of a contradiction, eh? But really - anyone who has been around the block more than once has seen more than one person set themselves up for failure. Maybe they like it. Maybe they don't know any other way of doing things. Help them discover what they are good at, what they enjoy doing and what they want to do and maybe other ways of doing things.
3. Encourage Participation. I have found that one great way for people to learn and appreciate things, is to have a hand in the doing of it. I know everyone is busy and is scheduled at 110%. Well manager, MANAGE - encourage your staff to get involved - then make sure they have the time to do it without missing their kids school programs and family vacations and trips away and holidays and... right. You get the idea. The hard part about being a boss is telling other people "No." And yet, we need to do that all the time, right? This is just one more reason why you must tell someone "No," or if that makes you uncomfortable, try my favorite alternative "We can not work on that right now. We should be able to start on it by ..."
4. Discourage Lockstep Conformity. I know we must all follow the process or whatever is in place at the company. Sometimes it takes people with a lot more pull than we have to change the rules. Well, sometimes bending the rules to let your people flourish is important too. Allow them the space to be creative in approaching problems. Allow them time to THINK. Remember when you'd think about something deep and technical? I still find a proper cup of tea, with a bit of sugar and a little milk, just sitting and sipping it, can help my brain unravel a problem that is in my way. Allow your people the same room for creativity and innovation - particularly if there is no Time Reporting Code for that on their time sheets.
5. Encourage Innovation. I find this tends to flow from what happens in number 4. Sometimes thinking leads to a new approach. This approach can take a little tinkering to get sorted just to see if it will work. Give your people, that's what they are after all, people, the flexibility they need. Don't force it on them, but if they want to try - let them. Then help them learn and clear the path of roadblocks in ways only a Manager can.
6. Discourage Disparaging Comments. Negativity can be a serious drain on energy and morale and productivity. If one of your people is down, a lot - see if you can help. It might be nothing you can fix, but maybe just letting them know you are concerned is a help. Then lighten their load, if possible, so they have the energy to deal with whatever is weighing them down. If they are just being, well, negative for the sake of being negative, talk with them about that too. Everyone gets down. Everyone has a bad day (sometimes a week!) Everyone has times when they'd rather be at the beach or the woods or... whatever. We just need to get the job done. Then let them go to the woods or beach or wherever. Just keep an eye on folks - If they know you have their well-being in mind, more than just what they do at work, they may turn around and surprise you.
7. Encourage Growth. This one is a mix of "mentor" and "coach." I know some people look to mentors for some level of guidance and teaching. If you can do that for your people - fantastic! Otherwise, keep an eye out for people who CAN do that - then get the mentors and students connected and allow things to happen - don't force them. One thing I have learned is this. Most technical professional types have a failing, somewhere. One common one I have found is how they relate to other people - technical peers and non-technical as well. It is amusing that so many people consider testers "non-technical" still, compared to some, most of us are. Compared to others, we're technical rock stars. Help them to navigate these waters. Help them to learn to do them better. Help them to learn to be a better team, and give them transferable skills they can use anywhere.
8. Don't be the Control freak. Like this guy. If you're my boss and you do those things, I'll quit. Promise.
Lessons Learned - I've seen these ideas applied often at various shops. Where two or three are used effectively, the result has been stupendous. The staff revel from one positive experience to another, the software gets better from one project to another, practices improve and, surprisingly at some shops, customer satisfaction went up - way up.
Remember: Managers are the oracles of the Truth, but the people working for them are the spirit that make that truth relevant. My wife used to say (when the kids were younger, at least, not in their 30's) "If Mama ain't happy, nobody's happy." You can set the tone - will you be happy and uplifting or a burden to be endured? By setting an example in attitude, work, learning and life balance, a good manager can do more than simply qualify for stock options and large bonus checks.
Monday, April 30, 2012
On Controlling Testing, or Being the Boss
I had a revelation recently that I wish I could have had some time ago, like years. It may have made me a better employee, and in my forays at boss-dom would have made me a better boss.
While my humble outline here may not be enshrined amongst the great writings on leadership that are available for the betterment of leaders everywhere, it certainly represents the sum of experience and belief demonstrated by many boss-types I have worked for and with. I therefore submit this for consideration toward your professional success as a controlling boss and the success of the group (we'll call them a team) over which you have control.
1. Encourage Training. This is important. This is really important. You want your testers (they like being called testers better than being called them peons of serfs) to believe that you want them to get better at what they do. Make sure they know that training is important to their career development. You want to make sure that the training they get is company sponsored training. Other stuff like, well, that encourages them to think is to be avoided, discouraged and downplayed.
2. Discourage Outside, Corrupting Influences. We want the people working for us to only consider the information we present to them as being relevant. When people express an interest in something they read about, maybe on the web somewhere, let them know that it is important they "get all the facts" before deciding to learn about it. Have them go looking for examples of companies where these wild, new-fangled ideas have actually worked. When they come back with some examples, make sure they know that these are not really solid examples because they are from outside the industry you are in, or are multi-national, not multi-continental (other way around works as well!) or they are in environments that are regulated differently than the environment we are in or... any number of reasons why "that won't work here."
3. Encourage Engagement. This is important, too. You want them to feel warm-fuzzy thoughts in their tummies when they think of the company. They want them to think, "Wow. The bosses at TLA* really DO have my best interest at heart when they tell me to do something and I'll be rewarded later. I hope I get a pony as my reward." This is particularly effective in large urban areas where the belief that a pony might be the "reward"is a complete impossibility where the large urban area does not permit ponies within the city. The idea is similar to "A rising tide lifts all boats." That is true, as long as the boats in question have plenty of slack where they are tied-up or moored. We want to be certain there is no slack at all for thepeople doing our bidding team, before the tide starts rising.
*TLA: Three Letter Acronym (thanks to Matt Heusser from whom I blatantly stole that concept.)
4. Discourage Uncomfortable Questions. Well, not really discourage them, just redirect them to be discussed "off-line" so people are not side-tracked by "side issues like this." The beauty is that when people ask questions you don't want asked, you can appear to be concerned with addressing their concerns completely, and at the same time keep those questions, and the discussion around them, from causing discomfort to the rest of the laborers. This allows the quick-thinking manager to isolate the trouble, and trouble-maker, pat their hand and say "there, there" and reassure them that everything will be fine. The upside for the manager is the next round of "synergy actions"/"staff rationalization"/ happy-sizing / down-sizing, you already have at least one candidate for "change agent" status.
5. Encourage "Extra Effort". Getting people to get things done when most people looking at on schedules that simply can not be achieved at a mere 45 or 50 hours per week per person can be a particular management challenge. One effective technique is to make the "casual" observation that contracts are tied to these dates and the delivery must be made on time. Of course, if the delivery cannot be made on time, well, "other options" will need to be considered. Then, this leaves open the carrot of the "stretch goal" set a week or two ahead of the "mandated goal" - where completing the project early may get recognized with a raise (or at least not a pay cut) IF all the other projects get done on time or early as well. (Notice the subtle conditional statement slipped in there, its a possibility, not a certainty.)
6. Discourage Process Questions. Yeah, this is kind of a big deal, too. The Process is sacrosanct. You are not in a position to suggest improvements to the process until you have moved through it completely, successfully at least once. Well, maybe twice or three times (because success is a habit, after all.) If people are having problems working through the process, it is because they are not doing it right. If they do it right, they have no problems.
7. Encourage Participation. This one is important, too. One way to handle trouble-makers is to get them involved. If someone asks questions, like a lot of questions, ask if they'd be willing to participate in a study group that has been created to look into that very issue they ask questions about. It is a great way to get all the people you need to keep an eye on in one place. Additionally, because this must be done in addition to the project work (see number 5 above) it will be one more way to drain them of extra energy to make trouble. If they still complain, ask if they have been "participating" with the study group on the issues they are complaining about. If not, you just transferred blame to them! That is good leadership.
8. Discourage Independent Thought. This is a hard one and it may take all the previous lessons to pull this one off. You want people who can do decent testing. That means you may have to hire people from outside the company. That also means you may need to hire people with some level of experience. This experience may have given them ideas of their own, or at least carried the lessons they learned from previous jobs with them. Encourage them to "observe and learn" how things are done at your company. Then, use the ideas from number 6 above to get them to become fully assimilated into the mindset of the company. This will, hopefully, keep them from thinking something is wrong with the company by reinforcing the image that the problem is with them (after all, they left their old job because of why?)
Lessons Learned - I've seen these ideas applied often at various shops. Where two or three are used effectively, the result has been promotion for the manager who did such fine work. Of course, the fodder complained and whined until they were replaced or learned that complaining led to them "seeking new opportunities" - which pretty sell stopped the complaining. In public. Which is as good as stopping complaining altogether.
Remember: Managers are the keepers of the Truth. The Guardians of the Holy Flame of Knowledge. Facts can change and shift and using these techniques what the Manager agreed to on Monday, on Tuesday, if you are effective, you can disagree with and explain that the staff misunderstood. This technique is good for keeping them from ever really understanding what is expected, which is even better because the money set aside for raises and bonuses will go into your pocket.
While my humble outline here may not be enshrined amongst the great writings on leadership that are available for the betterment of leaders everywhere, it certainly represents the sum of experience and belief demonstrated by many boss-types I have worked for and with. I therefore submit this for consideration toward your professional success as a controlling boss and the success of the group (we'll call them a team) over which you have control.
1. Encourage Training. This is important. This is really important. You want your testers (they like being called testers better than being called them peons of serfs) to believe that you want them to get better at what they do. Make sure they know that training is important to their career development. You want to make sure that the training they get is company sponsored training. Other stuff like, well, that encourages them to think is to be avoided, discouraged and downplayed.
2. Discourage Outside, Corrupting Influences. We want the people working for us to only consider the information we present to them as being relevant. When people express an interest in something they read about, maybe on the web somewhere, let them know that it is important they "get all the facts" before deciding to learn about it. Have them go looking for examples of companies where these wild, new-fangled ideas have actually worked. When they come back with some examples, make sure they know that these are not really solid examples because they are from outside the industry you are in, or are multi-national, not multi-continental (other way around works as well!) or they are in environments that are regulated differently than the environment we are in or... any number of reasons why "that won't work here."
3. Encourage Engagement. This is important, too. You want them to feel warm-fuzzy thoughts in their tummies when they think of the company. They want them to think, "Wow. The bosses at TLA* really DO have my best interest at heart when they tell me to do something and I'll be rewarded later. I hope I get a pony as my reward." This is particularly effective in large urban areas where the belief that a pony might be the "reward"is a complete impossibility where the large urban area does not permit ponies within the city. The idea is similar to "A rising tide lifts all boats." That is true, as long as the boats in question have plenty of slack where they are tied-up or moored. We want to be certain there is no slack at all for the
*TLA: Three Letter Acronym (thanks to Matt Heusser from whom I blatantly stole that concept.)
4. Discourage Uncomfortable Questions. Well, not really discourage them, just redirect them to be discussed "off-line" so people are not side-tracked by "side issues like this." The beauty is that when people ask questions you don't want asked, you can appear to be concerned with addressing their concerns completely, and at the same time keep those questions, and the discussion around them, from causing discomfort to the rest of the laborers. This allows the quick-thinking manager to isolate the trouble, and trouble-maker, pat their hand and say "there, there" and reassure them that everything will be fine. The upside for the manager is the next round of "synergy actions"/"staff rationalization"/ happy-sizing / down-sizing, you already have at least one candidate for "change agent" status.
5. Encourage "Extra Effort". Getting people to get things done when most people looking at on schedules that simply can not be achieved at a mere 45 or 50 hours per week per person can be a particular management challenge. One effective technique is to make the "casual" observation that contracts are tied to these dates and the delivery must be made on time. Of course, if the delivery cannot be made on time, well, "other options" will need to be considered. Then, this leaves open the carrot of the "stretch goal" set a week or two ahead of the "mandated goal" - where completing the project early may get recognized with a raise (or at least not a pay cut) IF all the other projects get done on time or early as well. (Notice the subtle conditional statement slipped in there, its a possibility, not a certainty.)
6. Discourage Process Questions. Yeah, this is kind of a big deal, too. The Process is sacrosanct. You are not in a position to suggest improvements to the process until you have moved through it completely, successfully at least once. Well, maybe twice or three times (because success is a habit, after all.) If people are having problems working through the process, it is because they are not doing it right. If they do it right, they have no problems.
7. Encourage Participation. This one is important, too. One way to handle trouble-makers is to get them involved. If someone asks questions, like a lot of questions, ask if they'd be willing to participate in a study group that has been created to look into that very issue they ask questions about. It is a great way to get all the people you need to keep an eye on in one place. Additionally, because this must be done in addition to the project work (see number 5 above) it will be one more way to drain them of extra energy to make trouble. If they still complain, ask if they have been "participating" with the study group on the issues they are complaining about. If not, you just transferred blame to them! That is good leadership.
8. Discourage Independent Thought. This is a hard one and it may take all the previous lessons to pull this one off. You want people who can do decent testing. That means you may have to hire people from outside the company. That also means you may need to hire people with some level of experience. This experience may have given them ideas of their own, or at least carried the lessons they learned from previous jobs with them. Encourage them to "observe and learn" how things are done at your company. Then, use the ideas from number 6 above to get them to become fully assimilated into the mindset of the company. This will, hopefully, keep them from thinking something is wrong with the company by reinforcing the image that the problem is with them (after all, they left their old job because of why?)
Lessons Learned - I've seen these ideas applied often at various shops. Where two or three are used effectively, the result has been promotion for the manager who did such fine work. Of course, the fodder complained and whined until they were replaced or learned that complaining led to them "seeking new opportunities" - which pretty sell stopped the complaining. In public. Which is as good as stopping complaining altogether.
Remember: Managers are the keepers of the Truth. The Guardians of the Holy Flame of Knowledge. Facts can change and shift and using these techniques what the Manager agreed to on Monday, on Tuesday, if you are effective, you can disagree with and explain that the staff misunderstood. This technique is good for keeping them from ever really understanding what is expected, which is even better because the money set aside for raises and bonuses will go into your pocket.
Saturday, April 30, 2011
Stepping Up to Leadership: Lessons From Harry Potter
I was thinking some time ago about how people can be leaders without having the word "lead" or "leader" in their title. What is it that makes a leader? Do leaders become a leader intentionally? Well, I expect some folks do. Some of those, however, I don't really consider real leaders - maybe managers, maybe bosses, possibly control-freaks.
I'm reminded of a line from Robert Heinlein about the advantage of hereditary monarchs is that on occasion you get a reluctant ruler who simply wants to do a good job. Its the ones who really want the job that you have to look out for.
In the rather interesting meanderings of my mind I was thinking back to discussions I had many years and a few jobs ago. There were, in my opinion then and now, an awful lot of managers and directors and not nearly enough leaders. Real leaders. The kind of people that colleagues turn to, not because of official channels or management chain, but because they know that person, or people, might just be able to help.
In pondering just where these thoughts might go, it dawned on me that there were many, many examples of the kind of leadership that I was thinking of. As I was pondering what it was that I was trying to say and how to say it, a weekend movie marathon featuring a certain young wizard kicked off and I had my answer.
I got to thinking that many "leaders" don't intend to be leaders.
Start by Deciding to Start
Some feel like they don't quite fit in. They want to, they try to, and yet they simply don't feel satisfied with what is around them. They start looking for something else, something that maybe they can't quite put their finger on. They are still trying to fit in, not knowing why they don't or can't and then the Owl shows up. Well, maybe not an owl with an admission letter to Hogwarts, but something clicks. Something triggers, well, something.
For those of us without an owl, that "something" can be a decision that there is more out there - that taking charge of your own career is what you need to do. Maybe the feeling that you have had enough of other people making decisions for them about your career.
It is more than making you better at you job or making you more valuable to your company. It is making you more valuable to you. It is becoming a tradesman and craftsman instead of a laborer.
The first step when that "something" happens, is to find a mentor, a guide to help you. It may not be Albus Dumbledore, but someone with the experience and patience to guide and teach you is needed.
Study and Self-Education
Then, when you have found a mentor, study the craft of software testing. Online materials, blogs, articles, testing forums, all can help you find information. Books and magazines are great and many are available for download to e-readers.
Begin your learning by self-education. Then, you can turn to your mentor for guidance and clarification. Seek out ideas new to you. Challenge what you have been doing and what you are reading and focus on learning your craft.
Harry studies and is willing to branch out beyond what the various professors are teaching in class. If a 12 year old boy is brave enough to do that, what is stopping you?
Learn by Doing
The next step is to find the guts to actually try stuff new to you. Now, it may be new to the company as well, but that is OK. Now, it might be a really, really good idea to have a more experienced person looking over your shoulder when you try this the first time.
Doing something the first time, whether its the first time for just you or the first time for the company, can take a fair amount of courage. Reaching out and stretching to try and extend your abilities can be a little scary sometimes. Particularly if your expected results are uncertain.
Now, while it is unlikely that a hippogriff might rip your arm off if you are too forward, it may be that your pride may take a hit if your first attempt does not succeed. Not to worry. Trying something new always takes courage.
If results are "less than optimal" then look to what happened. Look to see where you went wrong and correct it the next time. If there is not a next time, it means that those who were making decisions for you will continue to always make decisions for you. That is why you stepped out, right? So try it again!
The fact is, sometimes the results can be absolutely astounding. You and those around you may very well be amazed at what you can achieve simply by trying to achieve it. Now, it may not be riding on the back of a flying animal most folks consider mythological, but it may be astounding in a technological sense for your shop and your company.
Networking: Building Relationships
One thing you must do, find some "friends." Now, many of us have "friends" we can hang with. That isn't what I mean. I mean that you should find people you can talk with about what you are trying to do, what you are trying to learn. Chances are, they will take an interest in it and share what they are trying to learn as well. They can be valuable to help compare notes and share experiences with.
The amazing thing is that they don't have to be in the same company as you, not even in the same city or town as you. Conferences (local, regional, national and international) are great resources for this - but may be rather pricey if the boss does not agree to foot the bill. Local testing groups can be a great option as well. If there is not group around you, START one!
I bet that you know people who work at other companies. I bet you know people at other companies who are testers or know testers or work with testers. Get in touch with them and bounce the idea around about starting a local testing group. (See how easy that is? You just started building relationships!)
Yeah, there may be some folks who know more than others do, or think they do (Hermione...) and that's OK. There is no reason why they won't have valuable insight into what you are talking about.
The thing is, be patient and grow and nurture your contacts list - your network. You may find yourself having others in your circle reaching out to you while you continue to learn.
Helping Others While You Learn
Now, you may think that won't happen. You may think it can't happen ("What do I know anyway? I'm no expert!") That's OK. You don't have to be an expert. You may need to think carefully.
Someone will ask questions of you, based on your experience. When that happens, and it will, see this as another opportunity for you to learn yourself, and teach others what you have already learned. Now, you may not be learning the same thing. Its possible, but it is not a certainty.
They need help in an area where you have learned something. You may be able to provide it. You may also learn how to help others and in doing so learn another skill.
It is also OK if you express you own reservations to them. You can say "Yeah, I did this but I had people helping me..." The fact is, you did it and now you can help others.
Achieving Things You Never Thought You Could
The more you learn and the more you can apply what you learn, things that once seemed impossible for you will become regular occurrences, if not commonplace. Activities and events and practices that you once would not, or could not, dream of doing will become the norm.
You will then be able to reach out and impact things you never dreamed you could do. When this happens others will congratulate you - and encourage you to greater bounds. Others may turn to you and seek advice on things you have not thought about. Still others may ask you to help them with their problems, even if it is only to talk with them while having a coffee or tea or, something a bit stronger.
Being a Leader
The process of becoming a "leader" is never ending. There are always new areas to explore and new ideas to consider. Sometimes the ideas are revisiting old ideas and challenging some of the presumptions.
The point is, learning never ends. No person can ever learn everything there is to know on a topic. Speaking for myself, and not Harry, the more I learn, the more I realize I do not know and want to learn about.
I don't consider myself a leader, or an expert. Some other people have called me both. If they need a bucket to fit me in for their understanding and defining a relationship with me, that is fine. That part is not about me. The part that is about me is that I can learn and share what I have learned with others.
Mischief Managed.
I'm reminded of a line from Robert Heinlein about the advantage of hereditary monarchs is that on occasion you get a reluctant ruler who simply wants to do a good job. Its the ones who really want the job that you have to look out for.
In the rather interesting meanderings of my mind I was thinking back to discussions I had many years and a few jobs ago. There were, in my opinion then and now, an awful lot of managers and directors and not nearly enough leaders. Real leaders. The kind of people that colleagues turn to, not because of official channels or management chain, but because they know that person, or people, might just be able to help.
In pondering just where these thoughts might go, it dawned on me that there were many, many examples of the kind of leadership that I was thinking of. As I was pondering what it was that I was trying to say and how to say it, a weekend movie marathon featuring a certain young wizard kicked off and I had my answer.
I got to thinking that many "leaders" don't intend to be leaders.
Start by Deciding to Start
Some feel like they don't quite fit in. They want to, they try to, and yet they simply don't feel satisfied with what is around them. They start looking for something else, something that maybe they can't quite put their finger on. They are still trying to fit in, not knowing why they don't or can't and then the Owl shows up. Well, maybe not an owl with an admission letter to Hogwarts, but something clicks. Something triggers, well, something.
For those of us without an owl, that "something" can be a decision that there is more out there - that taking charge of your own career is what you need to do. Maybe the feeling that you have had enough of other people making decisions for them about your career.
It is more than making you better at you job or making you more valuable to your company. It is making you more valuable to you. It is becoming a tradesman and craftsman instead of a laborer.
The first step when that "something" happens, is to find a mentor, a guide to help you. It may not be Albus Dumbledore, but someone with the experience and patience to guide and teach you is needed.
Study and Self-Education
Then, when you have found a mentor, study the craft of software testing. Online materials, blogs, articles, testing forums, all can help you find information. Books and magazines are great and many are available for download to e-readers.
Begin your learning by self-education. Then, you can turn to your mentor for guidance and clarification. Seek out ideas new to you. Challenge what you have been doing and what you are reading and focus on learning your craft.
Harry studies and is willing to branch out beyond what the various professors are teaching in class. If a 12 year old boy is brave enough to do that, what is stopping you?
Learn by Doing
The next step is to find the guts to actually try stuff new to you. Now, it may be new to the company as well, but that is OK. Now, it might be a really, really good idea to have a more experienced person looking over your shoulder when you try this the first time.
Doing something the first time, whether its the first time for just you or the first time for the company, can take a fair amount of courage. Reaching out and stretching to try and extend your abilities can be a little scary sometimes. Particularly if your expected results are uncertain.
Now, while it is unlikely that a hippogriff might rip your arm off if you are too forward, it may be that your pride may take a hit if your first attempt does not succeed. Not to worry. Trying something new always takes courage.
If results are "less than optimal" then look to what happened. Look to see where you went wrong and correct it the next time. If there is not a next time, it means that those who were making decisions for you will continue to always make decisions for you. That is why you stepped out, right? So try it again!
The fact is, sometimes the results can be absolutely astounding. You and those around you may very well be amazed at what you can achieve simply by trying to achieve it. Now, it may not be riding on the back of a flying animal most folks consider mythological, but it may be astounding in a technological sense for your shop and your company.
Networking: Building Relationships
One thing you must do, find some "friends." Now, many of us have "friends" we can hang with. That isn't what I mean. I mean that you should find people you can talk with about what you are trying to do, what you are trying to learn. Chances are, they will take an interest in it and share what they are trying to learn as well. They can be valuable to help compare notes and share experiences with.
The amazing thing is that they don't have to be in the same company as you, not even in the same city or town as you. Conferences (local, regional, national and international) are great resources for this - but may be rather pricey if the boss does not agree to foot the bill. Local testing groups can be a great option as well. If there is not group around you, START one!
I bet that you know people who work at other companies. I bet you know people at other companies who are testers or know testers or work with testers. Get in touch with them and bounce the idea around about starting a local testing group. (See how easy that is? You just started building relationships!)
Yeah, there may be some folks who know more than others do, or think they do (Hermione...) and that's OK. There is no reason why they won't have valuable insight into what you are talking about.
The thing is, be patient and grow and nurture your contacts list - your network. You may find yourself having others in your circle reaching out to you while you continue to learn.
Helping Others While You Learn
Now, you may think that won't happen. You may think it can't happen ("What do I know anyway? I'm no expert!") That's OK. You don't have to be an expert. You may need to think carefully.
Someone will ask questions of you, based on your experience. When that happens, and it will, see this as another opportunity for you to learn yourself, and teach others what you have already learned. Now, you may not be learning the same thing. Its possible, but it is not a certainty.
They need help in an area where you have learned something. You may be able to provide it. You may also learn how to help others and in doing so learn another skill.
It is also OK if you express you own reservations to them. You can say "Yeah, I did this but I had people helping me..." The fact is, you did it and now you can help others.
Achieving Things You Never Thought You Could
The more you learn and the more you can apply what you learn, things that once seemed impossible for you will become regular occurrences, if not commonplace. Activities and events and practices that you once would not, or could not, dream of doing will become the norm.
You will then be able to reach out and impact things you never dreamed you could do. When this happens others will congratulate you - and encourage you to greater bounds. Others may turn to you and seek advice on things you have not thought about. Still others may ask you to help them with their problems, even if it is only to talk with them while having a coffee or tea or, something a bit stronger.
Being a Leader
The process of becoming a "leader" is never ending. There are always new areas to explore and new ideas to consider. Sometimes the ideas are revisiting old ideas and challenging some of the presumptions.
The point is, learning never ends. No person can ever learn everything there is to know on a topic. Speaking for myself, and not Harry, the more I learn, the more I realize I do not know and want to learn about.
I don't consider myself a leader, or an expert. Some other people have called me both. If they need a bucket to fit me in for their understanding and defining a relationship with me, that is fine. That part is not about me. The part that is about me is that I can learn and share what I have learned with others.
Mischief Managed.
Thursday, December 30, 2010
A Hero's Fall From Grace or Why a Big Pay Raise Is Better Than a Statue
A couple of things happened recently that made me think of things I probably would not normally think of.
I know a fellow who works for a company that has one or two (depending on needs) "major" releases each year. They also generate and distribute monthly maintenance releases to address defects, bundle hot-fixes neatly into a package and all the other good things that come from such things.
A recent release had some "issues." Lots of issues. After working for 12 "work" days and a Saturday and Sunday thrown in as well, this fellow's boss made a comment that he had "saved them again" and was a "hero."
When thinking about this, I got to thinking about Selena Delesie's blog posts on "hero culture."
When teams pull together and work to overcome obstacles, amazing things can be achieved. Sometimes, the issues encountered require extra effort and creative thinking and good, if not great, communication between testers and developers to find solutions. This is a fantastic thing and is, I believe, the point of being a "hero" in our profession.
The part that makes me think, if not wonder, about this is when this becomes the rule, rather than the exception. When the same team that pulled together and found solutions and worked toward delivering the best product that can be delivered is expected to work long hours regularly, to repeat the same "pull out all stops" effort for every project, big or small, there is a danger.
That danger is that the edge, the creative thinking, the "Hey, what if..." factor gets worn down.
Now, I know there are a lot of potential reasons for this to happen. Some may be within the team itself. There may be factors at work where individuals like the drama, the "rush" of the massive push at the end.
There may also be issues around the development methodology or practices. If the only testing done in unit testing is validating the "happy path" then likelihood that builds will come fast and furious, depending on how quickly the detected defects are addressed.
Another possibility is that someone, possibly in the test group or outside the test group but involved in the projects, likes the chaos - the frantic push is something they thrive on.
Whatever the cause, when every project turns into a heroic stand worthy of an action movie, something is seriously wrong. When testers, or anyone else, are expected to perform super-human, or heroic, feats every project, the edge will be blunted. The probability of significant defects being missed increases with each cycle. Eventually, people will be working less effectively no matter how many hours, or how "hard" they are working.
In some shops, the option to simply say "No, I won't do this" may be a legitimate one. In shops where contractual requirements don't allow such a response, I don't have a solution. Now, I am aware of the need to keep regular releases going, I'm just not sure of a solution that works everywhere.
What I do know is that the bosses, the leaders at your shop need to make sure they don't need their people to be heroes each and every release. Horatius held the bridge, but he had help. The lone cowboy was a myth, just like superman.
I know a fellow who works for a company that has one or two (depending on needs) "major" releases each year. They also generate and distribute monthly maintenance releases to address defects, bundle hot-fixes neatly into a package and all the other good things that come from such things.
A recent release had some "issues." Lots of issues. After working for 12 "work" days and a Saturday and Sunday thrown in as well, this fellow's boss made a comment that he had "saved them again" and was a "hero."
When thinking about this, I got to thinking about Selena Delesie's blog posts on "hero culture."
When teams pull together and work to overcome obstacles, amazing things can be achieved. Sometimes, the issues encountered require extra effort and creative thinking and good, if not great, communication between testers and developers to find solutions. This is a fantastic thing and is, I believe, the point of being a "hero" in our profession.
The part that makes me think, if not wonder, about this is when this becomes the rule, rather than the exception. When the same team that pulled together and found solutions and worked toward delivering the best product that can be delivered is expected to work long hours regularly, to repeat the same "pull out all stops" effort for every project, big or small, there is a danger.
That danger is that the edge, the creative thinking, the "Hey, what if..." factor gets worn down.
Now, I know there are a lot of potential reasons for this to happen. Some may be within the team itself. There may be factors at work where individuals like the drama, the "rush" of the massive push at the end.
There may also be issues around the development methodology or practices. If the only testing done in unit testing is validating the "happy path" then likelihood that builds will come fast and furious, depending on how quickly the detected defects are addressed.
Another possibility is that someone, possibly in the test group or outside the test group but involved in the projects, likes the chaos - the frantic push is something they thrive on.
Whatever the cause, when every project turns into a heroic stand worthy of an action movie, something is seriously wrong. When testers, or anyone else, are expected to perform super-human, or heroic, feats every project, the edge will be blunted. The probability of significant defects being missed increases with each cycle. Eventually, people will be working less effectively no matter how many hours, or how "hard" they are working.
In some shops, the option to simply say "No, I won't do this" may be a legitimate one. In shops where contractual requirements don't allow such a response, I don't have a solution. Now, I am aware of the need to keep regular releases going, I'm just not sure of a solution that works everywhere.
What I do know is that the bosses, the leaders at your shop need to make sure they don't need their people to be heroes each and every release. Horatius held the bridge, but he had help. The lone cowboy was a myth, just like superman.
Tuesday, November 30, 2010
Through the Looking Glass or the Fear Factor of Management
I finally have a bit of time to try and catch up on some reading. I don't know how strange this is, but I tend to read the same book two or three times, particularly if I can only read small segments at a time. As I'm not the widely travelled road-warrior spending long hours waiting in airport terminals, and when I am sitting in airport terminals I tend to have a stack of day-job stuff to read/respond to, I find myself falling farther and farther behind in my reading. The result is, I sometimes get to read a paragraph or two of a book, then get called away to deal with something.
I've been working my way through two books over the Thanksgiving weekend, both on software. Which ones do not really matter. I resolved to start the smaller one over completely and see if reading entire pages at a time made it better. (It did.)
I have also been trying to catch up on my long-list of blog posts that I intended to read and see what the great ones of our craft can teach me. The answer was: "Quite a bit." One stuck out though and prompted this post.
Selena Delesie wrote some time about Yes Men and the managers who like them. I had read enough of that post to say "I need to look that up when I get a moment." That moment finally came. Toward the end of her entry, Selena wrote "Have you worked with or for someone who is a dictator-type who thrives on working with ‘Yes’ Men?" This is my response:
Yes. To make matters worse, I did not even report to that manager, either directly or indirectly. I was in a completely different reporting line than he was. My Manager was a peer with him. However, as he managed a large development group I needed to work with (as QA and BA and PM) it presented all sorts of challenges. Forget that. It was not a "challenge." It was a "pain."
Management By Intimidation was the best way I can think of to describe his approach. Really, it was un-good. People who disagreed with him or had an opinion that did not exactly match his own were belittled, often publicly, or (as I learned later in private conversation then first-hand) had their position/employment threatened. Fear was a great motivational tool.
People who did not work for him but were in meetings with him could count on having any statement challenged, any assertion questioned. "You can't prove that, you have no evidence!" Never mind that the previous 15 minutes had been laying out evidence to support the statement he was challenging (gratuitously.) And even when assertions were presented as "possibilities" you could be certain that anything that could be in conflict with what he wanted done would be publicly thrashed.
Other managers were afraid of what he would say to the VP in private. He created a mystique of "getting things done" at all costs.
In a matter of months, from the time when he first joined the company to when I needed to interact with him or his people on a daily basis, this job went from the best job that I had ever had to the absolute worst one. In truth, I learned a lot during that time.
Managers in the business units were frustrated. When speaking with them, you know, doing my job, about needs and business function, several actually hung their heads and said "It doesn't really matter, Pete. No matter what I say, he's going to do what he wants to do and tell me this is the way it has to be." When I asked why they did not go to their leadership and look for support, to a man (they really all were males) the response was "If I don't put up with this, he won't have his people do what I really need to have done."
One interesting thing was if you did not have to interact with him to get your job done, and he needed you, you were the best buddy he had. Pals for life! Until there was a change or he did not get something he wanted.
This guy was also a huge believer in bell-curves. Particularly when they were applied to people. He also loved metrics. There was never a metric he did not proclaim the great value of, then manipulate to his own ends. Flagrantly. He also knew that no one would call him on it.
Finally, I did. Publicly. In a manager meeting. With the VP present. Hell hath no fury like a bully and a liar who is called on behavior. I knew it would cost me. I did not care. In the end, I could not work in an environment like that where people were truly afraid of the consequences of speaking out. I would no longer be complacent in an environment where the cost of taking a stand on the moral high-ground was more fearsome than what the toxic environment did to the person as a person.
I landed a new position. I did not realize how the toxicity of the last one lingered on me and I made some mistakes there. Nothing huge, but enough where my outlook had been changed to be more confrontational that it needed to be. I learned from that, too. That's another blog post though.
I said I learned a lot there. I did. Here's part of what I learned:
I've been working my way through two books over the Thanksgiving weekend, both on software. Which ones do not really matter. I resolved to start the smaller one over completely and see if reading entire pages at a time made it better. (It did.)
I have also been trying to catch up on my long-list of blog posts that I intended to read and see what the great ones of our craft can teach me. The answer was: "Quite a bit." One stuck out though and prompted this post.
Selena Delesie wrote some time about Yes Men and the managers who like them. I had read enough of that post to say "I need to look that up when I get a moment." That moment finally came. Toward the end of her entry, Selena wrote "Have you worked with or for someone who is a dictator-type who thrives on working with ‘Yes’ Men?" This is my response:
Yes. To make matters worse, I did not even report to that manager, either directly or indirectly. I was in a completely different reporting line than he was. My Manager was a peer with him. However, as he managed a large development group I needed to work with (as QA and BA and PM) it presented all sorts of challenges. Forget that. It was not a "challenge." It was a "pain."
Management By Intimidation was the best way I can think of to describe his approach. Really, it was un-good. People who disagreed with him or had an opinion that did not exactly match his own were belittled, often publicly, or (as I learned later in private conversation then first-hand) had their position/employment threatened. Fear was a great motivational tool.
People who did not work for him but were in meetings with him could count on having any statement challenged, any assertion questioned. "You can't prove that, you have no evidence!" Never mind that the previous 15 minutes had been laying out evidence to support the statement he was challenging (gratuitously.) And even when assertions were presented as "possibilities" you could be certain that anything that could be in conflict with what he wanted done would be publicly thrashed.
Other managers were afraid of what he would say to the VP in private. He created a mystique of "getting things done" at all costs.
In a matter of months, from the time when he first joined the company to when I needed to interact with him or his people on a daily basis, this job went from the best job that I had ever had to the absolute worst one. In truth, I learned a lot during that time.
Managers in the business units were frustrated. When speaking with them, you know, doing my job, about needs and business function, several actually hung their heads and said "It doesn't really matter, Pete. No matter what I say, he's going to do what he wants to do and tell me this is the way it has to be." When I asked why they did not go to their leadership and look for support, to a man (they really all were males) the response was "If I don't put up with this, he won't have his people do what I really need to have done."
One interesting thing was if you did not have to interact with him to get your job done, and he needed you, you were the best buddy he had. Pals for life! Until there was a change or he did not get something he wanted.
This guy was also a huge believer in bell-curves. Particularly when they were applied to people. He also loved metrics. There was never a metric he did not proclaim the great value of, then manipulate to his own ends. Flagrantly. He also knew that no one would call him on it.
Finally, I did. Publicly. In a manager meeting. With the VP present. Hell hath no fury like a bully and a liar who is called on behavior. I knew it would cost me. I did not care. In the end, I could not work in an environment like that where people were truly afraid of the consequences of speaking out. I would no longer be complacent in an environment where the cost of taking a stand on the moral high-ground was more fearsome than what the toxic environment did to the person as a person.
I landed a new position. I did not realize how the toxicity of the last one lingered on me and I made some mistakes there. Nothing huge, but enough where my outlook had been changed to be more confrontational that it needed to be. I learned from that, too. That's another blog post though.
I said I learned a lot there. I did. Here's part of what I learned:
- Managers may not be leaders, but they need to manage well;
- Human Mistakes are learning opportunities, not something whose outcomes should be dreaded;
- Intimidation only works if one is willing to be intimidated;
- Sometimes in the office, just like in the schoolyard, bullies will collapse when confronted by a united opposition;
- Make sure you are not the bully.
Sunday, August 29, 2010
Music, or Testerman's Ramble
At one point in my life I played in a band that performed a variety of Irish traditional and folk music. We also played a fair amount of Scottish traditional and folk as well, however, it seems if you play or sing a single Irish song, you are labelled "Irish" and you'll be crazy-busy in March, and pretty slow the rest of the year. Unless you work really hard and play reasonably well.
So a side-effect of playing in a band that performs this stuff is, when you get good enough for people to pay you money to go to their towns, cities, festivals, whatever, you will run into other folks who play the same type of music. When schedules permit, this often devolves into a session / sessiun / wild-music-playing party. There are certain protocols that most folks follow in these events - and the fantastic thing is that usually the level of play is quite good. Tempos are snappy so reels drive forward and hornpipes can be lilty (and tend to run around Warp 9) and jigs are of a nature where feet rarely touch the ground.
Now, these uber-sessions are not so different than more traditional ones held in houses or coffee-shops or bars or clubs. The big difference is the recognition that there are no light-weight players and everyone has mastered their craft. This is not always the case at other sessions.
I have been out of the performing trad/folk music for several years now, and in the last year began attending some of the local sessions, just to get my feet wet. I was a bit rusty on bodhran, the Irish hand frame drum, which I had played for 20 years on stage and in sessions. My limited ability on penny whistle was nigh-on vanished - I remembered tunes and could call phrases from my memory to my finger tips, but I'm effectively starting over. With crazy work and home schedule it has been hard to find time to practice , let alone become "street legal" on whistle.
So, I show up at the Sunday night sessions and play a couple of tunes on whistle when they come up. I will also play the bodhran a bit, depending on the number of people there (it does not take many drums to become "too many" for the melody instruments - whistles, mandolins, fiddles, flutes, dulcimers and the like.)
This last Sunday there were a fair number of players. There were 8 or 9 "melody" players, a couple of guitars, a tenor-banjo, who played melody when he knew the tune and vamped when he did not - and me on drum (with the occaisional contribution of bones.) Some of the players are quite experienced and I have seen around for many years. Some are between beginner and novice. Some are "in between" levels of experience.
One tune in particular would have made me stop the band, if it was a "band" that was playing and have them start again. That typically isn't done in sessions - so I did the "drummer equivalent" and simply stopped playing. One of the mandolin players, who knew me and has also been around the block gave a little smile and he stopped as well. We were treated to a rare sight of 6 people who were absolutely certain what the "correct" tempo was for the tune that was being played - and none of them would give an inch - or a click on the metronome. The guitar players seemed to play along with which ever melody instrument was close to them and generally the best description was "trainwreck."
That reminded me of a projet I had worked on some time ago. I was not on the project originally, but was brought in as part of a desperation move to fix it. Like in the tune on Sunday, each of the participants knew what the right thing to do was. The problem was none of them agreed on what that thing was. "Blood on the Green" was an apt summation of that effort. The programmers were berated for not following instructions - but how do you follow instructions when there are multiple, conflicting sets of instructions?
Because of the "political nature" of the project, no managers or directors were willing to step up and take on some form of leadership role for fear that there would be repercussions for doing so. The PM, BA and Dev Lead floundered without some form of direction from their respective management teams. Information was contradictory at best.
In the end, a Director put his foot down, asserted control and forced the issue. Me being added to the project was part of forcing the issue. Until that point, the uncertainty of the leadership was sapping the ability of the project group to operate as an effective team. Like the music session last week, no one had a clear picture as to what was "right" and where the center of gravity was.
People can urge "Best Practices," "Standards," "Process" and "Metrics" all they want. In some contexts, that may be the right thing. However, wiothout a clear understanding of the intent of the effort, nothing will save the project. Ulysses S. Grant, that prescient Software Oracle (well, American General turned President) warned that indecision was worse than a wrong decision. Wrong decisions could be countered by "right" decisions, but no decision, from leadership, leaves your group floundering looking for a center.
So a side-effect of playing in a band that performs this stuff is, when you get good enough for people to pay you money to go to their towns, cities, festivals, whatever, you will run into other folks who play the same type of music. When schedules permit, this often devolves into a session / sessiun / wild-music-playing party. There are certain protocols that most folks follow in these events - and the fantastic thing is that usually the level of play is quite good. Tempos are snappy so reels drive forward and hornpipes can be lilty (and tend to run around Warp 9) and jigs are of a nature where feet rarely touch the ground.
Now, these uber-sessions are not so different than more traditional ones held in houses or coffee-shops or bars or clubs. The big difference is the recognition that there are no light-weight players and everyone has mastered their craft. This is not always the case at other sessions.
I have been out of the performing trad/folk music for several years now, and in the last year began attending some of the local sessions, just to get my feet wet. I was a bit rusty on bodhran, the Irish hand frame drum, which I had played for 20 years on stage and in sessions. My limited ability on penny whistle was nigh-on vanished - I remembered tunes and could call phrases from my memory to my finger tips, but I'm effectively starting over. With crazy work and home schedule it has been hard to find time to practice , let alone become "street legal" on whistle.
So, I show up at the Sunday night sessions and play a couple of tunes on whistle when they come up. I will also play the bodhran a bit, depending on the number of people there (it does not take many drums to become "too many" for the melody instruments - whistles, mandolins, fiddles, flutes, dulcimers and the like.)
This last Sunday there were a fair number of players. There were 8 or 9 "melody" players, a couple of guitars, a tenor-banjo, who played melody when he knew the tune and vamped when he did not - and me on drum (with the occaisional contribution of bones.) Some of the players are quite experienced and I have seen around for many years. Some are between beginner and novice. Some are "in between" levels of experience.
One tune in particular would have made me stop the band, if it was a "band" that was playing and have them start again. That typically isn't done in sessions - so I did the "drummer equivalent" and simply stopped playing. One of the mandolin players, who knew me and has also been around the block gave a little smile and he stopped as well. We were treated to a rare sight of 6 people who were absolutely certain what the "correct" tempo was for the tune that was being played - and none of them would give an inch - or a click on the metronome. The guitar players seemed to play along with which ever melody instrument was close to them and generally the best description was "trainwreck."
That reminded me of a projet I had worked on some time ago. I was not on the project originally, but was brought in as part of a desperation move to fix it. Like in the tune on Sunday, each of the participants knew what the right thing to do was. The problem was none of them agreed on what that thing was. "Blood on the Green" was an apt summation of that effort. The programmers were berated for not following instructions - but how do you follow instructions when there are multiple, conflicting sets of instructions?
Because of the "political nature" of the project, no managers or directors were willing to step up and take on some form of leadership role for fear that there would be repercussions for doing so. The PM, BA and Dev Lead floundered without some form of direction from their respective management teams. Information was contradictory at best.
In the end, a Director put his foot down, asserted control and forced the issue. Me being added to the project was part of forcing the issue. Until that point, the uncertainty of the leadership was sapping the ability of the project group to operate as an effective team. Like the music session last week, no one had a clear picture as to what was "right" and where the center of gravity was.
People can urge "Best Practices," "Standards," "Process" and "Metrics" all they want. In some contexts, that may be the right thing. However, wiothout a clear understanding of the intent of the effort, nothing will save the project. Ulysses S. Grant, that prescient Software Oracle (well, American General turned President) warned that indecision was worse than a wrong decision. Wrong decisions could be countered by "right" decisions, but no decision, from leadership, leaves your group floundering looking for a center.
Subscribe to:
Posts (Atom)
