Design a site like this with
Get started

Frequent management interruptions for developers – A big lean waste in software development

Why do developers disdain to go to regular meetings? Besides, Why managers consistently call for such a variety of meetings everyday?

As a developer, we understand, how tormenting it is to pick your notebooks and go to the conference room for an extensive management meeting amid an occupied busy day.  Particularly when you are profoundly involved in brain-teaser design and development work and desperately need solitary confinement to squeeze your brain cells to get the technical problem solved.

As a manager, we always believe that developing communication structure within and between teams for tenacious, persistent, continuous communication is of significant importance for developing an incredible product. If you are an ‘Agilist‘, you are committed to required daily stand-up meetings, iteration planning meetings, iteration review meetings,  user story pruning meetings, iteration and milestone retrospection meetings. These meetings are important to close the feedback loop between teams, within teams and for an individual developer at different phases of product development. These feedback loops enable and empower continuous improvements in an iterative and incremental development environment. Agile needs regular feedback loops to drive the time-boxed iterations, get the team in a shared mindset and align product development activities with the product plans and milestones.

In a 2 week iteration, if a developer dedicate 15 minute per day on a daily stand-up meeting, 4 hrs for iteration planning meeting, 4 hrs for iteration review and retrospection, 2 hrs for product backlog pruning, It is 15.6 % of the total time(80 hrs) an individual developer has in a 2 week iteration. Investing 15% of you time in an iteration on effective meetings which enable development activities is not that awful for developers. The problem comes, when developers are frequently interrupted in their core hours, during the time when they are deeply engaged in design and development activity. This interruption can be in  the form of unplanned meetings, interviews, cross-cubical talks, manager’s room chit-chat,  unnecessary on demand sink-ups, management updates, group task reviews, and so on..

Development,  particularly coding is a complex activity. It requires collective, cognitive alignment of numerous elements – mental models of problem definition and the environment, understanding of  requirements and acceptance criteria, conceptualized solution options, approaches, design decisions, risks, assumptions, constraints, experiences, influence, understanding of the evolution and emergence of code and design etc. It is a challenge to bring all these elements in-resonance to discover and code the ideal solution. Interruptions, derails the cognitive processing. Interferences, crashes the cognitive transformation of ideas to working code. It makes developer mind to do a context -switch from one problem to another. Problems which are different. Problems which requires different cadence and mindset. When developer returns to development activity, it require them to re-build the mental structure and state. It can be like starting again.

Now, if you are repetitively doing the same kind development activity for a long time and your mind is hard-wired to repeat, you wont’ psyche getting intruded on, and  your manager will love you for being so effectively accessible to him for on-demand dialogs. But, development brings new insight and learning every time you code. Each coding circumstance is different. You have to be alert, investigating, exploring to get the right code artifacts. Yes, even when you are using Google to cut and paste, your mind need to be active to learn and adapt it to your problem needs.

I ponder, why managers require these frequent sink-up meetings with team members. Particularly, if you are doing agile and committed to iteration deliverables. Why do they need to chit-chat regularly with the developers and discuss what you are doing now. Can’t managers join the daily stand-ups and get the status? Don’t manager trust the team’s sprint commitments, skills, knowledge, ability and capacity to deliver on planned work. Particularly, when they are themselves involved in building the team. Shouldn’t the manager spent more time facilitating the iteration review, iteration planning, retrospection meetings, and work on cross-teams communications, competency and skills development, individual’s objective alignment achieve bigger and broader goals?

The bigger question is – What do managers do in agile development?
This is not the topic of this article. I will answer it in another post.

Management and development work require different cadence to achieve its goal. When you are on developer cadence – designing and coding; the daily cadence cycle is longer. I see, 2-5 average non-stop hours required to achieve development tasks. Interruptions during these development core hours break the rhythm of a developer. This context switching can make developers loose the thread and  blow away the entire day for them.

Developer’s and Manager’s work cadence

When your in Test-Driven-Development mode, a management call to discuss status updates can get us out of the context instantly. Here, we just composed a test to express what we intend to code, Interrupted!  we lose the rhythm, the context and the mental-model of it. It takes time to re-build context, to go through the code again, and understand what we were thinking when we actually coded those tests. Everything requires significant re-investment of time and effort- A rework, a big waste. Not to mention the frustration it brings with it.

