Technical Debt for The Non-Programmer

Summary

Technical Debt is a broad sweeping term that comes out of the Finance industry. Its meaning and relevance are not fully understood by most who use it. I intend to talk about the use of the term “Technical Debt” and suggest we replace it with the term “Technical Risk”, as well as give some guidance on what is and isn’t Technical Risk.

Brief history

Technical Debt was a term coined by Ward Cunningham, one of the Authors of The Agile Manifesto, while working in the finance industry to explain what was happening in the code to financial managers. He needed to explain explicit design decisions in a way that people in Finance could understand. So, he chose to describe the postponing of some aspects of design as a loan. This was an intentional desire to delay design decision until more was known. Therefore, the team took on some risk intentionally to capitalize on potential.

It’s about Risk

Ward was trying to get managers to understand the very real risk of losing money, increasing cost, and other bad things. The design of code can cost money in a couple of ways. First, it can, and does slow development time thereby increasing the cost of future features and bug fixes. Second, it can make code difficult to understand thereby increasing the chance that a change will result in a bug. Risk can be assessed, categorized, and handled.

Ward used the term as a metaphor. Like all metaphors, it can be useful but has its limits. Since Technical Debt is really talking about risk, I often use the term “Technical Risk” instead. This encourages a discussion on what the risk means on our system. It also allows us to approach it with systems we already know and are familiar with like standard Risk Assessment.

Lastly it is worth saying that no system is without risk. The question really is, is the level of risk acceptable within the system? Once we can answer this question, then we can make logical meaningful decisions around Technical Risk that fit our business plan for the software in question.

What is Technical Risk

Technical Risk being a code level risk means it exists within individual files of code and is about the structure of code within a file. This could be a portion of the code that few people understand, or a segment of code that is particularly difficult to change without effecting something else.
There are 3 causes of Technical Risk, each are valid and worth understanding as they aid in our assessment of risk.

Intentional Risk

There are times when release pressure or some unresolved decision leads a team to intentionally take on risk. This allows them to be heads down for a bit without worry of how the decisions they are making now will impact them in the future. The problem is longer the team waits to address this the harder it becomes to address. When assessing this type of risk, time is a major feature to reducing the risk.

Unintentional Risk

Unintentional risk is caused by the team or someone on the team not knowing how to avoid making a risk embedding decision. Since code level risk assessment is seldomly taught, and no one can be aware of all things all the time, this is not a statement on the quality of the programmers. When assessing this kind of risk, the key feature is training.

Code Rot Risk

Code rot risk happens because decisions that we made a few months ago, despite being the best possible decisions, did not have the insight we have today. We learn and grow while our code largely stays stagnant. This is a good thing, but it does introduce risk when it comes time to change the code. Automated systems that alert us to breaking changes helps mitigate this kind of risk. Code coverage is a key feature to assessing this kind of risk.

Audience Matters

My last point on Technical Risk is when using the term be aware of your audience. Talking about risk as debt might work well when talking to a business manager who understands finance. Talking about it just as risk might be well suited to other managers. However, neither are well suited for discussions between developers.

When talking to management at all levels within a company, I find using their familiar terminology while accurately conveying the information is best. That might be risk, debt, or other language. It is more important to accurately communicate the needed information then to hold to vague technical jargon.

I suggest developers do not use these terms when talking about the state of the codebase to each other. There are more accurate technical terms to use in all cases. The technical terms also give guidance on how to alleviate the risk they are seeing.

In all considerations of audience, the goal is to concisely convey the information needed to make decisions based from the current structure of the codebase. As such we need to choose our language and terms appropriately.

Conclusion

Technical Risk is about the risk that something will happen. If a bug is found, it is not technical risk anymore. A bug may be a business risk, but the technical risk comes in repairing that bug. Or in the risk of other undiscovered bugs existing in the code. Calling a bug Technical Risk or Debt confuses things. The term should be limited to talking about how the structure of code may lead to future loss of money.

