Setting Expectations for Software Engineering Teams

Introduction

When I started at Andela as the CTO I had an opportunity to introduce myself and set expectations for the technology product function. I described the goals and values I hold for individuals building technology. This was generalized across all product functions - engineering, product, design. Here is what I communicated at the time:

Mission

The most important thing we do as a technology organization is to deliver value to our customers in the form of compelling capabilities that solve business problems, quickly.

We Must

• Be accountable for delivery
• Be lean (i.e. build, learn, iterate)
• Do not be afraid to fail
• Work hard at communication across a remote organization
• Focus on delivering business value

What I Value

1. Customer Value is Priority #1
2. Accountability and Taking Ownership
3. Lean Approach to Delivery
4. Deep Customer Empathy
5. High Quality Scalable Systems
6. Design as a Differentiator / Emotive UI’s
7. Trust (and Respect)
8. Team above Individual
9. Working Hard (to be great at your craft)
10. Growing Your Skills (and Kaizen)

As 2019 wraps up and we move into the new year, I want to reflect and go deeper with more specificity on what I expect of software engineers.

These expectations come from learnings over many years of software development during my career. One should view these insights as a set of desired behaviors to produce better software.

Expectations of a Software Engineer

1/ Doing Your Work

• Show up ready to work and be proactive. We have to deliver because that is what the business expects of us. Yes, we use deadlines because they drive outcomes. Some people argue different forms of programming or agile methods. But, I will tell you this, I will always take SCRUM over Kanban for the simple reason that you have an end of sprint deadline with SCRUM that forces an outcome. And in the spirit of driving personal results, do not be that person waiting to take a ticket — lean into your work and ask for more problems to solve, stories to pull into the sprint, or tough bugs to squash.
• Own the problem, know the customer, know the product. It is critical that you understand the problems you are solving so you can be part of the solution. You should also strive to know how to use the product you are working on inside and out. Step up and give demos to show your knowledge. And, if you are not meeting with the customer from time to time, you are not doing enough to understand the problem.
• Production problems take top priority. It is unacceptable to say we will get to it later. If the system is losing data or if production is down, put fixing the issue at the top of the queue and don’t stop until you have a remedy. It might be painful in the moment, but I can tell you that the ‘esprit de corps’ (the feeling of pride) and the sense of accomplishment you and your team feel after conquering the problem, will last a long time.
• Think like a lazy person. Lazy not in how you act at work, but in how you solve a problem — sounds funny, but this is about how you automate not just the product you are building, but your environment, your testing set up, your tool chain, etc. Some of the best engineers I know are inherently lazy always looking for the most automated way to get something done.
• Engage others quickly when you are struck. Writing software is a team sport and the longer you go down a rabbit hole without asking for help, the more you are slowing the overall process. Yes, try to figure it out on your own, but quickly recognize when you are blocked so you can reach out to others to get moving forward again.

2/ Engineering Software Proficiently

• Code must be testable, able to scale, and performant. Do you have a unit test? Are the test cases easy to execute? Did you use feature flags? Did you hard code the CSS or is it configuration driven? Did you think how the service will perform at low, medium, and high load? Answer questions like these as you code. Have a mental checklist to go through before pushing your work.
• Everyone is responsible for code maintenance and improving quality. It takes experience to learn this mindset, but once you push your PR, the code you have written goes from being yours to being everyones. Do not take a mindset of “this is mine”. You have to be open to review and you have to entrust others to help make it better. And, as you interact with new areas of the code base you have a responsibility to improve it. It is kind of like responsible camping — leave the place where you were cleaner than when you found it.
• Deliver great UI’s user’s love. Always have empathy for the user and pay attention to the little stuff (e.g. the padding, the typography, the use of whitespace). You should also suggest better workflows if it makes sense and tell your team about it. Make the UI great as this is required to be relevant in today’s world. The best frontend engineers I know are not only quick to implement the interface, but they think like a user, always striving for clarity of experience and suggesting improvements.
• Write functional code that is easy to read and executes the task. Engineers have religious debates over code reviews and what should be in a pull request all the way down to the use of semicolons. However, this is a must: your code has to be readable (i.e. easy to understand with good commenting) and it has to perform the function it set out to achieve. Those are the basics that are required.
• Documentation: write it to explain and read it to understand. Yes, you must do it. As you progress in your career you start doing more of this to ensure communication of the proper design intent. It is also is one of the best ways to ensure maintainability and easy onboarding of new team members. Part of your job is writing documentation. You need to read the documentation, too. This is how you come up to speed on a new service or technology and avoid common mistakes.
• Software must be fast, do the task, and entail a little delight. And in that order. The best user experience is a fast performing application with low latency, quick response times, and few spinning wheels waiting on a function to complete. Of course, the software has to do the job as described, and it must do the task well. Otherwise just go home. I also advocate for software products to always have a little bit of delight for the user. Put personality into the copy or add that extra feature that makes the user smile or go “that is cool”. As with anything, it’s the details that set us apart.

3/ Improving Yourself and Team

• Be great at stakeholder management. Being a great stakeholder means being invested in the work you are doing with the team you are doing it with. You should always be working to understand by asking questions, improving your estimates so you can help set expectations better, and pro-actively engaging and constantly communicating with your team members. You need to keep the team informed of progress, blockers, and new ideas.
• Demand validated requirements and mockups. Sometimes people think along the lines: Product Managers own the “what and why” and Engineers own the “how” to build it. That is essentially the case in terms of responsibilities, but to be a high functioning team, engineers must also test the requirements. Demand validated requirements because it would be awful to be working on something that no one cares about.
• Suggest solutions, not just raise problems. Be part of the solution. If you see issues with requirements, the code base, processes, or team dynamics, you should raise them in a considerate way and suggest solutions. People appreciate and are more willing to take action when solutions to problems are offered up along with the issue itself. Challenge in a constructive way and be open to constructive feedback yourself.
• Work at forming a cohesive team and do your part. Be proactive, share ideas, help others. You also need to be constructive with criticism. Critiquing work is very important and makes us better, but it has to be done in a way that is focused on the goal of improving the end result and not aimed at the individual. Healthy discussion is critical, but strive for doing it in the context of a high functioning team that has a deep amount of trust and respect for others. No one wants to work with a jerk, so be self aware and avoid being that person!!
• Always be learning and share something relevant. Technology is always changing and you need to change along with it. Continue to learn new things and never rest on your past accomplishments. Seek out new challenges that help you improve. Also share new learnings with the team that can help produce better outcomes.