Joe sat down to interview Michael Lopp, Head of Engineering at Pinterest. Many of you probably know him online as Rands. You can listen to the whole interview at the bottom of this post.
Michael’s blog, randsinrepose.com, delves into the human side of building software. In this interview, Michael and Joe offer their advice on building teams, and leading developers. Their discussion will be especially helpful if you’re a new manager. Let’s get into it!
Joining a new team
Joe: When you come into a new team as a manager, what are you looking for?
Michael: You want to ask: “What is the culture?” “What are their values and principles?” “How are they making decisions?” This is a hard task. You have to talk to a lot of people to figure it out.
Joe: What are some green flags and red flags for teams that you’ve seen?
Michael: That’s a really good question. The green flags are:
- Do they believe that they’re being efficient? Do I have clarity about what I’m doing and what everyone else is doing?
- If managers exist, how are they viewed? (That could be a red flag as well)
- Is there technical leadership? Are there technical visionaries that are respected?
The red flags are:
- Politics (the bad kind).
- Communication issues: talking to two people about an issue and getting two different responses.
- When people don’t understand the vision.
Joe: What the rest of the organization really wants is consistency and clarity. The VP of Engineering at Urban Airship would always tell the business side, “Everything always takes 60 days.” He had a high confidence that most tasks take 60 days. There is often a communication breakdown between business and developers. The business is always asking, “When is this going to be done?” and developers have a very different definition of what “done” means.
Improving communication on a team
Michael: There’s always people that can sit on the fence and speak both languages (business and development) very well. You gotta have those intermediaries, those connective tissue people.
There also needs to be an education. Saying things like, “This is why this is hard (from the development perspective),” and “This is why this is important (from a business perspective).” We, as human beings at a distance, tend to simplify: “Marketing! Oh that’s story telling. Design! Oh, that’s graphics on shirts.” But they’re wrong. Those things require a deep knowledge.
Joe: I’d do this at Digg all the time. I’d have a brown bag lunch, and bring the business people in, and explain how Digg worked at a technical level. Things like, “This is what memcache is.” Business people would hear these things at meetings. One thing that frustrates me about working with developers is they’ll use information disparity to their advantage: “I know you don’t know what memcache means, so I’m going to say something highly technical, when in reality I don’t want to do that feature.”
Michael: There’s also these business types who know a couple technical words and throw them down all the time. They sound like they know what they’re talking about, but they don’t really have a deep understanding. These people need the education piece.
Should managers code?
Michael: Someone at Pinterest just asked me this question. Should leaders be coding? I’ve gone back and forth on it. I think when you still invest in the code, it keeps you grounded. The moment you stop, you lose touch with some of the reality. I think it keeps the organization flatter when the leadership team is still coding. I know what it’s like to be lost in an algorithm for an hour and feel like I’m not moving forward.
On becoming a leader
Joe: What are some things that surprised you when you transitioned into becoming a leader?
Michael: I’m working on this right now, for a talk. It has to do with the most common thing a new leader says:
I don’t know what I do all day. I used to be coding, and it was all very measurable.
The question is, “What are they doing all day?” Obviously, they’re going to meetings, on the phone, dealing with people stuff. But there’s this intangible work of leadership. The stuff that’s really hard to measure. I just did a piece on this called Chaotic Beautiful Snowflakes. There is all this overhead of people working together that we need these leader times to optimize. You have to invest in this! For example, I believe in doing one-on-ones, every week, at least 30 minutes, no matter what.
Joe: As an engineer that moved from really techie back-end stuff, into more management, product and people stuff, this was a bitter pill to swallow: people don’t care. They don’t care at all about the code, what it’s written in, what platform it’s built on. They do . . . not . . . care. That can be really a sad realization for an engineer writing beautiful code.
Michael: However, the consumer does care about the implications of the platform and technology. For example, “Do you like your pages to load fast?” We both know that there’s a huge amount of technology behind the scenes to make that load time work. The question is, how can you map into their reality?
Three recommended resources for leaders
Joe: What are 3 areas of knowledge managers should be reading up on?
Michael: These are things I’m currently passionate about:
-
Myers-Briggs might be hokum, but it’s really useful for understanding different personalities that are out there. The point is to understand the different types of human beings that are out there.
-
Status: you need to understand, when you’re coming in as a leader, how people are going to view you. There’s a book called Impro that describes this.
-
There’s this game called Werewolf. I wrote about it on A List Apart. The game is about learning how people lie. (Newsflash: people lie.) You need to understand how people work, and Werewolf helps with this.
