Expectations: We all have them, whether we’re aware of them or not.
In interpersonal relationships, expectations are said to be “killers.” This is due to their silent nature, because our expectations are often unspoken, which is where trouble can lay in wait.
An action that seems perfectly logical to your coworker, can leave you gasping in confusion. You can’t respond because you couldn’t even fathom approaching work in that way. You are dumbfounded because, to you, such behavior “goes without saying.” But what may be obvious to you can be another person’s blind spot.
As tech companies try to retain their talent during this Great Resignation, there’s a growing consensus that the reason so many workers are quitting stems from their expectations no longer lining up with the expectations of the organization. People are rethinking their work and life goals, disillusioned with a lack of open opportunities.
It’s realistic to have expectations for yourself, your coworkers, and leaders, but they can lead you astray by assuming your expectations are understood and shared by others.
Especially for software engineers; it can be easy to fall into some common blind spots and stereotypes about expectations at a tech company. Individual biases can set up unrealistic expectations throughout an engineering organization. Holding others to some arbitrary, invisible rules that they just have to guess at is an unfair situation to all involved.
Dispelling Assumptions, Defining Expectations
This is why it is important to clarify the professional expectations that are inherent to your engineering culture. Within a tech company, there will be multiple overlapping cultures with their own set of behavioral expectations.
The overarching expectations of the company is influenced by its founders, location, investments, and goals. For example, here in the states, people from the west coast tend to expect a more casual appearance in business settings. But on the east coast, there’s a higher expectation for a more buttoned-up appearance. Yet there’s still nuance in what constitutes ‘casual’ – does it matter if someone comes to work barefoot? One person’s fancy may be another person’s casual, thanks to cultural perspectives.
Then there’s the culture specific to an individual team, which is developed from the way coworkers engage with each other and the team’s goals. Even outside influences – like the stereotype of the 10x developer—can shape an individual’s expectations on what an engineer should look like or how they should act. Which can be completely different to your coworker’s interpretation of what a developer should be.
So, what are the professional expectations—those of your engineering team, department or even just you personally? Most lists start with the basics: responsibilities, communication skills, appearance, and conduct. Most professional expectations are often derived from a company’s culture, highlighting values like kindness and honesty. At Google, their expectations about respect—for the user, the opportunity, and each other—are outlined in public community guidelines.
Unfortunately, managers often don’t elaborate beyond these basics and expect software engineers to pick up a company’s expectations by osmosis. These unspoken norms often lax context, becoming a process that is full of restrictions because “that’s the way it’s done.” A developer may know what they are expected to produce, but it fails to answer deeper questions about their purpose, impact, and value. Prompting these philosophical questions helps developers and engineers feel more engaged with their work.
A better way to be transparent with a team’s goals is to build in questions that help explore the context behind professional expectations.
Defining expectations by asking:
- How much failure is acceptable?
- How do we tolerate failure over time?
- If the manager’s philosophy is to “fail faster,” by what metric is she making that determination?
- Who is accountable and what does that accountability mean?
- Do you place an importance on the individual, but believe all credit goes to the team?
- How does a team share knowledge, and when is someone expected to own information or be the go-to knowledge expert around a specific competency?
- Is vulnerability really appreciated—among everyone?
Getting On The Same Page, Over And Over Again
Software development is a team sport, and explicit expectations help teams work in the right direction, in the same ways.
If it is not clear about where your line of acceptable behaviors is drawn, you may find your line getting pushed back. Questions help prevent the standards for acceptable behaviors from being pushed backwards. Asking the engineers to define these expectations aloud allows managers to create a better space to confront any misalignment. Reduce the chance of bad behaviors and expectations festering and degrading your engineering culture.
Even asking questions about the basic expectations, those small things can make a huge difference. Do we turn cameras off in video meetings? That would be good to know. Is cursing allowed, because we all have our moments, but at what volume? What level of intensity? Around which people?
But openly declaring your expectations can’t just happen once. It must be an iterative process – much like fine-tuning to maintain a healthy engineering culture. Defining professional expectations becomes critical when adding a new hire to the engineering team.
New hires have so much to pick up on just being new, they can easily miss the nuances of team expectations. With functional onboarding, Edify brings expectations to bear, getting them out into the open so they can’t sneak up on a person. New hires and engineering teams will feel led by an onboarding process checklist that puts expectations first. And helps free up bandwidth for engineers to create, without feeling like they have reinvent the wheel, too.
Edify developed our chat bot eddy to help new hires learn those shared expectations. Hiring managers and team members can help articulate their own expectations derived from their time in the company to eddy, thus becoming part of the onboarding plan. By keeping eddy up-to-date for each new engineer, your team’s expectations stay current too.
By moving “the norms” from tacit to explicit, and having an easy way to reference back to those values thanks to eddy, it becomes easier to avoid behaviors that result in performance issues.
Clear professional expectations help contribute to a good engineering culture—one that evolves, adapts and grows so no matter when someone joins the team, they will be on the same page with their team.