If you are working on management tasks, cadence cycle is shorter. Managers can switch between tasks within minutes, multi-tasking is accepted and recognized way of doing day to day management work. Management tasks – email updates, co-ordination meetings, status updates, risk assessment and mitigation planning, work facilitation, task planning, resource and capacity assessment etc. all can be composed in of shorter time activities.

Managers need involvement  and participation of development team members to accomplish their work. Since, in most of the projects, managers are in more authoritative and legitimate positions, their call for unplanned short gatherings tend to drastically affect the developer’s development activity.
Manager’s  tend to disrupt  and upset the development activities several times a day. They are unknown of the fact that this regular interruption is causing a context-switch for developers which takes time to reconcile and is prone to loss of information, ideas, approach, problem modeling and solutions. It will reduce the quality of output, lower the productivity, increase re-work, affect the developer’s motivation and commitment and leave them exhausted.

Have you observed the complex behavior of a swarm of ants who have discovered a food source? Disrupt it! What amount of time it takes for the ants to return to the same behavior?

What can be done to bring these two required but distinct behaviors(Managers and Developers) in collective-cadence to achieve the desired shared behavior?

Give some attention to these important points:

  1. Managers should understand and recognize that there are two distinctive types of task schedules in the software development teams  – management tasks and development tasks schedules(which require involved coding and testing).
  2.  Everyone should understand the effect and waste caused by context-switching of development activities.
  3. Managers should learn to avoid frequent interruptions and allocate time for co-ordinated tasks which require involvement of development team members. Like, fixing the meeting timings in the afternoons or sending the meeting request, instead of an on-demand interruption.
  4. Managers should avoid the habit of frequently dropping by the developer’s desk or making calls for on-demand meet-up. Instead, keep a list of required communication and interruption logs and allocate time to do it when the developers are relatively free. Have empathy for developers schedule.
  5. The impact and intensity of waste due to context switching will depend on the type of development(especially coding) work. The more involved and collaborative a development task is, the more will be the waste in context switching.
  6. Developers need to understand the importance of accomplishing the management tasks for the project, and dispense time for it as a team in coordination with managers.
  7.  If the developer feels that interruption and context switching is going to create waste, he should inform the managers and appeal for alternative time to meet. Yes, I understand, many managers will get offended if you request for a change in meeting schedule. They always want it now!  I ask to these managers, isn’t ensuring high productivity, quality and facilitation of uninterrupted development activities your primary goal on the job?
  8. Are you an involved manager? Do you understand and have feel for complex coding exercises? Or Do you think, coding is like any other monotonous task which developer can perform without much attention? Because if you do, then believe me, you are soon going to get the team down. Good developers will leave you to work with better managers.
  9. Listen to your developers, and develop a working schedule for shared activities.
  10. Developer needs to structure their day. Know your schedule, what development tasks you need to accomplish, there complexity and communicate the same to managers.
  11. If developers can’t avoid some interruptions, it is recommended to record their last thoughts before joining the meetings. It will help in resuming the task again.
  12.  Developers can move to meeting rooms when they are working on complex, involved activities which require uninterrupted focus.

Confusion of Employee Performance Appraisal in Agile

Financial year end is near. Your organization has kicked off the yearly employee performance appraisal process. As a manager, what is your situation?
Mr. Sundaram is a confused manager today. He has been working for a Bangalore based software development company called SinsforSystems for last 8 years. He has been asked to provide performance stack-ranking (5, 4..1) for all his reporters, across all grades (E1, E2, .. E5), normalized across 3 teams he is heading, with entire data fitting the Gaussian distribution (The Bell Curve) across all dimensions.
Now, employee performance appraisal is the yearly process in SinsforSystems and Mr. Sundaram has been the champion who has mastered the art of ethical-performance-rating. People have never challenged his judgment and evaluation acumen. He has been transparent and objective in his employee performance ratings. His appraisal practices religiously embraced MBO(Management by Objectives). He is a smart technical manager who sets yearly goals and objectives for each of his subordinates at the start of the financial year and evaluates them sincerely and perfectly at the year end. No exception catching required.  20% of people reporting to him are always top performers, 20% always bottom performers and rest are ‘good performers’.  He is known for successfully giving constructive feedback and setting right directions and goals for those rated as ‘good performers’ to get them into the ranks of ‘top performers’ during next appraisal cycle. Interestingly, during every yearly employee appraisal, he still manages to get his 20% top and 20% bottom ranked employees.  The genius he is, it takes him just 1 hour to complete all the employee ranking papers, without missing the Big boss episode. He has always been an involved manager!

