Category Archives: General IT

General IT, Software Development, Workplace Automation

4 key Data tools to advance your IT or software and data career

Leave a comment

Whether you are a system administrator or you write real time avionics control software for military jet fighters there are some common tools that will enable you to do your job better and handle many scenarios with ease.

They may not be part of your standard day to day tool chain but they can enhance your corporate value and situational agility.

1. Excel

No matter where you go Microsoft Excel seems to be there (or Google’s Sheets).

Excel is a swiss army knife of data manipulation, analysis, computation and modeling. There are a lot of use cases for software and IT staff where excel can be your goto tool.

I use Excel regularly to

  • Clean and normalize data
  • Rearrange data to suite some new need or analysis.
  • Summarize data quickly with Pivot Tables.
  • generate executable code for putting into other programs.
  • Automate tasks (yeah VBA ….)
  • Advanced analysis and optimizations
  • Convert data formats
  • Modeling
  • and more…

The filtering in the data view or (tables) is hard to beat for super fast analysis and getting quick answers. And the newer versions support PowerQuery/PowerPivot which gets you beyond that annoying 1 million row limit!

Technical employees would do well to maximize their understanding of this very powerful tool (and its web kin).

2. SQL (Structured Query Language)

If French is the language of love, then the language of data bases is SQL.

SQL is how you ask a database questions. In the simplest example you can select data from the table you are interested in.

SQL is harder to learn for beginners but is very powerful. With SQL you can not only select data you want from a database but you can do complex computations, transformations, data summarizations and ranking, data partitioning and joining together of data from separate tables. 

There are several very popular powerful databases that you can download for free to learn such as MySQL or Postgres

Knowing basic SQL WILL enhance your value to an organization and give you new opportunities for advancement and assignments.

3. Python and the Python Data stack

If SQL were a bulldozer then Python and the Python Data stack is a whole fleet of earth moving construction equipment.

Python is a very approachable yet extremely powerful programming language for those new to programming and is easy to learn. Python has tons of built in capability and loads of add on libraries that make the most sophisticated analysis and data mining doable.

Python can help you automate the boring stuff and make tedious data work quick and easy. And python runs on all the popular platforms like Windows, MacOS and Linux to name a few.

I use Python in many ways to automate tasks, connect disparate data sources, perform analysis, build synthetic data sets, serve web pages, send emails,   process tons of data and generally enhance my life.  I also use python do automatically generate Excel spreadsheets too.

Adding Python to your personal skill repertoire is a huge value add for your technical skills.

4. PowerBI

Microsoft PowerBI has quickly become one of the most powerful and popular Business Intelligence packages. If you need to connect to a variety of data sets and perform analysis and publish dashboards of results PowerBI is your tool.

PowerBI is Excel overdosing on steroids.

With powerful data connection tools, data modeling and programming tools and a bevy of visual presentation widgets to make impactful analytic dashboards PowerBI is a data powerhouse.

Businesses are embracing PowerBI for its power, cost and flexibility to allow data connection, gathering, computation, transformation, presentation and communication to staff, employees and customers.

Conclusion

All four of these tools are widely available and used, not expensive, and very powerful. They will definitely give your skill set a boost and your productivity too!

Development, Employees, General IT, Hiring, Leadership

The 3 components of value for an IT/Software Development employee

1 Comment

How do you assess the value of an individual job?

How do you assess the value of an individual employee?

What makes you valuable to the job market?

What makes you valuable to a specific company?

How does value correlate to salary? Or does it?

Continue reading The 3 components of value for an IT/Software Development employee →

Customer Engagement, General IT, Security

7 deadly sins of IT

Leave a comment

I happened to overhear yet another conversation where some non-IT folks were discussing how they could get around IT. They were justifying their actions based on the lack of responsiveness of IT in general to their needs.

This is a common theme I have seen. Technology vigilanties bending the rules to get around the very team that supposed to help them solve technical problems.

Much of this attitude comes from the 7 deadly sins of IT.

Tech speak is not your first language

Nothing communicates implicit condescention more than using vocabulary and phrases that are are unknown to your audience. Technology is filled with words and acronyms that non tech professionals and employees don’t know or understand.

If you are fluent in tech speak and your immediate customer is not you can confuse them quickly and easily.

I have seen IT folks deliberately tech speak to the non-initiated for their own fun and sport.