Technical Risk is also not a critique of the skill of the programmer or quality of the code base. All code has risk. If we simply ask what an acceptable level of risk is, we can dispassionately plan to mitigate that risk. The moment we use it as a critique we lose the ability to approach it objectively and dispassionately. It is worth saying that using Technical Risk as a critique of the code also prevents mitigations that do not result in changing the code.

A fractal Cube

Our Team Doesn’t Need to Retro

TL; DR

Sometimes as a team becomes successful, and they have had very successful retrospectives, they stop getting value from those retrospectives. Something must change for the team, in its new state, to gain more value from this exercise. I suggest more retrospectives focused on smaller things.

Pain of Stopping Retrospectives

I have been part of a team that stopped seeing value from retrospectives. In fact, I have been part of many teams that found themselves in this situation for different reasons. In the past, those teams just stopped doing retrospectives until we realized things were very out of whack.

Then, as we scampered, and we flustered, and we struggled, we often found ourselves failing to pick up the pieces neatly. The few times we could recover was after months of struggling, the other times… Well I no longer work at those places.

Stopping retrospectives has consequences. Continuing retrospectives that are unfruitful also has consequences. A process that becomes tedious, and without any gratification, also becomes soul sucking.

This starts to feel like a “no win” scenario.

Increased Frequency, a Story

The team I am currently on hit this wall about two months ago. We did something very different. We increased our retrospective interval to once a day. The world seemed to change overnight. The trust and communication we had been building up to become successful and now started to pay off in large quantities. The daily retrospective allowed us to address issues and wins, as they were more fresh, meaning more of them were addressed and captured into our working agreements.

These new insights were on smaller things, but these smaller things made for bigger improvements. It was amazing, these retros were also shorter – about half the time. I felt energized and we are even more successful for it.

A couple of weeks ago, we tried another experiment, we turned up the frequency again. Now we hold a retrospective every time emotions run even slightly higher than normal. Some days we only have a single retrospective; other days we will have five. We always have our end of day retro (more on this in another post), however we let emotions and insights guide us now.

Advantages of On Demand Retros

These retrospectives are only about 10 minutes at the longest as they now focus on a single insight and outcome. By acting on focused events we have started to notice patterns that were subtle enough to be missed when we bundled everything into a single retrospective. We are becoming even more successful and our team is happy.

That is not to say it is easy. It takes work and trust to have retrospectives at this kind of interval. The payoffs are well worth it. The mini on the spot retros are some of the most effective I have ever had. We try all kinds of experiments now. Some last an hour, others a few weeks, but all are freer to try radically different approaches.

Conclusion

When your team is successful and safe, your old retrospectives may stagnate. They may have addressed all the larger and most visible issues, and you need a tool to help address the smaller, and larger impacting issues. We found that tool to be increased retrospective frequency.

Smaller, more frequent #retrospectives help when retros start seeming like they have no value. #Agile Click To Tweet

Functcon

TL; DR

We believe that Functional Programming (FP) is going to be, and is currently, a disruptive force in mainstream programming. We want to help shape the community around that force to improve the larger software community. We will do this by building an open and safe community where newcomers and veterans can explore FP- their love of it, and how to use it to build awesome software. If you believe in this please sign up on the mailing list at www.functcon.com.

@Functcon is a #FunctionalProgramming #Conference built around a community of #safety. Click To Tweet

Our Value Statements

To promote a culture of success and safety to a growing community of functional programmers, we believe the following things:

  • Functional Programming is disruptive and will continue to be so.
  • Psychological safety is the most important thing to build a successful community.
  • Excellence in programming makes changing code safe.
  • Processes of continual improvement are necessary to achieve excellence.

Functional Disruption

Kate, my wife, and I believe very much that Functional Programming is a disruptive force in the programming industry. This old technology is seeing increasing attention as we are needing different approaches to solve today’s problems.

The simplest computers are gaining more cores and an application’s ability to use those cores determine its success. Not to mention the kinds of thoughts needed to solve the problem of analyzing the increasing mountains of data we are accumulating by the minute. These problems are a couple of examples of problems that have been difficult to solve using Object Oriented Programming (OOP) or Procedural Programming.

