When we chat with professionals in the Software Engineering community, we often hear painful stories from their work lives.
“An engineer spent a week building a new feature only to discover a teammate changed a critical interface without their knowledge. A team working on their product hasn’t spoken with their Product Manager in a month. A product demo failed to meet customer expectations, and it was months before engineering received feedback.”
The pattern we’ve noticed in many companies is that leadership hands out tasks to software engineers with little context and no consultation, and those engineers work in relative isolation. Then, after the work is complete, business leaders are frustrated when development does not solve the original problem, and the blame falls on the engineers. No wonder the turnover rate in our profession is so high!
At Realtracs, we aim to create a collaborative environment where tasks are not handed out or assigned to our engineers. Instead, business leaders ask our teams to solve customer problems and help achieve business outcomes. Our engineers and product leaders are then empowered to work together collaboratively, creatively ideating and experimenting to solve those problems.
Mindset Over Matter
But you might ask, what’s the catch? If this process works so well, why isn’t every team operating this way? Well, this way of working requires a different approach and shift in thinking from every person on the team. You can no longer show up, work on your assigned Jira ticket, and clock out for the day. Instead, you must develop a collaborative attitude and a problem-solving mindset, which can be challenging for many engineers. But, for those who embrace this change in perspective, it’s not scary—it’s rewarding! Below, we share the expectations we’ve agreed on for each other. In sharing how we view our team responsibilities, we hope to elevate the importance and value of each Software Engineer to the team. By empowering more software teams to work this way, we believe software engineers will feel more ownership over their work, be more empowered to grow in their profession, and experience more joy in what they do every day. In addition, we have found that our teams develop deeper bonds and trust with each other and have more fun together. Some describe it as “building cool things with friends.”
Here at Realtracs, a Software Engineer must focus on four categories of skills to be successful:
Personal Discipline: Software Engineering is a team sport. As such, we must develop and exercise those timeless, crucial traits like humility, accountability, resiliency, and persistence to work more effectively together. Such an effort requires placing necessary restrictions and boundaries on yourself, tempering your pride and ego with humbleness to grow and become a better engineer.
Product Engineering: A successful team orders itself towards producing a product that delivers value for its customers in alignment with the company’s vision.
Planning and Decomposition: Good software engineers work with Product Managers and each other to determine the feasibility of a product and develop a plan to turn concepts into reality.
Execution: Visions, ideas, and plans are only valuable if you have the agility and prowess to execute them. Expectations here revolve around working together to determine priorities, eliminating distractions, and managing the pace of value delivery.
According to the classifications above, we will list expectations in reverse order to demonstrate how each subsequent category undergirds the previous.
Execution
- I work to eliminate distractions to execute my team’s goals. I prioritize who and what gets my attention.
- I know we must stop starting and start finishing. Before pulling new work, I check to see if I can help my teammates by reviewing pull requests, providing feedback, testing, and verifying solutions.
- I don’t wait for teammates to ask me for help. I actively seek to aid my team in moving items through the development pipeline to completion.
- I can tell when things aren’t going to plan, and I help the team recognize that we may need to “re-plan.”
- I am aware of the team’s emotional state and help acknowledge struggles and celebrate successes.
- We prioritize bugs, alerts, and customer support issues directly affecting customers over all other work and strive to resolve them as quickly as possible.
Planning and Decomposition
- We have a plan for our work and have discussed the strategy as a team before we start. We don’t start and then figure it out later.
- We recognize when we need more information and utilize all available resources to create the best plan. If necessary, we include others outside our immediate team to acquire the information required.
- The plan is clear and understandable enough that every team member can start any part of the work as it becomes ready. The plan is documented and covers topics like boundaries, contracts, workflow, and state management, which we can reference during development.
- We can identify when reality does not correspond to our plan. When this happens, we do not trudge forward. We come back together and develop a new strategy.
- We break down our work into small, low-risk, easily releasable chunks.
- We have a release plan. We know how we will release value iteratively (using feature flags or another strategy), support it, and measure the value we deliver.
- No release plan is complete without knowing how to undo a deployment. When the inevitable happens and a release goes wrong, we are responsive and quick to implement our roll-back plan.
Product Engineering
- I understand that as a team member, I am responsible for all aspects of quality. I do not assume a specific task falls under the responsibility of a different teammate because of their role.
- I understand how we prioritize work and am a part of that process. I take pride in our product and help the team prioritize the most valuable work.
- I understand that sometimes the most valuable thing to work on may not be fun or exciting, but I still happily do it because I know the larger vision.
- I understand that design is a collaborative effort. Therefore, I provide feedback to the Product Manager on what is useful and valuable in the hopes that I can give a different perspective.
- I actively participate in determining the feasibility of the proposed work. I help my Product Manager assess the level of effort in a proposed solution and offer potential alternatives to select the best mixture of Useable, Valuable, and Feasible.
- I help defer unneeded work and help simplify requirements so that we can keep batch sizes small and be iterative in how we approach product development.
Personal Discipline
- I understand we are all on the same team. I help create a cooperative atmosphere and pursue collaboration with others, not just agreement. I seek feedback from people who think differently than me rather than those who are likely to approve.
- I am only successful if my team succeeds. The success of my personal goals cannot be at the expense of the team’s goals.
- I don’t work in isolation. I ensure my work is transparent and proactively share design and architectural decisions with my peers before I write code.
- I have a work environment and schedule that allows me to focus without distraction.
- I have a growth mindset. I regularly and humbly seek feedback from others to become the best version of myself.
- I know others need grace and encouragement just like I do.
At Realtracs, we firmly believe that if you take the time to set the right expectations with your team, you will be more aligned with your business’s vision, have a better understanding of your customer’s needs and produce a more valuable product. In addition, you’ll develop a more trusting, collaborative environment in which you will enjoy working. There’ll be no limit to your success!
If any of this has piqued your curiosity and you would like to learn more, check our Expectations of a Product Manager to see how the whole team solves problems together and works toward common goals.
