Productivity

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

This Meeting Didn’t Need To Be An Email

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)

There’s a joke we’ve all heard – and probably repeated – “this meeting could have been an email.” It’s popular because it’s true, we’ve all had the meeting that could have been an email, and let’s be honest we’ve probably held those meetings. We’re all part of the problem.

But I’d like to argue that this joke wrong in some cases. That meeting didn’t need to be an email. That meeting didn’t need to exist in any form – email, chat, and so on – and that’s the real issue.

Am I going to analyze a joke about having too many meetings? Yes I am. If you don’t like it, send me an email.

So let’s take a look at this joke. We wasted a bunch of time getting people into a room, virtual or otherwise, to discuss things or share data. Some of us probably didn’t need to be there, certainly some of us didn’t want to be there. The end results probably could have been done in an email, not necessarily even a chain, just one.

The joke isn’t quite as funny when you analyze it, is it?

But here’s the thing. The meeting in question – or the email in question – is held because something had to be settled or something had to be done, or something had to be cleared up. Be it a meeting or email, something had to be done because something else didn’t.

So the real question is what was needed to avoid the meeting or the email that could have replaced it.

Was there some document that didn’t exist so people had to discuss it? Was there a signoff that could have been automated but is instead 5 people in meeting knowing 3 of them didn’t need to be there? Did people just not talk in the past and now you’re sitting in an actual room for hours because you could have done something earlier?

That meeting didn’t need to be an email. It needed to be a process. It needed to be an accurate help document. It needed to be a form in your software. It needed to be something that didn’t waste people’s time. It needed to not happen.

Now I am going to defend meetings as I schedule them as part of my job. But a good meeting is held when needed and should prevent even more time-consuming things from happening. A good meeting prevents other meetings.

But we shouldn’t just replace meetings with email. We have to make as many unnecessary.

Steven Savage

Can You Imagine Starting?

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 was going to do a post on media forms and what we can learn about today’s media from the Dada art movement, but Serdar had to go and get all brilliant and discuss how people can’t and shouldn’t wait for the right conditions to start something. It deserves it’s own blogpost, so me discussing art movements has to wait.

Serdar points out how people wait for the right conditions and how you can always find advice, from Doris Lessing to Buddhism that the time is never right, never perfect. The problem of course is helping people understand it’s time to get off their butts and do it. If you’ve ever tried to get someone – or yourself – “going” you know what I mean.

Now I work with Agile methodologies, as anyone who’s known me for five minutes is aware. Agile is about breaking work down, doing it in order of importance, and very importantly getting going. Just start and take feedback later – in fact doing something means you at least get feedback so you can do better (or even just quit). Agile isn’t “move fast, break things” it’s “move fast, make things.”

Thus as you can imagine I have to help people “get started” and “just get going.” Which should be easy as I have a lot of experience, a lot of certifications, and a very irritatingly effective attitude of “just do it.” Should be easy with a person like me, right?

Of course you know the answer is that it’s not, which irritates me at an irrational level. Sometime I “buddy up” with “just give it a try.” Sometimes I “Agile harder.” Sometimes I end up a therapist. But Serdar’s post made me realize in some cases what people lack is the ability to imagine starting. It’s easy to look at a big project or some ambitious idea and be so overwhelmed you can’t imagine starting – and in some cases it’s easier to imagine failing.

It’s easy to imagine not starting. I’ve realized as I mull offer Serdar’s writings that people like me are trained imagining how to start, other people have that imagination of how to start and we have to help others develop that capacity.

Of course easier said than done, and each person or group is an individual case. Maybe we have to inspire. Maybe we have to (in some cases literally) draw a picture. Maybe we encourage a prototype. Maybe we just “give it a shot.” But we need people to be able to see starting despite “imperfect” conditions.

Which means when we’re trying to help someone overcome a fear of imperfect conditions, our first job might be to help them see what’s possible. But the next job is helping them develop that imagination.

Steven Savage