Tag Archives: management

Thoughts on unlimited PTO

Posted on by
2

The idea of unlimited paid time off (PTO) has been around for a while. I wrote about it in 2015 shortly after my then-employer changed from a traditional PTO policy. But unlike many practices in the tech sector, unlimited PTO has not become ubiquitous. It’s still a matter of debate, especially since it can result in pressure to take less time off because there’s no signal about the appropriate amount.

The joys of unlimited PTO

My old company was small, engineering-focused, and fully-remote. Everyone wore a lot of hats and there wasn’t a lot of redundancy to go around. But the unlimited PTO model worked for us. Employees that were there a full year before and after the switch used, on average, about half a day more of PTO in the unlimited model.

We had a minimum policy: you had to take at least two one-week periods off each year. This helped make sure people did take time off and established that “unlimited” wasn’t a way of saying “don’t actually take time off, we just don’t want to carry this liability on our balance sheets”.

For me individually, I didn’t take much more time off than I had previously (I’m pretty bad at taking PTO to begin with). What I really liked about it wasn’t the lack of a limit, but the lack of having to think about it. Need to take a day off? Just do it. There’s no “hm. Well, should I only take half a day so that I can make sure I have some at the end of the year if I need it?”

After Microsoft acquired our company in 2017, we were back to a traditional model. We received about the same number of days off as I had been taking under the unlimited policy. But now I had to think about it. At Red Hat, we also have something like the traditional model. And I’m bad at taking it. In part because I tend to flex my work time in order to attend off-hours community events. In part because I’m just bad at it. I long for the day when I can just take time off and not worry about whether or not there will be any left for me at the end of the year.

To track or not to track?

Over the weekend, Alyss asked about tracking unlimited PTO:

I can understand the hesitancy. If your manager can reject PTO requests arbitrarily, then you don’t actually have an unlimited PTO policy. But the request/approval process can be useful for coordination. You don’t want to show up one morning to find a dozen people in your team have decided to take off for two weeks. In that sense, what’s needed more is acknowledgement than approval.

Tracking can also be abused, but I think it’s good on the whole. As a manager, if you can see that someone isn’t taking PTO, you can kick them out of the office for a week. (Not really, of course. But you can encourage them to find some time to not be at work.)

The relationship between managers and corporate culture

Posted on by
Reply

My friend sysadm1138 recently wrote a post titled “managers are more important than company culture.” I don’t disagree with anything she wrote, but I wanted to “yes, and” on it a bit. An employee’s immediate supervisor has the most impact their experience. This is true for everyone, but particularly for underindexed folks. But I would go on to say that managers are a reflection of the corporate culture.

I’ll grant that some people are better managers than others (indeed, some people are better people than others). Well-intentioned managers can still result in hostile and damaging work environments. But just as actions speak louder than words, the behavior of an organizations management at all layers is a more accurate reflection of corporate culture than anything else.

Even if 99 out of 100 managers are terrific, that one bad manager can taint the whole culture. If the organization doesn’t improve or remove harmful managers, then the culture is clear. Similarly, if the organization doesn’t enable and support employees identifying harmful managers, that says volumes about the culture.

This isn’t to say that you should only work at companies that have perfect management. I doubt any such place exists. But you should be aware of what the bad managers say about your culture. Corporate cultures, as expressed in words, are always aspirational. And when something is aspirational, you expect to fall short of it. Probably frequently. The question is how short do you fall? And what are you doing about it?

A culture of overwork

Posted on by
Reply

The technology industry has a problem. Okay, we have a lot of problems, but there’s one in particular that I’m talking about today. We have a culture of overwork and it’s bad for everyone.

As someone who is remarkably lazy, I have a keen interest in doing as little as possible. Of course, this tends to be more of the Sisyphean “automate all of the things” as opposed to just slacking off, but the point stands. Labor productivity in the United States has grown fairly steadily over the last few decades, so why don’t we see that reflected in the tech sector? (I can think of a few reasons offhand, but I don’t want to lose focus.)

