How to be a good leader

We have all had good leaders and bad leaders in our careers and often people who are a mix of both. Unfortunately there seem to be far more bad leaders than good ones. This really isn’t acceptable because leadership has a big impact. Good leaders help us do our best work while bad leaders stress us out and make it difficult to do good work. Fortunately you can learn to be a good leader with coaching and experience.

As part of IE’s agile training I asked people to take part in a retrospective on managers and leaders during their careers so that we could define what it takes to be a good leader. This is what we came up with.


Good: encourages, supports, defends and rewards good work.

Bad: negative, complains, attacks and blames.


Good: coaches and trains, shares the glory, gets the best out of people and helps people move to a better role.

Bad: takes credit for other peoples work, blocks training and blocks career moves.


Good: encourages people to raise issues, discusses issues and happy to be wrong.

Bad: doesn’t listen, shoots the messenger and has to be right all the time.


Good: accepts issues, takes ownership of problems and discusses difficult issues with people.

Bad: refuses to admit there are problems, won’t take responsibility for problems and refuses to discuss difficult issues.


Good: resolves issues blocking the team, resolves conflict, calm under pressure and says no when required.

Bad: doesn’t resolve issues blocking the team, doesn’t improve team methods, doesn’t resolve conflict, is afraid of upsetting people and doesn’t challenge broken systems.


Good: understands the work, helps improve the way the work is done, challenges bad rules and poor practices, streamlines administration, makes good decisions and helps their team efficiently produce high quality work.

Bad: doesn’t understand the work, doesn’t provide enough resources to do the work, gets in the way of people doing the work, forces people to comply with stupid rules and bad practices, increases administration costs, makes poor decisions about the work and makes their teams slow and low quality.


Good: delegates, empowers, coaches, mentors and teaches.

Bad: micromanages, doesn’t trust anyone, demands frequent detailed reports, wont delegate and doesn’t coach.


Good: open, honest, encourages discussion, doesn’t tell you what you want to hear and leads by example.

Bad: manages perception, denies involvement in decisions, is deceitful and deceptive, breaks promises and says one thing and does another.


Good: understands people, cares about people, builds relationships, leaves their ego at the door.

Bad: feels entitled to power and privilege, is jealous of others, doesn’t care about people and treats people like tools.


Good: calm, organised and clear.

Bad: disorganised, poor briefing, sudden urgent tasks and frequent changes in direction.


How to reduce waste in IT – Waiting Costs


Waiting costs time and money. When customers have to wait for a product or service they are spending time and resources they could have used for something else. This means that the total cost of a product to a customer is the direct cost plus the cost of waiting. The more time you make customers wait the more expensive your products and services are.

waiting cost2

It’s the same for employees and internal customers. The total cost of a product or service to an organisation is the direct cost plus the cost of waiting. When employees have to wait for the instructions, permissions, parts or tools they need to do their job then the organization ends up paying them to do low value activities when they could be adding value to a customer.  So the cost of waiting comes straight out of profit.

When waiting becomes a regular problem people respond by hoarding which increases cycle time and inventory which increases waste further.

The causes of waiting

Waiting is caused by bottlenecks in the system which are in turn caused by a poor system and by a failure to provide the people doing the work with the information, parts, tools and resources they need.

In command and control systems senior executives usually don’t consider waiting costs because they are too far away to see them and aren’t measured on them. As a result they drive internal and external suppliers to provide products and services at the lowest direct cost even if it causes delays. One of the main ways to do this is to centralise work into large batches and send it offshore to the supplier with the lowest labour costs. The problem is that this creates major communication, quality and alignment bottlenecks which lead to high waiting costs across the organisation.

For example a high quality in-house or outsourced IT team can usually deliver a fully configured and installed test server on site for a development team in a few days for $10K with only a few hours of client input. In comparison a big low cost offshore service provider might be able to do the same thing for $7K due to low labour costs. If you install a lot of servers it would seem like you could save a lot of money by outsourcing it all to one of these big offshore companies.

The problem is that it often takes a low cost provider six to twelve months to deliver, configure and install a test server. For example one large multimillion dollar project that I was involved in was delayed because the infrastructure provider said they would be able to deliver the environments needed in six months and then took nine months to deliver the test environments and fifteen months to deliver production environments. While the team of 80 were waiting they minimised the impact by escalating to management, developing work-arounds and doing any work they could. As a result the project was delayed by six months and went over budget by more than a million dollars which was a lot better than it could have been. This is unfortunately a common experience in large organisations which happens when management don’t count the cost of waiting.

