Over the weekend, I came across this article from someone that recently left Imgur on 21 lessons they learned while in that position. A few things stood out to me.
First was that the author had held the position for less than a year and was a very recent college grad. That was a good reminder of how many lessons fly at you in that first few months at a company, and especially when the environment is all together new to you.
The second thing is only obvious to me after spending so much time looking at new management strategies. The lessons there come form an organization that is using very traditional management techniques.
Lets take a look at how this list might be different with some other management ideas mixed in.
Today will be a day like most others; work commitments, meetings, deployments, testing, commute, family obligations, etc. Tomorrow will be a very different reality. That’s because tomorrow, I will willingly step back in time some three hundred years. Wait, what?
For the past several years, I have been participating in “pirate reenactment”. Yes, you read that right. I love the living history aspect of that time period. With my Welsh and Danish heritage (among several other countries), it’s easy to imagine pirates being part of that. This weekend, I will suit up at the Northern California Pirate Festival, being held in Vallejo, California June 20-21 (one of the largest on the U.S. West Coast). I will be participating with “Pirates of the Silver Realm“, based out of Reno, Nevada.
The worst part of it is the sheer inevitability of it. The entire question feels unreal. In nearly every conversation I have had on the topic, the decisions were already made. The people who were ambitious, who wanted titles and money, were going to pursue management anyway, while the folks more cut out of technical roles wouldn’t end up making the decision themselves – instead, they are led to a decision by someone behind the scenes, much like the stainless steel rat is forced into a room in the original short story.
But this question was about project management, which leads me to explore the entire concept of project management, its role on the ladder, and whether you should consider that change.
Now that is worth talking about. Continued »
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 »