Methodology

To gather the traits or skills a successful engineer should develop, we conducted a series of interviews. The pool of interviewees includes lead software engineers, DevOps, QA, UX, TW, PjMs, BRMs, etc.

To prioritize these traits, we created a card sorting exercise with the same pool of interviewees.

Interviewees Demographics

Roles

Participants

Software Engineers

6

Business (BRM, PjM)

2

Delivery (DevOps, QA, UX, TW)

4

Others (Academy, Security)

2

Interview Questions

In the interviews, we asked the following questions:

  • What do you think a great engineer should know?

  • My team achieves their goals because the engineers know or do X.

  • What could an engineer do to make your job easier?

  • I wish every engineer at our company knew/did X.

  • What do you think prevents developers from delivering?

  • The engineers in my team are great because they do X.

  • What things you have to fight against or for in your project?

  • What do engineers in successful teams do that engineers in other teams don't?

Interivew Answers

The following answers complete this phrase:

A successful engineer at our company ...

Sr. Application Security Engineer

  • Does unit tests (TDD).

  • Documents code.

  • Writes well formed User Stories.

  • Gives reliable estimations.

  • Creates clear architecture diagrams (UML).

Software Engineer, Pod Lead

  • Clarifies Acceptance Criteria to avoid back-and-forth with the client.

  • Fosters effective internal communication between different parts of the team such as QA, UX, TW, Backend, Frontend, etc.

  • Has an automation-first mentality. Uses automation to increase their productivity.

  • Thinks before coding. Analyzes design decisions based on facts and avoids hype driven development.

  • Follows up best practices and guidelines.

Academy Sr. Program Manager

  • Documents code and generates documentation.

  • Knows how and when to say no to stakeholders.

  • Understands and applies the client standards and best practices.

  • Tailors their communication to their audience level of technicality and needs.

  • Adapts to the different development workflows, code styles, and conventions of a team.

  • Understands the clients goals and uses them to prioritize the work.

  • Keeps a healthy life-work balance.

Project Management Director

  • Understands the project's business objective.

  • Has empathy with the client needs.

  • Analyzes the impact of a ticket towards the product goals and client strategy.

  • Considers the business context to make better prioritization and architecture decisions.

  • Focuses in the problem and not the solution only. Avoids focusing too much in the how.

  • Feels ownership of what they do, including testing. Doesn't leave everything to QA.

  • Looks for solutions on their own, is curious. Does not expect someone else to solve their questions or to give them detailed steps.

  • Knows how to communicate with client and with the team.

  • Knows when to ask for help.

  • Understands the commitment with the client and communicates quickly when a commitment won't be met.

Technical Writer

  • Gives clear standup updates.

  • Communicates clearly in presentations.

  • Applies writing best practices in emails to clients and Slack.

  • Knows what to communicate to the client and what not.

  • Knows how to communicate that something is blocked. Talks about the problem and asks for help.

  • Sees and understands the big picture of the project, the client's goal, what they want to achieve, the business value.

DevOps, Engineering Manager

  • Knows how to troubleshoot non-local environments.

  • Is proactive when doing troubleshooting.

  • Knows their project pipeline.

  • Is proactive when there is an issue. Communicates if they did any related change that may have caused the issue.

  • Knows and understands the projects running environment. If it's in a server or serverless, etc. Doesn't disengage from where the code is running.

  • Accepts the responsibility of code errors. Doesn't say it is the DevOps fault.

  • Gives constructive feedback in code reviews and to other team members. Adds enough context or related code examples in the PR comments.

  • Adds guidelines after failures.

Software Engineer in Test

  • Knows how to do stories estimation following the Agile process.

  • Understands the QA role inside the team.

  • Collaborates with the QA engineer.

  • Applies good tracking tool practices. Updates tickets status and assignees.

  • Is familiar with the ticket's workflow.

  • Understands the importance of having a good communication with the QA engineer.

  • Writes well formed user stories. Verifies that the user stories are testable.

  • Does demo dry runs.

  • Uses planning poker to do estimations.

  • Knows basic technical writing skills.

  • Understands the Agile Development processes.

  • Does realistic estimations.

  • Creates PRs using a template that includes screenshots and steps to test the PR.

  • Builds significative unit tests and integrates the unit test execution into the build process. Uses a coverage tool.

  • Does excellent code reviews. Tests the feature branches locally and detects bugs early.

  • Does stories subtasking.

  • Communicates when new releases is up.

  • Doesn't over compromise.

Software Engineer, Platform Architect

  • Understands and uses the Agile Development methodology.

  • Knows how and when to do refactors.

  • Applies Clean Code practices.

  • Does unit tests.

  • Knows about design patterns.

  • Clarifies requirements.

  • Proposes solutions based the big picture of what the client wants to achieve, not the how.

  • Fosters communication with the client and with the internal team.

  • Gives clear standup updates that communicate what are they doing. Can translate technical details into to day to day words.

  • Documents the onboarding process. Is focused in documentation.

  • Is clear when they have no idea of how long a task would take.

  • Is realistic, not too optimistic, when doing estimations.

