Hold Engineers Accountable By Giving Them Autonomy
It’s not uncommon for me to have conversations with a tech leader, VP/Director of Engineering in a tech company, that goes like this:
Tech leader: I understand autonomy motivates my engineers. But how about accountability? How do I hold my engineers accountable for what they do?
Me: You hold them accountable by giving them autonomy, by letting them do whatever they want.
For anyone who believes my response is oxymoron, I invite you to think just a little deeper. Autonomy and accountability are like the 2 sides of the same coin. Autonomy is about how decisions are made, and who get to make them. Accountability is about how responsibilities are taken for the consequence, and by whom. They are not mutually exclusive. As a matter of fact, they work best together.
Let’s use a real example. Back in around 2015 when it was still at the early stage of Swift platform, our iOS engineer, who was young, talented, and enthusiastic about any new technology, proposed to convert our Objective-C code base into Swift.
I had my concerns with his proposal. We were still an early stage startup. The priority was to move fast. I was concerned that the risk from adopting an in-mature platform like Swift would outweigh the potential benefits and slow us down. Objective-C was an ugly programming language. But it worked for our iOS app. Most of the issues about Objective-C had been figured out and well-understood.
In our team, autonomy means that engineer has the power to go against the opinions of other team members, in spite the title, rank, and experience level. Accountability means that after he made the decision to convert Objective-C codebase to Swift, he will get the full credit if the projected benefits materialize; or, if things go south as I feared, he will have to clean up the shit and learn from the lesson.
This is exactly what happened. I told that engineer: “Here are all the concerns I have about your proposal. However, if you are still convinced that it’s a good idea to convert our Objective-C to Swift, go for it”.
And he did. So he had his autonomy. Then what did I do to hold him accountable?
In the several weeks after he started on Swift conversion, I kept a close eye on his progress. I gave him feedback such as:
The “doubly wrapped optionals” in Swift has caused quite a few tricky bugs. Do we have a better way to handle this unique feature in Swift?
The subtle differences between
Intin Swift andNSIntegerin Objective-C is driving everyone crazy and hurting our productivity.It’s been 2 weeks since you started on Swift conversion. How much more time do you think will be needed to finish it? Do you still think the reward from that will justify the effort?
Giving this kind of feedback was not without some awkward moments. But throughout the whole time I refrained from saying anything like “now it’s time to stop and go do what I told you to do”. Precisely because I refrained from taking away his autonomy by telling him to stop, he didn’t get defensive. He didn’t feel I was trying to give him a hard time because he didn’t take my suggestion.The dynamic between me and him was more like “I’m your co-worker. I need a solution when your work made me less productive than otherwise”, as opposed to “I’m your boss. You will have to do what I tell you to”. Instead,
It took a few weeks but eventually that engineer realized converting Objective-C to Swift was not as rosy as what Apple had told him, and the benefits hardly justified the cost. So in one retrospective meeting, he announced: “I have decided to pause Swift-conversion project. The classes that have already been converted will stay but I won’t spend more time to convert the rest of the code base. Here is a FAQ page for all the problems you may run into when working with Swift. And I’ll be available for new problems you may run into.”
I know what you would say — “A few weeks of an engineer’s time went down the drain! How can you allow this to happen?”
To that I’d respond: “It’s true that there was a significant amount of waste in engineering effort. However, I believe it was a right decision for a few reasons:
- That engineer learned from it. The whole team learned from it. We emerged feeling confident that it’ll be less likely for us as a team to make similar mistakes.
- That engineer could have been right. I could have been wrong. Although “junior” engineers may be more likely to be wrong, I have seen plenty of cases when “senior” engineers making the wrong calls.
- In a team where a group of engineers with bigger title can outrank other engineers, their decisions usually go unexamined. Time and time again I see senior engineers or architects massively over engineer the design, while the junior engineers who do the coding and suffer the pain don’t have a voice in the decision.
Above all these reasons, the ultimate one why it was the best option was because all other options suck. Let’s examine all other options shall we?
Option #1: No autonomy. Only accountability. In this scenario, I’d have told that engineer to forget about Swift, while still held him accountable for fixing all the problems with our iOS app. The result? Finger pointing, office politics, and demotivated engineers.
Option #2: No autonomy. No accountability. In this case, I’d have told him to forget about Swift, and also turned an blind eye to all problems in our iOS app. This is how most teams in big tech companies work. People only care about getting their ass covered, not their work or the product.
Option #3: No accountability. Only autonomy. I’d have told that engineer to do whatever he likes, and not given him enough feedback no matter how badly the project had gone. When he emerged from the project after 5x longer than projected and the code that’s even uglier than before, I’d have announced to the whole team “huge kudos to XXX for his heroic effort to complete this Swift-conversion project!” The whole team would have left puzzling how this project benefited the team and the company. And that engineer himself never got to learn from it. The result? The team is in chaos with different people going on different direction and doing unrelated projects.
You know what the worst option is? It is the combination of #1 and #3. Engineers with higher ranks and bigger titles get to do whatever they want without being held accountable. Other engineers get all the blames and no power to make any significant decision.
This worst option, sadly enough, is the most common in tech companies.
Other articles in The Soft Side of Software Engineering Series:
