Category: Project Management

Good decisions matter. In fact, it could be argued the primarily KPI for a manager is decision making.

Confronted with a decision, I have seen many professionals give instructions based on the first thing that comes to their mind. As in any other field, some managers are particularly gifted, and this works out, for the rest of us, it makes some sense to have some rules of thumb handy.

In this entry, I will be reflecting on the various actions I have found useful in making effective decisions.

Be Precise

SMART. Specific, Measurable, Attainable, Relevant, Time based.

Surely we all must have heard about this acronym somewhere. As a framework for evaluating goals, its merits are beyond dispute, yet I argue the method can be simplified even further. For decisions only two factors matter.

Measurable and Time-based.

By definition, a decision implies the existence of alternatives. Here, I mean real options. For example, a decision should we or should we not pay our top employees is mute, the alternative is untenable

A good choice gives proper stead to the other options. It explores the possible costs and benefits in ways that can be measured.

Consider the decision such as:

We will introduce game night to boost employee morale

Sounds great right? Now what about:

We will introduce game night, this will cost us Kshs 1M per month. It is expected in the coming year, we will experience a drop in voluntary exits from average of 5 per month as seen last year to 2 per month saving us recruitment and training costs of 3M per month

The decision is not only measurable, but it is also possible to reflect on the decision in a year and see if it was actually the right decision.

Build in a way for the decision to be executed

If you happen to attend a government function, you can expect to hear words such as:

As a government we will work to ensure you have clean water, a hospital here, jobs for every able person and reduce your taxes.

Obviously high aspiration but mostly fluff. No decision has been made here, after all, how will all these goodies be delivered on the back of a government cutting its own funding means?

Any manager worth his salt sees through this hyperbole, the same manager then goes to the office the next day and declares to his team.

This quarter we have adjusted our sprint goal to 60 story points per sprint. I trust in you to deliver this.

If the confused looks from your team were not educative, let me explain what went wrong. The decision made here is merely un-executable. Don’t get me wrong, as a goal, it has some excellent characteristics, it’s definitely measurable and time-bound but how the hell is the team to execute on it?

Perhaps a better way to do this.

Due to company x ( a new threat) entering our industry, a decision has been made to more quickly move along our product plan. Our historical average has been 40pts/sprint but I believe we can get this to 60pts/sprint. To do this, we need higher quality hires, the HR team will be holding a session with us on how we can systemize our hiring process. Further, I believe as surely you must that higher quality code is the basis of faster development due to reduced rework. Thus going forward enforce a strict policy of 100% code coverage on all new code.

Of course, don’t give orders, ensure whatever decision you come up with and its attendant actions have well been negotiated with knowledgeable parties within your team.

Embrace conflict

I work with a great team at Twiga, for the purposes of this example, I will discuss two particular managers within the product team, Evans and Seth.

Seth is extremely precise in his thinking, his attention to detail is something to marvel at. In discussions, he will usually be the first person to notice inconsistencies in what we are working on.

Evans, on the other hand, is unusually perceptive. He is able to synthesize a great number of facts and come up with a simple and clear explanation.

In any working session, there will always be some opposition to my ideas. At first, I merely accepted this, but I have come to embrace it. These two gentlemen have sharpened my thinking, through their eyes, I am now able to see through my own blind spots.

This is not a fringe phenomenon in my own little world or even within Twiga but indeed a general truth. To get the best thinking available, you must submit your ideas to argumentation and be willing to take the best ideas.

Kiss up and kick down is one of the more common phenomena in corporate environments. It makes sense, after all, bosses are able to offer rewards subordinates can’t.

So when you become a manager, you may be surprised to find there exists an entirely different paradigm, kiss down and kick up!

I have had bosses who I have taken to be some kind of demigod. They handled almost everything with grace and poise. To this leaders, I may have at times been aggressive to the point of being disrespectful.

Too commonly lesser managers have reacted in ways which made the situation worse. In this entry, will be discussing some of the things to avoid.

Ridicule the individual who has pissed you off

The need to revenge is deeply embedded within us. The story of Cain and Abel, a story of betrayal and revenge is literally one of the first stories in the bible.

Thus when we feel attacked, we will immediately feel a rush of emotion pushing us to give ’em all we got.

It doesn’t help our homegrown culture of “Mchongwano” has trained us on the art of snark.

Why it doesn’t work

Your reports know more about you than you do about them. If you think about it, there is nothing strange here, as their manager, you hold a dispropriate amount of control on events in their life. Companies depend on managers for reviews which then inform bonuses or even state of employment. To understand your boss is a survival strategy.

This means what you say may be taken personally affecting the person’s view of themselves. Even worse, you close yourself off to future feedback from the person and anyone else who may have been watching.

What to do instead

No one owns your emotional state. If you are angry, no one made you angry, you made yourself angry. Events in the world just are.

As Ryan holiday put it:

The perceiving eye is weak, he wrote; the observing eye is strong. Musashi understood that the observing eye sees simply what is there. The perceiving eye sees more than what is there. The observing eye sees events, clear of distractions, exaggerations, and misperceptions. The perceiving eye sees “insurmountable obstacles” or “major setbacks” or even just “issues.” It brings its own issues to the fight. The former is helpful, the latter is not.

