Last time I introduced my negotiation strategy, which shifts the work from in the moment haggling to research. It works well when both sides are honest …
What do you do when the other side is not honest, hiding information at best or actively misleading you?
Let’s talk about it.
Are you ready for the impending robot takeover? I’m not.
Most of the automation I’ve seen slips into our frame of mind through simple business processes. Systems administrators make careers on this. When I first started working in technology, admins were automating as much as possible to make spare time for more important things, like DOOM. The rest of the business world caught wind of that and decided they wanted in. More automation, more productivity, more profits.
I recently wrote about the deskilling effect automation has on trades. Today I’m going to take a slightly different angle. I want to talk about the reality of technology and automation, and how that changes the work. The tasks we perform every day.
What if there were a different way? It would have to allow you to close a deal within seconds, that puts you in charge without any deception or shenanigans. More than that, the person at the other end of the table will appreciate you for it.
Over the years I have found only one method that meets this standard. There may be others, but today I would like to talk to you about my favorite.
Are performance improvement plans (PiP) a gambit to shuffle people out the front door, or are they actually there to help people?
I just finished the new Dan Lyons book, Disrupted, while on a plane flight to Seattle. The book seems equal parts entering a new environment with a terrible attitude, and the bad aspects of every startup I have ever worked for. This isn’t a book review, though. In one part of the book, Dan talks about the ups and downs (mostly downs) of being put on a performance improvement plan. This reminded me of a story about PiPs that happened to an old friend while we were working together in 2008.
How important is standardization to software work, and how much of it do we need?
I spend a lot of time reading about Lean principles, trying to apply them to my own work, and helping to teach the rare class so that others can take these ideas and find ways to work more efficiently. The basics are easy, remove waste from the process so that the only thing coming out of the end of the line is value. The stuff that the customer cares about and is willing to pay for, nothing else.
Like most simple ideas (I’m looking at you, agile) it is easy to misunderstand and go completely off the rails. There are some unfortunate overlapping areas between Lean and Frederick Taylor’s scientific management that might be worth thinking about.
Where does innovation come from, and where has it gone?
My schedule is jam packed lately. I have a nearly full time contract gig that keeps me at my desk testing software most days. After that, there is writing work to be done. That floats up and down depending on the month and what editors need. Add to that a few hunting (metaphorical) excursions each week to talk with new or existing clients about new partnerships and work. Sometimes I forget what day it is.
There is nothing I would rather be doing, but this schedule makes it hard to come up with new ideas. There is a hidden tie between lack of spare time and most modern software processes.
I consistently hear from testers, almost regardless of where they work, that they feel like second-class citizens at work. Testers get paid much less than developers, when they do a good job it adds friction to the delivery process and makes things slower, and then there is the snark. Developers certainly have plenty of snark to go around, but they get a pass because they are building something.
In the late 60s to the early 70s the consulting company, McKinsey, were on a consulting assignment to the government of Tanzania. Then President, Julius Neyerere, noted that the lowest paid McKinsey associate was earning more than the highest paid Tanzanian government Minister. He then noted that “if you offer peanuts, you get monkeys“. McKinsey won that deal.
I think there is something there, and also a system of forces that make software testers a lower class of employee at most companies. Here is my story.
Software is in a sort of heyday right now, a new tech stack or programming library is popping up almost daily. It seems like most business ideas now start with tech and then work backwards to the customer experience.
I spent last week in Atlanta visiting with a client and talking at a conference with my co-blogger, Matt Heusser. The night before the conference there was a nice speakers dinner. It was a chance for people to relax a little before speaking (if you get the pre-talk terrors, you know what I mean here), and also a way for the organizers to reward the contributors. After the conference, we had a smaller get together with the client to talk about current projects and working together in the future.
That reminded me of a comment from Steve Jobs after a sharp question from an audience member at one of his presentations.
After working as a writer for Forbes and later Newsweek, Dan was let go at fifty-two, and spent a year at Hubspot. His book Disrupted My Misadventures in the Start-Up Bubble tells that story.
This is my take on that story, my takeaways … and a few ideas for you.
I have been noticing a pattern in contract staffing lately, it usually starts with an emergency. The client needs an expert with a very specific skill set, and they need that person now. But wait, there’s more. There are almost always constraints on this that make the person nearly impossible to find. The candidate needs 10 years of experience, they need to be located in the south west region of the United States, and they need to be available to start working a full time contract as soon as possible.
This seems like a gold mine to the person trying to get the gig. They are rare and they know it. My bet though is that these emergency staffing efforts either fall through completely before the job starts, or don’t work out after a few weeks.
Let’s take a closer look at the emergency and the problem that got the client there.