“I’m not techy”: Complexity vs Simplicity
A few days ago, my sister-in-law made the claim that she is not “techy”. This was after she opened up one of those digital photo frames, got it working and got several of her siblings all hooked up so they could send their 94-year-old aunt photos. She did a nice job, but when one piece didn’t work, out came the “I’m not techy” statement.
Here is a smart woman that figured out an electronic device, user accounts, and smartphone apps for both Android and iPhone. I don’t know if you have ever used one of those digital photo frames, but the user interface is terrible.
The tech industry still doesn’t truly understand what creating products for non-tech people means. For the record, I include myself in “tech industry”. For 30+ years in IT, I was responsible for putting out lots of software for employees to use. There were a lot of mistakes. We continue to put things out that require more technical expertise than our customers or users need/want to spend.
The problem mostly revolves around the tradeoff between Complexity vs User Interface. To oversimplify, the more complex the feature set, the worse the user interface. It is very hard to have lots of features and keep things simple.
Unfortunately, I don’t see this changing in the future. One reason is that security, very appropriately, needs to be built into the lowest level of all our electronic devices and that adds complexity that is hard for the user to understand. The second reason is that interfaces between things (think photoframe and smartphones in this case) are getting more complicated. We all want different parts of our tech world to work together.
I don’t have a good solution here other than to suggest that companies (and IT departments!) work a little harder at keeping complexity hidden from the user. I know it isn’t easy, but it is important.
xkcd: Code Lifespan
https://imgs.xkcd.com/comics/code_lifespan.png
This is so terrifyingly true. From systems that morph into other systems to systems that rely on a whole hierarchy of vaguely known open source modules, code lasts a lot longer than we think it will.
Dashboards: over and under used
I did a search for IT dashboards to see what is currently going on and limited the search to this past month. There are an amazing number of complex dashboards, with dozens of little graphs and charts.
I can’t see how they are useful over a long period of time. Too much time is spent maintaining the automated tools to gather the metrics or manually gathering the data compared to the value we get. When personnel change, they often bring other ideas for metrics.
In an operating room, there is a lot of equipment, all with displays, warning bells and lights, and numbers available at a glance. Individuals in the operating room are responsible for their equipment. There is no central dashboard for the surgeon because it takes focus away from the main goal of surgery on the patient.
Airplane cockpits are very complex. There are many dials, knobs, levels, switches, and displays available to the pilot. Lots of effort has gone into identifying what the pilot needs and when they need it. The goal is flying the plane, and that drives how the cockpit is designed.
IT needs to take some hints from these two scenarios. Too often, metrics are gathered onto a dashboard because it is easy to create the metric. After it is created, people figure out how to use it. It should be the other way around. Don’t create the metric unless you know how to use it to manage the department.
The internal metrics for our IT departments should be driven from the external metrics we share with the rest of the organization.
We need to keep our eye on the primary task of managing the department and only make our team create metrics that will drive decisions and behavior changes.
The I.T. Leader’s First Days: Learn The Infrastructure
In American football, the athletes who are in the offensive line positions rarely get the glory. There are rarely positive highlight reels on the game recaps. Often, they only get attention when something goes wrong. However, as many coaches will tell you, as goes the offensive line, so goes the offense.
Infrastructure is IT’s offensive line. As goes the infrastructure, so goes the organization. Infrastructure is highly technical. The people and the technology need speed and flexibility. It requires a good plan in place and the ability to react to changing needs and threats.
Unfortunately, like the offensive line, there are rarely any positive highlight reels. You don’t see the articles on how an organization has a great infrastructure. Others in the organization rarely appreciate a solid infrastructure unless they realize that they never have any problems.
Now your job includes overseeing the infrastructure.
Portions of this article are excerpted from my book, The I.T. Leader’s First Days, available from bookstores everywhere.
New Book! The I.T. Leader’s First Days
Click here to see all bookstores!
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.
IT Leaders: Show Your Work Screens
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?
Portions of this article are excerpts from my book, The I.T. Leaders’ Handbook, available in paperback and ebook from fine bookstores everywhere.
IT Leaders: Point of Need Help
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.
Portions of this article are excerpts from my book, The I.T. Leaders’ Handbook, available in paperback and ebook from fine bookstores everywhere.
IT Leaders: Understanding How Vendors Make Money
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.
Portions of this article are excerpts from my book, The I.T. Leaders’ Handbook, available in paperback and ebook from fine bookstores everywhere.
IT Leaders: Questions to ask Vendors
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.
Ask The IT Director: Major Outages Suck
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
Dear Impatient,
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.