We see it as every mainstream OOP language starts to gain FP language constructs.  FP is appearing increasingly in podcasts. Functional Programming conferences are starting to appear and be successful with multiple hundreds of attendees.

We do not know if it will ever displace OOP, but we believe it will become as important. This means that to prepare for the future the industry will need people training in this skill set right now. The Dark Matter Developers are currently not learning this skill. You can see this by looking for accredited courses. Companies are not paying for accreditations in FP.

Dark Matter Developers are the strong majority of developers out there. That means there is currently a building skill deficit. As this skill becomes more in demand the culture surrounding that skill will become in demand. As a community, we can build a culture of success and safety.

Psychological Safety

Psychological Safety was defined by Amy Edmonson as the shared belief that a team is safe for interpersonal risk. She discovered teams that had this trait were the highest performing teams. Later Google found in their research that one of the most important traits to define a successful team was Psychological Safety.

For Functcon, we want to expand that definition from team to community. We believe by focusing first on Psychological Safety, we will build the most successful community.

Excellence in Programming

Excellence is not a word I like, as I state here. So, let me define what I mean by excellence. Excellence is the application of the most current knowledge about the best techniques and practices with understanding that the most valuable part of a project is its maintenance.

We believe by focusing on the very best of FP with this understanding of maintenance we can grow a valuable community.

Continual Improvement

It is virtually impossible to make something perfect, especially when you are dealing with a complex system. Everything you do is going to involve tradeoffs. Everything you do is going to be relevant to a given context which will move on and change under you.

So, we believe that Functcon needs to be about the continual improvement of the community, the code, functional programming, and itself. This will allow us to adapt and always remain at the top of the game.

Tying it together

If we manage to be the most successful community, with the most valuable practices, and we can adapt… Well nothing will be able to stop us. However, we don’t need to be the best to make an impact. If we even start to approach these things we will make for a better industry. Let’s do it together.

Call to Action

If you like what we are trying to do, please sign up for our mailing list. These names help us attract companies to help pay for the conference. Please tell your friends about us. Our page is www.functcon.com. And, of course, we won’t sell your information. Come hang out with us today!

I joined @Functcon mailing list. #Awesome #FunctionalProgramming #Conference https://functcon.com Click To Tweet

Myth of Management With No Hierarchy

TL; DR

Leaders exist; therefore, hierarchy exists. A flat organization is not truly flat, it is made of many leaders. Those leaders have the responsibility to train others to replace them. The company has the responsibility to help those leaders be successful and be diligent on keeping things safe.

A flat organization is not truly flat, it is made of many leaders. Click To Tweet

Leaders are Essential

‘The Harvard Business Review’ has the article: Hierarchy is Overrated. This article paints a very favorable view point of flat hierarchy, but does not address the need for leadership at all. People will become leaders. This is an essential and natural process.

However, much of what needs to be accomplished by leaders, functioning in a flat hierarchy, is not natural. One of the main responsibilities of these leaders, is to move to stop being a leader, the sooner the better.

The way a leader stops being a leader is to train and inspire. Say that someone feels passionate about team building. They take up the reins, figure out ways to start building team communication and unity. They start the ball rolling. Now they need to look for someone else who cares about team building. They will collaborate, train, and inspire them to both take over and train someone else.

Potential Problems

There are a host of potential problems. Everything from dissatisfied employees to locus of control. Most problems will stem from one of these three root causes:

  • Denying the existence of leaders
  • Team not trained in essential leadership skills
  • Organization not really being flat

Leaders Exist

Leadership needs to be recognized, and its existence acknowledged. This allows an organization to better define how leaders behave and what it means to be passionate about some aspect of the organization. Don’t deny them, embrace them, try to understand them.

Everyone Trained as a leader

Train everyone to be leader. This is a lot of work, but it pays off as people can step up and handle issues and opportunities that they feel passionate about. Leadership can be more easily distributed and handed off from one leader to another. Everyone is capable in guiding and supporting leaders as they venture into new ideas and interests.

Here are a few sources I recommend:

A Flat Organization

