Requesting and receiving feedback is crucial for an IT leader.  It is too easy to think we are doing an excellent/terrible job when the truth is quite different.  We discussed with Idan Manor, that feedback is also an effective way of managing 'Imposter Syndrome':

How to ask for and receive feedback as an IT leader? Ask people below, above and around you, display the behaviour you want.  Seek both casual and formal feedback.  LISTEN!

Just because people are not complaining doesn't mean that they have no complaints.  In many societies and cultures, it is difficult for people to give criticism or feedback.  Giving feedback is even harder when you are their boss! Let's look at how we can ask those around us for feedback, how we can digest that feedback, and how we should react/act on that feedback.

Demonstrate the Behavior You Want

To provide honest and  constructive feedback, one needs to ensure the feedback is:

• specific and as close as possible to an event
• given in a safe place in an appropriate setting and time
• not judgemental or personal
• constructive and actionable

The more quality feedback you provide to people, the more trust you build, the more likely you are to receive quality feedback from others when you ask for it.

Just because you ask someone for feedback, even when done emphatically and sincerely, doesn't guarantee they will provide you with the kind of feedback you need.  If someone doesn't feel safe and that their feedback won't be heard, why would they bother?  They could lose their jobs, or make themselves open to bullying, so why stick their necks out.

If you provide genuine and quality feedback to your team and also demonstrate a favourable and constructive reaction to feedback given, then you will likely build the trust and safety enough to allow others to provide you with the feedback you need.

If you demand feedback from someone, and they don't feel safe, then they will give you feedback.  However, this feedback will probably be very superficial.  I am pleased when someone who is not in a position of power, gives me feedback that makes me feel uncomfortable.  It shows that they feel safe enough to touch on difficult subjects.

When receiving feedback, try to:

• Listen
• Reflect
• Respond

Listen, even if you want to react.  If the feedback is painful, your instincts will be to defend yourself.  If it is coming from a superior, you will want to prove you are right and haven't messed up, if it is coming from a subordinate, you probably feel like your authority is being challenged.  STOP, breath, listen.

Listening is not just about being quiet.  Listening is also about asking lots of questions to clarify your understanding of what they are saying. Don't think about how you are going to argue point X or try and catch them out, or think about how you are going to respond.  Just focus on listening, making sure that you clearly understand what they are saying, and they are satisfied you have heard them.

If the feedback is particularly tricky or hard to digest, it is perfectly fine to continue the meeting at another time.  Make sure they understand that you value the feedback and want to continue the conversation, i.e. "What you are saying is important, and I need to reflect on what you have said so far.  Can we meet again on Tuesday at 10 am to continue the conversation?"

Reflect on what has been said with an open mind.  You need to show enough respect to the person giving you the feedback to seriously consider what they are saying.  If it is a subordinate, they are risking a lot giving you feedback they probably know you will find it difficult to digest.  Reward that bravery and trust by seriously considering it.

Some people can abuse the trust and use negative feedback as a tool to erode your self-confidence and manipulate you.  But these people and behaviour are not that common, and the rewards of trust and respect far outweigh the risks.  That being said, if you feel that the feedback is not genuine, then be careful.

When you are reflecting on the feedback, try to understand the context.  You may be surprised and think "That was not my intention at all!" But what is important is what was seen/perceived.  You may not have believed you were angry, but if you were seen shouting at someone, or it was perceived that you were aggressive, then it is crucial to try and understand why.

There may be a cultural misunderstanding; what you consider as talking, in this office/context is considered shouting.  There may be leaking for other parts of work/life, i.e. you may be dealing with a family issue which has affected your behaviour at work, and you may not even realise it.

You can also ask the person giving you the feedback if you are in the right frame of mind, questions like:

• "What do you think I could have done differently?"
• "Why do you think people reacted like that to my comment?"
• "What would have been the best outcome for that situation?"

Respond by thanking the person who gave you the feedback.  If this was a subordinate, it takes a lot of guts to tell your boss something you think they need to hear.  If it was a superior sharing their observations then be thankful too, they didn't need to do that so show you value their time and effort.

Remembering that impression is more important than intention if you realise that the negative feedback is due to a misunderstanding, don't forcibly argue.  It is essential to try and understand how the misunderstanding came about how it can be rectified and avoided in future:

"I didn't mean to make Sam feel unappreciated yesterday at the team retro.  How do you think I can clear things up with him?  What could I do to try and understand his input to the team better?"

It is vital to finish off by coming out of the meeting with a clear idea of the next set of actions.  Feedback is much more useful if it is actionable.  Being told that you are seen as disorganised is not as helpful as "You are seen as disorganised, maybe try writing down all the things you want to call out at standup on a card and run through that for the next two weeks.  Let's meet again then and see how that went."

Types of Feedback

There are two types of feedback:

• Positive
• Negative

Positive feedback is usually a compliment or encouragement.  It is used to help promote the behaviours you want to see more of or to help someone get comfortable enough to shine.

You can give positive feedback to everyone around you, including your superiors.  Providing helpful observations to your boss can help them understand how to get the most out of you and build trust, i.e.

"I found the agenda you provided with the meeting invite helpful.  We got through a lot of stuff quickly!  If you need any help drafting up the agenda for next week's department catch up, I would be keen to help."

When providing positive feedback, it is vital to ensure your feedback is genuine!  You should treat positive feedback with the same care and rigour you would when delivering negative feedback.

People can be immune to positive feedback.  They may ignore or not accept positive feedback.  Poorly given positive feedback may not register, or even worse, create mistrust "Why is she telling me I am doing a good job when I know I am not?"

Negative feedback is some form of constructive criticism that is trying to stop unwanted behaviour or encourage new behaviour.  It is usually hard to deliver and digest, and if poorly done, can cause a lot of harm.  If done well, negative feedback can build a lot of trust and foster loyalty.

To try and define good quality vs poor feedback, we can further define feedback as:

• Useful
• Useless

Useful feedback is delivered well, in an appropriate setting and is both digestible and actionable.  Digestible feedback is framed in a way that the recipient has a chance of relating to and accepting it, i.e. "You are the evilest person I have ever know, and you should see who I am related to!" Might not sink in as well as "I understand we have some tight deadlines this month, just giving you a heads up that Sam's kid is in the hospital so she might not be fully focused if you force her to work over the weekend."

Actionable feedback is feedback that the recipient can change.  It is not vague or unachievable, i.e. "You are not very nice!" or "You should grow another 30 centimetres."  If the feedback is around something that is going to be a lot of work to change, then working together on a plan consisting of small and achievable activities might be helpful.  The remediation plan doesn't need to come from the person giving the feedback, but they should still help with brainstorming and listening.

Good negative feedback will help someone come to realise something difficult, which they may have avoided thinking about previously, but also offer the hope and reassurance needed to move forward and beyond.

Useless feedback is not digestible or actionable.  The person getting the feedback doesn't understand what triggered the feedback, what they did that made the issue.  They also don't know what they can do to make things better in a measurable way.

Creating and Maintaining a Safe Environment

Never give negative feedback in public!

If you tell someone something awkward in front of others, they need to save face, and you may create an enemy for life.  Empathise with the person you are going to give feedback to and try and think "What environment/context will make them feel safe?" For some, a quiet table in a coffee shop not frequented by people from work may be right; for others, they may prefer a private meeting room at work.

Beyond a safe environment in which to share one on one feedback, one also needs to strive to create and maintain a generally safe environment at work.

A safe environment is one where those providing the feedback feel confident that their input will be welcome, acknowledged and considered.  They must be satisfied that giving feedback someone might not want, but needs, to hear and won't affect them adversely.

To give someone genuine feedback, particularly a superior who can make one's life miserable, is very brave and should be received with appreciation and respect.  If you demonstrate a healthy attitude to receiving feedback by being appreciative and respectful when people tell you things you don't want, but need, to hear, then you will go a long way to creating and maintaining a safe environment.

Building and maintaining a safe environment includes:

• Being curious
• Rewarding candour
• Showing vulnerability

Be curious and ask lots of open-ended questions.  Focus on listening and not criticising.  If something doesn't sound right, refrain from criticising and instead ask "Why?" in a positive and curious frame of mind.  Keep peeling back the layers.

As you learn more and more by being curious and open-minded, give credit and compliments where they are due.  Be genuine but be generous.  People are usually passionate about there work, so sincerely appreciating what they have done, as individuals and as a team, can build a lot of goodwill that you may need to draw on when more difficult conversations need to take place.

Reward candour by being grateful and gracious when people give you negative feedback, especially if it is not done privately.  You, as their manager, represent the company and sometime you will be a bit of a punching bag.  Don't take it personally and help them to unwind.  Then work out what you (they and you) can do to make things better.

If they are giving you negative feedback that does relate to you then again, LISTEN and once you are sure they know they have been heard, genuinely thank them for the feedback.

Regardless of the root cause of the feedback, whether it is frustration with the company or issue with yourself, you need to work together on actions and a plan to try and fix things.  To acknowledge a problem and then to take steps to remediate it, sends a compelling message.  This message can be re-enforced by regularly reporting progress.

Show vulnerability by acknowledging your mistakes and then trying to be better today than you were yesterday.  If you show your shortcomings to the team you are saying "It is OK not to be perfect" "Mistakes happen when you do stuff" etc., then you are allowing others to talk about their weaknesses and mistakes.

It is much more fun working in an environment where everyone is open about their flaws and supports each other to improve.

The Gap Between Act and React

I remember reading in a Stephen Covey ("7 Habits of Highly Effective People") that we, as conscious beings, don't have to react to our environment.  There is a gap between what happens to us and what we do.  With some, that gap is so small that they react to their environment.  If you work on extending that gap, you can observe what is happening to you and then decide how you want to act.

Owning how we respond to feedback carries responsibility but also freedom.  If we feel upset about what someone has said to us, we need to stop and think:

• Why is this upsetting me?
• What is the best way for me to respond?

This strategy is not just useful for negative feedback, but can also be appropriate for the positive feedback.  We don't want to make someone regret complimenting us.

Asking for Feedback

Firstly, you need to think about who you want to get feedback from?  The answer should be EVERYONE :-)

You can request feedback from:

• Those who report to you (you can go down a few levels)
• Those above you (you can go up a few levels)
• Colleges in the same team/group
• Colleges in other teams/groups
• Vendors, suppliers and external contractors
• Customers

When asking for feedback, consider:

Be specific rather than be general.  If you ask someone for feedback that might not jog their memory or help them understand what you want.  Instead, talk about something specific like "How do you think the team reacted when I presented our Vision and Mission this morning?"

You can be unspecific about the period if you are specific about behaviour/pattern, i.e. "Do I tend to talk over people?"  You can then try and work out when you did that and what the triggers and warning signs may be.  I tell a college it is OK to kick me under the table.

Ask for recommendations rather than just feedback.  Feedback might make some people feel uncomfortable because they have to talk about your behaviour.  It can feel personal and none of their business.  Asking for a recommendation can be more comfortable.  You are just asking for a tip or two, and it doesn't have to feel judgmental.

However, after you have got a few recommendations from a range of people, you can probably start to see some patterns of behaviour you may need to change.

Ask for both positive and negative feedback "What do you think I did well in that meeting?" "What do you think I could have done better?"  People might find it less confronting to give you positive feedback.  Once they are comfortable giving you feedback, then you can ask them to tell you something not so pleasant.

