In any organization, you will find two types of people, those who work to be part of a mission, and those who work for a paycheck. Ideally, you want to skew your developers towards the former.

This can be challenging owing to the nature of work developers do. You wouldn’t be able to tell if your developer is seriously churning code or trolling people on Reddit. Especially, if you don’t have a technical background yourself.

Thankfully, you can bank on people wanting to be part of something greater than themselves. You can tap into this intrinsic motivation to get great results both for your organization and your team.

In this entry, I will be discussing what I have found to work in my own practice.

Jointly come up with stories

The idea requirements are out there to be gathered is a truly misleading one.

I believe the act of story writing is a creative one. Out there what you will find is a problematic situation, your job with your team is to interpret the situations as problems and come up with stories which can then solve these problems.

By being involved in this initial problem setting, your team is able to see the meaning to the work they do.

As Fred Brooks put it:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures

By allowing the whole team to participate in this process, you get creations which are in line with the complexities of the business.

Regularly reflect on purpose

Having jumped the hurdles of the academic career track, I knew I was lucky to be a tenured professor of philosophy. Yet stepping back from the busyness of life, the rush of things to do, I found myself wondering, what now? I felt a sense of repetition and futility, of projects completed just to be replaced by more. I would finish this article, teach this class, and then I would do it all again. It was not that everything seemed worthless. Even at my lowest ebb, I didn’t feel there was no point in what I was doing. Yet somehow the succession of activities, each one rational in itself, fell short.

You don’t need to be approaching midlife to get this sense, write-commit-push-deploy can feel as grinding.

Your best developers joined your organization for why you do what you do. It is easy to assume this sense will always remain there after all the company has not changed right?

I would posit you need to regularly remind your people why they what they do. At iHub we built communities, it was always satisfying to see the uber successes in the industry trace their roots back to our organization. At Twiga, we are helping bring food security to the country. From this perspective, each commit matters that much more.

Identify and manage freeloaders

I came across this interesting video showing monkeys understand the concept of fairness

Unfortunately, in any team, there will be those who will be looking to do the least amount of work possible. Even if they never mention it, the other teammates notice and I assure you they don’t like it.

Ben Horowitz called it the law of crappy people:

For any title in an organization the talent in that level will eventually converge to the crappiest person with the title. Everyone at the lower level will naturally benchmark themselves against the crappiest person at the next level.

Present growth opportunities

If you did your interviews right, your people are smart motivated and ambitious. The last thing they want to feel is stuck. Paradoxically, your best devs will resist promotion to management. This is no excuse to give up on them. Instead, provide them with opportunities to grow within their interests.

This means actively monitoring what they are working on and scanning for new opportunities to challenge them even more.

How do you grow commitment within your own team? Talk to me in the comment section below or on my twitter @jchex

Ever since I joined Twiga, there has been talk of switching to a microservice architecture. This idea had been baked into the product from the beginning so the switch should not be as hard.

I don’t actively code so there is no technical satisfaction but am still excited about what is coming next.

In this entry, will be talking about what I foresee coming.

The project becomes more expressive

In a previous entry, we delved into what it means to properly name entities in your code.

Having a big vocabulary is useful because we are better able to attend to concepts we have a name for.

By breaking up our system into microservices, we are able to have multiple entities to talk about. For example, it will be possible to have a meeting to discuss authentication and have its code cast in the background that is functionally separate from the rest of the system.

This tallies well with our brain which is wired up for affordance. Briefly described, the theory of affordance states we don’t see things as they are but as what they mean to us. Eg a cup as something to reach towards. Thus our code will now express meaning.

Evolution on multiple timelines becomes possible

Working for a fast growing startup has turned out to require far more versatility than I originally thought. The core product needs to serve multiple parties each having their own goals, values and tech readiness.

We could always work out what would be the best processes for the organization and then code it but of what value would that be to the person using it?

To ensure the product we deliver actually has value to a human, we need to evolve the product to better serve them, when we have multiple classes of users with fundamentally different needs, we are in effect building out a suite of products.

Microservices should help this flow much easier by enabling us to evolve at the rate of the relevant party.

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:

Giving an update on an ongoing project

Planning for an upcoming project

Working together on an existing project

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:

What have you managed to achieve since last time we met?

What are your blockers?

What are your plans?

Not this:

What are your achievements?

Discuss on possibility of building an XML parser

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:

An action list (who to do what by when)

A decision

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