Having an organization that has a distributed hierarchy can be challenging. The leadership, the people with the titles, needs to support it. They must trust people to do the job, and enable everyone to be trained. The highest paid people in the room have the greatest potential to do harm with the simplest word.

So, there is a need to prevent their hidden biases from polluting down into an unintentional hierarchy with certain people being ‘more equal’ than others. This can be done by really paying attention to building a safe environment. By encouraging those beneath them, in title at least, to contradict them and actively stepping back, these biases become smaller.

Giving up Control

The goal of every leader, should be, to eventually not be the leader. Each person should be looking at passing the torch, and ensuring multiple people can replace them. If this is not done they become the bottle neck and get in the way of success. The idea is that everyone can take a vacation and nothing stops working.

Each leader finds someone else who is passionate about the task at hand. They share responsibility, and train as needed. Eventually they will stand back and give their protégé or partner a chance to run things.

In Conclusion

A truly flat hierarchy does not exist. This is a good thing. What real world flat hierarchies enable is everyone with the inclination can be a leader. There are difficulties which can be overcome with hard work and trust. It is rewarding to work in one of these organizations and they can be more effective if you acknowledge the existence of leadership, train for it, and upper management supports it.

The Power of a New Voice

TL; DR

Too often the person with the least experience is ignored. This is a shame because they are often the person who can lead us to the most significant insights. They will see things we overlook or have become accustomed to. They can help us question the things we have started to not question. They are a powerful voice for improvement.

A new perspective can help us question the things we have started to not question. Click To Tweet

Question Everything

Like @WoodyZuil says: “Any method or practice we use without question should be questioned.” https://twitter.com/WoodyZuill/status/881711076089384964

The problem is if we are practicing something without question, we can often be blind to the fact that we are practicing it without question. A new set of eyes can see these things, but we must encourage them to point them out. If not, we risk that they too will become accustomed before we have gained benefit from their newness.

Intimidation

The problem with capturing input from someone who is new, is that most people do not feel comfortable giving feedback while they are new. This means that we must be extra careful to foster that feedback. It is something that must be intentional.

The first step is listening. When a new person offers input, listen. Use both Active Listening and Comprehensive Listening. Do not interrupt, and take a moment before replying. This shows respect for what they have to say, and consideration of their point.

The next is to treat the comment and question as if it is valid, and wanted feedback. They may not understand all the context to the thing they are questioning. That is the point. Do not explain to them how they are wrong, instead explain to them how they are right. That does not mean that you do not explain your context, but instead use it understand what they offer.

What if they are wrong?

They will often be wrong. The suggestion, or question, will be wrongly worded. They will most likely not understand what it is that made them feel the way they felt. Don’t let the fact that what they say is wrong stop you from learning. Instead, examine the situation. There will be truth there, and that truth will lead to improvement.

At the worst case, if they are utterly wrong then you will have provided the opportunity to learn in a way that makes them feel appreciated. This learning will be retained longer. It will encourage them to voice more, and thereby learn more. Eventually they will teach you something, because they are willing to voice what they don’t understand.

The Warning of a Silent Voice

Pay attention to what is happening regarding the new voice. If that voice is silent, this is a waring. It means that there is something that is causing that person to fall silent. It means that the team is not welcoming that person’s insights, and not listening and accepting of what the new voice offers.

This is the loudest indicator you will often get to small problems on a team. These problems can- not always, but definitely often enough- grow into big noisy, and explosive problems if not handled at this point.

In Closing

It is hard to listen to the point of view of a new person. That person may not know the social norms, or the current environment. It is easy to just brush off what they say, as they do not know better. However, when we do ignore the “new voice” we lose a lot of valuable insight.

Listening to the new perspective is not always natural but it is crucial. Click To Tweet

The Things We Say

I want to retire certain phrases from programmer parlance.

TL; DR

We are not clear in what we say. We use incorrect metaphor. We choose vague terms instead of better ones. Let us trim some of the excess terminology and jargon.

We use incorrect metaphor. We choose vague terms instead of better ones. Click To Tweet

Technical Excellence

This terms vagueness is its undoing. Almost everyone I meet has a different definition of what Technical Excellence means. To some it is a synonym for Extreme Programming. To others it is learning design patterns or continuous improvement.