I think positive feedback is underrated; therefore, not used enough in the workplace.  Positive feedback is not a compliment but specific feedback about a behaviour.  As long as it is genuine and useful, then it can go a long way to helping foster high performing teams.

Why Seek Feedback?

"Great leaders are great learners."

Your role, as a leader, would require you to give a lot of feedback, but you can get away with receiving very little, especially with those who report to you.  Seeking out feedback gives you more opportunities to practice receiving feedback.

Being good at receiving feedback can help you be better at giving feedback.  On a practical level, it enables you to empathise with people who you need to provide feedback to.  You get to experience being on the other side of the table and get a feel for what works and doesn't work.

It is important to remember that what works for you might not work well for others.  People have different personalities and cultural backgrounds, so you need to be sensitive.  A great way of gauging how well you are delivering feedback is to... get feedback :-)

Another reason to seek out feedback and work on being good at receiving feedback is that it builds trust.  If you have taken on board and worked through feedback given to you by someone, then if you need to provide them with difficult feedback, they will likely be more open and accommodating.

Related Questions

What is feedback?  Feedback is some observation or advice provided to someone to help encourage or eliminate particular behaviour.  It should be specific and given in a safe place as soon as possible.  Quality feedback is actionable.

What is the feedback sandwich?  Feedback sandwich refers to padding negative feedback with positive feedback before and after.  For this to work, the positive feedback needs to be genuine, and the negative feedback needs to be useful.  The initial positive feedback can build trust/repore, preparing the recipient for the well delivered negative feedback, and the final positive feedback can act as encouragement.

We recently interviewed Idan Manor, a senior IT manager, and discussed techniques and tools for leadership.  Idan mentioned that he used the GROW model during one on one (1:1) sessions.

How do you use the GROW model when conducting one on one meetings?  As a leader, you want to help your team develop, and the GROW model can help you have structured coaching sessions with team members.  The model revolves around setting a goal and then thinking deeply about how to achieve that goal by asking lots of open-ended questions.

Let us explore the GROW model, and discuss how to use it when running one on one meetings.

What is the GROW model?

The GROW model stands for:

• Goal
• Reality
• Options
• Way Forward

Note: Some models have a separate "Obstacles" phase, but I like rolling the Obstacles discussion into the Reality phase and keeping the abbreviation simple.

Setting the Goal

In a one on one meeting, the discussion starts by establishing a goal for the team member.  This goal can't be your goal but has to be something that comes from, and resonates with, the person being coached.

It is OK to help the team member brainstorm suggesting:

• What areas in their professional life do they want to strengthen? i.e.  I want to be more comfortable when I have to present to the team.  I want to be more confident about the quality of the code I write.
• What skills do they want to learn/improve to help build their career? i.e. I want to get certification X.  I want to be able to contribute to architectural discussions.
• What habit/behaviour would they like to change? i.e. I would like to listen more.  I want to get to work before 10 am.

Ensuring the Goal is SMART

The goal is central to the GROW model.  With a well structured and achievable goal, the rest of the GROW steps are much more manageable.

The classic model for setting an effective goal is SMART:

• Specific
• Measurable
• Achievable
• Relevant
• Timed

Specific

The more specific a goal is, the easier it is to measure, decide whether it is achievable, ensure it is relevant to other goals/vision and to determine a realistic time frame.

So rather than setting a vague goal like:

Get fit

Think about what getting fit means to you at this time.  What made you want to get fit?  Maybe you tried going on a run with a friend and couldn't keep up, so a more specific goal might be:

Run for 3km without stopping

Or you may have taken your blood pressure and realised it is a bit too high.  Your overall goal maybe something like:

Reduce my Systolic pressure to below 120 and Diastolic pressure to below 80

Even though this goal is specific regarding results, it doesn't tell you what you need to do each day to achieve it.  You may create some subgoals that, if you accomplish them, will help you complete the top-level goal:

Lose 10kg

Establish a habit of running 30min a day

For ideas on how to reduce your blood pressure check out Mayo Clinic's "10 ways to control high blood pressure without medication"

Check out our article on "How to Measure OKRs" to see how to structure goals.  The 'goal' "Reduce blood pressure..." would be an Objective which could have reducing weight and establishing an exercise routine as Key Results.  If we achieve the Key Results, we hypothesise that the Objective will be met.  If not, then we can try a different set of Key Results.

Measurable

You must not only be able to tell whether you have achieved the goal but also gauge how far away you are from reaching it.  A vague goal, which is hard to measure, is easy to neglect.

Having a measurable goal allows you to not only have a satisfying sense of accomplishment when you have undeniably achieved what you have set out to do but can also gives you a sense of satisfaction when you have haven't reached your goal but can see that you have made progress, which can help you continue to work towards achieving your goal.

Achievable

"Thus it is that in war the victorious strategist only seeks battle after the victory has been won... " Sun Tzu, 'Art of War', Chapter IV:15

It is crucial to settle on goals that are realistic and achievable.   If you work at unattainable goals, you will eventually give up in frustration or may even cause yourself harm.

Life is a race only with yourself.  Take the time to build a rhythm, building on small successes rather than being crushed under an enormous failure.  Don't stress about getting your first goal right; this is not the only goal you will set in your life.  Hopefully, you will regularly set and reach your goals, slowly and steadily building momentum as you move slightly out of your comfort zone each time.

As you get better at setting and reaching your goals, what you will correctly consider as achievable will expand.

Relevant

We can only ever hold one or two long term top-level goals at a time.  We may also have established a life vision or have an idea of where we are trying to steer ourselves.  You may have a vision of being a successful entrepreneur or an amazing parent.

When you set your goals, you have to make sure they don't contradict:

• your top-level goals or vision
• other goals you are working towards

If you are trying to lose weight, then maybe competing in an eating competition may not yield the best overall results.

Relevant goals also have context and a clear Why.  This goal, if I achieve it, will help me do X, which would help with Y.  If your goals align and you clearly understand why you are doing them, then it much more likely that you will stick at them, even when things don't go smoothly.

Timed

Goals should be time-bound.  It is easy to neglect a goal that is not framed with an end date.  A goal like "I will lose 10kg" can always be postponed till it becomes meaningless as opposed to "I will lose 10kg by the end of Winter".

If the end of Winter is twelve weeks away and you have already lost 4kg, then you know you need to lose 0.5 kg a week, on average, to hit your goal.  Always be safe!  If you get close to the end of Winter and you can't get the last 4kg off DON'T starve yourself!  It is OK to adjust your goals.  Pat yourself on the back for getting as far as you have and then adjust the goal.  Give yourself another three months to lose that last 4kg in a healthy and sustainable way.

Taking Stock of Current Situation (Reality)

With the goal now established, it is time to work through the practicalities of how to achieve it.

Firstly we look at the current situation, the Reality.   The current reality is where the client is now. What are the issues, the challenges, how far are they away from their goal?

Our view of the world is always distorted.  What we think of as 'true' is merely a construct based on our internal model of the world.  This view of 'reality' may still be useful or not useful.  The Reality phase aims to try and help the person being coached to establish a helpful and healthy view of reality.  This reality is then used as the basis for the rest of the GROW model.

You can help the person being coached by asking open questions like:

• "Tell me about what is happening now?"
• "What barriers or obstacles will you face?"
• "What has prevented you from achieving this goal in the past?"

TIP: Never judge the person you are coaching or their situation.  They need to feel safe to come to the realisations they need.  Your job is to facilitate their journey, not to judge them.

The questions above are great conversation starters, but the core issues/blockers/shift in perception required usually lie deeper.  Using a technique like the 5 Whys can be very helpful.

In the context of a one on one meeting, the 5 Whys is merely asking "Why?" five times for an open question.  Ensure the person being coached understands what is happening and that the whys are not there to annoy them but to try and find the root cause/belief.

As a manager in the same organisation as the person being coached, you probably have some valuable insight into what problems that person needs to overcome and what value/strength they can leverage.

A successful Reality phase should establish a clear picture of what the current situation/environment is like, what obstacles/challenges might prevent them from achieving their goal.

Developing Options

We have a clear idea of what we want to achieve and why (Goal), and we have a good idea of the current situation including obstacles/challenges (Reality), so now we need to explore what Options we have to help achieve the goal.

Options can include physical and mental tools to help, i.e. if trying to improve one's fitness then exploring nearby gyms and learning about willpower models would be helpful.

Options could also include possible support structures and opportunities, i.e. if we wanted to be more confident presenting ideas to the team, joining a Toastmasters group and volunteering to talk at an industry conference would help build support and structure for achieving the goal.

Tools that can help uncover and develop options include open-ended questioning like:

• "What do you think are some available options?"
• "Whats the advantages/disadvantages of option X?"
• "If you didn't have any restrictions or constraints, what would you do?"

While answering these questions, develop a mind map on the whiteboard.  Don't be afraid to go shallow and broad initially and then dive deeper later.  Also, make it clear that there are no such things as silly options, put some outrageous options on the whiteboard.  This helps to come up with creative and out of the box ideas.

TIP: Don't ask multiple questions at the same time.  Ask one open-ended question at a time and ensure the person being coached has time to consider the question and answer it fully.  The less talking you do, the better :-)

A productive Options phase should provide a list of viable options with the ones that are easy to implement and deliver the most value at the top of the list.

The person being coached should also have a clear idea of what they need to do to take advantage of these options, and their progress can be tracked at future one on one meetings, i.e. if they want to join a gym then that can be broken down into steps like 'Develop a list of criteria for gym (cost, accessibility, locker storage and swimming pool)', 'Find five closest gyms and visit' and 'Join best gym'.

Way Forward

We have a plan.  We know what we need to to do to achieve the goal.  We now need to shift into action.

Thinking through what needs to be done, how you will do it, and how you will feel when it is done, can help move one into action.

Discuss questions like:

• "When are you going to start?"
• "What are you going to do and when?"
• "Who can help you?"
• "How can you improve your chances of doing it?"

TIP: Do not ask leading questions which indicate the answer you want.  It is easy to get impatient and push the person being coached into saying what you want to hear, but this is not helpful.  The person being coached is going through their own journey and need to arrive at answers that resonate with them.

Try and encourage the person being coached to start small.  You want to build a habit of working towards the goal a little each day.  It is better to be consistent and chip away at the goal a little each day, especially if the goal is trying to work on a habit.

Starting small and building on small wins builds momentum.  What you may find is starting slow results in more significant momentum later on than going all-in from the start.

A successful Way Forward phase of the GROW model will leave the person being coached with a sense of confidence and excitement.  They know precisely what they need to do and when to achieve their goal.  They are chomping at the bit to start!

Don't Rush the Process

When running one on one meetings, it is best not to let them drag on too long.  Thirty minutes to an hour maximum!  Running an entire GROW process would not be realistic in such a short time frame.

However, the GROW process can benefit from periods of reflection between sessions.  The subconscious needs time to digest and consider, so setting some homework between one on one meetings would be advantageous.

In your initial meeting, you can take the person being coached through the GROW model and explain to them how it can help them.  Go through setting SMART goals and ask them to reflect on possible goals that resonate with them (would help in and out of work).

You can set homework like generating mind maps, creating various option assessment artifacts or researching before relevant phases.

