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.
Sometimes, when we talk about office jerks, a story comes to mind. It happened over the course of a week. Over and over again I saw the same type of behaviors, and finally did something about it. It’s a story about my values, and my behaviors, but also others – and one I have learned enough about to share here.
Far Away And Some Time Ago … Continued »
One way to make your team faster, is to chop a few people out and move them to other parts of the company while still requiring the same output.
There are lots of stories and legends surrounding Toyota Production Systems and Lean creator, Taiichi Ohno. In one story, he was implementing a cost reduction strategy for Toyota. There was a team of people, let’s say it was 100 to make the story easier to tell. Taiichi cut ten people from the team and sent them to other parts of the plant. This staff changed cut production on the team by 10%. The goal wasn’t to slow things down of course. When he cut staff, he also left them with command to rise back to their previous levels of production. If the team managed to do that, they had successfully found and removed some sort of waste from their process.
Taiichi was not known for being a gentle guy.
I am seeing this same pattern of cost cuts in software teams over the past few years. Unfortunately that usually isn’t followed with the same reasoning and depth.