management – rc3.org

Tag: management (page 1 of 3)

Square one for managers

I pulled this from an op-ed by Arthur C. Brooks in the New York Times this weekend:

The Princeton psychologist Daniel Kahneman and his colleagues measured the “negative affect” (bad moods) that ordinary daily activities and interactions kick up. They found that the No. 1 unhappiness-provoking event in a typical day is spending time with one’s boss (which, as a boss, made me unhappy to learn).

This is simply the nature of the relationship. As a manager, this is the ground on which your relationship starts, and it’s up to you to build something better.

I really enjoyed Camille Fournier’s post about the implications of exercising authority as a manager. In short, being told you screwed up by somebody who can fire you can lead to pretty serious anxiety. She nails it when she says this about her role has the head of engineering:

In fact, it is important that I’m seen as an inspirational figure to my team, someone they look up to and look forward to interacting with, and not vice-versa.

Her post also reminded me of a powerful lesson in management I learned awhile back. I heard a story about why a developer really didn’t like our head of engineering. One time, the executive was approving expense reports, noticed an odd $30 line item on this person’s expense report, and rejected it asking for an explanation. The oddness was easy to explain, and the expense report was ultimately approved, but the fact that the executive had rejected the report rather than giving this person the benefit of the doubt permanently set in their mind that the executive was a jerk.

I took a few things away from this incident. First, you can run into problems doing the right thing. The executive was being a good steward of the company’s money, and questioning the expense wasn’t wrong. Perception was the problem, as it so often is. Secondly, this person had very few interactions with the executive, and so there was no established expectation of trust that may have made this OK. If I’m only going to talk to someone a few times a year at most, I don’t want one of those interactions to be negative, especially with so little at stake.

The third was that people should be mindful of what’s expected of people with their job. Had the executive in question forwarded the expense report to accounting and had them send it back, feelings would not have been hurt. People expect accounting to carefully review expense reports. When an executive does it, it can seem petty or vindictive.

This is one of the toughest aspects of a manager’s job. You have limited chances to communicate with people, and what matters most is the outcome of those communications. Everything you do when managing people ideally helps to do their best work, whether it’s getting them the right keyboard, insuring that they’re fairly compensated, or giving them advice on how to get unblocked when they’re trying to solve a tough technical problem.

If it seems like I’m saying that as a manager, it’s important to be almost painfully deliberate in how you approach communicating, I am.

The dangers of over-reliance on perks

June 11, 2014 / Rafe / 0 Comments

My colleague Melissa Santos and I wrote a piece for Model View Culture about perks and how they can be divisive, in spite of the best intentions of the people offering them. The article really cautions companies about building their culture or even their recruiting pitch around perks, it’s a dangerous shortcut to take.

Melissa has a blog, Allowed to Apply, which encourages people to just apply for things that interest them. It’s a great message. She’s @ansate on Twitter.

How to hire a superhero

January 5, 2014 / Rafe / 0 Comments

University of Rochester computer science professor Philip Guo has written a great post, shining a light on the bias in the computer industry in favor of people who look like him (or me). In it, he explains how he has gotten the benefit of the doubt in situations simply because he looks like what people expect a computer programmer to look like. It’s a first-hand account of what John Scalzi talked about when he wrote about straight white males playing the game of life on easy mode.

Here’s a bit from the post, Silent Technical Privilege:

… people who look like me can just kinda do programming for work if we want, or not do it, or switch into it later, or out of it again, or work quietly, or nerd-rant on how Ruby sucks or rocks or whatever, or name-drop monads. And nobody will make remarks about our appearance, about whether we’re truly dedicated hackers, or how our behavior might reflect badly on “our kind” of people. That’s silent technical privilege.

He contrasts that with the challenges placed before people who are outside the demographic sweet spot that so many people associate with being a computer programmer. As he says, you don’t have to be a superhero to succeed in software development, and we shouldn’t demand that people who don’t enjoy these privileges be superheros to make it in this business.