Don't make homework a hassle.  Start with simple tools that require minimal effort, and as they get more engaged, you can slowly increase the sophistication and needed work.

TIP: This is a coaching session, so the less talking you do, the better.   Don't force uncomfortable silences; you can ask open questions and make suggestions, but if you find yourself yapping, stop.

Related Questions

What is a one on one meeting?  As a manager, you need to not only look after the team but also the individuals that make up the team.  One on one sessions are regular meetings you have with each individual in your team.  They can be conducted weekly or fortnightly and go from 30-60 minutes.

What is WOOP?  WOOP is similar to GROW and stands for Wish, Outcome, Obstacles and Plan.  It allows one to not just think about what they want to accomplish but also what issues may arise and how they might solve them.  This mental preparation can help people complete their goals even when things get tricky.

Having worked in tiny, small, medium, large and extra-large teams, I was reflecting on what size works best.  What I realised is that there isn't a magic number and it depends on several factors.

What is the ideal agile software development team size?  Generally, the number stated at between 5 to 8 people, but the ideal number depends on:

• How many people the team leader can manage well
• The kind of work done in the team
• The age and personality of the team (not the team members!)
• Who is considered part of the team

So rather than setting an arbitrary number, let's discuss what issues maybe affect the optimum team size and how one may be able to increase/decrease it if needed.

Determining the Perfect Team Size

"Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint."  The Scrum Guide

A high performing team can do A LOT of work.  I have been on a team of five, who were running circles around a team of close to 30 people.  At the right size, with the right people in the right context, the whole is far greater than the parts.

However, putting 5 people in a room and expecting them to do the work of 30 people magically isn't going to work (sometimes you are very lucky... but not often).  The first thing you need to consider when trying to work out how big you can make the team is how skilled is the person who is going to run it.

The team lead needs to spend enough quality time with everyone on the team to iron out all the personality issues early, remove any blockers and engage/nurture the team.  This work is on top of any work they need to do managing up and other duties.  We need to balance/consider;
How much time do they need to spend:

• looking after each member of the team?
• managing up? i.e. preparing reports, getting approvals etc.
• working on tasks allocated to the team?

If the team lead can quickly (but still effectively) get through team nurturing duties and they don't need to spend much time on managing up and team's work tasks, then they can look after a bigger team.

The kind of work is also essential to consider.

• Is the work easy to divide within the team?
• Does the team need to handle BAU, project and emergency work?
• Does the team have all the skills needed to complete the work assigned to them successfully?

These factors impact how large/small the team can be or what work to allocated to them.

Another aspect to consider is how well established is the team and are they an open or closed team?  If the team have been around for a while and have developed a friendly and open internal culture, then adding an extra member isn't a big deal.

Finally, when we talk about team size, we need to decide whom we count as being a member of the team.  This decision varies from organisation to organisation and may include people who float between several teams.

Managing Work

The size of the team influences the kind of management and tools used.  With a smaller team, complex processes and documentation may not add much value and cause frustration.  People don't like to do work, which they perceive has no value.

If the team is large, then having too few processes and tooling can also cause frustration and confusion.  I have seen $30 million worth of work managed with Post-it notes and index cards, and it was a mess.

The irony is when I have worked in small and high performing teams, we happily adopted and extensively used ticketing, wiki and source control systems because we found it very helpful.  We didn't have stand-ups, a board or regular meetings like showcases and iteration planning session.  The business stakeholder sat in the same office as the team, and we developed rituals that worked for us.

Team Cohesion

How formal processes in the team need to be, and how large a team can grow can be affected by team cohesion.  If the team gets along well and people like to work with each other, then gradually bringing in new people who gel well with the rest of the team should be successful.

If the team is too large, then people work in their silos with small pockets of collaboration here and there.  Remember that too large is not a magic number.  It could be 5 or 15 depending on many factors.

Once a team has fallen apart, it is hard to bring it back together.  Team activities like lunches and 'team-building exercises' can help but only if the issues that drove the team apart are resolved first.  If a team has drifted away because of an abusive manager or leadership issues within the company, then no amount of team-building can fix the problem until the root cause is fixed.

Ensure there is the Right Mix of Skills and Knowledge

A team should not be so small that the skills needed to complete its work aren't present.  If the team needs strong database skills and no-one on the team has those skills, then one needs to either:

• bring someone into the team who has those skills (making the team bigger)
• move the work that requires the skill to another team
• train the team (not just one person) in the required skill

It is also essential to be aware that small teams do carry a 'bus factor' risk.  How many people could 'get hit by a bus' before the team/company would find it impossible/expensive to keep going.  I consulted for a company where a large chunk of the development team left suddenly, and no one knew how to maintain core systems.  It cost a lot of time and money to reverse engineer the stack.

Large teams can also carry a high 'bus factor' risk.  If there are only one or two people who know how to maintain and extend a system and they leave, then the company can be in real trouble.  It is vital to sit down and work out where risks exist in a team/company and fix them.

An interesting exercise is to ask "If Sam goes on holidays for 6 weeks, what would we have trouble doing?"  This exercise is a good way of working out what knowledge and accesses Sam has that might need to be shared.  It is more pleasant than asking "If Sam died/left... "

Roles included in the team

When we talk about team size, we need to define who is part of a team and what they role/s and responsibilities are.  A simple definition would be anyone who is doing work assigned to the team is part of the team.  However, there is work locating the work, defining the work, reviewing the work etc.,  are individuals who do those task part of the team?

It is also common to have individuals with specialist skills float between teams, i.e. the data expert or the QA consultant.  These people contribute to completing work done by the team but might not be there all the time and may have conflicting priorities.

Some teams are larger than they need to be because of a belief that one role equals one individual.  So there is a BA, QA, Engineers, Architect, IM, DevOps etc.  An individual can take on multiple roles, and in fact, I firmly believe that having people exposed to multiple functions makes them better at their primary role, i.e. having an Engineer do some BA and QA work makes them a better engineer.  The role Iteration Manager can be shared and rotated in the team.

Types of Work can Effect Team Size Sweet Spot

As discussed in 'Balancing BAU and Project Work',
there are different types of work that a team can be exposed to.  Each type of work has its advantages and disadvantages for the team.  BAU work is usually relatively short and discrete work that can be easily distributed amongst the team.  Project work is more involved and requires more extended periods of close collaboration, which might be more comfortable in a smaller team.

Ideally, the team has a mix of BAU and project work, and the people have turns solving BAU, project and emergency work.

Each Team has its Perfect Size.

Depending on the factors discussed above, i.e. leadership, kind of work, team cohesion and skills mix, a team has a natural optimum size.  If a team is too large or too small, then you see signs in the team, i.e. people start working in isolation or people are frustrated and unhappy because they don't have the skills to complete the work correctly.

Just because a team's optimal size is X at a certain point in time, doesn't mean it can't grow/shrink in the future.  If you want to grow the team, then you can proactively work enabling the team to grow, i.e. work with the team lead to get through more team management work and reduce their other duties, change the mix of work going into a team, help the team roll out more formal work management tools and processes etc.

Just remember to be observant and sensitive to the team.  If you try and help the team grow, see how the team reacts and whether you are helping the team or killing it.  You may need to slow down or try something different.  It is hard to get a team to come together and become high performing, and it is very easy to kill a high performing team.

Related Questions

How do you scale small teams to handle large and complex development work?  Each team can be small and specialised, looking after a part of the more extensive system.  Teams need to agree to upfront, how the system components will interact, and how those interactions will be documented/enforced.  Then each team can work on their part of the system.  It is also helpful to have people move between teams, but not so much that team cohesion is lost.

As a manager, how do I look after a large group of people?  If you are responsible for more people than can fit into a single team, then you need to split the group into teams of optimal size.  You then treat the team leads as part of your team, i.e. if there are six teams, then you have the six team leads directly report to you.  If the number of people reporting to you is too large, then you create a middle layer.  No manager should have more people directly reporting to them than they can comfortably manage, usually 5-8 people.

Fear of failure can slow down a company, and in information technology, speed to market is critical.  Traditionally, companies have tried to get it right first time and spent a lot of time and money working on pre-release activities like manual testing.  This front-loading of risk mitigation not only slows down a company's ability to build and releases features and products, but when, not if, a failure happens in production rectification is usually slow and expensive.

How to lower the cost of failure in IT? Firstly, implement tools and processes for business continuity in the event of failure.  Then make sure you can easily, quickly and reliably move code from development into production.  Then ensure there is enough monitoring and alerting in place to quickly notify the team if issues are occurring in production.  Finally, make sure that there are mechanisms in place to easily roll back deployments in case they are not successful.

The technology landscape changes continuously, and often the only way to know what is going to work is to try it.  Lowering the cost of failure enables companies to experiment and learn about their customers, thereby allowing them to build a successful product that solves their customers' needs.

Plan for Failure

I have found in numerous companies that planning for failure is neglected or given cursory consideration.  There is usually a considerable amount of time and expense invested in development and pre-release validation, but working out how to manage a failure of the system is ignored, neglected or forgotten.

There is an attitude that if we invest enough resources and work smart, we can prevent harmful code or a bad feature from reaching production.  This attitude is naive at best and delusional at worst.  New IT products are incredibly complex internally and rely more and more on external systems.  Guaranteeing a new piece of code will behave as expected in the wild is impossible.

So the bad news is that failures are inevitable.  The good news is with some planning and sensible design decisions; they don't have to be fatal.  If an organisation gets good at managing and learning from failures, it can become more resilient to failure and avoid significant failures.

Planning for failure means that we consider:

• How would we know if the system/component was failing? (relying on complaints from customers is not a good look)
• How would we diagnose the issue?  Does the system output enough relevant and contextual information to easily accessible logs?
• Is data being backed up?
• Can we spin up another environment with backed up data?  How long does that take?
• While the system is down, how can the company continue to function, i.e. take orders, receive goods, field requests etc.
• When the system comes back online, how is the system going to catch up? i.e. orders, goods received, and other transactions that were recorded manually while the system was down, now need to be inputted into the system.  How long will that take?
• Who is doing what during an incident?
• How and when will the incident be escalated/de-escalated?  What will happen when an incident changes severity?
• Once an incident has been resolved, how will the postmortem and related activities be conducted and when?

Being good at planning for, managing, learning and adapting to small failures can innoculate you against fatal failures and also improve the quality of your product.

Rolling Forwards

A company must have the technologies and processes in place to be able to easily, quickly and reliably move finished code from a developer's machine to production.  Setting up this pipeline for the completed code is vitally important.  Once it has been established, it can then be enriched and expanded as needed.

Initially, the pipeline may be as simple as a code repository hooked up to a build server, that only tries to compile the code and produces an artifact like a JAR, WAR, RPM or ZIP file.  The artifact can then be manually deployed to production.  Company policy must now only allow the deployment of artifacts produced by the build server into production.

Now that there is a single path into production, more manual and automated gates can be introduced into the pipeline.  You might create an automated test suite and also introduce a manual approval step for any newly built artifact.  Only artifacts that have passed the automated test suite and been reviewed by the test team (approved) can be deployed.

Since the test team only needs to look at artifacts that have passed automated testing, as the automated test suite grows and detects more issues, the test team has fewer artifacts to review.  Eventually, some artifacts will have a rigorous enough automated test suite that the test team rarely finds an issue, and the approval step can be removed for that artifact.

