The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt
My rating: 4 of 5 stars

The goal talks though the conversion of a manufacturing plant which had been running using cost accounting and its embracing of Lean manufacturing. The way the book is presented is quite novel in that its presentation is as a story where you go on a journey with the plant manager as he faces being closed down.

Through the course of the book Kanban is presented and applied to the plant. The book covers things such as challenging the productivity views of robotics, showing how the entire productivity of the plant is dictated by its bottlenecks, that you need excess capacity and you can’t run everything at 100% without building up large amounts of inventory which may or may not be sold.

The production line approach, made famous by Ford for the production of cars, was an extremely efficient form of production because of the flow of work but for such a system you need large volumes to warrant a dedicated line. The aim of lean manufacturing is to take the idea of flow and apply it in environments where the volumes are not sufficiently large to warrant their own production line.

Flow is key to shipping products to costumers – the key is to reduce the time from when a customer places an order to the point where we get the money for it.

This does not work with traditional local optimisations. This usually means large batch sizes since the set up of the machine is likely to be significant and traditionally people then try to produce as much of the parts as possible from the single set up. This results in large amount of in progress inventory which adds no value in its current form. Additionally the larger the batch the longer the parts need to wait – 99% of the lead time to produce a product can just be it waiting to be processed. To facilitate flow it is key that the focus on these machines is to improve the the efficiency of the set up time so that the machine is able to produce smaller batches which reduce the amount of over produced inventory and the waiting time thus reducing costs and lead time.

When there is an issue with flow inventories accumulate and the order lead time increases and reduces bussiness cash flow. One way to improve flow is by limiting space, this prevents the building up of large inventories. This is counter to previous approaches since limiting space means that not every worker will be busy all of the time, only bottlenecks will have the high levels of utilisation. By stopping people work it quickly highlights any issues in the flow and these can then be resolved. This means that the focus is always of making the bottlenecks more efficient – which is key since any time lost at a bottleneck will impact the output/productivity of the entire site. Things such as putting quality control before the bottleneck will improve the throughput since the bottleneck won’t work on parts which will be rejected later. Ensuring the bottleneck is able to run none stop, such as by splitting breaks so that people can cover it continuously.

The challenge of small production quantities and small buffers is that gridlock could happen where parts are not available for assembly when the space is already filled up. A solution for used in Kanban is instead of restricting buffer space between manufacturing steps the amount of products which can be produced are. The Kanban system uses the idea that when you want to ship something to the customer this triggers all of the preceding steps required to manufacture the product. The way this is achieved is through the use of cards, these cards are passed from the end of the production line towards the beginning each one triggering the manufacturing of the parts required to produce the product which is trying to be constructed.

Lean can not be applied to all industries, because of the time it takes for Kanban to produce an efficient manufacturing process it only works for products which do not change for a significant period of time – this works better in a car plan where new models are only released once a year. Additionally Lean does not work where the products are produced sporadically – because of the buffers the product needs to be being produced on a continuing basis. Lean also only works where the mix of products being produces are fairly consistent. Any of these three will reduce the effectiveness of lean.

View all my reviews

How to Recruit and Hire Great Software Engineers: Building a Crack Development Team by Patrick McCuller
My rating: 4 of 5 stars

You should be hiring people with the right attitude and the capability to learn, master and teach since although you know what you are doing now you don’t know what you’ll be doing 1,3,5 or 10 years from now.

Hire top performers, hiring anything less than the best will hurt your bussiness. Talent bring talent, incompetence repels talent. A mediocre or low performer will not aid the team and will actually diminish its performance though having to deal with messed up projects or missed deadlines. It is generally easy to identify low performers and exceptionally high performers, the challenge comes with the mediocre ones – once hired these people are very difficult to remove because they are not doing anything wrong they are just not capable of performing at the high levels which you need. Top performers perform between 10 to 16 times more than an average one.

Understand your current pool of talent, ask them to periodically update their CVs to map out the teams current knowledge and experience. Knowing who is in the team will identify holes in the team if they need filling and will help you focus your recruitment if you need to replace someone. Critically the profile needs to look at leadership, experience (tenure, technologies etc), style (cautious, quick, adventurous, perfectionist) and roles (build engineer, tool engineer, user interface developer etc). Engineers have two preferences, either creators or optimisers. As a project changes from the start-up/creation phase into the optimisation phase this might mean that the people in the team needs to change to ensure that the engineers are still being suitably challenged.

Hire ahead where possible – the pressure of hiring someone urgently to fill a role will always lower quality through subconscious if not though concious bias.

