productivity

Saving So Much Time We’re Slower

by

(This column is posted at www.StevenSavage.com, Steve’s Tumblr, and Pillowfort.  Find out more at my newsletter, and all my social media at my linktr.ee)

So let me lay out a theory here that the effort to go faster with modern software can often make things slower. If you’re ready for “Steve Rants About Software,” here you go. If not, anyway, read on, trust me.

OK, let’s restate the thesis. I’m starting to think the way software makes things faster means, in time, everything runs slower.

Anyway, you’re probably used to using software for speed. This thing moves faster. This thing does a task for you. I unabashedly love spreadsheet programs, they are amazing. I’m not a patient person, so I get it.

The thing is that software (and other solutions, but I’m focusing on software) sometimes require other things to be done. You have to do a setup. Maybe you have to come up with a way to name some project demands. Perhaps there’s some extra data you have to enter to take advantage of all that super-fast software.

Sometimes, to take advantage of the speed you have to do more work. You probably see where this is going, but I’m going there anyway.

If you’re not careful, the extra work you do starts to add up. You have to check it and correct it. Choices start to interact, say you discover that your new form requires someone to sign off on it due to legal reasons. The time you save starts to get eaten up in other tasks to support being faster. You’re going faster but also going slower at the same time.

Ever check all the checkboxes, done all the stuff to make things work faster and somehow all that speed feels slower? You’re not going crazy. Well, you may be, but it’s understandable.

And all that’s extra normal work. What happens when a software update bricks your system? When a data import goes wrong? Your fast new system(s) cost time to fix as well, and know what, I’m not counting on that going well unless you’ve really run through the scenarios. Since disaster planning in software has become “figuring the SAAS system we have will always work,” I’m not exactly confident.

Thus my conclusion – past a certain point with software (and indeed, processes) your attempts to get speed end up slowing you down. Hell, in some cases, so much other work comes in that you might not need software. You would have less work without the thing that goes faster.

Again, you’re not losing your mind. Your mind just would like to get lost to get away from this.

I guarantee right now that on your job all your cool automated stuff you still go to talk to a person to work around things. You might be the person. You know why you do it – it’s faster than using the fast software.

Measuring return on investment is one thing, but measuring speed as a whole is important when you adopt new software. The value of software for speed is that everything is faster overall, you have to be careful to make sure the trade-offs are actually doing something. Otherwise the thing you sped up is faster and everything else is slowed down.

Judging by my usual online gathering of friends – a huge crowd of IT nerds – it’s starting to feel a lot slower out there.

Steven Savage

It’s A Matter Of The Day

by

(This column is posted at www.StevenSavage.com, Steve’s Tumblr, and Pillowfort.  Find out more at my newsletter, and all my social media at my linktr.ee)

So let me take a break from discussing heavy world issues to focus on organization. In this case a more personal experience – what day of the week should I do my planning on?

No, trust me on this. Let me explain.

For a long time I did my planning for my week on Sunday (being an organized person, of course I plan my weeks). However the more I did that the more onerous it became. I was using my weekend to plan things and not relax. Why end the weekend with bureaucracy?

Yet at the same time wasn’t Sunday the start of the week and the end of the weekend? Wasn’t it the perfect day to do this? As a professional Project and Program Manager I felt myself in a quandary. As an organized person in general I was also in a quandary. Double quandary.

I confess this felt ridiculous at first. Why did the day matter? Well as I thought it over it mattered quite a bit.

Think of much much specific days matter. There’s the day you start work and the day you end it. There’s the time off you have that you want to enjoy. There’s the day traffic is the least worse so that’s when you do grocery shopping. All of these things affect your life – and thus when it’s best to plan it.

After some thought and discussion with friends, I settled on Monday as my planning day – essentially my week began and ended on Monday. It was the start of the workweek, it wasn’t on a weekend, and it wasn’t so far along the week it made things confusing.

My Mondays often got busy, but I’d carve out the time to make it work. Know what? It did.

Monday fit my needs perfectly as planning day, even with other things happening. The need to plan on the weekend was gone. I had clarity on my week and weekend. Thinking about what’s the best day to plan made a huge difference – and it was much less stressful.

I even changed up how I did my planning. Now that I was more aware of my time usage and rethinking things, I asked what other things I might do differently. I start planning my months not at the end of a month, but in the middle of the previous month. That let me get a better view of my upcoming weeks, which made Monday planning easier. One change had led to others.

Of course this helped me at work, and made me think over what I did when at work. I have statuses and reports and meetings to do. Now I have an experience to guide me on selecting the best day for things, a way to explain it, and some insights to share.

It’s a simple thing, but in busy times, deciding when to do what, the ideal day or week or month to accomplish something, can make a huge difference. Small things make a big difference organizationally.

