Category Archives: Business

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.

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

#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.

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.

A healing work environment

A healthy work environment means a healing work environment. Click To Tweet

TL; DR

To be healthy, a work environment needs to be a place of healing, not only a place where no further harm is done. Healing is not always easy or comfortable, but always rewarding. We should build a place of healing and reap the rewards.

Healthy

What does it mean to have healthy work place?

I think we first must ask what does it mean to be healthy.

Healthy: (Merriam-Webster)

  1. Free from disease or pain
  2. Showing physical, mental, or emotional well-being
  3. Beneficial to one’s physical mental, or emotional state

Healing

Each of these definitions show a common thread. Health is a good state, or the absence of a bad state.

So, what does it mean to have a healthy work environment?

A healthy place promotes health.

On the surface, it means to have a work pace that is in a good state or very least without a bad state. This definition is simple and compact. There is a lot of meaning behind it that is easy to gloss over. I want to unpack it slightly.

To be healthy you must be free of disease or pain. If you have disease or pain you must first heal to be healthy. A healthy environment encourages your healing. That means a healthy job will encourage you to heal.

To be healthy you will show physical, mental, or emotional well-being. A healthy work place will promote those signs of health. It will be a place where a person can grow in one or more of each of these healthy states. The more growth possible the healthier a place is.

To be healthy something must be beneficial to one’s physical, mental, or emotional state. This is really what I have been driving at. Beneficial is not just doing no harm, it is allowing for improvement. It is helpful.

When we think of a “Healthy Work Place” we should think of something bigger than simply a place where no harm is done. We should strive for a place where people can heal from past hurts, and improve the quality of their life.

Uncomfortable

However, healing past injuries is not comfortable. The worse the injury the more invasive healing can feel. People can be sore, and irritable. People can have trust issues that can degrade communication. Fear can cause people to see past wrongs in healthy and helpful actions.

For a work place to be a place of healing, not only does the company need to embrace it, so do the employees that are undergoing healing. This is scary, tiring, sometimes painful, but worth it.

I have worked in these environments. Whenever I do, I learn more about myself, and my work than in any other circumstances.

Thoughts

During our working lives, we will spend 24% of those lives at work (approximately 37% of our waking lives); assuming no overtime. We should strive to make that more then something we do to survive. We should strive to build environments where others heal; where we heal if we need to.

Making a safe place to work

Thanks

This post is a special thank you to @JoshuaKerievsky. First I do not work with Joshua, or am I associated with him, however he has inspired a large amount of good things within my team.

Safety is a Skill

Bringing safty to the place I work is one of my highest priorities. Now to be fair, my place to work is the most safe place to work I can imagine. So why do I focus on bringing safety to my work?

Safety is a skill. It is why all manufacturing companies have manditory safety training. But these trainings only cover one type of safety.

Phycological Safety

Google discovered that phycological safety is the key to a well functioning team. We have seen simular successes in our team well before this article was written.

Core Rules

My team’s core rules have been in place for almost 4 years (as of September 2016). They focus on building phycological safety. They are:

  1. Treat everyone with Kindness
  2. Treat everyone with Consideration
  3. Treat everyone with Respect

The first thing to notice is the word everyone. This is not just those you work with. It is not just the people within your department, company or developer community. It says everyone, and it means everyone. It also means that everyone you work with will do the same.

The Cards

I won a raffle held by Industrial Logic, Joshua’s company. The prize came with a small number of these cards:

The back states you have the autority to stop work if any of these things are at risk:

  1. Time
  2. Information
  3. Reputation
  4. Money
  5. Health
  6. Relationships

I instantly fell in love. I gave each member of my deportement one of the cards. I made discussing the cards part of the on boarding process. At the end of which I gave the new hire the card.

On Boarding with Safety

I inform every employee that they have great authority when they come to work here. They can stop work if they feel the any action anouther is taking threatens any of those things. I then express how our practices, Test Driven Development, Contiuous Integration, Mob Programming, and others help to protect these things.

The new hire now has the authority to stop our work if anyone violates these practices and the reason isn’t to experiment on a better way; and even if that is the reason.

Then I tell them the hard part of this authority. They do not only have the authority, but the responsibility. It is part of the job requirement that they do this. Ignoring these hazards is willfully not doing your job.

One of the best moments of my career was when I told this to our interns. They could not believe any company would give them such resposibility and power.

Part of our culture

