Expectations for a Software Engineering Team

A standard of conduct for building and shipping great software together.

For a team to function well, it’s important to foster an environment where expectations are clear. As a fellow team member, these expectations are like a contract that sets a basic standard of conduct. And as a manager, it’s essential that you and those who report to you share those expectations as a foundation for giving fair and valuable feedback.

From my own experience as software team lead and team member I’ve come up with a set of such expectations and refined them a bit over time. By sharing and committing to these expectations, it ensures that a healthy and focused atmosphere exists and that those who work within it will stay happy and thrive. And when followed I believe these simple concepts remove huge amounts of friction and unlock a team’s potential to build and deliver great software.

Demonstrating Work Ethic

• Show every day prepared to do your best work at all times. A work environment should not be treated like a hangout with free coffee where some work is occasionally done. Consider the office like a factory floor where machines are running and everyone is wearing a hardhat.
• Go the extra mile to deliver high-quality work. With pressure to release as quick as possible it’s often easy to make sacrifices. But quality of work should never be one of those things that suffers. We should hold ourselves to as high of a standard as possible and never let that slip.
• Demonstrate a passionate interest in making improvements. Whether our code, our product, our culture or our processes, there’s always room for improvement and everyone’s feedback is valuable. Disinterest or passive complaints should be avoided in favor of solution-oriented discussions and proactivity.
• Plan to do things the right way and always do it. This isn’t always easy as it can involve advocating for the necessary time from stakeholders who do not have the same priorities. But we should always be working under the assumption that we are building the right software in the right way. Taking shortcuts and and creating problems for our future selves should be avoided.
• Proactively find ways to add value and avoid sitting idle. This is the right attitude for full-time team members, but oftentimes the “freelancer” attitude can occur. That is, a team member sits idle until given explicit instructions, then finishes the task as soon as possible and returns to sitting idle.

Being a Team Player

• Collaborate and solicit feedback to leverage our team’s shared knowledge. Working alone without feedback will almost always yield a subpar result. Use the team as a valuable resources for refining and improving your work. Test your assumptions and validate your ideas.
• Offer your time to help others and prioritize their needs over your own. Varying levels of expertise can often leave some team members with tougher challenges than others. In order to unblock each other and keep making efficient progress, team member should always be highly available to each other for help. If you can unblock someone, that should be your highest priority.
• Ask for help when you need it. Getting stuck from time to time is expected, but staying stuck is a problem. Before losing too much time, ask around for help. The team should always be available to support you.
• Disagree politely, commit firmly. In order to make the best decisions, options must be explored and everyone’s point of view should be considered. But this can be a source of friction when not done properly. Discussions should always remain polite and respectful and strong opinions should be tempered with patience. Once a decision is made, the team’s should offer its unified support to see it through to success.

Continuously Improving

• Demonstrate a diligent interest in learning and improving. Even the most experienced, expert, senior-level engineer can always learn something new and get even better. We should never rest on our laurels and should always be looking forward to the next steps of our personal and collective growth.
• Take careful effort to avoid repeating the same mistakes. It’s perfectly okay and actually a good thing to make mistakes—as long as they are treated as valuable learning moments. Collect these and remember them in order to build wisdom.
• Help keep the team informed with new ideas, technologies and trends. The team’s combined knowledge and perspectives are a great resource for one another, but this requires active participation from everyone. When you discover something new or interesting, don’t hesitate to share.
• Welcome the opportunity to work on something new and challenging. It can be difficult to step outside of your comfort zone and start over as a novice with another technology or problem domain. And not all tools are created equal—some are just no fun. But it’s harmful and even a bit toxic to avoid certain tasks, and especially to refuse an assignment or to assert: “That’s not my job.”

Demonstrating Proficiency

• Write code that is readable, testable, scalable, flexible and performant. Yes, this sounds like buzzword soup but I really believe in each one of these concepts. When evaluating each other’s work, run through them like a checklist and recommend improvements where something is falling short.
• Stay sharp and current. Maintain advanced knowledge of modern best practices in your programming language as well as the associated frameworks, libraries and development environments. Stay on top of new developments and don’t let your skills fall behind.
• Always deliver an ultra high-quality user experience. Simply meeting acceptance criteria isn’t enough, even if your code is beautiful and test coverage is at 100%. Products live and die on their user experience and even if it’s “working” we should never ship to our customers anything that is buggy, slow, non-intuitive or onerous.
• Use your expertise to add value. Being a senior engineer or hiring senior engineers is pointless when that potential cannot be realized. Where there is opportunity for the team or our products to benefit from your experience, bring that to bear. Everyone on the team should empower and encourage each other’s ideas.
• Develop detailed knowledge of the product. In particular, understand the business logic and problem domains surrounding our tools and systems and how they integrate with one another. Engineers should be a technical resource and encyclopedic reference for others.
• Read the documentation. Skipping over important documentation because it’s boring or time consuming can be a costly mistake. Dig into manuals other source materials for deep understanding before getting started with a new tool or framework so that you never make an easily-avoidable misstep.