ed – Page 33 – Walking Contradiction

Technical Career Tracks

I’ve been involved in discussions with technical people about the disconnect between companies that want/need to hire and retain more technical people, but whose policies seem to favor those in the managerial roles. About a year and a half ago, I had a long talk with a fellow Rackspace employee who was charged with developing our “Technical Career Track”, which was going to help us succeed in attracting and retaining the best technical talent we could. Being a technical person myself, this was of course of great interest to me. But though the plans were extremely well-intentioned, they fell short of their goals.

Since then I’ve had the opportunity to speak at a lot of tech conferences, and I’ve used them to talk with people I’ve met there about how they saw the situation where they work. Wow, talk about opening the floodgates! Almost without exception, every technical person in a company of more than, say, 100 people, felt the same way: that they would be better off switching to a manager role, at least as far as career prospects and salary are concerned.

Based on those discussions, I believe that I’ve identified a fundamental flaw in the way that most organizations are structured that prevents even the best-intentioned companies from being able to treat their technical talent equitably.

I should point out that although I work for Rackspace, and that we are struggling with the same issues, that this is not based solely on this one company. Rather, the discussions I’ve had inside of Rackspace have led me to talk with others when I’ve traveled to conferences, and who are in no way connected to Rackspace, in order to get a variety of insights and observations from employees of many different companies. I felt that the added viewpoints would help me to separate issues that were intrinsic to Rackspace’s culture with those that were common to most tech companies. The points I am making apply to nearly all companies of people I spoke with, including Rackspace, but this is in no way to be taken to be directed at Rackspace in particular.

After much discussion, I can say that the problem is inherent in the way that the Human Resources department organizes the employment hierarchy, and not the result of a company consciously discounting the value of technical jobs. Let me explain: to HR, every employee needs to report to someone, and the person they report to needs to report to someone above them, on and on until eventually everyone reports to the CEO. This is an absolute requirement, and is modeled unquestioningly in every company with which I am familiar.

So what? Well, what that means is that if a new development project is started, a new team is formed, usually consisting of developers, business analysts, etc., and all of these people have to report to a manager. If no one of that group is already designated a manager, someone is placed in that role; a team simply cannot exist without a manager, at least in the view of almost all HR systems. This means that someone has to be promoted to that role, and usually it is someone who has displayed competency, initiative, and other positive qualities in their previous work. On the developer side, though, there is no such automatic role that must be filled. Usually technical levels are designated numerically, with the most junior devs being level 1, and the more experienced devs as level 3, 4, or even 5. In order to be equivalent to the managerial track, the technical track would have to require that every team have a Tech Lead as the leader of the developer team, but that isn’t the case in any company that I interviewed. And like the person selected to become a manager, the newly promoted developer would be the one on the team who has most consistently demonstrated solid work.

Typically technical promotions are always strictly review-based, and only happen on a pre-determined schedule (such as annual reviews). More importantly, they are completely at the discretion of the manager. There may be objective criteria for each level written down somewhere, but simply meeting those criteria is not a guarantee that you will be considered for a promotion to that level. And to make matters worse, in a dynamic, fast-moving company, developers rarely have continuity of management, so while a growing company needs more and more managers, each successive manager evaluates their devs based on their improvement from the day that the manager started, not since the dev started. This was far and away the biggest complaint that I heard, and it was the one constant across the various companies. Every time there is a re-org, or a new team created due to growth, or a re-assignment to another team, all the work you’ve done in the past is discounted, and you’re pushed back to the starting line.

What is the alternative? How can we change this? Imagine a company in which every development team had to have not only a manager, but a technical lead. That Tech Lead would be in most companies a Developer 4, 5 or higher level title, and if no one on the team was already at that level, someone would have to be promoted to it, just as someone would have to be promoted to a manager. It would be just as rigid an HR requirement. Then later, if a team is successful and grows to the point where it needs to be split, on the management side the former manager now becomes a Director or similar role, and a new manager is promoted for each of the new teams. To be equitable, on the technical side, the former Tech Lead should be promoted to whatever the next higher level is (the names they give these roles are laughably grandiose!), and two new Tech Lead promotions need to be made. This would ensure that the number of people at the equivalent level on both the managerial and technical tracks would remain equal, at least for technical teams. And it would remove the subjective, discretionary promotion practices that end up leaving developers feeling like they have no future with a company. The result is that on the technical side of the business, there is a requirement for parity in number between the managerial track roles and the technical track roles.