The deadly sin here is that instead of being a problem solver and technical guide, the IT personnel who engage in this behavior lose influence with their customers. Their customer can’t understand them. What customers can’t understand they won’t value. Customers will find other ways around IT to get their problems resolved. Hello shadow IT.

Would you like IT attitude with that?

Most IT folks are pretty smart. After all they are dealing with computers and networks and software which can be pretty complex stuff. It can be a pretty heady vocation.

Being smart as evidenced by your sagacious problem solving and astute solutions is one thing. But having the attitue that you (as an IT worker) are smarter than everyone else because you are in IT is another deadly sin.

The thing is most employees bring their own type of ‘smart’ to their job. Just because they don’t know tech stuff per se doesn’t mean their smart is less valuable. It’s just different.  A business requires different types of ‘smart’ in order to succeed and grow. IT smart is just one of them.

Ignoring the customer

Another deadly sin is creating solutions while all the time ignoring or not involving the customer.

Too many IT groups still operate under an “IT knows best” pattern. This leads to ignoring the customer in the pursuit of solutions that IT deems necessary.

The result is that the customers needs are not met, and they are forced to look elsewhere to get the solutions they need. More shadow IT.

Means and not the end

IT is a means to an end and not the end. Unless the revenue generating product is IT, then, of course, IT is the end.

In most companies IT is needed as a means to an end, such as to improve productivity, or speed production or aid compliance. IT is a utilility that helps the business get it’s job done, faster, cheaper and with higher quality.  And it should be a responsive utility to get the best results.

Too many times entrenched IT interests believe themselves to be the end. This deadly sin results in empire protecting and dedicated adherence to the status quo. Both of which are suffocating to a business. This jurrassic mindset will go extinct just like the dinosaurs, hastened by a flood of easy to use, online, inexpensive and disruptive services.

It’s the paradigm stupid

IT camps can also fall victim to the sunk cost fallacy. Unchecked this deadly sin can yield the ‘we have to do it this way’ attitude.

Your business needs may call for new thinking or a different solution. But, because of previous investment in systems and personnel, you try to meet that need with what you have always done. Even if that’s not what will work.

When all you have is a hammer everything looks like a nail, the old saying goes.

We have high standards

Standards are necessary. They reduce variation, expenses and help with more consistent results and experiences. We all need standards. We all get it.

The deadly sin comes in when IT uses standards like Wonder Woman used her bullet bracelets. Too many times IT teams do not respond to needs because they are outside of ‘standards’. In these environments standards are used to deflect requests, dodge opportunities and dampen ideas.

Standards end up being static snapshots in history. And in the wrong hands are used to stifle innovation and responsiveness.

Indecent exposure

The capability of technology we have today is really amazing. Modern software, mobile phones, the internet and all of its technology are unbelievable tokens of progress. Sometime just getting a technogy to work correctly is an amazing feat.

And IT has its share of amazing feats.

The deadly sin comes in when we don’t also consider security while doing amazing technogy.

We all see the news stories. There are lots of bad actors that take advantages of lax security and wreak havoc on businesses. Malware, ransom wear, data breaches, identity theft, internet disruptions are all the work of bad folks taking advantages of systems that have flaws uncorrected leaving the users of that technology exposed and vulnerable.

 

The seven deadly sins exist in many IT teams. If they remain unchecked they can damage business. Don’t let that happen to your business. What will you do about it?

General IT, Small Business Purchase, Technical Debt

5 Simple Ways to Boost Technology Value Before Sale

Leave a comment

This article first published at the Axial Forum here: 5 Simple Ways to Boost Technology Value Before Sale and is reposted here with permission.

During M&A, seemingly small technology concerns can have material impacts on the ultimate valuation of your business. When selling your business, how can you improve your technology’s value and speed up the due diligence process?

Here are 5 simple tips.

(Note that these tips don’t address more significant technology issues like embedded technical debt, un-found software defects, or key security risks. Those types of issues need to be discussed and evaluated separately.)

1. Clean the garage

Ask any realtor: a clean and orderly house is easier to sell and will do so at a higher price than one that is disorganized or in disrepair.

Every company accumulates old technology that is no longer needed or used. Clean it up. Take a Friday, buy pizza and sodas for the technology teams, and have a spruce up day.

Sell or dispose of old printers, laptops, phones, computers, or servers that are no longer being used. Get rid of the accumulated boxes, old manuals, broken mice, computer monitors that only show green, and outdated cables and connectors.

