I had a miserable experience with a new hire, a self professed object oriented guru. I wasn't involved in bringing this fellow in. An odd situation but I approached it with an open mind. A fresh pair of eyes can be a good thing. It didn't need to be a miserable experience.
It made me think about how one should go about evangelizing change. I've been on the other side of this fence but I've never seen how much the approach can dictate the outcome.
The first problem was that management gave this person carte blanche. Not a good idea if you want to avoid conflict. However, the guy should have known better than to abuse this privilege so that doesn't change the lesson of this post.
First rule. Be sensitive and diplomatic. Don't be shocked or indignant by anything you see. Small companies have many skeletons in the closet. That isn't necessarily a reflection on the people, the very people that did the very work you are critiquing. If you put people off they won''t want to help you.
Listen. People know a lot more about the technical and cultural challenges than you do. Especially listen for consensus and push back. Focus initially on issues that have consensus. Build rapport by building on consensus. Defer sensitive issues until you have built trust and can explore the reasons for the push back.
Don't talk down. Some of the things you advise may already be well understood. Constraints may have dictated the course of events, not knowledge. Also, people may want to learn new practices but that will dry up fast if you talk down to them.
Be pragmatic. This blog is about software development in small companies. There is not much room for idealism in a small company. Demonstrating pragmatism will earn you respect. Revealing idealism or dogmatism is a sure way to turn people off.
Contribute. Do a feature. Fix a bug. There's no better way to learn about the organization and earn other programmer's respect.
Compartmentalize. Practical examples will be necessary but be selective when demonstrating or applying your recommendations. Don't start out by refactoring everything you touch. Instead, focus your demonstrations on your own contributions or pick a specific area in the system. Look for some level of acceptance before expanding your scope.
Be frank. Don't be afraid to admit that there will be some pain. No pain, no gain. Change always has a cost.
Be firm. Don't sit on the fence. If you decide to go a certain direction, go.
Pick good demonstrations. Make sure there is a tangible benefit. Remember, you are dealing with pragmatic people. If practical demonstrations are not easy to understand and compelling you may not get buy in.
Respect current practices. For example, if there are code reviews, offer your code for review. Don't set yourself above the status quo.
Pace yourself. Oversaturating people will turn them off. Think evolutionary rather than revolutionary - revolutions can be bloody and we're trying to avoid that. At the same time, avoid going too slow or people won't pay attention.
Know when to stop. Keep the costs and benefits in mind. Even if you've been successful so far, don't forget that you can still lose people if you forget to be pragmatic.
The approach might be different if you are a consultant.Then you might have a much shorter time frame. However, the playing field is the same. If you want your recommendations to be followed through you still need to demonstrate value and earn respect.
Friday, 20 November 2015
Monday, 9 November 2015
Find Out What People Find Rewarding
Job satisfaction is critical to employee retention and productivity but companies often misunderstand what people find satisfying. There isn't a simple answer because people are different so it is very important to understand your people.
One thing for sure is that while money can be a factor in retention, it is not a very good source of job satisfaction. In a frustrating environment, you might hear a common cliche, "Oh well. Another day, another dollar." If you hear that, you are in trouble. Money may be some consolation when you have had a crummy day but it is a meager consolation.
There is a dramatic variance in productivity. People can be many times more productive when they are motivated and satisfied than otherwise. It can really pay to understand what gives people satisfaction.
Junior and senior people have different needs. The needs may be similar but the scope will vary. Senior engineers need to see how their work contributes in the big picture and see that their recommendations and designs have visibility. Junior people need to see how their work fits into the part of the system they are working on and that their feature/piece is appreciated.
There are some common factors in job satisfaction and dissatisfaction:
One thing for sure is that while money can be a factor in retention, it is not a very good source of job satisfaction. In a frustrating environment, you might hear a common cliche, "Oh well. Another day, another dollar." If you hear that, you are in trouble. Money may be some consolation when you have had a crummy day but it is a meager consolation.
There is a dramatic variance in productivity. People can be many times more productive when they are motivated and satisfied than otherwise. It can really pay to understand what gives people satisfaction.
Junior and senior people have different needs. The needs may be similar but the scope will vary. Senior engineers need to see how their work contributes in the big picture and see that their recommendations and designs have visibility. Junior people need to see how their work fits into the part of the system they are working on and that their feature/piece is appreciated.
There are some common factors in job satisfaction and dissatisfaction:
- challenge, coolness
- visibility, appreciation.
- appropriate forms of support
- quality
- pain level
There are some common scenarios that can be satisfying or dissatisfying depending on how they are handled. Almost everything management does has some effect on individual people's job satisfaction and motivation. Be aware of the effect of your management decisions and style.
Challenge
Most software involves a certain degree of tedium. People who have significant responsibility for maintenance work, backwards compatibility, etc. may have a high degree of tedium. Don't forget to share out some of the cool work to all people. At least give them a chance to be involved when there is new/cool work. Don't get caught in the trap of thinking that a person is too busy and that you can't afford to have them work on something cool.
Avoid a hero culture when a select few get all of the cool work and visible appreciation. Instead, create a culture where everyone contributes and gets visible appreciation.
Avoid a "give it to the Co-op" culture where work that would be interesting to a senior person is given to an overly junior person, especially when you will later expect the more senior people to live with and possibly maintain the thing. Instead, give the Co-op to the senior person to direct and mentor.
One of the best experiences for junior people is to work with more senior people. You can easily spoil them by giving them a taste for glory too early.
Appreciate
Show appreciation at the level where the work is done. Regularly. As immediately as possible. If the only visible appreciation given is the open e-mail from the CEO congratulating engineering on a project that just achieved a General Availability release milestone, don't be surprised if this fails to make people feel appreciated. It's too little, too late. It could be months to many months after the work was done.
Appreciation should be based on tangible evidence that the work is complete. A unit test, integration test or demonstration. Don't be arbitrarily appreciative or you will encourage poor work.
Recognize initiative. If someone shows initiative in a valuable area, give them visible appreciation, give them a role moving forward. A financial bonus for initiative can be a very much appreciated and a better use of money than a raise.
Don't bypass people. If they've had a role in the past, involve them in the future.
Support
Listen to what your best people need. Be careful not to intrusively, forcefully help them, like taking a part they've done good work on and give it to someone else because you think they are too busy. Talk to them first. Find out what they want.
If people ask for help, listen.
Quality
Have a quality agenda if possible. Allow people to feel proud of the product and their contribution to it.
Pain Points
Develop a good development culture. Recognize competency and allow your best people to work with your best people.
Some development activities are painful. Don't try to hide necessary evils but do try to minimize any unnecessary pain points. Avoid ADHD behavior, militant project management, finger pointing, etc.
Wednesday, 4 November 2015
Emergent Challenges
I recently read "Prey" by Michael Crichton which is an exciting, easy read that explores the surface of nano-tech programming gone wrong.
A key element of the story is that high level goals and behaviors are too sophisticated to program into such simple devices. A programmer devises individual behaviors that interact to result in a desired collective, overall, emergent behavior. This is also how insects work. No individual bee knows how to build a hive. It is the outcome of a collection of primitive individual behaviors.
Where it goes wrong is in how difficult it is to predict and control emergent behaviors.
This idea of emergent behavior exists in more complex systems. In fact, I imagine it exists in every system. This article is about how it exists in technology projects in a real way that can affect quality, time to market and success or failure.
Pointers are a powerful feature in C but so many problems emerge from programming using pointers that modern languages like Java and C# have completely abstracted pointers and object life cycles out of the language and moved them into a virtual machine with automatic garbage collection. A solution was too dependent on garbage collection to be solved with pointers. Solving the emergent pointer problems of C required a paradigm shift.
Sometimes emergent problems could be solved in the original domain but laziness and new features often drive new paradigms, e.g. Microsoft's shift from WinForms to WPF. Although it is a paradigm shift in some ways I don't think the advantages would be compelling to most small companies. What Microsoft doesn't tell you is that, while WPF may be the answer to some of the problems that emerged from WinForms, a whole new set of emerging problems will be caused by WPF. Here is one of the most sensible things I've seen written about WPF - http://stackoverflow.com/a/75387.
Every new technology will have new emergent challenges. Don't forget this simple fact when tempted to switch to a new technology. The real problem is that a new technology is new to everyone and the problems that are going to emerge aren't yet known. Also, the evangelists are biased. Don't expect them to caution you about realities. Think about how aggressively Microsoft evangelized COM. Where is it now?
Even large scale systems have emergent behaviors. For instance, the obsession with copyright in the western world has driven a lot of innovation into the far east. We arm patent owners with trivial or self-evident patents and powerful legal leverage that prevents derivative innovation. The emergent result is to empower countries where those patents are not enforceable to innovate and threaten our dominance in a technology.
Another example is the success of personal injury lawsuits in American society. Bell used to be a prominent motorcycle and bicycle helmet company. Because they were American they were the successful target of anyone in the western world that wanted to sue them after personal injury because they were wearing a Bell helmet. The result was to stifle the helmet industry in North America and create a vacuum which was filled in the Pacific Rim where personal injury lawsuits could not easily get traction. For years the motorcycle industry has been dominated by Arai, Shoie, HJC, etc.
Be wary of new paradigms. Even if the end result is compelling, the transition will almost certainly cost more than anticipated, take longer the estimated and present a new set of problems that will take further time before new practices are established and incorporated in your development environment.
My best advice is to be aware of new techonologies and to experiment with them so that you can judge the cost/benefit issues for your own situation. When you want to transition, do it in a series of phases that mitigates the cost, learning curve and risk to delivery dates for your next few releases.
A key element of the story is that high level goals and behaviors are too sophisticated to program into such simple devices. A programmer devises individual behaviors that interact to result in a desired collective, overall, emergent behavior. This is also how insects work. No individual bee knows how to build a hive. It is the outcome of a collection of primitive individual behaviors.
Where it goes wrong is in how difficult it is to predict and control emergent behaviors.
This idea of emergent behavior exists in more complex systems. In fact, I imagine it exists in every system. This article is about how it exists in technology projects in a real way that can affect quality, time to market and success or failure.
Pointers are a powerful feature in C but so many problems emerge from programming using pointers that modern languages like Java and C# have completely abstracted pointers and object life cycles out of the language and moved them into a virtual machine with automatic garbage collection. A solution was too dependent on garbage collection to be solved with pointers. Solving the emergent pointer problems of C required a paradigm shift.
Sometimes emergent problems could be solved in the original domain but laziness and new features often drive new paradigms, e.g. Microsoft's shift from WinForms to WPF. Although it is a paradigm shift in some ways I don't think the advantages would be compelling to most small companies. What Microsoft doesn't tell you is that, while WPF may be the answer to some of the problems that emerged from WinForms, a whole new set of emerging problems will be caused by WPF. Here is one of the most sensible things I've seen written about WPF - http://stackoverflow.com/a/75387.
Every new technology will have new emergent challenges. Don't forget this simple fact when tempted to switch to a new technology. The real problem is that a new technology is new to everyone and the problems that are going to emerge aren't yet known. Also, the evangelists are biased. Don't expect them to caution you about realities. Think about how aggressively Microsoft evangelized COM. Where is it now?
Even large scale systems have emergent behaviors. For instance, the obsession with copyright in the western world has driven a lot of innovation into the far east. We arm patent owners with trivial or self-evident patents and powerful legal leverage that prevents derivative innovation. The emergent result is to empower countries where those patents are not enforceable to innovate and threaten our dominance in a technology.
Another example is the success of personal injury lawsuits in American society. Bell used to be a prominent motorcycle and bicycle helmet company. Because they were American they were the successful target of anyone in the western world that wanted to sue them after personal injury because they were wearing a Bell helmet. The result was to stifle the helmet industry in North America and create a vacuum which was filled in the Pacific Rim where personal injury lawsuits could not easily get traction. For years the motorcycle industry has been dominated by Arai, Shoie, HJC, etc.
Be wary of new paradigms. Even if the end result is compelling, the transition will almost certainly cost more than anticipated, take longer the estimated and present a new set of problems that will take further time before new practices are established and incorporated in your development environment.
My best advice is to be aware of new techonologies and to experiment with them so that you can judge the cost/benefit issues for your own situation. When you want to transition, do it in a series of phases that mitigates the cost, learning curve and risk to delivery dates for your next few releases.
Subscribe to:
Posts (Atom)