The pipeline can also be expanded to include the automatic deployment of an artifact into production.  So instead of a human needing to copy files and run commands, automate the process and wire it into the pipeline.  As the pipeline does more of the heavy lifting, the time it takes to deploy changes can be dramatically reduced, and the more deployments can occur.

Rolling Backwards

Rolling forwards is excellent, and if there is an issue in production, being able to roll out a fix quickly is very helpful.  However, it takes time to work out what is wrong, how to fix it and then to implement a quality fix, in the meantime, the system/component is down, and people are screaming.

It is essential to think about how any changes pushed into production can be rolled back.  Rolling back code can be hard, especially if the systems and architecture haven't been designed with rollbacks in mind.

Rolling back code is not just about working out how to replace the code with a previous version; you also need to consider:

• how/if to revert the database schema?
• what to do with data generated by defective code and stored in the database?
• what to do about data generated by other parts of the system based on information provided by the defective code?

As complex as this sounds, if one thinks about how to rolling back their code as they write it, they can significantly simplify the process.  Database schema changes can be implemented in rollback friendly patterns.  Components can be loosely coupled to encourage separation of concerns, thereby reducing the blast radius of defective code and allowing for easier rollback.

There are also well-established patterns and tools for helping to deal with poisoned data like Data Lineage.  Data Lineage illustrates the point that thinking about managing failures of your software can help build a more resilient overall system.  Bad data may come from a defective deployment but could also come from external systems too.  Considering nearly all systems rely on data from external systems, being able to handle poisoned data gracefully is a distinct advantage.

Monitoring, Alarming and Recovery

One has to answer "How will we know if the system is not working?" and then "What impact would that issue have on the business?" and then "How will we diagnose an issue with the system at 3 am with people screaming?"

Too often the only users of a system that are considered are the end customers.  However, customers are not the only users of a system.  Other users may include:

• Operations Team
• Customer Service Team
• Back Office Team

Monitoring

Operations Team need to be able to monitor the system/component and know when there is a problem, well before someone in customer service rings them up and tells them people are complaining.  Does the new code emit log messages at appropriate levels (INFO, WARN, ERROR, FATAL) and with sufficient details?

A developer needs to ask "Would this log message give someone enough information to understand what the problem is and how to fix it even if they didn't understand the component well?"  Unless the developer wants to be woken up at 3 am to fix the issue, if they are still at the company/team, then they need to make sure some else can diagnose and fix the issue based on the information they provide.

Customer Service Team needs to be informed ASAP of any system failures and how that might affect customers, so they can field call appropriately, and possibly escalate to account managers if major customers are impacted significantly.

So a dashboard that reads "Voyager component down" isn't as helpful as "Voyager component down - Credit card payment gateway is NOT available."

Monitoring is not just seeing if services are up/down and ports are open.  Monitoring should also be answering "Is business function X working correctly?"  Synthetic monitoring are scripts that emulate a user of a system and answer questions like "Can customers see the catalogue?" or "Can customers place an order?"

Back office team need to know if any component they need to do their job is down.  There are parts of the system that are critical but not customer-facing, like claims processing, warehouse receiving and order management.  The back office team may also need to organise staff and resources when a system has recovered, i.e. they may need to organise staff to input received goods into the system, which are currently being processed manually while the system is offline.

Alarming

Getting alarms working well takes time and tuning.  You need to consider:

• When to raise an alarm.
• Who needs to be notified.
• How they should be notified
• When/how to escalate an alarm.
• How an alert/alarm becomes an incident.

Alarms can be raised when a single event happens, i.e. a service is down, or they can be raised only when a series of events occur within a set period, i.e. web servers have high memory and CPU usage but low network usage (something smells bad).

When an alarm is raised, ideally, the person who gets the alarm can either a) resolve the issue or b) understand who needs to be called in to resolve the issue.  When handling an alarm, non-technical people may also need to be involved, i.e. someone from marketing may need to put updates on social media platforms.

How an alarm is raised needs to be considered.  If it is 3 am, sending someone an email to respond to a critical alarm will probably not get them out of bed.  On the other hand, you don't want to have a robot phone call pulling them out of bed at 3 am for a minor alarm.

The duty of responding to alarms needs to be shared; otherwise, people will get burnt out.  When working out a roster, it is important also to identify escalation points and contacts.  The primary duty person may be busy resolving an existing alarm or unavailable, so a secondary needs to listed who can also field alarms.

Not all alarms result in incidents, and if an incident wasn't raised by an alarm discuss in the postmortem.  Understanding when an alarm should be escalated to an incident and at what severity is essential to decide and clarify before an incident happens.

Recovery

Generally, there are two states of system recovery after a failure.  Initially, the system needs to be brought back to a state where it is available.  So, for example, the system taking care of accepting customer orders is now back up and can handle new orders.  Having restored the order system is great and will relieve some pressure, it is not over yet.

The system also needs to be fully restored.  While the order system was down, the business continued, and orders were either taken manually, or sales have a list of people to call.  Until the old orders have been uploaded into the system, the system has not been fully restored.  Customer can't enquire online about orders that are sitting on a piece of paper.

Another aspect of recovery is that of automated recovery.  Automated recoveries may be triggered by internal activities like deployments or external factors like increases in activity/load.

If we have automated deployment of code (roll forward) and automated rollback of code, and we have adequate monitoring.  Then we can craft a solution that can detect if a deployment has caused issues and then attempts to roll back the deployment automatically.  It should be noted that not all deployments will have a clean rollback process so developers might need to mark which deployments are safe to roll back automatically.

With cloud-based platforms, we can script recovery routines.  So if we detect that we may need more web servers to handle the increased load, we can have the recovery run automatically.  One needs to be careful and ensure there are hard limits otherwise you may be paying a fortune to scale up a Denial of Service attack :-)

The Virtuous Cycle of Managing Failure

With proper planning and processes, smooth and automated deployments, adequate and trustworthy monitoring and alerting, and roll back tooling and processes that work the cost of failures can be kept in check.

When something goes wrong people don't have to panic.  Everyone knows what they need to do, and if things don't go smoothly, there is now a framework to store this tribal knowledge for next time.  Having a framework for managing failure is very powerful because people can shift into proactive problem-solving mode rather than drowning in panic.

Even better, as you get good at detecting and recovering from failure, you may find that you can recover from a failure before customers notice and if a tree falls in the forest and no-one has heard it...

If failure is no longer fatal and is becomes quite cheap, then we can be more courageous, try new things, and when we do fail, dust ourselves off and try again saying "Interesting, learned something new."

"Would you like me to give you a formula for... success? It's quite simple, really. Double your rate of failure."  Thomas J. Watson

Related Questions

How can we measure failure and recovery in IT? To understand if we are getting better at recovering from failure, we can measure our MTTR (Mean Time to Repair/Restore).  As we get better at repairing (bringing a system back online) and restoring (getting a system back to a pre-failure state with offline work uploaded) we should see our MTTR go down.  We can also keep track of our MTBF (Mean Time Between Failure), which should increase as we mature.

Should we be using time as a variable when calculating MTBF?  Unless your system has a consistent load and runs 24/7 then maybe measuring Mean Time Between Failure is the most useful metric.  Measuring a transactional activity may give a more useful picture, i.e. Mean Number of Orders Between Failure.

The struggle is to balance the pressing short term needs of the business with the more strategic medium to long term strategy/goals of the company.  I have worked on development teams that have got bogged down in Business as Usual (BAU) work and other development teams that have got lost, by focusing only on project work.

How to balance BAU (Business as Usual) work with project-based work?  The right balance between BAU and project-based work continually changes, but neither should ever be neglected for too long.  Too much BAU work can limit the vision of the team and lead to the team fixing symptoms rather than root causes, exposing the business to strategic risks.  Too much project work can disconnect the team from customer and business problems/needs.

Doing BAU work has advantages and risks, just like project work. Let's dive deeper into what we mean by these terms and how to recognise when we might need to adjust the kind of work the team is engaged in.

Defining BAU and Project Work

Before we talk about balancing BAU and project work, we need to clarify what they mean.

Business as Usual (BAU) work is the work that you didn't know you were going to do at the start of the day/week/month plus the routine work your team does all the time.  There is no business case, budget or oversight from PMO/project manager.  Depending on the maturity of your organisation, BAU work should not exceed a specified amount of effort, i.e. if the "BAU" work could take six weeks of effort, then it needs to become project work.

Examples of BAU work include:

• Generating regular reports for the broader company
• Preparing environments and portals for onboarding of new customers
• Preparing demos for presales work
• Fixing minor issues
• Helping Customer Service team with customer enquiries

Project work is work that is planned.  It has gone through various gates to ensure the work has value, and everyone knows why we are doing it and what the expected outcomes will be.   Project work tends to be larger and more involved than BAU work, so internal and external resources and budget need to be organised and approved.

Examples of project-based work:

• Product Development
• Transformations and uplifts
• BAU work that requires more resources and rigour than usual, i.e. onboarding of a significant client.

The team that delivers a project may be formed for the project and disbanded afterwards.  For this article, we will assume that the team is long-lived and does both project and BAU work.

Balancing BAU and Project Work

Too much BAU work can lead the team into a state where:

• Becomes stuck in a local optimum
• Understand the customer's problems but also listens to their solutions

When we do BAU work, we develop a great sense of purpose.  Each day brings immediate challenges that can be quickly resolved and satisfy an internal/external customer's need.  After knocking over these short term issues, we go home with a sense of accomplishment and satisfaction, which can become addictive.

Focusing on only short term works means we could get stuck in a local optimum.  We get better and more efficient in our area but, because we are only looking around our small patch, we may be missing a much better opportunity.  We may also be unaware of changing market/competition.

Mixing in some longer term project work where the team can reflect, experiment, deliver and review can help them see beyond the local optimum.  In information technology, using the right tool, framework or methodology can save an enormous amount of time.  The technology landscape is continually evolving, so devoting a bit of time to try something new can yield massive benefits.

Another danger with too much BAU work is developing such a close relationship with customers that you not only listen to their problems but also listen to their solutions.  Each customer will have their ideas about how to fix their problems and getting lost in that forest usually ends up either a very fragile, monolithic system that is trying to do everything for everyone.  Or an unwieldy number of unique systems, one or more for each customer, that become impossible to maintain and improve.

Too much project work can also be hazardous.  I have worked in several companies where we went from one long term strategical project to another, burning money and opportunities as we went.  Because we didn't spend much time with the customer solving their problems, we either ran out of money before we could deliver or delivered a system that eventually got turned off.

It is too easy to think you know the customer, you understand their problems, and you know what they would like you to do.  But until you spend time with your customer's and iterate through your work with them, you are making wild guesses.

A balance between BAU and project work is when the team cares about the customer.  Instead of using abstract personas, they talk about real customers.  They love helping the customer but are also dedicated to building a better solution for the business.  They regularly discuss the kind of issues customers are having, operational/business issues and emerging opportunities.  Then the team plan out discrete projects they can work while continuing to service BAU work.

Pushing BAU Work Out of the Development Team

A lot of BAU work is either routine and can be automated or, with the development of some internal/external tooling, be pushed out to other teams.

