The majority of my mornings start out the same. The night before I make plans at all the great things I will do – each seems reasonable. I plan the number of hours each ‘should’ take, and I’m certain to get five or six done by the end of the day, easily.
Then the alarm rings and I check my email.
A short time later, I look up from my monitor to my clock. It is 1:30PM; five hours have passed. I have not had lunch, and I am staring at a video of a cat playing with string. (No, wait, don’t click that link! )
Instead, let’s talk about how to plan and predict workload.
About two weeks ago I found myself driving to Dearborn Michigan, to the Adoba hotel to attend Agile and Beyond. I’ve always found the title a bit ironic; too many companies want to get to “beyond” without doing the heavy lifting. It was my third trek to the conference, and I didn’t expect a whole lot new.
Then I heard the opening keynote, by Joshua Kerievsky. It blew me away.
I’ve been reading a pretty neat book called On Looking over the past week or so. The main premise of the book is that all of your experiences cause you to look at the world in a completely different way from other people. You will ‘see’ things that others will not. One thing struck me in chapter 7.
The example that jumped out at me was Fred Kent from the Project for Public Spaces (PPS) mentioning that something preventing a person from getting into a space could actually help groups of people move about faster. Think about the last time you were exiting a theater through double doors after a really big movie let out. That column in the middle of the double doors has an unconscious effect on people. Groups self-organize and things get real efficient real quick.
There are all kinds of bad bosses out there, but reading the Gervais Principle has warped my mind a little bit. I can’t help but see organizations in terms of this model now and it is sort of freaky. If you haven’t read this, I’ll give you enough for this article to make sense, but I highly recommend it.
The Gervais Principal is based on this sketch by Hugh McLeod which explains an organization in terms of three kinds of people. There are the losers at the bottom who have made a financial trade off for any number of reasons but usually it is stability, the clueless on top of that who are basically incompetent, and on top of that are the sociopaths of create their own ethic based on self-interest alone.
Really though, I wanted to talk about some of the ways you can deal with working with a person like this.
1) Quit your job and find something better. This is an immediate, albeit risky solution to your problem. There is some risk for this solution though, you might be jumping into another equally bad situation.
2) Become a low performing loser in your company doing just enough to get by and keep your job. If you choose this path, you’ll probably want to make an effort to continue developing your skills outside of work. Most tech jobs don’t last forever and sabotaging yourself isn’t a good thing.
3) Go independent, be a consultant. Michael Church added a fourth layer to the model, the technocrat. The technocrat is driven to good work and to serve. The goal of the technocrat is a mutually beneficial relationship, their life isn’t dependent on the failures of others. I think the independent / consultant tech worker can potentially fit nicely into this role.
4) Have you ever had one of those managers that liked to act as a shield from all the bad stuff that rolled down from management? Finding one of those might help you out. They can at least provide a layer between you and the sociopath. Maybe you can find one of these in your company and transfer under that person.
5) Learn the secret language of the sociopath, power talk. This might leave you feeling a bit icky, but at least you’ll will be armed to navigate the kind of conversations that surround you.
I think I know what I’d choose given these options, how about you?
Have you ever been to one of those meetings where the entire department is called in with four hours notice? If you have, then you know a bit of what I was feeling.
If you haven’t, consider yourself lucky.
There we sat, around the conference table, waiting for our newly promoted Senior Manager of Technology Delivery to tell us what was going on.
The room was silent, breathless almost.
Our boss told us the news, which was mixed. The greater organization was sending some extremely challenging project schedules down the pike, and we needed to drop all-non essential project work to focus on three company priorities. Our manager assured us that Technology Leadership was committed to sustainable pace. “Now is not the time”, he said “For us to be doing favors for other departments, to sneak in just one thing on the side. We have NO energy for other projects. Zero. If your request isn’t on this list, you don’t do it, even for a friend, even at night or on the weekend. We want to protect you.”
When we left the room, the general feeling was elation. Wow, people seemed to be thinking, Tech leadership really cares about me.
I wasn’t quite so sure. Continued »
Last time I talked a little bit about the differences between a traditional university education and posted some thoughts about why you might want to look into vocational education. This time, I have an interview with Eliza Brock from Nashville Software School to get into some details about their program.
To get started, can you tell me a little about what Nashville Software School is, and what you do there?
I teach the advanced course, Software Development Fundamentals with Rails.
When students graduate, what % of students have a gig one month after graduation – six months? Do you keep up with how many are still working for the same company 12 months after graduation? If the number is low, do they get a better job or what?
I have the luxury of having my only job be teaching, so I don’t personally keep track of those numbers.
I know that with cohort 1, 14 of 16 had jobs within a month or so of completing the course. At least one more student from cohort 1 got a job within a few months.
Cohort 2 (26 students) graduated in July and their initial placement rates weren’t as good. This is at least in part because two of our bigger employer partners weren’t able to make planned hires. You could ask John Wark for more details- I’m sure he has the latest figures.
What makes Nashville Software School different from a university. Are these certificate programs? Are they specialized along the lines that continuing education certificates are? What range of course work is offered.
We don’t offer a certificate or anything like that. The students largely get out of the courses what they put into them, and the best way to demonstrate that is with their skills and the portfolio of projects they build up during the six-month program.
NSS is significantly different from attending a university. My job is to give them the tools to become working junior developers and to grow into solid professional developers. Students aren’t graded (although they are given lots of feedback and classwork) and there is no graduation. At a university, a lot of the job is to help young people grow into well rounded individuals. Our students are expected to be adults already, and most of them have degrees, so that isn’t a component of what we do.
How was the NSS curriculum developed and vetted? How do you know that the material you are teaching and the evaluation methods that are being used are effective?
I can’t speak to the curriculum of the intro course, but the curriculum of the advanced course was developed by me.
I was a teaching assistant in college, and as soon as it was decided that I would be teaching this course, I called up my former professors and asked for their guidance on developing the curriculum. It is largely based on the high points of the 4-year software engineering program at Rose-Hulman. Obviously, you can’t cram 4 years of education into a single 3-month course, but I do my best to expose the students to the depth and breadth of the field. I also consulted with a number of area developers for feedback as I was developing the initial curriculum.
From that point, I’ve iterated based on how each class has reacted to the material. For example, for cohort 3 (my current class), I’ve expanded the databases unit by several weeks, so that they have a firmer foundation in what’s happening behind the scenes. The feedback I’ve gotten from cohorts 1 and 2 (and their employers) post-graduation has been quite positive.
If you’d like more details on the curriculum and how it’s evolved, you can view the full syllabus and course materials from the first 3 cohorts on my github profile (https://github.com/elizabrock). The README for the current cohort (https://github.com/elizabrock/NSS-Syllabus-Cohort-3) will be of particular interest.
Now, it’s your time to shine! Tell me a little about yourself and what you do outside of teaching.
I run a software consultancy (Eliza Brock Software) that specializes in test driven development of web applications.
My background is in software engineering, with a degree in software engineering and computer science from Rose-Hulman (which I’m compelled to mention has been Newsweek’s #1 undergraduate engineering school for the last 14 years).
It’s actually quite a challenge to teach an immersion class (mornings) while also running a consultancy (the rest of my waking hours), so I don’t do too much outside of that.
Education paths for tech workers has been pretty cut and dry for the past few decades. Get through high school and ideally be good at math, then move on to a university and major in computer science, or computer engineering, or some type of mathematics. Alternately, go to university and major in the humanities and spend a lot of time with learning on your own after graduation while working your day job.
There are a few problems with this model though. Most software jobs don’t require a deep understanding of pointer arithmetic and data structures. After graduation, most of us will spend your days writing web-apps that help with some business process. I don’t mean that as a bad thing, at all, there is a lot of value there which is why this is such a big part of the programming world. So, you spend 4 or 5 years learning the most intimate details of software development and may rarely have an opportunity to use that knowledge.
(I have a hard time learning in this environment, do you?)
Expense was a big problem for me, I bet others have shared this experience. A university diploma isn’t cheap and it is growing more and more difficult to justify for a lot of people. I spent about 10 years on my undergrad working full time as a way to offset the cost. Each semester I took one or two classes and paid in cash. While taking one class per semester, the industry work experience I was gaining quickly became more valuable than the degree I was working on. I knew something was up, but there that nasty rumor that you will never advance without a degree kept looking my way.
There are quite a few non-traditional school options around that are probably worth exploring if you find yourself questioning the university route. Job specific schooling can be a great alternative for people who don’t fit well into a university system, or people that are already in the workforce but are looking for a change.
Tech schools range from the extremely casual to an intense boot camp type atmosphere (sans push ups I suspect). On the more casual side of things are websites like codeschool.com where a student can register and work through a series of exercises based on the technology they want to learn.
(Nashville Software School graduating class)
The goal of this program is to teach technologies that there is local market demand for, and to help the students land a gig as soon as they graduate. From what I understand, they are doing a pretty good job at both of these things.
If you want to build software for the space station, or for geological drilling expeditions, sure, go get that university degree. But if you aren’t set on that, you may want to consider some vocational options.
Next time I’ll be talking with a friend and instructor at Nashville Software School to get a closer view of how they do things.
Steve Wozniak is the other founder of Apple Computer Corporation, the one who actually built the Apple I and Apple II. Many of us know that ‘Woz’ left Apple quietly in 1987, for several reasons, one being the realization that in their early partnership to create the Atari Game Breakout. (The two were to split the fee. Jobs collected $5000, and gave Woz $350; Woz would not find out for over a decade.)
Despite the breakup, Wozniak has been quiet about his feelings about Jobs. It might have been out of loyalty to Jobs, or to Apple Computer, or, perhaps, Steve Wozniak just isn’t the kind of person to make a mess in public with no clear benefit to anyone.
All that changed with the new movie, Jobs, starring Ashton Kutcher. Suddenly there was a new narrative about the founding of Apple, one without Steve Jobs around to make corrections.
It was time for Steve Wozniak to set the record straight, and to do it, of all placed, on a public comment to a Google+ post. Continued »
It looks like Zappos is joined the company wide reorganization bandwagon, but this time it has a new name; holacracy. This new change will mean fewer managers, fewer or no job titles, and small empowered groups working together to solve problems. Gone are the days of working through a red tape to get permission to do work.
When reading about this, I can’t help but think that this is completely in the spirit of the agile manifesto. In the agile world, everyone is a developer. Everyone focuses on the product and what actions can be taken to ship software and ship it faster.
Fred George refers to this phenomenon as programmer anarchy.
Back in the day, I worked at an early stage start up in a previous life that had a fair bit of success with this. We were building a software product, trying to get to market as fast as humanly possible to see if the customer would like it. If the liked it, great! If they didn’t, we would do the same thing but different and see if they liked the new different. Failure was quick and changing directions was no big deal.
Slowly, this little infant of a software project turned into and adolescent. The project had grown quite a bit, the team had grown a little bit, and most importantly we had paying customers. Paying customers that don’t like failing software. Releasing multiple times a day became dissatisfying for customers that like some amount of stability.
We did have managers, titles, and team members self-identified with certain parts of product development that they enjoyed or felt comfortable with.
As far as I can tell the mistakes that lead us to be not holocratic (and not very agile) were having paying customers, and a product that eventually became monolithic. One of those seems to be negotiable though. I mean, Facebook and Google seem to do just fine with monolithic software.
Many times, this structure can lead to customers being used to vet new ideas. Facebook doesn’t exactly have an untarnished record as far as releasing quality software goes. I’m sure you see the complaints and reports of weird behaviors in your feed each time they push a noticeable update. The theme for holacracy seems to be mediocre software as fast as possible, then something different is customers complain loud enough.
I wonder how this will work out for Zappos.
If you want to start a fight on my team, bring up estimates. Just the idea of estimates is a “hot button issue”, and I don’t think it’s just my team.
On any given team, the technical staff are likely sensitive about how their estimates will be used. They have reason to be sensitive; there is a system-wide cultural misuse and misunderstanding around the concept. Woody Zuill is trying to reframe the estimates discussion around the idea of starting and completing small pieces of work, and not estimating at all. You can follow that by looking at the #NoEstimates hashtag on twitter. Matt Heusser, the lead contributor to this blog, did some investigation and wrote an article recently for CIO.com about transitioning from traditional planning and estimating to, well … not.
Let’s consider another case: What if the act of estimating tasks actually has value?
If you are willing to grant that, then we can explore ways estimation might be a useful exercise for you.
(kanban board: how much work goes here sometimes depends on your estimates)
My ideas on estimates:
Estimates can be used for all kinds of things: accounting and billing, planning what can be completed in a sprint, and, yes, as a whip to punish people who can not comple work they have “committed” to complete. I’d be willing to bet you’ve experienced each of those at some point in your tech career. One thing I think we ignore though, is the way group estimates can take the ideas (and variances!) in our head and bring them out to the table where we can talk about them for real. That’s a meaningful benefit. Since estimates aren’t going away anytime soon for most people in software, that’s what I’d like to focus on: The benefits.
Pretend you’re in a meeting to plan a some work for the next two weeks. (If you are a scrum-er, this is “grooming the backlog for the next sprint.”) You all talk about a feature for a bit, what this thing should do, how users might benefit from it, and think you understand it pretty well. At least to the extent that you can start to make some guesses about how complex you think the work to build this feature is.
This conversation takes place:
PM: Alright, does everyone think they understand this enough to make an estimate?
PM: OK then, lets do this in t-shirt sizes. 1…2….3….go!
I think this difference is really important and is something the no estimates community doesn’t talk about enough. Sometimes estimation differences means people have different skills on the technology, the code base, or even a different understanding of the problem to be solves. Sometimes they are a lesson in disguise. As a general rule, if your technical staff have wildly varying opinions on how long something will take, then something might be going on there worth talking about. This might not tell you where to look or immediately solve a problem, but it sure seems like a good start.
This difference in estimates can be a clue that people have different understandings about what they need to work on. Maybe there is a complete misunderstanding about what is being built, maybe someone knows about available libraries or utilities that you don’t know about, or maybe some aspect of this widget has already been written by another group in your company. Without that estimate you may have never had that conversation. The group could have had the story grooming session then gone off happily and started working only to realize later that these misunderstandings existed. What a shame that would be!
What you can do tomorrow:
Don’t stop estimating, rather reframe how you think about this tool. Start thinking of estimates as a tool that can help groups of people reduce ambiguity and gain clarity on a topic. Don’t worry so much about being victimized by a process.
I mean, sure, we could point out the process is broken. But has that ever helped anyone?
Focus on the good, and there’s a chance things might get better.
The choice is yours.