Planning for change

Let me begin by illustrating how change can come rapidly to even the most mature systems.

At Twiga, one of the Tech team’s critical areas of responsibilities is the DMS. This system is an internal propriety system that helps us manage each and every aspect of the value chain.

For a very long time, the business has been focused on Fresh Foods and Vegetables (FFV). For the system, it meant we could use Kilograms (Kgs) as the Stock Keeping Unit (SKU). The idea was, you buy from the farmer in Kgs, you store and ripen in Kgs and finally sell in, you guessed it! Kgs.

The concept of Kgs as a standard unit of measurement worked so well for so many years, you could see the signs of the idea in virtually every report.

Well recently, the business decided to add Fast Moving Consumer Goods (FMCGs) to its offering. FMCG include the likes of Flour, Cooking Oil, Sweets, etc.

The problem with FMCGs is, of course, the concept of Kgs doesn’t map very well. How many Kgs is a packet of sweets for example? Does anybody buy their tea leaves in Kgs?

So we now have an interesting situation, flour would be bought in bales, stored in pallets and sold in packets.

As you can imagine, there was a lot of pressure to bring the system up to speed. Every day we were not selling was a day the company lost revenue.

Eventually we did solve the problem and adapted the system. The key takeaway here is you should anticipate change not just in requirements, but in concepts the business is built on top of.

Here I will point out some of the tips you can use to manage significant changes better.

See requirements gathering as a continuous negotiation.

Tech teams have a reputation of being inflexible. Who can blame us, we are good at delivering on what we promised and its hard to understand why others see it fit to change their minds on a whim.

Yet to go past “meets requirements” to “exceedingly valuable,” we must see tech, not as an external party who checks of items in a scope document, but as an integral partner who shapes the work to be done.

If you do take on this mindset, you don’t wait for the client to simply tell you what they want, you dig deeper and see the problematic situations they face. You try to understand how they came up with their requirements and then see if you can help them refine it so that it better solves their problems.

In this process, you must understand you are dealing with a human being not a machine, some of their needs they may not be able to express. Remember, you are the one with the years of technical training and experience. Still, they must feel respected and listened to, they probably have even more expertise in a different line of work.

In all this, remember to treat your client as a colleague and maybe even a friend. This relationship is what will keep things going in the tough times.

Give the pessimistic date

“All Models Are Wrong, Some Are Useful”

George E. Box

Standard industry knowledge states you should give a range of dates for delivery. For example, we will get this done sometime between 10th Sept and 1st Oct. That’s some good advice if people were able to grasp what you mean entirely. In my experience, what happens is they tend to forget the later date and then push you for not meeting the more aggressive deadline!

Certainty, even when dead wrong is incredibly valued in business settings.

I think a better way is to just give the pessimistic date. This works even better if you already plan your work in sprints. Then you can say this is planned for 4 sprints from now.

A useful rule of thumb would be to plan your work as usual but allow a full day for the team to work on changes every 10-day working period.

The confidence trap

For most teams, especially internal teams. The person giving instructions occupies a higher position in the totem pole. For the most part, it means when they look into their past, all they see is their success and how they have been right while others were wrong.

There is nothing wrong with this mindset, confidence is another highly valued trait for business leaders. Unfortunately, what it means for you is they will likely have a solid sense of what they want to achieve and will actively resist being persuaded otherwise. They will tell you what they want, how they want it done and how long it should take. Conveniently forgetting their expertise doesn’t neatly translate into tech.

For this kind of situation, there really is no clear answer. The best thing to do is to massage the client’s ego as much as possible while actively involving them in the development process. You will come to find there is a lot of value in engaging a committed and smart professional in your thinking.

How do you handle large changes in your own organization? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Lessons in growing a self organizing team

Late last year, in the cold Karen weather, we were in a management retreat discussing Twiga’s quarterly performance and what needed to be done to take the business to the next level.

Grant, the co-founder, and CEO of the business stood up to speak to his gathered managers. He said something paradoxical.

“If you want to succeed in this company, you must make yourself redundant”

The unexpressed question hanging over everyone’s head: Isn’t redundancy an unwanted ticket home?

But then I understood the paradox, if you are needed too much in your current position, you will never have the bandwidth to take on new challenges in the fast-growing organization.

I decided to risk it and work with the team I am part of, tech, to hone our self-organization skills. By this, I mean our ability to identify value creation opportunities within the business and act on it while at the same time remaining reliable in the delivery of committed objectives.

In this article, we will be discussing some of what we think works.

Master communication

A big part of managing is being a message broker. When the team is just you, communication is instantaneous, you make a decision, you act on the decision. When one other person is hired, you now must have a discussion with at least one other person before significant action. Once you get to 5 people, every other person must communicate with every other person meaning you now have 10 communication pathways.

As Richard Hackman points out:

“A colleague and I once did some research showing that as a team gets bigger, the number of links that need to be managed among members goes up at an accelerating, almost exponential rate. It’s managing the links between members that gets teams into trouble.”https://hbr.org/2009/05/why-teams-dont-work

More specifically, the formula for determining the number of links between members in a group: n(n-1)/2. Where n is the number of members.

The manager then acts by being the person everybody refers to, cutting the links back to a more manageable (n-1). Yet this is what we don’t want.

To solve for this, don’t waste time seeking consensus.

I am generally an agreeable person. Yet, I have come to find out if you put enough smart people in a room they are bound to disagree on important issues. Even worse, you will come to find none of them is demonstrably wrong.

In this environment getting everyone to agree is a waste of time, a more productive path is seeking buy-in.

