Business – Page 4 – Walking Contradiction

PyCon 2014 Review

Better late than never, right?

PyCon 2014 happened two weeks ago, and I’m just getting around to write about it now. Why the delay? Well, I took a few days of vacation to explore and enjoy Montréal with my woman after PyCon, and when I returned I found myself trapped under a mountain of work that had built up in my absence. I’ve finally dug myself out enough to take the time to write up my impressions.

This PyCon (my 11th) was different in many ways, not only for the fact that for the first time, the US PyCon was not in the US! It was held in Canada in beautiful (and cold!) Montréal. It was the first time in years that I did not arrive early enough to help with the bag stuffing event, which has always been a highlight of my PyCon experiences. I arrived late Thursday afternoon, and just made it to the Opening Reception, where I not only touched based with my fellow Rackers, but also ran into dozens of Python people I have gotten to know over the years. PyCon is special in that regard: while I have technical contacts at many of the conferences I attend, I consider many of the people at PyCon to be my friends.

I was pleasantly surprised by the bold choice for the opening keynote: John Perry Barlow, one of the founders of the Electronic Frontier Foundation (EFF).

OLYMPUS DIGITAL CAMERA

He pulled no punches, and let the audience know exactly where he stood on matters of security, openness, government spying, and free information in a society. I enjoyed his talk immensely, but I knew that some with more conservative views might not respond positively to the anti-corporation, anti-BigBrother tone of his talk, and judging by the sight of several people leaving during the talk, I think I was right. Still, I appreciated that the primary conferences for one of the most important Open languages took that risk.

I attended several sessions, and bounced between them and my duties at the Rackspace booth in the vendor area. We were once again a major sponsor of PyCon, and this gives me great pleasure, as I had first convinced Rackspace to become a sponsor shortly after I joined the company 6 years ago. We benefit so much from Python and the work of the PSF, it’s only right that we give something back.

I won’t go into detail about the individual sessions, but I would encourage you to check out the videos of all the talks that are available on the pyvideo site. The quality of the presentations keeps getting better and better every year, which is a great reflection on the talk selection committee, who had to select just 95 talks from a total of 650 proposals. That is a thankless task, so let me say “thank you” to the folks who reviewed all those proposals and made the tough calls.

I would also like to note that this year 1/3 of the speakers were women, and by some estimates, the percentage of female attendees was nearly as high! (They don’t record the sex of a person when they register; hence the need for estimates). This is a phenomenal result in the traditionally male-dominated tech industry, and it isn’t by accident. The PSF has actively encouraged women to attend, both by creating (and standing behind) a Code of Conduct, as well as offering financial assistance to those who might not otherwise be able to attend. And this year was another first: onsite child care during the main conference days. I think this is an amazing addition to PyCon, even though my kids are grown. It allows many people to come who would otherwise not be able, and also encouraged more families to travel together, making PyCon the hub of their vacation plans.

That’s exactly what I did, too. Linda flew into Montréal on Saturday evening, hung around PyCon for the closing session so that she could get a glimpse into the strange geek world I inhabit regularly, and meet some of my friends. We spent the next few days exploring this city that neither of us had visited before, enjoying ourselves immensely. Coming from South Texas, we could have done without the near-freezing temperatures and snow, though! Here was the view from our hotel window: OLYMPUS DIGITAL CAMERA

It was a wonderful vacation, but much too short! We’re really looking forward to returning next year for PyCon 2015!

Sales Should Not Equal Sleaze

I like to lease automobiles. I could go on at length about the financial pros and cons of leasing versus buying, but I’m not trying to convince anyone here. Just saying that it works for me.

I guess that I should mention that I worked in sales for many years, and have gone through several training programs that ranged from the high-pressure adversarial sales approach to the helpful partnering style that I prefer. So I know enough to recognize when someone is using these tactics against me. And it goes without saying that I strongly dislike when I feel that I’m being played.

My current lease ends this month, and so recently I started shopping around for a new car. Since I don’t care about cars beyond the ability to get me around reliably and comfortably, I talked to people I know who are much more knowledgeable about these things, did a little research, and then went to local dealers to test drive the cars. I liked a few models, including one from the dealer that is the focus of this post, so I asked for a quote on how much the lease would run.

Let me pause here to explain that I will not name the vehicle brand, dealers, or sales people that I am discussing in this post. My goal is not to publicly shame them, irrespective of whether they are deserving of such a shaming. If you know me and want details, I would be more than happy to share them with you privately. I will be telling everyone I know in the area who might be considering buying a car to avoid this particular dealership at all costs.

I received the quote for the lease: $179/month! The email said in nice bold letters: “I have great news we have the [vehicle type] in stock and available and you have been selected to recive [sic] our Lease Special.”

Wow! What a great price! It was around $100 less than what I was expecting! Aren’t I so lucky!

Yeah, and I was born yesterday. Still, even though I figured that the final price would be higher, I still liked the car, so I went in to iron out the details. Up until then, the sales person had been very pleasant and relaxed; not at all the stereotypically pushy type we all loathe.

All was going well until he brought a purchase agreement for me to sign. It had no numbers filled in, but stated that I was agreeing to purchase the vehicle from that dealer. Up until that point, the only number I had in writing was the $179/month quote from the email, and I was tempted to write that in and sign it, but instead pointed out that I wasn’t about to sign a blank commitment. He fumbled with an explanation, but I still refused. At that point he got up to “speak to his manager”, and about 10 minutes later returned with that sheet with a figure filled in: $354/month!