Some other common examples of waiting in IT are:

  • waiting for stakeholders to provide feedback on requirements;
  • waiting for the architecture team to review the design;
  • waiting for management to provide approval to proceed through a stage gate;
  • waiting for management to provide funding for the build phase;
  • waiting for procurement to approve a vendors statement of work;
  • waiting for another team to change a shared component;
  • waiting for defects to be fixed that are blocking a test module and
  • waiting for a deployment window.

How to reduce waiting costs

In free market economies decisions are made locally by the people impacted by them. To these people waiting costs are obvious and serious. When stakeholders and employees can choose between suppliers then they will choose the one that has the lowest combination of direct costs and waiting cost. These decisions drive down waiting costs across the organisation. As a result one of the best ways to drive down waiting times is to push resource and supplier decisions down to the users of those suppliers.

Another way to reduce waiting times is to implement the Plan Do Study Act cycle to remove blockers and streamline your work. That is to: study your process to identify issues causing delays, plan changes to resolve these issues, act to implement these changes and check the impact of these changes on cycle time.



Control charts are an important tool to help you study delays in your process. Control charts measure the time it takes to complete a cycle of your key business processes for software development and infrastructure delivery from you’re stakeholders point of view;

waiting cycle time2

Cumulative flow diagram’s are another useful tool which helps you identify which part of your process is slowing progress;

waiting cfd

Once you’ve identified the area where delays are occurring you can address it by using the following techniques.

  • Allocate more resources to the bottleneck area to increase it’s capacity;
  • Put in place a buffer before the bottleneck to make sure that it doesn’t run out of work;
  • Stop previous processes from increasing the queue of work for the bottleneck station;
  • Reduce batch sizes to improve flow through the bottleneck;
  • Use daily scrum meetings and visual project management tools such as Kanban boards to ensure that everyone is clear on what they need to do each day;

You can also increase the speed of the bottleneck station by using “Five S” to reduce wasted motion.

  • Remove all steps that add no value to internal and external customers;
  • Streamline the work process to remove any unnecessary effort;
  • Develop Standard Operating Procedures to reduce time and improve quality;
  • Continually improve the standard procedure;
  • Implement reviews and automated acceptance tests to improve reliability and quality;

Waiting is a major cost to organisations that can easily out way any benefits gained from driving internal and external suppliers to drive their costs down as low as possible. To reduce waiting costs measure them, push decisions down to users and implement the PDSA cycle.  This is well worth doing.


How to reduce waste in IT –Wasted Motion

In manufacturing wasted motion is any movement by a worker or machine in a work space that does not add value to the customer. It includes searching for instructions and tools, retrieving parts, making and modifying parts and rotating or twisting during assembly. Wasted motion reduces efficiency and increases wear and tear which causes injuries and breakdowns.

Since 1900 industrial engineers have made huge improvements in production efficiency by using assembly lines and time and motion studies to reduce the time and effort it takes for workers to do their work. This approach led to the modern industrial era of low cost, mass production, commodity goods.

assembly line

In IT wasted motion is any effort by the IT team that does not add value to an internal or external customer. It includes things like working off old version of documents, fixing defects, creating documents instead of code, deploying software changes manually and waiting for a server.

Wasted effort is ultimately caused by uneven work flow and unreasonable demands.

In Lean production you reduce wasted effort by applying a process called 5S or CANDO. At first this approach doesn’t seem to apply to IT but when you translate it from a physical space to a virtual one it has a lot of value.


Sort or Clean up.

Remove everything not needed in the work space so you can find what you need easily. In IT you can apply this by regularly archiving old versions of documents in your file system and refactoring your software to make it easier to understand and change.

Streamline or Arrange.

Organize your work so that it flows smoothly and consistently without waste, defects or delay. Define your end to end business process from the customer’s point of view and track your work on a Kanban board. Work in small batches. Set up cross functional teams and keep them together. Use Scrum and XP. Use acceptance test driven design and development. Automate software builds, tests and deployments.

Shine or Neatness.

Review your work flow regularly to maintain standards. Build review steps into your business process. Get testers to review requirements and design before you build and get developers to review each other’s code before you deploy to test.

Standardize or Discipline.

