Level 11

Communication

• comfortable offering constructive feedback to all levels, even clients
• accepts feedback and modifies behavior based on the feedback
• Always writes down processes and procedures to follow for other developers
• Regularly updates other members of team, PM in particular, on status, including whether they are blocked, questions, and how long current task may take to complete
• Actively participates in retrospectives and other performance meetings (one-to-ones), e.g.: shares their ideas with other members of the team
• Communication is truthful and accurate (no effort is made to cover one’s mistakes)
• Expresses feelings regarding a project during retros or other organized meetings (one to ones)

Leading

• are able to identify which developers are able to execute given tasks effectively
• seeks input prior to making a decision from those affected by the decision so that they feel that they are a part of the final decision
• Others come to you seeking advice on how to do things
• Insights begin to be more creative, the developer begins to see more creative ways to move the project forward. For example, instead of documenting a process flow in text, the developer may create a process flow diagram or a class sequence diagram to help others see and understand sometimes complex relationships between different parts of the system.

Learning

• seeks input / feedback from others e.g. pull requests, sharing screens, code in Slack etc.
• incorporates that feedback into toolbox and skillset
• Self motivated, will teach themselves new skills when aware of a lack of knowledge
• At this level, learning begins to include “soft skills” (how to run a meeting, how to express yourself clearly in writing, etc.)

Ownership

• Track record of task and small project ownership
• Is aware of client needs and goals and adapts accordingly
• they know at all times how the client has defined success and if not will ask. They will also use that definition to drive how they work and be constantly challenging decisions if they do not reflect how they understand success. The typical quality vs time conundrum. They will also communicate this clearly to the client … if you need this by Friday I can only do it this way … this means that in future … at any time the developer can explain how success has been defined, will question it and the way they work will be defined by it.
• At this level developers are reliable. They do what they say they’ll do (but may still be off on estimates). For example, if they say they’ll get back to you, they get back to you. If they receive an email directed at them, they reply within a reasonable amount of time.
• At this level developers are able to rephrase tasks and ideas in their own words to demonstrate their understanding (or lack of) of a given task. For example, if a user story is “I as a user can leave a comment on a post so that my voice can be heard by the community.” the developer might rephrase as “Add a feature that allows users to comment on posts. This implies creating a Comment object and a relationship to both Posts and Users.” and might follow up with a question: “Should comments be deleted when the Post or User is deleted?”
• Demonstrates curiosity by asking about issues that are not assigned to her but that are of interest, possibly because they could impact her work.

Technical

• Able to contribute to project work independently
• Able to solve most problems presented to them
• Solves problems in the first or only way they can think of
• Solutions just get the task completed. May be able to articulate pros and cons of a given solution but unlikely to be comprehensive or able to offer alternatives
• Willing and able to introduce new patterns to projects
• Doesn’t necessarily recognise what patterns they are introducing and why