On one project, senior management wanted daily progress reports.  We spent a day rigging up our build server to generate a flashy report based on the state of BDD tests in the software.  Before a sprint began, we wrote a high-level outline of the functionality that would be developed during the Sprint.  Each business function on the report showed up blue.  Then actual tests would be written for that functionality, which would now come up as red because the code hadn't been written/completed.  When all the code for a business function was written, and tests passed, it would come up as green.

Since developing a comprehensive BDD suite was already a requirement of the project, engineers didn't need to spend any extra time generating the report and management got a URL which they could visit to see progress in real time.

On other projects, we mined systems like Jira and HPQC to generate various required reports automatically.  Most systems have report generation capabilities and APIs, so on a Friday afternoon, you can either put together a script to create the report or at least grab the data and groom it for easier report generation.

Sometimes the team gets bogged down doing ad hoc work for customers or the support team:  cancelling orders in the database, trying to find the state of a consignment, updating addressing information etc.  These tasks may exist because a system doesn't have the functionality available for customers or internal teams to resolve the issues themselves.

Keeping track of how much time is spent doing these ad hoc BAU activities can then help build a case for developing features to facilitate self-service.  If three weeks of work can save one week a month for the team, then that sounds like a good ROI.  It also helps keep the group engaged and focused on building a better product rather than keeping afloat.

Motion vs Progress

It is easy to confuse movement with progress.  The team may have been flat out all week working on stuff.  They had resolved several issues raised by customers and internal teams, so feel it has been a productive week.  But if no work has been done to improve the underlying system or permanently remove some BAU work from the team's plate, then has the team made any progress?

A development team should be striving to remove routine work from their plate constantly.  This work never ends, because as the team adds new features and functionality, new operational work is created.  As a feature proves itself popular and matures, effort needs to be made to remove the routine work it generates from the development team so they can focus on the next feature/product.

Related Questions

What is BAU work? Business as usual (BAU) work is unplanned work that can happen unexpectedly or regularly.  It is usually relatively small and doesn't have a set budget.  BAU work includes tasks like generating a regular report, answering support enquiries or setting up a product for a customer.

What is project work? Project work is planned work that happens for a set period and usually has some dedicated resources and personnel.  Projects have well-defined outcomes and typically have a fixed budget with related oversight.  Project work includes activities like onboarding of significant clients, new product development and system uplifts.

Decisions are something that we have to do many times a day and having a heuristic for decision making can make us much more efficient and effective.  I was researching product development at Amazon when the concept of one-way and two-way door decisions came up.

What are one-way and two-way door decisions? One-way door decisions are decisions that you can't easily reverse. These decisions need to be done carefully.  Two-way door decisions can be reversed.  You can walk through the door, see if you like it, and if not go back.  These decisions can be made fast or even automated.

Even if you have to make a one-way door decision, there are still ways of limiting your risk.  Getting good at recognising what kind of decision you need to make and then being able to make that decision quickly can give you a competitive advantage.

Identifying One-way and Two-way Door Decisions

One-way door decisions are ones that you can't reverse or take too much effort/expense to rollback.  These decisions are usually strategic decisions that require a fair amount of information and deliberation.  Fortunately, one-way door decisions usually don't need to be rushed.

Two-way door decisions are ones that you can rollback easily.  If they don't work out as planned, then you can reverse them and try something else.  Because these decisions don't carry many risks, you can make them quickly.  If they happen often enough, you can even automate them so you can focus your energy on other decisions.

"One common pitfall for large organizations – one that hurts speed and inventiveness – is 'one-size-fits-all' decision making."  Jeffrey P. Bezos

Understanding the difference between the two types of decisions is important because then you can focus on the crucial decisions instead of wasting too much time on the reversible ones.  In many large companies, it is the same amount of paperwork getting approval for $50 as $50,000.

Even when you do have to make a critical one-way door decision, you can lower your risk by:

• seeing if you can transform it into a two-way door decision
• reducing your exposure

Make a One-way Door Decision into a Two-way Door Decision

Sometimes big decisions can seem like one-way doors, but after further examination and creative problem solving, the decision can be turned into a two-way door:

"For example, when we launched Virgin Atlantic I made a deal with Boeing that we could hand the plane back in a year's time if the airline didn't get off the ground. Thankfully, we never had to. But if the things hadn't worked out, I could have walked back through the door." Richard Branson

Framing is another technique to help you to transform one-way doors.  Pricing can be challenging to get right, and it can be quite hard to change without upsetting your customers.  You don't want to discount often to attract business because that will lower the perceived value of your product.

Testing your price with an "Introductory Offer" is an excellent way of letting you feel out the market without committing to a price.  If you think, based on feedback from the introductory offer, that the market could pay more, then you can extend your experiment by expiring the introductory offer and bring in an "Early Bird" special.

You can also use these pricing schemes to help manage expectations while you refine your product.  You can explain that the introductory price is cheap because you are ironing out the content or refining the code, as the product is polished, the price will increase.   This not only gives you some breathing room will refining your product but give customers a sense of urgency.

Reduce Your Exposure When Making  One-way Door Decisions

Sometimes you have to go all in.  If you want to release a new physical product or you need to commit to a legally binding agreement, you need to try and do this with confidence.

Are there ways you can test the waters without risking too much? For example, can you release into a single market where you have enough know-how and penetration to test out the product, but it is not your major cash cow?

Can you presell the product on something like Kickstarter to gauge whether people are interested, customers are ready to pay for it and where your best market might be.  If the Kickstarter doesn't take off, it is easy enough to return everyone's money and try something else.

If you are entering into a contract or planning a critical project, ensure you have some concrete and measurable milestones set, i.e. after X period, if you don't see Y result then have a clause that lets you get out.  Yes, you will lose some cash and time but think of the cash and time you save by not pursuing the project.

Quick Decisions Help You Understand Your Environment

Ideally, we can do some research and get all the information we need to make a decision that is highly likely to succeed.  However, this is not usually the case in our modern world.

Indeed, many people don't do enough research when making critical decisions, but most of those people wouldn't still be reading the post.  So for those of you who DO do their research, you know that the more we learn, the less we know.

When you are playing in an environment where you and your competitors don't know the precise state of the market, those who can quickly try things out, learn and adapt, have a distinct advantage.  If several of you can do, learn and adapt, then the winners are those who can cycle through the quickest.

Being able to recognise what is a two-way vs one-way door decision and then ensuring that company processes align, will not only empower your people to act fast but also to slow down and do their due diligence when faced with one-way door decision.

Being Nimble is About Culture and Policy

In large companies project spending has to be planned out for the financial year and involves so much work to approve that no one wants to say after 8 weeks "You know now that we have done more market research and tested our MVP, this product probably isn't going to fly.  We should scrap the project and focus on something else." Large company projects can't usually pivot like this.

Employees are usually thinking about their jobs and vendors are thinking about their contracts.  For employees, the project budget has been locked in for a year.  As long as they can stay on the project, they don't have to worry about being made redundant.  For vendors, they have fought hard to win the contract, and if this project is scrapped, they have to find more work.

So when a company says "We want to be agile and encourage entrepreneurship" the policies need to be there to allow people to make mistakes, learn and move on.  The culture needs to be one where everyone focuses on the success of the products and company rather than their job/contract.

Related Questions

What is decision fatigue? Like a muscle fatigues from repeated use, so does our ability to make quality decisions.  We need to rest and recharge, ensuring that important decisions are made while we are fresh.  Using heuristics like two-way door decision making, we can focus our energy more wisely.

Do we really make 35,000 decisions a day?  I can't find an experiment/study that proves that we make 35,000 decisions a day.  When I find the number quoted it is referred to as fact or attributed to "various internet sources estimate".  It also depends on what you classify as a decision.  It seems obvious that we don't ask ourselves 1458 times an hour  "Hmmm should I choose X or Y?", especially when we are asleep.

Having worked in successful and unsuccessful digital product-based companies, I have seen digital product development tactics that work and learned a lot from watching others fail.  Pondering my experiences and also reviewing the reflections of seasoned experts like Neha Monga and Dave Wascha, I have compiled the following list of product development tactics for digital products.

What are some tactics for successful digital product development?:

1. Launch Products Incrementally
2. Launch Updates, Releases and Products Often
3. Learn from Your Product Launches
4. Learn from Your Competition's Product Launches
5. One-way vs Two-way Door Decisions
6. Set SKID Metrics: Scale-up, Keep, Iterate and Destroy
7. Always Have a Launch Plan

Digital products are different from physical products.  We expect frequent updates, feature releases and a higher level of engagement from those building/supporting the digital product.  Even if your company sells physical boxes, they still need a digital presence and complementary digital products.  So let's dive deeper into some useful tactics for digital product development.

1. Launch Products Incrementally

You have an amazing vision of what the next killer digital product is, but if it takes five years to launch, then your probability of success dimish rapidly.   For a start, you will need to find extremely patient investors with deep pockets.  In the meantime, your competitors could beat you to market, and you are not even sure if the product will succeed!

It's great that you have a strong vision of where you want to go, you can now work backwards and figure out what you need to do to get there and what you could quickly deliver that gets you closer to your goal.  Each step you take will help resolve some high-risk hypothesis so that the further you go, the more confident you can be about your vision, which has probably been tweaked based on what you have learned.

The sooner and cheaper you can mitigate risk, the more likely you will be to succeed because you will be able to apply more of your resources to activities that have a high chance of succeeding.  A big challenge for companies is to get the minimum in MVP (Minimum Viable Product) small enough.  If you can operate the business with spreadsheets and phone, do that before spending millions on developing software.  Software that gets turned off because it doesn't solve the customer's problem!

The MVP needs to answer a question, and once you have decided what question it needs to solve, then you can mercilessly cut back the MVP back till all it does is answer that question.  If you try and cram too much into an MVP and it takes two years to launch, then you are back to square one.

If your MVP ends up only being a webpage with a form backed by a team of people who will manually process the request, that is FINE!  It is cheap and easy to change the webpage, modify the form, refine your processes or throw it all out and try another idea.

Once you have proven the MVP is a success, then you can confidently spend some more resources delivering the next increment and answer another question etc.

2. Launch Updates, Releases and Products Often

Now that you have split your digital product into lots of small incremental launches that are cheap and quick to deliver, you can launch frequently and regularly.  For digital products, customers expect frequent updates, new feature releases and related product launches.

The more you launch, the better you get at launching.  You get better at not just planning, executing and learning from a launch, you also get better at dealing with issues when, not if, things go wrong.  If you can learn from your mistakes, get good at limiting the effects of failure as well as get fast at resolving issues you will run rings around your competitors, or at least keep up with them.

In the digital product space, to be able to do frequent launches, you need close collaboration between the tech team, operations and business stakeholders.  You all need to collaborate to work out what to develop next, how to build it good enough, and how to support it.  If the feature/product compelling solves a problem for customers, construction and delivery are flawless, but the company drowns from all the back office work, then that limits scalability and future growth.

Building a tech capability that allows for rapid and frequent releases can be expensive and complicated.  The tech team needs to build platforms, tools and processes for things like:

• Source code management
• Build and deployment pipelines
• Automatically scaling infrastructure
• Extensive system and functional monitoring and logging
• Incremental release capabilities
• Reliable rollback mechanisms

However, like the investment in development, marketing and operations need to be done incrementally with each release, so does the investment technology.  As you gain confidence in the product with each successful launch and the customer base grows, then progressively increasing the complexity and maturity of the technology capability can occur.