Eliminate everything but what you know you have definite need and direct use for. Resist, with great aggression, the notion that “this may have value someday.” It won’t, especially not for your business’ new owners.

2. Take inventory of the technical assets

Know what you have and what the new owner will be taking over. You should already have an inventory of your technical assets, but if you don’t, create one now. This can be as simple as a Word or Google Doc, or an Excel spreadsheet that lists servers, software systems, infrastructure elements, employee devices, etc.

The inventory list also needs to show the purpose of the asset. If the server called “acmeacct” is the host server for the corporate accounting database then say that. If you have a Cisco router that interfaces with the WAN circuit to the remote office in Columbus, OH, then put that as the purpose. I recommend having hardware and key software systems listed on the inventory sheet.

An up-to-date inventory list will speed the work of the technical due diligence and improve the perception of the acquiring team.

3. Draw pictures

They say a picture is worth a thousand words. If you don’t already have them, create a few high-level drawings of the overall technical layout and architecture of the technology in the business. Those drawings will communicate, far better than any other medium, the technical relationships and dependencies for your acquiring team. Include the names of the assets, physical locations, and other pertinent high-level details on the drawings. Be sure and use the same names on your drawings as you do in your inventory lists.

The drawings don’t have to be professional CAD drawings. Simple PowerPoint block diagrams or even hand drawn pictures, as long as they are legible and accurate, will suffice for most businesses.

4. Police your policies

The state of your technology policies and procedures will communicate volumes about your operational condition to the acquiring team. Clearly written, accessible, and organized policies increase compliance and will improve the buyer’s perception of the value and capability of your organization. Password and security policies, backup policies, and software deployment procedures should all be documented. Especially if your business engages in regular credit transactions, the lack of security will increase perceived risk in the minds of the acquiring M&A team.

Before due diligence starts, review and update any policies or procedures that are out of date. Document missing procedures and communicate them to the organization.

Organize the policies and procedures and title them appropriately in a common place – this could be a shared folder on a company server, a list of Google documents, or a defined location on the corporate intranet. Every employee should know where these live and how they are accessed.

5. Rectify the roles and responsibilities

Acquirers will view your company’s employee base as a key asset during M&A. Certainly any good HR department will have a list of employees and job titles. But that list does not communicate responsibility or system expertise from a technical perspective.

The technology teams should have their own roles and responsibilities list that communicates what each team member is responsible for and expert in. When possible, the list should include the names of systems used in the other documents to facilitate better overall understanding by the acquiring entity.

Development, General IT, Leadership

5 reasons to attend a tech conference near you

Leave a comment

It was the first tech conference I had attended in years. And waiting this long to attend a technical conference was a mistake.

Last week I had the opportunity to attend the ITRoadmap conference put on in Fort Worth, Tx. by the fine folks at IDG.

I enjoyed a well-paced day of keynotes, panel sessions, vendor presentations and tutorials.

I had breakfast and lunch with very interesting groups of people and discussed relevant current issues and found out how they are dealing with them.

I even ran across 2 guys who live very near me that I had never met before.

I spent time discussing culture issues with one of the panelists on the “Best IT places to work” panel. He gave me some great ideas regarding culture and employee practices to improve engagement and retention.

I left the day refreshed, better informed and motivated.

So here are my 5 reasons you should attend a conference near you.

1. Meet new people in your market similar to you

As an IT and software development director, it was enjoyable and informative to meet the same type of people who work in my geographical market and get to know them and their business.

I increased my network, made new friends  and learned new things about some of our local businesses.

It was good to hear how those folks are dealing with some of the same problems I have to deal with. I walked away with new ideas.

2. See new perspectives on the same problems you are dealing with

The tutorial sessions and vendor presentations were well done and educational.

I learned something new in every session I attended.

I walked away with new techniques to try, new tools to investigate and new acquaintances to further my reach.

3. Form connections for future business or collaboration

I made connections to people and businesses that will help me in the future as well.

I learned about some new tools from Dyn that can help us with product delivery to our customers.

I came away with new DevOps strategies from Irwin Lazar, Vice President of Nemertea Research.

Dean Shroll of Sophos gave an interesting and scary talk about ransomware and the current threat landscape.

And I met some folks who work very close to me that I can continue to develop friendships and learn from.

4. Explore more in-depth industry trends and issues

