Thursday, April 30, 2009


I will be presenting at a Ruby User Group on the topic of enterprise readiness

Some of the things that I have concluded is that Ruby is starting to gain traction and should be enterprise ready by 2011. In comparing its value proposition to Smalltalk, Ruby now has more potential...

| | View blog reactions

Wednesday, April 29, 2009


Open Source DRM

Bet you didn't know that you could combine open source with DRM? Check out project DREAM here...

| | View blog reactions


Unemployed IT Professionals in the Northeast

Many IT professionals have yet to figure out that there are lots of jobs in IT security and they can position themselves for it by attending their local OWASP meetings...

The next meeting for the Hartford chapter of OWASP is on June 10th and addition to our usual great topics on web application security, we will be inviting in recruiters from several large enterprises who will be sharing their current job openings.

This meeting will feature Marcus Ranum, inventor of the first firewall.

This event is 100% free to attend. Subscribe to the mailing list to receive updates on future meetings:

| | View blog reactions

Tuesday, April 28, 2009


Retirement from the Blogosphere: July 4th 2009

I previously announced that I would be regaining my independent on July 4th and will stop blogging. I have been noodling what should be my final topic. Should I post my own departing thoughts or should I simply respond to questions that others would like to know?

| | View blog reactions


Identity Federation and Management

Now that Sun is owned by Oracle, I wonder if Pat Patterson will be making an announcement at the European Identity Conference on whether OpenSSO will survive against Oracle's own Oracle Identity Federation (OIF) product suite it spent money acquiring from Oblix?

Oracle and Sun had competing technologies in the identity provisioning space as well. Migration between these two tool suites is non-trivial, but if one tool will loose the battle, it will become important to think more about standards such as SPML as an isolation layer vs attempting to deal with even more custom adapters.

The strategy around how identity management evolves in the enterprise is actually a more important conversation than whether Oracle decides to keep products around. I suspect that many within the enterprise have done a horrific job of making their identity management implementations other than tightly coupled. Maybe, we need some discussions in the blogosphere on IdM and looser coupling to enterprise applications...

| | View blog reactions

Monday, April 27, 2009


Did you know that SCRUM increases failure in many large enterprises...

In reading many of the internet musings about Scrum from evangelists, cynics and everyone in between, three common and somewhat contradictory themes have stood out to me:

1. Scrum implementation fails because the processes of Scrum are not followed closely enough.
2. Scrum implementation fails because the organization does not adapt Scrum to its own environment/culture/practices.
3. The processes of Scrum are not important; only the values in the Agile Manifesto matter.

Many enterprisey types miss one of the key components of agility which is to release early and often. To the degree that you don't do this, your process is not agile and bound to suffer the same sorts of problems that traditional, plan-driven processes have. It may be that this is a temporary condition as you are just getting used to things, but you need to start releasing soon (and regularly). Remember, working software is the primary measure of progress. Putting documents on sharepoints and other traditional waterfall practices are not releases.

| | View blog reactions


More thoughts on Identity Based Encryption

Awhile back, I blogged on Identity Based Encryption and wanted to share additional thoughts...

Next week is the start of what I predict will be one of the most meaningful conferences to occur on the planet. The European Identity Conference will feature the likes of Pat Patterson, Jackson Shaw, Kim Cameron, Luther Martin, David Kearns and other thought leaders all under one roof talking about all things identity related. Anyway, I am sitting here thinking about identity and this reminded me of identity-based encryption.

Identity Based Encryption really isn't about encryption but is more about key management. Encryption is an easier topic on many levels than key management and I believe that IBE attempts to sweep the difficulties associated under the rug. Trying to use identity as the foundation is fraught with problems, because no one has a really good solution to verifying identity in electronic applications, whether on the net or in the physical world. Without a good solution to identity, these IBE schemes fall on their face once you stress the identities they rely on.

Most of the IBE systems discussed in the wild lack the technical thought leadership necessary and simply devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.

The problem is that you have to have a way of generating and managing those keys, and that turns out to be hard, because the scheme is only as good as the protection you have on your private key. There are a number of methods for doing this.

ID based encryption attempts to simplify this key management problem by proposing special algorithms that construct private keys from a known public piece of information: say an email address. To do this in a way that still makes it hard to figure out the private side, you need to have a trusted entity who constructs the private key based on some other secret they know. So, to establish your communications with someone who knows your email address. you go to the trusted provider and ask for the private key to be generated. The person you want to communicate with knows what provider you use, and gets a master public key from that provider.