Develop common standards and ways of working. Develop and use standard business processes, templates and coding standards. Develop checklists for code reviews and new accounts.

Sustain or Ongoing Improvement.

Use standard methods and continually improve them. Set time aside to write down your methods regularly, train new people in them. Encourage people to experiment with methods and improve them.

The dangers of over optimizing

In the service sector many companies have adopted an assembly line approach to cut costs so they can be more competitive. This approach often leads to a situation where you have to wait a long time for a service only to find that it doesn’t do what was promised and costs more than expected. When you follow up it’s common to get pushed from one person to another with no resolution to your issue and no updates on what’s going on. This happens because it’s possible for one step in the process to reduce costs by cutting staff so much that it increases time and costs for the customer and other steps in the process.

To avoid these problems we need to make sure that when we are reducing wasted time and effort in our own step we increase the value of the end to end business process to the customer not decrease it.

How to reduce waste in IT – Transport Waste

In manufacturing transport is moving products between operations and locations. It could be moving product from the machine shop to the welding shop, or from a factory in China to an assembly line in America. Transport increases shipping and handling costs, damages product and delays the process without adding value to customers.


In IT transport waste is the time and cost caused by handing over work from one functional team to another. For example from a build team to a test team, from an internal team to a vendor team or from an onshore team to an offshore team.

When work is handed over from one group to another there are engagement costs, management costs, learning costs and delays. To maximise utilization many functional teams do work in big batches which leads to over production, over engineering and big queues of work in progress. In additional physical, organisational and cultural distance between groups often lead to poor communication and poor integration which cause a lot of defects and rework which increase time and cost further.

handover cost2

Many big IT departments are full of handover costs because they have adopted a strategy of cutting costs by centralizing each specialist function in a shared service, standardizing the work and outsourcing it to the lowest cost commodity vendor. When this is done each central function focuses on cutting costs by reducing team size and skill until they just barely meet minimum acceptable standards and by adopting strict procedures which push as much work as possible onto customers and other teams. Any local savings from doing this are outweighed by a large increase in time and cost to the customer when you look at the system as a whole. As mentioned before this leads to situations where it takes 12 weeks to get a firewall rule changed and 12 months to get new servers in production.

Handover time and cost can be reduced by setting up co-located, cross functional teams that contain all the functional specialists required to do the work from beginning to end just in time to meet customer demand and by mapping out the end to end business process from the customer’s point of view and eliminating any steps that don’t add value. This approach can deliver large savings in time and money with little cost.

The lean approach to reducing transaction costs is well aligned with the Agile Manifesto which says that we value “Customer collaboration over contract negotiation” and the Agile principle that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

This is not an argument to do everything in house with permanent staff. If your IT organization is not able to work in cross functional agile teams or does not have the capability for a particular project then you may be better off engaging an agile team from a quality local provider to both do the project for you and teach you how to operate in a lean agile way.

In the next article we will look at another cause of IT waste.

How to reduce waste in IT – Over production

In a previous post I talked about the different types of waste in IT. In this article we will talk about the waste of overproduction

In manufacturing over production is making too many products before they are actually needed. Over production ties up capital in work in progress and excess product, takes up space and increases support costs. This reduces profit and the money available to build other products that customers want.

In IT over production means building and supporting features that are rarely or never used. In a 2002 study, the Standish Group found that in traditional waterfall software projects 64% of typical system features were rarely or never used.

feature usage

Over production of features occurs often in traditional IT because stakeholders are only given one opportunity to present their system needs every 5 to 10 years. Recognizing that this is their only chance, stakeholders specify everything they’ve ever dreamed of with the hope that it will deliver value. IT project teams take these requirements without question on the assumption that stakeholders understand what users need.

The principles of Lean Manufacturing require that we make what the customer wants when they want it, pulling only what is ordered through your work flow. We can do this in IT by re-organising our work to deliver small batches of features frequently with cross functional teams that have a short cycle time from feature request to delivery combined with a customer feedback loop to determine if users really want what we delivered or need something else instead. This aligns well with one of the key principles of Agile IT which is that “our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. For guidance on how to implement a customer feedback loop take a look at The Lean Startup.

In my next post I will examine waste from over processing in IT.

How to reduce waste in IT – Excess Inventory

In manufacturing inventory is raw materials, work in progress (WIP) and stocks of finished goods. Money tied up in inventory increases debt, reduces return on investment and is not available for other work. Excess inventory also increases transport, storage and administration costs. Over time excess inventory becomes obsolete and must be written off.


