Know your people

December 2, 2010

If your people want direction, give ’em direction.
If your people want freedom, give ’em freedom.
If your people are overly conscientious, make ’em step a bit out of their comfort zone.
If your people aren’t conscientious, and it’s important, nudge ’em to be a bit more so.
If your people don’t like to change, encourage ’em to change.
If your people think what they’re using works, so why change, listen. They might be right.
If your people think what they’re using works, so why change, explore further options, then sell the best one to them.
If your people are all novices and you’re expecting them to be experts, change your attitude.
If your people are all experts and you’re treating them like novices, change your attitude.
If your people are fine but their interactions aren’t, don’t think firing and hiring will help.
If your people can’t get their work done, don’t assume new software will be a silver bullet.
If your people are clamoring for a new product, listen. It won’t be long before they switch to your competitor.
If your people are experts, don’t hesitate to ask them what to do. Humility can lead to good solutions.

A business run without a system is like a car driven by a man with short-term memory loss, continually having to guess which pedal is the brake, the gas, and the clutch. It will, most likely, eventually, and with luck, go forward, but the passengers aboard will not find the ride comfortable or smooth. And if the environment the car is in is a fast-paced, highly-competitive Philadelphia freeway, then the passengers may not even survive.

I worked for a number of years across the street from what in the flower world would be called an “annual” cafe. It flowered approximately once a year, under a new name, with new owners, and a new, though usually similar, menu. The owners tried a number of different tactics–higher prices, less food, catering, advertising–but they all had one thing in common–they did not have a system. These folks served excellent food. I drooled over their burgers–yet the McDonalds down the street made more money than them. They did not have a system for ordering, for buying food, for cooking the food, for serving the food, for obtaining customers, for retaining customers–they figured “make it good and they will come.”

In the United States, the overpasses must be 14′ from the road way in urban areas, and 16′ in rural. It’s odd that they wouldn’t standardize on one–in fact, many people might be downright angry at a system with dual standards. I don’t know the historical background to this, or what competing factions had to compromise to get there. One thing is for sure, though–it is better to have something for the truck manufacturers and the freight carriers to rely on than to make no system of standards at all.

Lazy people have an edge over the more hard-working among us: they tend to do the same thing that barely worked last time. This, over time, multiplied by many lazy people working in concert, will mean that eventually some sort of ad hoc system will emerge. It will not be the best, it will not be perfect, and it may fail at times, but it will be a system. An unorganized, but hard-working group of people, by contrast, will have a tougher time. They will realize that the way they did it last time didn’t work so well–that maybe it barely worked at all. So they decide to try a different way, which they believe will work better. A local auto repair I use is like this–they are excellent, hard-working mechanics, who charge less than most and are completely honest, but they struggle to deliver on time, and have problems with cash flow, billings, and customer retention. They keep changing things, trying new methods, working ever harder, and generally staying fairly disorganized.

The lazy people would be helped by consciously putting together a system that works, instead of having a system emerge on its own–by the time the system emerges, it may just be too late. And the hard-working ones would be helped by realizing that consistency, even in a flawed system, can be helpful.

Don’t wait until the software you’ve just purchased for 50,000 dollars is configured exactly the way you want it, and don’t wait for all the users to be bought in. Don’t make the mistake of thinking that change for change’s sake is a good thing. Don’t think for a second that you couldn’t be helped by having some sort of system–software or hardware or practices or procedures–that would help you in your work. But remember that perfection is the enemy of the good. Get something going, and then change it incrementally, in thought-out iterations. But just get it going!

Quote

November 5, 2010

“Elegance is the art of refusal”

Coco Chanel

Where are your people at?

November 3, 2010

A few weeks ago Seth Godin wrote about the Dreyfus model of skill acquisition, which has these five steps, which I’ve cut and pasted here from Wikipedia:

*********************************************************
1. Novice
  • “rigid adherence to taught rules or plans”
  • no exercise of “discretionary judgment”