First hires on a team are critical – you need engineers who are leaders and great communicators, who inspire the team both technically and on a personal level developing and coaching them.

Its a race – how quickly can you hire? because if someone else can hire quicker the candidate might be off the market before you have got very far through your process. Look at the process, the barriers and try to reduce the process to as short a time as possible – could you go from candidate to decision in one day? Can you speed things up, remove steps or reject candidates earlier? There are ways to make things quicker without lowering the quality of the candidates.

Candidates as customers. Candidates will be more likely to work for a company with a simple and enjoyable hiring process. If your candidates experience is exceptional, they will notice, talk and refer others to you. You will turn down a lot of candidates so if they are treated well rejected candidates can still spread the word about your company. So ask the candidates how they found the process, see what they say and improve things. By being as open with the candidate as possible they will know what to expect and so can perform at their best – provide a guide for the candidate to know what the steps of the process are. During the interview the words chosen should be straightforward – uncommon or complicated words should be avoided, not just for people for who the interviewing language is not their first language but for all candidates. There are some people who should just not be allowed to interview – for whatever reason they are not the suitable, these people should not be forced to interview as these people will leave a bad experience with the candidates.

Passive candidates need wooing – this might be extra steps such as a getting to know you phone call, speaking with developers, pre screening etc. Reduce the barriers to entry – such as not requiring a fully up to date CV however all candidates should be treated fairly. Don’t make exceptions for one if you are not prepared to make exceptions to all.

Active candidates contain a large number of people who can’t hold down a job, don’t have sufficient skills (e.g. new graduates). These sort of candidates gain a lot of experience at being interviewed.

Job descriptions are not inspiring – why would anyone work for a company based on a job description. If your target is passive candidates especially then they will either ignore or not care for the job description, so how can you attract such people but still provide them with the details of what they will be doing? A passion statement, this shows the passion for the company – Why are they doing what they are doing? Why should people work for you? and don’t present it in a dull form.

Great software engineers know other great software engineers, tapping into their network is immensely powerful but engineers themselves are usually not very good at seeing or networking. Additionally it is likely that their immediate group of contact are not looking for a job but encouraging them to speak about your company both to their immediate network and their wider network (friends of friends) is a great way to spread the word about your company.

Recruiters want to make money, if you reject all of their candidates they will not send you any more. The best way to improve this is better explain the candidate you are looking for to them, to explain the company, to help them better understand what you are looking for. The more information they have the more suitable candidates they will send to you and thus the better the candidates the more you will hire and the more money they will make. So spending time with recruiters is a great way to improve the quality of the source of candidates. Just remember that because the recruiter is incentivised to hire people they are likely to do whatever they can to help the candidate get the job (such as leaking interview questions etc).

Contract hires, instead of a long laborious interview process hire more freely on a short term contact then if they are performing well look to give them a permanent contract. To the author this has always turned out to be counter productive and a distraction rather than a benefit.

Unfortunately it is part of the concious for people to want to hire people “just like them”, this introduces bias be it sexism, ageism, universityism etc these are a challenge so when people say why they should not hire someone try to get to the root of it. For new starters working in another country it is likely that this bias is even greater. Don’t bother searching the internet for details about a candidate – it is as likely that you will find out irreverent information as relevant information, as such the risk of bias is greatly increased. Consider if the interviewer actually needs to have seen the CV or not – if the interview is competency based then there is no need for a CV then they should not see it since this will introduce additional unneeded bias. The HR team should redact any information which is not important to the hiring process and could introduce bias – such as gender, age, marital status etc.

Identify the source of the candidate, where you get a good source spend more time getting candidates through that source. Different recruitment companies and even recruiters have different approaches so try to focus on the ones which work best for you.

Lower the barrier to entry. Do you really need 6 years of Java experience? CV screening is quick simple and cheap – but this drastically reduces your pool of candidates for no good reason. Someone doing the same project for 6 years gaining Java experience is very different to someone working for 2 years on a variety of projects. Interviewing is expensive but it is better to look at your interview process, such as telephone interviews, rather than being harsh on CV content. When going through CVs look for positive points, negative point and neutral points. If the positive outweigh the negative then the candidate is worth interviewing. Positive items are things such as length of experience, relevant experience, variety of experience, education, computer science experience (such as university but specifically computer science rather than just Java courses), patents and publications (though reading these is not recommended), responsibility. Negative items are “wall of words” but not saying what the individual did, lengthy CV and quickly changing companies. Things to discard when reviewing a CV, things such as breaks in service, irrelevant information, small spelling or grammatical errors – especially when dealing with people who’s first language is not English.