My company has what I would consider a very healthy policy. Our vacation policy is effectively “take all the time you need,” and we have a minimum annual amount in case people don’t recognize that they need to take time. It’s in the best interests of company and employee alike that everyone is rested and focused. Exceptional times require late nights or weekends, but those are understood to be the exception.

But even in well-meaning organizations, particularly startups and small companies, it’s easy to let overwork culture creep in. Sometimes getting a release out on schedule means a lot of late nights for developers. Or a production outage for a customer means your support team loses their weekend. Even an offhand comment like “well look at Alice with the quick reply on a Saturday” can slowly lead to an unspoken social expectation that it’s always time to work.

For my team, I’ve always made it clear that I don’t expect anyone to be working outside of our business hours unless they get paged. In order to lead by example, I don’t have my email auto-sync to my phone, and I don’t check Slack when I’m not working. My team knows how to reach me in an emergency and I trust them to judge what an emergency is. Of course, the first week my most recent hire joined, I emphasized this to him and then ended up spending most of the weekend working. It was clearly and exception, but someone new to the company may question if that’s the unwritten reality.

Which brings me to the written reality in some places. A recent opinion piece by Alex St. John said, in effect, game developers should work 80 hour weeks and like it. Tech Twitter and many publications were immediately critical of St. John’s philosophy, but the fact that he could even get such an article published means it’s more of a problem than it should be.

I could never work in the kind of environment St. John advocates. Nor could many others for very long (and this is without considering his views on women in tech). I suspect even Mr. St. John would hate working for himself. I find the “just quit” reply to any complaints about a job to be incredibly myopic. That most people have practical considerations beyond the purity of an artist’s idealized life seems to have escaped him.

As an industry, we should be celebrating the incredible gains in productivity that we help make happen by shortening the work week, not lengthening it.

Managing an IT team when you’re not technical…or even when you are

Posted on by
1

I came across a great article by Alison Green called “5 secrets to managing an IT team when you’re not a technical person“. I don’t disagree with anything she said, but I think she sells it a little bit short. The leadership failures that I’ve seen in my career are rarely because the person wasn’t technical enough. If anything, too-technical leaders are a bigger problem.

I’ve known more than one technical leader who focuses too much on the technology, and not the business case for the technology. When a new shiny object comes along, they chase it, leaving projects core to the business to languish. This not only causes short-term harm, but it can lead to longer-term failures to keep up with changes.

As an industry, we often promote good technical people into management without any consideration of their management abilities. Having worked with a wide variety of managers, I can say that I much prefer the non-technical-but-good-at-management managers to the very-good-technically-but-completely-hopeless-as-managers managers. The best managers I’ve worked for have been both, but that’s not as common as one would hope.

In the meantime, all managers of technical groups should read those five secrets and understand them. The best success occurs when the business and technology are working together.

Book Review: The Open Organization

Posted on by
Reply

Full disclosure: I own a small number of shares in Red Hat.

Three years after Red Hat become the first open source company to reach a billion dollars in annual revenue, CEO Jim Whitehurst published a tell-all book about his company. The Open Organization barely mentions the technology involved in Red Hat’s success, although Whitehurst holds a bachelor’s degree in computer science. The Open Organization, as the title suggests, is about the organizational culture of Red Hat that enables its success.

Whitehurst describes his time at Red Hat as a learning experience that made him a better leader. Previously, he had been the successful Chief Operating Officer at Delta Airlines, guiding that company through bankruptcy and revival in the wake of the September 11 terror attacks. The organizational structure of Delta is described as being “top down”, typical of most large companies.

Such a structure arises from an promotes risk aversion and central control. Red Hat prefers a bottom-up approach where employees are given a wide latitude to make decisions. The role of the CEO becomes motivator and context-setter, while accountability is handled by social pressure.

However, the bottom-up approach cannot be truly described as a democracy, a point that Whitehurst emphasizes repeatedly. Red Hat follows a “the best idea wins, no matter where it comes from” policy, but Whitehurst makes it clear that ideas have to be solicited, too. Employees have different preferences about communication, and they need different ways to provide their ideas.

