I love the idea of Laziness, Impatience, and Hubris as virtues of engineers, articulated in “Programming Perl” by Larry Wall. I believe these virtues sustain into leadership, and learning how to channel these traits into advantages is something I encourage all managers to do.
As a manager, when you are dealing with people 1-1 you probably don’t want to be impatient, of course. Impatience can be rude when it is directed at individuals. And you don’t want to seem lazy, there’s nothing worse than working for a manager who seems to be taking it easy while you kill yourself to deliver projects. But impatience, paired with laziness, is wonderful when directed at processes and decisions. Impatience and laziness, applied to process, are the key elements to focus.
As you grow more into leadership positions, people will look to you for behavioral guidance. What you want to teach them is how to focus. To that end, there are two areas I encourage you to practice showing, right now: figuring out what’s important, and going home.
I can’t stand watching people waste their energy approaching problems with brute force and spending time rather than thought, and yet, any culture where you are encouraged to work excessive hours all the time is almost certainly doing just that. What is the value of automation if you don’t use it to make your job easier? We engineers automate so that we can focus on the fun stuff, and the fun stuff is the stuff that uses the most of your brain, and it’s not usually something you can do for hours and hours, day after day.
So be impatient to figure out the nut of what is important. As a leader, any time you see something being done that feels inefficient, start to ask the question, why does this feel inefficient to me? What is the value in the thing we are doing? Can we deliver that value in a way that is faster? Can we strip down this project into something simpler and get it done more quickly?
The problem with this line of questioning is that often when managers ask, can it be done faster, what they explicitly or implicitly want to know is, can the team work harder or longer hours to deliver it in fewer days. This is why I encourage you to develop and show the value of laziness. Because “faster” is not about “same number of hours but fewer total days.” “Faster” is about “the same value to the company in less total time.” If the team works 60 hours in a week to deliver something that otherwise would’ve taken a week and a half, they haven’t worked faster, they’ve just given the company more of their free time.
This is where going home comes in. Go home! And stop emailing people at all hours of the night and all hours of the weekend! Forcing yourself to disengage is essential for your mental health, believe me. Burnout is a real problem in the American workforce these days, and almost everyone I know who has worked sustained excess hours has experienced it to some degree. It’s terrible for individuals, terrible for their families, and terrible for teams. But this isn’t just about preventing your own burnout, it’s about preventing your team’s burnout. When you work later than everyone else, when you send those emails at all hours, even if you don’t expect your team to respond to those emails or work those hours, they see you doing it, and think it’s important. And that overwork makes them less effective, especially at the detailed knowledge work that engineers need to perform.
When you are a newish manager, and you haven’t figured out the tricks to do your job effectively, you might find yourself needing to work more hours to get it all done. That is ok, for a little while. But I encourage you to figure out a way to work those hours without encouraging your team to do so, or making them feel obligated to be on your schedule. Queue up the weekend and overnight emails for the next work day. Put your chat status as “away” in off hours. Take vacation and don’t answer email during that time. And constantly ask yourself the same questions you ask your team: can I do this faster? Do I need to be doing this at all? What is the value that I am providing with this work?
Ooooo, what a compelling way to frame this. I've been the kind of manager who sends his teams home on time for 20 years, but have never been able to articulate why in such a crisp way. Thanks for giving me some very useful language!
ReplyDeleteLove the mention of queuing email if you do find yourself working at odd hours. Helps with situations where I have catching up to do, but don't want to unintentionally create a dialog off-hours......
ReplyDeleteA well written piece. Similar to yourself perhaps, Larry Wall's Virtues inspired me to evaluate what traits I hold in high regards for software engineers to possess. I went for lazy, passionate and empathetic.
ReplyDelete“Beyond Code” @trionkidnapper https://medium.com/@trionkidnapper/virtues-of-a-highly-efficient-software-engineer-9353c940bc83