MMS was a blast. The amount of information, and networking possible is just staggering. I was also pleasantly surprised to find strong brothers in the faith while I was out in Vegas as well.
I’m excited about the future with CM12, Intune, App-v, Powershell, Server 12, Hyper-v, and Ops Man. I had an interesting conversation today over lunch about the essential folly of strict delegated authority and technology specialization that happens inside corporations. I would like to hit a few of the high points I was arguing to substantiate my claim that smaller work forces with broader skill sets offered a stronger IT work force as a whole. In terms of retention, satisfaction, cost of operation, and potential for innovation.
Employee retention and satisfaction will increase.
As I had posted on here previously, money does not serve as a motivational tool for cognitive tasks; which we can all agree on is where most IT engineering level jobs reside. Give enough money that money is not an issue, and you’ve essentially reached the end of money’s power of motivation over your employees. So then how do we motivate these employees to do more? Essentially, give them more to do; or give them diversity in their work and more to solve.
So? What can we conclude from that?
That a highly technical person (who is paid appropriately) will become a more productive (and one could read loyal) employee if given more opportunities to work.
What does delegated authority, and technology specialization teach us? Don’t give them enough money to make money NOT an issue, but instead give them a fixed growth path, and limit their technical involvement to one area. Generally this breeds a mercenary type behavior born of a loss of interest resulting in poor production. This WILL result in higher turn over as employees seek better opportunities, generally using a skill set they cultivated on the previous company’s dime… So why isn’t retention an issue? That’s lost revenue in training, hiring, terminations, and man hours to complete the tasks involved with all of this.
Reduced headcounts, with improved availability
Doing more with less, or less with more. Lets just look at this for a minute and really think this through.
t*(e^x)=c
Technologies that need to be supported (t) times the total number of employees (e) required for each piece (x) then I can get a rough estimate of my required headcount. To keep it simple lets assume that ideally these technologies can be supported 1 for 1. If I find myself in a specialized state the value of x will have to be 2. In some cases you could get away with 1, but if this is a tier 2 or higher item you are at a serious risk in terms of support availability. This is a problem with specialization, you can cross train, but rarely does that cross training work appropriately for hand off in a crisis situation.
However if your standard mode of operation allows for covering multiple areas then workloads will delegate themselves between employees evenly. When one leaves another can step in line to carry that workload without any impact. You have effectively reduced your required workload by 1 per technology. Now of course this is very basic, and doesn’t account for a lot of variables that would exist such as synergies that already exist, but if one adopts distributed responsibility more synergies will be found and that head count will reduce. Salaries will be released to go back into the company, and to the salaries of your remaining talent.
You’ve now found the way to take the subject of money off the table, and increased your support availability. When I talk about availability, I don’t just mean in terms of support, but even in project through put and time lines. You won’t be hit as hard by your “so and so guy”‘s vacation in terms of project completion.
Innovation’s will be found more frequently
I’m not going to go too deep on this as it’s a pretty simple benefit to identify. You have more eyes on something, the greater the chance is you find an improvement to that.
You will have an increasingly more motivated work force
By establishing a distributed responsibility system you have also given your employees two of the 3 fundamental keys for motivation.
- Autonomy
- Mastery
How so, you might ask? By exposing your employees to more technology and work you have given, or even forced them into a state of self governance. They are given the reigns to see what is needed and respond accordingly to those needs which in turn will result in mastery of the technologies that they support. Look, we can spend as much time as we want discussing how people learn and what makes the best teacher, but inevitably we all know that experience is king.
Great, I’m sold, so what are the pitfalls?
You need to identify the right talent, and you need to always evaluate service level requirements and demand.
These are areas that require strong management to be able to identify. In truth, you could spend a lot finding a solid recruiter for talent selection, but I think your current teams should be more involved in selecting their peers. The reality is, they are your source that should let you know if the new person will have the technical chops and personality to fit in and do the work.
Anyway, I could go on further extolling the merits of this model, but I feel most my points would just be beating a dead horse so I’ll stop now.
Have a good one.
Edit:
So valve’s employee handbook and business model serves as an excellent (and humorous) example for what I’m talking about.