But, this year performance appraisals are a lot different. SinsforSystems has ventured into an agile transition program and Mr. Sundaram has been lately baptized with holy agile water.  He has attended few agile courses, conferences and organized classes. He has been actively engaged in agile ceremonies – Sprint planning, reviews, retrospection, daily scrums. He has been through lessons on self-organization and autonomous team building. He has done some self-reflection on his role in agile teams and worked with agile coaches in team building and agile roles fitment exercises.  

He is not sure if the existing techniques of rating and ranking the team members performance in isolation are going to work this time. He has seen a lot of team member’s involvement, communication has improved, team members are more aware of what is happening in the team, they know who is contributing on what,  and how much. This scrum implementation has bought some noticeable awareness on team visibility, contributions and effective deliverables. Yearly individual objectives and goals they have set do not make sense to him in agile context. E.g. one of the architect’s in the team has a goal of “Creating high quality complete design before development”.  Team is now forced to work on more iterative design and development within the sprint. His goal is somewhat redundant.  Similarly, what is tracked now is sprint deliverables not individual deliverables. He can only give limited credits to those high-profile-experts in the team, who in the past, were recognized for quick completion of tasks irrespective of whether anything makes into the sprint’s potentially deliverable completion list or not. He sees the importance of measuring knowledge building and sharing, mutual trust and team work, re-work, continuous improvement through retrospection, code quality, adherence to agile principles, practices and disciplines, but he does not know how he can change these yearly performance goals for every individual to reflect these much required changes. Does he really need these individual goals now or does he need few team goals in addition?  How will he measure them? Does he a need 360 degree feedback from team?

Mr. Sundaram is sure it’s a different appraisal this year. But, he cannot do much. Human resource department has never been part of the organization agile initiative. They do not know how agile initiatives impact employee’s yearly appraisals, they never planned or modeled for it.

What will Sundaram do?

Stop Micromanagement Epidemic – Lessons for Micromanagers

Micromanagement has severely impacted people and teams in the organizations. 
It’s the most ubiquitously prevailing management sickness in the organization. Micromanaged environment kills creativity and productivity, bringing down the organization capabilities to produce quality products. If your team is on the agile journey, it’s important for managers to be aware of the micromanagement activities. It’s not easy for managers to understand, recognize and take necessary actions to eliminate the micromanagement behavior. It gets into your management style like a virus, severely hurting your subordinates, team, colleagues and yourself. It is important, we identify micromanagement activities in the organization and plan for it’s remedial.

I have been compiling some thoughts on micromanagement for a while. It turned out to be a long article at the end.

I have divided this article into following sections:
1.    What is micromanagement?
2.    People and organization impacts of micromanagement: Big cost to the company.
3.    What do micromanagers do?
4.    How micromanagers justify their act?
5.    Why we do micromanagement?
6.    Why we let go micromanagement?
7.    How micromanagement affects micromanaged victim?
8.    Micromanagement cycle – The micromanagement trap
9.    What can organizations do about micromanagement?
10.What can you do if you are micromanaged?
11.What can you do if you are a micromanager?
12.Micromanagement vs. Effective Management

What is micromanagement?

Micromanagement is about “Excessive involvement by a manager with an employee in regards to his performance. In short, it is imposing work standards and behavior expectations that meet the personal needs of the manager, not the employee, or the organization. It is to control a person or a situation by paying extreme attention to small details“. Courtesy – Jim Rooney “From micromanagement to mentoring

Micromanagement is the inability to trust or relinquish control to others and is a manifestation of fear and insecurity. In micromanagement, the manager not only tells a subordinate what to do, but also dictates that the job be done a certain way, regardless of whether that way is the most effective or efficient one. Manager will engage in behavior that may be in-protective of their division’s interests, or their personal interests, but harms the organization as a whole.

People and organization impacts of micromanagement: Big cost to the company

1.    Poor quality of deliverable from team: This is a vicious circle, which leads to more micromanagement from micromanager to get more control.

