What I Value in Software Engineering Management
Back in December 2016, my manager and I were talking about my philosophy of software development. I'd become a Director of Mobile Engineering in March 2015, but I didn't become a manager of managers until I finally filled the Android Manager position on my team in October 2015—and even then I was still directly managing the iOS team. It wasn't until the fall of 2016 that I stopped managing any of the individual developers directly. Welcome to a new challenge!
Just as moving from an individual contributor role to a management role can be an adjustment, so can moving up the management chain. I don't claim to be particularly great at it and am still learning as much in my "new" role as the people under me are learning in theirs, so I'm not going to offer any advice just now. I do, however, have some thoughts on what I value in a good software engineering manager—a role I did well in, and thoroughly enjoyed.
Which brings me back to that conversation with my manager in December 2016. He suggested I take some time to write down my software development philosophy: to articulate the standard that I was holding my direct reports (and myself) to. My thoughts probably aren't unique—I owe both a conscious and an unconscious debt to the awesome leaders I worked with at Macromedia and Adobe, including, but not limited to Karen Olsen-Dunn, Jay London, and Paul Madar—but they are pretty stable. While I started by opening Notes on my Mac, changing the font to something goofy in order to shift my perspective a bit (it worked!), and launching into a stream-of-consciousness bullet list, there's not much I've twiddled over the past 8 months (and I return to the list often, just to check). Even the headings have stayed the same as in the original draft.
Anyway, for the record—and for any value that anyone else building customer-facing software, especially for a large audience, might find in it—here's the list that I headed What I Value.
Execution
- Work on the right things at the right time. (See also: Active Participation, Alignment, and Alternatives.)
- Come up with multiple ways to get where you want to go. Develop a Plan A, a Plan B, and a Plan C.
- Measure as you go: Know if you're on track or not. Don't engage in magical thinking; tell the truth to yourself so you can tell it to others. (What's going well? What's taking longer than anticipated? Does anyone need help, whether they've asked for it or not? What is the find rate? What is the fix rate? What is the severity/priority trend of the bugs being found? Are you winding down or still cranking out?)
- Adapt to reality. If things don't go according to plan, what can you do instead? (The answer isn't always just less.)
- Know your product. Use it daily if possible.
- If you're unsure about an investment, what is the smallest thing you could build to be more sure? Build it.
Active Participation
- There are the things you'll be asked to do, and the things you know you should do. Speak up and provide context. Will doing that feature now add technical debt? Say so. Is there something else we could do instead? (See: Alternatives.) Could more be gained by investing in a foundational technology that would allow for more—and more stable—features 4-6 weeks from now?
- Features don't just happen to you; give feedback about how they should fit on your platform.
- Ask: Why is this important? What problem are we trying to solve? Is there room to experiment with more than one solution? Is the goal to meet a minimum standard or to delight? Is it possible to do both?
- Read existing documentation and expand on it if you have more information.
- Advise on the API. Does it have what you need? Is it faster/more robust/more adaptable to do something on the client than via the API, or vice versa?
- Contribute implementation details—before you implement, if possible! Discuss your plan with developers and testers across platforms.
- Update documentation to match what was actually implemented.
Alignment
- Know what your immediate supervisor, your wider team, and your company values. Align your work with those values.
- If you see value that others don't, point it out. If they still don't see it, and you still want to pursue it, be prepared for it not to be appreciated. (It might be, but you can't count on it—so it should not supplant any work that is guaranteed to be valued.)
- Ask yourself: Am I helping the members of my team build a portfolio that's valuable both inside and outside the company, or only one or the other? How can I make the work of my team more visible? What opportunities can I provide them to demonstrate their knowledge inside our organization? To represent their team?
- How do you make what you/your developers care about what the team cares about, too?
Alternatives
- If you don't like what you're being asked to do, suggest an alternative.
- If you don't understand what you're being asked to do, ask questions. "Did you mean X or Y or something else?"
- Don't just ask for permission to deliver less/to extend a timeline: Sell it. "Here's where we're at, and here's what I think makes sense to do."