The above assumes that the person saying the term has good intentions. I have also heard this term used as a passive aggressive way of saying that someone is a poor programmer, by telling them to strive for technical excellence without specific feedback. Calling someone a poor programmer without giving guidance on what needs improvement is useless at best, discouraging and defeating at worst.

Instead of using technical excellence, let’s say what we mean. If that is Extreme Programming, let’s say Extreme Programming. If it is adherence to corporate coding standards, then document the standards and talk about the standards document. If we want to critique someone, take the time to critique them in a way that is helpful. Encourage growth and improvement rather than attacking.

Simple

Again, simple is an extremely vague term. What is worse is that we acknowledge how vague this term is by modifying it with: Simple isn’t easy. As if this sound byte could explain what we mean. This suffers from all the problems of “Technical Excellence” and really doesn’t say anything useful.

We spend so much time talking about making things simple and then engaging in a long conversation quantifying what we mean. Why do we do this? The term “simple” just causes confusion, debate and eventually is shortly forgotten.

It is amazing to me how much energy we spend saying nothing rather than what we mean. If we could talk specifically about the types of complexity we want to avoid, we allow for improvement. We start the conversation that moves us into a better place.

Remove confusion, add clarity and forget simple.

Technical Debt

Technical debt was a good metaphor. Past tense. It was created for a specific reason, it was to explain the causal effect of decisions to bankers. It was not created to discuss the state of the code between developers. So, let’s stop using it for such communications!

Instead of technical debt, let’s talk about Anti-patterns or Code Smells. Both have names for specific things that can be addressed. They can be researched and understood. Better yet, there are know ways to move from these potential problems to good patterns.

Lastly if we are talking about the state of code caused by a ignoring problems over a long time, then even the team “Code Rot” is better at describing what needs to be said. There is real meat in using directed language to discuss the state of a codebase between developers.

In Short

Stop being vague right now. Don’t mix your metaphors. Be clear and intentional. If there is better language that can be used to describe what you want to say, then use it. Increase your ability to be understood by thinking about what you are saying.

Stop using 'Technical Excellence', 'Simple', and 'Technical Debt'. Start communicating effectively. Click To Tweet

#NoEstimates Story Sizing

A way to determine if a story is small enough without estimating it.

TL; DR

“No Estimates” is a modern movement in software development that focuses on eliminating wasteful estimates. However how do you know if a story is small enough to be accomplished without estimating its size? There are a series of rules that when followed guarantees a bite size bit of work.

There are a series of rules that when followed guarantees a bite size bit of work. #NoEstimates Click To Tweet

Setup

“No Estimates” is built on continuous delivery of valuable product. That means that the business must be able to measure the output of a development team in near real time. If releases are regularly weeks or months away, then you leave the business with few tools to measure with. Faster the delivery the better they can measure. Stories need to be small enough to complete daily.

How do guarantee that the average story is small enough to be completed in a day without estimating?

The Rules

There are three rules that can be followed to ensure that a story is as small as possible. In all three rules, the word team means much more than the development team. It means the whole project team including the developers, the product owners, testers, management, executive management and anyone else who has a stakes in the product being delivered.

  1. Does everyone on the team have the same understanding of what the story delivers, and what need it addresses?
  2. Does everyone on the team have the same understanding of when the story is completed?
  3. Is the story free of any known preconditions?

Three simple rules for sizing stories in #NoEstimates Click To Tweet

Understanding

Gaining understanding about a story that crosses skill and role boundaries is difficult. To better communicate intention, we must be communicating simpler ideas. The first two rules do a lot to limit the size and scope of a story.

The first two rules also ensure that the right thing is done. A shared understanding means a shared vision and shared responsibility. If we understand what is to be done, and when it is done then we do not mistakenly build the wrong thing.

Preconditions

Once everyone understands what is to be done, and when it can be considered complete then we have a certain level of understanding about the story. If at that time anyone can think of a precondition that must be done before the story is complete, then the story is too big to be worked on. Maybe it is time to work on the precondition, or something else entirely.