2.    Low team morale: Individual heads are down due to daily fire-fighting. Team morale suffers as people are not engaged and feel low esteem.

3.    Impacts on other teams and employees: There are grape wine and dis-engagements talks all around. Other team members will avoid helping or joining micromanaged teams. It also leads to conflicts between individuals and teams.

4.    Absenteeism from work: Who would like to face a micromanaging boss every morning?

5.    Feeling of dis-empowerment: You are a puppet executing on the boss’s daily agenda. Are you building something significant or blindly executing on orders?

6.    Low confidence: People operate at low confidence due to fear of failure and resulting humiliation.

7.    Suppression of innovation and loss of creativity: Innovation thrives on conducive and creative environment. Micromanagement kills it!

8.    High employee attrition: Knowledge that goes straight to competitor. Remember, people leave their managers more often their companies.

9.    Loss of productivity:People who are micromanaged lose interest. It affects their productivity and effectiveness. Will you contribute if you know that the credit of your hard work goes to someone else?

10.  Loss of corporate knowledge: Organization knowledge system weakens with people leaving the company.

11.  Project failures:  High cost, delayed deliveries, poor quality and low productivity leads to project failures.

12.  Loss of trust between organization and employees: Here is this manager making your life hell every day. What is the organization leadership doing? Will you trust the organization supporting micromanagers?

13.  Delayed decision making: All approvals go through the micromanager. It is he who makes all decisions. You are supposed to wait for that trickle of important decisions flowing from micromanager’s office, blocking everything.

14.  Restricted information flow:  Communication structure and flows are important for team and organization decision making. Filtered and tempered information leads to delayed and ineffective decision making.

15.  Walls of functional silos: Departments, functions and groups lead by micromanager’s work in isolation; embracing ‘throw over the wall’ practices.

16.  Goals and objectives are forgotten: Individual goals are not aligned with team, function or organization goals. Satisfying the micromanager becomes the only primary goal for subordinates.

17.  It grows as an organization style: Virus!  – Micromanagers breed more micromanagers. You want to pass on your pains to others. 

What do micromanagers do?

Following are common acts of a micromanager:

1.    They exercise raw positional power, and use their positional authority to assert things.

     What subordinates hear from micromanager?

         “I am the manager here”
         “This is ‘My team’.
         “I will monitor”.
         “You report to me”
         “I will tell you how to do it”
         “I want this  …  by this date… “
         “I made it clear to you…”
         “Why it was not done the way I dictated”

2.    They dictate time for tasks to subordinates. They don’t trust people to assess their own work; so they impose priorities and timelines which no one understands.

                What subordinates hear from micromanager?

         ‘I want it by end of day today’
         ‘Work for 50% of your time on this today’
         ‘Give me the estimates now…’
         ‘I can finish it in few minutes. Why you want this much time…’
         ‘I do not see any progress today(even in last few hours)’
         ‘I have committed end of day Friday for delivery’. So do it!

3.    They control how work gets done.Work always needs to be done the way micromanager wants it. They do not care to develop standard practices and processes.

4.    They run their own system of processes and practices, completely misaligned with the project, functional and organizational practices. They call it ‘their long experience of doing right things in right way’.

5.    They always focus on ‘How to do a task?’ instead of ‘What to do in a task?’ They dictate the steps of the task rather than the form of the results.

6.    They require undue approvals. They allow no one to move forward without their approval even on routine or time-sensitive matters. Everything needs their approval.

7.    They ask for excessive status updates. They demand frequent, unnecessary reports. They require reports that focus on task activities over outcomes.

8.    They resist delegating,or delegate small un-important tasks or take back delegated tasks and re-assign often. Instead of letting subordinates solve problems and challenges at hand, some managers return those tasks to their own domain to exercise dominance. This brings discouragement to team members working on the tasks.

9.    Delegation without authority:If they delegate they watch every details- suffocating the team. Delegation without authority and accountability is a ‘Dirty delegation’.

10.  They create dis-empowered team. They do not encourage empowerment of team members, which means lack of control to them.

11.  They control information. They filter information for personal benefits from their subordinates or their bosses. They temper with organization communication structure and provide limited information for decision making

12.  They are always found around subordinate’s desk monitoring over the neck.

13.  Unwanted status checks:They drop unwanted emails to check progress. Example: Those, after lunch status check emails in your inbox.

