There has been much written about managing knowledge workers. Now there is a dissection between managing knowledge workers and the specialties of managing IT/software development staff with further breakdown to managing millennials.
Regardless of these breakdowns, the first idea I want you to grasp 100% is that managing knowledge workers is difficult. It is new in the span of management theory; there are competing theories about how best to do it. We are the subject of virtually every organizational behavior experiment going on today. Compounded by cross-cultural issues with differing English language levels with dynamics, of women managing men from certain cultures. Lesson one: this is really complex!
Remember from last issue’s Leader’s Pulse on New Management Theory- Part 1? We are going to take these theories, plus a few others and take this from the theoretical level down to the level of how to actually implement some of these ideas.
Today’s software development staff, particularly millennials, have a disdain for authority, especially if there is a perceived lack of knowledge, as well as a repulsion of “process” and paperwork. However, they still require guidance, attention and support. Also, there is another layer of complexity of teams and team building, collaboration, pair programming, cross-functional teams, small work groups and their many needs vs. development of the individual.
Collaboration is a primary pillar in both Agile and DevOps. But working against this is distributed teams, and the individual’s need for autonomy. This is a delicate wire to traverse as well.
Lesson two— you need to read a lot. Do courses. I thought the Golden Rule was the primary management tenant: Treat others the way you want to be treated. This often still holds— but I am not a millennial and they often want to be treated a different way. And I manage people smarter than I. The Golden rule is not the overarching rule as it once was. A full course in managing knowledge workers is needed! We will only focus on a few ideas I have found to be particularly useful in this area.
The Agile revolution had brought this need for overhaul in IT management to the forefront. So many teams formerly divided by role are now put together into Scrum teams, regardless of role— with former silo leads and managers wondering what their job is now. As we said in Part 1- the lead and manager’s job is now empowerment, support, and more HR tasks rather than project-level work.
Another example area— fairness and consistency. When today’s tech workers feel they are not being treated fairly, or they feel certain people are treated differently or there is inconsistent management— they revolt.
The 3 main ideas discussed in Part 1 are:
- Drucker’s ideas on Knowledge Workers being different,
- Agile/Scrum moving project execution, and management to the Scrum Master and Product Owner— not leads or managers,
- The Lean principles, particularly “empower the team.”
Now we will look at practical ideas for how to implement those practices in a modern way. Everybody wants to hire smart people. In this article, we are going to talk about how to manage them.
Davenport
Thomas H. Davenport famously coined the phrase and acronym “HSPALTA” in 2002.
“Hire Smart People and Leave Them Alone.”
Can you do it? You would have to have a lot in place to even attempt this. It would take huge trust. And trust is a very big word. Trust can only be built slowly over time. The staff will have to be fully enrolled and aligned in the vision or goal of the organization, product and customer. I suggest you not do this! Collaboration, coordination, and productivity, at the very least, will suffer. The notion of team will get lost. This is asking for giant problems.
From Leading Geeks by Paul Glen I suggest you do this instead, give:
- Attention.
- Direction.
- A great environment.
- Training.
- Protection.
I highly recommend reading the book Leading Geeks by Paul Glen.
Additionally, also take a look at Drucker and the 6 characteristics of Knowledge Workers.
Leading Geeks
Leading Geeks, extending Drucker’s work, is seemingly particular to software development. It’s a wealth of experience, recommendations for modern leads and managers. He has profound and fun thoughts. I could identify with each chapter.
Drucker
Taking ideas about Knowledge Workers down to a practical level, Drucker (1966) defines six factors for knowledge worker productivity:
- Knowledge worker productivity demands that we ask the question: “What is the task?”
- It demands that we impose the responsibility for their productivity on the individual knowledge workers themselves. Knowledge workers have to manage themselves.
- Continuing innovation has to be part of the work, the task and the responsibility of knowledge workers.
- Knowledge work requires continuous learning on the part of the knowledge worker, but equally continuous teaching on the part of the knowledge worker.
- Productivity of the knowledge worker is not— at least not primarily— a matter of the quantity of output. Quality is at least as important.
- Finally, knowledge worker productivity requires that the knowledge worker is both seen and treated as an “asset” rather than a “cost.” It requires that knowledge workers want to work for the organization in preference to all other opportunities.
Let me toss out a quick restatement of these 6:
- Define the task well. Manage ambiguity.
- It is the staff’s job to get the job done— not yours. Let them do it.
- Let them do it their way. This is a tough one. Recommend, coach, but give them freedom.
- Provide an environment where the staff is always learning new things, trying new things, time to learn new skills (classes, webinars, eBooks, etc.)
- Instill the notion/belief: Pride in work, do it right the first time, cut rework waste. Build quality in from the start.
- Give visibility and recognition to each staff’s work.
These are primary recommendations for how to lead and manage knowledge workers.
Keep the Monkey off your back
Problems, issues, frustrations, annoyances, roadblocks— all of these are part of normal work, as well as joy, satisfaction, worth, using your brain, camaraderie, etc. When problems happen— deal with them. Don’t ignore them, they always get worse. But, my next suggestion for managing knowledge workers is, if you are not doing this already, do not take on the staff’s issues and problems. Have them fix issues themselves.
This is predicated on people with emotional intelligence who you can trust to want to fix problems. Also, there has to be trust. Again, trust is a big word. Also, know that it means that you are not going to abandon them— they can try various fixes with your support, coaching, and checking in.
When this was first used on me as a staff engineer, I heard: “Don’t come to me unless you have a solution to propose.” Occasionally this manager would listen to my problem analysis and say, “what do you want to do?” listen again and say, “go try it.”
For Leads and Managers, this is called Keeping the Monkey off your back.
I would highly recommend “Who’s Got the Monkey?” to read.
Wherever possible: experiment. Take a chance. Try it. It helps you and it challenges and empowers the staff.
Blanchard’s 4 management styles
The most important, and immediate way you can modernize your management is using the 4 styles of Blanchard’s Situational Management.
If you do not know this practice of Situational Leadership, go learn it!
Source: The Ken Blanchard Companies. http://www.kenblanchard.com/
The theory focuses on the evaluation of staff as to which practice— directing, coaching, supporting or delegating— should be used based on the person, or Team’s Performance Readiness.
Even if you know these principles and attempt to apply them in your team, I would still recommend refreshing your practice. The Blanchard Institute, which released some astounding findings a few years ago. See chart at right. Only a small percentage of leaders and managers actually use all 4 methods.
I suggest you read or if already familiar, reread these principles. Distinguish each of the four for your work. Classify each of your staff as to where they are today in the quadrants.
Now, here is the big part to me, and another recommendation for you in managing knowledge workers, particularly in software development: take a chance and bump each person or team up a level. Take some risk. Challenge and empower each member of your team. Let them know what you are doing. Then, pay attention and fail fast.
Actually, doing this practice will be just as challenging on you, the Leader, as it will be on the staff. The goal is to keep the staff energized, challenged, always growing and learning. For you, there are risks associated with giving too much when someone is not ready (hence, learn the evaluation process!) but the benefits can be great. For knowledge workers to have growing responsibility, challenges, and autonomy is essential to job satisfaction and productivity.
Summary
Managing knowledge workers is tough. Attracting, training, challenging, as well as retaining knowledge workers is a difficult job— and your main job.
The execution of the work to achieve a quality is their job, not yours. Engage staff and provide an environment for job satisfaction, so that they can produce a quality product.
Hire smart people but pay attention. Trust. Take some chances. Use the agile principle of Fail Fast. Try something! If it works— great! If it fails, figure out what went wrong fast and correct it, then try something else. This is a tall order. Good Luck!