Telephone screening provides its own challenges because of the unnatural narrow band of communication. A simple problem can become difficult and a tricky problem can become impossible over the phone. Asking open questions such as about recent projects can just use up valuable interview time because the power is passed to the candidate. Posing coding questions should be short, typically 30 seconds and can be conveyed without confusion and the answer to which are just a few lines long. An alternative is to use a shared screen so that there is no room for confusion.

To maximise the use of interviews ensure that there is some coordination over who is going to ask which questions to prevent repetition. Four or five experienced interviewers are the optimal number. When handing over the candidate don’t discuss the candidate to prevent bias. Gain feedback from interviewers independently before discussing the candidate.

If the candidate says that they are suffering from outside stress offer to reschedule the interview for a time when they are better able to focus on the interview process. During interviews candidates will be at their best. As an example if the candidates English is a challenge it is likely to be worse once they are hired, however a thick accent should be forgiven since after a day or two of working with the individual you will quickly get used to the way they speak. If the candidate makes inappropriate jokes or comments these are likely to be more prevalent once they start. If the candidate has strange mannerisms (such as restless legs etc) these can be medical conditions or stress induced and should be ignored. If there is silence then let it happen, this could be the way the candidate thinks and so you should be happy to let a little time pass for the candidate to focus. A large number of candidates lie, if you suspect a lie push it a bit to find out more – it is likely the candidate will admit to a misunderstanding however if the candidate gets caught up in their own lie the author has highlighted the issue and contradictions and then ends the interview process. Candidates expect certain questions, if you ask questions which are similar to these but are not the same then the candidate might inadvertently answer the wrong question in which case you should highlight the difference to clear the confusion up for the candidate. Where possible get them to do the job you will expect them to do and see how they get on, for jobs where you can’t do this ask them questions about their past jobs but remember it is likely the responses will be on the positive side. The book goes into many more details about interview questions than I am going to cover here.

Interviewers are only able to asses people of a similar level – it is very hard for a junior developer to asses the difference between a senior and a principle developer. This can be a real issue where you are looking to recruit a competency into a team that you don’t currently have as people will be recruiting outside of their field of expertise. Training interviewers through shadowing, classes and workshops, documentation and guides, coaching, practice interviews and then once they are actually interviewing candidates to continue to provide feedback so they are always improving. It is especially important to get interviewers to understand between domain knowledge and capabilities, if the candidate does not have the knowledge but has the capabilities then they will quickly pick up the knowledge.

Hire the best engineers you can afford and keep going till you run out of money/budget. During hiring there is always a margin of error. Hiring a poor performer is quickly correctable, you can just let them go. It is difficult to fire someone for doing just and “all-right” job. Hire the candidate is all of the things you want and nearly none of the things you don’t. “Nice” people are not enough, they need to have capability the nice people who are pleasant to everyone but when they start have no capability to do the work are the hardest to let go. You should never hire people who: slam former employers, severely irritates anyone, lies or deceives, ignores goals. Never hire below your standard, the hire will have impact for their entire tenure at the company which could exceed your own.

Feedback can give the option for a candidate to argue about an already made decision and potentially could give the option for a legal challenge. As such, if the HR team do not already have guidelines of what you say, the author recommends giving more generic feedback such as “You were not a great match today. Gain some more experience, hone your skills-coding, design and so on and consider applying again in a year or two”.

Keep and analyse records – not just of the candidates but of the recruiters. Review the data regularly. If you hire someone then let them go, was there any data which could have given you the information earlier? If a candidate performs really well were there things which you could pick up on to help identify this earlier? etc.

The amount you pay developers falls between the bounds of local market rate at the lower end up to creating golden handcuffs at the top. If you want great developers you need to pay them appropriately but over paying people will mean people who should not take the job take it only for the money and get tied in so they can not leave. Decide what your offer is and make it, this should be the maximum which you feel would be appropriate and explain this to the candidate so they know their is no room for negotiation. Make sure that you hire at the appropriate level, someone being interviewed for a developer role who is at a principle level will sail through the interview but they are not right for that role. Let the candidate speak to others on your team, even after the interview process, by being open and honest with them they are more likely to feel that they have made the right choice. If the candidate does not respond within a week don’t assume that they are not interested, instead get the highest person in the company you can to call to speak to the candidate as a sell call – this will set your company apart for a candidate who might get a couple of offers and your CEO has phones to speak to them.