14.  They discourage others from making decisionswithout consulting them. They get irritated when subordinate makes decisions.

15.  They blame others for failures. Their defensive routines are always at work. They take credit for positive results and shift the blame for negative results to their subordinates. The regularly criticize their subordinates.

16.  They create their own performance measuresfor project, tasks and individuals. These measures are not aligned to functional goals, objectives and responsibilities of subordinates. They surprise you with their measures.

17.  There is no transparency in how tasks are done and measured in micromanaged environment. Thriving in chaos protects their personal agenda.

18.  They assign tasks not responsibilities. 

How micromanagers justify their act?

Micromanager is blind to his micromanaging behavior, so he justifies whatever he does in his own way, re-enforcing his own improper behavior.

1.    They call it ‘Attention to details’.

2.    They say they are ‘Involved and hands-on managers’.

3.    They claim it as ‘Positive aggressive attitude’.

4.    They say, ‘they get results by micromanaging’.

5.    They interpret the result of micromanagement experimentation as proof that, without his constant intervention, his people will flounder or fail.

6.    They glorify short term results. ‘I made it working otherwise…’

7.    They say they are fixing inefficiencies of the system quickly and firmly.

8.    They say they are “structured”, “organized”, and “perfectionists”.

9.    They educate their subordinates to adopt their style and practices. 

10. They say they are recognized for their efforts.

Why we do micromanagement?

1.    Personal traits

·         Control-obsessed: Controlling subordinate behavior gives sadistic satisfaction.
·         Personality of manager
§  Shaped by her own experience with micromanagement from his mentor.
§  Obsessive–compulsive personality disorder.
§  Supreme leader disorder – self-proclaimed supreme team leaders experience extremely low self esteem, ever worsening inferiority complex, and zero respect for their teams.
         Inability to trust others.
         Emotional insecurity.
         Feeling of control and superiority: Hierarchical organizational systems, and power allocation with position, leads to the feeling of superiority for micromanagers.
         Tendency to create aggressive individual image for themselves in the organization.

2.    Lack of knowledge and skills

         Lack of competency and creative capabilities.
         Limited skills.
         Limited training.
         Lack of knowledge on organization and team’s behaviour.

3.    Organization culture and management

·         Organization culture: If the organization has a culture of micromanagement, it infects at all levels. It comes straight from top.
·         Style of management of senior, influential people impacts other management level.
·         Instability of managerial position. If the position or job is at risk, people tend to do micromanagement.
·         Peer competition can lead to getting into lot of task and project details leading to micromanagement.
·         Promotion and rewards based on experience rather than skills can lead to micromanagement. Experience people focus on exercising more control rather than building knowledge and learning.
·         Business and work environment
§  Misfit for the job – If the manager is not good fit for the assigned job and he cannot meet the demand of the situation, he will tend to control all tasks and work assignment to get visibility and control.
§  Time or performance pressure without right skills can lead to micromanagement.
·         Unplanned project schedules can also lead to micromanagement. Micromanager may not know the current capacities and capabilities of the team
·         Lack of capacity in teams results in more involvement of managers on tasks which can lead to more scrutinized work.
·         Skills of subordinates also lead to micromanagement by manager.
·         Lack of tools. If the team do not have right tools they tend to spend time doing repetitive tasks. Long delayed task get more attention.

Why we let go micromanagement?

1.    We are afraid of becoming the next target. Fear of job and insecurity leads to our submission to micromanagement.

2.    Conflict avoidance: We are all basically afraid of conflict, we’re endowed with a fight or flight response, and we just want it to go away. No one wants to get into the mess, so we avoid it.

3.    Lack of skills and knowledge to do better job. If people have limited skills to do their job, they avoid getting pointed out for productivity and effectiveness concerns.

4.    No access to higher management to discuss issues and concerns. If there are no channels to discuss the micromanagement issues at higher levels, people suffer.

5.    Selfish interest also leads you accepting micromanagement activities. May be you are due for promotion or rewards and you think it’s better to let the situation go as-it-is, rather than raising concerns.

6.    Lack of trust in organization capabilities to change things. If you believe that organization leaders will not act, you will not bring the concerns to their notice. 

How micromanagement affects micromanaged victim?

1.    People are publicly humiliated.

