Signs you are in a useless meeting

When I was fresh in the work scene, I used to secretly admire my boss who seemed to always come from a meeting.

While we were holed up in our workstations, he would come back with interesting stories about the client or happenings from the powers that be in the organization.

If you google terms related to success, you can be sure one of them will involve a well-furnished boardroom. The boardroom is associated with power.

What I didn’t know then was my adorations were misplaced. As a matter of fact, my boss was doing me a favour by actively excluding me from these meetings. You see since then, I have had my fair time in the boardrooms. What I have come to find out is most meetings are simply a waste of time.

My brother has a saying:

If we are going to waste time, at least lets waste it doing something fun

In this entry, we are going to be looking at some of the signs you are currently trapped in a useless meeting.

What is the purpose of this meeting?

Should be obvious right? Wrong!

Never assume the purpose of the meeting is obvious. The purpose should be stated explicitly both in the invitation and when the meeting starts. This helps focus the participants and get the most value for the allocated time.

If you are the sponsor of the meeting or a participant and you can’t articulate a purpose, there is a good chance no such purpose exists.

You see in a meeting you are either:

  1. Giving an update on an ongoing project
  2. Planning for an upcoming project
  3. Working together on an existing project
  4. Reflecting on a complete project

If this meeting doesn’t fall in any of this buckets, you are likely stuck in a useless meeting.

How many topics are up for discussion?

If you walk into a meeting and realize there is no agenda, excuse yourself and find something better to do with your time.

A good agenda acts as a guardrail for the team. It empowers each participant to know when the meeting has gone awry.

Assuming the sponsor has the discipline to keep the meeting within the bounds of the agenda, it is just as important to ensure the agenda items are few and focused. More specifically, each item on the agenda should be seen to serve the purpose of the meeting.

For example, an update meeting agenda should look something like this:

  1. What have you managed to achieve since last time we met?
  2. What are your blockers?
  3. What are your plans?

Not this:

  1. What are your achievements?
  2. Discuss on possibility of building an XML parser
  3. Review of intern applications

Who benefits from the meeting?

In physics, we learn, no matter how long you push on a wall, if it hasn’t moved, then no work has been done. In the same way, no matter how lively the discussion is, if people go back to their desks the same way they got out of them, then no work has been done.

The meeting sponsor (the person who invited everyone) should clearly benefit from the meeting.

You will be shocked to know how many meetings happened because the Director said it should happen. Even worse, some meetings happen simply out of custom, ie this is how we have always done things!

What are the outcomes?

Meetings are not necessarily gloomy events. Humans are social animals, we are programmed to enjoy the company of others, yes even those pesky coworkers.

Yet meetings must be productive, something must come out of it.

Some examples of meeting outcomes would be:

  1. An action list (who to do what by when)
  2. A decision
  3. A communication plan

This meeting artefacts bear witness to a good meeting.

While some meetings will only produce notes, that is ok as long as it’s understood from the onset this was meant to only be a status update.

How do you protect your team from useless meetings? Talk to me in the comment section below or on my twitter @jchex


What it means to be a leader in a software team

In my career in technology, I have had the chance to serve in several leadership roles, latest being Twiga foods. My first time, I assumed leadership, or as the organization referred to it, management involved defining what was good for the organization, breaking that up to tasks then delegating the tasks to individual developers.

Over time, I have come to realize this model of leadership is seriously flawed, not in the least because developers are very smart people, smarter than I am.

Even more important, by monopolizing the work of visioning, I simultaneously lost out on great ideas from others and demotivated them at the same time!

In this entry, we will be looking at what I see is the role of the leader in a software team.

Custodian of priority

All teams face a bombardment of new information every single day. In this blizzard, its very easy to get lost and like the proverbial hyena get split in half!

Your job is to make sense of this incoming mess of requests, messages and bug reports and in the light of your team goals, give them meaning.

Not all tasks are the same, by giving them context, the team can then decide which tasks will give them the greatest return on their time and energy investment.

This also means you guide them in reviewing old commitments to see if they still make sense.

Trawl for new useful information

Nassim Taleb in his classic book The black swan introduced the concept of the unknown unknowns.

A black swan is an event, positive or negative, that is deemed improbable yet causes massive consequences.

