What Makes a GREAT Engineer

There's a lot of talk around the internet on what makes a great engineer, team player, executive et cetera. Since our founding, one thing that has become clear as we’ve grown and matured as an organization, is that as humans we want more clarity on what behaviors can make someone great at what they do.

Observing this pattern, we ended up formalizing our engineering levels with clear requirements on what it would take our team members to get to the next level.

There’s a lot of talk regarding the “10x engineer,” who exhibits unrealistic levels of productivity (and no empathy). But we want to challenge the notion that there’s only one way to be an effective engineer. The initial draft for this post riffed off an old post by Ben Horowitz on good and bad product managers.

In reality, all of us, at some point, have embodied behaviors that we describe as effective or ineffective on the list below.

The goal of this post is to keep all of us (including us) focused on demonstrating positive behaviors that help us become a better product team every day.

Behave as an Owner

It’s easy when you’re part of a bigger team to think of problems as something you don’t have an obligation, permission, or time to solve, and as a result to pass that issue along to the next engineer, tech lead, or worse yet—user. The behavioral goal is not “if you see something, say something,” but rather “if you see something, do something.”

Effective behaviors:

1. Proactively taking ownership of problems and creating solutions.
2. Knowing the backlog and developing your own sense of priority.
3. Being able to work autonomously without explicit daily direction.
4. When things go wrong, thinking "it may not be my fault, but it is my problem,” and addressing alerts and customer issues without being asked.
5. Seeing a job all the way through (scoping to shipping).
6. As you come up with solutions, ask questions and verify your approach.
7. Addressing code review comments, getting your work merged, deploying and testing your changes, releasing the feature to customers, and validating that there are no issues.
8. Knowing that you are the master of your own growth.
9. Watching what more senior engineers do and emulating their behavior.
10. Building trust, autonomy, and social capital over time, knowing those things must be earned.
11. Thinking long term, setting goals for your own progress and learning.

Ineffective behaviors:

1. Thinking “that’s not my job”.
2. Waiting for your lead to assign you work. Never taking alerts or addressing customer issues and bugs without being asked. Assuming someone else will handle problems.
3. Focusing only on the discrete tasks that are assigned to you instead of developing a holistic view of your team’s work.
4. Thinking that your product’s direction and roadmap comes only from leadership.
5. Needing constant check-ins to make sure you’re focused on the right tasks.
6. Starting to code immediately without thinking through or validating your approach. Failing to consistently discuss possible solutions or solicit feedback from your team or peers while working.
7. Not communicating about how your work is going unless someone asks you. Needing someone else to remind you to update issues or share a project’s status.
8. Not letting anyone know when you’re stuck. Wasting time going in circles without asking for help.
9. Not trying to solve a problem on your own before asking others.
10. Not proactively addressing code comments or pushing your code unless someone reminds you. Letting others stumble upon code problems in production.
11. Not asking questions or showing curiosity about customers and competitive products. Ignoring the wider context and focusing only on your island of ownership.
12. Believing you are owed career progression or promotion. Waiting for wake up calls to push you to grow.
13. Ignoring the behaviors that have helped those more senior to you advance.
14. Never asking for help. Thinking you should already know the answer to every question or that you should always be able to work things out by yourself.
15. Not planning your work in advance. Not setting goals and reflecting on whether you’ve met those goals.

Customer First Approach

At Turing Technologies, our mission is to help millions of organizations grow better, so it’s expected that our engineers and tech leads demonstrate customer-centricity in their approach.

Effective behaviors:

• Going on calls with customers/clients on how they use the product. Approaching these calls to understand their pain points and building things that delight the end user.
• Building with empathy. Approaching the problem with customers’ use cases and workflows in mind.
• Understanding that code that doesn’t provide value to end users isn't worth writing.

Ineffective behaviors:

• Caring more about using a new technology or approach, than the value it adds for end users.
• Sitting out of user calls and research sessions.
• Not using the product—and maybe not even being sure of what the product does.

Complacency is the Root of all Decay

In a market where customers have thousands of options for their tech stack, our team needs to feel that avoiding problems is failure.

Effective behaviors:

1. Leaving things in better state than you found them.
2. Questioning the accepted truths. Seeing when systems are no longer adequate and identifying where and how to adapt them.
3. Understanding team strategy, developing your own perspective, and giving feedback and suggestions. Being passionate about your team and sharing that passion with others.

Ineffective behaviors:

1. Writing code, but not connecting it to solutions or outcomes.
2. Not testing your code.
3. Trying to pass off laziness as keeping it simple.
4. Following known patterns blindly, and failing to adapt to changing needs or requirements.
5. Complaining about what’s going wrong—but not working to fix it.
6. Assigning blame instead of charting a path forward.
7. Seeing the existing culture, technology, and process as permanent.
8. Not pushing yourself and others to grow.

Shipping Fast & Iterating

One of the reasons engineers come to work with us to this day is because we move very quickly. So if you’re someone who wants to launch just one big product per year or who wants an instructional manual for daily tasks, we likely aren’t the best fit.

Effective behaviors:

1. Knowing that no one gets things perfect on the first (or even second) try, but doing what you can to make things better with every iteration.
2. Knowing that complex systems evolve from simple systems. Not designing complex systems from scratch—but starting over from simple systems.
3. Identifying ways to test concepts with customers without building an entire application.
4. Knowing when to let a project go if it’s just not working.
5. Building out something that works and provides value to customers, even if dependent teams are still catching up.

Ineffective behaviors:

1. Trying to create a perfect system, then getting bogged down in complexity and details. Coming up with reasons why your system is special and can’t be built iteratively.
2. Working for weeks without committing code or getting feedback from customers.
3. Getting attached to a project and insisting on seeing it through to completion, even when the tide has shifted from customer feedback or lack of interest.
4. Demanding perfection from other teams, and being reluctant to let other teams iterate on problems for fear that it will make your life harder.

Keep it Simple

We want to grow people who infuse simplicity into our product and systems with everything they do. Often the boldest actions in our team are deleting code, choosing not to build something new, and removing steps or processes to help our customers save valuable time. We want to create an environment that values and rewards simplicity for our team and for our customers.

Effective behaviors:

1. Taking as much pleasure in deleting code as you do in writing it.
2. Solving one problem at a time, instead of trying to solve 100% of use cases.
3. Starting simple, looking for opportunities to deliver 80% of the value with 20% of the solution.
4. Writing code as if someone else will one day read it. Chances are someone will.
5. Implementing things when you actually need them, rather than when you think you might.

Ineffective behaviors:

1. Writing code that’s needlessly complex or difficult to debug.
2. Failing to appreciate the value of consistency; introducing new technologies or libraries for minor benefits.
3. Using technologies or frameworks meant to solve much larger problems when you could have used something simple or well-known.

Finally, no list of behaviors is ever exhaustive, unconditional, or applicable in every situation. Cultural context and situational context are critical here. But our goal in sharing this is to give our candidates, engineers, customers, partners, and leadership team a clear picture of how we think about success as a team, and the choices, big and small, that drive what we view as high impact behaviors in our organization.