This leads me to the theory that if you want to hire superheros, you should ditch your biases and expand your hiring pool. The people who have persisted and succeeded in this industry in the face of the inequeties that Philip documents are much likelier to be superheros than your run of the mill bro who shows up to the inteview in his GitHub T-shirt with a cool story about making money in high school by creating Web sites for local businesses. There are plenty of superheros that fall into the privileged category, but they already have good jobs because they will never, ever be overlooked in the hiring process. The awesome programmer who also seems like they’d be super fun to have around the office? They get a job offer every single time.

The enterprising hiring manager has to think outside the box a bit. You know the feeling. The person seems like they’d be great at the job, but is different enough from everyone else that you wonder a bit how hiring them would affect team chemistry. I’m not talking about personality here, but demographics. (I’d never recommend that a non-competitor hire brilliant jerks.) The hypothetical candidate I’m talking about here has to deal with these unspoken questions every single time they apply for a job. That’s not fair, and it’s incumbent on our industry to change, but in the meantime, it’s possible to exploit these widespread biases to hire the superheros that most companies won’t even consider. At least that’s the theory.

Management, the hard parts

January 1, 2014 / Rafe / 0 Comments

Camille Fournier: 2013: The Constant Introspection of Management

Nice post on the hard parts of being a manager. One thing I’d add is that as a manager, the mistakes you make all too often have an impact on real people, an impact that’s impossible to undo. If you put someone on the wrong project and they spend six months not really learning anything, that’s six months they can never have back. It’s a tough job.

Some thoughts on delegating

December 31, 2013 / Rafe / 0 Comments

John D. Cook has a post on one of my favorite management topics, when to delegate.

My thoughts on delegation are probably fairly radical. The first principle is that if a project strikes me as interesting to work on, I must delegate it immediately. Managers almost never have the bandwidth to tackle interesting technical problems, it’s the nature of the beast. When I delegate projects, I can remain engaged to a degree that allows me to learn and to hopefully add some value, without stalling progress because I’m too busy dealing with the other million distractions that are part of manager life. I tend to stick with working on the tasks that are too boring or repetitive to bother delegating to other people – they’re generally about the right size to get out of the way when I’m between other things.

The second principle is, delegate everything, especially if you’re in a new role. When you take on a new role, there is no way to estimate how much work is going to be coming your way, or to list what all the demands on your time will be. All of the stuff you were doing is either going to keep you from succeeding in your new role, or just isn’t going to get done, unless you can delegate it to someone else. Of course, in reality you’ll never be able to delegate everything, but proceeding as though you can will hopefully keep you mindful of the fact that you should always be looking for opportunities to delegate.

The point I’m really getting at is that most people are far too reluctant to delegate, and far too selfish when it comes to delegating. Usually when you’re in a position to delegate, you are also at least partially responsible for the professional well-being of the people you’re delegating things to. The things you delegate should hurt a little to give away.

Marc Hedlund on what managers produce

August 25, 2013 / Rafe / 0 Comments

What do you make as a manager?

Marc Hedlund on the less immediately tangible but in many ways more rewarding products of being a manager. The difference between good jobs and bad jobs is the manager you report to, a lot of the time. Most people spend more time at work on any other single thing. As a manager, your responsibility is to make that time more fulfilling, enjoyable, and productive. I find it’s a good gig.

How management and teaching are alike

June 11, 2013 / Rafe / 1 Comment

Ta-Nehisi Coates writes about his experience of teaching a writing class at MIT this semester. Here he is talking about motivating students:

I didn’t have to work hard to motivate people. What I found was that if I showed up, and I was excited, they fed off of that, and they got excited. I came to feel that teaching was performance. My job was to communicate my own energy and belief in the importance of the work.

As a manager, this is what I try to bring to my work. Hopefully I’m successful.

I’m going to write more about this some other time, but one thing I’ve come to realize is that there’s nothing I appreciate more than a committed performance. Whether it’s from a singer, an actor, a teacher, or a colleague. Commitment makes up for almost any other deficiency.

Your dogma is already obsolete

February 1, 2013 / Rafe / 1 Comment

Last week’s New York Times included a book review of defense reporter Fred Kaplan’s book “The Insurgents,” which covers General David Petraeus, counterinsurgency doctrine, and the wars in Iraq and Afghanistan. It explains well how falling in love with your ideas can get in the way of success.

