Someone I work with posted this link:
One of the more interesting quotes from that article...
"As a boss, your energy has a disproportionate impact on those you lead, by virtue of your authority. Put bluntly, any time your behavior increases someone's anxiety — or prompts any negative emotions, for that matter — they're less likely to perform effectively.
The more positive your energy is, the more positive their energy is likely to be, and the better the likely outcome. "
If you are working under constant and continuous pressure to 'perform' no matter what your position or job, your manager may be making a short sighted mistake where your decision making may be compromised as a result.
Tuesday, November 1, 2011
Friday, July 29, 2011
Organizational Branching (Feature or Abstraction)
There has been some recent interesting commentary by Martin Fowler and Jez Humble on the use of features branches in DVCS systems. Specifically Fowler started the conversation with this post on Feature Branches.
It was during my reading of Jez's commentary in his recent post that I had a little light bulb moment about management of organizations in relation to the blog topic.
So the light bulb moment I had related to how companies I have worked for tend to address specific 'project/program' needs within the organization. My observation was this: Companies tend to "Feature Branch" the organization as a way to attempt to accomplish a specific project/program, i.e. new teams or new groups are formed to handle high level work items for the organization.
I believe that organizations run into a great number of the same issues associated with feature branching code when they split their org. structure to do work in this way. Breaking off a new group invites Conway's Law issues and shoves a 'wedge' between the body of the company and this newly formed entity. The new entity slowly stops conversing with the organization - they become disconnected from the needs, the new teams stop being able to really effectively know that what they are developing is helping. The only way to combat this tendency to to have the new org occasionally "merge" what they are doing with the larger organization. If too much time has passed between this merge and the last merge that occurred (Status meeting, conversation or other people synchronizations) then the new team may have developed their software considerably far down a path that is not useful to the organization as a whole - making the merge efforts difficult at best.
Following this analogy I am curious if there is an argument to be made about branching the organization by abstraction, similar to how code might be branched by abstraction. I believe that this would look like having work stories divvied up amongst a bunch of pre-existing teams. Some of the teams may have an expertise in a given area but would be more generalist in nature. This would keep the teams engaged and involved in what the reset of the organization is doing and accomplishing, no thought merging required.
Very interested in any of your (dear readers) experiences or thoughts - this is just something I have been mulling around in my head about how the business of software development works.
Comments...
It was during my reading of Jez's commentary in his recent post that I had a little light bulb moment about management of organizations in relation to the blog topic.
So the light bulb moment I had related to how companies I have worked for tend to address specific 'project/program' needs within the organization. My observation was this: Companies tend to "Feature Branch" the organization as a way to attempt to accomplish a specific project/program, i.e. new teams or new groups are formed to handle high level work items for the organization.
I believe that organizations run into a great number of the same issues associated with feature branching code when they split their org. structure to do work in this way. Breaking off a new group invites Conway's Law issues and shoves a 'wedge' between the body of the company and this newly formed entity. The new entity slowly stops conversing with the organization - they become disconnected from the needs, the new teams stop being able to really effectively know that what they are developing is helping. The only way to combat this tendency to to have the new org occasionally "merge" what they are doing with the larger organization. If too much time has passed between this merge and the last merge that occurred (Status meeting, conversation or other people synchronizations) then the new team may have developed their software considerably far down a path that is not useful to the organization as a whole - making the merge efforts difficult at best.
Following this analogy I am curious if there is an argument to be made about branching the organization by abstraction, similar to how code might be branched by abstraction. I believe that this would look like having work stories divvied up amongst a bunch of pre-existing teams. Some of the teams may have an expertise in a given area but would be more generalist in nature. This would keep the teams engaged and involved in what the reset of the organization is doing and accomplishing, no thought merging required.
Very interested in any of your (dear readers) experiences or thoughts - this is just something I have been mulling around in my head about how the business of software development works.
Comments...
Thursday, March 10, 2011
Carrots, Sticks, Stones and Management
So - I have been involving myself quite a bit recently with reading and doing presentations to the people that I work with. A recent presentation that I gave was on process and why it matters in the work place. Now - I know what some of you are thinking, NO I have not gone off the deep end and YES I still rail against the Process = Progress models that are occasionally touted by the places I have worked for and "Big Co." in particular.
So - what sparked the presentation in the first place? Well, I viewed the following TED Talk by Daniel Pink on the science of motivation. I also had the opportunity while I was putting the presentation together to read Freedom from Command & Control: A better way to make the work WORK but did not immediately incorporate the ideas of work FLOW from the book into the presentation. Let me focus in on the TED talk as I think it relates to programming.
Carrots
Companies all over the US have been set up for a long time to essentially offer Carrots to their employees. In essence every company I have worked for has a bonus program which is based on some amount of performance that is usually measured by an individuals manager and is more measured by gut feel then by a strict "You got it over the line" type of measurement. Companies attempt to make each "goal" for the year that an individual will do to get their full bonus a S.M.A.R.T. goal - one which is:
Specific
Measurable
Attainable
Realistic
Timely
Which is interesting because it teaches people to game the "Specific" part to be as small as possible so that in the end it is "Attainable". People end up being taught to think IN the box rather then out of it - or risk getting screwed out of the money that they may feel they rightfully deserve. So whats wrong with this Goal/Bonus system?
As Daniel Pink pointed out carrots (Rewards in a do this and I will give you that regime) work very well for anyone not doing 'creative' or 'problem solving' work, in fact they work very well helping people to move faster and do more when the work is easily repeatable or rote in nature.
These types of carrots or monetary incentives however prevent people from being able to use the thinking and creative sides of their mind in order to problem solve. The rewards have a tendency to NARROW the mind which in the end prevents people from seeing more creative "outside the box" type answers to problems. In fact when people were presented problems requiring even rudimentary problem solving skills the time taken to solve the problem increased rather than decreased. Plenty of science to back that up - and yet every company I have worked for still dangles these carrots as if they were something grand and great that you get for working for "Big Co." when really I have come to see them more as a pain in the ass and not as important as the type of work I am going to do or the environment I happen to work in.
Sticks and Stones
A few people have noted to me how much they HATE getting yelled at. For a very narrow band of people the idea of getting admonished by someone is a motivator. I would venture that in today's work place that this behavior by managers or staff isn't tolerated very much at all. I believe that you do still find people that believe that by being an asshole or the office mad man they get results and motivate their people to be better and produce more but I am fairly sure that this only works on people that have fairly low self esteem to begin with, everyone else leaves or quits and goes on to find a better environment or boss to work for and with. Fear of reprisal, similar to adding incentives to creative work, works to de-motivate staff and make them think twice about moving to a new position elsewhere.
What does this all have to do with Management?
Management
Typical management that I have been associated with lives in a world where the hierarchy is king, and their command and control may not really be questioned. The HR department works with management to set up 'Carrots and Sticks' to make sure that workers keep themselves in-line and 'producing' the things that make the company money. The problem is that as software developers we are not building cogs, nor producing cars - we are inherently doing something that requires each and everyone of us to think about what we are doing. We have to spend time asking questions and thinking critically about what we are doing and why. We 21st century workers are much more interested in Autonomy, Mastery and Purpose then we are specifically about the dollar figure. Management has to move to take the conversation about money off the table by paying workers in a way that makes the worker comfortable so that the company can get more performance from the staff and to engage in conversation about the things that really matter when it comes to jobs like software development.
Nothing motivates a software developer better than being told:
1) You have the ability to work when you need to, from home or from the office as long as you get done the work required. Autonomy to work w/ teams in the way that everyone decides rather than in the prescribed way a manager feels is best is a wonderful motivator.
2) Most software developers pride themselves on the Mastery of the software development craft of one or more software development languages. Developers like to share their knowledge with others and take pride in producing cool things that the world uses. Managers should encourage and support this by helping your software development staff to get smart and stay that way.
3) Context is everything. Software developers rail against doing something when they don't have the context for why they are being asked to do it. Not being given this information is a huge de-motivator for most software developers that I know. Context is king and is vitally important to making the software being developed manageable and maintainable over time.
The days of Carrots and Sticks are now done and gone - OH SO 20th century at this point. We need to listen to the science and attempt to find the 21st century motivational equivalents, things like Autonomy, Mastery and Purpose so as to reshape the companies we work for and with and the managers the help run them.
So - what sparked the presentation in the first place? Well, I viewed the following TED Talk by Daniel Pink on the science of motivation. I also had the opportunity while I was putting the presentation together to read Freedom from Command & Control: A better way to make the work WORK but did not immediately incorporate the ideas of work FLOW from the book into the presentation. Let me focus in on the TED talk as I think it relates to programming.
Carrots
Companies all over the US have been set up for a long time to essentially offer Carrots to their employees. In essence every company I have worked for has a bonus program which is based on some amount of performance that is usually measured by an individuals manager and is more measured by gut feel then by a strict "You got it over the line" type of measurement. Companies attempt to make each "goal" for the year that an individual will do to get their full bonus a S.M.A.R.T. goal - one which is:
Specific
Measurable
Attainable
Realistic
Timely
Which is interesting because it teaches people to game the "Specific" part to be as small as possible so that in the end it is "Attainable". People end up being taught to think IN the box rather then out of it - or risk getting screwed out of the money that they may feel they rightfully deserve. So whats wrong with this Goal/Bonus system?
As Daniel Pink pointed out carrots (Rewards in a do this and I will give you that regime) work very well for anyone not doing 'creative' or 'problem solving' work, in fact they work very well helping people to move faster and do more when the work is easily repeatable or rote in nature.
These types of carrots or monetary incentives however prevent people from being able to use the thinking and creative sides of their mind in order to problem solve. The rewards have a tendency to NARROW the mind which in the end prevents people from seeing more creative "outside the box" type answers to problems. In fact when people were presented problems requiring even rudimentary problem solving skills the time taken to solve the problem increased rather than decreased. Plenty of science to back that up - and yet every company I have worked for still dangles these carrots as if they were something grand and great that you get for working for "Big Co." when really I have come to see them more as a pain in the ass and not as important as the type of work I am going to do or the environment I happen to work in.
Sticks and Stones
A few people have noted to me how much they HATE getting yelled at. For a very narrow band of people the idea of getting admonished by someone is a motivator. I would venture that in today's work place that this behavior by managers or staff isn't tolerated very much at all. I believe that you do still find people that believe that by being an asshole or the office mad man they get results and motivate their people to be better and produce more but I am fairly sure that this only works on people that have fairly low self esteem to begin with, everyone else leaves or quits and goes on to find a better environment or boss to work for and with. Fear of reprisal, similar to adding incentives to creative work, works to de-motivate staff and make them think twice about moving to a new position elsewhere.
What does this all have to do with Management?
Management
Typical management that I have been associated with lives in a world where the hierarchy is king, and their command and control may not really be questioned. The HR department works with management to set up 'Carrots and Sticks' to make sure that workers keep themselves in-line and 'producing' the things that make the company money. The problem is that as software developers we are not building cogs, nor producing cars - we are inherently doing something that requires each and everyone of us to think about what we are doing. We have to spend time asking questions and thinking critically about what we are doing and why. We 21st century workers are much more interested in Autonomy, Mastery and Purpose then we are specifically about the dollar figure. Management has to move to take the conversation about money off the table by paying workers in a way that makes the worker comfortable so that the company can get more performance from the staff and to engage in conversation about the things that really matter when it comes to jobs like software development.
Nothing motivates a software developer better than being told:
1) You have the ability to work when you need to, from home or from the office as long as you get done the work required. Autonomy to work w/ teams in the way that everyone decides rather than in the prescribed way a manager feels is best is a wonderful motivator.
2) Most software developers pride themselves on the Mastery of the software development craft of one or more software development languages. Developers like to share their knowledge with others and take pride in producing cool things that the world uses. Managers should encourage and support this by helping your software development staff to get smart and stay that way.
3) Context is everything. Software developers rail against doing something when they don't have the context for why they are being asked to do it. Not being given this information is a huge de-motivator for most software developers that I know. Context is king and is vitally important to making the software being developed manageable and maintainable over time.
The days of Carrots and Sticks are now done and gone - OH SO 20th century at this point. We need to listen to the science and attempt to find the 21st century motivational equivalents, things like Autonomy, Mastery and Purpose so as to reshape the companies we work for and with and the managers the help run them.
Subscribe to:
Posts (Atom)
