Folks, I am very pleased to announce my second book. If you are a new or future IT Leader, The I.T. Leader’s First Days is for you. It covers the skills you need to have and how to come up to speed quickly in your new position.
The ebook is available NOW. Paperback & Hardcover will be available in the next few weeks.
Here is the book description for The I.T. Leader’s First Days:
As a new IT leader, you are stepping into a world of excitement and challenge. Prepare yourself.
You and your team must understand and apply ever-changing technology to make your organization successful. You must continually improve yourself, your team, and your company.
The I.T. Leader’s First Days introduces skills and techniques you need to be effective and provides you with the strategies for your first weeks and months on the job.
Long-time IT leader, author, and speaker John Bredesen leverages decades of experience to create the book you need to start your IT leadership career. Clear explanations with a splash of humor cover a broad range of topics needed to launch your leadership career. Check out The I.T. Director series to see all his books.
Starting your new job off right is important to you. This book will help you make your First Days successful.
Last week, I talked about Point-of-Need help as a way to put better help in your internally developed systems. This week, I want to cover a related topic.
Imagine this situation (for those of us that have been in IT for a while, we don’t have to imagine because we have lived it). An application gets written and implemented. Years go by. The people in the organization that set the requirements have moved on to other jobs. The developers have moved on. New people come into the organization and start using the software.
Now we have a situation where the following is true:
- The interior logic and calculations in the code are no longer well known.
- Users understand the software by the output, not by the design.
- The assumptions and decisions made by the organization when developers created the software are no longer known by the users, management, or the new developers.
The last point is the hard one. It leads the organization to no longer trust the software. What can we do about it?
If I told you to look at code in the above photo and tell me what it does, only a few of you could.
If I told you that to do your job, you had to read and understand it, unless you were one of those few, it would likely raise your stress.
But much of the software that businesses put out for internal use is as confusing as the code above. Why do we in IT department do that to our fellow employees?
Point-of-Need (PON) help is an idea that can help without redesigning a total new user interface.
Vendors have to make money to stay in business. Like it or not, it is in our best interest for our strategic vendors to make a profit off of our business. After all, win/win is the best way to sustain a long term strategic relationship.
If they don’t make a profit off of us over time, they will fire us. Yes, vendors do that — mainly by acting like a bad vendor until we go away. Or just tell us no the next time we want to place an order. Or dramatically raise prices.
If we understand how a vendor makes their profit, we also can understand where we have negotiation leverage. Just because we are ok with them making a profit, doesn’t mean we can’t negotiate to our benefit.
Let’s look at a few ways vendors can make money off us.
By necessity, IT works with vendors. Some vendors are transactional and can easily be replaced. Some are strategic and are more critical to your organization. Ask these questions to build a good understanding of your strategic vendors. The answers won’t be easy to get and you may need to do some digging, but having them will definitely be beneficial.
Are you working with the vendor’s strengths?
As vendors grow, they add different products and services. Some will be major investments and will be implemented well. Some will be new and won’t have much depth or capabilities. A classic example is a new service that has just one or two people behind it. “Yeah, we do SharePoint consulting” may mean they have one person who knows a bit of SharePoint.
If a vendor has multiple products and services, take the time to learn which ones are strengths and which ones aren’t. The more important your need, the more important it is to work with the vendor’s strength. This will reduce the risk of vendor problems down the road.
Where does the vendor make their most profit?
This can be tough to figure out, as vendors aren’t always willing to share this. But it is important to your negotiation position to know this. A classic example is a services vendor. They likely make a good profit from consulting or contracting. They will protect that in any negotiations. Once you know that, you can work in other areas to get what you need. Sure, you can, and should, have discussions about cost, but there is more you are interested in. You can negotiate on topics such as support, specific personnel, add-ins, faster response and more if you respect their profit. There is a caveat on the size of the vendor. Once you get into Microsoft, Amazon, and Apple size vendors, we are dust mites on a flea on the tail and we have no influence over the dog.
How big is the development team?
For software companies, find out how big their developer team is. This tells you how many features they are planning on adding in the future. A small team may indicate that they believe the product is mature (startups are an exception, of course). Companies with multiple software products will move developers to the one needed the most new features. Putting it perhaps too simply, you don’t want to be on a product with a small maintenance team until you are winding down your own usage.
When was the last major rewrite?
Also related to software companies, understand that all major software products need to be re-architected and rewritten at least once in their lifecycle. I’m talking about ERPs, CRMs, Client Billing, etc. Ask questions about how long the product has been on the market and when the last rewrite was. Technology changes fast enough that if you get into the 5-7 year range, there should be a rewrite in the pipeline. For these large systems, it will take a few years to get the new product to replacement quality.
I’ve always been a fan of moving to the new product as soon as practical for my organization. The vendor will put most of the developer resources on the rewrite and their response will be much faster than the older version.
What investments have they made in the last two years?
Technology is a tough business and vendors need to be making investments and partnerships with others to be successful. Check out the News section on their website and see what they are doing. Especially for larger companies, those that go it alone will not last long.
Dear IT Director,
When we have a major outage, my team jumps into action quickly, but sometimes they get in each other’s way or try the same thing multiple times
– Impatient in Indianapolis
Been there, done that, got the t-shirt. Even if we do everything right to prevent outages, they will happen. Let’s look at a few ways to improve your team’s response.
In Douglas Adams’ novel, Dirk Gently’s Holistic Detective Agency, the character Dirk Gently frequently talks about the “interconnectedness of all things.” He was talking about solving mysteries, but might as well have been talking about software. Interfaces are a significant part of the power, and complexity, of today’s IT department.
I would suggest that the interfaces are becoming as important as the functionality within a piece of software.Read More
This post if for IT people but applies to any field with their own jargon. Scroll down to see the video I’m talking about.
Gustav Holst write a brilliant piece of music call The Planets. In particular, the Jupiter portion has always been one of my favorite classical music pieces. I don’t know the creator of the video, but he seems knowledgeable about music. He dissects Jupiter in a very deep way, using tons of music jargon.
I don’t understand most of what he is saying… I believe he knows what he is talking about, but I don’t know that he knows what he is talking about.
If you are an IT person, I challenge you to start at 1:30 and sit through at least five minutes of this video (for the adventurous, start at 7:30). Make a sincere effort to understand what he is trying to say. Try, as if your business depends on understanding it. Unless you have musical training, you probably won’t get much further than I did.
This is what we sound like to people outside our field. The organizations that depend on us aren’t able to understand the technology to the level we do. This isn’t because they are dumb (I hate the “dumb user” trope), it is because they are experts on other things and haven’t put in the years of focus that you have.
It is our job, not theirs, to figure out how to communicate better. We need to be creative in using analogies, metaphors, and straightforward language to communicate.
If we don’t, they may wonder if we know what we are talking about or just faking it by using jargon they don’t understand.
A great system, implemented badly, will probably fail. A mediocre system, implemented beautifully, will probably succeed.
In the IT world, there are often projects that require selecting a product. The team determines requirements, creates a long list, reduces it to a short list, and makes a selection. This is usually done with large systems, like ERP.
It is important that we get the selection process right. The wrong technology can hamper our organization for years.
However, implementation is at least as important, if not more important, than selection.
The point of the IT department is to help the organization succeed. To do this, we need to understand that organization and the world it operates in. In addition, we must understand technology products, services, and trends enough to know how to apply them to our organization. We must understand the overlap between business and technology. That is where the IT department lives.
While this concept applies to any staff group in an organization, including HR, Finance, etc., let’s look at what this means for IT.