You may have met the type, and you know the combination is incredibly powerful. And also dangerous.
The classic advice to stay technical is to take as much as twenty hours per week – 6PM to 10PM, 5 days a week, to learn the new hotness. That’s fine advice, but at what cost?
20 hours a week, from age twenty-one to forty-one, is twenty thousand hours or about ten business years. Think of what else you could do in that time.
Let’s imagine those twenty-thousand hours as an investment, designed to generate enough revenue that you don’t need the tech job anymore.
Here’s five ways to do it.
- New graduates are cheaper, hungry, work hard, and are open to learning new things
- As people get older, it gets harder to learn new things
- Therefore the typical tech career is about fifteen years long.
After fifteen years, if you haven’t moved up into management, you’d better be working for a company where you have deep an intimate technical knowledge, inventing something new (eg be the author of Linux, create git, that kind of thing) or move on to some other field.
I can’t disagree the conclusions above, but if you don’t mind, I’d like to propose an alternate explanation for why – and perhaps what you might do about it. Continued »
If you are anything like me, at this point, you’ve heard lots and lots about the DevOps movement. Like so many other things in this world (“quality” and “architecture”, for example), DevOps is a term that everyone grasps immediately, everyone is sure what it means … and if you ask five people, you’d get six different answers.
Today, I’ll take a brief stroll through the concept, probably get shouted at in the comments, and eventually we may actually get somewhere. (This follows Heusser’s Rule: When other people can’t define something, tell them what you think it is, and they’ll be happy to correct you.)
This week the paperwork finally came in for me to do placement for a client – three software testers in sunny Florida, relocation provided.
So yes, I have spent a lot of time on Linkedin lately.
Along the way, I noticed something strange – many of the job descriptions people post for software testing begin with something like “Create and Execute Test Plans” or “Create and Execute Test Cases.”
Who Talks Like That?
I mean, do know a programmer who “Creates and Execute Programming Plans”? Or a manager who “Creates and Executes Management Plans?”
The statement “Creates and Executes Test Plans” is really just saying “I plan my work, then I do it”, with the term “Test” thrown in; it is content-free.
You could say it of anyone.
When I see that on a linkedin profile, it’s headed to the ‘do not contact’ pile.
A Different Way To Do It
Yes, as part of the job, some testers create and execute test plans. Sure. That is the accident. I’m more interested in the essence – the why – the problem that testing solves. I’ll explore that with a 5 why analysis.
Why create test plans? Because the customer wants testing to occur.
Why should testing occur? So the software can ship.
But why does the software need to ship? So the client can use it.
But why does the client want to use it? For the value that customer will see when they use it.
That’s the thing.
The customer doesn’t care about the test plans; she just wants to be able to buy books from Amazon on her iPad. That’s it.
Imagine two fast-food workers, one who “prepared fries and burgers according to purchase orders” and another who “Satisfied customers by providing warm, fresh food quickly.”
That is a huge difference. It can be used on any job, from the intern to CEO.
But … Why Do So Many People Write Resumes Like That?
The programmer who writes “Creates unit tests in jUnit”, the DBA who “Tunes using SQL*Plus profiler”, and everyone else who writes in this stilted way, is doing it for a reason — they want to get past the folks in HR who scan for keywords.
The keywords got their from a job description, and the person who wrote the job description wanted it to be vague enough to not have to change every year, and to be able to span departments, and a thousand other reasons.
It’s all part of a game, using the same words as everyone else, doing sort of like what someone did before with the same words. Don’t rock the boat, go along and get along, if you need to put these words on a resume to get ahead, well, of course you should do it right?
We Can Do Better
I don’t blame the people who write “Create Test Cases” on their job descriptions, who hope to work within the system, to get past the legion of HR-scanning drones and get a chance to speak to a hiring manager. It’s okay. I get it.
If you find yourself in that position, though, I would like to offer a word of warning, and another of comfort.
First the warning: Organizing your resume, and pursuing a job in traditional ways, can be sort of earning one of those obnoxious certificates you don’t really believe in but HR seems to care about too much: It might just get you the job that you don’t want to have.
Second, the comfort: There are people recruiters and (many more) hiring managers who have a perspective like mine — they care about results and skill more than buzzwords; the essence of ability over the accidental elements.
Working for those folks is a lot more fun.
So if you’d like, take a look at that linkedin, that resume, or even how you position and explain what you do on the day job — and consider what kind of client you are attracting, who you’d like to attract, and what you should change.
The next step?
That’s up to you.
As a small business owner, I’m spending the day running my business. Invoices, taxes, payments. It’s not that bad, really — As a small business owner, I get to take the afternoon off, and go to the beach then, when the beach will be empty except for a few homeschooling families.
September also marks the end of the summer conference season, where the most common personal question I was asked is probably for information about “going independent.” The questions I get are reasonable: How do you decide if it’s a good time to jump ship, what should I do to prepare, that sort of thing.
Given that I am working on labor day, it seemed appropriate to write a blog post about doing just that: Moving yourself from labor to management by starting your own contracting company.
For the first half of my career, I found the term transparency to be kind of, well … scary. Not because transparency itself is bad, as much as it’s step-children and cousin words — governance and accountability.
Governance, to me, meant that someone up above didn’t know what was going on, so they were going to give us still more work to prove something. Exactly what we were proving was always sort of undefined; it felt a bit like a tiger chasing its tail.
Accountability wasn’t much better; it meant that someone would call us to “account” for missing the commitments someone else made six months ago to project deadlines, before they really knew what the project was going to be. Even if the estimates were good, because the steering committee was probably going to add more work without shifting the deadline, then call us to “account” for “missing” the deadline.
I’m not really this cynical. I just want to set explain what my reaction would have been to a word like transparency ten years ago.
Today, I think transparency is the secret sauce. It is the magic milk, the healing homebrew. All those problems above go away with transparency implemented correctly.
Let me give you an example.
Transparency in Action
Say I have far too much work to do, and not enough time to do it — but I can break the work down into tasks that can be done in an hour or so. Not all kinds of work falls into this category, but a lot of what I do, testing, configuration, consulting — a lot of it does.
I make three columns on a white board – “To Do”, “In Process”, and “Done”, then write down a sticky for each task. Once the setup is done, I pull the first task from “To Do” to “In Process”, and work on one thing at a time. Now this isn’t a perfect list; there is no tasks for “check email” or for scheduled meetings, but for the most part, my tasks are modeled on the board.
Any leader, any boss, any executive that walks by can re-arrange the tasks, and put something to the top. Because the tasks are small, I can tell you how long it will take on average from putting a task to the top to moving it to done. If I want to, I can count the number of tasks I get done per day, to predict when things will get done. A process improvement wonk would call this a “kanban” system, and they’d be right – but a Kanban is simply a Japanese word for tag system to manage a flow of work.
Here’s a Kanban that I set up at a client a few months ago; the tasks are a list of business risks we were testing for:
We had five team members on the project, thus, give items or less of work in progress on any given time — when we were pairing, we’d have less. If we were under pressure and had to ship, management could look at our ideas to test remaining (and we always have more ideas) and decide the benefits outweighed the risk.
Think about how that decision changes things when there are problems in production, versus the ancient model of testers “certifying” software for release while under time pressure.
Kanban and You
Imagine walking into an annual review meeting and finding out you worked on the wrong thing, or your priorities were wrong, or, after 12 months, your manager was disappointed you hadn’t accomplished (some_thing).
Only this time, you had a kanban. Everything you did was visible. Anyone in leadership could see them, adjust them, ask “What about (some_thing)”, create new stickies.
At that point, the person who has the problem is the reviewer, right?
I don’t mean to be manipulative here — the point was just to illustrate how powerful this kind of transparency can be. What I have above is just one way to model a Kanban (it is a team board) and Kanban is just one way to make the work visible. For more, check out Jim Bensen’s book “Personal Kanban”, or keep it tuned here.
Until then: Have you tried some form of radical transparency? When you did, what kind of results did you have?
My article was not inspired; I’m not a genius. Instead, the timing was right, that’s all. I literally happened to be reading William Zissner’s On Writing Well this week, perhaps the most respected book on late 20th century writing style, good enough to keep updated into the 21st. It was Zissner, and his book, that explained my discomfort on reading the memo, a discomfort we probably all felt.
After clicking the publish button, the very next questions in my mind where why, and how, the CEO of a Fortune 50 company could get it so terribly wrong.
I believe I may have some answers.
Yesterday I was struck this tweet from Fog Creek Software CEO Joel Spolsky:
Then I read the memo.
Now I’m with Joel.
The document is not something someone leaked, a half-baked message sent off in a moment when a quick decision was needed. Nor is it an insiders document, full of shorthand terms and abbreviations that make complete sense, but only to insiders. No, this was actually designed for everyone to read, for all employees to read. It is on the web now, hosted on a Microsoft Website; you can read the full memo yourself.
I’ve got a lot to say here, but I’m going to start by answering Joel’s question (‘what the heck does all this mean?’) with a little bit of commentary, leaving conclusions for next time. The original text will be in italics; what it means, in bold.
Here goes … Continued »
At least, that is one of the major themes in Malcolm Gladwell’s book Outliers, and it makes sense to me.
It doesn’t really matter what you are working; it could be on MySQL clustering, writing mobile applications (or testing them!). It might be your golf swing or your knowledge of University of Michigan football.
Today, I’m going to talk a bit about how to know when you’ve ‘arrived’, and what to do with that knowledge.