In describing Red Hat’s culture across seven chapters, Whitehurst doesn’t prescribe the specifics to every other organization. In chapter 7, he acknowledges that Red Hat is still a work in progress. Nonetheless, the broader principles are applicable. Whitehurst cites examples from other companies across a variety of industries to demonstrate that it’s not only software companies that can follow Red Hat’s example.

The Open Organization is a well-written book that turns out to be an easy read. Unlike many management books, it focuses on practical effects instead of theory and provides numerous examples. The content is well laid out, establishing the “why” before moving on to the “what” and finally the “how”.

My main complaint is that Whitehurst does not address the potential criticisms of Red Hat’s method. The blunt and argumentative (although generally collegial) nature will not be appealing to everyone. Furthermore, the way the company aggressively defends its culture (a phenomenon described in several places) prevents whimsical change but it also could discourage appropriate changes from the outside.

Nevertheless, The Open Organization is an excellent book for leaders at any level of an organization. I strongly recommend it as a guide to opening up your own organization. Picking and chose what works for you.

The Open Organization is scheduled to be released on June 2. It is published by Harvard Business Review Press.

How I scheduled a meeting

Posted on by
3

Part of my responsibilities at work include wrangling our platoon of students. With most of them graduating at the end of this semester, I’ve preemptively hired many more to begin absorbing the knowledge necessary to keep a high performance computing shop running. The problem with students, though, is that they have classes to attend, which can make scheduling a bit of a bear. It gets worse as the number of students go up. Right now, I’ve got 14 separate schedules to balance .

I initially had them all register their availability using the free site whenisgood.net, but there were no times that worked for the whole group. Trying to figure out manually a pair of times that would get everyone to at least one meeting was challenging, but then I realized I could script it pretty easily. The hard part was turning each block on the calendar into either a 1 (available) or 0 (not available). Then it was simply a matter of trying every combination and rejecting the ones that don’t get everyone to at least one meeting.

The code below was saved as student_meeting.pl and invoked with a set of nested for loops like so:

for x in `seq 0 79`; do for y in `seq 0 79`; do perl student_meeting.pl $x $y 2>/dev/null; done; done

You may notice that each pair of available meetings would be printed twice. For example, 27 and 71 work, so 71 and 27 work as well and both get printed. The 0-79 represent the 80 half-hour time blocks from 9 AM to 5 PM Monday through Friday. The availability should be encoded similarly for each person inside the script. I include just mine in the example code so that you can see what it looks like. As it currently stands, the code is horrendous and not very robust. If there’s interest, I can clean it up some and put it on github. I’m not really sure if anyone else would care about it, but it might be a useful little project to someone else.

#!/usr/bin/perl

%availabilities = (
 'bcotton' => [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
 1,1,1,1,1,1,0,0,0,1,1,1,1,1,1,0,
 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
 1,1,1,1,1,1,0,0,0,1,0,0,0,0,1,0,
 1,1,1,1,1,1,1,1,1,0,0,1,1,1,1,1],
 # More people would also be here
);

@accounts = keys(%availabilities);

$meeting1 = $ARGV[0];
$meeting2 = $ARGV[1];
$meeting1attendees = '';
$meeting2attendees = '';

foreach $person ( @accounts) {
 $goodtimes = 0;
 if ( $availabilities{$person}[$meeting1] == 1 ) {
 $goodtimes++;
 $meeting1attendees .= " $person";
 }
 if ( $availabilities{$person}[$meeting2] == 1 ) {
 $goodtimes++;
 $meeting2attendees .= " $person";
 }
 unless ( $goodtimes > 0 ) { die; }
 $goodmeetings{$person} = $goodtimes;
}

print "###\nMeeting times $meeting1 $meeting2\n";
print "Meeting 1 $meeting1attendees\nMeeting 2 $meeting2attendees\n";