Here are just 3 small examples of the talks and tutorials that were given.

Derek Hulitzky provided a talk with 3 short case studies of companies that have made profound digital transformations their business.

Mikel Steadman, Director of Sales and Solutions Engineering at Dyn gave a fascinating talk regarding doing business on the internet and provided some perspective on the recent DDoS that Dyn suffered.

Nicole O. Fontayne, Vice President, Chief Information Officer for  DART described how they deal with the enormous IT complexity of a metro area transit system.

We learned about the trends in hiring, retention, IoT and cloud migration and scaling, DevOps, Security and tons of others.

5. Find a new job

And yeah, you can also find folks who have businesses that need people like you. It can be a recruiting (or hiring) bonanza depending on what you are looking for.

Conclusion

It was so worth missing a day of work and the pains that come with that to attend the IT Roadmap conference. It was a great benefit to me and I will sign up as soon as registration starts next year.

So go and find a good conference near you and attend, and participate. You will be glad you did.

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.

General IT, Technical Debt, Uncategorized

7 Areas of Hidden Technical Debt That Increase M&A Costs

2 Comments

This article first published at the Axial Forum here: 7 Areas of Hidden Technical Debt That Increase M&A Costs and is reposted here with permission.

Effective buy-side deal teams are well-versed at issues during due diligence that might impact a deal. But even the most astute deal teams can miss te­­chnical and IT aspects of the target company that can significantly impact the cost of the integration and the return on the investment.

Here are seven often overlooked areas of potential hidden technical debt that acquirers should investigate prior to close.

Employee Devices

Desktops, laptops, mobile phones, and tablets are the tools of the modern office worker. In most businesses each employee has at least one of these and in many cases 2 or 3.

The acquiring business will assume responsibility for the condition and upgrade/replacement policies for these devices. Even in a small company acquisition, there can be hundreds of devices to track, maintain, update, replace, or discontinue. A well-run business should have an inventory of employee devices.

During due diligence use this inventory to determine if excessive technical debt exists in the device fleet. If the business does not have a device inventory, further due diligence investigation will be needed to determine hidden costs.

Backend Server Hardware

Most businesses still use physical servers. These could exist in a rented data center or be stacked up in the closet down the hall.

As an acquirer, you need an accurate list of these assets and the purpose they serve. The actual server hardware needs to be checked for age, serviceability life, warranty, general condition and need. A server upgrade can be a non-trivial task, especially on a mission critical application. Factor in the costs of migration, updates, and maintenance of these physical assets in due diligence planning.

Server Operating System Patches and updates

In addition to physical hardware inventory, the operating systems of the servers need to be checked. Operating system vendors like Microsoft, Apple, or Linux issue updates to correct software defects and security vulnerabilities. It is up to the system administrators to keep up with the installation of patches and updates. Systems that have not been patched are more vulnerable to penetration and disruption.

Spend time during due diligence inventorying the operating systems’ patch level and the security vulnerabilities of the servers. Then plan for additional time and effort post-integration to mitigate.

Unsupported/Obsolete Software Applications

Some businesses rely on older software applications, sometimes custom-built. Old or obsolete software is a significant cost factor when planning mergers of technical assets.

During due diligence, inventory all software in use by the business. Licenses, support contracts, warranties, and necessary upgrades also should be documented. Software applications that are no longer supported by the vendor or creator need to be factored into the cost of the merger. Knowing the landscape of the business software and planning for changes during due diligence can save significant amounts of time and money during the execution phase.

Paper Dependent Processes

Many businesses still use paper. Make sure you understand which processes are dependent on paper, how its stored, whether it needs to be converted to electronic format and the like.

Paper can generate storage, security, and accessibility issues for the acquiring business.

Integrating paper processes with electronic processes of the acquiring business can add time, expense, and potential errors, as well as require additional equipment. Investigate this liability up front to appropriately plan for it during integration.

Duplication of Data

Almost all businesses have databases to hold corporate, product, or customer data. Careful examination of the database architecture yields important facts regarding duplicate data that will impact future integrations.  Duplicate data leads to misreporting, inefficiencies, and security risks. It’s not a deal-killer but does need to be examined and understood to determine its ongoing need, security risk, and cost impact to the merger.

Custom Software

Custom software can be a competitive advantage, and help make a target attractive. However, custom software can also hide all kinds of scary things. On the outside things may look shiny and new, but on the inside there may be loads of technical debt.

During due diligence, consider the software’s architecture, dependencies, and implementation. Look at the quality of the code and what tools and languages were used. All these factors impact the cost of the business and its ability to grow and integrate in the future.

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.

 

 

 

 

General IT, Software Development

5 ways a small business can protect itself from losing the software developer

Leave a comment

For a small business with high dependence on customized or proprietary software and online tools, a good software developer can be a lifeline to better efficiency, growing revenue and increased profit.

But what happens when that software developer leaves the company?

For some companies this can be a disaster.

What were simple requests before, now become profoundly difficult obstacles. Making basic website updates, adjusting the troublesome customer’s account, or running the custom reports for the CEO now become almost impossible.

It doesn’t have to be like that.

With some basic planning, standards and consistent communication  you, the business owner or executive, can mitigate much of this pain. Here are 5 ways to start.

1. Use source code repositories

Make sure any developer that does work for you is keeping the software files for all projects in a source code repository that you own and control. It’s like a library for the files that make up your delivered software.

The software that is created for your business should be treated like an asset so as to maximize it’s long term value return to the company. A good code repository helps protect that asset.

There are many programs that act as software source code repositories. Systems such as Atlasssian’s BitBucket or Github are popular, loaded with features, inexpensive and conveniently online. You can also download and use local versions of systems such as SVN or Git for the more technically capable.

These systems facilitate modern, flexible source code control with many integration options for other parts of the software development and delivery eco-system.

If your software developer insists on keeping code on their local hard drive, its time to find another software developer. You can’t afford to have your software walking out the door when the resource decides to leave.

2. Use ticketing or issue tracking

A ticketing system or issue tracking system is a tool to document and clearly divide units of requested work when used correctly. To a small business this may seem like a lot of overhead. However, a ticket tracking system is a way to more clearly communicate what needs to be done, who is doing it and track progress over time, and potentially across multiple developers.

Online systems such as Jira, Fogbugz or Trac can be used at a reasonable cost. Also Mashable has a longer list of issue trackers you can use.

A ticketing system is also a way to maintain accountability and communication regarding specific tasks and requests. Many of the systems allow you to pull reports and see how things are going, how a project is progressing and measure quality metrics for your code.

3. Keep systems and software diagrams

Every small business should have a basic diagram (could be paper or electronic) that shows where things are. Items such as key servers, locations, databases, internal tools should be shown along with what relationships there are.

As changes are made and systems are added or migrated, update the diagrams as part of your standard procedures. Review it from time to time to validate its accuracy. Adjust it as needed.

A simple diagram that shows where and how your systems link together can save hours of time in misunderstandings or unclear documentation. It can also make on-boarding of a new software developer or system administrator much easier and faster.

4. Track passwords and access

A developer will need access to systems to update code, release software and make fixes and changes.

The small business should own all the passwords and control of them. Allowing the software developer to be the only one who knows the admin passwords is a recipe for disaster.

In order to track a large number of passwords I recommend using tools such as Lastpass or 1password. These tools allow tracking of passwords and provide online and mobile access for convenience. Alternatively you could store passwords in an encrypted file or disk volume (as long as it is backed up elsewhere) with the operating system you use.

The bottom line is that, as the owner, you need to be able to access these systems when the developer is no longer available for what ever reason. Tracking the passwords yourself helps guarantee that access.

5. Maintain regular communication

This is perhaps the simplest but most neglected area.

Business owners and executives get busy. It’s easy to forego the regular, sustained communication that facilitate shared understanding of a software project. Neglecting this communication will cost you when it comes time to transition to a new developer.

Setup and keep a regular meeting schedule to discuss issues, progress, and review updates. This should be done at least a couple of times per week, or daily if possible. Once you get in the groove, these meetings are usually short.

Many teams who use the Agile methodology have stand-up meetings every day to discuss progress, issues and immediate plans. This quick, consistent communication helps educate you, as the owner of the software, and educate the developer to your expectations and needs and the systems evolve.

Force yourself to meet and talk. Ask questions and get answers without technical jargon and acronym soup. Any developer worth their salt can explain what they are doing, and show examples in terms any businesses person can understand. If they can’t, its time to upgrade.

Summary

The departure of your software developer can bring about loads of pain without proper preparation and planning.  But with preparation you can facilitate smoother transitions between developers and lessen your companies downside risk.

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.