In IT any work done on planning, analysis, design, development and testing for system features that have not been deployed is inventory waste. Most traditional IT groups are full of inventory waste because they spend millions of dollars on waterfall projects that take years to deploy to production. For example a $10 million IT project that delivers in one big bang after two years has $10 million of inventory before it deploys. If your IT division spends $100 million a year on projects like this then you have an average of $100 million dollars tied up in IT inventory all the time. If you could reduce your software development lifecycle from 2 years to four weeks then your IT inventory would drop to less than $4 million which means that you would have an extra $96 million available for profit or other projects.

In IT as in manufacturing the main cause of excess inventory is over production and queues of work within the production process. As described in a previous article over production is caused by doing work in big waterfall projects. It’s made a lot worse by doing the work in specialist teams that throw it over the fence to the next team at the end of a phase. When work enters a team in a big batch it blocks other work and takes a long time to process. When the team is slow, under-resourced or has a long lead time then work sits in a queue for a long time. For example, when an IT Operations team has minimized its costs to the point that it takes several months to provide a server then this causes unfinished work to pile up in software projects that need servers.

The best way to reduce inventory waste in IT Operations and Software Development is to set up cross functional teams to do the work for each requirement Just in Time to meet customer demand. A good approach is to set up a Kanban board for each team with columns for request, analyze, design, build, test and deploy. When you have a Kanban board you can measure the average cycle time from customer request to deployment and you can see where work is building up and take steps to reduce it. It’s not important to ensure that every person is fully utilized. What is important is to implement things that customers value as quickly as they need them and no faster.


The Agile principle that we “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale” aligns well with this approach.

Excess work in progress hides a lot of other problems. When you drop your work in progress you start revealing issues that are causing waste in other areas. I will continue this series on reducing waste in IT in subsequent articles.

How to reduce waste in IT – Over Engineering

The next major waste we will look at in this series is over processing. In manufacturing over processing means doing more than the customer requires. For example: painting areas customers don’t see or producing products with unnecessarily tight tolerances. Over processing increases labor and material time and cost without delivering extra value to customers.


In software development over processing is caused by designing and building more complex applications than users require. For example: rebuilding an application on a new platform when the old platform could have been upgraded for a much lower cost, using a complex middleware product that causes a lot of extra work or building an ideal server platform that can cater for far more users than you expect to have any time soon.

Over engineering is common in traditional software development because design is done upfront by a software architecture team when the requirements are over stated, the solution is uncertain and the costs are unknown. As a result traditional software architects often design big, complex solutions using the latest technology with little consideration of the cost.

In IT Operations over processing occurs when you give customers more than they need sooner than they need it. For example: setting up a new employees PC two weeks before they start or getting new servers into production in one week when most projects won’t use them for two weeks. This happens very rarely.

In Lean manufacturing you minimize over processing by developing acceptance criteria that customer’s value and standard operating procedures to meet them with the minimum time and effort possible.

In software development we can minimize over engineering by moving from big design up front to continuous just in time design that evolves as we learn what we really need to build.  We do this making design a role within a cross functional team that develops software from beginning to end in small batches with a short cycle time and a lot of feedback from users. This aligns well with the Agile principle that “Simplicity–the art of maximizing the amount of work not done–is essential”.

In IT Operations we can minimize over processing by asking users what they need and then developing standard services with standard processes and end to measures of customer value to meet those needs. Anything that doesn’t add value to users can be taken out of the process.

Unfortunately many traditional IT Departments apply Lean Principles in a way that cuts IT costs locally at the expense of customer value. For example it’s common for Contract Managers to outsource IT services on a long term contract to the IT provider that promises to meet service level agreements (not user needs) for IT transactions (not end to end services) at the lowest cost (not highest value). To minimize their costs commodity service providers typically apply strict operating procedures that push as much responsibility for the work as possible onto users and other teams. Then they reduce labor costs as much as possible by reducing the team size and skill and sending the work offshore until they just barely meet the minimum transaction requirements. In these arrangements it’s common for new employees to find that they can’t get a PC or login until weeks after they’ve started and for it to take 12 weeks to get a firewall rule changed and 12 months to get new servers in production. This approach is not recommended because it substantially reduces the value of IT to the organization.

The next article will discuss how to reduce inventory waste in IT.