Sunday, December 29, 2013
11 Bosses You Need To Fire Right Now
Christopher Hawkins' post on 11 Clients You Need To Fire Right Now (http://www.christopherhawkins.com/06-13-2005.htm) will also tell you which bosses to fire or never work for.
Why is Dilbert funny?
Because we are bad at management. A comic strip about bad bridge building would not be funny because it isn't true. Every day we can look at Dilbert and imagine something from our own work experience.
Customer Development vs. Product Development vs. Logo Development
The key insight of Steve Blank's work is that the customer development process for a startup should take priority over product development until the required product fit has been found. This presents an interesting balancing act for a new company. The product must be developed enough so that customer development can proceed (Eric Ries' Minimum Viable Product), but no more.
What you don't hear discussed is what could be labeled as "Logo Development". The logo development process encompasses activities that are important to large businesses, but a distraction to startups. For example, unless the startup's logo is so bad that it frightens small children, no time should be spent improving it until it is clear that it is an impediment to the future success of the business. Other examples of this type of activity may include business card layouts, aspects of the web site appearance, and even the name of the company itself.
The key test for addresssing any activity is whether it is preventing the organization from moving forward. For a web-centric company, web design is often crucial. In fact, the web site may be the product, so web site changes would be properly categorized as product development. For a hot-dog vendor at sporting events, a web site might not be useful at all (although a mobile app might be).
What you don't hear discussed is what could be labeled as "Logo Development". The logo development process encompasses activities that are important to large businesses, but a distraction to startups. For example, unless the startup's logo is so bad that it frightens small children, no time should be spent improving it until it is clear that it is an impediment to the future success of the business. Other examples of this type of activity may include business card layouts, aspects of the web site appearance, and even the name of the company itself.
The key test for addresssing any activity is whether it is preventing the organization from moving forward. For a web-centric company, web design is often crucial. In fact, the web site may be the product, so web site changes would be properly categorized as product development. For a hot-dog vendor at sporting events, a web site might not be useful at all (although a mobile app might be).
Startup Source Code Quality Bait and Switch
Many software startups cut corners with low quality code. They are just trying to get ramen profitable with a minimum viable product. If they ever get to the point of a sustainable business, they will clean up their act then.
Caveat emptor. If you are an investor or customer or are otherwise contemplating putting skin in the game with respect to a software company, understand that at some point, massive resources will be required to pay down the technical debt accrued during the ramen days. If this debt is allowed to grow too large, it will one day ruin the company.
Caveat emptor. If you are an investor or customer or are otherwise contemplating putting skin in the game with respect to a software company, understand that at some point, massive resources will be required to pay down the technical debt accrued during the ramen days. If this debt is allowed to grow too large, it will one day ruin the company.
The Military Figured This Out Long Ago
The military has known for a long time that there is a difference between fixing airplanes and leading a group of people who fix airplanes. For the most part, the software industry has yet to figure out that there is a difference between developing software and leading a group of people who develop software.
It is obviously very important that leaders understand the nature of the work performed by the organization. The closer the leader is to individual contributors on the organization chart, the more important the knowledge of the work becomes.
However, it is rarely the case that the leader of a military organization can outperform the rest of the organization in basic tasks. For example, a company commander is not likely to be the best marksman in the company. The company commander should be the best at commanding a company, which should not require significant marksmanship skills when things are working properly.
I understand that most software developers have had experiences with terrible managers, and this has lead them to believe that management is a bad thing. Some companies such as Valve and Treehouse have eliminated managers completely. As long as we continue to promote our best software developers into lead and management positions, for which they are often unqualified and uninterested, we will continue the cycle of poor software management.
It is obviously very important that leaders understand the nature of the work performed by the organization. The closer the leader is to individual contributors on the organization chart, the more important the knowledge of the work becomes.
However, it is rarely the case that the leader of a military organization can outperform the rest of the organization in basic tasks. For example, a company commander is not likely to be the best marksman in the company. The company commander should be the best at commanding a company, which should not require significant marksmanship skills when things are working properly.
I understand that most software developers have had experiences with terrible managers, and this has lead them to believe that management is a bad thing. Some companies such as Valve and Treehouse have eliminated managers completely. As long as we continue to promote our best software developers into lead and management positions, for which they are often unqualified and uninterested, we will continue the cycle of poor software management.
Two Great Management Articles in Jan-Feb 2014 HBR
There are two great articles in the January-February 2014 issue of Harvard Business Review. The first is IDEO's Culture of Helping by Teresa Amabile, Colin M. Fisher and Julianna Pillemer. It describes the benefits of employees helping each other and the prerequisites necessary for helping to occur. I thought the most interesting prerequisite was slack in employees schedules. If there is no spare time in your day, you won't have time to help others. There are many other benefits to schedules that appear to be less than efficient, and I recommend you read the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco on this topic.
The second article was How Netflix Reinvented HR by Patty McCord. The big idea is to minimize policies and rely on the judgment of your people. My favorite quote is "Hire, Reward, and Tolerate Only Fully Formed Adults".
The second article was How Netflix Reinvented HR by Patty McCord. The big idea is to minimize policies and rely on the judgment of your people. My favorite quote is "Hire, Reward, and Tolerate Only Fully Formed Adults".
Measuring and Managing Performance in Organizations by Robert D. Austin
I'm about a quarter of the way through Measuring and Managing Performance in Organizations by Robert D. Austin. It is a real eye-opener for anyone tasked with developing metrics in an organization. In the foreword, Tom DeMarco and Timothy Lister explained how impressed they were with Austin's PhD thesis and encouraged him to write a book on the topic.
So far, I have been helped by Austin's discussion of the role of measurement in organizations and prior measurement models. They key finding of his work is the source of dysfunction in measured tasks. Whereas previous work has ignored dysfunction or treated it as a rare anomaly, Austin shows that it is common in measured tasks.
While many proclaim that "What gets measured, gets done", I read an alternate version that says "What gets measured, gets gamed". I wish I could find the original source for that quote.
Dysfunction in measurement systems exists because not everything can be measured, and the tasks that are not measured are not rewarded. Austin points out that when critical tasks are not measured, and therefore neglected, dysfunction results. I take this further, and believe that the more important a task is, the harder it is to measure.
Measurement has its place, but it cannot replace sound judgments by human beings. This is due to the complexity of human interactions and the fact that organizations are nothing more than collections of human beings interacting with each other.
So far, I have been helped by Austin's discussion of the role of measurement in organizations and prior measurement models. They key finding of his work is the source of dysfunction in measured tasks. Whereas previous work has ignored dysfunction or treated it as a rare anomaly, Austin shows that it is common in measured tasks.
While many proclaim that "What gets measured, gets done", I read an alternate version that says "What gets measured, gets gamed". I wish I could find the original source for that quote.
Dysfunction in measurement systems exists because not everything can be measured, and the tasks that are not measured are not rewarded. Austin points out that when critical tasks are not measured, and therefore neglected, dysfunction results. I take this further, and believe that the more important a task is, the harder it is to measure.
Measurement has its place, but it cannot replace sound judgments by human beings. This is due to the complexity of human interactions and the fact that organizations are nothing more than collections of human beings interacting with each other.
If the Mothership is Going Down, Abandon Ship
If you work at a company in decline, you should start planning your exit. There are a few situations that work out, but typically, how well you, your team, or your department is doing will not matter much when the fit hits the shan. Decisions about whom to fire, what locations to close, what to sell off, etc. are made at the macro level by number crunchers will little regard for nuance.
If you're not sure whether your company is in decline, watch the actions of the savvy business people you know. If many of them are jumping ship, they probably know something you don't.
If you're not sure whether your company is in decline, watch the actions of the savvy business people you know. If many of them are jumping ship, they probably know something you don't.
The End of Public Companies
Capitalism has been turned upside down. The traditional model is that owners hire managers to oversee employees. The assumption is that employees will not act in the best interest of the company unless managers keep an eye on them. The owners are the people with skin in the game, and management theory attempts to solve the "agency problem" of getting managers to do the owners' bidding.
Today, with the advent of public companies and liquid stock markets, the owners have almost no skin in the game. Often, the owners are only owners for a few seconds in the Wall Street casino. The board of directors is asleep at the switch, and only wakes up when an "activist investor" forces them to break up the company or lever up to pay out dividends. While the directors sleep, management has free rein to take care of themselves and then jump to a new company when the host organism finally succumbs to their incompetence or malevolence.
In the final analysis, the employees are the only ones with skin in the game. They are faced with high switching costs when starting over at a new company. Relocation disrupts their families. They often have to accept a lower position, salary, or benefits at the new company. The reputation they have worked hard to build at the old company is left behind.
Over time, we will see the end of the traditional model of public companies, because companies embracing new models will outperform them. Google is one example of this evolution. When Google went public, it kept control with the founders and offered the public the opportunity to come along for the ride. Traditional corporate governance experts howled, but Google has performed well, both in financial terms and in providing useful services. One key to the success of Google's approach is that it was transparent. The typical shareholder has no say in how a business is run anyway, but Google was explicit in its direction.
Other successful models will include employee owned companies and privately owned companies, as well as hybrids. We also see successful non-companies, such as the open source software community.
Today, with the advent of public companies and liquid stock markets, the owners have almost no skin in the game. Often, the owners are only owners for a few seconds in the Wall Street casino. The board of directors is asleep at the switch, and only wakes up when an "activist investor" forces them to break up the company or lever up to pay out dividends. While the directors sleep, management has free rein to take care of themselves and then jump to a new company when the host organism finally succumbs to their incompetence or malevolence.
In the final analysis, the employees are the only ones with skin in the game. They are faced with high switching costs when starting over at a new company. Relocation disrupts their families. They often have to accept a lower position, salary, or benefits at the new company. The reputation they have worked hard to build at the old company is left behind.
Over time, we will see the end of the traditional model of public companies, because companies embracing new models will outperform them. Google is one example of this evolution. When Google went public, it kept control with the founders and offered the public the opportunity to come along for the ride. Traditional corporate governance experts howled, but Google has performed well, both in financial terms and in providing useful services. One key to the success of Google's approach is that it was transparent. The typical shareholder has no say in how a business is run anyway, but Google was explicit in its direction.
Other successful models will include employee owned companies and privately owned companies, as well as hybrids. We also see successful non-companies, such as the open source software community.
In a Merger, Evaluate Employees in Their New Context
When a merger of two companies happens and the time for the inevitable layoffs arrives, it is important to evaluate employees in the context of their new roles with the merged company.
Two mistakes are common in this scenario. The first mistake is made by the company. Due to the lack of transparency typical of corporations (for a variety of reasons, mostly invalid), managers are not informed or consulted on the new roles for their teams after the merger. Therefore, the manager does not have the appropriate context for evaluating how well current employees will fit in the new environment.
The second mistake is made by the managers. They must predict what the new context for each employee will be and how well suited the employee is for that context. If no information on the new organization is provided, ask for it. Even when you are able to obtain information, you must also weigh it against what you know about the acquiring company and their management. What have they done in previous mergers? Do they have an "East Coast" or a "West Coast" mentality? By looking at the financials, are they just putting pieces together in the hope of selling the whole, or do they plan to operate the business long term?
As an example, let's say you develop software for Linux, and you are being acquired by a Windows shop. You would probably rank employees differently depending on whether the target OS is Linux or Windows. If the acquirer is going to maintain the Linux products while migrating to Windows, you should think about who is best at maintaining the Linux products (which is not necessarily the same is who is best at developing Linux products).
Free bonus advice: don't be naive, and when in doubt, be pessimistic.
Two mistakes are common in this scenario. The first mistake is made by the company. Due to the lack of transparency typical of corporations (for a variety of reasons, mostly invalid), managers are not informed or consulted on the new roles for their teams after the merger. Therefore, the manager does not have the appropriate context for evaluating how well current employees will fit in the new environment.
The second mistake is made by the managers. They must predict what the new context for each employee will be and how well suited the employee is for that context. If no information on the new organization is provided, ask for it. Even when you are able to obtain information, you must also weigh it against what you know about the acquiring company and their management. What have they done in previous mergers? Do they have an "East Coast" or a "West Coast" mentality? By looking at the financials, are they just putting pieces together in the hope of selling the whole, or do they plan to operate the business long term?
As an example, let's say you develop software for Linux, and you are being acquired by a Windows shop. You would probably rank employees differently depending on whether the target OS is Linux or Windows. If the acquirer is going to maintain the Linux products while migrating to Windows, you should think about who is best at maintaining the Linux products (which is not necessarily the same is who is best at developing Linux products).
Free bonus advice: don't be naive, and when in doubt, be pessimistic.
Subscribe to:
Posts (Atom)