The operative word in the last rule is “known”. We could spend an infinite amount of time looking for and understanding preconditions. It also goes without saying that we may find new preconditions as we start working. The important thing is that no preconditions are discovered in the process of gaining group understanding.

During the doing of the work, if we do discover a precondition we then need to decide if we continue or abandon the current story? Most often we can continue, especially if the precondition that was discovered meets the 3 rules, which means we must communicate our progress effectively.

Summary

In short, by following the three rules we can ensure work is taken in bite size chunks, even without estimating.

Let’s Encrypt AWS Lightsail with WordPress

SSL all things is a good thing, especially if you allow for user interaction. This includes clicking on links, writing comments or simply navigating your sight.

TL; DR

Let’s Encrypt is a free service that allows you to add Transport Layer Security (TLS) to any website for free. When you see the green padlock, this means that the sight is protecting its users from malicious scripts that inject them selves between the user and the sight. The documentation is well written but does not cover the what is needed to get it working on AWS Lightsail.

The Basics

I found this article that really describes the first half of the problem. It tells you how to enable TLS through the use of a Let’s Encrypt certificate: http://www.alondiamant.com/2016-12-20-using-lets-encrypt-certificates-with-wordpress-on-amazon-lightsail?utm_content=buffer27ff6&utm_medium=social&utm_source=plus.google.com&utm_campaign=buffer

What it doesn’t do is tell you how to ensure that only the encrypted version of your site is used.

Redirect

The rest of this article is assuming you are in an SSH shell.

To force redirection from http to https, there are some settings you need to change and delete.

First thing is to make a backup of your configuration. This way you can recover if you make a mistake.

sudo cp -I /opt/bitnami/apache2/conf/bitnami/bitnami.conf /opt/bitnami/apache2/conf/bitnami/bitnami.conf.bak

Then you are going to edit the config file. I will use ‘Nano’ to do this as it is a reasonably friendly editor for most people.

sudo nano /opt/bitnami/apache2/conf/bitnami/bitnami.conf

Once editing you will delete lines from the file. This can be done by using the arrow keys to move to the line and then pressing Ctrl+k.

You will want to delete everything between the <VirtualHost _default_:80> and the closing </VirtualHost> tags.

You will want to replace them such that the tag now looks like:

<VirtualHost _default_:80>
ServerName [your server name eg: www.mydomain.com]
ServerAlias *.[your root domain eg: mydomain.com]
Redirect / https://[your sever name]
</VirtualHost>

Then you will exit Nano by hitting Ctrl+x. You will be asked “Save modified buffer (ANSWERING “No” WILL DESTROY CHANGES) ?” Type a capital ‘Y’. Then when you are asked “Name of File:” just hit Enter.

Restarting Apache

Lastly you will need to restart Agache.

sudo /opt/bitnami/ctlscript.sh restart apache

Now to test your site.

Note

Your certificate is only valid for 3 months. So you will want to setup a Cron job to renew it.

Employee Feedback without Unicorns

I am talking at #Agile2017 about giving meaningful, helpful, and humane, employee feedback. The secret is that the employee needs to be central.

TL; DR

The only person qualified to give advice to an employee regarding their career is the employee. That means we need to empower the people who work for- and with- us to analyze their career. If we can empower people to better their lives they will do more and do it better.

The only person qualified to give advice to an employee regarding their career is the employee. Click To Tweet

Questing

What if employees looked forward to receiving feedback? What if they found feedback valuable and able to improve their lives? What would that look like? How would we provide that environment? Our department asked these questions and the whole department swarmed to tackle the problem. The solution we came up with worked well in our context, and I also believe the lessons learned while figuring the answer out are valuable to others.

Personal

The first lesson we learned was that if we want to give meaningful feedback to individuals was that it had to be individual. That means we must do things to consider, protect, and appreciate, the single person who is receiving the feedback.

Our solution, currently, is to do a personal retrospective for the person. This retrospective is private, personal, confidential and facilitated by a peer who the person trusts.

Trust