Kaplan writes about how proponents of counterinsurgency doctrine in the military worked the media, defense scholars, and the defense establishment to replace the existing Cold War doctrine with their own ideas. Here’s how the reviewer, Thanassis Cambanis, describes their better days:

President Bush had promoted the COINdinistas because they were flexible, pragmatic problem solvers and because he had a nagging problem on his hands: how to get out of Iraq without looking defeated. Counterinsurgency was just one part of the fortuitous mix that yielded a just-good-enough resolution for Iraq. Petraeus and the officers and experts had been right about how to fight in Iraq and reached plum positions in the Pentagon.

And here’s the conclusion:

The COIN brigade forced the Army to adapt, to become what one officer called “a learning organization,” but the Pentagon failed to grasp the most important lesson of the decade: that the military does best when it can learn new types of missions quickly, whether delivering aid after a tsunami, stabilizing a failed state or running covert missions against international terrorist rings. Instead, it exchanged an old dogma for a new one. Once persuaded that the military could do counterinsurgency, few in Washington stopped to think about when it should do it.

This story reminded me a lot of the tech industry. Last year, GitHub’s Ryan Tomayko wrote a “here’s what works for me” blog post about his management style, which was fantastic. Here’s the crux of it:

It’s often cited that GitHub doesn’t have managers. In my opinion, a better way to describe the phenomenon would be to say that everyone at GitHub is a manager. Instead of assigning 100% management duties to individuals, the basic role of management is spread between 1.) every single employee, and 2.) a set of custom in-house tools that serve to keep everyone in the know with regards to other projects.

I think this is a pretty brilliant philosophy, and my impression is that it works very well for them. That article changed the way I think about my work as a manager.

This weekend I listened to a presentation from a developer at GitHub about their “no managers” corporate structure. This presentation essentially argued that the GitHub approach is indisputably the best way to run a company, and that all other corporate structures are broken.

This is exactly the trap that the military officers Fred Kaplan wrote about fell into. It’s a form of lazy thinking. Every problem and situation is unique. Nearly all people are naturally inclined to cling to heuristics rather than thinking deeply about problems and adapting to solve them.

This is one of the great penalties of success. People try something, meet with success, and then attempt to apply that formula over and over again, failing to recognize that new problems require new solutions. Often the real reasons for success go completely unexamined, because people are so eager to embrace it as proof of their own brilliance.

To the proponents of counterinsurgency doctrine, every war looks like an opportunity to apply counterinsurgency doctrine. To the GitHubber, every corporation should work like GitHub.

When people propose that all problems look the same, or even worse, that problems look different but that old solutions are still ideal, it’s a strong sign that they’re operating from within their dogma rather than starting with the problem and working their way out. There’s nothing that invites disaster more than falling in love with your own good ideas.

What does it mean to be a senior engineer?

October 25, 2012 / Rafe / 0 Comments

You should read John Alspaw’s essay, On Being A Senior Engineer, even if you don’t aspire to be a senior engineer. Maybe you already think of yourself as a senior engineer. Maybe you work in some completely unrelated field. What it’s really about is becoming a mature professional and not only mastering the skills of your field but passing them on to other colleagues in useful ways as well.

I recently read a post about the value provided by managers. I was not surprised to read that managers do add value, but I was a bit surprised at the means by which that value is added. I would have assumed that it was by keeping people happier, removing distractions that sap productivity, or helping to prioritize work. As it turns out, the actual value is in teaching people how to do their jobs better.

So as a manager, the best way to add value is to help people along their path to becoming senior engineers (if the people who report to you are engineers). As an engineer, you should be looking for opportunities to work for a manager who can teach you to be a better engineer. And perhaps most importantly, you don’t have to be a manager to help other people get better at their jobs, so you should helping other people get better as a key aspect of you’re job. This is one of the key points of John’s essay.

Anyway, you should be reading his post and not mine. It’s a road map to making the most of the incredible opportunity we have to work as engineers.

rc3.org

Strong opinions, weakly held