The recruitment process is not over until the candidate is settled into their new job. Once they accept send a welcome email to them, giving them details about the work they will be doing – a large number of candidates will be passionate to know about some of the technologies they will be using before they actually start and will do some investigation at home. For people who relocate they will need even more help with things which you take for granted, e.g. where to rent a place or where shops are etc speak to them before they begin to see what help you can give them. Think about the first day – make sure they have a desk, their network account is set up, arrange for people to go out for lunch – everything you can do to make the new starter fell welcomed and part of the team. Try to arrange things for their first week to get them to start settling in this should cover the team, bussiness and technologies. Perhaps give them a peer mentor that they can chat to, someone who is an aspiring leader will usually enjoy taking on this role. Everyone is different and so will need to be treated a little differently to help them fit in.

Top talent want top talent requiring jobs, if you hire top talent make sure that the work they are doing is suitable. The things which turn off top talent are incompetent developer and low quality work.

View all my reviews

Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo
My rating: 4 of 5 stars

The book is targeted at Agile management of software development teams but the ideas within it are not specific to them. It is written in a mixture of anecdotes, theories from scientific papers and practical approaches you can take. The target is to present a model which has 6 “views”; Energise people, Empower teams, Align constraints, Develop competence, Grow structure & Improve everything. Here are the things which I noted from each of these views.

Energise people – Innovation is the key to survival for a company, and innovation is the combination of information, knowledge, creativity, motivation, diversity & personality. Here people are key to the system, and people are complex. To energise people they need a creative environment which is safe (where people have freedom and can take risks without consequences), has games (allow people to practice their creative talents), is variation (routine kills creativity), visibility (show off creativity breeds more creativity), on the edge (challenges should be a little scary). Traditional management used extrinsic motivation, e.g. target driven bonuses, however these reduce creativity. Instead creativity is best when it comes from intrinsic motivation. Intrinsic motivations are to feel competent, to be accepted, curiosity, honor, purpose, autonomy, order, influence, social contact/relatedness & status from challenging work, achievement, personal growth, recognition & responsibility. Additionally “hygiene factors” such as job security, salary, working conditions, etc – these don’t motivate people but there absence does demotivate people.

Empower teams – No one person can comprehend an entire project, this is why at planning and daily stand-ups the entire team need to be present. As such the team is the best place to make decisions, not some manager since the team has the most information and understands it the best. As such empowering the team produces both the best results but also allows a company to grow. Telling people what to do just builds up motivational debt, but asking empowers people for their input and sometimes results in a better idea as well as the work actually getting done. Additionally a manager should not step in to make a decision but might help the team make their own decision – the worst thing a manager can do is to think “If I want a job doing properly do it myself” as this just obliterates the empowerment of the team. People or teams can be empowered for different tasks at different levels. The proposed levels go from management take control through to the team take control, these being Tell, Sell, Consult, Agree, Advise, Inquire, Delegate. For different people and different tasks they might have different levels (e.g. spending < £500 might be an inquire but for people in their first 3 months this might be at the consult level). There are different levels of maturity for empowered tasks from the low maturity level with little risk for the company, this could be things such as coding guidelines or internal workshops; through to moderate maturity which would be things such as self-organising the team, getting people involved in interviewing others for the team or potentially developing a new business model; up to a high maturity level where people determine their own salaries, choose their own projects or job title. Sometimes you would not empower an individual to do something but you might empower the team, so collectively they are responsible. Empowerment is built on trust & respect; between a manager and the team, team and a manager, within the team and within yourself – it needs to be built. One way to build trust is to be open and visible, if you tell people as much as possible (even if you think it might not be relevant) then they will do the same and build trust further.

Align constraints – Manage the system, not the people. So we now have a group of creative and empowered people and teams. There are always boundaries, and these boundaries should be tweaked and refined to get the desired outcomes from the team. The role of a leader is to develop the self organising system, protect the system & direct the system. Directing the team is to give it purpose. People have three types of purpose intrinsic, extrinsic and autonomous. The intrinsic purpose of a software team is to create software – without this the team no longer exists. The autonomous purpose for the same team might be to develop “clean code”. The extrinsic purpose is imposed by a leader, and this can be for the individual team or company since it is only the leader who can is responsible for the whole system. This extrinsic purpose(s) is the long term vision, for the product the team and/or company as well as the short term mission. These statements should be understandable, concise, memorable, ambitious, actionable, useful, plain, tangible, excitable, and inspiring. Again, a purpose linked to a reward will likely restrict people and reduce creativity.

