Employee’s Self-Assessment of Results Against Commitments
The first of my three commitments is a personal goal. It is less about working with the team so much as aligning myself to team success. Toward shipping our product, I have made commitments and accomplishments above and beyond simply participating in the process. I have provided review and feedback for all aspects of the project, including involvement in the planning process, raising and proposing solutions for development concerns, and helping bring new members up to speed.
Additionally, I took a lead position in the conception and implementation of the integration sprint. When the planning process was lead firmly in the direction of continued independent sprints and codebases, I investigated and presented the future risks to the team. I then acted as the scrum master for the sprint to integrate our disparate codebases. Simultaneously, I included planning for the ramping up of our engineering process and testing infrastructure.
My second commitment is about improving the performance of the development team. I don’t know if our team’s performance has improved. However, I do know our ability to understand and work with each other has improved. I influenced the definition of goals for the team, as opposed to individuals, to strive toward. This creates interdependencies and makes a team. Unfortunately, it also makes very clear team deficiencies. I think we have more work in improving our weaknesses and relying on our mutual strengths before I can consider us an “improved” team.
My third commitment was about ensuring the development team and our partners are synchronized. Much of the work there has been a matter of connecting the results and consumption of our teams. While painful, this has forced a spotlight and evaluation of both groups. On our partners’ side, the model creation process has been relatively uncontrolled and therefore allowed rapid evolution. The simple fact there are over six branches of the models – none matching the current project features – indicated there was a need for rigor. On the development side, we had only an ad-hoc process for accepting model changes, regenerating designers, and realigning all associated work. Now that our pains are understood, both teams (and our GPM) agree on the importance of defining and formalizing these processes. By getting all parties on the same page, we can make steps toward parity. (No one person can do it alone.)
Overall, I feel I have at the very least achieved my commitments. They were aggressive goals with the intention of causing both tactical and strategic change. I have been employed at Microsoft for six months, and had solid commitments for less than half that time. While simultaneously learning the culture and currently existing processes, I have been influential and some cases instrumental in both team and project improvement. I have had some setbacks, personality conflicts, and have been overly optimistic in some goals; but, thus far have allowed none of my overall commitments or personal goals to slip.
Self-Assessment of Commitment Rating: Achieved
Manager’s Overall Assessment of Employee’s Results Against all Commitments
Scott join the company in January and was productive in his role very quickly. I have been impressed with his attitude toward creating maintainable and quality code, and drive to have the right environment and practices. When working on the build system Scott quickly learnt the tools (TFS, MSBuild, C#, VS SDK) and then made the right design trade-offs to get what is needed and support a build that does not require SDK installation. His ability to dig into issues was great.
Scott was able to ramp up on the DSL toolkit, VS SDK and validation framework and our own toolset to get a number of sprint work items done and go beyond that to looking at the approach we take to generating the DSL designers and the associated code. He was able to come up with a number of ways to improve this process. He did not follow through with carefully written set of features for vendors to complete. I would have liked to have seen that.
Scott also influenced the way we work with his drive for and creation of the process developers follow in order to get code reviewed before check in.
For all Scott’s promise he has shown some behaviors which if not addressed will prevent his ability to be successful in the team and long term. If he is able practice better behaviors and show a shift in these I see Scott being very successful in the future at Microsoft.
The first pattern is attendance. The hours he keeps in his office have been erratic and he has been late to or missed many meetings. Both have resulted in Scott being hard to find and I have received feedback from multiple team members that they are unable to locate Scott at times during core business hours. The result of this is not just lost time but erodes the level of trust the team can have in Scott.
The other, and this is often related to the first, is that Scott needs to do better at remaining in contact with his team mates, particularly other disciplines. Missing daily scrums have been particularly harmful and resulted in others not knowing what his focus is and how his tasks are progressing. Some have viewed this as Scott taking a very Scott centered view of the project.
Addressing these issues should allow Scott to show a great cadence of delivery.
Final Commitment Rating: Exceeded
Final Contribution Ranking: 20%
Nine to five, Robinson.
And, talk with your PMs more.
Otherwise, you rock.