Instead of reacting to whatever the person has said, be curious, try to understand why they said it.

If you are overwhelmed by emotion, take a break, go get a glass of water. Follow up with the offending individual later. This break will help you formulate a more useful response.

Chastise the whole team

Back when I was in primary school, one of our teachers called the entire class into the staff room. This was not a common occurrence. Neither was the big cane she was holding or the space created between the desks.

As it turns out, the class had performed very poorly, it seemed the best performing student had about 10/30. So she decided the best way to remedy it would be to administer the balance of marks to 30 as cane strokes.

This was not a good experience, it did not help later it was discovered she was using the wrong marking scheme.

While as a manager you hopefully don’t resort to physical abuse, verbally abusing the entire team is just as bad.

Why it doesn’t work

As humans, we naturally lean towards our groups for direction. Especially when feeling confused or afraid. When you attack the entire group, you characterize yourself as the enemy.

If you have ever participated in some kind of civil action, you must have experienced how fear of authority vanished under group fever.

Even if the team does not dramatically rise up against you, you will take hits in productivity. For knowledge workers, which all developers are, you need their commitment to your goal.

What to do instead

Take time off to reflect. Was the vision not clear? Was the team not empowered to act on it? Was there a major blocker which I was not aware of?

Call in a retrospective. This is not the time to blame anyone, you need to see what is going on as objectively as possible. Solicit feedback on how you can better define the objectives.

Finally, learn from your mistakes and move on.

Take over and make all the decisions

Winslow Taylor defined scientific management as knowing exactly what you want men to do and then see that they do it in the best and cheapest way.

Unfortunately, software developers and really all knowledge workers don’t take on too well to this paradigm.

If you feel you are dealing with a particularly idiotic individual or even worse team, the temptation may be to simply make all the hard decisions and give direct orders.

Why this doesn’t work

Modern products and companies that make them are complex. So much so that no individual human could ever fully understand the workings of a modern product, say a vehicle.

As Walter Powell put it:

There are a number of jobs that are based, in large measure, on either intellectual capital or craft-based skills, both of which have been honed through years of education, training and experience. Many of these kinds of knowledge-intensive activities, such as cultural production, scientific research, design work, mathematical analysis, computer programming or software development, and some professional services, require little in the way of costly peripheral resources. They are based on knowhow and detailed knowledge of the abilities of others who possess similar or complementary skills. Knowhow typically involves a kind of tacit knowledge that is difficult to codify

No matter how smart you are, the people working on the product will always have more details than you. This is not even a bad thing. It means your team can scale.

What to do instead

Embrace the power of the team, you see if everyone is working towards the same goal, they will make the continuous improvement on various aspects of the product making it better in ways you did not anticipate.

What you need then is come up with some kind of process with incentives which nudge the team towards good decisions.

How do you handle being kicked? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex

Years ago, I discovered the power of process. Through the work of David Allen and his GTD Process by following a simple process I no longer dropped balls in my work.

When I started managing people and projects, I figured if there is a process for managing my life, surely, there must be one for managing teams. As it turns out, there was, scrum is an incredibly powerful technique for enabling teams to self-organize and deliver value.

On this path, I have come to realize the process is not enough. In fact, it seems the question “What is our process” is not as valuable as asking “How are we managing our risk”.

It seems no matter how much you stick to the process, the universe has an unlimited number of curve balls all lined up for you.

In this entry, we will be looking at some of the more common sources of uncertainty in software projects.

System requirements

Time and material model of software development is still dominant. I don’t even blame the industry, after all, once you get high enough in the organization, features against a budget is a first good approximation of the ROI of your dev teams.

The only problem with this view is it ignores the aspect of time.

You see, the more the time, the more the events which imply the business has evolved at a rate dictated by its market and innovation pace. It follows previously valid and useful requirements are no longer aligned with what the business needs.

I have come to find, in real businesses, there are no well-poised problems. What you will have to learn to deal with messes.

How will you cast these problematic situations to problems your dev team can solve?

Available engineers

The advent of coding schools has really helped alleviate the general problem of lack of developers. Unfortunately, they have not done much for the population of senior developers.

It’s very different to build a toy problem that calculates tax to be paid vs building a full-on accounting module taking into account all the nuances of the Kenyan tax code.

Even if you are able to solve the problem of getting experienced engineers in, you now face the secondary problem of ensuring they understand your business.

I have been in two-hour brainstorming sessions to understand how to map common directions parlance to how our business thinks about locations. How do you onboard this knowledge to a new engineer?

What would you do if your longest serving engineer receives an offer from Google?

Organizational politics

Your first true brush with power will be in an organizational setting.

As long as you had sane parents and teachers, probably the worst that could happen to you would be a good spanking, nothing to fret about.

Your boss, on the other hand, has the ability to infringe some major pain in your life.

In this kind of setting power can be used to trump reality with disastrous effects.

HiPPO (highest paid person’s opinion) means the organization may never achieve alignment. How can you build a software product when different stakeholders in the same organization demand mutually exclusive features?

How do you handle uncertainty in your own organization? Talk to me in the comment section below or on my twitter @jchex