The value of clear goals

 

As the business I work for has scaled, we have found ourselves in a situation where we rapidly need to grow the technology team. In this scenario, we have come to see the limiting factor is how fast we can nurture new leaders within the organization. For context, the tech team is organized to have small groups of 4-6 people led with a subject-matter expert team lead.

For our newly minted team lead, I need to take them through the ropes, especially if they are a first time manager. Even if they aren’t, we need to instill in them how we view leadership.

If you imagined we do some Nyamachoma or a related team building activity, you would be wrong. The first task we set out to do is to articulate the defining and setting of clear goals for the leader and their team.

In this entry, I will be discussing why we consider goal-setting to be the most critical activity for a team.

Eliminate politics

In the absence of something to aim for, people generally result to irrational self-interested behavior. In truth beyond the smallest businesses, the activities and aims of the organization are beyond the reach of individual contributors.

Sure, you may have an inspiring vision, but if you are customer support agent in Google Adsense division, what exactly are you supposed to do with “to organize the world’s information and make it universally accessible and useful.”?

This ambiguity means the measure of work rapidly falls to the level of who receives the most accolades from the boss or whoever can warm the office seat the longest.

Mutual accountability

I have had a varied gym relationship, filled with “on” and “offs”, mostly “offs”, but that is a story for another day. The point is when trying to understand why it’s so hard to sweat it out for 30 minutes, I came across the concept of a gym buddy. For the time my brother and I went to the gym together, I experienced my longest “on” streak.

You can employ the same principles which make this system work to your teams. Think about this way, to them you are just a boss, overpaid and didn’t do any actual work. Their colleagues, on the other hand, are comrades, they sweat it out together to bring the sprint to fruition. As you can imagine, much loyalty abounds in these relationships.

With clear goals, you can tap into this dynamic. Every team member can see what the others are doing to accomplish shared goals, and they don’t want to be the ones viewed as slacking off. If an individual decides to be a loafer, peer pressure works for you as they receive the stink eye from their colleagues.

Grow leaders

In one of the leadership syncs, the sourcing manager quipped at how happy she now is to see the table full. For context, she was one of the earlier employees, doing the start-up work from tuk-tuks to now leading a 100+ organization. Still, I wondered why the comment. She went on to explain, before we came she had to do everything, to think of everything now, there was a whole team of colleagues.

You can not scale any organization if you can’t grow leaders.

By challenging your team to set clear goals for themselves which align with overall company goals, they start to understand the concept of what it takes to honestly ask themselves “What can I do that will benefit this community I am a part of.” In this way, you forge the next great leaders.

What to look out for

Finally, it’s essential to look at the two things you should never do when setting your goals: impossible goals, and mutually unachievable goals.

Stretch goals are great; they help teams do better than they thought they could. However, when you stretch the goal past the level a human being can accomplish, you lead your group straight to the death march.

The death march is a situation where everyone knows the goals will not be achieved, but you as the leaders don’t acknowledge it. Under this reality, work seems to be going on, but everyone is demotivated and stressed at the same time. Don’t do this to your worst enemy.

Mutually unachievable goals refer to situations where there is just nothing you can do to achieve both. For example, insisting this coming quarter, your QA team catches twice the amount of bugs as well as committing the senior members within the same time to scout out new QA software which will take most of their time in the same quarter. The benefits accrued from the latest technology may achieve the former feat, but the goal just can’t be completed in the quarter, perhaps at best the next one.

Do you have clear goals for your team? How do you set them? Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

How to manage schedule risk

null
In one of our usual catchups, I was having a chat with one of our engineering leads, casually explaining a feature request we had received from our sales organization. As a team, most of our clients are internal, and we are always happy to receive such feedback. It came in as a mild shock when the response was we wouldn’t be implementing this feature. I knew it wasn’t a matter of time; we had processes to handle long term as well as delight features. So why the no?

In the same casual tone, he went on to explain a viable scenario where with the feature implemented, the interaction between sales and finance systems would grind to a halt, and we would then need to push an Android update. In short, the feature delivered nothing more than delight value but had the potential to stop the entire business!

I moved on from this conversation with even more respect for this individual; this truly is the mark of great leadership.

In this entry, I will be discussing a bit more about risk and how you can relate to it within your engineering organization.

Be clear

Risk is such an ambiguous concept. You can’t see, touch, smell, hear or taste it. Even intellectually grasping it is a hard endeavor.

It is easy to ignore such things. After all, do you really want to be the Grimm at the project kick-off party?

Still, it’s essential to enumerate your risks and the likelihood the risk will materialize. It doesn’t need to be a long or formal document. Frankly, even if you drop the likelihood calculation, just the fact that the possibilities are on top of your mind is well worth the effort.

If you already do this, pat yourself on the back. Now, to the more difficult task. How do you know the risk has materialized?

Suppose in your risk register, you had “Developer leaves team” and “Vendor X stops supporting Y library.” You may say, well, of course, we will know when these risks have materialized. Once you dig a bit deeper, you will see how this belief is flawed in an insidious way.

Let’s take the first case. Most organizations have a reasonable notice period before you can leave, for an engineering manager, this is cheap comfort. When a team member has decided to move on from your business, all sense of initiative goes out of the window. What you now have is not the whole brained, energetic, committed dev you used to know, rather a by the book, can’t wait till 5pm, does minimum work to get it done lad. In short, your ambitious schedule is f*ckd!

Have a contingency plan

If you have a risk register and have not thought through how you will handle the risks, then in essence what you have is a glorified worry list.

I have come to see risk as having a fascinating characteristic. Once it becomes obvious, a risk will transition then what you need to do becomes obvious but mitigating it, if at all possible can only be done at a high cost. Before a risk is obvious, what you need to do is less obvious, but it can be done much more cheaply.

To illustrate the point, think of an app that failed in production because it runs out of memory. In this case, once it becomes manifest the event is happening, there is little else you can do if you are stuck in a VM type of architecture, scale it, and the application quickly eats through the new RAM. In short, what you need to do is visible but very expensive. If you had thought about this problem when the app was still in Greenfield, you then wouldn’t know if the risk would ever materialize, but solving it would have been as easy as say, choosing a different programming language, or going cloud-native.

You obviously can’t plan for all risks, but if you can select the risks with the most significant impact and the chance of happening. You maximize your chances of being able to sail through the worst of the storm or better yet, avoiding it altogether.

Did it happen to your peers

In Swahili, there is a saying

“Ukiona mwenzio ananyolewa, zako tia maji”.

Roughly translated, if you see your neighbor getting shaved, you better start wetting your own hair.

The point here is if other smart people have tried to solve the problem you are now embarking on without success, and you can not clearly articulate why they failed, there is probably an underlying structural issue.

An example here is the Kenyan cashless markets. Almost all international players come in with a firm intention only to accept online payments via credit cards, soon this softens to Mpesa, and for those that thrive, cash makes its way back into their model. I am not saying I understand why pure cashless doesn’t work or that it will not work, maybe even sooner than we think. What I am saying is, if you are entering the market now, you are well advised to consider lessons of your predecessors.

To get started, you can think of some of these risks, almost every leader in a tech organization I know has had to face some variant of.

  1. Developer leaves your team
  2. An essential vendor/library drops support suddenly
  3. The client gets new ideas as the project starts shaping up

How do you manage risk in your own organization?  Talk to me in the comment section below, my Linked in chenchajacob or my twitter @jchexv

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

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