This week a guy announced he is resigning. He gave more than two weeks notice which was classy of him. He was a good guy, he made some useful contributions.
It got me thinking a bit about software development teams. At the site where I work there are several hundred developers across many teams for different clients. At a very small number of places like Microsoft, Google, Facebook, there are no weak developers. Those firms have the advantage of a constant stream of outstanding applicants so they have the luxury of having pretty much everyone being very high performing.
In general at places where I've worked over the years, there was more of a mix. Some really outstanding developers, some solid pretty good developers, some mediocre developers, and some low performers.
Now when someone quits, it's almost always someone from one of the first two groups. They tend to have better prospects and people who worked with them in the past will keep in touch more and be agreeable to them working with them again at some new firm. The lesser developers tend to have much less mobility so they tend to rarely leave voluntarily.
Now with recruiting replacements it tends to follow the breakdown of the existing developer population. So sometimes the replacements can be as good or better than the people who quit, and sometimes you will be unlucky and bring in someone from groups 3-4. So over time on its own then what could happen is that inevitably the ratio of good and very good developers to mediocre and bad developers becomes less. Entirely due to the differing rates of attrition of good and bad developers, and natural variance in recruiting replacements.
This will cause a bad situation over time as developer skill is by far the crucial factor in the success of a software team. While most teams can and have to carry some mediocre and weak performers, there needs to be a healthy percentage of good developers to be long term sustainable and successful.
So I realized something. When a good developer quits, then the correct move for the employer is to also fire a weak developer at the same time. So instead of having to bring in one new person they recruit two. This is crucial to keep the team balanced and the proper ratio of strong developer to less strong. So when bringing in two new people ideally they will both be good. But if variance hits and only one is really strong then the overall team is still ok and the team remains well balanced.
Sunday, November 23, 2014
Friday, October 17, 2014
back at work
There's some news on the job front. I have found work. After I was laid off I had an informal list of people to contact who I'd worked with in the past. It was to get references and see if they knew about any leads. I also updated my resume and posted on Monster and Career Beacon.
There were a couple of leads and I put my name in at a few places. I got an interview and an offer followed. It looked okay so I accepted the offer and returned to work in July. I was out of work for a bit more than a month. So that wasn't too bad. Good to have paycheques coming in again that's for sure.
I caught on with an IT consulting firm in the Halifax office. I've been in consulting in the past from 1997-2001 back with PRIOR Data Sciences and xwave. It's a bit different than doing commercial product development from the years at Core Networks, SupportSoft and RIM. Writing code that we don't own. It's nice to be billable again and generating revenue, instead of being a cost. It's a Java and Oracle project I'm starting out on so that part is still pretty familiar.
I miss work from home at times. But the commute is pretty favourable to where I live so it hasn't been too hard an adjustment. So a new chapter begins.
There were a couple of leads and I put my name in at a few places. I got an interview and an offer followed. It looked okay so I accepted the offer and returned to work in July. I was out of work for a bit more than a month. So that wasn't too bad. Good to have paycheques coming in again that's for sure.
I caught on with an IT consulting firm in the Halifax office. I've been in consulting in the past from 1997-2001 back with PRIOR Data Sciences and xwave. It's a bit different than doing commercial product development from the years at Core Networks, SupportSoft and RIM. Writing code that we don't own. It's nice to be billable again and generating revenue, instead of being a cost. It's a Java and Oracle project I'm starting out on so that part is still pretty familiar.
I miss work from home at times. But the commute is pretty favourable to where I live so it hasn't been too hard an adjustment. So a new chapter begins.
Wednesday, October 15, 2014
laid off
well it finally happened. I was laid off from a high tech job. it was back in June. I was working at home. a little after 10 AM the phone rings. it was the director. he was mumbling and it was hard to hear. he said something like there's bad news there's been a reorg and I've been downsized. my work duties end as of the end of this phone call. There was also an HR person on the line and he handed it over to her. he seemed anxious to get off the call so I didn't keep him. It was over in about 30 seconds.
The HR stayed on about 30 minutes going over the many details of severance. There were some complications because of work from home. Usually in office the person is just run out the door and your cubicle is left behind for IT or whoever to scavenge or clean up. someone might meet you after with a banker's box of your personal stuff like headphones or whatever.
so that's that. I survived a great many downsizings over the years. statistically I was bound to get caught up in one eventually. meh RIM went from 19,000 to 5,000 employees in the last 3 years so for everyone, any day you go to work at RIM could be your last. well I got ahead financially at RIM and iPhone had been released when I joined in 2008 so I knew going in. I did get my severance which will come in handy.
The HR stayed on about 30 minutes going over the many details of severance. There were some complications because of work from home. Usually in office the person is just run out the door and your cubicle is left behind for IT or whoever to scavenge or clean up. someone might meet you after with a banker's box of your personal stuff like headphones or whatever.
so that's that. I survived a great many downsizings over the years. statistically I was bound to get caught up in one eventually. meh RIM went from 19,000 to 5,000 employees in the last 3 years so for everyone, any day you go to work at RIM could be your last. well I got ahead financially at RIM and iPhone had been released when I joined in 2008 so I knew going in. I did get my severance which will come in handy.
Monday, October 13, 2014
The Phoenix Project by Gene Kim, George Spafford, Kevin Behr
I recently read The Phoenix Project: A Novel About It, Devops, And Helping Your Business Win. It's a fable about Bill, the director of midrange computing at a fictional large auto parts manufacturer called Parts Unlimited. Bill has set up a comfortable life in middle management in the orderly world of AS-400s.
One morning Bill is called to the CEO's office. He's informed that the CIO and VP of IT operations have been terminated and Bill is now the VP. So Bill is reluctantly thrust into being a freshly minted VP in a role he did not seek. Bill's early tenure is marred by numerous IT disasters such as a failed launch of a major product called Phoenix, a failure to make payroll due to an IT issue, and a failure in the retail point of sales system. Bill has to work extremely long hours dealing with these crises and it begins to take a toll on his family life. To make things even worse the CEO presents Bill with an ultimatum. Fix IT in 90 days or the IT department will be outsourced.
Early on Bill is introduced to a mysterious guru character named Eric. Eric teaches Bill about how IT can be approached like manufacturing. Eric takes Bill on tours of a large manufacturing plant. They discuss inventory and work in progress, the evil of inventory in manufacturing, and how to apply this to IT.
Eric introduces the modern concept of DevOps. In devops development and operations are combined. So the idea is to reduce this "over the wall", "works on my PC", "all hands on deck deployment", "developer role / IT role", "separate performance testing" dysfunctions and inefficiencies. Replacing with one piece flow and continuous deployment.
The book was ok. It was a compelling read for the first 100 pages or so. It dragged a bit in the last 50 pages. From the developer side I could relate to a lot of it. Parts of the book, especially toward the end, came across as a bit autobiographical and self-congratulatory.
Still it was worth reading. The director at the time ordered everyone to read it and I've finally got around to it. I'm not sure if it was supposed to make us think, or it was "this is what we're doing now." I got it from the local library, as the manager at the time refused to allocate budget for some local copies. I guess that shows how important it was - brand new hardcover copy can be had for $20 each. meh w/e.
It was good for me to see more the IT operations side and what happens to both prepare for, and to support deploying the code that the developers release. I've written about one piece flow on this site mostly as it relates to the software developer experience - since that's been my area all these years. It was good for me to get some more insight into the IT side. I was pleased to see the same principles of value stream apply on the operations side too. So it can be integrated with development if the effort is put in to set it up.
One morning Bill is called to the CEO's office. He's informed that the CIO and VP of IT operations have been terminated and Bill is now the VP. So Bill is reluctantly thrust into being a freshly minted VP in a role he did not seek. Bill's early tenure is marred by numerous IT disasters such as a failed launch of a major product called Phoenix, a failure to make payroll due to an IT issue, and a failure in the retail point of sales system. Bill has to work extremely long hours dealing with these crises and it begins to take a toll on his family life. To make things even worse the CEO presents Bill with an ultimatum. Fix IT in 90 days or the IT department will be outsourced.
Early on Bill is introduced to a mysterious guru character named Eric. Eric teaches Bill about how IT can be approached like manufacturing. Eric takes Bill on tours of a large manufacturing plant. They discuss inventory and work in progress, the evil of inventory in manufacturing, and how to apply this to IT.
Eric introduces the modern concept of DevOps. In devops development and operations are combined. So the idea is to reduce this "over the wall", "works on my PC", "all hands on deck deployment", "developer role / IT role", "separate performance testing" dysfunctions and inefficiencies. Replacing with one piece flow and continuous deployment.
The book was ok. It was a compelling read for the first 100 pages or so. It dragged a bit in the last 50 pages. From the developer side I could relate to a lot of it. Parts of the book, especially toward the end, came across as a bit autobiographical and self-congratulatory.
Still it was worth reading. The director at the time ordered everyone to read it and I've finally got around to it. I'm not sure if it was supposed to make us think, or it was "this is what we're doing now." I got it from the local library, as the manager at the time refused to allocate budget for some local copies. I guess that shows how important it was - brand new hardcover copy can be had for $20 each. meh w/e.
It was good for me to see more the IT operations side and what happens to both prepare for, and to support deploying the code that the developers release. I've written about one piece flow on this site mostly as it relates to the software developer experience - since that's been my area all these years. It was good for me to get some more insight into the IT side. I was pleased to see the same principles of value stream apply on the operations side too. So it can be integrated with development if the effort is put in to set it up.
Subscribe to:
Posts (Atom)