2. Advanced beginner
  • limited “situational perception”
  • all aspects of work treated separately with equal importance
3. Competent
  • “coping with crowdedness” (multiple activities, accumulation of information)
  • some perception of actions in relation to goals
  • deliberate planning
  • formulates routines
4. Proficient
  • holistic view of situation
  • prioritizes importance of aspects
  • “perceives deviations from the normal pattern”
  • employs maxims for guidance, with meanings that adapt to the situation at hand
5. Expert
  • transcends reliance on rules, guidelines, and maxims
  • “intuitive grasp of situations based on deep, tacit understanding”
  • has “vision of what is possible”
  • uses “analytical approaches” in new situations or in case of problems

*********************************************************

Godin writes “If you treat an expert like a novice, you’ll fail” And I would expand on that to say “If you treat any person at a level that they are not at, they and you will fail.”

McDonald’s is a system that is designed around the Novice. McDonald’s does not need a willing host of experts waiting to sign up for duty when it moves into the next dusty podunk. Rather, they just need an unskilled person who is willing to follow direction. They only need someone who can be taught to count to 12 so they can stir my frappe the correct number of times.

Jack Welsh, CEO of General Electric, began working ten years before his retirement to choose a successor. He was not interested in anybody but the best of the best–an Expert of the nth degree. He could give some tips, some maxims, or some heuristics to such a person to help guide their actions, but there was no way for him to write out the exact steps to being an excellent CEO of a Fortune 100 company.

All systems need to be designed with the user in mind. Some systems need to be designed for the Novice. Some systems need to be designed for the Expert. But most systems could use a smattering of all, in order to serve the full range.

One of my clients is a large excavation company. They often have unskilled workers enter their workforce as a general laborer, working in the field. This job does not require a large amount of skill, and can easily be done by a Novice; they need to know what the rules are, and how and when to do it, and they will succeed. However, as these laborers gain experience, they begin to work their way up in the company. First, they may become an operator of several large pieces of equipment, able to make decisions that can affect their coworkers in major ways. They are now an Advanced Beginner–but they are not yet ready to become a foreman. Foremen are Competent; they can plan ahead, create tasks for the Advanced Beginners and Novices under them, and they know what role they and their crew play in getting the whole job done.

The next level at this company is Superintendent. They are Proficient. They know what needs to be done in order to get the whole job done on schedule and on budget. They know how important one piece of the job is compared to the next, and don’t have a perfect, set routine in the way they run their day. Finally, the project managers have become experts. They no longer are held to the rules of the laborers. They have the ability to go out and help obtain the next job, to think about what should be done from a deeper, strategic perspective, and to fully and completely understand the impact of all political, physical, and financial decisions on their work.

I would like to pose a simple question: what would happen if the laborer was told  “Go out and make money” and nothing else? And the corollary: what would happen if the project manager was told what to do every minute of every day?

All systems have a human element somewhere. Know what level of skill you are working with. Then adjust your system to meet and challenge the person at that skill level.

When are you done with an implementation? In a perfect waterfall (design/build/test/implement/use) situation, the goals for success are defined and agreed upon by all the stakeholders at the beginning of the process. However, many, if not most new systems do not follow the waterfall method. More often, the definitions of success are not and cannot be defined at the beginning of the project.

The role of the system architect is to take a vague business ideas (reduce double entry, improve communication, streamline deliveries) and make it reality. But who gets to decide when the “reality” that has been delivered answers the business need? The answer, counterintuitively, is everyone.

Everyone has examples of this in life. A student, for example, may have considered the B she received in English acceptable, while her father considers anything less than an A failure. A long, expensive project may be considered a success by those who worked on it, as they know the details of the obstacles faced along the way, but a failure by the Chief Financial Officer because of its dismal return on investment. One user of a new piece of software may consider it to be the best software they’ve ever used, while the next thinks it lacks critical features.