3. Learn from Your Product Launches

We can interview customers, collect data and make some educated guesses about how our customers will react to the product.  But we won't know what they think about the product until we put it in front of them.  We can then see if they use the new product, do they use the new feature the way we intended and are they willing to pay for it.

Since we now release new features and products regularly, we have lots of opportunities to learn from our customers and refine our mental model who they are and how we can help them.  To find out what our customers think we can:

• use analytics programs like Google Analytics and Clicktale to see their behaviour
• email or discuss the product directly with a sample set of users.
• read comments and reviews on social media
• look at the numbers

"We thought they would love the new feature, but on Twitter and Facebook, they are constantly complaining about it."

"Since we changed the shopping cart layout, we have seen an increase in average customer spend of over 10%!"

4. Learn from Your Competition's Product Launches

If there are competitors with similar digital products on the market, this is not necessarily a bad thing.  We all have different idea and opinions so your competitor will try things that you haven't.  As they experiment, you will also be able to observe.  You won't have access to their internal metrics, but you can trawl social media and review sites to see what their customers thought.

When a competitor releases a new feature, you can review and decide:

• it was a bad idea, let's not do that with our product
• it was a solid idea but poorly executed, let's review internally
• it was a solid idea and well-executed but not appropriate for their customer demographic or ill-timed, let's examine if would work in our product or related product.
• it was a solid idea and well-executed and well-received.  Do we need to implement a version to stay competitive?

Every launch done by your competitor is an opportunity for you to learn something about your market.  They spend all the money and resources developing, marketing and delivering a new feature.  Then you get to learn from their success/failure and continue from where they left off.

5. One-way vs Two-way Door Decisions

Two-way door decisions are reversible decisions.  If a new feature is very unpopular or impacts the business negatively, then we can roll it back.  The work to rollback a feature isn't only technical.  Do we need to inform the customers and if so, how?  Do we need to work with suppliers or vendors who may have built capabilities to service our new product?

One-way door decisions are decisions that are either not reversible or too expensive/difficult to change.  An example, which is hopefully not applicable to you, is a release date that is locked in because "We have already spent a fortune on marketing".  Selling a house, quitting a job and an international release of a physical product are also examples of one-way door decisions.

In the digital product space, we should be able to ensure most of our decisions are two-way rather than one-way:

• Make sure the feature can technically be rolled back
• Ensure marketing and customer service ready for a rollback
• Soft launch products before investing in marketing
• Frame pricing of the product so it can change, i.e.  "Introductory price for a limited time only."

6. Set SKID Metrics: Scale-up, Keep, Iterate and Destroy

Every line of code that exists in production posses risk to the business.  It makes the system harder to maintain (more complexity) and increases the number of attack vectors for hackers.  So if the code is not adding any benefit to the business, it needs to be removed.

Conversely, if the new feature/product is popular, then we may need to allocate more resources or work on creating more content.  Neha Monga described how a game she worked on took off, and she had to get designers to develop more levels quickly.

The SKID metrics and levels must be decided BEFORE launch!  Having agreed SKID metrics before launch helps to formulate a better launch plan and makes it much easier to either get more resources allocated:

"We already agreed that if we had more than 100 orders a day, we would have the headcount for two more people in the Customer Service team."

or shut down the product:

"We agreed that if we only average 40 orders a day, we would roll it back and work on delivering product B.  We are only averaging 25 orders a day."

7. Always Have a Launch Plan

A launch plan helps you sort out what needs to happen before, during and after launch.  You should know what you want to learn from the product launch and have the SKID metrics in place.

A deployment should have:

• Entry Criteria:  What needs to be in place before we can start launch.
• Exit Criteria:  In what state do we need to be for us to say the launch is complete.
• Stop Criteria:  If any of the following happens, we stop the launch and rollback.

The criteria help us generate checklists, which then help us outline activities.   For example, our Entry Criteria may include:

• The customer service team is aware of the launch and is ready to field queries.
• Relevant members of the development team are available during the launch.
• All automated tests are passing and there are no unresolved critical issues.
• Required metrics are collected, are accurate and are reported.

Exit Criteria may include:

• No failures or issues have been reported post-deployment for 2 hours.
• A post-launch debrief has been scheduled for the next day.
• A SKID review meeting has been scheduled in seven days.

Stop Criteria may include:

• Critical issue reported during deployment.
• Deployment couldn't be done within the launch window three-hour launch window.

Related Questions

What is the difference between product strategy and product development? The product strategy outlines to stakeholders how the product aligns with the company's business strategy.  It also discusses what needs to be done other than developing the product, i.e. requirements and impacts on sales and marketing teams.  Product development refers to all the activities that take the product from concept to market.

What are the objectives of product development?  The core objective of product development is to develop a product that solves a problem for customers.  The product needs to be delivered at a competitive price point and of sufficient quality, that a customer is willing to pay for it.  The price is relative to the importance of the problem it solves.

I have worked in many organisations that didn't have Vision and Mission statements or had poorly constructed ones.  It takes a lot of effort to create, communicate and integrate Vision and Mission statements into an organisation, but when done right, there are subtle and powerful benefits.

How can a company benefit from having good vision and mission statements?  Well constructed, communicated and integrated Vision and Mission statements can help align and focus an organisation.  They define in clear, precise and inspiring terms an organisation's reason for existing (Mission) and where it is going (Vision), helping to drive success now and in the future.

Let's explore deeper what the benefits of well-constructed Vision and Mission Statements are and why those benefits may exist.  By understanding what we can achieve with excellent Vision and Mission statements, we will be better able to recognise good Vision and Mission statements, as well as create our own.

Benefits of Vision and Mission Statements

A Vision Statement describes the future state that an organisation is working towards achieving.  Vision is the long term goal of an organisation.  What long term means depends on the context.  For a typical organisation, a Vision may be looking ten years ahead, but for larger firms, or ones that are pursuing more ambitious ends, their Vision maybe twenty, thirty or more years in the future.

A Mission statement describes the organisation's purpose or its high-level business strategy.  A Mission statement should answer the following questions clearly with laser focus:

• What does the organisation do?
• For who does the organisation do it?
• How does the organisation do what it does?

Vision and Mission Statements have no power unless they are shared.  If the Vision and Mission statements resonate only with the authors, then they will not be very effective at guiding and driving the organisation.  Creating the Vision and Mission statements is done from the ground up or the top down or both.   Once created, the Vision and Mission must be communicated, integrated and adopted by all parts of the organisation.

Vision and Mission statements are successful if anyone in the organisation can recall them upon request and does so with a hint of pride.  Then the Vision and Mission can yield benefits like:

1. Guide the Thinking and Actions of Employees

When people are about to invest a lot of time and energy into an endeavour, they want to know they are doing "the right thing".  They want to know their actions will not generate criticism and hopefully garner praise.

If there are clear Vision and Mission statements, the whole organisation has adopted them, and the employee has correctly interpreted them, then an employee can ask "Will this action be in alignment with our Mission?  Will this action get us closer to our Vision?"

Having a reliable way for someone in an organisation to internally validate their thinking and actions means they can focus more of their time on moving the organisation forward rather than worrying about justifying the soundness of what they are doing.

2. Help Determine and Inform Performance Standards

Like guiding thinking and actions of employees, strong Vision and Mission statements will make it much easier to construct transparent and consistent performance standards and measurements.  One can ask "What behaviours do we want to encourage/discourage that would bring us in alignment with our Mission and closer to our Vision?"

Not only can performance tools be aligned to the Vision and Mission, but the performance tools can be used to help align the organisation.

3. Help Attract Appropriate Talent

Clear and easily understood Vision and Mission statements help with hiring in several ways.  Making the Vision and Mission not only public but also communicating them to candidates means that some candidates will select themselves out because they know the organisation would not be a good fit for them.

Since performance standards align with the Vision and Mission, then we know what behaviours, characteristics and skills are needed to help fulfil the Mission and achieve the Vision.  When conducting interviews, interviewers can use the information to guide their questioning and assessment of candidates.

4. Provide Context and Reduce Friction During Organisational Restructures

Organisational Restructures and major reallocations of resources can be very stressful.  However, if the restructure aligns with the Vision and Mission, it can help give some context to the restructure.

When people understand why the change has to happen, and they can see how that change would improve the organisation, then they are going to be more accepting even if it might cause some personal grief.

5. Provide a Stable Framework that can Outlast Internal Changes

Creating a crisp and inspiring Mission and Vision and then weaving it into the fabric of an organisation is hard.  But when the Vision and Mission are an integral part of the organisation they give the company strength and direction well after those who helped create it are gone.

A charismatic leader or founder may leave, or C level management may change, but the company continues from strength to strength.  The Vision and Mission providing an almost spiritual leadership that can help ensure the actual leaders that take over following in the footsteps of those who came before them.

6. Inspire People to be Focused and Productive

The Vision and Mission need to be inspiring.  They need to resonate with everyone in the organisation.  They need to help provide meaning and purpose.  Therefore Vision and Mission can't just be about increasing revenue because that doesn't motivate someone doing their shift in Customer Service.

Once a Vision and Mission have sparked inspiration with the individual, the team and the organisation, then they operate in a state of focus.   Being focused allows an individual and an organisation to channel their energy and creativity into a single and concentrated direction, the Vision and Mission.   It is the difference between trying to push a blunt pencil versus a sharp pencil through a sheet of paper.

7. Facilitate Collaboration with Teams, Customers, Suppliers and Partners

When teams in an organisation have a common Vision and Mission, they can look beyond internal politics and KPIs and can collaborate.  Helping you may cost me, but it brings us closer to our Vision and Mission.

When the Vision and Mission are crisp and inspiring, beyond just those in the organisation, then customers, suppliers and partners can feel part of something special too.  Customers know why they use your services.  Partners know why they collaborate with you rather than a competitor and Suppliers feel proud that their product or service can help you achieve your Vision and Mission.

8. Help with Public Relations

Since Vision and Mission help define an organisation's identity, then it makes sense that the Vision and Mission are an important part of a company's Public Relations strategy.  Who we are, what we do, and why we do it are enshrined in the Vision and Mission, and that is also what we want to communicate to the outside world.

Since the company arranges itself around the Vision and Mission, aligning the company's brand and communications with the Vision and Mission means that there will be consistency between what happens inside and what is communicated outside.  Keeping the company and its public image in sync gives its public persona greater gravitas.

Importance of (Shared) Vision

Kouzes and Posner say that the second characteristic people look for in a leader, after honesty, is vision.  They point out that generally you are encouraged not to think too far ahead, but as you move up in leadership roles, you need to look further and further ahead:

But for a vision to be effective, it must be inspiring, and for it to be inspiring it must resonate with everyone in the organisation.  Kouzes and Posner point out:

Yes, leaders must ask, "What's new? What's next? What's better?"—but they can't present answers that are only theirs. Constituents want visions of the future that reflect their own aspirations.

So whether the Vision and Mission statements are arrived at by a series of workshops with everyone in the organisation contributing, or senior managers craft them at an off-site, they need to appeal to everyone in the organisation.  Kouzes and Posner go on to state:

The only visions that take hold are shared visions—and you will create them only when you listen very, very closely to others, appreciate their hopes, and attend to their needs.

