Making better decisions

 

 

Good decisions matter. In fact, it could be argued the primarily KPI for a manager is decision making.

Confronted with a decision, I have seen many professionals give instructions based on the first thing that comes to their mind. As in any other field, some managers are particularly gifted, and this works out, for the rest of us, it makes some sense to have some rules of thumb handy.

In this entry, I will be reflecting on the various actions I have found useful in making effective decisions.

Be Precise

SMART. Specific, Measurable, Attainable, Relevant, Time based.

Surely we all must have heard about this acronym somewhere. As a framework for evaluating goals, its merits are beyond dispute, yet I argue the method can be simplified even further. For decisions only two factors matter.

Measurable and Time-based.

By definition, a decision implies the existence of alternatives. Here, I mean real options. For example, a decision should we or should we not pay our top employees is mute, the alternative is untenable

A good choice gives proper stead to the other options. It explores the possible costs and benefits in ways that can be measured.

Consider the  decision such as:

We will introduce game night to boost employee morale

Sounds great right? Now what about:

We will introduce game night, this will cost us Kshs 1M per month. It is expected in the coming year, we will experience a drop in voluntary exits from average of 5 per month as seen last year to 2 per month saving us recruitment and training costs of 3M per month

The decision is not only measurable, but it is also possible to reflect on the decision in a year and see if it was actually the right decision.

Build in a way for the decision to be executed

If you happen to attend a government function, you can expect to hear words such as:

As a government we will work to ensure you have clean water, a hospital here, jobs for every able person and reduce your taxes.

Obviously high aspiration but mostly fluff. No decision has been made here, after all, how will all these goodies be delivered on the back of a government cutting its own funding means?

Any manager worth his salt sees through this hyperbole, the same manager then goes to the office the next day and declares to his team.

This quarter we have adjusted our sprint goal to 60 story points per sprint. I trust in you to deliver this.

If the confused looks from your team were not educative, let me explain what went wrong. The decision made here is merely un-executable.  Don’t get me wrong, as a goal, it has some excellent characteristics, it’s definitely measurable and time-bound but how the hell is the team to execute on it?

Perhaps a better way to do this.

Due to company x ( a new threat) entering our industry, a decision has been made to more quickly move along our product plan. Our historical average has been 40pts/sprint but I believe we can get this to 60pts/sprint. To do this, we need higher quality hires, the HR team will be holding a session with us on how we can systemize our hiring process. Further, I believe as surely you must that higher quality code is the basis of faster development due to reduced rework. Thus going forward enforce a strict policy of 100% code coverage on all new code.

Of course, don’t give orders, ensure whatever decision you come up with and its attendant actions have well been negotiated with knowledgeable parties within your team.

Embrace conflict

I work with a great team at Twiga, for the purposes of this example, I will discuss two particular managers within the product team, Evans and Seth.

Seth is extremely precise in his thinking, his attention to detail is something to marvel at. In discussions, he will usually be the first person to notice inconsistencies in what we are working on.

Evans, on the other hand, is unusually perceptive.  He is able to synthesize a great number of facts and come up with a simple and clear explanation.

In any working session, there will always be some opposition to my ideas. At first, I merely accepted this, but I have come to embrace it. These two gentlemen have sharpened my thinking, through their eyes, I am now able to see through my own blind spots.

This is not a fringe phenomenon in my own little world or even within Twiga but indeed a general truth. To get the best thinking available, you must submit your ideas to argumentation and be willing to take the best ideas.

It is only through this means your decisions will get sharpened.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Objectives of a Software Project Manager

In the friendly banter after a routine management meeting, a colleague asked me.

If I was to become a software project manager, what advice would you give me?

For context, the lady leads her own team successfully and has the requisite project management educational background. So obviously she did not care for a run through on the latest PMP manual.

I thought a while about this and distilled what I think are the most important objectives for a SPM.

  1. Get it done faster
  2. Make commitments you can keep
  3. Make progress visible

Get it done faster

I am a otarian, in one of our Saturday fellowships, the speaker made a comment which has stuck with me for 3 years now.

I am a slave of time

After the session, I tracked him down to understand what he meant by this cryptic statement. He mentioned to me, of everything else in our physical universe, time is the only thing we have absolutely no leverage on. Given enough resources almost anything else can be changed, but time waits for no man.

In the world of software, this is especially true. Engineers are usually one of the highest paid resources in a business. If you happen to be accountable for their time, you must take this responsibility seriously.

Even more importantly, the features being released to the business are time sensitive.

Bill Gross, in one of the most popular ted talks in the business category makes the case, timing is the most important factor in the success of a startup

For a business which is going concern, you can be sure what you are building is relevant only now, take too long and whatever you deliver may just as well be garbage.

Figure out what too long means for your business.

Make commitments you can keep

Why is Uber so successful?

Some may argue its the comfort, the quality of the cars, or even a great rating system. I posit its because they are reliable.

When you call for an Uber, you never have to worry wether one will be available, or that it will be where you are within 15 minutes (upper limit) or that you will get home safely. Yes, you may at times pay more but your ride will be there.

If you may even allow me the audacity to claim, reliability is the most important factor for career success.

There is a characteristic of a good number of people I find very annoying. You have a discussion which yields some action points, perhaps you note yours down. Looking into their eyes, you can see a lazy glaze, you feel a premonition, in time an excuse is coming. Will it be they forgot the task? Maybe they were too busy? Who knows.

Don’t let fancy degrees fool you. Business is not a high iq sport, the ability to deliver consistently is more valuable than brilliant but sporadic outputs.

As a SPM, you are now in charge of more than just your own output, you are now going to be held accountable for commitments made by the entire team.

Be reliable.

Make progress visible

The most important objective of any manager is to illicit top performance for the team they serve.

This is doubly true for development where the work output quality is not self evident.

To understand why its so important to show progress, let’s take a moment to think about what motivates your team. Before they were the rockstar engineers you now know and love. Your team mates were struggling noobies. Now learning programming is a painful experience. For most part nothing makes sense, the errors are cryptic and the machine does what it darn well pleases. Wins are few and far spread, before it all clicks.

Yet this feeling of progress, the joy of competence is worth it.

In the work environment suddenly everything is tipped around, the work is rarely technically challenging, most apps are glorified database abstraction layers after all. Business requirements are however ambiguous and constantly changing, the hierarchy passes on dictates without pause to explain why it matters. This is a different kind of jungle, how is one to know they are getting better?

This is where the SPM comes in, build your team a racetrack. Absorb all the uncertainty and spit out a challenge, one the engineers will know for sure when it’s accomplished, be able to access their current position relative to it and understand how well they actually did.

From your fellow business managers, expect some skepticism, after all, the head of commerce brought in 10% more sales this quarter, what did you bring?

Good progress indicators help you demonstrate what you are doing and why it’s essential.

Make progress measurable.

In your opinion, what are the three most important objectives of a Software Project Manager? Talk to me in the comment section below, my Linked in chenchajacob  or my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Why have a deployment pipeline

 

When I was starting out on my software development path, I landed on a handy little trick.

On the root of the project, I would put in a new file deployment.md.

On this file, I would write out all the steps I took to deploy the code. This includes even code to ssh

ssh app@172.65.45.32

Use password: secret

This system worked quite well. After all, I was a lone wolf and everything I deployed needed to work on only one server.

Of course, nowadays the systems we write are not as trivial:

  • They require coordination across teams
  • Security is a key concern
  • Downtime is unacceptable
  • Different services run on different servers

With this new conditions, I have learnt to embrace a new concept, automated deployment pipelines.

In this entry, we shall be looking at the benefits to be experienced in deploying the new system.

Feedback to all teams involved

In deployment just as in development, you will come across errors, bugs as it were. You may think this is a problem, I don’t think it is, such is the nature of the world. The problem would be not knowing what is going wrong.

Automation helps in the sense the bug happens every single time, not just when the sloppy developer is pushing their code. This makes it far easier to diagnose and thus permanently fix the issue.

Furthermore, each team formally or otherwise has the DevOps expert. But what happens if the person gets sick and the system goes down?

A proper pipeline is a crystallization of this professionals knowhow, it can be used even in their absence. Even better, other devs can explore what he did to add to their own knowledge.

Less documentation

Documentation is a whole lot of fun, isn’t it?

Without a deployment pipeline, there must be documentation guiding the rest of the team on:

  • The steps to deploy
  • How they will know they have been successful
  • The various error states and how to recover

Even if you are able to successfully do this, the work quickly decays and there is no obvious way of seeing this happen.

A CD pipeline is in tune with your code. The moment it breaks, the code can’t go into production. This means:

  • The deployment pipeline will always be up to date
  • The steps are self-documenting

Basically unit tests on steroids.

Free up time

To carry out a successful deployment. The developer needs to have a working knowledge of :

  • Unix commands
  • Servers
  • Proxies and load balancing
  • Networking
  • Etc

Beyond trivial websites, the work is not child’s play.

Yet after the first time, it is very repetitive. Which creates the dilemma for you, hiring expensive staff to work on rote stuff and bad for the professional who gets to basically bang their head on the keyboard every day.

A deployment pipeline frees up the devs to work on high value creative work. You will notice this in the form of higher engagement from them.

Easy to verify

Suppose the work was outsourced, the consultants then give you a working system together with the source code.

What happens if for some reason it went down and you need to restart it?

Sure, you can always call them back in and trust somehow the developer who worked on it is still employed with them and has retained a working knowledge of your system.

Quite the gamble my friend.

Alternatively, they could show you during the demo which button to push to bring the whole system right back up!

In conclusion, automated deployment will make your life much easier. With the rising popularity of containerization and development of great orchestration tools like Kubernetes, you really have no excuse to still be doing manual deployments.

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

Facebooktwittergoogle_plusredditpinterestlinkedinmail