I’m in a few skype threads themed around software testing. Last week, I was chatting with a friend there about the topic of being freelance/independent full time.
She mentioned that the word independent is a weird way to describe the way I work. Even though I’m not traditionally employed, my livelihood is still dependent on lots of different things.
My friend is absolutely right of course, I am dependent on lots of things. Her question did get me thinking about what independence and freelance mean to me, though.
This will be the last in my series on holacracy and Zappos for a while, I promise. In this last installment, I’m going to talk a little about the required reading for Zappos employees that decided not to take the severance package and move on to other companies.
In the email that went out to all Zappos employees, Tony Hsieh explained that in addition to being willing to adapt to a completely different work environment, they would be required to read the book Reinventing Organizations. This book explains a model of companies in various levels of evolution (that is the authors description, not mine) and then goes in some depth about how a self-organizing , or as the book labels it, teal companies should run. The description includes every thing from roles, to how a meetings should run, how conflict resolution should work, to how information should travel from the executive level on down.
I have mixed feelings about all of it.
I’m working on a code project called the bowling kata, mostly as an exercise to teach my fingers to think in ruby. I also have a brand new macintosh, and I thought the experience of re-installing all the command line tools might be fun, and even generate some material.
The generate material part turned out to be true. The fun … not so much.
I stall started when I wanted a unit test framework, and tried to install Test::Minitest, which I read about it Practical Object Oriented Design in Ruby, sometimes called “POODR.” (Fantastic, short read, by the way) Continued »
Last week I has the pleasure of speaking with Jordan Sams from Zappos about his experience in helping the company transition to Holacracy. Jordan began working at Zappos as part of the customer service team. He worked for years with the goal of being a manager and shortly after being promoted into that role, an email went out to the entire company.
The email explained that not only was Jordan’s role being eliminated, but every other role in the company was going away too.
Rather than taking the severance package and moving on to new opportunities, Jordan chose to stick around and move to a different part of the company where he could still provide value.
Let’s take a look at the Zappos Holacracy transition, and see how folks like Jordan fit in.
This Wednesday I was on a #SheChat on twitter where I was asked questions like: Do women lose out on top startup roles due to bias or presumption? Why do women pick less hitech or datascience, bigdata, or startup jobs? Is the whole talk about fewer women in tech even true? What is the biggest challenge For #womenintech? Is it men? 🙂
Before I get into answering each of these – let’s look at the data.
There has been an interesting discussion happening on twitter as of late about the perceived value of individuals in an organization and the skills they bring to the table. I have found myself in the past several weeks in the interesting position of having to take on much more of a role I had not anticipated needing to take on, that of release manager. At the beginning of April, this was a job that was just done by someone else and I provided testing support to make sure that we had solid code going out the door. Today, I am the release manager, much of which has to do with merging branches, writing and maintaining scripts to make sure the revision numbers are correct, and a variety of small housekeeping jobs.
Prior to taking on this role, I was seen positively by my team, but outside of my immediate test team, I was really just another tester. Helpful, to be sure, but still seen as “other”. Once I started taking over the release management, though, there was a subtle change. My comments for stories were taken a little more seriously and acted on a little more quickly (at least that was my impression). My comments about potential fixes more times than not now get worked on quickly. Comments have generally been positive. What happened? Just a little paradigm shift, but one that has proven to be very interesting to see unfold.
I often go into new and different organizations that have new and different tech stacks. Once I finally get my arms around unstructured data analysis tools like Splunk, it is probably time to change, to go work with a rails shop that is using Amazon Web Services (AWS) combined with docker to create build-deploy pipelines that use CircleCI that …
It’s all fine, don’t worry about me. I can pick up a yeoman’s understanding of the technology soon enough. The problem is the difference between an understanding good enough to help the business and good enough to be a practitioner. I tend to ask how the tool works, to see more than a demo of a build-deploy run, but how to actually create and maintain a new project.
Sometimes people are surprised by the question, and say “it’s super easy, you just do it” without actually showing me anything.
For example, I once saw a fitnesse demonstration that had a bunch of code functions, inputs, and expected results. Run the application and it reaches down into the Software Under Test, calling the code function, comparing actual to expected.
But how did it work?
Someone had to actually write some code to connect the two systems, right? Continued »
That is a trick question.
Despite the fact that there is a blog post once a week or so, and tweets far more often about the nasty work environments people are enduring in the name of Agile, it doesn’t seem to be failing at all. As far as I can tell, agile is still thriving and growing, and probably hasn’t quite reached the point of market saturation.
That seems to be the case at least based on the number of agile themed conferences, meetups, and consultants that are available.
So what gives?
Have you ever noticed that the answer is “no” more often then it is yes?
This can be extremely frustrating. In some cases the company just spent several thousand dollars to send you to a course or conference. If nothing changes, the conference was a waste, right?
And yet the answer is no.
You can be careful — picking a topic that requires no training, no consulting, no new software. You can find free and open-source tools to use, or even offer to come up to speed at night, on your own time.
And yet the answer is still no.
How is that possible?
Let’s look at it from the Boss’s perspective.
What Does the Boss Get?
Assume your new pet project fails – who will take the blame? The boss will. After all, he approved it. Assuming the project succeeds – who gets the credit? You do, after all, it was your idea. Looking at this, there is no upside for the boss. It is a classic heads-I-win, tails-you-lose scenario. Only someone who owes you a favor, or someone you have some power over, would go along with something like this, and, sadly, the type of person willing to try is unlikely to have a long career in management.
Here’s the alternative to getting permission: Do it yourself anyway. Say, for example, you want to add a batch command that takes in userId’s from a file and deletes them, instead of hand keying the deletes one at a time. Or pair programming. Or adding unit coverage to a particular module, or some other small changes to the codebase. Who’s to stop you from doing this?
Mostly outmoded ideas about how we spend our time.
Most knowledge workers have some amount of time assigned to a task such as a story that really needs to get done. We also have a second set of time – discretionary time – that is really up to us. If you take an extra five minutes in the restroom, or have another cup of coffee, or decided to sit in on another team’s standup meeting, or just spend an extra twenty minutes on email (or reading this blog post), you won’t get fired. In fact, no one will notice. The assumption is that use of time will make you more productive (as opposed to skipping the bathroom all day), so it is fine to just do it.
Add up that time and it could add up to hours per day.
So just do it.
The Time Argument
An XKCD comic shows the payback to automating a particular manual chore over a 3-year time horizon.
This allows you to think of the payoff of an experiment — If you have to do it every day, and it saves you five minutes, that’s a lot of time saved over three years. Another, more fanciful XKCD shows the danger of guessing wrong, so be wary, as automation needs to be maintained.
Still, it it’s worth doing, and you can do it it in discretionary time, or, perhaps, a little sweat time at night, consider just doing it. Don’t ask for permission.
In fact, if you need to get permission, go the other way: Don’t pitch the boss, pitch the team – with the project as your idea if it fails and that you will share the success if it succeeds. Timebox it, limiting it to a two or three week experiment with a dozen hours invested per week.
Have a few successes, and you’ve changed the pattern for “innovation”, from top-down to by anyone. You’ve hacked the culture, created a more fun place to work, and maybe, started a ripple that can turn into a way.
Let me go a step further: Most major productivity and technical innovations in large companies are created by lone wolves, doing things in their spare and discretionary time, that are later recognized by the establishment. I call this the Charles effect, and I’ll talk about it next time.
This past weekend during our most recent Weekend Testing session, we focused on some exercises centered around Accessibility. The experience was both interesting and enlightening. Interesting in the fact that there is always a greater appreciation when confronted with challenges outside of our own, but enlightening in the sense that it can be very difficult to make the mental switch to “think differently” about our experiences.