A number of us have attached the card to our badges, as a reminder of how important this really is. We retrospect often and try to do things that promote this safety. I think we are better then any company I have ever heard of it this regard. However, I do not believe we are perfect or finnished. The company recognizes that this safety has obviously contributed to our success and we are dedicated to finding better ways to achieve it or grow it.

The problem with the #NoEstimates Debate

The problem with the #NoEstimates debate is that both sides are not arguing the same thing and therefore the debate focuses on invalid points. The #NoEstimates hash tag has almost nothing to do with estimates, despite the focus the debates have. What is really being discussed is fundamental ways of doing business.  The pro #NoEstimates group is talking about a fundamental shift in how business is being done. We are talking about regulating and controlling price of software in a very different way.

Without changing, in entirety, the way in which business is done then a lot of the concerns the anti-#NoEstimates group bring up are valid. However, we are talking about a fundamentally different way of doing business.

The basic tenant of #NoEstimates is to change the way that decisions are made. We start with the assumption that the market is moving faster than we can. If this is true, then anything that delays getting a product to market has a huge cost associated with it. This cost is measured in employee hours, loss of customer faith, and competition gaining market shares before us.

The second tenant is that we are going to make mistakes. We are human, and therefore it is impossible to be correct all the time. If we are going to make mistakes, then let’s minimize those mistakes. We want to release small pieces of functionality often so that we can get feedback quickly. We can use this feedback to find mistakes before they are big and costly.

The third tenant is that the market will move with the introduction of product. Once the customer gets any functionality that is useful to them, that functionality will change what they want from future functionality. We have to be able to sense and move with that change.

This brings us full circle. The market is going to change faster than we can.

#NoEstimates is a way of doing business that attempts to accept these three tenants, while ethically helping companies navigate the new landscape of business. We do this by making business decisions in real-time and trying experiments in the marketplace to determine real value. We make decisions based on evidence instead of estimates.

A Better Interview

As interviewing is the first impression a company has of a candidate and the first impression a candidate has of the company, it is important to get right. My goal with this article is to start an open discussion about interviewing and how we can improve it. As a community we need feedback, debate and understanding to create something better. The place I work currently has the best interview process I have ever seen in my 17 plus years in this field. By examining what they do and why, the discussion can open with a solid foundation. We can build upon this to achieve something greater.

Where do we Start

The Hunter Software Development Group is built off of three core rules, and those rules permeate everything we do, including the interview process:

  1. Show everyone kindness.
  2. Show everyone consideration.
  3. Show everyone respect.

These are our foundations upon which we build everything. We believe every facet of an interview process should be executed with these in mind.

Our Objectives

When you consider kindness, consideration and respect as the foundation for an interview, your goals change shape. Yes, you need to know if the candidate is right for the job, but how you determine that changes subtly as your focus changes.

There are three conditions for an interview being considered successful:

  1. The candidate leaves feeling fairly assessed.
  2. We know if the candidate will be a good fit for the team and company.
  3. The candidate knows if the team and company is a good fit for them.

Achieving those Objectives

Each objective is achieved through very intentional means. We examine our process after every interview. We look for any place where the process can be polished, or someone can be better trained. We focus on each objective to better our process and make the interview successful for both the candidate and the company.

The candidate leaves feeling fairly assessed.

It is difficult to judge the capabilities of an individual within a small time frame. It is harder to do that in a way that feels fair and just. We try our best to accomplish this goal by tackling the idea from a number of sides. In order to talk about how a candidate is assessed, it is important to know what they are assessed for.

The traits that we are trying to assess are:

  1. How much emotional intelligence has the candidate acquired so far?
  2. What unique technical background and skills does the candidate bring?
  3. What part of programming does the candidate shine in?
  4. How much does the candidate know about Extreme Programming?

The first thing that happens is the candidate is given an explanation of the interview process. They are told what will happen, what they are evaluated on and why. It is important to eliminate surprise wherever possible. We believe this level of transparency is essential to the accomplishing our three goals.

Once the interview has been explained, there are a number of programming problems that the candidate is asked to work through. Each problem is straightforward with no obscure programming knowledge required. There are no riddles or surprises. Each exercise allows candidates to demonstrate a host of different skills as they work toward different solutions.

As they work through the problems, they have the opportunity to be given help and advice by three to four programmers that have been designated as their team. The team will not give solutions, instead they will help with programming language knowledge and design advice. The team will also rotate into the interview, giving the candidate a chance to navigate, teach, and guide various people with different skill sets.

There is a proctor, a person who takes lead on the interview. The proctor works as a guide for the candidate, helping keep them on target, and moving smoothly through each problem. It is the proctor’s responsibility to ensure the candidate understands what is happening throughout the interview.

Lastly, the candidate is not expected to solve the problems. In most cases it is not possible to finish in the allotted time. The purpose of the exercises is not the solution, but the path taken. We are not focused on what the candidate does not know, but rather the unique experiences and strengths the candidate brings forward.

We know if the candidate will be a good fit for the team.

There is a lot to consider and understand when talking about team fit. The Hunter Software Development Group works very differently than any place I have ever worked. We use a practice called “Mob Programming” to do all of our daily tasks. This means that all production code is written in a highly collaborative environment.

The factors that are key for our work environment are:

  1. Can the candidate communicate collaboratively?
  2. How does the candidate research new information?
  3. Do they demonstrate kindness, consideration, and respect?

Being part of a collaborative team is essential for anyone working in a Mob Programming format. Candidates will be asked explain how to solve problems and sometimes navigate a member of their team through the process of solving a problem. This means that one of their team sits at the keyboard and the candidate is asked to tell the teammate what to do. The disconnect from the keyboard forces some form of communication between the team and the candidate. Each of the team members is at a different skill level for different sets of skills. Inevitably, the candidates will either guide someone that is currently more skilled than they are or a teammate who is less skilled than they are. The way the candidate handles these two situations provides invaluable insight into that person’s communication style. It is important that the candidate shows kindness, consideration and respect during the whole process.

The processes of our everyday work environment puts highly collaborative teams into situations where they are acquiring new knowledge, usually as a result of having no foundational knowledge. The problems that the candidates are presented with are straightforward as for as core knowledge but ask questions that the candidate may not be familiar with. We look forward to web searches, text messages and anything else the candidate can use.

The candidate knows if the team/company is a good fit for them.

Letting someone know who you are is complicated process that can easily take the entire time of the interview. So how do you let someone know who you are within a couple of hours and still accomplish the other goals of the interview? This is one of the hardest questions we try to answer during our interview. We start by holding the interview in our open work environment. The candidate can just look around and see how other teams are working. They can hear the discussions, and see the excitement. A few feet away a team is working to solve problems and tackling goals.

Our interview process is part of our work. It is collaborative and social, designed to mimic the best parts of our work while still being an interview. Teammates take turns typing, helping, and guiding during the process, all of this helps give a feeling of what to expect.

If the candidate seems to be a good fit skill-wise, we then continue to a Lean Coffee session that lasts 45 minutes to an hour. This changes how the Q&A process for interviews goes as it starts by putting all questions and topics up front for all to see. Even if all topics are not discussed, the candidate and the team can see what was on each other’s mind.

A Lean Coffee format gives the candidate the chance in participating in the selection of questions and topics. Each person participating in the interview has three dots to vote on topics. These topics are then organized by number of votes. The topics with the most interest are then discussed first.

This gives the candidate a lot of agency in guiding the discussion. Their voice gets heard and they get a chance to have their questions addressed. It also allows them to focus on topics from the interviewer that they feel will make them sound better.

Each topic is given a five-minute window to be discussed. When the time is over, everyone votes on continuing or moving on. If even one person wishes to continue then the topic is continued, but only for two minutes. Then the voting cycle continues until everyone is done with the topic.

Each topic discussed is a topic not a question. Everyone is encouraged to reflect on the topic and address what it means for them. For instance, if the topic given by one of the interviewers is, “Describe a moment when you felt you really shined,” all members of the interview are encouraged to answer, not just the candidate.

This also means that topics brought up by the candidate will not only be addressed by the interviewers, but also by the candidate.

These discussions are the best way that we have found to truthfully let the candidate know who we are, what we do and why we do it.

In Summary

The Hunter Software Development Group has a very different approach to interviewing born out of a different perspective. We start with a foundation of kindness, consideration and respect and build from there.

We work to fairly assess the candidate based off of four types of skills. Emotional intelligence, unique experiences, what makes the candidate shine and what they know about Extreme Programming.

These methods have been very successful for us when hiring. We retrospect and adapt after every interview, so we are always improving. However, I would like to be part of a larger conversation. By discussing this with other professionals the community as a whole can gain insight from each other’s experiences that might not be seen any other way. Maybe the whole of the industry can improve and find yet to be discovered better ways. Mob Programming has led to better code quality. If we all huddle up and analyze how we interview who knows what will happen?