So what day, or week, or monthly planning might you want to switch up?

Steven Savage

The Wasteful Efficiency of the Large

by

(This column is posted at www.StevenSavage.com, Steve’s Tumblr, and Pillowfort.  Find out more at my newsletter, and all my social media at my linktr.ee)

I’ve been thinking of large, easy-to-deploy, fast-to-scale solutions can be an inefficient waste of time. Before I go into my inevitable rant-o-speculation, let me note the origin – Chinese history and Agile. Trust me, it’s worth it.

As to Chinese History, I’ve had a deep interest in the Taoists and because of that some of Chinese history and culture. The Taoists provide a body of philosophy, meditation, and sarcastic humor while focusing on simplicity, uncomplicated-ness, and a kind of mystical realism. Chinese History is replete with scholar-bureaucrats whom I deeply relate to because I’m me. This means I can read about a figure who is essentially “He was in the Department of Awesome Flowcharts and a famous Taoist scholar” and go “yeah, this dude rocks.”

Early on in philosophical Taoism there’s an emphasis on frugality, not-over reaching, and taking care of things while small. Arguably the “journey of a thousand miles begins with a single step” originated in the Tao Te Ching (Chapter 64). If you focus on small things before they’re large and not overdoing it, you get a lot done without, well, doing a lot.

Now does this sound like Agile? Well now you can see where this comes in . . . and learn even more about my personality. I love Agile’s focus on small, meaningful incremental change. The tenth Agile principle even states success is what you don’t have to do. Well done Agile Projects do what is needed, no more, and thus get a lot done – and even save time by not overdoing things.

By now if you know me, you can see where this is going in the world of IT solutions, so thanks for humoring my above explanation. Now let me rant about discussions I have with my friends in IT which is . . . most of them.

Back in my day (hey, I’ve been in IT 30 years) I saw a lot of custom IT systems. I built them. Whatever you needed for your specific needs might not have an off-the-shelf solution, and if it existed it was large and expensive. So when you had to make something custom you learned the issue, solved the solution, then watched your code decay for ten years after getting a promotion. Maintenance was an issue, but at least it was small.

(Software is an expense, talent is the investment.)

In time people of course made solutions that were scalable, that were customizable, that built on layers and layers of code over the decades. We took advantage of cloud computing, of distribution systems. Any large provider of services can instantly set up your small business because of years of investment.

You can implement the same solution as the big guys, or customize a solution . . .

. . . except everything is now all so large.

You just bought, say, an infrastructure tracking tool. Sure it’s on the cloud, but only runs in this one browser. Also you have to figure which modules to activate. You have to train your team. You also have a lot of features you may not need, but everyone wants them as they’re there and easy to use (for the people who want them). You may not have to maintain the system, but you have to get everyone on board something they never participated in making and isn’t based on your specific needs.

Oh, and as soon as a certain web security company who’s name sounds like “Clown Strife” goes under your inventory system is unreachable. Well, also half your other systems are too, but I digress because I still flash back to that outage.

Now you’re using all of this stuff to ease paperwork while creating more paperwork. You are probably entering data you don’t need but it was one of the features. You now have to reconcile the new system with the old system, which is months of work and means you need a consultant. You’re trying to get everyone aligned on something that you basically dropped on them and they make workarounds.

I have met people who were still solving problems with spreadsheets because the applications didn’t work. I have been those people.

You quickly and efficiency implemented a big solution that doesn’t quite work and thus you make more work and waste more time. You have small issues to solve and maybe if you solved them first you wouldn’t be here. Plus maybe you had no gain once all the overhead is taken account of.

All that new work you added may be worse than the janky old system – and you can’t tell.

Right now in technology we can implement huge, powerful solutions easily with no concept of the small picture that makes them work. We don’t even know if they serve the small picture as the “Big Thing” becomes paramount. You can buy a solution and not solve anything and may not know.

Maybe it was worth it slowly maintaining and upgrading the system you had. Or having done it right in the first place. B Or a piecemeal migration.

This is a reminder of Agile, of the Taoists, all having a point. Solutions are often about the small things, about working on something before it’s large, of doing what’s needed – and not letting things grow into a problem. I think in the world of IT we’ve accumulated so much tech, so many solutions it’s easy to just throw a Big Thing at a problem. That may not solve the problem, it may make more of them.

There are situations that need bottom-up implementation and that’s a lot of them. Yes, you might be able to use a Big Solution, but only after you get what you need, and probably do it incrementally. You have to address the small to fix the big, not throw the Big at whatever else is Big and hope.

Also let’s face it, sometimes we get Big Solutions because we let something get out of hand and hope it’ll fix it. We forgot the lesson of starting small then repeat it.

Think small. It’s the way to do big things right as opposed to just doing a Big Thing and hoping.

Steven Savage