Category Archives: Teams

General IT, Product Management, Software Development, Teams

The two warring tribes within small business IT and software development and how to make peace

Leave a comment

Lisa Jaspers LinkedIn article struck a chord. She identified a huge issue that affects any small business IT/Development team that is tasked with BOTH maintaining existing systems as well as facilitating new product development.

In small companies, usually a single team has to do both existing system maintenance as well as new product development. This duality can  create a “two warring tribes” atmosphere. And as Lisa states in her article, you can’t just add roles here and there and solve the problem.

Sometimes the warring tribes exist inside the individual as they feel pressure from both camps to do different, yet equally urgent, work. Sometimes they exist as 2 groups of developers within the same team, competing for resources, priority, or direction.

Warring Tribe #1: Maintenance Tribe

Your existing systems, software, and products carry the company. They pay the bills, enable the work, and serve the customers.

But, over time, these systems require patches, bug fixes, updates, security changes, regulatory modifications and customer feature additions. Maintenance, support, and caretaking of these systems can consume a small team.

It’s like your company is in a boat in the middle of the ocean and the boat is made up of the existing systems and products. Any leaks or issues with the boat have to be corrected quickly lest you risk the boat beginning to sink. This is existing system maintenance. Yeah, small leaks can be ignored for a while. You can hire more folks to ‘bail water’. But in most cases existing system maintenance issues will soon trump new product developer in time and dollars.

Warring Tribe #2: New Product Tribe

New product development, on the other hand, is like building a new boat, while you’re still in the old boat, without sinking either boat.

When there are existing product or system issues or urgent features needed for the paying customers, you pull your team out of the new boat and back into the old boat. When existing maintenance furor dies down the team heads back to the new product and continues on. This back and forth focus shift is more expensive than you think. It causes both tribes to suffer. And it causes the results of both tribes to suffer.

Influences on Tribal membership

When I was a developer, getting picked to go build the “new thing” was special. It was like getting drafted in the NFL. Or like getting asked to the prom by someone you really liked. You were desired and worthy of helping accomplish an important initiative for the company.  Getting “left behind” to continue to maintain systems was not as desirable. You got to sit out the prom. No dancing for you.

However, for others, who had key hands in building an existing system, they wanted to stay behind and continue to nurture their ‘baby’.  They had little desire to go and build something new.

In a large company setting, an engineer may get the flexibility to choose. And some engineers can do either.  But in a small company setting, you don’t always get that choice.

The same tension between  doing something new, or staying behind and shepherd something current, also affects project managers, QA folks, DBA, system admins and other roles within the team.

Ways to make peace

1. The two team approach

If you have enough resources you can divide and conquer to some extent. Pick those who want to go and help out with the new thing and allow them to focus on that exclusive, leaving those in favor of maintaining the existing systems in place.

I have seen this method work well.  Small, competent, focused teams can make progress very quickly. In the end, this is probably the most desired approach as Lisa Jasper shares, “because product development is such a different mindset“. A dedicated team can focus on new tools, new processes, different vendors and the different mindset needed for new product development without distraction.

2. Bring in the reinforcements

Another approach, if your new product development takes too many of your resources is to strategically contract for necessary  bug fixes and feature work on existing systems. Using this approach can help minimize cost, focus effort on only the most important issues and help keep you from ‘gilding the lily’ on existing system improvements.

If your existing systems have a lot of baked in technical debt the outside, tactical contractor engagement may not make sense. The success of this approach hinges on finding a reliable contractor who is familiar with your tools/framework/languages or systems. If this is the case then tactical contractor engagements can be very useful.

The success of this approach hinges on finding a reliable contractor who is familiar with your tools/framework/languages or systems. If this is the case then tactical contractor engagements can be very useful.

3. Bring in another army

If your team is small and they don’t have the experience or knowledge in the  domains of the new product then you can consider outsourcing the new product development.

In one engagement, in the earlier days of the app store, our team was building and maintaining web applications and needed an iPhone app built. Our team knew databases and the languages and frameworks we used but none of us had any real experience with iOS or ObjectiveC. So after some research and comparison shopping, we went with a third party company that specialized in mobile app development to develop the app for us. If your new product need is specific enough this method can work well.

If your new product need is specific enough this method can work well.

4. Refactor

