Current category: management
Blog home
About me: I'm an unrepentant generalist finding my way in a world of specialists. I started this blog to review books, but I now talk about topics ranging from management to cognition to social software.
email me if you have any questions or comments.
Using WordPress
2.2
We had to read about Six Sigma process management last week for class. Six Sigma is a set of practices that allow companies to improve their processes towards satisfying customer needs, which is a laudable goal. The basic idea is that you have to first Define your goals, find ways to Measure your performance relative to those goals (which has its own problems), Analyze your measurement results, and then Improve and Control your process to narrow the gap between goals and results. Six Sigma calls this the DMAIC model. And that’s where I start having issues (note: this is based on reading 70 pages of a single Six Sigma book so I am extrapolating wildly).
As far as I can tell, Six Sigma is designed to make mid-level project managers feel more important and knowledgeable than they are. Rather than say “First you have to figure out what needs to get done, and then make sure that you are doing what you said you would”, Six Sigma introduces a massive infrastructure with indecipherable jargon like DMAIC and Process POA and SIPOC diagrams and QFD Matrices, terms which have precise definitions to make those who have not studied Six Sigma look ignorant.
People who sign up for the Six Sigma cult are rewarded for their increased study with status symbols leading up to the “black belt”, giving them the title of a martial arts sensei for their command of the minutiae of management jargon. By using this jargon to separate their discussions from the rest of the organization, project managers can feel that they have mastered a discipline, putting them at the same level of achievement as trained software engineers or quantitative analysts. Since this jargon is used to refer to what should be common sense (identifying goals and ensuring movement towards those goals), Six Sigma has the feel of the more bogus aspects of critical theory, where jargon can be used to dress up basic concepts to the point where nobody can determine whether a paper is legitimate.
Our lecturer made the good point in class that the prevalence of Six Sigma does mean that it provides a common framework that one can use to communicate between organizations. Aligning language is difficult, and perhaps Six Sigma has to use artificial jargon to ensure that none of its terms could be confused with terms we might think we know. This would serve a valuable purpose, but the sense I get from Six Sigma is that it’s considered to be an end in itself, rather than a means to more effective communication.
One of the perils of introducing process is that it overrides the initiative and decision making capacity of the people who have the most relevant information. I have been suspicious of process ever since an experience where an organization applied its process so restrictively that we never answered the questions that the process was originally designed to ask. We followed every single detailed step of the process, but we didn’t get any of the benefits that the process was supposed to deliver because we couldn’t adapt it to our particular situation. Six Sigma has the feel of a methodology where that could easily happen. By letting people displace responsibility onto the process (”I did what Six Sigma said I should do”), it distracts organizations from focusing on the core function of delivering value to customers.
This distrust of process may be a result of my never having worked at a large organization. Larger organizations require a certain level of process and infrastructure to function, much like animals need a skeleton to grow past a certain size. And I have seen the disadvantages of not having any process in place at some of the smaller organizations I have experienced. Perhaps if I had worked at an organization where process enhanced productivity and initiative, I might be more amenable to believing in its usefulness.
Process is a powerful, but dangerous, weapon. When used skillfully and appropriately, processes can enable organizations to be more productive and react more intelligently by ensuring that knowledge is distributed to where it is needed. But when process is an end in itself, or is misused in a task for which it is not designed, it can choke an organization and prevent people from achieving what needs to get done. Six Sigma might be great if an organization could use the parts that it found useful to help align language and objectives. However, Six Sigma could be a disaster if if is imposed in a top-down fashion where the whole infrastructure is implemented regardless of whether it is appropriate or not.
Why do organizational hierarchies exist?
I was discussing this question with a friend a few weeks ago - I actually read The Origin of Wealth because she said that it had a good discussion of this question. The answer in the book, which I sort of agree with, is that hierarchies are actually an efficient way to manage the information flow of larger organizations.
This is a consequence of the network effect on communications. The number of communication links necessary for everybody to know what everybody else is doing goes up exponentially with the size of the organization. An organization can’t grow beyond 100-150 people (Dunbar number-ish) without putting in some form of hierarchy or controlled communication, which is why alternative management structures like W.L. Gore split out new units whenever a unit grows beyond that size.
This communication “catastrophe” also lies behind the Mythical Man Month, where “Adding manpower to a late software project makes it later.” Adding manpower increases the size of the organization which exponentially increases the amount of communication necessary to make decisions about the project, which decreases the productivity of the people working on anything productive.
To grow an organization requires dedicating more and more people to handling communication. And that’s why middle management exists. We scorn middle managers as being useless parasites that just sit around talking all day in meetings, but their role is to make sure that information gets routed to where it needs to go in the company. Admittedly, their actions in real life are often dominated by petty backstabbing politics. But the purpose they serve is real, and larger organizations could not function without them.
Such organizations need people whose job is solely intracorporate communications. Unfortunately, many companies don’t realize this, so they give those people other roles, and nobody does the job of communication, leading to dysfunctional companies where the left hand doesn’t know what the right hand is doing. In particular, middle managers may think that their role is to direct their people and make decisions, distracting from their real purpose, which is to make sure that their team has all the information it needs from the organization, and that the needs of the team are being met by the organization.
It would be an interesting experiment to see if a larger organization could be run in a non-hierarchical fashion by explicitly designating certain people as intracorporate communication specialists, whose job was to circulate among the smaller teams of 5-20 people working on various things, and make sure that the teams knew about the relevant resources available to them and activities impacting them elsewhere in the organization. I might be biased, though, since a free floating role like that would be a good fit for me.
In case you’re wondering, we were talking about growing organizations at work and I was stunned to find myself defending middle management, so I thought I’d post about it. We now return you to your regularly scheduled silence while I go read about execution and operations, work on my company case studies, and contemplate my master’s project.
When I first went to work for Applied Strategies, I didn’t really understand what they did. Applied Strategies (at that time) specialized in doing demand forecasting using decision analysis, which meant that we constructed mathematical models to estimate the size of a market for a drug or a vaccine. Our analysts used complicated decision trees, taking into account the probability of getting to clinical trials, succeeding in each phase of clinical trial, getting FDA approval, what other competitors were entering the same space, how much it would cost to build a factory and scale up production, etc.
At the end of all of these calculations, a number was delivered as to the size of the market. And I was horrified to think that this number was a deliverable. There were an absurd number of assumptions made in the calculation of that number, and changing any of those assumptions would alter the number significantly. So I couldn’t figure out what the value of that number was.
I eventually figured out (or had it explained to me) that the real deliverable wasn’t the number; it was the model. By constructing this model that had all of these assumptions and possible inputs, our customers could then see for themselves how altering certain assumptions would affect the result. The model also helped our customers do a sensitivity analysis and figure out which inputs had the greatest effect on the final result, which determined the inputs for which they needed better data. In other words, the deliverable wasn’t even the model - it was using the model to help the customer determine the relevant factors in their analysis, changing how they viewed the world.
In class this evening, we were discussing various frameworks for strategy analysis, from Michael Porter’s Five Forces Analysis, to a standard SWOT analysis (Strengths, Weaknesses, Opportunities, Threats), to a PEST framework (Political, Economic, Sociological, Technological). One of my classmates at the break was commenting that he wasn’t sure that he saw the value in such analyses, because things change so fast these days that the result of the analysis is stale as soon as you’re done.
His comment reminded me of my Applied Strategies experience, and I observed that the point of the analysis was not in the specific results, but in the change in view that results from doing the analysis. For instance, us technologists find it very easy to get sucked into the everyday grind of specific deliverables. But if we do a five forces analysis, even if the results of that analysis are immediately obsolete, it starts to get us thinking about the big picture of the overall industry and where it’s heading. Doing such an analysis changes how we see the world, and that is the important result.
I am also reminded of scenario planning, as described by Peter Schwartz in The Art of the Long View and at a Long Now talk. The point of doing a scenario analysis isn’t to predict the future - it is to prepare oneself for the future. By examining the larger trends that can shape the future and how one’s organization would react to those trends, scenario planning allows the organization to identify key pointers that indicate which way trends are heading and therefore be able to take proactive rather than reactive action.
This idea that the results of a process are a change in view rather than a tangible result resonates with me. Many organizations claim that people are their most important asset, but few organizations follow through in realizing that changing the viewpoints of their people is among the most effective investments they can make. If everybody in the organization is thinking strategically (shades of Semler), then the organization will have achieved greater results than they ever could have by investing in technology or tangible assets.
Several people have asked me why I’m pursuing this degree in technology management, when it appears to them that I have all the skills for management already. This viewpoint change is a significant component. I know how to think like a scientist, an engineer, a technologist, and an end-user. I even have some inkling of how to think like a manager. But this program is giving me the tools to think like an executive, and to put issues into the terms they will understand.
As an aspiring generalist, I believe in the power of bringing multiple perspectives to an issue, of having many mental models in my toolkit. I want to be able to communicate effectively with every level of the organization, from the peons doing the front line work, all the way up to the executive board who are concerned with ROI and shareholder value. I want to be able to re-frame issues and ideas in such a way that they make sense to anybody I talk to (part of the point of this blog is for me to practice explaining ideas within the constraints of a few paragraphs). I’m still not quite sure what precise career path this is preparing me for, but I’m investing in the most valuable resource I have, my mind, and I look forward to the eventual returns on that investment.
My last post on advice for managers stirred up a great comment thread, so go read those comments first.
The main subject of contention was my third point where I said “There is no such thing as authority”. What was interesting was that every commenter had a different way of interpreting the word authority. Jessie pointed out one can be an expert authority in the field, and be consulted on that basis. Beemer and Jessie both shared experiences where they should have used their implied authority. Tstop mentioned the “big ugly stick” of authority whereby a manager can get their way because they’re the boss. So I’m posting again to explain what I actually meant, with asides to answer those comments.
Tstop encapsulated what I meant with the phrase “permission to manage” (since he’s the one that inspired the authority point, it’s not surprising he captured the meaning). As a new manager, you have to earn the “permission to manage” of both your team members and your bosses. A misconception I had early in my career was that one got that “permission to manage” by being granted it by one’s bosses. If I could persuade my bosses to appoint me as manager, then people would listen to me! It doesn’t work that way, though.
I was once appointed as the spokesperson to represent my team to the rest of the company. I went to the planning meeting, argued over the tasks that needed to be done until they were reasonable to my eyes, and then brought the task list back to the team. The grizzled veteran with 15 years of experience laughed me out of the room. I ended up giving up the spokesperson position to the veteran’s boss because I didn’t feel I had the “authority” to tell this guy what to do.
I now realize that you have to earn the “authority” or “permission to manage” of your coworkers. You have to start acting like a manager by:
If you do those things, your team will start seeing you as the leader and the person to whom they look when they’re not sure what to do next. From there, the “granted authority” implied by the org chart will often follow. In one of those Zen paradoxes, by the time you are granted official “authority”, you don’t need it because you have already figured out how to persuade the team to follow you.
The other “authority” you have to earn is the “permission to manage” from your bosses. Even if you earn the trust and respect of your coworkers, you will not be made an official manager on the org chart unless your bosses believe in you. As I mentioned in that previous post, your team has to consistently deliver results for you to earn that trust. You always need to balance between what’s best for the team and what’s best for the company.
So my previous post’s advice might have been better phrased “There’s no such thing as granted authority”. If I’m sitting around waiting for the company to appoint me to a position of leadership, I’m going to be waiting for a very long time. I have to earn that authority myself. Even if they did grant me “authority”, I would not be able to wield it effectively because I would have no way of getting my team to do anything other than by relying on the “big ugly stick” of “Because I’m the boss!” (as Tstop pointed out, there are times when the stick needs to be wielded, but it should be the exception, not the rule).
Hopefully that makes it clearer what I meant by that third point, and answers the questions and objections of my commenters. I continue to be fascinated by how people get organized to do things, and the role that managers or leaders have to play in that organization, so I expect I’ll continue to think about this topic.
P.S. Street mining today was fun. A walk around SoHo with a bunch of interesting people, dropping into shops and galleries selected by Pam Grossman, followed up by a beer at Spring Lounge and dinner with a few folks.
P.P.S. Lots of posts in various states of conception. I get distracted from posting too easily. This week it was a company excursion to Curtains on Wednesday evening, drinks with Columbia classmates on Thursday evening, and reading Harry Potter 7 on Friday evening. I think I need to be more disciplined about finding a time of day to post and sticking to it, or finding some other “ritual of preparation”, as Twyla Tharp suggested in her book The Creative Habit.
How do we change the student who looks to authority for answers into the adult who generates their own answers? Graduate school is one way, as it is explicitly about turning the student into an authority in a given field, changing somebody who does the work of others into somebody who does their own work. In the ideal case, the advisor understands that role, and mentors the student through the process.
People in industry don’t have a guided process for that same transition, which I think causes inevitable disillusionment and cynicism. If we treat new employees as if they are still students and subject to unquestionable authority, then there will eventually be a time when their bosses don’t have the answers, and the illusion of authority is shattered. However, as Jessie and Beemer pointed out, they do need the structure of authority early in their careers because they have not yet learned to function without such structure. How to handle that transition should probably be another post when I figure out a good way to do it.
A friend of mine just asked if I had any advice for a person who’s just starting his first management position at a startup. Even though I have minimal management experience myself, I’ve been in all sorts of work environments, including a startup that grew from 40 people to 150 people and went bankrupt a year later, so I’ve seen a variety of managers and management strategies. I thought I’d share my advice here, even though I’m still learning to apply these lessons in my own nascent career as a manager.
As an aside, I highly recommend picking up the book Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp. Lopp writes at Rands in Repose and the book is a collection of some of his best articles. I really like his advice on how to be a good manager, and much of what I suggest here is similar to the advice in his book. You can browse around his website instead, but I found the book form factor to be better.
This book is recommended by Joel (mentioned in his post on “Econ 101 Management”) so we read it recently in our book club at work.
The premise is that measuring employee performance is guaranteed to distort an organization’s desired results. This assertion contradicts management mantras everywhere, such as “You can’t improve what you can’t measure”. How can a manager know her employees are doing the right thing for the company unless she measures their performance?
Austin attacks this conventional wisdom by creating an economic model of how managers and employees will interact, and then exploring the consequences of that model. The model assumes a certain amount of intrinsic motivation - that the employee wants to do the right thing, but is only motivated to work so hard on their own. So the manager has to offer incentives to get the employee to work harder.
In the model, the employee has two dimensions along which their performance could be measured. If the manager offers incentives based on only one of the dimensions, that will distort the employee’s efforts. Austin uses the example of a job placement service which offered incentives based on the number of job applicants each employee interviewed. The inevitable result was that the employees spent all of their time interviewing applicants and none of their time calling companies to find jobs for those applicants. The goal of the organization was to connect applicants with jobs, but because of the distorted incentive system, it failed completely. Another example is from 21 Dog Years, where customer service representatives at Amazon were measured by how many phone calls they answered per hour. Mike Daisey hung up on every third caller and won a customer service award because he answered so many calls.
At this point, many managers are saying “That’s because the measurements were stupid - if I measure enough aspects of performance, then I can construct an appropriate incentive system.” The problem is that not only do managers have to measure all aspects of performance that contribute to company goals, they have to measure them all equally well. Otherwise, Austin’s model shows that the poorly measured aspects will get ignored in favor of the well measured aspects, and the same sorts of performance distortion occur.
Furthermore, measurement has a cost. An organization has to spend time and resources constructing measurement systems and reviewing the results. If an organization has to measure many aspects of performance to monitor employee performance, the cost of such measurement may outweigh the short-term benefit in increased employee performance.
Austin acknowledges the possibility that in a system with perfect knowledge of what an employee should be doing, such as an assembly line, it might be possible to perfectly measure performance along all relevant axes. But in a knowledge and service based economy, the measurement of performance is always going to be inexact. Because measuring performance directly is impossible, organizations use easier-to-measure proxies for performance. And because there is not a direct correlation between measurement and performance, distortions are introduced into the system.
Austin recommends managing by increasing the intrinsic motivation of the employee to do a good job. He makes the assumption that employees know the most about how to do their own job, so they are the only ones who can optimize their effort among the different aspects of their job. So a non-measuring manager needs to convince the employees to do their best “by example and through persuasion, and in clearly communicating direction to employees”.
The weakest part of the book is that Austin’s thesis rests on the model he constructed for how employees might behave in a measured environment. While the model is appealing, he provides very little data justifying the assumptions he builds into the model. For instance, he assumes that the employee knows better than the manager on how to optimize effort, but that assumption would not hold in a situation where a recent college graduate is being managed by a twenty year veteran. He also assumes employees want to do the right thing for the company/customer, which is not universally true in my experience. Austin is playing the same game as the managers he criticizes - he makes convenient assumptions and constructs a system that will work for those assumptions.
Despite having issues with his methodology, I agree with Austin’s recommendations for management. I hate being measured, as my rant about timesheets illustrated. Don’t revert to Taylorist management methods that treat the employee as an automaton that has to be bribed into doing the right thing. Hire skilled people who want to do a good job, point them in the right direction, and then clear obstacles from their path so they can get there.
I recommend the book as a thought-provoking read despite its weaknesses. Austin’s model is a good counterweight to the pithy aphorisms spouted by management consultants. His thought experiment provides ammunition for a more human-oriented style of management, where employees are treated as more than numbers in a spreadsheet.
I went to the nextNY happy hour last week, which got me thinking about the different ways in which people network.
Measure of success for the agenda networker: Whether he advanced his agenda by attending.
Measure of success: Practicing and refining the pitch
Measure of success: Number of business cards collected.
Measure of success: Not applicable. They were born to attend such events and experience great joy in them. I’m jealous of them.
Measure of success: Meeting some people they can go for drinks with later.
Measure of success: One good conversation and/or finding one person that I want to stay in touch with in the future.
This list is by no means comprehensive, but lists a few of the archetypes I have come across at such events.
What interests me is finding an event structure that can accommodate all of these different networking styles and goals. Different event formats lend themselves to different networking styles, as I discussed in my post about Meta-Brainjamming. A happy hour is great for the connector or the “personal relationship” networker, but it’s less amenable for the agenda networker, who’d prefer to break off conversation if it’s not useful. Conferences might work better for that type of networking as there’s always the excuse of a session to attend. Round robin one-on-ones like the BrainJam had would be great for the Rolodexer, but annoying for others.
What kind of networking do you do? What advantages and disadvantages do you see in it? Before going to a networking event, do you assess what you are trying to get out of it, and whether your goals are compatible with the format of the event?
Feedback sessions are a powerful tool for generating forward progress in any aspect of life. Even though I determined that iteration and feedback don’t work as a management tactic, I still think feedback sessions are important.
One simple benefit is that regular feedback sessions force you to take action. It almost doesn’t matter what form the session takes - it could be a daily status meeting, a one-on-one with your manager or mentor, or even a journal update that you write for yourself. You can keep yourself moving forward by regularly being evaluated on what you’ve done since your last session, and what needs to be done for the next one. I feel like I have drifted less since starting the five minute daily journal report suggested by Gerald Weinberg. There’s no implied consequence in failing to accomplish my daily goals, but getting into the habit of setting goals and recording whether I reached them has kept me more focused and disciplined.
Another benefit of regular feedback sessions is to confirm which direction is forward. One tactic I use in rapid prototyping situations where direction is unclear is to create a first draft just to have something to criticize. I don’t spend a lot of time on that first effort because I’m not trying to solve the problem with it. Its point is to elicit criticism, and by analyzing and understanding that criticism, I learn where I should be spending my design efforts and what the final goal is as of today. By getting early feedback, I don’t waste time polishing a solution that doesn’t fit the situation. Because I intentionally didn’t spend much time on that first attempt, I’m not personally invested in it, so I am open to exploring other options in response to the feedback I get. With regular feedback sessions, I can work with my teammates in shaping our work even as goals change.
To take a specific counter-example, I once worked at a company where a software team interviewed end-users about what they needed, drew up a specification and disappeared for six months to code to that specification. They came back with software that did exactly what was requested and found that circumstances had changed drastically over the six months since the specification was written, making their software useless. But because they had spent six months writing that software, they were emotionally invested in finding a use for it, so they spent another couple months trying to fit it into what the end-users were doing. If they had re-evaluated the specification every two weeks with the end-users, they could have evolved the software in response to the changing landscape and not wasted their time or the time of the end-users.
Feedback sessions also allow us to overcome our innate desire to keep doing what we have always done. We humans are subject to the consistency principle described by Cialdini, where once we say we’re doing something, we become more committed to doing it. We don’t want to find out that we made the wrong choice, so we either don’t evaluate the results, or interpret the evaluation results in order to support the choice we made. Feedback sessions allow us to verify that our choice is having the intended effect.
In an environment where feedback is valued, the review informs what will happen next. If everybody involved has agreed to take action in response to feedback, designing the evaluation process is in some sense more important than designing the work itself, because the evaluation process will determine how the work evolves. This is the idea behind test driven development, where the evaluation (test) is actually written before any work starts on the software itself. This is also why students always clamor to know the grading scheme at the beginning of the term - they plan their work by knowing how they will be evaluated. A good evaluation process creates a good end result.
Feedback sessions play a large part in why I currently function better as a team player. I do not yet have the self-discipline to re-evaluate myself with brutal honesty on a regular basis. I’m working on that with exercises like the daily Weinberg journal. I’ve also started setting up regular phone calls with trusted friends to talk about my life goals, and even though they are friends, I feel a responsibility to have made some progress towards those goals between calls. These feedback sessions are increasing my ability to move forward and execute, and I think that is a good thing.
P.S. I wrote this post on a bus on the way to Cornell. Yes, the bus has wi-fi. Luxury!
My recent post on fixing the real problem reminded me of an earlier post on the rapid prototyping of life, where I said “The qualities which point towards rapid prototyping are where the final goal is poorly defined, where only experimentation, not theory, will help define that final goal, and where there are no irreversible consequences for trying something.”
Can we apply these iteration and feedback tactics to management? It seems like an appropriate solution, as managers are often in situations where the real problem is “poorly defined”. Perhaps the only thing a manager can do is to guess what the problem is, try something to fix it, see what happens and then repeat the process.
Unfortunately, people are involved, and people have memories. My statement on the applicability of rapid prototyping included a clause about “no irreversible consequences”. That doesn’t apply here. If a manager decides that the problem is that employees aren’t working hard enough, and the real problem was a technology issue, then that manager loses credibility in the eyes of the employees, opening an irrecoverable breach of trust.
Another problem is that the feedback received as a manager may be untrustworthy. In rapid prototyping, evaluation is an integral part of the process, because the feedback drives the direction of the next iteration. In a management situation, the relevant feedback would have to come from the employees being managed, and that feedback is inherently suspect because of the power differential. Very few employees will provide critical feedback to their manager, even in anonymous forums, for fear of retributive consequences. Even positive feedback can’t be trusted because employees may be deceivingly flattering in hopes of currying favor.
I think there are ways in which iteration and feedback can be incorporated into a management setting, but they depend on a having already built a team. When there’s a problem with a project, the manager can’t unilaterally make a decision without risking losing the team. He has to consult the team to collect possible ideas and create a consensus around one of those proposed solutions. There has to be a foundation of trust between the team and the manager for iteration and feedback to work, and for the employees to believe that their feedback will be included in the next iteration. That trust takes time and several iterations of projects to establish, so hopefully you’re not a bungee boss.
There’s also an element of iteration as a new manager. You’re going to mis-read situations and make the wrong choice sometimes, and you have to learn from those mistakes. The team also has to see you accept feedback and change your behavior, which will make it easier to get better feedback the next time, creating a virtuous circle of trust and improvement. One critical tactic for earning that trust is to take the blame, not only for yourself, but for the team.
Wow, this post ended up in a different place than where it started. I meant to write about how to use rapid prototyping and Trust but Verify methods in management and spent an hour yesterday on a draft that wasn’t working. But after writing a comment about trust this morning, I realized that the whole approach was bogus, so I ended up writing a post about how those tactics _won’t_ work. Ah, the joy of thinking in public.
When I worked at Signature BioScience, there were ten other software developers, all of whom wrote better and more sophisticated code than I did. Yet I survived through multiple layoffs as Signature spiralled into bankruptcy, and I was the only developer re-hired by MDS Sciex when they picked up the pieces from Signature’s carnage. Seem peculiar?
It was actually an easy choice for Sciex. At the time Signature went under, I had written the vast majority of the code actually being used by the company. The difference was that the other developers went to the biologists, asked them what software they needed, put together a specification based on what they were told, and coded to that specification. Yet somehow, even though they delivered code that did exactly what was requested, it never did what what the biologists wanted.
My skill as a software developer was not in my programming skills, but in my ability to identify and fix the underlying problem. When a biologist asked me for software that did A, I’d talk to them, realize that they were actually trying to solve problem B, and give them software that solved problem B by doing C. When I worked as a consultant, one of my clients said in admiring bewilderment, “You never give me what I ask for, but it always does what I need!” Similarly, the biologists at Signature eventually said “Eric just reads our minds!” when asked why they used my software over the software delivered by other developers.
I was thinking about this recently because identifying and solving the underlying problem seems to be a general concern of management. To take a concrete example, if sales aren’t meeting expectations, what’s really going on?
Is it that
As a manager facing this situation, it’s important not to dive into fixing the problem without first determining which of these possibilities apply, because you could end up like those developers at Signature, doing a lot of work with nothing to show for it. It’s also important to not to get too attached to a single solution (like making your people work harder), because that’s the “everything looks like a nail” situation.
As an aside, I think this is the idea behind the theory of constraints in manufacturing, as described by Eliyahu Goldratt in his books The Goal and Critical Chain, but I haven’t read those yet.
This idea of first identifying the real problem also applies in the softer side of management. When somebody isn’t doing a task assigned to them, what’s going on?
It would be easy to assume any of these and take action, but picking the wrong one could exacerbate the problem.
As an aspiring manager, I believe it’s impossible to distinguish between these various possibilities without actually talking to the employee in question. All the project management software in the world won’t help you figure out what’s really happening - such software can only provide an idealized abstraction of the situation. Five minutes of conversation can often identify the obstructing issue, and make it clear what the appropriate response is. I also believe that such conversation shows interest in the employee and makes it clear to them they are valued, but that’s a personal bias.
The difficulty of identifying the underlying problem is why the characteristics of reflection and thoughtfulness are so important in a manager. It’s too easy to jump on the first solution presented and spend resources without having any impact on the problem. You can tell the companies that do this - they unquestioningly adopt the meme-of-the-year from Re-engineering to Six Sigma to Total Quality Management to Agile Programming, hoping that this time it will solve their problems.
So when faced with a problem, don’t assume you know what’s going on and immediately start yelling out orders in an attempt to exude authority. Take the time to talk to everybody associated with the problem, figure out what they think is going on, get agreement on the problem and possible solutions, and go from there.