2.    The victim is shunned and punished for speaking out, and often ends up being forced out.

3.    People lose focus on work.

4.    They become disengaged.

5.    They lose confidence to execute work independently.

6.    Their performance and productivity suffers.

7.    They get frustrated with day to day micromanagement pains.

8.    They tend to get timid and tentative.

9.    They avoid taking responsibilities.

10.  They avoid making decisions and leave to micromanaging boss to decide for them.

11.  Their professional progress stops. 

Micromanagement cycle – The micromanagement trap

Micromanagers follow a pattern while exercising their micromanagement wills.

1.    Micromanagers target people mostly one at a time.

2.    They victimize them regularly.

3.    They force them out of the team and organization.

4.    Victims are replaced by incompetent people so micromanagers can exercise more control with no resistance.

5.    Micromanagement cycle continues.

6.    Micromanagers grow; Organizations suffer. 

What can organizations do about micromanagement?

1.    Identifying and recognize micromanagement in the organization.

         Spot it!
         Check for complaints. Encourage people to report micromanagement.
         Look for teams with high attrition, and low productivity; a micromanager might be at work.
         Study how teams work together; conduct a survey of their job satisfaction and begin tracking their productivity.
         Look on long term measures rather than short term results. Example: if the product releases are happening on time but leads to lot of technical debt, people are not involved or committed to quality and continuous improvements.

2.    To address the micromanagement issue, be decisive, and lay out a clear plan-of-action for micromanager with consequences for not following through.

3.    Once recognized, intervene, and act as early as possible (no matter how uncomfortable it is).

4.    Limit the authority of the micromanagers to reduce the micromanagement impacts.

5.    Institute a mentoring and leadership program that can re-align micromanagers with your organization’s values.

6.    Hire right competent people – people who can solve problems, not micromanage them.

7.    Institute right values and principles and continuously spend time in improving company culture. Lean and agile principles adoption can help in controlling micromanagement.

8.    Drive out fear. Encourage an open door policy which will enable your employees to work and communicate openly without fear of repercussions, and more importantly, leave no room for manipulations.

9.    Establish chain of responsibilities across the value chain. Ensure that the tasks is considered done when the next person in chain is able to consume the deliverables. This will lead to end to end responsibilities requiring inter-team communications and collaboration and less chances for micromanagement.

10.  Grow communication structure and channels for transparent and open communications in the organization.

11.  Encourage teams for self-organization with managers as mentors and coaches.

12.  Get help from external coaches and mentors to help the teams and micromanagers.

13.  Rotate work and team members.

What can you do if you are micromanaged?

1.    Find a new Job. Is it the only solution?

2.    Help your boss to delegate to you more effectively by prompting him to give you all the information you will need up front, and to set interim review points along the way.

3.    Volunteer to take on work or projects that you’re confident you’ll be good at. This will start to increase micromanager’s confidence in you.

4.    Make sure that you communicate progress to your boss regularly, to discourage him from seeking information just because he hasn’t had any for a while.

5.    Concentrate on helping your boss to change his one micromanagement habit at a time.

6.    Understand your manager’s role, responsibilities and information needs. Help him meet his goals.

7.    Develop skills and collect data to plan project schedules and project deliverables with higher confidence level. Avoid estimating tasks where there is no data or experience.                                                                    

8.    Forward books, articles, links to blogs on leadership and team management and other stuff to your boss.

9.    Don’t let your supreme team leaders get on your nerves. Don’t let them catch you off guard.

10.  Document everything!

11.  Exercise patience and resolution to change and improve.

12.  Identify other communication channels to talk and seek help on micromanagement. Don’t let it go.

13.  Work with your peers and create constructive plan to reduce micromanagement from your boss. 

       14. Empathize with you micromanager boss. Understand his job and offer help proactively.
       15. Identify patterns pointing to situations when the micromangement behavior activates. 
             Solve the problems in advance and help him.
        16. Earn respect and confidence and then communicate about the micromanagemnt aspects to him.

What can you do if you are a micromanager?

1.    Realization and recognition of micromanagement: Realize and recognize that your controlling-ways will probably hinder your own career. This is the first step to bring required changes for your micromanagement style.

2.    Realize that you are a micromanager and your style is affecting individual, teams and the organization.