In software, this translates to unplanned work. As mentioned in How you pay for technical debt

Like matter and antimatter, in the presence of unplanned work, all planned work ignites with incandescent fury, incinerating everything around it

As the leader, you need to be constantly monitoring your environment for signs of this black swans. It may come in the form of changing business environment for your clients or even unresolved disputes in choices to be made.

Either way, bring them up to the team for discussion and resolution.

Ensure personal growth

Maybe I have been more lucky than others. All engineers I have worked with have been naturally curious autodidacts. Yet for those new in the field, they may have no idea what they need to know or the experiences they need to have to mature into senior roles.

Your work as a leader then is to appreciate raw talent and provide support for growth.

Peter Senge establishes Personal Mastery as one of the core disciplines. He defines it as:

Personal mastery is the discipline of continually clarifying and deepening our personal vision, of focusing our energies, of developing patience, and of seeing reality objectively.

This is very important to understand and practice yourself while encouraging it for others as well.

You see, the higher the skill level of those around you, the more peace of mind you experience. When you are knee deep in a project this is not the time to start wondering if your colleague will drop the ball.

Provide feedback to the team

All successful systems are so because they have someway of getting and acting on feedback from their environment.

This means even as the team is working on the next iteration, you must be mindful of how the last release is being used. What do the users think of it?

Even here, you must be careful the team does not develop a culture of aloofness and insensitivity to the message coming from the rest of the business.

Through this entire entry, you may have noted the leadership I talk about does not need any official designation to execute, yet it will provide a lot of value to your team.

How have you provided leadership to your team today? Talk to me in the comment section below or on my twitter @jchex


Why we do internal demos mid sprint


At Twiga, we have regular demos of features in progress, most times way before the feature is expected to be finished. Now, these events are not for the weak, a fair number of times the flow being demonstrated simply tanks with a 500 error or worse.

Even if it doesn’t and you go through the happy case, everyone else in the team digs into what you have presented looking for edge cases, bugs and any other opportunities for improvement.

It is not a Kumbaya event yet I feel these sessions have helped us improve our products while cutting down on development time.

In this entry, we will be looking at why you may want to hold such critical sessions within your own teams.

Change is hard when the product is deemed complete

Typically, at the end of the sprint, what is delivered is a coded, tested and usable piece of software. Let’s use a simple project to illustrate this effect.

Imagine if you set out to clean your house, you decided you will fully clean out each room before moving to the next one. However, it’s your wife who gets to judge if the room is truly clean. After you have finished cleaning up the study and your brain is flooded with dopamine, would this be the opportune time for her to come point out all the spots you missed?

Will you be able to continue cleaning out say the kitchen while at the same time working on the spots missed in the study?

In this case, just like in software, it’s much better to have spots pointed out while you are in action rather than when you are done.

Mistakes don’t compound

Early on in one of our time-sensitive projects, we decided to switch the language used from Java to Go. Our senior team was working on this project so this switch was not anticipated to be much of a problem.

By the first demo, we noticed things were going horribly wrong, whilst the team was learning, our existing Java libraries did not play as well as anticipated with Go.

Given the sensitivity to the deadline, we decided to revert back to Java and implement a less time-sensitive project on Go.

If we didn’t have this chance to reevaluate our decisions, we probably would have missed the deadline and worse, so much work would have been done on Go we would have no other option but to commit finishing the feature using it.

Decisions are more inclusive

Over the course of development, developers make hundreds if not thousands of decisions. This is ok, after all, that is why we hire people smarter than us. The challenge is by the end of the sprint, the decision is embedded so deep in the product, it’s hard to know there was a decision made at all.

An example would be the choice of which cache provider to use, typically this decision will be made by the developer. It is possible that someone else in another team has experience with the same service and knows it doesn’t work as well with our architecture in certain use cases.

By getting this feedback early on, course-correction is possible and everyone learns something.

In conclusion, these sessions should be safe spaces. As much as possible avoid involving the client or senior management who demand perfection. To understand why. Take a tour of a garage and see what a vehicle looks while it’s being painted. Unless you are in the profession yourself, all you will see is ugliness, only other developers will be able to capture the vision being presented and provide useful feedback.

Do you hold internal demos in your own organization?  Talk to me in the comment section below or on my twitter @jchex