I suspect the tone here — largely laudatory, abd looking up to people like Peter Thiel and Paul Graham — will rub most of my readers the wrong way.
Look past that, and pay attention to the notes on what makes Palentir work. I completely agree with a lot of the conclusions about how important being embedded with real customers is. It happens also to be the model that I saw working at 18F and USDS!
We promote people into management and we just hope that they figure it out. And then we stand, mouth agape, when things go sideways. And this isn’t just a problem for our new managers. We are 40 years into this strategy and now the overwhelming majority of the workforce came up through this same form of occupational hazing. Here’s a new job. It’s very high stakes. It’s totally different from what you’ve done to date. And the skill set isn’t intuitive at all. You’re smart. You’ll figure it out. And if not, you’re fired. Good luck.
An alternate pattern to architecture teams for determining technical direction.
“So remember, much like many other management problems, trying to be “nice” where you should be clear is one of the worst things you can do. “
So this came up in a slack and then i had a long expansion and someone asked me to make it a post so they could link it to people and well ok fair enough
It’s gonna be heck…
Great (as usual from Will) roundup of the kinds of meetings effectve eng orgs have.
My only addition: I find demo days (mentioned breifly) quite useful; they seem to really drive a culture of shipping.
I’ve gone through this myself – unsuccessfully – and wish I’d had this guide. Great information about a confusing and opaque process.
For the past several years, I’ve run a learning circle with engineering executives. The most frequent topic that comes up is career management–what should I do next? The second most frequent topic is measuring engineering teams and organizations–my CEO has asked me to report monthly engineering metrics, what should I actually include in the report? Any discussion about measuring engineering organizations quickly unearths strong opinions. Anything but sprint points! Just use SPACE!
My favorite planning exercise
How to plan? How hard could it be? 4k words scribbled down on a sunny October afternoon for people in tech observing the Season’s Traditional Annual Planning Process, inspired by a recent interview question (and 25 years of variously painful planning processes).
Really fantastic crash course in pay systems.
My latest in Quartz… My partner and I had a hellish move recently. We were lucky in that our landlords are nice, reasonable people, and unlucky in that they were quite disorganized and hadn’t done …
“your job is not to manage people but to manage processes and lead people”
“This is the part where I say something about how more diverse teams build better products, and how diversity of backgrounds, identities, and opinions leads to better decisions. That is all true. However, in this organization we value diversity and inclusivity because that is the morally and ethically correct thing to do. That it benefits us, our customers, and the company is nice. We will do it regardless of how true that is. If inclusivity fails to benefit us, our customers, or the company, we will seek to realign that conflict rather than cease being inclusive.” (The whole thing is this good.)
Great Twitter thread with some hard truths about “we need to hire more engineers”
Last time I was looking for a job, I wrote up a list of questions I wanted to ask prospective employees. I just ran across the list again, and figured I’d share. I was looking for a senior management role (Director/VP-level) in Engineering or Security, so the questions are sloped in that direction.
Also note that I was in a fairly strong position; I didn’t need the a job immediately. So, I was able to ask fairly direct, challenging questions. You may have a lower risk tolerance and want to scale some of these back.
Craig recently wrote about his mixed opinions about OKRs. The crux of his argument, I think, is that communicating goals is the important thing, and that OKRs are a heavyweight tool (with limited success).
I agree, somewhat; this post is a “yes, and”:
OKRs (when done well) do one other important thing: force explicit conversations about performance. Talking about goals can be fairly easy compared to talking about performance. But talking about performance is a basic management responsibility, and unfortunately it’s frequently done poorly (if at all). This can leave staff and management with wildly different views on what “good” looks like, which can cause all sorts of problems. Even if you’re totally aligned on goals, if your team doesn’t understand what good performance is, you might never hit those goals. As a manager, you have to talk about performance. Any tool you use is fine. OKRs, like Craig says, are heavyweight. But heck, if that’s what you need to force a conversation about performance, then fine.
When I interview, I say nearly the same thing at the beginning of the interview. It’s a script I’ve practiced and honed over the years . It’s only eleven sentences, but each has a specific purposes. I’ve iterated on this for years, and it’s pretty tightly honed at this point. I published this script in the guide to interviewing I wrote at 18F last year, but never got a chance to break down where it comes from
Like many engineers, I got thrown into management without any real guidance. I thought management was just telling people what to do. I thought there wasn’t any real science to it; you just needed to feel your way through it. I was wrong: there’s a whole field of study here, and you can learn a lot by, you know, studying!
This is the reading list I wish I’d been given as a new engineering manager. It’s organized roughly in the order that I’d want to have read them. If you’re a new engineering manager: I hope this list helps you succeed.