Related Questions

What comes first Mission or Vision?  The Mission is what an organisation is or wants to be now (within two years).  The Vision is what an organisation wants to be in the future.  You can start with either.  Create a Vision and then work back to a Mission, or define a Mission and thought experiment where that leads (Vision).

How long should a Vision or Mission statement be? Vision and Mission statements should be as short as possible.  They need to be understood and easily remembered by everyone in the organisation.  Two to three clear and precise sentences each is a good rule of thumb.

References

'Vision and Mission: Unleashing the power of vision and mission.', Jennell Evans, https://www.psychologytoday.com/au/blog/smartwork/201004/vision-and-mission

'To Lead, Create a Shared Vision', James M. Kouzes and Barry Posner, https://hbr.org/2009/01/to-lead-create-a-shared-vision

'Mission and Vision Statements', Bain, https://www.bain.com/insights/management-tools-mission-and-vision-statements

'The Mission, Vision, and Values statements', 365 Careers, https://www.youtube.com/watch?v=8wem6FZAucw

'Google’s Mission Statement and Vision Statement (An Analysis)', Andrew Thompson, http://panmore.com/google-vision-statement-mission-statement

OKRs are all about measurement, which is what makes them so powerful.  Being passionate about data-driven decision making, I was fascinated by Rick Klau's video about OKRs at Google.  The following are my thoughts on measuring, grading and reviewing OKRs.

How can we measure OKRs?  An OKR consists of an Objective and Key Results.  Each Key Result needs to be measurable and have a target.  The score for each Key Result should fall between 0.0 to 1.0 and is the target divided by the outcome.  To get a score for the whole OKR, average out the scores of all its Key Results

If we set arbitrary OKRs with vague Objectives and Key Results, we could end up with a set of Key Results that can't be completed and Objectives that have an unknown impact on the business.  Let's dive deeper into scoring and grading Key Results and then, using the performance as feedback, discuss how to tune not only the Key Results but also the Objectives.

Measuring and Grading OKRs

OKRs are like experiments where we propose the hypothesis:

"If we succeed actioning the following Key Results, then we should see the Objective move up/down by X".

To run an experiment successfully, we need to be able to measure the inputs, Key Results, and output, Objective.

Each Key Result has to be something that the person, team, department or company doing the OKR can work on directly.  The Key Result must be measurable, and a target set for the Key Result before the OKR is shared, i.e. The sales team will 1000 leads by the end of Q1.  Once a Key Result is established, then its performance can be monitored and, during a review, graded.

Klau recommends scoring Key Results between 0.0 to 1.0, but that is not mandatory, and 0% to 100% or A to F are also excellent options.  One can score Key Results using whatever format and style best suits the organisation.

To calculate a score, we divide the target set by the actual result.  So if the sales team only managed to call 300 leads and the goal on their Key Result was 1000, then they would get a score of .3, if they called 700, the team would get .7.  Once we have a score, we can then grade the Key Result:

When setting a target for a Key Result, reaching a 0.6-0.7 should feel like it is a stretch.  If a team/individual is averaging a score of 0.6-0.7 on their Key Results, then they are probably doing an excellent job taking appropriate risks and pushing themselves.  There will be a few Key Results which they kicked out of the park (0.8 or 0.9) and a few that didn't work (0.2-0.3 or even 0.0).  Unless the Key Result is binary in nature, i.e. Launch the website by date X or Release product A by close of Q3, then getting lots of 1.0s is a smell.

Are people or teams setting Key Result targets low so they can comfortably meet them?  If so, why?  Are Key Results being used for individual performance assessment?  Organisations should not weaponise OKRs.  Use another tool and different criteria to manage performance and keep OKRs as a safe place for individuals and teams to be brave, experiment and fail.

An individual can be very conscientious and be part of a high functioning team, but the individual and the group may still fail to hit their OKRs.  A person put in heaps of extra hours and helped the company through a series of critical incidents in the last quarter, which meant they didn't have the time to knock out all their OKRs.

Reviewing ORKs

If you or the team didn't get a good score on a Key Result, don't despair.  Ask:  What went wrong?  Did we have any blockers or issues beyond our control?  How else could we have done it?  What else can we do?  OKRs are like experiments, so failure is a learning opportunity and should be applauded rather than condemned.

To help foster a safe environment, publicly review company and team OKRs results quarterly.  Get owners of OKRs such as Head of Engineering, Head of Product and Team Leads to explain their grades and any adjustments they want to do for next quarter:

• What grade did we get?
• Why we got the grade?
• What we are going to do differently next quarter and why?
• What did we learn?

Determining an OKR's Success

Rick Klau explains a way one can assess a whole OKR is to average the Key Results scores that belong to an Objective.  Averaging the Key Results only tells us how well we completed the Key Results for an Objective.  It is entirely plausible that one can knock all the Key Results out of the park but still fail to move the Objective.

Objectives are measurable outcomes that one wants to influence but can't control directly, i.e. increase signups by 1000 per month, raise revenue by 3% or lower churn to 15%.  Key Results are quantifiable activities we can directly control, which we think may be able to influence the Objective. i.e. reduce page load time to below 2 seconds or resolve 90% of customer enquiries in under 10 minutes.

Therefore, even if you have completed the Key Results of an OKR, you need also to review the Objective.  The Key Results may not have affected the Objective, or the Key Results didn't have enough of an impact for the money and effort invested.

If the company has an Objective that spans across multiple quarters like "Increase revenue by X" then one can try different Key Results in each quarter and learn what kind of activities help move the revenue up and by how much.  Remember that useful Key Results may not be successful all the time.

Some Key Results may be seasonal, i.e. trying to sell ski gear in the middle of summer may not yield great results.  Other Key Results may have reached points of saturation, i.e. reducing the shopping cart load time from 30 seconds to 2 helped with the conversion rate last quarter but continuing to cut it to 1 second may not help that much.

Developing Quantifiable Objectives

If a company has a vague Objective like "Improve our company's reputation" how can people reviewing the OKR tell if the company's reputation has improved or not?  Brainstorming "How could we measure our reputation?" may help generate some quantifiable Objectives like "Improve our NPS (Net Promoter Score) from -63 to -45" or "Reduce registered complains from 2000 a month to 1000."

Having an Objective that clearly states a metric as well as current and desired target for that metric, makes it is easy to tell how we are tracking.  "Looks like this month we will be down to 1200 complains!"   Remember always to feel free to question an Objective.  Even if the company hit all the Key Results and saw the NPS rise to -45, but employees agree that when they mention the company's name at parties people still try and spit on them, then review the Objective.

• Are we using the right metric?  i.e. NPS may not be appropriate for understanding our customer's sentiments.
• Do we need to be more patient or aggressive with our goal? i.e. an NPS score of -45 is still not great; maybe people will stop avoiding employees at parties when we get NPS to 45.
• Are we measuring the metric correctly? i.e. We are only surveying NPS on customers who contact the sales department and not customer service

Measuring and reviewing both the Key Results and the Objectives can help us answer several questions:

• How well did we go executing the Key Results?
• Did achieving the Key Results influence the Objective?
• Did we have a useful/meaningful Objective?

Related Question

How many OKRs should you have? You should have 3-5 OKRs and 3-5 Key Results under each OKR.  Remembering that OKRs are reviewed and set every quarter (3 months), this would give you 9 to 15 Key Results to work through.  More OKRs/Key Results would make it difficult to focus, and fewer would probably not be as engaging.

What's the difference between OKR and KPI?  KPIs are a set of basic metrics that help determine the performance of an employee or team.  Think of a dashboard in a car.  OKRs are a tool for trying to translate the strategic goals of the organisation into activities that individuals and groups can undertake.  Think of taking the car on a family holiday.

What is OKR tracking? OKRs are reviewed every quarter (3 months) but should be tracked more often.  Personal OKRs can be tracked at every 1:1 and team OKRs at regular meetings like Retros.  If an issue is found when tracking an OKR, the OKR can be adjusted immediately, before the next review/creation cycle.

When engineers talk about horizontal and vertical integration, they are talking about implementation design choices, i.e. whether to implement a single system based on particular functionality that integrates external systems (vertical) or whether to invest in an Enterprise Service Bus that facilitates broader communications (horizontal).  But there is value at looking at the problem of integration through the business lens.

Vertical Integration