It’s a paradox: they are all correct. They all have their belief about the outcome of their particular system, and that belief is the determination of success–and nothing else.

To succeed with your new commission scheme, your new web app, your new inventory tracking system, your new customer retention policy, do just two things: define success early and publicly, and limit the number of people impacted. With these two measures your chance of success will increase tenfold.

So go on, get to work!

Details

September 28, 2010

Architects are funny animals. They generally like to complete the grand vision, put the parts in motion, make sure everything looks good and plays well, and let the “others” do the rest–the “others” being the programmers or the employees or the consultants. But often they get hung up on details.

Why are the details important? First off, in many cases they aren’t. If the detail in question lays smack in the middle of an individual component, then the architect can forget about it. For example, in a complex software project, the way a  programmer writes an argument within his block of code doesn’t necessarily matter all that much. Or in a building, what tools a carpenter chooses to cut the wood to length really doesn’t matter. Or in an organization, the way an employee spends his lunch hour.

Details become important when the details lie between the components–the API calls in code or the hold-downs in the building or the meeting format in the organization. These details are critical. The brilliant architect knows these details inside and out. He memorizes them, speaks about them in his sleep, breathes them. The more complex the system, the more the components will interact; the more the components interact, the more details will need to be known about.

Courtrooms are chock full of lawsuits stemming from missed construction details. In a recent case, an architectural firm in my very own Pacific Northwest was handed a multimillion dollar judgement because, among other things, the structural drawings of a high school didn’t match the architectural drawings in a few key areas.  In a client’s organization, one employee would occasionally work on a project for the better part of a week before finding out that management had killed the project, because there was no clarity in the communication of information. A recent Inc. magazine article highlighted yet another web startup that nearly failed due to their four programmers’ individual pieces not playing well together.

But really, it’s quite simple: If you want to have a good end product, identify the components, find out how the components interact, and understand the details of the interaction. There’s where the problems with your design will lie–components can be switched out if they are bad, but the interfaces will remain.

Stability v Change

September 9, 2010

Are stability and change mutually exclusive? Is it possible to create a stable, changing system? Can you reinforce the value of a stable product or environment or business without sacrificing the ability to change?

The UAW feeds on people’s desire for stability. They promise a stable wage with stable benefits while working at a stable job. This is immensely appealing for the workers in the system–especially those who’ve been shocked or betrayed by unscrupulous employers.

Our political system feeds on people’s desire for change. People want forward progress, they want something to be done, and they want to feel like they are part of something new. The “swing” voters are quickly “disillusioned” which leads to a shift in power from left to right, or vice-versa.

Often times laziness or complacency is disguised as stability. Low turnover in a company may mean that the people are content and there is stable management–or it might mean that the company is suffering death by ambivalence. Software programs that were written for MSDOS in the ’80s and are still used today represent stability–they also may represent a lack of IT know-how.

People (especially managers) often use unprincipled change as proof of progress. Switching to an Oracle ERP system in a 50 million dollar company may be more about showing that the company is technologically savvy than about positive change. Buying new automated robots to machine the parts may be more about impressing the tour visitors than about cost savings.

In a single, small piece of software, stability can be surprisingly hard to come by, especially when written by an inexperienced or unskilled programmer. But stability becomes exponentially harder to achieve the more complex the software becomes–each component has to successfully interact with every other component. Further, as the system becomes more complex, it becomes more and more possible that an individual change will cause instability-which in turn causes change to become harder. And here’s the central point: COMPLEXITY INCREASES THE POTENTIAL FOR INSTABILITY AND DECREASES THE POTENTIAL FOR POSITIVE CHANGE.

Don’t mistake instability for positive change, and don’t mistake lack of change for stability. Don’t associate complexity with grandeur. Just make sure your system is simple, doesn’t break, and can change easily–easy, isn’t it?

%d bloggers like this: