Tag Archives: managing people

Unpacking the Components of Hard Work to Design Better Work Conditions

Effort is grossly underrated by Jamie Flinchbaugh:

There is a common phrase of “work smarter, not harder.” I get the appeal of that. Effort without clarity, efficiency, and effectiveness, has severe limits. Working smart is essential. But does that mean working hard has no value? No, effort is grossly underrated.

I believe we should aspire to work smarter and harder. Neither is sufficient, both are required…

My father used to convince himself working smarter should be the main focus and then he would return from Japan and say yes working smarter is important but they also just work harder. Then he would revert to moving to a primary focus to working smarter, then return of Japan and repeat. It took maybe 3 trips to have it sink into his consciousness that it really was both.

I am slower than my father to accept the necessity of hard work 🙂 I still think we could reduce the hours of work if we worked smarter and the processes were improved to eliminate wasted time and we worked hard for fewer hours. To some extent some agile software development efforts have shown this by changing the system of work and including as part of that a commitment to long term sustainable pace of work (no overwork).

I think if people define work as hard as a large number of hours then that can be reduced. If they define hard as putting forth their best efforts (in a smart and effective way) continually for the hours they put in then I can’t see reducing hard work as a goal. The hard work of doing the challenging things when they are important cannot be abdicated. If anything that is one of the most important methods to reduce the hours of work needed – doing the things that often people avoid because it will be difficult, upset people, make people uncomfortable, upset the way things are done…

farmers tilling a rice field with a machete and a tractor

Tilling a rice field in Bali. See more of my photos from Indonesia.

“Hard work” is often code for “work I despise doing.” If you create a system where people take pride and joy in their work the same time spent working is not nearly as “hard.” If they are proud of what they accomplish a difficult task is often rewarding, and not seen as working “harder.” As is so often the case “hard work” is really packing together numerous ideas in one phrase.

  • long hours
  • difficult tasks (physically, emotionally or intellectually)
  • unrewarding work
  • unpleasant tasks
  • inflexible work (It is a “hard job” if it prevents you from for example, seeing your child’s basketball game. If you were able to see the game and finish up 2 hours of work after they went to bed that is less hard.)
  • difficult work environment (whether that is due to the stress level, physical demands, or other things – like a boss that is difficult to work for)

I think you can reduce many of these parts of hard work by creating a better system of work in the organization. But to do so you increase the need for focused effort on what is important. The key to me is designing a management system in which the effort required by work is the effort you want to give and the amount of unproductive, unrewarding and unpleasant work is reduced. Creating such a management system is not easy; it requires hard work, and it requires working smarter.

Related: Dream More, Work LessSigns You Have a Great Job … or NotRespect People by Creating a Climate for Joy in Work

Change Management: Create a Culture Seeking Continual Improvement or Use Band-Aids?

Successfully shepherding change within an organization is often a challenge. Often change management strategies are mainly about how to cope with a toxic culture but exclude the option of fixing the toxic culture. Why not address the root causes instead of trying band-aids?

The most effective strategy is to build an organizational culture into one that promotes continual improvement. A continual improvement culture is one that is constantly changing to improve (grounded in long term principles: respect for people, experiment, iterate quickly, etc.).

You can try to push change in an ad hoc basis by adopting some strategies to create a similar feeling about the individual change effort. But that isn’t as effective as establishing them in the culture are. Strategies such as: going the gemba, pdsa, build trust via respect for people…

These tools and concepts build trust within the organization. The do that by showing people are respected and that the change effort isn’t just another in the long line of wasted effort for ineffectual change. The first part can be addressed, normally the second part can’t be addressed effectively. Often that is at the core of the issue with why the change effort isn’t working. It is a bad solutions. It hasn’t been tested on a small scale. It hasn’t been iterated numerous times to take a seed of an idea and grow it into a proven and effective change that will be successful. If it had been, many people would be clamoring for the improvement (not everyone, true, but enough people).

But still you can use strategies to cope with lack of trust in your intentions with the change and lack of trust in the effectiveness and fear of change. Some of those are included in the links below. But mainly my strategy is based on focusing on building the proper culture for long term excellence and the change management strategies are just short term coping mechanisms to help deal with the initial challenges. Using those strategies as a long term solution for dealing with change in a toxic culture isn’t a very sensible way to manage.

Continue reading

Take Advantage of the Strengths Each Person Brings to Work

The players have weaknesses. But it is our job as coaches to find the strengths in what our guys do. They all have strengths, and that’s what we highlight. What really helps is having Russell. He is so committed to improving on the littlest things every day. I try to find a word for this sometimes, but I can’t … it’s his refusal to fail. No detail is too small, and he makes sure to stress that every day.”

Darrell Bevell, offensive coordinator of the world champion Seattle Seahawks and former quarterback of the Wisconsin Badgers provides a good guide for managers. “Russell” in the quote is Seattle’s quarterback Russel Wilson; also a UW-Madison alumni.

Street art in Singapore 4 people sitting and a kid

Street art in Singapore. Photo by John Hunter.

Managers should be setting up the organization to take maximum advantage of the strengths of the people in the organization while minimizing the impact of weaknesses.

“Refusing to fail” by saying you refuse and yelling and stomping around if you fail doesn’t work. But if you commit to improve, not just the exciting stuff but every important detail you can create a climate of success. You create a system that works and builds on the skills, ability and desire to do great work that your employees bring to work.

Sure you fix what is broken. But you also improve what is working well. You figure out where the system isn’t optimized for the abilities of the people and you address that by changing the system to take advantage of everyone’s capabilities while limiting the impact of people’s weaknesses.

Continue reading

Building a Great Software Development Team

twitter screen shot of the quoted conversation

Elliot: I worked with some of the best programmers I’ve ever known at the tiny, obscure ASEE

Adam Solove: Why do you think that happened? They hired for passion, rather than experience?

If I had to pick one thing, passion would likely be it but really it is a complex assortment of things. Passion for the right things, based on what we aimed to be, mattered a great deal. That took the form of being passionate about the user experience, being passionate about good software development practices, being passionate about good software itself, being passionate about treating each other with respect, being passionate about learning and improving.

I think there were several other important factors, such as: the skill to turn a passion for good software into actual good software. This required intelligence, interest and knowledge about software development but didn’t require specific experience (computer science degree, 2 years of Ruby on Rails development, certification or any such thing). Hiring based on experience is a big mistake. In my opinion hiring based on capability and potential (which is based partially on experience) is wise.

Another factor is that we had people (those first few hires were critical) that were really knowledgable about programing good software and that became a self reinforcing process. The gaps one person’s ability and knowledge could be filled by someone else helping them understand and get better.

The expectation was that we found great solutions. If we didn’t we kept looking and asked each other for help (another factor in creating a great team). We didn’t just accept that we were confident the solution wasn’t very good but couldn’t find any better options so I guess this is the best we can do.

We were interested enough in good results that we would push for better options instead of just accepting something that was kind of ok. This shouldn’t be such a big deal; but in practice it is huge. So many places just end up avoiding conflict to the extent that it is a huge detriment to results.

Without confidence, honest debate about ideas is suppressed as people are constantly taking things personally instead of trying to find the best ideas (and if doing so means my idea is criticized that is ok). Our group was great at this. It is something I find it a bit silly to say a workplace was “great” at but in most places I find the fear of someone being concerned stifles discussion to an unbelievable extent.

This is also one of many areas where the culture within the team was self reinforcing. As new people came on they understood this practice. They saw it in practice. They could see it was about finding good ideas and if their idea was attacked they didn’t take it nearly as personally as most people do in most places. I sought to understand if people we looked at hiring would be comfortable in such an environment.

Continue reading

A Good Management System is Robust and Continually Improving

imagine various people working within it, somehow swapping out gears and cogs without the clock stopping or slowing down even a little.

This is a fairly good quote on a good management system. Some people might not like the mechanistic model – comparing an organization to a clock, and I agree that isn’t the right model, but even so it is a good quote.

The quote, from a story about the San Antonio Spurs captures what should happen with a good management system. Things just keep running well as inevitable changes take place (and keep getting better in the case of a management system).

A good management system doesn’t rely on heroic efforts to save the day. The organization is designed to success. It is robust. It will succeed with all the variation thrown at it by the outside world. A good management system takes advantage of the contributions people offer, but it is not perform poorly when others are relied on.

A well run organization has graceful degradation (when one component fails or one person is missing the performance doesn’t suffer, bad results are avoided).

With software for example, a decently created web sites may use javascript to enhance the user experience but if javascript is unavailable the site works fine (just missing some neat features that are nice but don’t prevent users from getting what they need). Poorly designed software has critical dependencies on conditions that cannot be guaranteed to be present for end users and the software just fails to work when those conditions are not met. Ungraceful degradation is too common in software. It is also too common in our management systems.

An organization succeeds because of the efforts of many great people. But the management system has to be created for an organization to prosper as what we all know will happen, happens: people will leave and need to be replaced. And the people that stay will need to adjust to new conditions inside the organization and in response to external forces. A good management system is constantly improving performance, innovating, increasing the robustness of systems and increasing the capability of people.

Related: Bad Weather is Part of the Transportation SystemHow to Sustain Long Term Enterprise ExcellencePerformance dependent on specific individuals is not robust and not capable of continuous high quality performanceEuropean Blackout: Human Error-Not

Innovative Thinking at Amazon: Paying Employees $5,000 to Quit

Amazon continues to be innovative not just in technology but with management thinking. Jeff Bezos has rejected the dictates espoused most vociferously by Wall Street mouthpieces and MBAs that encourage short term thinking and financial gimmicks which harm the long term success of companies.

Most CEOs and executives are too fearful or foolish to ignore what they are told they must do because Wall Street demands it. CEO’s and boards often ratchet up the poor management thinking by tying big bonuses to financial measures which are much more easily achieved by gaming the system than by improving the company (so companies get the games there boards encouraged through their financial extrinsic motivation focus).

Amazon does many good things focused on making Amazon a stronger company year after year. These innovative management practices seem to largely be due to the thinking of the strong willed founder and CEO: Jeff Bezos. Jeff was smart enough to see the great things being done at Zappos by Tony Hsieh and bought Zappos.

Jeff Bezos has added his letter to shareholders to Warren Buffett’s (for Berkshire Hathaway) as letters worth reading each year. In the latest Amazon letter he includes many worthwhile ideas including:

Career Choice is a program where we pre-pay 95% of tuition for our employees to take courses for in- demand fields, such as airplane mechanic or nursing, regardless of whether the skills are relevant to a career at Amazon. The goal is to enable choice. We know that for some of our fulfillment center employees, Amazon will be a career. For others, Amazon might be a stepping stone on the way to a job somewhere else – a job that may require new skills. If the right training can make the difference, we want to help.

The second program is called Pay to Quit. It was invented by the clever people at Zappos, and the Amazon fulfillment centers have been iterating on it. Pay to Quit is pretty simple. Once a year, we offer to pay our associates to quit. The first year the offer is made, it’s for $2,000. Then it goes up one thousand dollars a year until it reaches $5,000. The headline on the offer is “Please Don’t Take This Offer.” We hope they don’t take the offer; we want them to stay. Why do we make this offer? The goal is to encourage folks to take a moment and think about what they really want. In the long-run, an employee staying somewhere they don’t want to be isn’t healthy for the employee or the company.

A third inward innovation is our Virtual Contact Center. It’s an idea we started a few years back and have continued to grow with terrific results. Under this program, employees provide customer service support for Amazon and Kindle customers while working from home. This flexibility is ideal for many employees who, perhaps because they have young children or for another reason, either cannot or prefer not to work outside the home.

The first point reinforces Dr. Deming’s words encouraging companies to do exactly that – pay for education even if it wasn’t related to the work the employee was doing or would do for the company. Still quite rare decades after Deming’s advice.

Continue reading

Toyota Understands Robots are Best Used to Enhance the Value Employees Provide

Toyota has always seen robotics as a way to enhance what staff can do. Many USA executives think of robotics as a way to reduce personnel. Toyota wants to use the brainpower of employees to continually improve the organization. Toyota wants to free people for monotonous or dangerous work to let them use their minds.

Humans Steal Jobs From Robots at Toyota

Humans are taking the place of machines in plants across Japan so workers can develop new skills and figure out ways to improve production lines and the car-building process.

“We cannot simply depend on the machines that only repeat the same task over and over again,” Kawai said. “To be the master of the machine, you have to have the knowledge and the skills to teach the machine.”

Kawai, 65, started with Toyota during the era of Taiichi Ohno, the father of the Toyota Production System envied by the auto industry for decades with its combination of efficiency and quality. That means Kawai has been living most of his life adhering to principles of kaizen, or continuous improvement, and monozukuri, which translates to the art of making things.

“Fully automated machines don’t evolve on their own,” said Takahiro Fujimoto, a professor at the University of Tokyo’s Manufacturing Management Research Center. “Mechanization itself doesn’t harm, but sticking to a specific mechanization may lead to omission of kaizen and improvement.”

We need more companies to learn from the executives at Toyota. They show real respect for people. They are not focused on how much they can extract from the corporate treasury to build themselves castles at the expense of other employees, customers and stockholders as far too many USA executives are.

Toyota has been extremely innovative in investing in robotics as human assistants (partially this is due to the extreme demographic problems Japan faces): Toyota Develops Thought-controlled WheelchairToyota’s Partner RobotToyota Winglet – Personal Transportation Assistance.

Related: Webcast on the Toyota Development ProcessDon’t Hide Problems in ComputersAkio Toyoda’s Message Shows Real Leadership

Deming and Software Development

I am sometimes asked about how use Deming’s ideas on management in a software development context. My belief is Deming’s ideas work extremely well in a software development context. The main issue is often unlearning some assumptions that people might have about what the Deming management system is.

It really is surprising to me how many “knowledge workers” respect Deming ideas but then say his attempts to treat factory workers as thoughtful people who should be respected and involved in improving their processes doesn’t make sense for them because they are “knowledge workers.”

There are many good things being done to improving the software development process. I think many of them are very Deming-like in their approaches (but to me miss out on aspects of the Deming management system that would be helpful). I think Dr. Deming’s approach to software development would focuses on the system of profound knowledge (the 4 inter-related areas below):

  • Understanding variation – software development has quite a bit of variation, some probably innate [unique work] and some due to not having good procedures, batching work, not fixing problems right when they are seen, quick fixes that leave the system venerable in the long term (when you make one simple change to the code it has an unanticipated consequence due to poor practices that could have been eliminated), etc.. Many good coding practices are effective strategies to deal with this issue. And building an understanding of variation for managers (and business process owners/product owners) is very helpful to the software development process. The ideas in agile and kanban of focusing on smaller delivery units of work (one piece flow, just in time, cycle time…), customer value, maintainable code, sustainable work conditions, etc. are directly found in a Deming management system.
  • Appreciation for the system of software development. Don’t just complain about bugs. Examine the process of development and then put in place mistake proofing efforts (don’t duplicate code, use integrated regression tests, don’t put artificial constraints on that result in system distortions – unrealistic targets…). Use things like kanban, limited work in progress, delivering value to customers quickly, think of success in terms of getting working software to customers (not meeting internal delivery goals), etc. that take into account our experience with systemic software development problems over the decades.
  • Theory of knowledge – how do we know what we know? Are estimates reliable? Lets look at what users do, not just what they say (A/B testing…). Software developers often appreciate the value of usability testing, even though they rarely work for organizations willing to invest in usability testing. In my experience when software developers object to usability testing it is normally really an objection to overwork, and the usability testing is just going to give them more work or criticize things they were not allowed to spend the time they needed to do great work. That won’t always be the reason but it is the main one in my experience (I suppose their is also fear and just the psychology of not wanting to hear anything negative about what has been created – even if the usability testing shows tons of great results people will often focus on the negative).
  • psychology and respect for people – This pretty much seems like it is the same for software development as everywhere else.

Continue reading

94% Belongs to the System

I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this: 94% belongs to the system (responsibility of management), 6% special.

Page 315 of Out of the Crisis by Dr. W. Edwards Deming.

the system that people work in and the interaction with people may account for 90 or 95 percent of performance.

Dr. Deming’s quote from the introduction to the Team Handbook

I think, in looking at the total of Deming’s work, that the point he is trying to make is that looking to blame people is not a good strategy for improvement. The impact due solely to a person’s direct action (not including their interaction with the system and with others) is small in comparison to that of the system within which they work. So, Deming (and I) want people to focus on improving the system; which will achieve better results than searching for what people did wrong.

What did Deming want people to take from his statements?

Did he want us just to accept bad results? No. He was not saying it is the system there is nothing we can do just accept that this is how things are. He wanted us to focus on the most effective improvement strategies. He saw huge waste directed at blaming people for bad results. He wanted to focus the improvement on the area with the greatest possibility for results.

Did he want to say people are just cogs in the machine? No. Read or listen to most anything he said at any significant length (a full chapter of this book, a full article he wrote on management, an hour from one of his videos) and it is hard to maintain such a thought.

photo of forest trail

Pinetree Trail, Frasers Hill, Malaysia by John Hunter

Did he believe that people were not important? No. He was trying to direct the focus of improvement efforts to look not at the fault with one person but to look at the system. I believe strongly he was correct. If you blame a person as the root cause of a problem, my first, second and third reactions are why? why? why? It is possible the person is to blame and there is no benefit to exploring system improvement instead of settling for blaming the person. But that is rare.

I have written about the importance of developing people to build the capability of the organization. My father wrote about it previously, “American organizations could compete much better at home and abroad if they would learn to tap the potential information inherent in all processes and the creativity inherent in all employees.”

I wrote about the importance of the ideas behind Deming’s quotes here, back in 2006 – Find the Root Cause Instead of the Person to Blame

Continue reading

What Does Respect for People Actually Mean?

“Respect for People” is a great short hand statement. There is a great deal of complexity packed into those words.

At the simplest level respect for people requires systems that are designed with people in mind – systems are not designed as though robots were doing what people did. Then those systems also must be built in a way that respects the inherent value of people.

photo of construction site in Mongolia, 1980s

Construction site in Mongolia in the 1980’s, photo by Bill Hunter.

And the idea builds beyond that and grows into an understanding that in order for human systems to be most effective they must engage people. There are significant limits to how effective systems with people can be if you act as though people are just robots to implement the instructions given by some boss. Respect for people moves from being about just the inherent value of people themselves to a principle to allow organizations to be most effective.

Within these principles are all sorts of shades of grey where the principles shed light on ideas to consider but it becomes challenging to know what the specific situation calls for.

Things also get complicated with the way English works. There is another aspect to respect that has to do with having confidence in someone’s ability or maturity.

You don’t show more “respect for people” by overestimating them. If someone does not have the statistical skills to do a task it isn’t a failure of “respect for people” to acknowledge that.

I find myself making decisions on how to treat people differently based on what can be seen as different “respect” (in the respect = confidence in their capabilities and their self-confidence). With some people I can simple say, no you are wrong in this case it is best to do x, y, z. I find this is what I can do with those I have the most of the “respect” for their emotional intelligence.

Continue reading