Another approach that is not as glamorous, is to refactor existing products. This is especially true in software. In software, refactoring refers to the process of re-structuring software code to improve its operation and add or take advantage of new features that could not be done in the prior state.

If your new product needs can be broken down into smaller more atomic features, it may be possible to use your existing team and refactor your current product to add certain aspects of what a new product would bring. In the end, this may be a less costly approach overall and bring incremental improvements online faster.

Pass the peace pipe

There is no one size fits all solution.

Each company and situation are different.

By taking the time to contemplate some of these options you may be able to come up with a new and creative approach that will enable you to deliver a great solution within the constraints of your team and budget. The strengths of your team, time to market needs and existing product structure all influence this type of decision.

But in the end, recognize the pulling forces between the two tribes and the different mindset required for new product development. If you do this you are well on your way to a more successful engagement.

Employees, Leadership, Teams

6 P’s of really bad leadership OR don’t inspire your employees this way

Leave a comment

Bad leadership can be highly inspirational. It inspires anger, mutiny, frustration, confusion, abandonment, resentment or just plain old apathy. All of which, negatively affect your business.

Use the 6 Ps below to see if you have any of the highly inspirational traits. And find out alternative mindsets for change.

Patronizing

When leaders patronize their team they are sending an implicit message that they don’t believe the team knows what they are doing. It is a message of superiority on the part of the leader. It’s saying “I’m smarter than all of you”.

Patronizing your team chokes the flow of ideas and communication. No one likes being spoken to in this way. It makes you feel like a child and generates resentment. Do this long enough and folks will stop ‘having your back’. That can expose the leader’s blind spots in public and sometimes embarrassing ways.

Smart leaders will use tone, words and body language that encourages dialog and ideas.

Pontificator

A close relative of the “Patronizer” is the pontificator. A pontificator expresses themselves in such a way as to convey that they are always right. And usually, they do it in an overly long-winded dialog. They may allow conversation and listen to other ideas. But at the end of the discussion they make it clear through their speeches that they are the ones who are correct.

This too, is a habit that limits real communication. It makes people zone out. It encourages your team to go through the motions. It undermines team effectiveness. Why bother fighting for a great idea when you have to be brow beaten with long winded diatribes about why your idea is not as good as the pontificator’s idea? People will give up.

Observant leaders will carefully structure their words. You as the leader may be right. If so, then communicate clearly why. Succinctly list reasons or constraints that eliminate other ideas or courses of action. Invite dialog. Explore counter arguments. You may well be right. Or you way well learn something new.

Platitudes

Leaders with nothing substantive to say often resort to platitudes. These statements are worn out cliche’s that have little or no value in the business context in which they are said. They are said so much they are meaningless.

Phrases such as “It is what it is“, or “You never know what might happen” are worthless. Jeff Haden has more great ones in this article.

Resorting to platitudes during a time when real debate, discussion, and collaboration is needed on hard issues will evaporate the confidence of your team in you as a leader.

Effective leaders don’t waste others time with meaningless phrases that serve only to derail substantive discussions. They speak clearly and concisely directly to issues, allowing their team to fully participate.

Petulant

So what happens when you don’t get what you want?

Maybe the software release is going to be late. Maybe you didn’t get the contract. Maybe marketing rejected your ideas on the new website.  Maybe the CEO rejected your product plan.

Do you react in anger? Do you throw a fit? Do you lash out in rage on unsuspecting subordinates when they had nothing to do with the issue?

If you react like this, you are a petulant leader. Think of a three-year-old not getting the toy they want, falling down kicking and screaming. Yeah, you’re an adult version of that.

Having a public negative reaction undermines confidence in your leadership and will cause employees think twice before bringing bad news to you. The bad leadership behavior clogs up the communication pipeline.

Good leaders understand that things don’t always go your way. They react professionally and use these times as learning opportunities. They focus on what improvements they can make when bad things occur.

Pretender

The pretender always seems to have done great things…somewhere else. They can regale you with stories of great business prowess from yesteryear. They are always they one who saved the day, rescued the sale, figured out the bug. They always have accomplishments that no one else has heard of. Pretenders spend more time in the neighborhood of make believe than they do making people believe in whatever they are doing.