In the business world, Vertical Integration refers to bringing in-house, or acquiring a controlling interest in, different parts of a supply chain to help secure resources and service and enable optimisation and saving across the supply chain.  Examples are Ford in the early 20th century (https://www.economist.com/news/2009/03/27/moving-on-up)

"By the 1920s his company (Ford) ran coal and iron ore mines, timberlands, rubber plantations, a railroad, freighters, sawmills, blast furnaces, a glassworks, and more. Capping it all was a giant factory at River Rouge, Michigan (pictured), which built the parts and assembled the cars."

and Tesla today (https://evannex.com/blogs/news/book-excerpt-tesla-s-vertical-integration-is-a-radical-change-in-strategy)

"Some have estimated that, of the over 5,000 components in a Tesla vehicle, around 80% are made in-house."

As different parts of the supply chain communicate better and refine their responsibilities to cater to the company's unique value proposition a company not only reduces costs and streamlines production but, through cross-pollinate of ideas and increased collaboration, can also create new opportunities and unlock value.

In Tesla's case a fresh set of eyes on the problem of building cars has brought issues but also advantages (https://www.bloomberg.com/news/features/2018-10-17/tearing-apart-teslas-to-find-elon-musk-s-best-and-worst-decisions)

"The software and electronics are also better. Munro found that Tesla reduced the amount of wiring snaking through the car by concentrating a lot of the electronics in small circuit boards. That’s knowledge from Silicon Valley that the carmakers don’t have."

Vertical IT Integration Through Business Lens

Assuming the supply chain is more than just moving goods to the customer but also includes:

• Product Development
• Marketing
• Operations
• Distribution
• Finance
• Customer Service

Focusing on how products are developed, created, sold, delivered and supported and looking at the flow of information, materials and resources, at each stage of the supply chain we need to identify:

• internal systems currently involved
• external systems currently involved
• internal systems that could be involved
• external systems that could be involved

You will see some systems like CMS, ERP, WMS and Finance are either already involved in multiple steps or could be.  You will also find where ever you are dealing with an external party like suppliers, transport companies, media houses etc they will usually have some form of system to system communications (think email or FTP file drops) or APIs available.

Where to Start

Theory of Constraints, which we will discuss more in future posts, dictates that there will be only one constraint in the system at any given point in time.  Along the supply chain there is one point that is preventing movement from the left (inputs) to the right (output) more than any other, and when you alleviate that constraint, you will see an increase in production.  Once you find that constraint it should be fairly easy to explain in concrete terms the dollar value benefit of alleviating that constraint and this should be doable in iterative steps, i.e. start with a simple and cheap solution and then build on it until that part of the supply chain is no longer the constraint.  Once a constraint has been resolved, then another part of the supply chain will surface as the new constraint.

Integrations don't need to be complex solutions with high upfront cost in time and money.  One can start with download and upload of spreadsheets with some smart macros to optimise daily activities and then work towards more mature solutions as, or if,  the value becomes more and more apparent.

Summary

Understand how the business works and how information, materials and resources move internally and externally.  Then list out all the IT systems that are, or could be, involved at each stage.  Focusing on delivering the customer an incredible experience and enabling the business to cut cost and unlock value, see what incremental improvements can be made re system integrations, which can be discussed in concrete terms of money/effort saved, value unlocked and improvements for the customer.

A friend once said to me "People are not lazy; they are just unmotivated."  I find this statement helpful because it shifts one from a blaming attitude "You can't get good help these days!" to a more proactive attitude "What can I do to help X be more engaged/motivated?".

I have been fortunate to lead well paid, skilled professionals so I have rarely met a lazy person at work.  My thinking is "If they are lazy how did they finish a university degree and then spend the next 3-5 years honing their craft?"  Here are a few approaches I have found worked well for me:

Aligning the work with their drivers/motivations

Getting someone pumped can be about understanding their drivers/interests and then demonstrating to them how the work aligns.  They may want to work on cool tech so they can brag to their peers, so look at the task "developing a backup solution" and ask "What would it take to make this backup solution we are doing so interesting you could do a presentation on it at a conference?"  Nudging them gently, and clearing the path, so that they can build a high-quality backup solution that is reliable, useful and tested, and that they can proudly brag about to others will probably get people jumping out of bed in the morning.

Painting the bigger picture

There are times where no amount of polishing will make the work shinny.  Here one may be able to get the team on board by regularly reiterating and personalising the bigger picture and demonstrating how this work is an essential part of the whole.  "To do X and Y, we need first to complete A and B, the better we do A and B the less likely we have to worry about them when we are having fun in X and Y land."  Like a good relationship, no matter how cool/interesting a project is there are always boring bits, but if overall the work has meaning for those doing it, then they can conscientiously complete the meh parts because the overall outcome is worth it.

Removing Fear to Make Way for Awesome

Another reason people can settle into a state of inaction is because of fear.  They may feel overwhelmed by the work, be scared they will mess up, will somehow break something, will work on something no one will find useful, or be found out as a fraud.  One needs to nail down the root cause of the fear and mitigate/help overcome it.  It is common for the best engineers to be underconfident; they understand better than most the underlying complexity and what can go wrong.

Being Compassionate Makes Good Business Sense

Life is not limited to the four walls of the office.  People have lives outside of work, and things can happen that throw one off their game.  A death, divorce or illness can be overwhelming.  As a leader, one needs to empathise as much as possible and try and help to the best of their ability.   Being considerate is not just the right thing to do but makes good business sense.  Giving someone paid time off or more flexible work options so they can to grieve or deal with family matters can build a level loyalty that will be paid back in spades.

Being nice is not the same as being soft

Being nice is about having authority but wielding it responsibly and compassionately.  Without perceived power, one can be viewed as just soft and won't inspire loyalty or respect.

"One ought to be both feared and loved, but as it is difficult for the two to go together, it is much safer to be feared than loved, if one of the two has to be wanting" Niccolò Machiavelli, The Prince.

Sometimes one needs to be firm in order to set boundaries and bring someone back into the fold.  If someone's behaviour is getting out of line then reiterating expectations and clearly outlining consequences is a good first step before seriously considering termination.  One bad apple in the fruit bowl can poison the rest, and the safety and welfare of the team have to outweigh the well-being of the individual.

Recently, there has been some talk about large companies in Australia going overseas to find skilled IT talent because they say there isn't enough here.   I have also seen companies flooded with consultants working on projects that could have been done cheaper and better using in house staff because "It is too hard/risky to hire good talent".

It takes skill to manage skill.

Finding Talent

How do you source people? Do you and your team go to Meetups, conferences and camps, not just participating but also contributing, sponsoring and hosting?  Does your company actively maintain open source projects valued by the community?  Does your company participate in mentoring programs?  Do people in your company recommend people they know or friends of friends?

Or do you solely rely on recruiters?

Recognising Talent

How do you know the confident, well-dressed person with a solid looking resume:

• knows what they say they know
• can do what they say they can do
• will be conscientious
• will work well with the rest of the team
• will grow themselves and the team

A lot of good nerds are introverted, underconfident, poorly dressed and have a resume filled with companies that aren't household names.

Attracting Talent

You have found your next tech deity who can help the team reach the next level.  How do you get them onboard?  Throwing money at the problem doesn't always work.  Excellent engineers will also factor in things like:

• is the company well regarded by their peers
• will they be able to work with other good engineers and have managers/leaders who get tech
• will the company help them grow technically as well as professionally
• will working at the company provide a high level of job satisfaction

If you are starting a team and can't initially provide the right environment then you may need to pay above market rates but, spending 20% more for someone who is three times more productive makes good business sense.

Utilising Talent

Ms/Mr Robot has a desk, workstation and id badge with a lanyard.  How do you enable them to weave their magic?  Do they have the tools they need, access to the people and systems they need, help to plough through the red tape so they can focus on delivering outcomes and do they get appropriate recognition for the value they bring?

Nurturing Talent

The tech industry moves fast and the skills you hired your nerd for may no longer be as relevant in a few years or for the next project.  By the time shiny new skill X is packaged into a corporate-friendly training seminar/program you have probably missed the boat, and besides, a three-day training course is not likely to produce miracles.

How are you going to ensure the talented, enthusiastic and curious recruit doesn't become a walking dead?

(See 'Finding Talent' for some ideas)

Keeping Talent

Assuming salary is being regularly reviewed, letting people do an excellent job and acknowledging their achievements is usually more than enough to keep someone happy and engaged.  Adding ping pong tables, an office speaker and free ice creams won't fill the void of a meaningless grind.

Small is Beautiful

It might cost more to hire excellent people locally, but in IT a small team that can work well together can get A LOT of quality work done fast.  Having the tech heads next to the business allows for more frequent and natural interactions which can lead to deeper mutual understanding and better collaboration.  Steve Jobs took this to a new level by ensuring everyone had to go to the same bathrooms at Pixar thereby encouraging impromptu discussions and cooperation.

Improved understanding and collaboration mean the tech team can solve the right problems and solve them appropriately, i.e. not building a mansion when all that is needed is a dog house and vice-versa.

Being able to build and nurture good local teams means companies can do much more with less and solve the right problems quickly.

I have spent most of my professional life trying to work with and understand machines, not people.  Don't despair if you too find these sacks of water to be confusing.  As a friend once said to me "This is a game and you are smart enough to learn the rules."

When you are talking to someone, it is important to remember there is a gap between what they are thinking, what they are saying, what they mean, what you hear and what you understand.  The context of the conversation and each person's view of the world will influence what is perceived, i.e. the same discussion with your partner, boss and parent may lead to some very different conclusions in your mind.

People don't come into a situation with a blank slate.  They enter into a discussion with their worldview already shaped by past experiences.  If this is the first time you have met each other, then you only have a few seconds to make a good impression.

It is important to remember the individual in front of you is a person.  One's thoughts, ideas and hopes are rarely based on only a rational breakdown of the current situation.  Trying to understand where they are coming from and what cognitive biases and prejudices both you and them have, will help you work out how to communicate effectively.

It can be so easy to think that the meaning of what you are saying is obvious, but this is not always the case.  People may come from different cultures or hang out with different social groups, and therefore misunderstandings can arise from:

• use of idioms
• cultural misunderstandings
• use of sarcasm

Does the phrase "Let's go hit the gym" conjure up images of grabbing some baseball bats and unleashing on poor Jim or bonding over a bench press at a health club?  When someone says "That haircut is so you" is that a genuine compliment or do they think it is ugly and are being polite or are they making fun of you?  When someone says "That's OK." is it OK or are they just tired of arguing or expecting you realise it is not OK and they are giving you a polite way to back down?

Then there are the physical issues that could hamper both the speaker or the listener:

• Are you speaking clearly?
• Are you mumbling?
• Do you have a thick accent?
• Is there too much background noise?
• Is the venue appropriate for the conversation?

So how to navigate this new terrain?  First, seek to understand! "Most people do not listen with the intent to understand; they listen with the intent to reply." Dr Stephen R. Covey.  Listen carefully, ask lots of questions and repeat back your understanding in your own words "So are you saying... "

Learn about nonverbal communication.  A fair chunk of what is said is not through words along.  Tone and body language give important clues as to what the words actually mean.  I found "What Every Body Is Saying" by Joe Navarro very helpful.

Both active listening and understanding nonverbal communication are skills that need to be acquired, developed and honed.  So it is important to learn, find opportunities to practice, observe people and situations and, spend some time reflecting.  Don't get frustrated, just persevere and it will slowly start to make fall into place.  Even when you guess incorrectly you will have a framework to refer back to i.e. "OK John was actually open to the idea, he was crossing his arms because it was cold.  I must take that into account next time."

I once approached a manager to discuss an issue that was weighing heavily on my mind and was told: "Don't come to me with problems, come to me with solutions!".  The meeting quickly fizzled out, and I was left feeling demoralised.

I value my superior's time and only go to discuss a problem with them when:

• I know that I don't know.  Since the problem and possible solutions bleed beyond my sphere of responsibility, I want to discuss the issue with a superior.  There may be information or context that I am not aware of which will influence possible solutions.
• My solutions were not digestible.  I have been in meetings where I have presented a problem and solutions but got feedback that I didn't offer any solutions.  I chalk some of these to a communication failure on my part, but on other occasions, this was due to the solutions not being acceptable to the decision makers in the room.
• I may need to kick the hornet's nest. I am concerned that my solutions will not be received well, so I present just the problem to try and get a sense of the mood or am laying the groundwork for further discussion.
• I am stumped.  I know this is a significant problem, and I have thought deeply about it, but my lack of experience/skills/context is preventing me from coming up with satisfying solutions.  I am seeking mentoring/coaching so I can grow.

I talked to several friends in leadership positions about their thoughts and advice.

As a manager, some things to keep in mind:

• Listen and acknowledge, that may be all you can do but may be all that is needed.
• Once you understand the situation, provide more context/coaching so they can go and develop some great solutions.  As you grow someone and guide them on how to arrive at solutions that align with your vision, you have someone you can transfer more responsibility to.  So investing the time and energy is not a waste.
• If you don't have the time, then delegate to someone who has the skills, context and time to help.
• Listen and acknowledge! (repeating this point because it is crucial).  You are their link to the company, and they don't usually get a lot of time with you. Show you appreciate their time as much as they value yours.  If they are telling you something, it is because it weighs heavily on their minds.

As someone being managed, some things to keep in mind:

Your manager is probably busy fighting a hundred fires and is short on time so doing the prep work and getting to the point is a good idea.  It not only helps things to run smoothly but demonstrates that you respect their time and are worth investing in.

• Be proactive. Before talking to your manager, think through the problem and work through some ideas in your head.  You don't have to present the right solution, you just need to show you have put some effort into trying to solve it yourself.  In the meeting say things like "I have thought about X and Y, but we can't do that because of Z."
• Your manager is not your therapist.  Make sure your meetings don't degenerate into a therapy session, stay at the professional, problem-solving level.
• Since your manager is short on time, plan your meeting.  "What do I want to cover?  What order should I present this information?  How can I be more succinct?"  Role-play the meeting in your head and then reviewing how it went after is helpful.  Initially, your rehearsal may not look like the real meeting, but as you get to know your manager, you will hopefully be able to anticipate what they will think/say and then be able to make decisions more confidently on your own.