Develop competence – Growing competencies is key to systems improving. There are multiple ways to grow competencies – self directed, being coached (this does not need to be by a manager), certification (the certificate only attests to your ability at a point in time but the process of certification will give you learning targets), tools (such as check lists), peer review and feedback, supervisors (to check quality), management (to check compliance). Care has to be taken else you get a “what you measure is what you get” approach, and if this is of a sub-system the optimisation of which might be bad for the business as a whole. The dimensions which contribute towards the project are functionality, quality, tools, people, time, process & value so these would give a more holistic view of progress but should be measures at the highest level which they make sense. Competency is a mixture of skill and discipline. Skill is missed out of the agile manifesto, and following which craftsmanship or mastery has been an important topic. Discipline is things such as task board up to date, meetings start on time, code coverage, etc. Skill and discipline are deliverables, where as knowledge or experience is theoretical – people should be rated on their deliverables not on the theoretical. Where possible use relative ratings – how much better are things than the last time, not just how good are things. As with all of agile, people should get feedback quickly. The people who work closely together should provide feedback – not managers who do not work with people continually.

Grow structure – With people being the core of the system, communication is the key to success. Communication is tricky as different people interpret the same thing differently – it is a combination of information, relationship and feedback. Since relationships are key to this whenever a team is forced together the communication will start poorly, as such keeping a team together (even if the project change) is beneficial. Where feedback between team members is poor the communication suffers and the result is unpredictable. The structure of communication should impact the structure of the teams – where communication within the team should be the primary communication. Communication from outside of the team will always be needed but this should be at a slower pace. This has impact on the decision between forming a functional or cross-functional team. Where communication is mostly within a function then a functional team is more optimal but where the communication with with others then a cross-functional team is more optimal. This might also change over time, and it might be worth seconding someone from a functional team to another team to ease communication. Since each team optimises for its own process it is possible that, for example, a functional team might optimise its process so the function is very efficient but this might not be efficient for its users – as such each team should be a value center with other teams as valued customers. For inter-team communication there are two approaches – where all communication goes via management or where teams talk directly. It is mostly the case where teams talking directly is best because of bottlenecks which going via management introduce. The ideal team is one of 3-7 people where members compliment each other in such a way that they get the job done quickly – this is only possible by having a diverse team. It has also been shown that the product developed is a reflection of communication structure of organisations – e.g. have 2 teams working on a compiler and you will get a two parse compiler. So the team needs to be adapted to the product which is being developed. To keep people interested their role should change regularly, so it is best to keep job titles broad to allow flexibility. These broad titles help informal leadership – everyone in the team should take on whatever is needed for the team to function best be it leadership or development. To facilitate this generalised specialists (T people) aid in the team members being able to take on any task required. Build on the communication by connecting people to build relationships and improve communication.

Improve everything – A system is a success until it is not, the best we can do is delay failure – a system has to change to be able to keep up and delay its end. For a system to be changed it has to take into account the current environment the system is in – simply repeating someone else approach to solving a problem will not yield the same results for you as it did for them. Systems can adapted but they also need to explore new ideas as well as anticipate potential shifts – these should be continually being reevaluated to maintain change and prevent failure. The model presented identifies the following steps to improve the system; identify the problem, define the goal of the change, define success metric, identify the improvement, implement the improvement, collect the metric, analyse the results, distill learnings and loop again. This can reach the best peak for this mountain but it might not be the peak of the maintain range – taking radical jumps from one mountain to the next might not land you in the idea place but you can improve from there to get to the top. People naturally don’t like change and sometimes the environment needs to be changed to encourage people to try things. To prevent stagnation it is important for teams to try out new approaches to see if they improve things for them – sometimes even by imposing a little pain for stagnation, this then gets teams to want to improve themselves to reach the next peak. There are three strategies for optimal performance. Changes and improvements to existing practices. When starting new projects try out taking the best solutions others teams are using and see if the combination results in a better result. Increase inter-team communication to spread ideas which teams might then pick up on and use. Some tools for doing this are using retrospectives, improvement backlogs, use catalysts to encourage change, improvement community.

View all my reviews

Sort Your Brain Out: Boost Your Performance, Manage Stress and Achieve More by Adrian Webster
My rating: 4 of 5 stars

An interesting book highlighting that the brain is always changing, and that providing it with new challenges and through a healthy lifestyle it can continue to evolve and take on the continuous challenges which we throw at it.

My personal take aways are how rest and sleep are as important to the brain as taking in information and that by continuously stimulating our brain we are actually suppressing the output which it is generating. Not only does this get explained, but some tips are provided on how to actually use this to your advantage if you are trying to tackle a particularly challenging problem.

Additionally the book looks at stress and how it is both a bad but also a good thing – it goes on to explain how managing stress can actually use it to your advantage and that there are ways to reduce the stress levels in your body.

View all my reviews