What NOT to do when someone pisses you off in a meeting

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Sources of uncertainty in a software project

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to communicate your release plan

A release plan is simply the dates you expect to deliver on major milestones for your project.

The beauty of scrum and its sister methodologies is there isn’t too much ceremony around this information.

Really, once you get past trivial projects, you very quickly realize what is to be built is not very well understood. Any plan you come up with that ignores this fact is guaranteed to become a source of pain in the future.

I see planning as a search for value, if well done, it helps us answer the most important question for any software team. What should we build?

Its a consideration of the features, resources available and important dates. This then illuminates a possible path for development.

I find it ridiculous that some people write a detailed document complete with dates and then think they are done with it all and no further revisions are needed. A release plan should reflect the current context. This means the format you choose should be one that helps you best express your most current thoughts.

In this entry, I will be looking at some of the formats I have found useful for communicating release plans.

Outcome buckets

In a previous entry, I talked about Why I don’t assign deadlines by date

For context here is how tasks bucketed into weeks would look like.

Well, as it turns out, planning your tasks as such is also really good for presentation. You can very easily get a sense of when you expect things to be completed.

Even better, the system communicates a level of uncertainty, because you don’t have an exact date for any of the tasks, you know it can be delivered on any date within the bucket and the plan would still be true.

For highly uncertain outcomes, you can increase the size of an individual bucket, say to 1 month. This communicates to all stakeholders there is much more risk to the outcome but we will get it done early if we can.

Spreadsheets

Maybe it’s my finance background talking, but I must say I love spreadsheets!

I find it to be one of the most powerful tools to establish coherence of thought within whatever your team is working on.

As part of our communication kit, spreadsheets allow us to play around with the quantitative bits of our plan. For example, if we need to model what would happen if a story point takes 5 days to develop as opposed to 3 days, it would be trivial to do so with the tool.

There is a perception in the business world anything on Excel is more serious than on a goofy tool like Trello. The perception is wrong but since its there, why not make use of it?

Gantt charts

A Gantt chart is a staple of the project management industry. They are highly visual and easy to understand. As you can tell from the fact am using a stock image here, I am not the biggest fan of them.

TeamGantt sample
TeamGantt sample

 

The problem I have with Gantt charts is it doesn’t communicate the uncertainty inherent in any software project. Furthermore, when a date changes, you don’t immediately see how such a change escalates across all other tasks and further how the other outcomes are now more likely to take more time.

Not all of it is gloom and doom, because of its visual nature, its far easier for non-techies to grok it over say a spreadsheet.

Furthermore, for a high ceremony executive, a Gantt chat will likely fit better with the rest of the reports they have to go through for the rest of the day.

How do you communicate your own release plans? Talk to me in the comment section below or on my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail