Showing posts with label Process. Show all posts
Showing posts with label Process. Show all posts

Monday, 9 May 2016

Results over Process, or Process over Results... Managing the Balance

Statistics


In my first sales job, the company micromanaged the process. They had it all the stats figured out and the process was a pure numbers game. If you do X number of cold calls per day, you will get Y number of new customers. Simples. So, you had to tally up your cold calls for the day, and you could stop when you reached that magic number. If that didn't yield the expected results, you were put on probation, because it was assumed that you hadn't done the number of cold calls that you claimed. Again - Simples. They removed the human element and reduced sales ability to pure statistics. As far as they were concerned, anyone could be a good sales person, they simply had to follow the programme.

Were they wrong? Not entirely. Were they right? Partly.

Repetitive action (habit, perseverance, or whatever you may want to call it) in the wrong direction is still wrong. You just get better at being wrong.

Repetitive action in the right direction is still right. You get better at being right.

Management


In our previous example, where statistics rule, there is no such thing as a bad manager. The success of the team was purely as a result of following strict processes. The manager was the stick who made sure that you were following the rules, and the financial bonus was the carrot.

The Emotional, the Hands-off, the Micro-Manager and the Entrepreneurial Manager


I have worked for all of the above, and I have learned so much from each of them.

The Emotional Manager 

No Process, and results are a matter of chance


They say you should do one thing today, and then the opposite tomorrow. They have no clear strategy or process, and therefore no clear parameters for measuring performance or attributing praise or blame. They would be better off in a team of one.

The Hands-off Manager

Some Process, and the results are in your hands


They will let you succeed (or fail) on your own terms. They may or may not have benchmarks for measuring success / failure, and they may or may not have procedures in place. Working for someone like this is the next best thing to being self-employed. Go forth and experiment.

The Micro-Manager

I am the process, and the results are all my doing


It's my way or the highway. This person does not welcome feedback on the system (or lack of). Just do as they say (and not necessarily as they do), and even then, they will take the credit for everything.

The Entrepreneurial Manager

Process is evolutionary, results are understood, and the team is central to that


This is really the holy grail of management styles. Usually this person runs their own business and they are very much a part of the business. If you have hopes of working for yourself one day, this is the best person to learn from and to collaborate with. You can question this person and be assured that they will have sound and balanced business reasons behind what they do and why they do it. You can trust them to put process, quality and results on an equal footing and you can recommend them with confidence to your network. They harness the collective expertise of their team and place a great deal of value on it.

Sunday, 6 December 2015

Getting from A to B with Algorithms... Don't Panic! Code On!



So, I set myself a bit of a crazy challenge a week ago. I decided to learn Javascript from scratch, and then use it to create a Binary Search Algorithm of a Sorted Array... Simples!

The challenge is from Khan Academy, and it assumes prior knowledge of Javascript. I wasn't going to let that little assumption get in my way! I started off with Codecademy - learned the basics, and then skipped straight to 'for' and 'while' loops.

I thought this would be a good topic for a blog article because I am relatively new to the practice of coding, and I wanted to share my experience with other budding beginners out there. If you are new to programming, or you would like to give programming a go, I hope you find this article interesting and useful.

So, what is an algorithm?


An algorithm is literally just a set of steps that you follow to get something done. Your daily routines are algorithms, for example, getting dressed, going to work, cooking a meal. That's not so intimidating is it!

The first step to coding an algorithm actually requires no coding at all. You just need to work out how to get from A to B. Sketch out the steps that need to be followed in order to get from A, which is your input, to B, which is the output (or result). Get a pen and paper, and start sketching out your ideas.

Plan your route before starting the journey!


Now, for experienced programmers, it is easy to jump straight in and start coding. The Khan academy tutorial has the task written out in plain English, with a tiny bit of pseudocode, so they've done all the thinking for you right? Wrong! It is still best practice to map out your own process. That way you can ask questions and get a complete understanding of the task at hand. But if you're ok with buggy code, go right ahead!

I'm going to show you how I did my planning, and then I will share my code at the end.

The Task


We have an array of prime numbers from 2 to 97.


Feed a random number into the binary search algorithm.
If the number is present in the array, the programme will return the index position of that number.
If the number is not present, the programme will return '-1'.


Binary Search


Binary Search is a really efficient way to find an item in an ordered list of data. In this case we have the list of prime numbers above. The search is a process of elimination. You narrow down the possible options by dividing the data in half over and over again, eliminating all the possible options until you are left with just one, which will be target.

Our minimum value is 2, which is at minimum index position 0.
Our maximum value is 97, which is at maximum index position 24.

Note: Because our array starts from index position 0, and ends at position 24, that means there are 25 values in the array.

How it works


To illustrate how this works, I am going to choose a random number and show how the algorithm will 'guess' my number.

Step 1


The programme starts by guessing the mid-point of our array, which is index position 12 in this case.

The algorithm establishes the mid-point in the following way:

My number = 67


Is my number equal to the first guess, i.e. is 67 = 41? No. My number is 67, is at position 18, and the first guess was 41, which is at position 12.

Step 2 & 3


We want the programme to compare the value of our number, 67, and the value held at index position 12, which is 41.

If 67 is greater than 41, we know we can eliminate all the values to the left of and including position 12 in the array, because they are all less than 41, which in turn is less than 67.

If the our number had been less than 41, we would do the opposite and eliminate the values to the right of and including position 12.


Step 4



Step 5


We now need to find our new mid-point, so we repeat Step 1 as follows:


We have arrived at our number!

This programme will keep running until it finds our number.

But what if we choose a number that is not present in the array?

We simply say to the programme, if the number we choose does not match any of the values in the array, it will give us an output to indicate that. In this case, I have asked the programme to return the value '-1'.

Edge Cases


Something I will touch on very briefly is Edge Cases. The programme that I have written above does not factor in what happens if I were to choose the values held at index position 0 or 24, which are the prime numbers 2 and 97. They are what is referred to as 'edge cases'. The values at the edges of an array.

So, I had to write a couple of extra lines of code to deal with them. I gave the programme specific instructions about what to do if I choose either number 2 or 97 as my random numbers. As with all programming, there are different ways to do everything. I will not go into detail, but here is my solution:

If my number is 2, return the value: index minimum;
but if my number is 97, return the value index maximum.

The Code



The Main Challenges


  1. Getting to grips with for loops and while loops required a lot of repetition. I completed the exercises on Codecademy and revisited them a few times to make sure that I fully understood the flow.
  2. The code performed really well when testing the mid points of the array, but some extra code was needed to test the edge cases.
  3. Although the code is neat and tidy, it could do with a bit of refactoring, so that's my task for another day!

Long story short, I finished it yesterday! Hooray!


It was a really fun process because it's like solving a puzzle. Who needs sudoku when you can code!

If you are thinking about coding, stop! Don't think about it anymore. Just get started!!! Codecademy is a great resource to start with, or you can check out these amazing tutorials from +Kingsley Ijomah He starts with html & css, moves on to Bootstrap, and then Ruby on Rails. The great thing about his tutorials is that he assumes that you have absolutely no prior knowledge of coding. The tutorials are for absolute beginners! Get started today!

About Me


I am not a programmer, I am a dabbler, with a curious interest in Mathematics. I have not worked commercially as a programmer, but I co-founded a software company back in 2008, and I have worked with programmers since then. The bulk of my experience is with html and css, but I have studied Ruby and a bit of Python, so I understand the key concepts and I can hold my own. I have recently made a foray into the world of MVC (Ruby on Rails), which is a whole new experience, but I did not have a project that I had coded from start to finish before, until now! So when I did my first git commit yesterday, it felt good!!!

Saturday, 5 December 2015

Are You An Infinite Monkey?


Do you remember tackling Maths problems at school, and the teachers would always say, "Show how you worked it out!" I thought that was a pointless exercise, because if I know the answer, then I know the answer, right? If I don't know the answer, then I'll have to work it out. Showing what I already know is a waste of time. Or is it?

When one of the teachers explained it to me, it made perfect sense. They want to know how you arrived at the answer - the steps you took to get there. It's not so much about having the correct or incorrect answer, but if they can see your workings, they can help fix your process. You can then apply your thinking more effectively to future Maths problems and improve your chances of getting the correct answer.

Those same principles have a much wider application than I originally realised when I was at school. If you can show your workings, when it comes to work, hobbies, relationships, you can solve a lot of your own problems.

Well, that's how it's always been done


Very often in life, as children in school or adults at work, we are told 'what' to do without really knowing the 'why'. That's because the people in charge probably don't really know why. The answer, 'Well, that's how it's always been done', is a particular favourite! As is the case with middle-management, they don't know why you are being asked to do things a certain way, which can be very frustrating for the workers, but it can also make the job of the managers very difficult.


It's easy if you have a fixed set of steps that you must follow every day, which have fixed outcomes; but what if the instructions vary from day to day, with no clear goals or vision? It would be very hard and stressful to work in such a place.

A broken or dysfunctional process produces varied results of poor quality. As with Infinite Monkey Theorem, it is likely that they will produce something of quality at some point, but it will not be by design.

Why rely on such random odds?


When revolutionary new business practices are developed, they are often very intuitive and look like common sense. But that's because they asked 'Why'. Why have things always been done a certain way? Do those practices suit the modern tools or workforce, or are they from a different era?


Bad processes are scary because they're like a tangle of wires. You don't want to change anything because you're afraid it might break!

Continuous Improvement



Processes that have clear reasons behind them are easy to follow. They take into consideration the end goals, the tools available / needed to complete the tasks effectively, the skills of the workforce and expectations of the clients. Good processes are easy to review and change, because they are clear. You can see how everything is connected - the flow - and the impact of each stage in the process. Arguably, a good process is one that is under constant review. The thinking behind it is being improved and reviewed.

Kaizen is a very old principle, but it is one of eternal youth. A process that is continually improved for greater quality, efficiency and productivity will keep the workforce inspired, and it will certainly keep your competitors on their toes!