Productivity

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

But What If It’s Not Worth Doing?

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)

OK this isn’t another post on AI exactly. I get it, there’s a lot of talk of AI – hell, I talk about it a lot, usually whenever Ed Zitron goes on a tear or my friends in tech (IE all my friends) discuss it. If I was friends with Ed Zitron, who knows what I’d write.

The funny thing about AI is that it’s about automation. Yes it’s complex. Yes it’s controversial. Yes, it lets you generate pictures of Jesus as a Canadian Mountie (Dudley Do-Unto-Others?). But it’s automation at the end of the day. It’s no different than a clock or a pneumatic delivery system.

And, referencing a conversation I had with friends, when you automate something on the job or at home, let’s ask a question – should you have been doing it anyway?

First, if you get something you have to automate, should it be assigned to you? If something really isn’t part of your portfolio of work, maybe someone else should do it. Yes, this includes things like home tasks and that includes the shelves you have not and almost certainly will not put up.

A painful reality I’ve come to realize is that many people take on tasks someone else can do, and often do better. However due to whatever reason it drifts up to them and of course they stick with it. Worse, the really good people often would be better at it, and maybe even have more time and hurt themselves less.

A need to automate something often says “I don’t need to do it and I may be bad at it” and the task should move up or down or somewhere else. I’m not saying automate, it, I’m saying reassign it – to someone that may automate it anyway, but still.

Secondly, and more importantly, if you have a task that can be automated it’s time to ask if anyone should be doing it period.

Anything really important needs a person, a moral authority to make a decision. You have both the decision making skills and the ethical ability to make the right decision. Automation certainly doesn’t have the ethical element, and if it doesn’t need your decision making skills . . . why are you or anyone doing it.

The task might be unnecessary. It could – and trust me I see this a lot – be the result of other automatic generation or other bad choices. It may be a signoff no one needs to sign off on, an automatic update you don’t need to be updated on, or who knows what else. I honestly think a lot of work is generated by other automatic processes and choices that could just bypass people anyway.

But there’s also the chance the task is unneeded, shouldn’t exist, or really a bad idea. Look if the task is assigned to you, a competent individual with good morals, and you want to automate it maybe it just should never have existed. Much as good Agile methods are about making sure you don’t do unneeded work, process is the same.

Whenever something has to be automated, it’s a good time to ask “why did it come to me anyway?” Because the answer may save you time automating, instead letting you hand it off, change how things work, or just ignore it.

And that’s not just AI. That’s anything.

Steven Savage

Efficiency Fallacy

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)

“Efficiency” has been in the air a lot in the world of business, technology, and now government. I find this amusing because after 30 years in IT I’m more in the “keep hoping” mode on achieving real efficiency in organizations. Most people don’t think about what efficiency really is, but boy are they ready to try and achieve what they don’t understand.

The illusion is usually somewhere in a Daft Punk-esque dream of “better, faster, cheaper.” We will somehow achieve efficiency that means everything is of higher quality, gets to us faster, and costs less. When you put it that way, it starts to sound suspiciously like marketing and not actually a plan which is what a lot of efficiency efforts turn out to be.

See, sometimes efficiency as people conceive of it is actually not what they want. Yes, sometimes, better, faster, and cheaper is a terrible goal. However a lot of consultants, politicians, and marketers don’t want to admit it, and in many cases are too deliberately ignorant to understand it.

To illustrate this, let me give an example from computer code. Once I was working with a coder that was pulling their ever-thinning hair out over some legacy code that was incredibly brittle – simple modifications created cascading problems. Upon closer examination, the conclusion was a case of people being “efficient” – to stay on time they’d done all sorts of tricks of half-reusing code, ignoring good long-term choices for the easiest-to-code, and left us a mess.

Totally “efficient” and a total disaster to maintain and easy to break.

Something that works may not be the cheapest, or the fastest, or even the best. However it is reliable, consistent, enduring, and keeps going. You can save money, cut corners, overload what you’re doing but it will break. Efficiency is sometimes bad for actually getting good results because when you’re goal is to save time, money, or whatever you don’t ask will it work and keep working.

If you aim for better over some single-number driven measure of efficiency – more stable code, a better process, have higher standards for your company – you will probably get gains in efficiency anyway. Your company database not crashing saves money. Not having lawsuits due to better testing of a product is good. Efficiency sometimes comes from you know, doing things well.

I feel we’ve created a cult of efficiency in America. Maybe it’s also part of our weird health craze trends or a way to cope with economic differences. Perhaps it’s some malignant leftover part of the Protestant Work Ethic. But I think we’ve really overdone it because efficiency may not be what you want – or the only thing.

In closing, let me talk about another traumatizing event in my long career. A project I was assisting with once had employed a contractor who had software that gave answers perfectly. A quick test revealed they’d basically made software that could only past the test.

It was very efficient in its own way, and absolutely totally wrong.

Steven Savage