It is important that the retrospective is personal and private. Without this security, there is no safety. Without safety, truth is limited, constrained and lost. The goal is to allow the employee to have real insight into how they can improve their career path, their entire career path, not limited to that within the company.

Facilitation

It is also important that this retrospective is facilitated. Facilitation gives the opportunity for the employee to explain their thoughts to another. The process of explaining leads to insight.

The facilitator is to listen, and ask questions only to gain understanding. They are not to judge or comment. They are not to burden the person whose retro it is with their own opinions. We decided to provide facilitation training for everyone who is interested in being a facilitator.

The facilitator is invited by the employee who is undergoing the retrospective. Invitation is important, as it signifies trust. It is just as important the invited facilitator be allowed to refuse without explanation. Not everyone is comfortable with facilitation.

The last thing to note about facilitation is that the facilitator will make mistakes. After all, these are not professional facilitators. Mistakes are okay. Even if they disregard all their training, just by being there for the retrospective, they will make the retrospective more successful.

Output

The content of the retrospective is private and personal. The things talked about during this meeting need to be protected, unless there is a legal obligation. If not, we again lose trust.

The product derived from this retrospective is a set of possible goals. One or two of these goals will be decided upon and acted on. They will be shared with the director who will help to achieve the goals. He uses this information to understand the ebbs and flows throughout the department.

When a goal is not achieved, the director needs to know if the department hindered its progress, and if so, how. If a goal is completed the director wants to know how the employee felt about the goal, if there is more that can be done to improve upon the accomplishment, or if knowledge can be shared.

Rewards

These goals, the retro, and information gained through this process, except where there is legal obligation, is disconnected from compensation. This frees us from the burden of creating an accidental game where the outcomes can become harmful.

The only reward is the ability to take an analytical look at your career and take steps to move it into a direction you want.

Plug

Please come to my talk, where I will talk in depth on this. I hope to see you there.

I will be watching Facilitation Without Unicorns at #Agile2017 Click To Tweet

Onboarding a human into a human system

Onboarding is much more than a meeting with HR, it is the integration of new person.

TL; DR

Onboarding is an important endeavor. If we approach it seriously and conscientiously we can make the new person feel more welcomed and part of a team.

Initial Onboarding Meeting

Human Resources has a job to do with its onboarding process which is important for all kinds of reasons. This onboarding covers legal issues and is often the first, if not only, exposure a new hire has with the company’s culture as defined by its executives. However, this should only be the start of the onboarding process.

Integration

It can take several months to integrate a new person into an existing team, so that they are emotionally and mentally part of that team. During this time, we need to help them, guide them, and be there to support them as they have questions.

Our goal in onboarding should be to help and guide a new hire in becoming a member of a team. Click To Tweet

My department has extended its onboarding process to three months and provided the new hire with a buddy. We choose a buddy from the newest employee who has been at the company at least six months, who are on the same team as the new hire, and is willing to accept the responsibility. The buddy is chosen this way to maximize the empathy for the new hire since buddies have the most recent memory of what it was like to be a new hire.

Buddies

They are a buddy, not a mentor. Buddies are there to answer questions and give support. They are not there to teach. Which is to say buddies are not given any authority over the new hire and are a model of the flat organization structure of the department.

Department and Team

We also extend the onboarding process to the team and the department. When a person is added to a team, that team is no longer the same team. To emphasize this fact, the team, the new hire, and their buddy all undergo training about the Satir Process Change Model by Virginia Satir.

This creates a cycle of repetitive learning for the new hire. The new hire learns about the process as part of their onboarding. They then learn about it again with each new hire brought onto their team. They again learn it when they become a buddy. We do this because we believe understanding of the Satir Process Change Model is important to the successful integration of a new person into an existing system.

The team and department then undergo activities to introduce the new hire to everyone, and to introduce everyone to them. These activities might include a Market of Skills, a Lean Coffee on hobbies, or many other activities. One of the main goals of an onboarding process is to make the new person feel welcomed, wanted, and appreciated. These activities done over a three-month period seem right to me.

Request for Comment

How do you, and your company/department/team approach onboarding in a new way? I would love to hear about it.