Over the last few weeks I have overheard a couple of things that really tickled me, because of their brutal portrayal of some business truism, and because of the skill of the speaker in articulating:
a blog about software projects...
Over the last few weeks I have overheard a couple of things that really tickled me, because of their brutal portrayal of some business truism, and because of the skill of the speaker in articulating:
Product Management is something that should be easy to understand. The highest level goals of product management should be easy to articulate.
1) build a valuable product
2) maintain the value of a product relative to its customer community
3) manage the investment in the product, to ensure the best possible return
Sometimes it would just be easier, and better for all parties if we were honest and just "Fired their sorry asses!" It would be easier for management, because there is less corporate drama around firing and hiring than around a reorg, or implementing alternative staffing models, and RIF's are either good (when the economy is going down) or bad (when it is going up), from a market analysts perspective - but firing ineffective employees and hiring new talent is always good.
I work in an environment that is somewhat dominated by a project governance mentality. What does this mean? What it means to me is this - that our diligence is focused on spending rather than on asset creation. Why is this significant? Because it changes how we focus the decisions in the process of software development.
Product Portfolio
If you want to manage a portfolio of software products, it is necessary to understand the organizational goals that are met by those software products. The product portfolio is a vehicle for understanding the ongoing investment in development or deployment of software assets. It requires an ability to measure the value of software assets separate from their cost (rarely done in industry today), and an ability to measure the cost of ongoing support and maintenance of software product.
This week I have been reflecting on the relationship of ego to team, and how to deal with clashes of ego's as teams form, and reform.
Over the last few months, I have watched a project that I am playing a key role on transform from an outsourced staff model to a hybrid staff model, to a staff aug model, to a hybrid aug model, and each transform has required changes in project leadership.
Don Gray wrote this post about management style entitled Managing in Mayberry. I thought that it was insightful. When I thought about the example he used, though, it was about a stable state system. It was managing to the status quo. Manager as remover of difficulty.
Where is manager as practice improver? Certainly the masterly manager will have to do this at times. Waiting and watching, allowing others to propose, building consensus - all good. But facilitating practice improvement requires decision making, and sometimes those decisions are not universally popular. How would the masterly manager deal with individuals that "go passive" or outspokenly negative about the improvements? How would the masterly manager deal with practice improvements that require cooperation with customers, or other departments.
Often I have railed against the stupidity of management, when designing one size fits all "round hole" policies. It is the single most abused policy anti-pattern in my experience.
Policy Structure:
For the purpose of this discussion, any policy can be divided into three components:
Policies are often not "free", in that there is some cost to implementing the policy. Policies often have "side effects" that are changes not specified in the benefits. These side effects can be positive or negative. Usually, the side effects of policies appear as we have to adjust business processes and practices to comply with the policy. These adjustments are evidence of "square pegs", or gaps in the policy that do not contemplate the essential complexities of the business model.
The old aphorism - "if the only tool you have is a hammer, then every problem starts to look like a nail" derives from this type of anti-pattern.
I am clearly aggravated. I have been for a while, and I finally understand why.
In the world of systems thinking, it is called Local Optimization. That is where, in a multivariable system I optimise for one variable at the expense of other variables, and subsequently reduce the overall output of the system.
In more understandable business terms, I am optimizing one or more of the means, without regard to the "ends". As my seventeen year old son put it I am maximizing one benefit without regard for the overall goal.
In organizational management, in a business with multiple business entities or sub-units - we are trying to maximise the profit of each entity, rather that maximising the profit of the whole. In process optimization, we talk about optimising throughput of one subprocess, without regard for the throughput of the whole.
Here are some examples that should resonate with everyone:
1) I spend so much time working to earn money, that I don't have time to enjoy my wealth.
2) I build an educational system optimized for a specific metric (standardized tests) but have not taught my students how to learn independently.
3) I construct a business enterprise optimized to grow the stock price quarter by quarter, but do not produce anything of value.
We can train people to be competent, but excellence is a result of an individual being given the freedom to make mistakes, to learn, and truly incented to grow without fear of retribution - not without accountability but without loss of reputation. Excellence develops when an individual recognizes his own adequacies and inadequacies, and is willing to grow by following, learning, and failing.
If "Failure is not an option!" - then the best you will get is competence.
If you must "prevent them from making mistakes" - then the best you will get is competence.
If the following the process is more important than developing the people - then the best you will get is competence.