Now let me explain: if I had been quoted that price originally, I would still have been interested, even though it was a bit higher than what I would have been paying for one of the other car models I was considering. But the extreme nature of the bait-and-switch tactics employed just really turned me off. I don’t mind paying a fair price for things I want, but I absolutely refuse to do business with companies that use these sorts of dishonest tactics in order to trap you into doing something that may not be in your best interest.

After I explained that not only was the price higher than I was willing to pay, but that I felt like I was being duped, he went back to his manager for another 10 minutes or so. I probably should have walked out right then, but I guess I still had some glimmer of hope that they would at least realize that their BS tactics weren’t going to work with me, and would instead start dealing with me straight. Instead, he came back with a quote that was a little lower, but still way higher than anywhere else (yes, I checked other dealers before coming in!). The manager even came over to try to close me, but at that point I wasn’t having any of it. I got up and left.

I still liked the car, though, and looked online for a dealer over on the other side of town. Their website quoted me $326 for the exact same car with the same features. I contacted them online, and told them that I had just been through Salesman Hell, and was hoping that I could work with them. After a few emails and phone calls to iron out the details, I agreed to lease the car from them. Everyone I dealt with at the new dealership treated me with respect; they realized that I wanted to get a car, and that they wanted to sell their cars, so it was in both of our interests to work together to make that happen.

I feel sorry for businesses that are stuck in the mindset that the only way to get people to do business with them is to trick them. Unfortunately, there are many of these still around, and I just happened to run into one of them.

PyCon Canada Review

It’s been almost a week since PyCon Canada ended, and I had meant to write up a review, but I was busy, so better late than never.

Besides an opportunity to learn more about Python, this conference served as a “training ground” for next year’s PyCon Montréal, which is where the 2014 US PyCon will be held. Yeah, I know, it seems silly to still call it PyCon US instead of PyCon North America, but I suppose it has to do with domain names, trademarks, etc., so I’ll refrain from ranting about that. So to that end, I volunteered to be an MC for roughly half of the total conference. Normally for PyCon you have two roles: Session Chair, who introduces the speaker, times the talk, and manages the Q&A session; and Session Runner, who makes sure that the speaker gets from the green room to the correct session room, and who handles any problems such as missing video adapters, etc. But for PyCon CA, this was changed so that there was an MC and a Runner. The MC was someone with experience from PyCon US, and they served for half of the day in the room. There were fresh runners for each session, but rather than just escort the speaker, they did everything that session chairs and runners do, with the MC guiding them and making sure that they knew what was expected, and who could help out if there were any problems. So in many ways, though I spent half the conference running the talks, I felt like I hardly did anything. The runners did just about everything, and I only had to help out a few times. I have no worries that they’ll be ready for the big leagues next year!

As expected, there were many interesting sessions. I’m not going to give you a summary of everything I saw that I liked, but instead I’ll touch on a few highlights. Probably the one that made the biggest impression on me had nothing to do with Python per se, but instead was about Sketch, a programming language designed by MIT to get children thinking about programming without saddling them with the tedium of learning syntax. This was shown in the keynote on Sunday given by Karen Brennan, who is an Assistant Professor of Education at Harvard University. Besides making it easy for the kids to get started learning about programming concepts, it also makes it easy for them to share their projects, or to take someone else’s project and add to it. In other words, they are teaching kids about the benefits of open source and shared code! And while it’s designed for kids, I think it would also be a huge benefit for non-technical adults by helping familiarize themselves with programming without having to get totally geeked out.

Another talk I enjoyed was Git Happens, which was given by Jessica Kerr. This was one of the talks for which I was MC’ing, and hadn’t otherwise planned on attending, as I’m comfortable enough with Git. But rather than be bored, her way of explaining how Git works was much, much clearer than I have ever been able to manage when helping someone else get up to speed with Git.

Brandon Rhodes gave an excellent talk entitled Skyfield and 15 Years of Bad APIs , which covered his efforts to re-write his astronomical calculation library. It was fascinating to see how decisions which seemed reasonable at the time turned out to be less than optimal, and how he learned from them to make the new version much cleaner. As an aside, if you haven’t seen Brandon talk, you’re missing something special. He blends insight with an extremely dry sense of humor, making for a very enjoyable session.

I’ve already written about Dana Bauer‘s Red Balloon demo, so I won’t repeat it here. Suffice it to say that it captivated the attention of everyone in the room.

My talk was basically the same talk I had given the previous month at PyCon Australia, but in a much shorter time slot: 20 minutes instead of 45! I spent much of the time before the conference consolidating my slides, and eliminating anything I could in order to cut the length of the talk. I practiced giving the session over and over, speaking as fast as I could. When the time came, I apologized in advance for the speed at which I was about to give the talk, and then blazed through it. To my surprise, I managed to finish it in 18 minutes, and had time for a few questions! Afterwards I spoke with some who attended the talk to get an idea how it seemed to them, and they didn’t feel like I skipped over anything that made it hard to follow, which was my goal when I was paring it down.

After the sessions had ended, I went with a fairly large group of people to a local restaurant. I didn’t know very many people, and those with whom I sat were all from the team in Montréal who were going to be running PyCon 2014. They started out as strangers, but by the end of the evening (and more than a few pitchers of beer!), we became friends, and I look forward to seeing them again in Montréal next April!

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.