The pretender knows the jargon but comes up short on execution and results. Excuses yes, accomplishments, not really. Pretenders are impressive at first glance but with any probing, you see quickly how shallow they are. And pretenders are highly skilled at pointing the finger of blame somewhere else. They wear Teflon jackets.

Fred Brooks said it well in The Mythical Man Month:

“In practice, actual (as opposed to formal) authority is acquired from the very momentum of accomplishment”

Pretenders may have titular authority, but true influence comes from results. Eventually, the pretenders have to move over for those who actually get things done.

Authentic leaders inspire more devotion because their words and actions reconcile.

Parsimonious

These are the leaders that will choke every last cent out of an organization. No toilet paper is cheap enough. No coffee is too watery tasting. No office supply cabinet is too bare for their tastes. Spending the tiniest amount of money, even on absolute necessities, is like pulling wisdom teeth without anesthesia.

Certainly, keeping a judicious eye on expenses is prudent and desirable. But if getting you to spend any money is harder than prying food from the hands of a starving man you are misguided. If you cling to every cent and are so maniacal about costs that you won’t buy sugar packets for the coffee machine you are missing the bigger picture.

There is a balance between expense control and putting out a few bucks to improve the business or treat the employees from time to time.

Balanced leaders know a little spent here and there can go a long way to adding fun,  improving morale and generally making people enjoy the environment more. All of which are shown to improve productivity and engagement. Happy employees are proven to take care of customers  far more effectively than their sad sack counterparts.

So What?

If any of these behavioral attributes ring true for you, the first step to change is admitting you have a problem. If you have leadership tendencies from this list know you can change your habits. These traits may not in singular cases cause you big problems but they all subtly undermine your leadership and effectiveness if the behavior is engaged in on a regular basis.

If you are an employee and see these attributes consistently in your leader or leadership team then it may be time to polish up that LinkedIn profile.

Maybe this was what Grandma was talking about with the admonishment to “mind your P’s and Q’s”.

General IT, Personal Growth, Software Development, Teams

3 more career limiting habits of software developers

Leave a comment

So you as a software developer didn’t have any of the career-limiting habits from my previous post. Great! Congratulations! You’re totally good and on your way to career growth and unlimited success.

But wait, there’s more.

There are many other habits that can severely mitigate your career growth. So here are three more.

1. Lack of thorough testing

So you have completed a feature and think it’s good to go. Your code is committed. You are feeling good about meeting your deadline. The QA folks are unleashed.

Then it happens. Thirty minutes later a problem is found. Oops.

Many times, I have had developers come into my office, proclaiming that a feature or bug fix was completed, tested and ready do go. Then, when external validation started, something was found within just a few minutes.

Granted we all miss things on occasion. But, if this situation happens too many times in your code, you might be forming the habit of lack of thorough testing.

There are many reasons this occurs. Everything from time pressure to just plain laziness can contribute to this. Sometimes it’s a lack of environmental understanding or unclear requirements. Regardless of the origin, this habit will severely curtail future career opportunities.

You can overcome this by using TDD, BDD or similar methodologies where appropriate. Thinking “testing first” can help you identify and code for those issues up front. Even if your organization doesn’t make formal use of test-driven development methodologies, you should still spend some time thinking through all the ways your code could fail and make sure you handle or document each one. Making that a habit will reduce the chance of an embarrassing situation with your boss or QA just minutes after you pronounce something done.

2. Lack of communication

For an application that is larger than one person can manage, there is a natural migration to particular areas of expertise by the team members.  Alice knows the database interface, Bob knows the CSS and front end, Sarah knows the business logic, Arun knows the device drivers and so on.

We all build silos of information and expertise. This is good and helps us provide value to the organization.

The career limiting aspect occurs when we withhold knowledge (either implicitly or explicitly) that could help other team members. The lack of free flow of information across developers reduces productivity, increases the odds that defects are found late and reduces overall department effectiveness.

If you become known as the person who “knew that last week” but didn’t bother to share with the team, you will become a pariah. The team members who could have benefited from that information will grow to resent you and begin to exclude you, exacerbating the problem of team effectiveness.

It’s a good habit to err on the side of too much communication as opposed to not enough. In the end, you will make the team more productive and be seen as a better team player and better example. It’s a karma-enhancing habit if you believe in karma. 🙂

3. Being a “One trick Pony“

Software tools and technology move at a rapid pace. The hot technical tools and trends of a few years ago become the archeological artifacts of tomorrow.

