Years ago, during one of my first big presentations to execs, my director interrupted my presentation multiple times, and eventually just took over the presentation entirely, grabbing my laptop in front of a room of 20 people.
We’d spent multiple hours preparing for this presentation and I’d flown to SF from NYC to give it. Others who were there confirmed my presentation was going fine and was what we’d prepared. The boss just called an audible and decided the team should speak with one voice—his.
Prior to this, the same director had also made a bunch of edits to my deck without talking to anyone. But I didn’t say anything. At this point, we all knew better than to try to argue that he shouldn’t do that, so we tried to negotiate toward a version of the deck we were all happy with.
After the incident at the meeting there wasn’t any follow up. My manager didn’t want to get into it with the director, and I wasn’t comfortable raising it w/ the director or his manager (our VP) if I didn’t at least have my manager’s backing. So I dropped it. My new job search started that week.
Autonomy, Mastery, Purpose
It’s about to be performance review season at certain very large companies, and so there’s a bit of conversation on Twitter about whether performance reviews “work” or not, and in general what behaviors from managers and leaders actually help folks learn and grow in their careers.
This thread by Bryan Cantrill is very good and on point:
An an engineer in a large corporate environment, I had found that performance management never actually improved my own performance.
The things that resulted in my own high performance were the basics: being motivated by the problem; being drawn to the mission; being a part of an incredible team.
Daniel Pink summarizes these motivators concisely: people are motivated by autonomy, mastery, and purpose.
The role of management is in constructing that environment, not micromanaging it. If engineering performance is suffering, it’s (likely) a management problem: wrong problem, wrong mission, or wrong team — or all three.
This other blog post by Dan Abramov is about programming, but is true for all kinds of work:
If someone tells us that abstraction is a virtue, we’ll eat it. And we’ll start judging other people for not worshipping “cleanliness”.
I see now that my “refactoring” was a disaster in two ways:
Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together.
Secondly, nothing is free. My code traded the ability to change requirements for reduced duplication, and it was not a good trade. For example, we later needed many special cases and behaviors for different handles on different shapes. My abstraction would have to become several times more convoluted to afford that, whereas with the original “messy” version such changes stayed easy as cake.
The director who grabbed my laptop prioritized the work product over the health of the team, in the short term by damaging our working relationship, and long term by signaling that individuals’ hard work and opportunities are unimportant.
Trust and communication are so much more important than optimizing the work product, and redoing someone else’s work for them, not with them, robs both of you of a learning opportunity.
You can always optimize/fix work product. If someone on your team thinks you don’t see them, that breakage is far more damaging and harder to fix.
Regardless of where you are in an org chart, your org is made of people. It’s a society. It may seem like the work is more important than people, and anything you do to improve the work is justified.
But in my opinion that’s totally wrong. The work is a side effect of bringing together a team.
Some of the world’s great businesses were built by great teams writing shitty code that worked. Instagram’s first logo was the word “Instagram” set in a free font. Most business PowerPoints are horrifying. Facebook and Slack use PHP for heavens sake. A great team with great working relationships and a willingness to ship, learn, and adapt can achieve almost anything, no matter how ugly any given thing they ship may be.
But a team that can’t hold onto people — because a director steps on people in meetings, or the CEO is abusive on Slack, or because there’s nonstop crunch with no recognition or reward — is not going to succeed in the long run.