3.    Understand the difference between involved-manager and a micromanager. Just because you are seeking fine details about tasks from the individuals does not mean you are ‘involved’. Involved-managers enable problem solving with just enough control. They are facilitators not dictators or directors.

4.    Do not ask for excessive status updates. While knowing the status of project and tasks is important, asking for constant updates on work status can limit productivity. Updates that are too frequent leave less time for true progress. Instead of over-managing each task of the project or assignment, it’s important to let employees spend time developing their own ideas and knowledge.

5.    Taking back delegated tasks after you’ve assigned it to team or individuals, or going back on your word can be a sign that you’re a micromanager. Let subordinates solve problems and challenges at hand; help them by providing support for problem solving. Do not move tasks back to you (without real reasons) after assignment.

6.    Forget that you can always do all tasks more quickly and in a better way yourself. Committed, skilled teams always deliver more than the individuals. Work on building team capabilities and competencies, and do value adding contributions to the work individual and teams are doing.

7.    Work hard on delegation skills. Delegate, and hold people accountable. Delegation without accountability is ‘dirty delegation’

8.    Enable individuals to make their own informed and evaluated decisions. Requiring others to ask your permission to perform tasks under their control is a way to inhibit progress. While being consulted on tasks is normal, do not make it mandatory to seek your approval on all tasks even when they are in employee’s realm of responsibilities. This controlling behaviour strips subordinates of decision-making power, even when the decisions made are within the sphere of the subordinate’s responsibility or authority.

9.    Never filter or control information. Enable free and transparent information flow by building right communication structure. Do not get involved in filtering or tampering information channels. Encourage information flow to subordinates – Keep them informed.

10.  Do not send unwanted emails seeking unnecessary status on tasks.

11.  Talk to your teamregularly on your management style. Get their feedback.

12.  Build relationship with subordinates. Good work relationship will build trust and reduce micromanagement.

13.  If you are not confident of the subordinates capabilities to deliver, focus on the ones with the most potential, and learn to delegate effectively to them.

14.  Encourage ownership by subordinates.

15.  Trust your team to develop and deliver.

16.  See long term benefits – The big picture. Do not exercise control to seek short term benefits. Spent time in building teams and capabilities.

17.  If you have identified your acts which might have caused problems to subordinates, apologize and change.

18.  Know when you need to get involved and when to get out of the way.

19.  Clarify the outcomes of the tasks to subordinates. Manage the outcomes not the process.

20.  Set the clear communication plan.

21.  Master the art of questioning and listening– Ask, not tell people.

22.  Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.

Micromanagement vs. Effective Management

Click to view ‘Dave Crenshaw’ talk on differences between effective management and micromanagement.

Here is table differentiating a micromanager from an Effective-manager based on the above presentation
They are like less effective ‘activity directors’.
They are ‘effective leaders’.
They focus on how things are done and want the prescribed way to be followed.
They focus on results. They discuss the end results, constraints, issues, expectations, paths and then they give people flexibility to think and create.
They tell people ‘what to do’.
They tell people ‘why we are doing something’. They explain and discuss the reasons behind the task at hand.
They want everything now. They want to get all things done within the determined timelines. Often defined by them without much consideration of existing constraints.
They focus on ‘when’. They work with their team to define the timelines.
They want compliance against the policy, inflexible practices and procedures.
They focus on growth and continuous improvements.
They look their team members as subordinates.
They work in teams.
They are always hovering around their subordinates for status.
They hold people accountable and allow them the freedom to do what they think is correct.

Swarm Intelligence –Can agile teams learn some principles of self-organization from Swarm intelligence?

Swarm intelligenceis the collective behavior of decentralized, self-organized systems, natural or artificial. Swarm intelligent systems are typically made up of a population of simple agents interacting locally with one another and with their environment. The individuals have to follow very simple rules in decentralized control environment. They have to take local actions to optimize the value of their interactions with the environment and other individuals.  This will lead to emergence of “intelligent” global behavior.
Examples: ant colonies, bird flocking, animal herding, bacterial growth, and fish schooling.
Article on Swarm intelligence By Peter Miller in National geographic magazine –
Self-organization:  (Wikipedia definition )is the process where a structure or patternappears in a system without a central authority or external element imposing it through planning. This globally coherent pattern appears from the local interaction of the elements that make up the system, thus the organization is achieved in a way that is parallel (the entire elements act at the same time) and distributed (no element is a central coordinator).
 Understanding software development is complexity science problem. Complex behavior of agile team is difficult to understand. Agile software development teams can learn from understanding collective intelligence in nature.  Very complex behaviors can be coordinated by relatively simple interactions enabling emergent behaviors which cannot be created by individuals.
