Month: December 2010

  • Another advocate for Openness, Transparency, and Accountable Management

    Somewhat recently, I finished reading Employees First, Customers Second by Vineet Nayar.  It was a very easy read since the techniques the author talks about using to restore his company to an industry leader agree a lot with what I already believe.  Nayar makes a strong case, based on real experimentation and use, for complete transparency, honest confrontations with the truth of what problems and potential problems lay ahead, freedom of information, and making management accountable to employees and not just the other way around.

    Early on in his tenure as CEO, Nayar realized his company had slowly gotten used to being at the top, satisfied with slow, steady improvement rather than large leaps of innovation.  Nayar writes: [My company] had lost its competitive edge because it had become tolerant of gradual change … and unless the company becomes obsessed with constant change for the better, gradual changes for the worse usually goes un-noticed. He also realized the solution to the company’s problems, even awareness of the problems themselves, laid within the employees, not necessarily with the managers at the top of the traditional hierarchical structure.

    In his introductory meetings with employees, Nayar realized there were three broad-types of employees: the transformers who understood and wanted to make things happen, although they were often hampered in doing so by the corporate structure, the fence-sitters who would usually not commit to taking action until there was a clear tide pushing behind them, and the nay-sayers who would pretty much be against anything new.   The key, therefore, to getting employees to take action, was to let the transformers loose. Once they were actively working, the fence-sitters would see that the tide had changed and join in. The nay-sayers, of course, would still be nay-sayers, but you deal with those people separately, anyhow and try to get them into better situations.

    How to get your employess off the fence? Give them a honest cause to believe in and, perhaps more importantly, engage those who are ready to act now, first.

    With these sort of tenets in mind, Nayar set out to create an environment where the employees, particularly, the transformers,  could catch, promote, and solve problems themselves. He turned management upside down and instead of making employees accountable to management, made management accountable to employees.   Managers were there to respond to the line workers needs, not the other way around.  Their shared job was to create an environment where people could easily innovate and solve their company’s problems. Of management, Nayar writes: People saw that some of the managers were little more than aggregators and brokers of information.  These mangers’ entire authority lay in their control of the information.  As soon as everyone had access to it, their power might come into question. And that was exactly what Nayar wanted.  He recast the value of his managers not by their zones of hierarchical control, but by their span of positive influence.  To help evaluate the latter, Nayar opened up the employee review process to allow any employee to comment on any manager in the company, within their functional or project unit or not.Other traditional performance review processes were changed as well. For example, instead of just rewarding support services by their time to close each submitted issue/request, Nayar’s company also added an incentive to be proactive by making the total number of requests and issues received a monitored metric as well.  Someone closing 1000 issues in 10 minutes each may actually be doing a worse job than someone who only closed 100 within an average of 4 hours.   It’s easy to solve long-recurring issues quickly. It’s much more useful to eliminate those common problems and leave time available to concentrate on the larger ones instead.

    Nayar created a culture of trust in his company by whole-heartedly adopting a strategy of transparency and openness. Of one purpose of transparency, Nayar tells a short story: “Why do you have such large windows?” I asked my friend [who had very large windows fronting a busy street where all could see in]…. “It keeps the house clean,” he said. Transparency promotes accountability by all – both management and line worker;  helps make problems, issues, and solutions, known to all; and not only keeps the house clean, but provides direct, verifiable evidence that it is so.  Powerful results for a simple philosophy that is actually easier to enact than the traditional one of hiding information behind a “need to know” umbrella.

    Nayar had public talks with staff members, did live video simulcasting of other important meetings, and always focused on the truth of where the company was at any given moment (for better or worse) as well as where it wanted to go.  He called one aspect of this approach Mirror, Mirror which he described as … a communication exercise that involved talking with employees throughout the organization about the truth as they see it and getting them to acknowledge the reality, the elephant in the room, that everyone essentially knows about but which has never been publicly acknowledged. This exercise sounds a lot like the looking underneath the rocks aspect of Good to Great. Not only do these exercises get the employees to see and acknowledge company issues, but it often gets them known to management for the first time!

    After getting the employee insights into the company’s problems and issues, Nayar engaged them in the solution process, as well.  He writes: Mahatma Gandhi, Nelson Mandela, and Martin Luther King Jr. … these great leaders did not formulate strategy by retreating with their top people to a private place and then emerging to make a pronouncement to the masses. No, they walked the roads of their countries, met their people, and talked with them ceaselessly, – just like the Level 5 leader of Good to Great.

    There’s a lot more to Nayar’s story than what I summarized here and I think it is also important to note that not everything Nayar tried went well.  Some solutions brought unintended consequences that either had to then be corrected, or a new solution put in place instead.  Other solutions, though, brought along unintended additional solutions, as well.  I think a key to Nayar’s success, as well as to that of the Level 5 leaders of Good to Great, is an inclusive, honest dialog, an erring towards too much available information rather than too little, and a willingness to try and experiment with new ideas.  No solution is going to solve everything, but if each one gets you further down the path to continual improvement, you’re doing very well indeed.



    Scot’s best teams, both to manage and work within, were hierarchically fairly flat. Equal access to information and abilities to propose and implement solutions makes it exciting to be part of a team and working on a problem. You can create an atmosphere where people moan in the hall ways about what is wrong with the company or you can create one where people buzz in the hall way about what each of them are doing to overcome the current problems.

  • Working with academic vendors…

    In my previous post, I made the outlandish statement that not all vendors are well-versed in the skills needed to properly handle large, fixed-price, contracts for one-off products.   Now, I want to discuss some ways to effectively work with such contractees.

    Risk: Many vendors feel they are simply not prepared to assume the risk that’s involved in a fixed-price contract.  When you press them, of course, you find that risk assumption is not the real problem.  If you ask questions like, Could you do the project for $10 million?  Could you do the project for $100 million.  What if we offered you $1 billion? These questions are obviously silly, but they illustrate the point that there usually is a price point where the risk can be assumed.  So, what they usually mean by we can’t do a fixed price contract is that they don’t understand the risk well enough to be able to price it into their bid.  With this insight realized, there are a number of approaches you can take:

    1) accept certain risks for the vendor
    2) initiate some pilot studies to assess and/or eliminate key areas of risk
    3) allow some flexibility in the bid price, with certain elements being priced only after enough effort has been made to understand and costs the risky bits
    4) simply encourage them to price the uncertainty into their bid and submit a higher priced bid

    Working Relationship: Most academic teams don’t really like the customer/vendor relationship model.  Many of them are in academia, and not industry, for exactly reasons like this.  They usually prefer a more interactive partnership where science objectives, technical requirements, and management decisions are made more jointly with less clear lines of authority from contractor to contractee.  The goals of the academic world include building and sharing new knowledge and closer interaction with the project partners helps fulfil these objectives.   The contractor, therefore, has to be willing and able to devote more resources to the project and have more interactions with the contractee than they might otherwise have, sometimes partnering in parts of the work and mangement efforts.  Lines of ultimate authority and responsibility can get a bit blurred in these situations, though, so it is important to make it clear who has the final say when necessary (although only when necessary) and what decisions and discussions have contractual implications vs. those that are simply exploratory debates and discussions.

    Understanding the Contract: Many of our vendors (academic or not) do not seem to fully read or understand our contracts.  They often do not know exactly what they are expected to do, nor what their rights and responsibilities are with respect to the contract.  Sometimes this lack of understanding actually helps the contractor when, for example, a contractee does not realize that a change initiated by the contractor does not have to be accepted without additional compensation.  But even in these cases, ultimate harm is done to both the contractor and contractee if the  contract terms are not openly discussed and enforced by both parties.  No one who loses money in a contract due to changes by the customer will want to contract with them again, for example.  So, it is vital for the contractor to really explain the contract to the contractee and to constantly refer to it and abide by it when new situations arise.  This behavior gets everyone’s rights and responsibilities out in the open, eliminates a lot of arguments about what the correct course of action is, and build good relationships for this and future work together.

    Contingency Management: I referred to this issue in my last post, but it’s of such vital importance to the success of a project that I want to bring it up again here.  First of all, it is important to realize there are three types of contingency: cost, schedule, and functional.  The temptation, typically, is to use them in that order, but that is exactly the wrong thing to do.   Towards the end stages of a project, often when the most problems occur as the pieces come together for full assembly and integration, there is very little functional contingency left. The only thing that will get you our of a jam at this point, is usually money.  The only time functional contingency has any availability is early on in the project, before the design has been set and components purchased.  Unfortunately, early on in the project, there should also be lots of cost and schedule contingency, so the temptation is to keep the product fully functional and start dipping into the cost and schedule buckets.  The problem then comes, of course, at the end stage, when the functional contingency has expired and the cost and schedule contingencies have already been spent.  You don’t want to hoard your cost and schedule contingencies past the end of the project, but you do want to make sure they are available in the latter stages of the project when you are most likely to need them.

    The scientists and technologists involved in a project will not want to give up functions early in the project when, from their point of view, there is a pile of available time and money just waiting to be spent.  Worse still, they may want to start adding features as new ideas and products are discovered that will enhance the end product.  Ask any experienced project manager and they will tell you that succumbing to these two temptations is to go down a very precarious path towards successful project completion. So, one technique to employ is to leave hooks in the project for the cut or new functionality and set a date by which time it can be included if other risks have not been realized.  Doing so establishes the mindset that these three areas of cost, schedule, and function have to be continually balanced within each of their finite limits and may even inspire people to work harder in other aspects of the project so that their favorite functionality can be restored/added later.