Back in my high school days, I was pretty good at BASIC.

Guess what. Nobody cares.

If I still relied exclusively on my ability to do BASIC for employment, if I had made it my ‘one trick’, I would have starved long ago.

I moved on to other more mainstream technologies over time such as FORTRAN, C, Perl, Python, PHP and the like.

If you, as a developer, acquire the reputation of being able to only do one thing, it will, over time, severely limit your opportunities.

Think about how technology has changed in just the last 10 years, then extrapolate that out over the next 20 or 30 years. We all better be embracing change. In the future, the most important skill could be the ability to learn new things.

Over a 40 or 50 year, career time span it is imperative to stay relevant. The saying goes “Adapt or Die”.

If you become a ‘one trick pony’ you will be limited in the opportunities that are available to you.

Conclusion

Hopefully, none of these describe you. However, if you have any of these tendencies, now is the time to change your habits so you can reap the future benefits.

 

 

 

 

Development, Product Management, Software Development, Teams

One simple method to improve the design of your next software app

Leave a comment

The late Stephen Covey, in his seminal book “7 habits of Highly effective people“, wrote that one of the 7 habits is: “Seek first to understand, then be understood”.

An effective way to “seek first to understand” and  communicate with someone is to put yourself mentally “in their shoes”. This is the essence of the habit Stephen Covey introduced in his book.

In High School debate, participants prepare to argue both sides of a presented issue. This means a debater has to thoroughly research, understand and prepare cogent arguments for both the negative and affirmative sides of the issue.  The debater has to put themselves in the shoes of both a supporter and detractor of the issue. The best debaters do this well.

This same metal exercise can also improve your next software application.

Key Mental Exercise

By changing mental viewpoints and analyzing the software project from the new point of view, you can become aware of new issues to solve or new opportunities and features. You can do this regardless of your role on the team.

This exercise helps prepare you for the client meeting, that big design review or the next sprint planning session. It can help you work more closely with the product owner and improve your design and plan.

If you are one of the general roles of a project team, forcing yourself to mentally assume the viewpoint of the other roles in the software project will improve communication, understanding, planning, and results.

Forcing yourself to assume the viewpoint of other roles in a software project improves results. Click To Tweet

7 viewpoints of a software project team

Here are seven viewpoints you can use in your mental exercise:

Designer

The designer creates the look and feel, screen flow and color scheme and page layouts.

Designers are concerned with creating a compelling user experience in a style that complements the genre and use of the application. Style, simplicity, cognitive load, and utility are  key concerns the designer has.

If you are not the designer, you can consider methods to express style, or improve the usability of the app.  Realize there are many opinions that influence the aspects and implementations of design. Many times there is no one right answer. The designer has to arbitrate these, sometimes conflicting, opinions.

Developer (coder)

The developer is the person (or team) actually doing the coding of the application.

The coder has to worry about the execution environment, standards, tools, compatibility across consumption devices, security, language implementation, performance and 3rd party services, code libraries and API’s that will be used.

To put yourself in the shoes of the developer, consider the job of a translator, translating one language to another. There is a lot of work  and knowledge that goes into translating a language. Nuances such as tense, idiom, gender and the like add complexity as well. That’s essentially what a developer does, translating the requirements and desires of the team into software, but also with a lot of other constraints.  Many of the constraints coming from the environment and devices that have to run the app.

Project Manager

The project manager is responsible for schedule and resources.

Their big concerns are resource utilization, schedule, milestones, reporting, test results and barriers to completing the tasks. And, if the project manager doesn’t have direct reporting control of the resources, their job is much more difficult.

To envision their world, think about being the director of an elementary school orchestra. They attempt to get all the band members set up with their instruments and music, on key, and on tempo so that what the orchestra plays will actually resemble music.

Owner

This is the person who is funding the development. The business owner or VP who is sticking their neck out (and budget) to get the project done.

To think from the owner’s frame of reference, consider making a large purchase with your own money. Writing a big check out of your own account always gives you pause. It motivates you to thoroughly investigate the value of the purchase, the terms, guarantees and warranties and lifetime costs and service. You don’t write big checks out of your own account without sufficient reassurance that the purchase is a good one. Thinking about the owners situation in this manner helps you better evaluate the value proposition, return, and on-going or hidden costs. All of which are key concerns for the owner.

Customer

The people who actually pull out their credit card and pay for and use the app you are creating.

They will have lots of needs and questions. Why should they buy? How will they realize value? What will their pain points be? How will they consume the app?

All of these and may more questions will have to be answered in order to produce a product that is valuable and has utility for the customer.

Competitor

Consider those companies with products already in or directly adjunct and selling to the market space you will be in.

What are the pain points of the customers of your competitors? What is the competitors unique value proposition versus that of the app you are building? Why would customers potentially buy from your competitor and not you?

Answering these questions will provide greater clarity about the market position, value proposition and relationship to existing competitor offerings.

Maintainer (another developer)

The maintainer is the poor souls who come after the initial release to clean up after the parade and maintain the app and system that was created.

What documentation will they need? How can you structure the app code to improve maintainability?

The maintainer will be the person fixing bugs, adding features and making other needed additions and improvements. Making their life easier through well architected and written code, template based screen layouts, comments and a software spec will speed maintenance activities lowering long-term cost of ownership.

Summary

If you spend a little time, thinking about your project from the viewpoints of the various roles, you will be a better team member, facilitate better communication among the team and make the project go smoother and improve the results.

Work on assuming the viewpoint of others to more deeply think about your application, improve your results and reap the rewards. And, who knows, you might make it a habit.

Employees, General IT, Leadership, Teams

The single biggest IT risk in small business and 9 ways to deal with it

Leave a comment

The dependence of small business on IT systems and the people who run them increases continuously. Whether the accounting systems, corporate web site, inventory system, the online shopping cart, marketing automation, email servers, the customer management system, internal database servers, manufacturing automation servers and the like. The list goes on and on. Without those IT systems, business grinds to a halt. And without the people that maintain them, you risk business grinding to a halt if something goes awry. IT systems have loads of risk vectors. Hackers, Malware, viruses, ransomware, hardware and software failures and the like.

However those don’t create the biggest risk a small business owner has with respect to IT.

The biggest IT risk a small business owner faces is being unprepared for the loss of a (or the) key IT person or key software developer.

Examples of the key person(s):

  • The developer who wrote the code for the product.
  • The sysadmin who knows all the configuration and passwords.
  • The director who knows where all the vendor logins are including the payment processors.
  • The development architect who knows how all the systems fit together and where the vulnerabilities are

Losing any of these types can be hard on a small business. If your business has several of these people in one person then you are at a HUGE risk if that person walks.

What can you do to mitigate the impact if that key person is gone?

Here are 9 steps that can help when that happens.

System configurations backed up

Make sure that the existing staff has backups of key system configurations saved in a known location. Firewalls, key routers, switches, IP addresses of networks and servers and other company configuration setup should be saved in a known and agreed to place that the owner knows about and understands how to access. This should be also documented.

Login/Password locker

It is wise to use a corporate password locker such as 1Password or Lastpass. Key system passwords should be stored here with the master password to the locker available to the owner.

System diagrams

Simple block diagrams should be in a known location that diagram key systems, how they are connected, where they are located etc. This will enable the owner to help locate systems in case an issue arises and will help them direct new personnel or vendors when repairs or service is needed.

Key 3rd party vendor information

A list of all 3rd party vendors that are used by the IT / Development teams should be kept in a known place. Contact information for the account representative, as well as services provided and key contract or agreement details.

Backup locations

The locations of on-site backups of systems should also be documented. Additionally off-site backup locations and / or vendors should be detailed in the 3rd party vendor section.

Process and procedures and site/documents

The owner should know the processes used to get IT and development work done, including how to deploy system updates for key servers, web sites and online apps. If for no other reason than to train the replacement employee.

Monitoring Notifications

If your company uses automated monitoring such as Icinga or similar, then the owner or replacement personnel need to be added to the notification list.

Job Descriptions

A documented set of job descriptions will help in the hiring process after the key person leaves. This will give the owner more detail on what the key person does, and the attributes and skills needed in a replacement employee.

System/Content Deployment steps

The steps, logins and other necessaries required for making site or system updates to key systems need to accessible and understood so that another employees or the owner could execute them or show them to a contractor in a pinch. You may think this is far fetched but if something happens you want to be able to update content and code if needed.

Final Thoughts

As part of your on-going training and planning it would also benefit the company to conduct a risk and vulnerability assessment so that key risks are known and can be planned for. Additionally, transitions can be planned for as well with succession planning as part of leadership/career development and key employees being cross trained regularly. Finally, the owner should audit these areas periodically to validate readiness and expose weaknesses.

The above 9 steps won’t eliminate the pain of losing a key employee but they will enable the business to move along and speed the on-boarding process of the replacement. The wise small business owner will do well to track and keep up with these areas.

 

Employees, Personal Growth, Teams

B.A.K.E. your employees for better annual review results

Leave a comment

In the previous post I talked about the need I had for a more consistent form of employee evaluation and feedback.

What I needed was something quick, direct, clear and actionable.

The B.A.K.E. Method

What I came up with was a simple table, on a single piece of paper called the B.A.K.E. Sheet, that captures short written elements for each of 4 areas:

  • Behaviors
  • Attitudes
  • Knowledge
  • Execution

Behavior

This is what I (or other employees) observe you doing. These are the actions and interactions of your work. Your words, actions, gestures, and the overall way you conduct yourself in the workplace (or outside it – thank you social media).

Attitudes

These are the mental patterns, thinking, bias’s and mindset that drive behavior, speech and motivation.

Knowledge

This is the expertise of the employee, what they know. It is the skills and training they have or need to get the job done.

Execution

This is how they apply all of the Behaviors, Attitudes and Knowledge coupled with processes and procedures/tools to get the assigned task or job done.

The B.A.K.E. table has 2 columns, one is “Observations” and one is “Desired/Comments”.

How to B.A.K.E. an employee

Every few weeks you sit down with the employee and summarize what you have observed and what needs to be changed improved or doubled down on using the B.A.K.E. sheet. By doing this you have the feedback loop as part of a regular interaction with employees. Necessary changes are discussed more. Incremental improvements can be recognized and rewarded where appropriate. Other circumstances can be responded to as required.

The point is that the discussion occurs on a regular basis. What you end up with is a more engaged workforce and one that has more regular improvements. Regular touch-points also foster a more continual dialog about culture and values that drive the desired outcomes in the 4 B.A.K.E. areas. Its like AGILE for feedback management.

After doing the B.A.K.E. method for a year, the annual review becomes more of a formality. But one that has fewer surprises and more concrete milestones to review, and like a good cake will taste better after its thoroughly baked.

 

Employees, Personal Growth, Teams

What does an oven have to do with better employee reviews?

2 Comments

It seems its a continual struggle to consistently get and give good actionable feedback to employees.

Annual Review Surprise?

I hate annual reviews where the employee seems surprised by the revelation of some undesirable behavior or action that hasn’t been as clearly discussed as needed along the way. Especially if that employee is me.

Effective employee feedback in 2 forms

Effective managers give feedback at the point of need, whether good or bad, in One Minute Manager style. While this is good, and immediate, there needs to be a more concrete long term environment where change and improvement can be discussed, planned, encouraged and agreed to, regularly. This promotes  change in smaller increments. The discussion gets easier when it’s regular and part of the culture. It builds relationship. Feedback, in the absence of relationship, especially critical feedback, usually yields defensiveness. However, feedback in the presence of relationship, while still difficult sometimes, is more trusted and more likely to be acted upon. So the question is how do you do that type of feedback?

But do you have the right tools?

The times I have worked for large corporations they always had what I called “Performance Review DeJour” where online tools or documents were available to help the feedback process. And these were changed very regularly. However, being at a small company, or being a small business owner, can mean you don’t have access to these formal tools or methods.

So what is needed is a simple form that allows for the easy and regular capture of simple elements of feedback to the employee. Something that could be done on one sheet of paper (or screen). Something that would only take a few minutes but provide clarity and actionable discussion points.

In the next post I will share what I came up with, that is how you can B.A.K.E an employee to better results.

Employees, Leadership, Teams

How emotional immaturity is like a clogged toilet and what you can do about it

Leave a comment

There are few thing more unpleasant to deal with than unclogging a toilet. Over the years I have heard those famous and dreaded words several times, “Dad, the toilet is clogged, again”. I am not sure who decided it was Dad’s problem when the toilet clogged but I would like a re-count.

Thankfully, most of the time the remedy is quick and the problem is literally flushed away in a few moments. Sometimes, however, the problem is more serious, messy and in need of professional assistance.

The last time this happened, while I was correcting the clog, it occurred to me that this is exactly what happens in teams of people where emotional maturity is lacking in one or more of the team members.

Emotional immaturity creates situations where things that should be flushed away quickly hang around and clog up other normal interactions and operations. And, like a clogged toilet, if they hang around too long things get ugly and very unpleasant fast. And everyone notices.

I have found that in order to best deal with these situations you have to act quickly as a manager or leader. The longer the situations are left hanging in the air the more team chemistry can be damaged.

So what can you do about an emotionally immature situation?

I have found that a quick, low key dialog as close to the point of the issue or incident is best. Think Ken Blanchard’s One Minute Manager. Try to be calm and focused, directly pointing out the observed issue, and desired action. Before you engage with the person, mentally rehearse what and how you need to say and try to anticipate their responses. If I am calm and low key in my approach I have found that the employee or colleague is more receptive. In most cases employees respond well and the issue is ‘flushed away’ and things are better. Most employees want to improve and when presented with actionable opportunities they will work to improve.

But what do you do when emotional issues  don’t change?

Some people lack the emotional maturity to handle basic relational situations like clear, open or honest communication, confrontation, conflict, compromise, or forgiveness. In other words, they missed the day in Kindergarten when getting along with others was taught. Others  remain emotionally opaque and can’t have meaningful relationships while some are just plain mean, devious and vengeful. These are the kind of people that can really ‘clog up’ your team and company.

In cases where someone is in that situation they have to learn and choose to make different choices, let go of anger, forgive, adapt, grow and become more open. It’s not easy. That person has to have a recognition that there is a problem and a willingness to make changes. Some folks can do that, others choose not to. And here, sometimes a professional is needed.

It’s not me it’s YOU

At one point in my career, there was a team member who basically operated with the attitude that if you ever did them wrong (actual or perceived) you were written off and nothing would change that. That person chose to remain full of anger and resentment toward their perceived injustices which led to deep seated bitterness. Their actions and attitudes created a negative atmosphere and affected team productivity and cohesion. Coaching, closed door meetings or pleadings could not change their anger or resentment toward the situation or the other team members.  And, in that case, it only got better when that person was no longer with the company. In this case, I was a victim of the sunk cost fallacy. I had already invested a lot of time and effort in trying to improve the situation so I didn’t take the necessary action when I should have. The delay hurt the team, the individual involved and me.

Necessary Changes

As a manager or leader in this situation you have to decide how critical the issue is, how disruptive it is to the team and how that on-going situation affects the department or company. You have to decide if the contribution of that employee is worth the disruption. Most of the time it is not. When your threshold is crossed and other forms of redress with the employee have not worked, you have to act in removing that troubling employee, either by re-assignment, moving to another department or division or firing them altogether. Dr. Henry Cloud, in his book “Necessary Endings” lays out clear guidelines and methods for these situations. I highly recommend it.

On a team that is operating at a high level, one bad apple can affect the whole lot. It is better to deal with issues while they are still small than to wait until the mess is really bad and stinky later.

Now, where is that plunger????

General IT, Small Business Purchase, Teams

Why You Need an IT Professional on Your M&A Deal Team

Leave a comment

This article first published at the Axial Forum here: Why you need an IT professional on your M&A deal team and is reposted here with permission.

Traditional M&A deal teams run the risk of missing substantive issues that could impact deal structure, terms, and integration success.

Where does this risk come from?

Often the answer is simple: a lack of informational technology (IT) visibility.

Most M&A deal teams comprise accountants, lawyers, M&A professionals, and executives. These are the small teams that engage and form the deal framework with a target firm.

This small team approach can work well and move quickly. But business today is increasingly IT dependent, and these teams may overlook crucial items that could make or break a deal.

How can M&A deal teams mitigate this risk? Involve IT professionals as part of the deal team to help assess a broad overview of the IT landscape of the target firm and identify any substantive issues that may exist early in the deal making process.

This may seem crazy to some. Traditionally, IT is viewed a functional unit of a business — far down the food chain when it comes to M&A deal making. Information technology is not considered at the beginning of the process unless the acquisition is IT-related.

However, here are six reasons that an IT representative should be involved in your next deal team.