So can we develop swarm intelligence in agile teams?  Yes, we can but one important difference we have is that development teams are composed of knowledge workers not dumb ants and bees.  Knowledge workers can see the whole and relate how their individual actions can create something bigger than sum of their individual efforts (Systems thinking). Swarm intelligence as theory still applies but in a different way. Self-organized agile team requires a context, a goal and carefully crafted constraints to align purpose and efforts in right direction. 
Study of Swarm intelligence and theory of Self-organization in agile teams can help agile leaders in better understanding of agile principles and practices.

Change in leadership style for leading 21st century knowledge workers

Today’s Software professional are smart individuals. They have different expectations and aspirations from the workplace.  People management practices need a change. What are the change required in leadership and management style and why? Excellent post from Martin Proulx is here

Still Managing like it’s  1992 ? Good luck with the Millennial s!

Power of Good Management – Two blog articles from Joel Spolsky

 Joel Spolsky  (Joel on Software)shares his experience on management styles which discourage innovation and creativity in an organization through command and control(Hit and Run) management – Two Stories by Joel Spolsky

Another interesting read on Command  and Control styles is the following article from him
Command and Conquer and the Herd of Coconuts  by Joel Spolsky

A lesson for all Manager who hide their inefficiencies to manage effectively by acting in Command and Conquer mode. These managers bring down the creativity and innovation in the organization, kill motivation and create an environment of distrust where talented people will  get suffocated. No matter, Product and People will suffer.

Deming’s 14 Points

Good description of Dr. Deming’s 14 points for quality and improvement is here.

14 points philosophy from Dr. Deming:

1. Constancy of purpose:
Create constancy of purpose toward continual improvement of product and service, with a plan to become competitive and to stay in business.
2. The new philosophy:
We are in a new economic age, created in Japan. Management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
3. Cease dependence on mass inspection:
Eliminate the dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
4. End lowest tender contracts:
End the practice of awarding business on the basis of price tag along. Instead, minimise total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.
5. Improve every process:
Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
6. Institute training on the job:
Institute modern methods of training on the job.
7. Institute leadership of people:
The aim of management should be to help people to do a better job. Management is in need of overhaul.
8. Drive out fear: (one of the most important for organization)
Drive out fear so that everyone may work effectively for the company.
9. Break down barriers:
Break down barriers between departments. People in research, design, sales, technology and production must work as a team.
10. Eliminate exhortations:
Eliminate the use of slogans and exhortations for the work force asking for zero defects and new levels of productivity.
Eliminate work standards (quotas). Substitute leadership.
Eliminate management by objective. Substitute leadership.
Eliminate management by numbers, numerical goals. Substitute leadership.
11. Eliminate arbitrary numerical targets:
Eliminate work standards that prescribe quotas for the work force and numerical goals for people in management. The responsibility of managment must be changed from sheer numbers to quality.
12. Permit pride of workmanship:
Remove barriers that rob workers and people in management of their right to having pride in their work. This means, for example, abolishment of the annual or merit rating and of management by objective.
13. Encourage education:
Institute a vigorous programme of education and self-improvement.
14. Top management commitment and action:
Put everybody in the company to work to accomplish the transformation. The transformation is everybody’s job.

Management 3.0 – Jurgen Appelo’s fantastic book

I completed reading Jurgen Appelo’s fantastic book on Agile development.

This a good read for all development managers and agile practitioners. Very practical book which teaches models for agile team and organization development. Advice coming straight from someone who has worked in different roles, practiced and experimented with different agile development practices and models. Unlike management guru books, I found this book very practical, straight on the subject and valuable to development managers like me who want to learn more about softer aspects of agile product and team development.
Must read for all managers, leads committed  to improve the Software development practices in their respective organizations.

Jurgen discusses following 6 views.

Six views of the Management 3.0 model:

● Energize People
● Empower Teams
● Align Constraints
● Develop Competence
● Grow Structure
● Improve Everything

Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn)) byJurgen Appelo 

Product Details