Software Engineer, Product Owner

  • Is committed with high code quality. In PRs, reviews the logic and code conventions. Doesn't approve PRs just because.

  • Is committed to deliverables. Understands that when there is a critical deliverable, they need to work more to complete it, beyond the tracking tools.

  • When giving demos, practices them, validates them, and knows how to react to failure.

  • Fosters open internal communications. Shares problems and ideas without fear of retaliation.

  • Asks for help to their team.

  • Understands the project development methodology.

  • Has ownership of the code, including the documentation.

  • Writes clean reusable code. Assumes someone else is going to use it.

  • Is willing to communicate and listen to other team members.

  • Accepts and gives feedback.

  • Is eager to learn new things.

  • Adapts to the way of the team gives feedback.

  • Joins the standups on time.

Software Engineer, Platform Architect

  • Understands testing concepts and knows how to automate them: unit testing, functional, integration, performance, regression. Uses the QA as a consultant only.

  • Knows the origins of Agile Development and why it is useful.

  • Clarifies, understands, and negotiates requirements.

  • Fosters better internal communication. Discusses technical things among the team and respects the technical decisions of other team members.

  • Is open to learn from someone else.

  • Understands the problem they are solving.

  • Has enough technical abilities to develop the project.

Software Engineer, Platform Architect

  • Knows and applies best development practices, such as design patterns, code reusability, and good variable naming.

  • Knows how to do refactors.

  • Writes significative tests.

  • Knows basic architecture and security concepts.

  • Is a specialist in something.

  • Has a good debugging process. Knows how to effectively find the root cause.

  • Has enough skills to communicate with the team. Can explain their ideas and defend them with good arguments.

  • Has good communication with the client (Nice to have).

  • In complex situations, doesn't take things to heart. Doesn't feel attacked and doesn't attack people. Even when they are under stress, they don't generate conflict. Talks face to face to try to solve the problem. Avoids talking behind other person's backs.

  • Is trustworthy.

  • Is reliable. Communicates when they can't finish or there is a problem.

  • Has good work ethic. Takes decisions that benefit the team or client even when that is a difficult decision or means extra work.

  • Respects their team and their work.

  • Understands that they are here to build a company, not only for a 9 to 5 job. Looks for opportunities to contribute to a better company. Tries to fix the problems they see instead of pushing it to someone else.

  • Is always looking for a way to improve. Is open to feedback.

  • Understands that the goal is to solve problems and that technology is only one medium.

  • Knows who can help them and seeks help fast. Avoids solving the same problem twice.

Business Relationship Manager

  • Cares about understanding the client. What they do, what they care of? Finds new areas of opportunity where they can offer more to the client.

  • Cares about team work. They are not isolated, they are not entitled.

  • Is on the lookout of the client needs. Communicates to the team any insight regarding the client.

  • Prioritizes the daily standups. Understands that the daily communication with the client is more important than running morning errands.

Product Software Engineer

  • Thinks about code maintainability. Writes code that is easy to test, to change, and to understand a year after.

  • Does not only translate the ideas of others to code, but also has initiative to solve problems.

  • Cares about the future developers.

  • Has initiative to solve issues, even when they didn't cause it or wrote the code that caused it.

  • Understands the bases of general concepts and applies them to learn new technologies of other projects. Reduces the limitations for staffing.

  • Has disposition to solve problems. Has empathy to help persons without technical background solve their problems.

  • Clearly expresses their ideas to stakeholders making them understand the limitations. Knows how to negotiate to avoid too much dependency on the PjM.

User Experience Designer

  • Understands the UX process.

  • Understands that UX is not the responsibility of the UXer only.

  • Participates in the UX process with feedback from a technical point of view.

  • Doesn't focus on things that don't matter. Knows that what matters is doing a good job. Explores other ideas if they don't like their current project.

  • Is proactive. Accepts that not all projects are challenging, but proposes solutions instead of only complaining.

  • Avoids attitudes such as "it can't be done" or "is too difficult".

  • Knows how to confront people. If they don't like someone's work or the way someone works, talks it directly instead of escalating it.

  • Understands that is healthy to have discussions, but being respectful.

  • Knows how to confront the client. Does questions and proposes better solutions based in their own experience.

  • Demonstrates their technical expertise by understanding better the client's ask and proposing other solutions, not only doing what the client asks. Helps the client understand the consequences or options.

Prioritization

To prioritize the traits, we used a Card Sorting exercise based in the ideas of this article.

As in the article, we calculated the weighted priority with the following formula:

WP = 4 * times placed in “Most important” + 2 * times placed in “Very important” + times placed in “Important”

Prioritization Results

Trait

+++

++

+

WP

Team Work

8

6

0

44

Goals Oriented

7

3

2

36

Problem Solving

5

5

3

33

Work Ethic

5

4

4

32

Development Best Practices

4

7

2

32

Emotional Intelligence

5

1

8

30

Feedback

4

4

5

29

Client Communication

3

3

8

26

Requirements Negotiation

3

3

6

24

Working with Other Roles

3

2

7

23

Testing

1

7

5

23

Learning

1

5

7

21

Agile Development

1

4

7

19

Estimations

1

3

9

19

Code Review

0

6

7

19

Risk Communication

1

3

8

18

Daily Standup

1

2

9

17

Fixing Issues

0

4

7

15

Documentation

0

2

11

15

User Stories

0

3

8

14

Running Environment

0

3

7

13

Giving Presentations

0

2

9

13

Writing

0

1

10

12

Ticket Tracking

0

1

9

11

Last updated