You will come to find most smart people will support, even commit to an idea if they feel their own view has been given proper consideration.

So what you ask of them is not agreement but commitment.

Provide context and let the team figure it out

No one is promoted to a post where they manage others because they were incompetent at their jobs. Yet what makes you successful as an individual contributor is diametric to what makes you successful as a manager.

Think about the developer who is now the engineering manager. One of his developers is struggling to get a feature done, and the demo is in a few days. The manager knows if he rolls up his sleeves, he can get the work done this evening. He is not looking forward to embarrassing the team in front of the senior leadership, what should the manager do, continue waiting on the feature or get it done himself?

If you chose the latter option, don’t worry you are in the majority. The feature does get done, the powers that be are happy but the team has learned an insidious lesson when it gets tough, give the work to the boss.

The solution here is to appreciate just how much your job has changed now that you are the manager. Your work no longer entails getting things done; it’s now making peoples skills effective.

This shift in mindset means you will no longer experience the highs that come from getting a feature done, you now must find joy in the success of others.

You should now work hard to clearly illuminate the work that needs to be done, then step aside and watch as others find success in this path.

As the legendary Steve Jobs put it:

It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.

Find common purpose

Teams are formed for many reasons, the reasons, for the most part, get lost in time. There is no point in focusing on why the group was formed, at best this can help provide context, the team now must decide on its reason for being.

I have come to find smart people generally resist being told what to do. Yet they will passionately commit to what they have chosen to do.

Victor Frankl said:

In some ways suffering ceases to be suffering at the moment it finds a meaning, such as the meaning of a sacrifice.

This illustrates then the difference between compliance and commitment. Compliance is what happens when the team does what you tell them to do, commitment is what happens when they do what they have chosen to do.

Your work is clear, let your team know what are your priorities, your posterities, what is going on in the business what are the emerging problems and then ask “Knowing all this, how do you think your contribution will be effective?”

How do you help your teams grow? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

What to consider when growing your team


 

In the course of our working lives, we have to make a whole lot of decisions. In this entry, I would like to take the time to reflect on what I think are the most important decisions you have to make, hiring, firing, and promoting.

As the leader of your team, it is your responsibility to nurture it to maturity. This means you can not abdicate hiring decisions to HR, staffing firm or even hiring system.

Obviously most of us don’t really originate the teams we lead, we inherit them, still your most important work remains this team, when you took on the job, you became accountable for its performance.

With that said, let me delve right into what it takes to make great staffing decisions for your team.

What does each role do?

A characteristic of the modern economy is specialization. Within our teams, this manifests as highly specialized roles.

For example in a tech team you may have:

  • Backend developer
  • Front developer
  • Designer
  • UXer

Depending on your business even more nuanced roles may come up.

Looking at this composition, the most obvious take away is none of the team members are any good by themselves. What good does a Designer do if no one translates her designs to a working system?

As I stress in other posts, tech is an organ of the business, it gets its raison d’être from the business of which it is a part.

Thus your duty as the leader of the team is to carefully consider (best done with the team) what value the team offers to the business. Once this is done, consider how each role contributes to the generation of this value.

The exercise will help you more clearly see the roles, who would fit in them, missing roles and even redundant roles.

Remember, the character of the roles changes with the rhythms of the business. An example would be the perfect backend engineer role when the business serviced 20 customers may fit the bill for an SRE engineer now that the business serves 100 customers.

What strengths are needed for each position?

I used to believe all humans are equal in ability and temperament, all that matters is the effort put into the work. I have come to learn from experience this is not true.

Each person comes equipped with a natural set of strengths and weaknesses.

There is no point in trying to mold a naturally creative but otherwise disorganized person as your coordinator. Likewise, it would be foolish to strap your “by the rules kind of gal” into a position requiring constant adaptation.

Now, this is not to say weaknesses can’t be overcome, of course, they can, the challenge is even if they are, what you end up with is at best an average performer.

The point here is not to eliminate glaring weaknesses, even the most charming salesperson is to be relieved of his role if he repeatedly shows up to important meetings inebriated.

What are behaviors to look out for?

In time, I have come to realize people judge themselves by their intentions and not by their actions. This would be ok if intentions and actions match, but you must have come across individuals who consistently act against their self-interest in ways which dumbfound even themselves.

What is the implication of this odd fact as you make hiring decisions?

You must focus on behaviors and not on statements of intent. You must teach yourself to drill into the details. If an interviewee says I taught myself python, ask what projects they have actually done in this project, then ask to see the codebase. If you have the time, see the commit history!

When defining the role, think deeply about what behaviors they will need to exhibit in order to be successful in this role. This can help you and other hiring managers ask the right questions.

For example, I hold people who have self-taught in high regard. There is something special about someone who after all the stress of their day jobs still manages to get home and finish a course not directly related to their current job. This is a behavior, not an intent.

Now that they have joined, what next?

I am not one easily accused of micromanagement. I believe each team member should be able to set their own working style and priorities as long as they align with the business goals.

The problem is if a new hire or recently promoted staffer has no idea what the role involves. In this case, some guidance is needed.

This is because a person’s performance depends on both their ability and experience on the job. So a person who has great ability but no idea what the job is all about will likely fail. A person with low ability should likely not be in your team at all.

Personally, I use OKRs (Objectives and Key results). Together, we brainstorm on 5-10 objectives for the next quarter, I give them a week to think about it, we then whittle down the list to the top 3 and attach some measurable results to tell us if they met the objectives.

How do you make staffing decisions? Talk to me in the comment section below, my Linked in chenchajacob  or my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail