Tag Archives: Small Business IT

Development, Software Development, Technical Debt

4 ways every business is increasing technical debt and how to change that

Leave a comment

We all like to think what we do helps move our business and products forward.

But………

Sometimes subtle, embedded habits and tendencies we have actually increase the rate at which a business accumulates technical dead. Which of these does your business have?

Short Sighted Executive Decisions

You have been in those meetings.

You know the meeting, where the executive in charge slams their hand on the table to get everyone’s attention after an extended debate.

And then, with red face of anger and the decibel level of a 747 on takeoff, bellows “this product will ship on time“. 

This display is usually accompanied by promises of some sort of employee  retribution if the fantasy date is not met. It is at that point the meeting is really over and no one will dare raise any additional points no matter how real and urgent they are. 

Using emotional outbursts to attempt to motivate a team doesn’t create technical debt per se. However, it is the short-sighted executive decision making that results in this environment will create technical debt.

There may be valid reasons why the product can ship on time. However, there may be serious issues, just under the surface, that could cause the company big problems if the ship date is met.

Astute executives ask penetrating questions, validate assumptions and create productive dialog. Click To Tweet

Astute executives ask penetrating questions, validate assumptions and force the analysis and discussion that create productive dialog. It is only in an environment where subordinates and colleagues feel safe in disagreeing or bringing bad news that all issues can be on the table and then dealt with appropriately. Otherwise, things that could be real issues get covered up, hidden, or ignored. And when issues and technical debt builds, are you can rest assured they will pop up later at the most inconvenient time.

Management Short Cuts

Typically managers take short cuts that build in technical debt for two reasons: 1)because they are incompetent or 2)because they are trying to make points with the boss by finishing earlier, cheaper etc.

Incompetent managers yield all kinds of pernicious evil in software or IT implementations. They can hire the wrong employees, force inadequate or inappropriate implementations, misunderstand technical requirements, force the use of the wrong tools or rewarding the wrong behaviors. The results of these managers will always cost more, take longer, disappoint, and need large corrective actions.

The brownie points gang are those managers that always want to have the right answer.

“Yes we are on schedule”

“The project is coming in under budget”

“Yes we can add those all those new features” 

“No, that change won’t affect our delivery capability”

Looking good is more important than reality and truth. These types of managers are skilled at making themselves look good and figuring out some other person, group or division to take the fall when things hit the fan.

Adroit managers work to always increase their competence through training, assignments, asking questions, checking assumptions and working closely with their teams. They understand that by continual growth and disciplined execution they will impress their bosses and it will be real.

Developer  Laziness

I was recently working on some software and came across a whole section of code that had been copied identically and only a couple of  lines changed to accommodate the different situation. This is a perfect example of developer laziness. Instead of taking the extra mental effort and time to create a method to do the work so that it was encapsulated in one place,

This is a perfect example of developer laziness.

Instead of taking the extra mental effort and time to create a method to do the work so that it was encapsulated in one place, technical debt was created by copying a bunch of code unnecessarily. It may have allowed the developer to quickly get work committed but built in a headache for someone else to deal with later.

Skilled developers understand when small refactoring can save huge time later. Click To Tweet

Skilled developers understand when small refactoring can save huge time later. They know when it is worth it to make additional small investments to avoid bigger problems later.  Invest in resources to train developers on your systems, standard coding best practices, and effective coding refactoring processes.

Team capability

What’s your team training plan look like?

Do you cross train?

Are you encouraging them to learn better methods of coding or testing or implementation?

Are you giving them tools to improve code, deployments, or testing?

Is continual learning part of your culture?

If you don’t have answers for these questions for your team or yourself then you could be inadvertently building technical debt in future implementation.

The technology software and IT is advancing at an ever increasing pace.  Your organization has to adopt an adaptive, learning mindset to stay up with advancements. And incorporate them to give your business advantage.

Improving teams create and execute training plans for the tech they are involved with. They set expectations for learning, growing and utilizing what they learn to improve products, productivity, and performance.

 

General IT

Simple ways to deal with V.U.C.A. IT in small business

Leave a comment

If you have realized that  your small business IT is a V.U.C.A. environment, then you may wonder why do I care? Lots of things change around us all the time. So why does it matter with IT?

There are many reasons that V.U.C.A. in a IT needs to be mitigated when possible. V.U.C.A. in your IT environment can lead to things such as:

  • Increased system outages
  • Lost data
  • Security risks and breaches
  • Lost revenue
  • Increased costs
  • Diminishes efficiencies
  • Customer service troubles

to name just a few.

These are bad. No one wants any of them. So a natural question is:

What can I do to reduce the V.U.C.A.?

Here are some simple ways to help deal with the V.U.C.A. in your environment:

Volatility

  • Monitoring – use monitoring tools in your IT environment. You can monitor for intrusions and security risks, viruses, malware and operational thresholds. Open source software such as Icinga allows you to create custom monitoring scenarios and report on many different system variables. A well architected monitoring system is like having extra IT staff working 24 hrs / day 7 days a week.
  • Redundancy – The most important parts of your IT system should have redundancy. Simple things such as mirrored hard drives on a key server, multiple disparate backups and .
  • Contingency – The building where we office now has had many power issues in the last few years. Having a contingency to run our services elsewhere is a huge help for us. Think about if you lost a key server, or your phone system went down. How could you continue serving customers until the problem is resolved?  If possible you want the ability to run key applications offsite if a severe problem exists.
  • Margin – Leave yourself operating room. Don’t run servers at 95% load all the time. Give them plenty of memory, stay out of swap. Don’t allow key server hard drives to always be near full. Have some spare equipment. If you are taxing your internet bandwidth constantly get some spare bandwidth. Having some excess capacity in these areas can reduce risk.

Uncertainty

  • Focus on what you can control – Take care of maintenance items. Update patches, install security updates, monitor hardware, check access logs. Verify backups. If you make simple maintenance tasks like this part of your regular routine you will be better prepared for the inevitable surprises.
  • Prepare – Have some key spare parts. Make sure your hardware warranties are up-to-date and your equipment is still serviceable. Have the contact details for each supplier and vender available and documented for your team in case of emergencies. Create an escalation procedure for increasing the scope of notifications when problems arise.
  • Learn – when things out of the ordinary happen take time for an ‘after action review’ with your team. What can you learn to prepare for or avoid the problem the next time it might happen. Update your procedures and operating practices to include any new thing you learn.

Complexity

  • Pictures and diagrams – Draw out how your systems are connected and configured. Where is key equipment located? Who are the assigned people responsible for each area? Are the vendor contacts included? How would someone get access to systems if assigned personnel were not available? Simple pictures and diagrams updated regularly and distributed to the team and can help you deal with crisis much faster and more clearly.
  • Online Notes/Wiki on company intra-net – provide a convenient, accessible location that everyone knows about to document and notate your key data. You should be able to ask anyone in your company and they would know where that is.
  • Labels – Label cables, computers, routers, cabinets and other devices. Labels help with inventory and provide quick verification you are working on the right equipment.
  • Screen casts – For multistep instructions you can record screen casts and save them to your online notes  / Wiki area. For configurations or setups where a number of online steps are involved a quick screen cast can communicate very effectively what it takes pages and pages to write.

Ambiguity

  • Modeling – When possible use simple models to illustrate functionality. Sometimes this can be done with maps, drawings or, where numbers are involved, with spreadsheets. Simple, clear models help clarify concepts and communicate more clearly abstract ideas,
  • Iteration – When building new systems or adding functionality break down big features into smaller iterations. Smaller iterations, allow you to engage key stakeholders throughout the process, keeping everyone closer to the same page. Iteration is one of the foundational ideas of Agile development. It applies very nicely to a wide range of system domains. Use iteration to fight ambiguity.

None of these ideas are revolutionary or difficult. They are all well within the capability and resources of small business. And they all will help you better deal with a V.U.C.A. environment.

General IT

Is your small business IT a V.U.C.A. environment?

Leave a comment

V.U.C.A. is an acronym the military (and others) use to describe an environment that is: Volatile, Uncertain, Complex and Ambiguous. While the military uses this term to describe what can happen in war and battle, it also describes what can happen in business IT.

What does V.U.C.A. look like in IT?

Volatile

Webster’s defines volatile as “likely to change in sudden or extreme ways”.

In IT, things occur unexpectedly. Hard drives fail. Fiber cables are cut. 3rd Party vendor API’s change. Prices increase. Hackers hack. The power goes out. Routers are mis-configured. Owners change their mind. Web servers go down. Developers break the build. Owners change their mind some more. Your biggest customer cancels a contract. All of these can occur randomly and without warning. And each can have a great impact on the life of the IT manager or director.

Uncertain

Uncertain means “not exactly know or decided, or not definite or fixed”.

Users think they know the requirements but then they are not sure. They waffle. They change their mind. They decide they don’t need th 5 screens you built for the last sprint. They are not sure what the screen forms need to present to the end user. The client can’t make a decision on the database implementation. The business owner flip-flops on system design issues causing the team to whipsaw. Key vendor software updates are delayed and you don’t know when they will be delivered which impacts your sprint planning. The higher the uncertainty the less likely we can move forward confidently. High uncertainty makes it difficult to act decisively.

Complex

Complex is a “group of things connected in complicated ways”. Surely the editors at Webster’s were thinking of IT when they wrote that definition.

The small business environment is growing more complex all the time. Every department has online tools, software, services, API’s, databases, reports, virtual and real servers, user compute devices and on and on. The inter-connectedness and dependencies require dedicated effort and skill to comprehend, troubleshoot, maintain and improve.

Ambiguous

Ambiguous means that something has “more than one meaning”. To quote Steve Jobs: “Customers don’t know what they want until you show them”. Frankly neither do most project managers, product owners or anyone else designing  a system or process. What you are told to do by the client, customer, owner or other person in charge is usually just a vague notion, leaving the technical team to fill in tons of details. Clarity is an illusion in most every project.

 

Now What?

Does this describe your IT world? I am sure that more than one of the scenarios above struck a chord with you. Maybe a lot of them.

In my experience this describes the state of most small business IT.

So what can the dedicated IT professional do in order to still make progress and serve their customers? How can you bring some order and certainty to your IT world in a VUCA environment?

It turns out there is a lot you can do and we will cover those in the next post.