1. Pervasiveness

Even small market firms have a significant IT footprint these days. Every department in a typical business has dedicated information technology systems to handle their day to day business functions. There is marketing automation, accounting, resource planning, point of sale systems, human resource systems, production management systems, customer relationship management software, database management systems and big data analytics software, to name just a few examples.

These are the simple cases. Entire departments can be completely dependent on IT systems to fulfill their duty to both internal and external customers. We are almost numb to the pervasiveness of IT. Like electricity, as long as it works, we don’t take much notice.

This out-of-sight out-of-mind attitude can blind an acquirer to potential deal trouble spots. Since IT impacts each business area, it’s important to identify major obstacles and issues early in the deal process.

2. Complexity 

As the pervasiveness of IT systems increases, so does their complexity. Servers, databases, networks, cloud storage, security firewalls, authentication and security systems, third party APIs, and open source software stacks are the hidden components of visible business technologies. It is here, in the maze of hidden components, that potential problems lurk during deal formation.

As a business scales, the number and interconnectedness of these systems increases. It is easy to conceptualize a corporate web server. However, that simple concept can have a complex implementation. For example, it could be that the corporate web server is really several cloud virtual machines behind a load balancer using shared common storage and front end proxy caches for static element distribution and a content delivery network for serving corporate media. (And this is just a small piece of the potential IT complexity in a small to mid-size corporate acquisition.)

Getting a bird’s eye view of the complexity of the IT situation can help deal makers better understand the impact on price, terms, and deal structure as well as improve integration planning.

3. Business Impact 

If a target firm is desirable to an acquirer from a financial or operational perspective, chances are its IT systems will have a direct impact on the business. Effective IT systems can bring significant competitive advantage to a company through automation, proprietary function, scale, and features. The acquirer needs to make sure that they can realize and potential improve upon these advantages after the acquisition. Having a high-level view of the business impacts of the existing IT systems can give the deal team unique insight into ways to further leverage those capabilities post transaction, thus improving potential ROI of the acquisition.

4. Cost

According to Bain Capital’s Will Poindexter and Vishy Padmanabhan, the single biggest impact on general and administrative costs for many companies is IT. Deal teams should consider early on the condition and strategy necessary for the target business’s IT functions. The current condition of IT will have a big impact on future cost trajectory. Poindexter and Padmanabhan use three archetypes — “Neglected,” “Indebted,” or “Gold Plated” — to describe, at a broad level, the conditions they have found in their engagements.

Each archetype will have its own impact on future costs and investments needed post transaction. Much like a high level financial assessment is done to justify pursuing a deal, a high level IT assessment should be done up front as part of the early engagements. Hidden costs, true condition and implicit assumptions regarding the financial needs of the target firm’s IT structure should be revealed and known to the deal team.

5. Security Liability  

Not a day goes by that there is not some news story about a hacked company website or stolen corporate database of customer information. The impact of a data breach can be expensive at least and debilitating at worst. According to the IBM’s 2015 Cost of Data Breach Study, the average consolidated total cost of a data breach is $3.8 million.

Because of this potential liability, an acquiring firm absolutely needs to fully evaluate the security capabilities and practices of a target business during due diligence. However, certain key elements of a business’s security architecture, policies, and practices should be discussed and reviewed during early deal discussion. Having this information early will give the deal team an indication of how the firm approaches security. Knowing this will facilitate a more accurate assessment of potential risk and immediate mitigating actions needed post-transaction.

6. Expectation Management

Integrating IT systems can be the largest part of a merger or acquisition. Differing systems, tools, protocols, and implementation architectures or tools can complicate integrations significantly, impacting timelines and ROI. If some of the thornier issues of a potential IT integration are known at a broad level during deal formation, it’s easier to create more realistic timelines for closing and merging. This knowledge can also help the deal team more appropriately staff the integration teams needed to complete the merger or acquisition.

Summary

An engagement with IT during the deal phase can help identify red flag areas that will need extra due diligence or that can impact deal structure and negotiations. Knowledge of the IT situation by the acquiring firm can also provide leverage points during negotiations and enable the acquirer to factor in early impacts from IT risks, costs, or additional investments that may be needed. Ultimately, knowing, considering, and planning to mitigate IT related factors and issues early will contribute to a more successful M&A outcome.