Software engineering is creative work, it’s disciplined work, and it’s sacrificial work. Your commitment to your work is reflected in the quality of your product. There are endless corners that can be cut, objections that you can choose not to raise, and subtle bugs that you can ignore. You are most likely to build a quality product when you care about that product. When you’ve “bought in”. When you feel a sense of ownership.
As an engineering manager one of my goals is to develop a sense of ownership within my team. This hard to do, but the more successful I am - the more successful my team and my products are.
Hopefully you’re not starting from scratch. Anyone on your team knows why they came to work for the company. There’s something there that they’re interested in. Salaries, benefits, location, etc. all factor in, but are often more or less equivalent. There was something else that led you to your current company, assume that’s true for your team as well. As a manager it’s your job to know what that motivator is. It will help you do your most important job:
That’s your job.[1]
Everything else is secondary.
No amount of technical or architectural wizardry from you will make up for failing to attract and retain talent. You cannot build your way around it and you cannot market your way around it. If your company needs a manager your company needs a team. If they don’t need a team they don’t need a manager. Someday I’ll write a post just on this. But for now; I hope you’ll just believe me.
Back to ownership.
Having a sense of ownership over a product means caring about more than just the code you wrote and the decisions you made and are responsible for. It means caring about the product’s success. Caring about what other people think about it. An engineer that feels a sense of ownership over a product will talk it up in the elevator.
You need to know what brought your team to your company, and you need to be able to build clear connections in their mind between why they’re here and what they’re doing. If they are just there for a paycheck any company in your area can offer them that. In fact odds are they’ll get a raise. But those companies aren’t building your products.
To the extent those bridges already exist - that’s your baseline. Now let’s talk about how cultivate a sense of ownership.
“The first rule of improve is agree.” - Tina Fey [2]
If someone on your team comes up with an idea, a feature, or a direction for a product it’s vital that you look for ways to embrace it. This doesn’t mean that anything goes. This means that you need to either buy into that idea yourself, or work with the person to develop the idea into something you can buy into. Failing to embrace and develop ideas will train your team not to bring them to the table. The end result of this is that your team will act like code monkeys and the quality of your product will reflect that it was written by monkeys.
Engage. This one is straightforward. Bring your team into all aspects of the product they are working on. They should have a voice in how it is marketed, how it’s monetized, how it’s monitored, how it’s branded - everything that they have strong opinion on or interest in - not just how it’s built. They won’t (and shouldn’t) get to make every decision, but they should feel like their voice is being heard and their opinions taken seriously. You team should feel that they fully understand their product. If they don’t they should asking questions and you should be helping them find answers. At the end of the day, nothing gets into your project’s repo that an engineer didn’t put there. You never want to be in the situation of making a team member do something they don’t believe in. Spend the extra time and effort to get their buy in - to help them feel like the product is theirs.
The bad news is, odds are everyone on your team has already been trained to act like a code monkey in a previous role. This is to be expected. If you’re coming from a school background you were graded on your ability to deliver specific, conforming results. This is perfectly reasonable, it would be hard to give objective grades if everyone got to be their own snowflakes all the time, and there are lots of fundamental things that you just have to learn at some point. If they’re coming from a previous job they might have been new in the industry when they got there and got accustomed to following the direction of more senior engineers. Even if they weren’t new to the industry, starting a new job can be daunting for any of us and code monkey habits are easy to slip into.
I should also acknowledge that managers (any variety: engineering, project, product, etc.) are likely to be in that role in part because their instincts are to command and decide. This is a valuable skill too, but if miss aimed it can break down a team member’s sense of ownership in a hurry.
As a manager your job is to encourage ownership. To actively break your team out of code monkey habits. Ask for their opinions, expect them to speak up, don’t accept silence as agreement. When they do bring something to the table make a point of taking their side - defend their idea. If you don’t agree with it work to develop it, and if at all possible avoid telling them no in front of others. You want your team to feel like you’ve got their back and that they can bring ideas to the table and have them earnestly heard out and not shot down out of hand. Even if they later realize those were bad ideas the fact that you listened means they’ll be comfortable sharing when the inevitable good one comes.
When working with a more experienced engineer this can also mean doing something incredibly difficult - letting them take a shot.
What I mean by that is - letting them do something that you’re not convinced is the right thing to do, letting them take a risk. This is tough to do. You’ll be annoyed when it fails for exactly the reasons you thought it would, and frankly you’ll be annoyed when it works and you have to admit to yourself that you were wrong.
But here’s why you need to do this:
First, because this is how your engineers (especially the more senior ones that already know the basics) can learn, and learning is a big part of what retains their talent. They need to be able implement their ideas and see them play out. This is how you learned. Remember that terrible decision you made? I bet you never did that again! I bet you learned a lot from fixing it. (I did.) Remember that time you had an outside the box solution that you really believed in and were excited about and you brought it to your boss and they let you do it and it worked? I’ll bet you do. Remember that time you had one of those solutions and you brought it to your boss and they shut you down? I bet you don’t work there anymore.
Second, being trusted to make a big decision about a product gives you a sense of ownership in it. When that decision pays off it builds your pride in that product. You can look at it and say “I built that.” You feel responsibility for that product because you created that product - it is how it is because of you. Even if your decision breaks it you’ll still feel that ownership because you broke it. While a team absolutely does succeed and fail together, the experience you have when you’ve negatively impacted a product bonds you to it, makes you respect it, and makes you take it seriously. You’ll become the advocate to prevent that mistake in the future because you know how bad it was to go through.
Third, and this takes some getting used to, but if you’ve been programming for awhile you’ll know it’s true: projects get abandoned all the time. The market changes, the funding changes, the priorities change, the customer changes - Dewey Defeats Truman, Truman Defeats Dewey. You can spend a lot of time fighting over a decision, or trying to make the perfect decision, and it will turn out to be entirely wasted time because that monolith that absolutely should be micro-services FIGHT ME or vice versa got shut down last week. If you don’t let your engineers take shots, and then this sort of thing happens, you’ll have burned up moral and prohibited ownership for nothing.
Fourth, there’s a very high chance that your team is right! If you did the other parts of your job well these are people who know what they’re doing. As fun as it is to be right yourself, it’s even more fun to let someone else make a decision and for them to be right, and you to be right by extension! While you’ll be annoyed that you were wrong if you thought it wasn’t going to work, you’ll soon get over it while you’re reaping the benefits of giving someone else the space to be right. If you don’t give your team the opportunity to take shots your product will never get the benefits that come when those shots succeed.
A final note on this:
If the shot misses. If things go wrong, never put the blame on the team member. The reality is the team succeeds and fails together and part of success is growing from failure. Two steps forward one step back will get you where you need to go. No steps forward won’t. You can have a conversation with the team, and you can do a blameless postmortem, and work together to figure out what went wrong. You can’t blame a team member for a failure.
If forces outside your team want someone to blame (and they very well might) make sure it’s you. It won’t be fun, but it’s worth it. Protecting your team from the fall out of a mistake may cost you some reputation, but you’ll gain it back and then some with the accomplishments your team will be able to deliver if you give them the cover they need to succeed. Besides, if your boss is a good at their job as you’re being at yours they’ll give you some cover because they’re working on the exact same principles.
Even if you’re doing everything right to build a sense of ownership throughout your team there’s another challenge you’ll have to address. Other people. (Cue cheesy horror scream.)
For a sufficiently large operation you’ve probably got Project Managers, Product Owners, Designers, Business Analysts, QAs, and who knows who else who will all try to tell your team what to do. Even if you’re not training code monkeys someone else could be. You need to guard against that.
However, you shouldn’t belittle or dismiss these other team members in the process. Here’s how you can strike the right balance - teach your team that:
Your engineers, your team, reports to you. You are the one responsible for evaluating their performance. No one likes feeling like they’re getting pulled in multiple directions. Make it clear that they don’t answer to anyone outside of their actual chain of command.
Contextualize the other members of the team. All those other people pulling your developers in different directions are expert advisors, trusted consultants. They are providing immense value. Their suggestions and opinions should not be ignored, but they also shouldn’t be blindly followed. If an engineer does something because the designer made a picture and that’s how the picture looks they feel like a code monkey. If an engineer does something because they evaluated the design and liked it - they feel like they own their work. If they didn’t like the design, but brought their concern to the designer and the designer was able to show them why the picture is correct - they feel like they own their work. If at the end of a debate they can’t agree your engineer needs to know that the ball is in their court. They can go with someone else’s recommendation or they can take a shot (see above). Either way what’s important is that they make the choice - that they own the choice.
“I want you to feel a sense of ownership over the products you work on.”
I tell my team that as often as I can. More importantly I try to model it and prove it in my actions.
I encourage you to do the same. Your product will be better for it.