The objections I’ve heard when I’ve shared these insights is that not every developer is qualified to be a Tech Lead. That’s true, but let me ask you this: why is everyone promoted to a manager role any more qualified? Aren’t there just as many people who get into management only to find themselves either ill-fitted to the role, or in over their heads? The same would be true for developers: some would falter, while others would thrive. Many would not want the tech lead role; they would be more comfortable just writing code instead. That’s no different than someone who doesn’t want to be a manager, and have to deal with personality conflicts, and all the meetings and paperwork associated with the role.

I think that every company that is serious about attracting and retaining technical talent should look at the numbers: do they have just as many people in high technical roles as they do in high managerial roles? Are the numbers of people at the Director or VP level who are technical equal to the numbers of mangers? Are they even close? If not, then you need to question your HR structures. Change the rules so that technical people are required to be promoted at the same rate as managers, and you’ll probably be amazed at the results.

OpenStack Miniconf at Pycon AU 2013

Friday was the pre-conference day, with two miniconfs: one for Django, and the other for OpenStack. While I’d love to spend some time digging deeper into Django, I figured that given my background as an OpenStack developer, the OpenStack miniconf was for me.

There were probably 40 people or so in attendance, and it was a good mix of those who were completely new to OpenStack, those who have looked into it a bit and wanted to learn more, and those who either were core developers or (in my case) a former core dev. Tim Serong from OpenSUSE opened up the day with the talk “WTF is OpenStack?“, which was an excellent introduction for those who had heard a lot about this “cloud” stuff. The presentation included the classic spoof by The Onion about “that Cloud thing” (with apologies to Robert Collins of HP, who really does totally know what that is). He covered all the projects within OpenStack, and how they work together.

Robert Collins then followed with a talk on “Deploying OpenStack using OpenStack“, which tackled the issue that although OpenStack allows you to automate the provisioning of cloud resources, installing OpenStack itself is a terribly manual process. His solution is “TripleO“, which stands for “Openstack On Openstack”. It sounds similar to the iNova project from Rackspace, but with several differences. From the ReadMe:

TripleO is the use of a self hosted OpenStack infrastructure – that is OpenStack bare metal (nova and cinder) + Heat + diskimage-builder + in-image orchestration such as Chef or Puppet – to install, maintain and upgrade itself.

Christopher Yeoh of IBM was next, and gave an excellent overview of the changes coming in v3 of the Nova API. The current v2 API was smartly designed by making only a precious few critical parts part of the core API, and making everything else an extension to this core. The problem is that some of the implementation details that seemed wise at the time are starting to show some cracks, both with consistency in naming and in the connection to the core Nova code. Nova v3 API addresses these problems by removing the requirement that extension name matches the class name, allowing for cleaner (and thus more consistent) extension naming. Extensions now must be derived from a common base class; this was optional in v2. Overall, it was apparent that the people working on the v3 API had learned the lessons that the v2 experience offered, both good and bad, and that as a result the v3 API will be much more consistent and robust.

After lunch Tim Serong gave a talk on the state of OpenStack development on OpenSUSE. They are doing some interesting stuff with Crowbar for deployment, and have spent a lot of time on their internal CI processes. I didn’t take very extensive notes, as this is an area that I have little experience and/or interest in, but it was obvious that Tim is passionate about this, and that they are doing some excellent work at OpenSUSE.

Next up was Robert Collins again, this time talking about testing, covering both improvements in the tools themselves (e.g., the testtools module), as well as his work in creating a test runner runner. No, that wasn’t a stutter – this is a script to run a test runner, such as Jenkins in this case. With the growth of projects in OpenStack, it can take a very long time to run the tests, which is done when a change is first proposed for review, and then again when it has been approved to ensure that no conflicts have creeped in while the change was in the review process. In order to speed this up, his test runner runner breaks the tests into several parallel processes, and then aggregates the results. This means that the time required to run all the tests can be reduced greatly, depending on the number of parallel processes. It also provides for test randomization, which can help reveal hidden test inter-dependencies.

Next up was a talk on how to get involved in OpenStack development, which covered the basics of where you can find bugs to work on, or blueprints to contribute to, as well as the review process and Gerrit. Michael Still from Rackspace was supposed to give this talk, but the birth of his child was a bit more important, so Robert Collins stepped up and did the talk for him. This was more of a review session for me, but it had a lot of useful information for those who were new to OpenStack development.

That was the last talk; after that was the hackfest, which had the goal of getting participants to find a fairly simple bug, fix it, and submit it for review. In practice, though, most of the time was spent helping people get Devstack up and running on their machines. Those of us who were OpenStack ‘veterans’ helped where we could, and in the process I had some great discussions with people about OpenStack, so even though we never got to fix any bugs, I believe that the people there who were new to OpenStack got a lot out of that time.

Finally was the bar track! Many of the miniconf attendees, myself included, retired to one of the many bars here at Wrest Point, and enjoyed a cold beer after a long day of learning about OpenStack.

Some More Differences

After a few more days down under, some more observations:

Overall, people in Sydney are not nearly as fat as Americans. What is even more remarkable is that I have not seen any fat children. It takes getting out of America to realize that no, 10-year-olds don’t typically have rolls of fat around their bellies.
I’ve spent hours walking throughout downtown Sydney, in both the residential outskirts, the business office areas, and the tony shopping districts. I have yet to see a single police officer on patrol. Maybe they’re all undercover, but still – in most US cities, there is always a uniformed police presence.
Even though I’m sure there are a number of tourists among the crowds, people on the streets know how to walk without bumping into others. Coming from New York City, I always took this skill for granted – until the first time I tried walking through Boston. Boston is a great town, but no one seems to have any awareness of their surroundings as they walk down the street. Since then I’ve noticed that each city I’ve been in has a general level of sidewalk awareness, though none are close to Boston in terms of obliviousness. Sydney is the first city which approaches NYC in this regard.
I always had the impression that Aussies were heavy beer drinkers – perhaps too many Crocodile Dundee movies. Yet it is difficult to buy beer here unless you know where to look. Convenience stores don’t sell it; supermarkets don’t sell it. The only place I’ve found to buy a beer are the “bottle stores” (their ‘liquor stores’). And while I’ve seen plenty of local beers on tap, I’ve yet to see Fosters anywhere. I’ll bet that if you ask Americans to name an Australian beer, the only one they know of is Fosters.
Understanding people speaking with the native accent isn’t too bad, but it is much, much more difficult to understand them on TV. I initially thought that it was due to crappy speakers on the TV in my hotel, but flipping around I found an old American movie, and the voices were crystal clear. Flip back to an Australian show, and I get about every third word.

The Wrong Side

I arrived in Sydney this morning. Not only is this my first time in Australia, it’s my first time in a place where cars drive on the left side of the road. I took a cab from the airport, so I didn’t have to deal with it from behind the wheel, but it still seemed very odd visually. Still, it was pretty much what I had anticipated.

What I didn’t anticipate, though, was how different it would be as a pedestrian. When crossing the street, I reflexively turned to the left to look for oncoming traffic, and seeing none, began to cross… until I heard something coming from my right! The reversed traffic flow meant that I had to re-learn how to cross a street!

There is another, much more subtle effect of this that I noticed as a pedestrian: when walking along the sidewalk, I naturally keep to the right, but here more often than not, people keep to the left while walking, too. I suppose that makes sense, given the convention for automobiles, but it was surprising nonetheless. It’s striking how such small differences can change your routine so dramatically by making you focus on things you would normally take for granted.

DOMA and Common Sense

Today’s ruling by the Supreme Court striking down the Defense of Marriage Act, or DOMA, is both ground-breaking and trivial at the same time. It’s a huge change from a legal perspective, but more of a “duh!” moment in human progress.

We look back 40 years or so, and see the landmark cases that struck down laws against interracial marriage, and have a hard time imagining living in a world where you can’t marry the person you love because of their skin color. From our perspective, those decisions were trivial: of course you should be able to marry someone regardless of their skin color or eye shape. That’s just silly to think otherwise.

It is my sincere hope that 40 years from now, people will look back on this decision and have a similar “duh!” reaction to it.