Engineering Teams and Code Ownership: Take a Step Back and Think About the Big Picture

Neil Mitchell

Head of Platform Engineering at Valley National Bank



We reexamined the overall principles of how team members interpret what they need to do around the code. It's great having tools like full regression tests and code reviews, but how do you make sure everyone understands what is good code and what's good code for our company specifically? Typically, engineers have a tendency to do their coding, then throw things over the fence to QA, who then pass it off to Ops. Then it gets passed back again if there is a bug or deployment issue... and the cycle repeats.

Actions taken

We decided to create a set of engineering principles so everyone has a consistent frame of reference i.e. people understand my point of view as the engineering director, the views of QA, Product and Operations teams. It was less about company culture although very important but more about the context of doing things to ensure other team members, departments and partners were happy. In creating these principles, we researched what other engineering teams around the world were doing, and we came up with 10 that worked for us. Then we took it to the team, who are a mix of A-players and juniors. We got the team to buy into the principles by explaining that we all want to be treated with respect and do our best work efficiently and the principles would help make that happen. Although we have our established Agile processes/ceremonies, like our daily standups, planning, sprint retros etc, we wanted to figure out how we better respect each other and address potential friction, the principles we came up were:

  • Words are important
  • Be an educator
  • Delight Users
  • Kaizen - Dont Makes Things Work
  • Design and Build for Operations
  • Only Build What Matters and Adds Value
  • Write Clear Rather than Clever Code
  • Automation beats Repetition
  • Collaborate rather than Corroborate
  • Test What YOU Develop These principles helped the team think more broadly about issues.
  • Engineers are all about the how. We gave them a little more of the what and why.
  • If you're doing things you don't realize are impactful to others, background is required.
  • We asked them to think about operations. Writing code is easy, but code lives and is operated for a long time.
  • We placed a big emphasis on not just the development side of engineering but also on the QA side and making engineers responsible for their own quality

Lessons learned

It is difficult to introduce principles and perseverance is important, everybody has to use them in real life situations and you as the sponsor have to constantly use/reference them. We now use the principles in lots of aspects of engineering i.e. in discussions about design, ops, etc. They've also become prompts for the product team if they propose an idea, then we discuss all of the other partners and people within the organization that might be impacted. These best practices define how we think about our work. Everybody now has a common understanding, which is especially helpful for remote teams and across languages, in conveying why we're making a particular request or how we think about it. But to be clear they also need constant refinement as goals change so you need iterate on them. By empowering our team to take more ownership for the code, the quality has improved. There's less of a laissez-faire (indifferent) style of engineering and there's is now less of a back and forth between teams.

Be notified about next articles from Neil Mitchell

Neil Mitchell

Head of Platform Engineering at Valley National Bank

Engineering LeadershipCommunicationOrganizational StrategyCulture DevelopmentEngineering ManagementPerformance MetricsTechnical ExpertiseTechnical SkillsProgrammingSoftware Development

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBountiesBecome a mentor

© 2024 Plato. All rights reserved

LoginSign up