Now, the person you want to send to can then generate the public side from your ID without knowing anything except some master key information from the provider; the key is never transmitted direction.

In other words, it looks like this: Alice wants to send email to Bob that's encrypted. They both trust a provider, Tom.

  • Alice sends a request to Tom with her email address "", and gets back a private key P. There is a corresponding public key p, but Tom doesn't send that to anyone.
  • Bob sends a request to Tom and gets Tom's master public key m.
  • Alice encrypts her message "x" with her private key, giving {"x"}P. (That notation is just "message "x" "wrapped" or encryption with key P.) Alice then sends that message to Bob.
  • Bob uses his knowledge of Alice's email address and Tom's master key m, and computes. p=f("", m). Now he applies the decryption decrypt({"x")P, p) and poof, out comes Alice's message.

    The thing about these schemes is that it simplifies some key management issues, but only somewhat. You still need to generate the keys, and what's worse, you have to really trust Tom, because he knows everything: he can generate your private key, and encrypt with it, making any message look like it came from you. What this means is that it creates an inherent key escrow scheme; your private key can be found out.

    Most of the IBE systems I've seen any technical detail about really devolve to "trust the provider", which doesn't scale and doesn't provide real security when you really care about it. The provider endeavors to to establish identity over the network, and then acts as a trusted third party, holding the encryption keys for everyone. Relying on a trusted third party has many known weaknesses.

    Modern cryptography is all about searching for ways to not have to rely on the third party. Web of trust is one approach, the main drawback is that it leaves key management to the end users. The solution is not to make key management more expensive but to reduce the process and practices around it.

    Traditional PKI approaches rely on certificate issuers where there is clarity on who the certificate issuers are and are known trusted third parties by all. A few years ago, one of the major issues that all the browsers trusted went bust and was bought out of bankruptcy by a player who wasn't obviously trustworthy, making it clear that the weakness in that scheme is at the root of the certificate chains.

  • | | View blog reactions


    Adventures of an Eternal Optimist

    Chris swan shared a link with me on the experiences of Pamela Dingle and her attempts to attend the RSA conference that I thought was fascinating...

    Let's analyze her posting to see if new insights emerge:Do the folks at Gartner ever go easy on new startups that are short on money before they provide deep coverage on them? The RSA conference is all about folks with money and like Gartner, if you don't have lots of it to give to folks, then consider yourself and your business the step-child.

    Hmmm. While they publish the value propositions of sessions, we all know that conferences don't make any money worth speaking about on them. A conference derives its revenues from vendors purchasing booth space! Additionally, vendors will purchase even more booth space when they see lots of people visiting their booths and to guarantee lots of visitors (above and beyond those who pay) they market the opportunity to be sold stuff for free by giving out free expo passes. Achieving the goal of educating attendees is never the goal of those who run conferences.

    If you come to a conference and literally fall asleep at each session, the conference makes no more or no less than those who avidly participate. You have to tell them why they should care?

    The movers and shakers that matter to them are probably not the ones who have small businesses but those who are in large enterprises with billion dollar IT budgets as what they think matters more to them and of course the folks who are buying the booths on their behalf. My two cents says that a noble gesture would be for the next RSA conference to give free both space to OWASP as this will help attract a new demographic and breed cross pollination that is beneficial to all...

    | | View blog reactions

    Sunday, April 26, 2009


    In order to adopt Agile, do you have to divest team members from their respective skills?

    As enterprises start to experiment with introducing agile methods, skill sets are becoming blurred and people will over time receive less respect for their individual abilities...

    Some developers are excellent at server-side technologies and optimization of heavy-weight data provisioning. Others have invested a large amount of their careers learning GUI technologies and have developed a fundamental understanding of users and usability in an application. Neither skill set is better than the other but they are certainly different.

    While agile should encourage developers to learn new skills, many simply get better at becoming mediocre and never master another skill. If you have telecommuters involved, they will get even further blurred as managing remote workers is not a skill that many PMs have in their toolbelt and agile makes it more difficult. PMs can either bury resources where they give preferential treatment to those who manage face time or simply give those not in sight menial tasks that they don't have to track (aka busy work).

    While I know that many will have a different perspective, I am curious to hear from those who had different experiences...

    | | View blog reactions


    European Identity Conference 2009

    The European Identity Conference is the place to meet with enterprise technologists, thought leaders and experts to learn about, discuss and shape the market in most significant technology topics such as Identity Management, Governance, Risk Management and Compliance (GRC) and Service Oriented Architecture (SOA).

    I attend a lot of conferences but this is the one that I am looking forward to attending the most in 2009. If you will be in attendance and want to hook up, trackback. I hope to meet up with many enterprise architecture practitioners in Europe and hope to trade notes..

    | | View blog reactions

    Saturday, April 25, 2009


    Enterprise Architecture: Quote of the Week

    Too many people seem to think that documentation is the "final" argument. It's not. Not even close. It's a hint and a help, but it's _secondary_ to code. Anybody who doesn't understand that should never be allowed to write code (or documentation, for that matter).

    -- Linus Torvalds

    | | View blog reactions

    Friday, April 24, 2009


    Enterprise Architecture: How to guarantee outsourcing failure...

    I have developed a reputation for bashing Indian outsourcing without necessarily taking a look at the worst practices in the United States. Today's blog entry focuses on one that I believe accounts for the majority of failure...

    Imagine you are responsible for outsourcing a particular function within in a company... Now, the outsourcing has been going well, but it's time for a contract renewal. Will your employer thank you for simply renewing and keeping things the same, and thus keeping the service running well? Unlikely.

    More likely, you'll get your bonus only if you:

    So, how do we align what's best for our employers while not sacrificing what is best for our wallets?

    | | View blog reactions

    Thursday, April 23, 2009


    Are Europeans smarter than Americans when it comes to outsourcing?

    For the time being the best outsourcing location is Eastern Europe. Especially for companies from Western Europe as there is no time shift, there is no much cultural difference, there are all the possibilities to communicate and travel to each other etc. But still there is a nice price difference for outsourcing to be appealing.

    Just as an example of smart outsourcing - if you are a company from Sweden, what would be the right choice for you to outsource to? Naturally, it would be a country like Lithuania or nearby. As the location is pretty close but the price difference is two times.

    I wonder why American's let Europeans have such a competitive advantage while we have the ability to pull off an even better deal by outsourcing to Jamaica, Trinidad or other Caribbean islands...

    | | View blog reactions


    Links for 2009-04-23

  • The evolution of blogging
    Do you agree?

  • Destroying relational competence
    Someone likes the latest Gary McGraw podcast

  • Are bonuses demotivating your employees?
    Increasing productivity when times are tough and you don't have money as a tool is something most executives are clueless about.

  • Hackers grabbed more than 285M records in 2008
    This problem can only be solved with Barack Obama style governance. If he can get the CEO of GM fired, then I wonder if firing executives who lose data is the next best idea.

  • Bad water in CT
    Hopefully folks on my side of town are aware of the don't drink the water scandal.

  • OWASP Hartford
    This is the place where all the cool IT professionals hang out.

  • | | View blog reactions

    Wednesday, April 22, 2009


    Enterprise Architecture: CMMi is evil...

    Is the goal of CMMI to create consistent suckage...

    How many times in your career have you ran across an enterprise architect who is an employee of a Fortune enterprise where they were advocates of CMMI?

    Long procedure documents full of obvious statements are evil, because they distract the reader with trivial details. Therefore nobody will read them more than once, and most people will not read them at all (with the exception of folks doing Indian Outsourcing and others who have zero clue about anything).

    Of course one cannot simply state that CMM is evil. Making that statement without an auditable artifact flow is against evil best practice. Please create an Evil Requirements Definition document to be submit to an Evil Review Committee as directed in the Evil Development Life Cycle Manual. Once you have obtained the appropriate signatures of the Evil Personnel, you can begin to prepare and Evil Design Document that must be reviewed not once but at least twice. Once you have completed and Evil Preliminary Design Review and an Evil Critical Design Review and again received the necessary Evil Signatures, you can begin to develop your Evil Statement. Once complete, you will have to submit your Evil Statement to an Evil Independent Test consisting of testers who do not know what Evil is but have read through your Evil Requirements Definition.

    Of course, you can be Agile and Evil. Evil is flexible. Feel free to generate your own tailored versions of the thousands of pages of standard Evil Procedures. These will be carefully reviewed by the Evil Process Waiver Committee and rejected after wasting even more time and effort.

    | | View blog reactions


    Thoughts on the Sun and Oracle

    Every industry analyst has expressed an uninformed opinion on Sun and Oracle and figured that I should be equally irresponsible...

    Talking about products all day doesn't get me excited. What does is the possibility that Sun may be afforded the opportunity to fix deficiencies in their culture. I have met many Sun employees whom I thought were bright but otherwise constrained in their ability to do meaningful things like interact with customers in a proper way.

    Many Sun employees are on mailing lists and are passionate about blogging but yet never find enough ways to interact with customers on a face-to-face basis. For example, in the Hartford CT area, you can find user groups for developers being run by Microsoft, Oracle and other large vendors. What you won't find is a single event that is ever sponsored by Sun targeted at this demographic.

    So, we all know that support via mailing lists is a great characteristic but this usually matters only until after you become a customer. Sun simply doesn't do enough before you are one. Likewise, folks understand that I am passionate about building security in and believe that software companies need to have static analysis tools in their portfolio to provide secure code review capabilities. If you were to take a look at the top ten enterprise software vendors, Sun is the only vendor to not have any deep capabilities to review their own code. At some level, they rely on smart people but this isn't a sustainable model.

    Oracle's culture doesn't suffer from any of the above deficiencies and if they get the acquisition right, it could be 1 + 1 = 11. Now for a few predictions:

    1. Oracle will dump OpenSSO in three years and stick with OIF.

    2. Oracle will keep both OIM and Sun IDM as it is too difficult, costly to migrate customers between them.

    3. Oracle had a strategy around providing specialized storage capability for Oracle databases. This strategy can now be flushed as they were working with HP on it.

    4. Sun employees would do themselves a big favor by being proactive and pursuing their own startups. Think about writing those business plans you dreamed about and getting funding for them. The bloodbath is imminent.

    5. The employees within Sun who will survive will not only be the better engineers, but the ones who understand the mindset of those within large enterprises. I suggest Sun employees start reading enterprise architecture books in their spare time.

    6. The biggest bloodbath will occur with Sun employees in India...

    | | View blog reactions

    Tuesday, April 21, 2009


    If your wife were a relational database...

    SELECT wife FROM women WHERE
    looks=gorgeous AND idealman LIKE 'James'
    SELECT husband FROM men WHERE
    job=geek AND loves=Sherry

    | | View blog reactions

    Monday, April 20, 2009


    Enterprise Architecture: Why inhouse applications are difficult to maintain...

    We all know that Enterprise applications that were developed inhouse cost more per line of code to maintain than applications developed by commercial software vendors, but have never considered the factors as to why...

    Commercial software development has an advantage over inhouse developed applications along the lines of the ability to maintain conceptual integrity. Requirements are normalized across many different demographics where inhouse developed applications are not.

    Within enterprise applications, business rules are often determined by high-level managers and the marketing department. There may not be any apparent logical or rational to many of them from the developer's perspective and asking for it may not be an option. Marketers tend to be "intuitive" thinkers which often drives analytical geeks nuts.

    Inhouse applications unlike commercial software have encoded within them, the personality(s) rather than physical or mathematical truths. Enterprise architects struggle to rationalize and devise roadmaps where predicting the future of them gets more difficult as time passes.

    | | View blog reactions

    Sunday, April 19, 2009


    Agile Manifesto 2.0

    - Make business aware of programming and programmers aware of business

    - Accept the reality of change and embrace it rather than resist it

    - Personal responsibility beats external control

    - Structure is essential to success, but heavy bureaucracy is not

    - Software development should occur via empirical process control rather than defined process control

    - Planning is everything, but the plan is simply the starting point

    - Perception management is important, treating others like they are human and rewarding them for their dedication and integrity is more important

    | | View blog reactions

    Saturday, April 18, 2009


    Enterprise Architecture, SCRUM and Agile Ceremonies

    What happens when you combine the thinking of enterprise architecture with partial adoption of SCRUM, you get something along the lines of making chocolate chip cookies but without the chocolate chips...

    I was talking to an architect down the road and realized that the buzzword of SCRUM is the latest word to be abused in large enterprises. When folks are talking about SCRUM, they are talking about socialization constructs and not necessarily management practices. All of the agile methods advocate the principle that everything is important but something is more important yet most enterprise architects have no framework that guides them in this regard.

    The interesting observation I have noted is that the enterprise architects that still dabble in code have a fundamentally different perspective on the enterprise version of SCRUM than those who no longer code. One can find the results of enterprise SCRUM processes to feel a lot like cowboy coding where folks downstream are forcedencouraged to maintain 200,000 lines of undocumented comment-free code.

    SCRUM is also used to hold enterprise participants hostage. Getting off a project that you didn't much care for to work on something fun, only to be repeatedly dragged back for firefighting is amplified since it requires co-location. The enterprise decision making process has always been sporadic but enterprise scrum makes this even worse. I bet you may have noticed that many of the technical decisions in enterprise scrum are made by the least technical person...

    | | View blog reactions

    Friday, April 17, 2009


    Enterprise Architecture: Are hybrid approaches always useful?

    Two guys are in a room discussing enterprise architecture. One is extremely overweight yet desires to be a horse jockey while the other is short and skinny and desires to play basketball in the NBA. The answer emerges where they eschew common sense for a hybrid solution...

    The notion of conceptual integrity is a lost concept in most minds of enterprise architecture where consensus rules the day. We so often compromise on core principles and then wonder why things go awry down the road.

    Can the enterprise be truly competitive if decisions are made on facts and logic where perception management is more important? Lately I have been brainstorming PCI compliance and believe that the best way to comply may be to create a company policy that states all servers in the datacenter will be immediately turned off upon the arrival of auditors.

    I bet you didn't know that PCI/DSS requires code review as part of its process but doesn't require its auditors to even know how to code? Even if this requirement were put there, PCI only spends an entire fifteen minutes teaching its auditors how to look for worst practices.

    This reminds me that I need to bullshit a few process weenies I know and convince them I did a proper code review. Maybe I can ask my seven and four year old sons to bless my code just before heading out the door to Chuck E. Cheeses. I bet they will be real thorough...

    | | View blog reactions

    Thursday, April 16, 2009


    Team OWASP on Kiva

    Kiva is a non-profit website that allows you to lend as little as $25 to a specific low-income entrepreneur in the developing world. You choose who to lend to - whether a baker in Afghanistan, a goat herder in Uganda, a farmer in Peru, a restaurateur in Cambodia, or a tailor in Iraq - and as they repay the loan, you get your money back.

    Check out the OWASP lending team, and learn more about lending teams on Kiva in general, by clicking here.

    I haven't had anyone yet join from Gartner, IBM or EMC...

    | | View blog reactions

    Wednesday, April 15, 2009


    Enterprise Architecture: You are NOT management material...

    Here are a few ways of determining whether you are management material...

  • You envy the developers under you instead of your own boss.

  • When the CEO asks whose fault it is that the project is late, you say, "Yours, Sir"

  • You use statistics and facts in meetings instead of overdistilled generalizations

  • When you go out and get drunk at night with your boss, you break down and start crying about how much you love Java

  • You try to explain to the CEO how the company will capture a new market by drawing a UML Interaction diagram.

  • You hold as important the needs of the consumer and the quality of what is produced for them over the magnitude of the bottom line

  • You can personally "sign" your work with pride

  • | | View blog reactions

    Tuesday, April 14, 2009


    Enterprise Architecture: When good people get fired...

    Most employees in the US can have their employment terminated by their employers at any time, for almost any reason...

    Recently, I have heard many people talk about being fired. Some feel that the modern approach to management differs from being human (at some level I agree) but also without acknowledging all of the factors that go into a firing decision. So, I decided to outline some things to noodle.

    Because employees cannot count on their jobs being around forever, employees need to take control of their careers and their economic security. If you save your money, keep your skills up to date, and maintain contacts outside your company, then being fired should not be a disaster. Don't become too economically dependent upon your employer, and don't let your self-esteem or sense of well-being be too closely connected to your job...

    | | View blog reactions

    Monday, April 13, 2009


    Enterprise Architecture and the Federal Government

    Now that we have a new Government CIO, I figured I would share some thoughts on making it better...

  • Encourage more personnel churn. There is often too much ossification in government.

  • Don't make the job application process so cumbersome that productivity-minded people give up or are frightened away.

  • More subordinate evaluation of supervisors would help immensely. There are too many supervisors with huge flaws that never get checked because their superiors don't see it or don't care.

  • Encourage Federal Government employees to participate in OWASP.

  • Mandate that government contractors use methodologies such as Extreme Programming and SCRUM.

  • Allow for all belief systems to be fair game for questioning.

  • | | View blog reactions


    OWASP Hartford: April 2009

    Want to learn about Agile, CMMI, Extreme Programming, SCRUM or other software development topic? Scott Ambler will be speaking at OWASP Hartford tonight (Monday, April 13th) as part of a special session. If you would like to attend, drop me a note at my work email...

    | | View blog reactions

    Sunday, April 12, 2009


    Time to make it short...

    I have made this blog entry longer than usual because I lack the time to make it shorter.

    | | View blog reactions

    Saturday, April 11, 2009


    How low quality is the software your enterprise writes?

    Has anyone ever ran across high-quality internally-developed enterprise software? When software isn't consumed by third-parties, then quality can be order of magnitudes lower in quality...

    So, if quality can be lower in enterprise inhouse software, then that allows for lower-quality resources from Indian outsourcing firms to maintain it. Remember that good is good enough and it doesn't make sense for architects to expend such energy churning on better ways of developing higher quality working software.

    Indian outsourcing has caused many to lower their standards and therefore the opportunity to abuse is rampant. Methodologies such as extreme programming encourage merciless refactoring while indian outsourcing has taught us that refactoring is nothing but overhead as you have to write comprehensive documentation in order to get working software. Sometimes the effort but into documentation makes refactoring a non-starter.

    Refactoring in code isn't overhead, any more than writing a first draft is overhead in writing a book. It's an inherent part of one of the best ways of producing good code, just as writing drafts is an inherent part of one of the best ways of producing a good book.

    American IT professionals have lost the battle because they argued the quality front which no longer matters...

    | | View blog reactions

    Friday, April 10, 2009


    Industry Analysts and Federated Identity

    I was thinking that I haven't worked with any industry analyst firm in a long term in terms of allowing them to create a case study on things we do well. I wonder if there is interest in learning about what me and my employer are up to in the world of federated identity?

    | | View blog reactions


    Explaining Security to Business People

    The vast majority of IT security professionals in large enterprises don't usually interact with the business community and therefore don't know how to convince them that well-established encryption algorithms, well-established key exchange protocols, etc, will be much better than whatever homebrew scheme they cook up themselves in a couple of meetings...

    Not invented here is a common attitude in many enterprises when it comes to many things but security is even more challenging in that it requires others to acknowledge that their thinking is incomplete and adhoc schemes are not enough before they are willing to spend time and effort to quantify additional requirements.

    Security is a business issue and many decisions should be made by business people, however there is no framework that helps business people who generally aren't as passionate as IT in seeking enlightenment to participate and make informed decisions. Imagine what would happen if business customers came up with their own scheme to implement either disaster recovery and/or high availability? They will probably come up with ways that are either expensive and ineffective, or simple and ineffective. There are many ways to handle HA/DR requirements but usually you have to specify the need before you can decide how to do it.

    So, what are security professionals not doing that HA/DR types have figured out? Maybe this can be a conversation at an upcoming OWASP conference?

    | | View blog reactions

    Thursday, April 09, 2009


    Are you married to Enterprise Architecture?

    If you really love someone, then you'll stick around and take advantage of the ways they're wonderful, and you'll try to ignore, improve, or mitigate the ways they're awful. But if your husband starts slapping you around, it's time to leave. Too many folks let themselves be slapped around...

    You have a certain realtionship with your employer. You also have a relationship with your lover, your children, and your future. When the interests of these parties conflict, this may manifest itself as dissent within one or several of your relationships. Sometimes we are all consumers of a slow poison that is toxic to everything we do.

    So, if enterprise architecture is about people, processes then tools, in that order then how do we determine when we should marry things together and when things should be separated. So, if we were to focus on the people aspects then it would probably mean that we need to focus on poor people management which spreads without conscious effort and can slowly poison others.

    Poor managers are poor managers for a reason: fear, distrust, ignorance, etc. Over time, they will actually make decisions that increase these qualities in other people they deal with. This is apparent in most interactions with coworkers, but is exceptionally apparent in personnel decisions, with poor managers hiring, promoting, and otherwise rewarding subordinates with dysfunctions that complement their own. The classic example is trusting only a "yes-man", who will agree with every decision you make regardless of the quality of the decision itself.

    In addition to rewarding and spreading mismanagement, this will also drive out motivated, conscientious intelligent workers, who will at some point realize it makes more sense to focus on organizational change management over committing to other business-oriented strategies. Through this phenomena, an organization can actually get less competent over time, even with other inputs (size, revenue, business climate, etc.) remaining constant.

    Mismanagement can destroy an entire organization, but it can happen so slowly that the managers might not notice it or are likely to misunderstand why the organization is failing. So the feedback loop is not very tight, and they can either avert their gaze from the growing problem or they can find scape goats.

    | | View blog reactions

    This page is powered by Blogger. Isn't yours?