Make The Right Thing The Easy Thing
In the dynamic realm of software engineering, orchestrating a team towards cohesive productivity is both an art and science. It’s a landscape filled with intricate tasks, demanding precision and an eye for detail. As a software engineering manager, my journey through this world has been a constant endeavor to ensure the team’s efficiency. However, I’ve often found myself pondering one crucial question: How do we get the team to do the things we need them to do? This inquiry has led me to a simple yet profound realization: the path to success isn’t just in commanding action but in crafting an environment where the correct choices are the effortless ones. How do we achieve this in a field where tunnel vision is common, and the minutiae can eclipse the bigger picture? How do we transform good intentions into seamless, habitual practices? How can we guide our teams to not just hear but embody the unspoken language of action?
As a software engineering manager, I am often tasked with ensuring the team is doing things and we the team are achieving specific outcomes. Often I need to make sure specific things are happening on a regular basis. Occasionally I need to understand why the team is NOT doing something we otherwise think they should or thought they were.
For any change or behavior I need the team to act on, I lean on my golden rule to maximize our chance of success: “make the right thing (to do) the easy thing (to do) because when you make the right thing the hard thing you get the wrong thing”. Human nature is to minimize effort so every ounce of added friction for “the thing the team is to do” means the team is more likely to struggle executing.
Life is full of examples where the default behavior occurs because it’s been made so darn easy how could it happen any other way? The grocery store displays bakery items and fried food at the entrance and candy bars at the checkout lane. Social media websites siphon user data because of lax security settings. Disney World setup gift stores as the attraction exit so the parents will buy more gifts for their children. Why would you want to make it any harder than it needs to be for your team members to find success?
Keep meetings efficient by setting an agenda ahead of time. Eat less candy by removing it from your house. Complete your workouts by setting a workout plan ahead of time and pick a gym that is easy to access. Ensure the unit tests are run by including them with automation as part of the check-in process. Ensure the test environment is stable by adding automated verification tests. Agile software development practices encourage the team to break down work in to smaller pieces so they can be delivered more quickly. Reducing scope means reducing complexity which yields an increased chance of getting it right on the first attempt.
Software engineers are a predictable group of people - they easily get engrossed in their work which is similar to acute tunnel vision. They are “zoomed in on the microscope” and very easily miss things in the bigger picture. Software engineers are frequently shifting between solutioning, coding, testing, fixing, refactoring, beautifying, simplifying and optimizing. They miss things (in the moment) that seem horrifyingly obvious once sufficiently detached from the work. We have all heard “I could have sworn that button was working when I merged the code…” Drawing back to the tunnel vision analogy - the primary thing that made sense at the time was their work immediately in front of them. Use your imagination to replace “software engineer” with your field of choice and the specific ways they operate - it’s all the same at the end.
I’ve lost track of the number of times a senior team member has brought up a change for the team that I felt was overly confusing or ambiguous or perhaps even both. My role as a manager is sometimes a therapist - to absorb the negative emotions, diminish their power and then get the person to work towards a solution. If I can get them to get me to clearly understand the problem and articulate the solution then we have solid evidence that we can get the team moving on board too.
My approach of “making things easy” is completely unremarkable and probably makes a lot of sense on face value. However, I’m frequently shocked at the high levels of compliance that teammates are expected to showcase simply because they were ordered to do so. That’s just not how people work. As the leader, our objective is to ensure that the established processes for the team are simple, concise, straight forward and make sense. So simple, a caveman could do it if necessary. Your team will SHOW YOU through their actions when they are picking up what you have been putting down. The actions of the team will show you what they understand.
What can we learn from a skilled prompt engineer that can be applied to our human interactions?
My next post: Prompt Engineering for HumansIt is the leaders responsibility to ensure the team is given the proper runway and support to maximize their potential It is the leaders responsibility to ensure that problems are properly remediated once identified. One option for problem resolution that is quite common is to get mad, lead through negative emotions, announce the team members are stupid and lazy, make passive aggressive comments about the lack of commitment or professionalism and finally alienate everyone in your vicinity. Reaching for the phrase “what the heck is wrong with my team??” is the perfect litmus test for knowing that the team has been tasked with ambiguous orders that are too difficult to execute in a reliable and timely manner. Jocko Willink taught me “there are no bad teams, only bad leaders” to which I fully believe because I’ve seen it play out time and time again. Seeing is believing. The leader is the only person that can be identified as the root cause of a problem!
Another option, the preferred option for a strong leader, is to review the underlying root causes for the problem and then enact change where we make the desired outcome so simple to accomplish it’s impossible to NOT do it. Ensure the team knows there are real reasons for why they need to follow protocol. Chat with the team to see if they can identify why they are struggling to follow through with the requests. Keep in mind, they might not even know themselves. Listen to them if they offer meaningful improvements but if not, the leader must be maximally aware of what can be done to ensure the team members can follow through for what is being asked of them.
Remember this short phrase: make the right thing the easy thing. No one will ever say “thank you” for making it easy but they will do what you need them to when you need them to it.
On Twitter/X I post focused content on software engineering and leadership. Where did I get it right? Where did I get it wrong? Let me know.
Follow me on Twitter/X