This is a public version of my Manager README. I have omitted some information that is very company specific regarding information about the product and company policy. If you're an internal person reading this then I can share another version with you that is 97% the same as this but has a bit of supplementary material that is important for you.
Revised September 2022 It's been nearly three years since I started my journey as a manager and I have learned A LOT over this time. I'm coming back to reflect on this document to see where I still agree, if I've changed my mind on anything and finally update with new information. Do you want to see what I learned? Check the diff on this file to see where my brain is focusing these days! Thanks for taking the time to read.
Hi, I’m Ryan Rodemoyer. Most people here call me Rodey. Rodey is a nickname I’ve had for the majority of my life and it’s just the first two syllables of my last name. My last name is kind of funky but it’s pronounced Row-Dee-moyer.
At this point in my life there are three things that define me: my family, my career and my fitness. My family consists of my wife of fourteen years and two daughters (eleven and fourteen when writing this). My youngest is crazy in to dance and my oldest is crazy about volleyball where she plays club and school. In early 2015 we relocated to Colorado in search of a better life than the cloudy, dreery and humid climate of western Pennsylvania. After six wonderful years in Denver we moved back to Pittsburgh, PA in June of 2021 and now live just outside of the airport. Being fit is a core value to me and I workout almost every day to support that value.
I’ve been with the company since May 2016 when I joined as a developer. I’ve had the most impact on a few key areas: RabbitMQ implementation, API security, adoption of Git and unit testing, creation of our webhooks framework and creation of the mcp-cli tool that is used to update local developer environments. In early 2018 I joined the Architecture group and over the next year and a half I split my time between the ELC and DC products. November 2019 I moved back to the Engineering organization as an Engineering Manager.
- Support the development team as a whole.
- Ensure we have the right people in our organization.
- Strive to efficiently use our company resources to make progress against our road map.
- All people need to be accountable to someone.
- All efforts need to be accountable to someone.
- Support my direct reports by providing feedback, exposure and opportunities for growth and learning.
- Balance your needs against the needs of the company/project and put you in a position to succeed. Preparation is your responsibility. My responsibility is for you to know what is expected.
- Make those around me better.
"So, what would you say you do around here?" goes the famous quote from Office Space. Even though it's a joke, I still have put a lot of thought into this question and how I would describe my job to a complete stranger. The answer is I get people to work together to build software. It is with that frame of reference that we can continue with describing my current role within the organization and the things I do on a daily basis.
One of my primary responsibilities is helping manage our Release Support team - the group of people and the workload that focuses on released versions and soon-to-be-released versions of our software. I can and will do many different things on this front to keep the team moving:
- help build and refine requirements
- help developers understand requirements
- review pull requests
- create work items to suggest enhancements and fix issues
- triage and resolve production issues and outages
- triage and resolve issues with internal deployments and environments
- several other responsibilities too onerous to fully enumerate
For technical work, I am hands-on with contributing to functional requirements, getting relevant information about the work and helping you navigate the organization so you you can deliver the technical changes. Part of my role is defining and setting requirements and expectations. I want you to have the “creative freedom” to deliver the solution assuming it solves the high level functional requirements. I prefer to contribute to the requirements of a solution and almost always delegate the implementation to those closest to the code.
"The buck stops here.", as they say. "One hand to shake." is another variation.
I have developed two axiomatic truths when it comes to managing people and managing work:
- All people need to be accountable to someone.
- All work needs to be accountable to someone.
Perhaps the above statements are obvious - that's a reasonable assessment. However, my experience shows me that the cause of so much strife within an organization is due to breakdowns in one or both cases. People are brought in to projects and given vague descriptions of what needs done, to whom they report and how they should get help. There are things that need done and it's unclear who will actually complete. Bob and Janet both think the other has the next step, or even worse neither Bob nor Janet know who will complete the next step. Another common situation is the team has identified several action items that are required to make progress or complete a task yet failed to assign a specific individual to the specific action item. Then over the next week, little-to-no progress was made because everyone resumed their normal day-to-day activities.
I view myself as a leader. People and work need to be lead.
Our relationship in the organization is a bit different than traditional manager-employee relationships at other organizations. At Mortgage Cadence, with respect to how we will interact, as a manager I operate in two phases:
- Work diligently to understand your professional goals, balance those items with your current progress and trajectory and influence others in the engineering and architecture groups to put you in positions/roles for where you are best-fit.
- For career and professional work, we will work together to build a plan for growth. I can and will put you in a position to succeed in this organization. Once in position, it is up to you to make the most of the opportunity. I can only open the doors for you - it is up to you to step through them.
- Understand the needs of the upcoming projects, company direction and skills of my employees to provide recommendations on direction for both company/product affairs and professional growth for people. Our company and products have the best chance for success when our people - who provide the direct support and lifeblood - are best prepared for the upcoming opportunities.
We will most likely not work on projects together nor will I assign you items/manage your workload. I have my own work to complete and will not be involved with assigning tasks to you or your team. You’re welcome to check in with me about your work items and ask for feedback, help and/or assistance but otherwise I will trust you to complete work items on your own terms and within the acceptable guidelines of your team.
I am a trusting person by default. I extend that trust, at the beginning, liberally. With that said, I retain the right to pull back my trust if professional and/or performance issues arise. My expectations are well documented (in this very document!) so if I do have a concern I can almost certainly reference my listed expectations as for why there is an issue we need to address.
Many years ago I had a boss who used the phrase "you can't manage what you can't measure". And while I didn't quite care for the fellow, I do think he was on to something. During my time as a manager I have developed a corollary: "your data tells the story". I've cultivated a fondness for data and using it to generate (hopefully actionable!) insights into our engineering practices and organization.
KPI is an acronym for Key Performance Indicator. Data points that we can anchor against to show us how we are performing as team members and as an software engineering organization. I'm extra passionate for these four KPI's because they speak volumes about how well a manager can onboard a new employee, get them acclimated to the organization and productive within the company.
- number of days to complete first pull request.
- number of pull requests complete within first thirty days.
- number of pull requests complete within first six months.
- number of kickbacks (a work item that goes back to development because it failed testing).
These are a few questions that we will discuss at one of our one on one meetings. I provide them ahead of time so you can think about potential answers, gather your thoughts and talk about them without being put on the spot.
- What makes for a good one on one?
- Unrelated to your career, what is a skill/craft/hobby you have consciously cultivated?
- What people in your professional life have impressed you and why?
- Who is someone in your career that you have gone back and thanked for something?
- In your own words, what do you expect from me?
These are a few items that have resonated with me and thought it would be useful to share.
- https://thinkgrowth.org/what-elon-musk-taught-me-about-growing-a-business-c2c173f5bff3
- https://www.youtube.com/watch?v=iMGWTGGVMzw (Jocko Podcast #210)
- https://www.businessinsider.com/former-navy-seals-jocko-willink-leif-babin-laws-of-combat-2018-9
- https://hbr.org/2011/04/how-to-build-confidence
- https://hbr.org/2020/05/good-leadership-is-about-communicating-why
- https://hbr.org/2016/01/the-right-way-to-hold-people-accountable
- https://hbr.org/2016/06/to-hold-someone-accountable-first-define-what-accountable-means
- https://www.saba.com/blog/how-to-hold-your-co-workers-accountable
These are high level targets that I will use to assess, gauge and guide your acclimation to the company over the first year. A Developer role requires a lot of things to get done yet it all boils down to this: shipping code. Our fundamental unit of work is making changes to the system through code and in our organization all code is changed through a pull request. Our most successful developers register high on the list on "raw number of pull requests completed".
- Setup developer environment.
- Demonstrate the most common tasks for a developer: update to the latest version of the software, update the database, etc.
- Ensure all aspects of the software can get launched successfully.
- Ensure that breakpoints in the backend and frontend can be hit.
- Complete first pull request.
- Explain relevant pipelines and the CI/CD process.
- Demonstrate the work item management tool (Azure DevOps, etc.) and how to find items to work on. Employee works with manager to find relevant work items. Do not assign complex or challenging work items that will require significant assistance from Manager or others.
- Complete 2-3 additional pull requests.
- Rapid knowledge acquisition and exposure to various work items.
- Resolving 1-2 work items or pull requests per week.
- Assist agile/scrum/feature team through implementation.
- Resolve 5-8 story points or 2-3 work items per week.
- Confidence building to work independently and with less oversight from team members. Employee is reaching out to peers/SME's when appropriate.
- Work independently on multiple areas of the system and/or with/through SME's.
- Carry a story from beginning to end while engaging relevant SME's when applicable.
- Resolving 8-13 story points or 2-4 work items per week.
- I will provide an additional list of relevant internal trainings that are beneficial along with a timeline to complete.
- Self-identify weaknesses or development areas where you are uncomfortable and identify relevant trainings and/or learning opportunities to grow in these areas.
The below areas are what I consider to be the most important for performance and evaluation. These key areas will be used to gauge your performance and a lot of the feedback you receive will be focused on them.
The Accenture performance review cycle begins late in the summer and culminates in the fall. Shortly after you start we will work together to establish two to three priorities that you can work towards.
Outside of the code we write, the crux of our roles is both written and verbal communication amongst your peers and across groups (dev-to-dev, dev-to-qa, dev-to-ba, etc). Keep in mind these guiding principles for effective communication patterns.
Keep me in the loop. Let me know what’s going on. Keep your team in the loop. Let them know what’s going on. Reach out (to someone) when you need something. Create thoughtful documentation. People in the organization will read and value the content. Contribute to reviewing pull requests.
Your written word is powerful and will persist for far longer than any words that are spoken during calls and meetings. Prioritize concise and thoughtful written “artifacts”.
You can use me as a sounding board for thoughts, problems, ideas, solutions, feedback, etc. I will not always have an answer or silver bullet solution but I can most times help you think through something or point you to another person who can assist.
I am being very clear: you will need help from your peers. Everyone needs help, regardless of their existing system knowledge or tenure. The great thing about this is that everyone has been in your shoes and needed help and they have almost always found someone to help them. Please return the favor when you have attained enough knowledge and enlightenment that others find your information and time valuable.
something that describes our current system(s) and implementation to provide context for the new employee
Please be active in the requisite Teams channels. Please contribute if you have something worth contributing. We have developers in many locations and quick answers to questions in Teams keep everyone moving. We can all share the burden so no single person is overloaded.
Feedback, both from me-to-you and you-to-me, is one of the most critical aspects of our working relationship. I put a lot of thought into my behavior and I want to cultivate habits that increase the quality of my interactions and make it easier for both of us to get things done. Please let me know if there’s something I am doing that is exceptional so I can try to do more of it. Conversely, if there is something that is causing stress or significantly hindering our working relationship then let me know.
You are the only person who knows best what you have been able to complete over the past Accenture fiscal year (September 1st through August 31st). I highly recommend you document and/or track your accomplishments and successes throughout the year. This practice enables you to have a list of these items and are well prepared for the upcoming annual Performance Achievement cycle.
Performance Achievement is a critical aspect of your career at Accenture and is taken seriously. The annual performance review cycle is the method for determining compensation adjustments and promotion opportunities. Monitoring and tracking your “wins” is a hugely beneficial habit for being fully prepared as you enter this event. I will advocate for you during Performance Achievement based on what I know and understand and getting your supporting information is insanely beneficial so I know as much as possible during these discussions.
Performance reviews are critical aspect of your career at Accenture and are taken seriously. I highly recommend you keep track of your accomplishments and successes throughout the year so you have a list of these items and are prepared for when we need to complete our self-assessments. It’s impossible for me to remember everything for everyone (I struggle for just myself!).
I summarize the growth mindset with the following statement: all skills are attainable and cultivable through dedicated and mindful practice.
Sound interesting to you? Read the book on this topic: https://www.amazon.com/Mindset-Psychology-Carol-S-Dweck/dp/0345472322
I truly believe we are in an organization that values the growth mindset. You're going to do well if you have a go-getter attitude and you look at what needs done and start planning and executing. This might be a tough place if you prefer to sit back, lay low, be quiet and do what you're told. It's okay if you prefer the latter but getting ahead requires the former.
Look first to yourself when something goes wrong or sideways or the outcome failed to meet your expectations. You will most often find a few things within your control that could have been done to affect the outcome.
Ownership is:
- Contagious. You will set an amazing example by demonstrating ownership and it will spread to your peers on the team.
- A two-way street. Exhibiting ownership within your team and on your projects will set the standard at a high level. You cannot force another person to adopt the ownership mentality but you can set the expectation.
Do you know why a story was kicked back to you with a bug or because your deliverables failed to meet expectations?
- Did you fully understand the acceptance criteria? If not, did you clarify with the BA/PO?
- Did you demonstrate through Functional Review that the delivery of this story met the BA and testers expectations? If not, how could you be sure the change you made is what was expected?
Build woes when trying to merge your PR?
- Did you run the tests locally? If not, remember the build server is not your personal test runner.
If you truly feel like you exercised all of your power to control the situation and execute; to interface with the necessary parties to get and share information. Then good. The outcome is still sometimes unfavorable despite our best efforts.
If and when something goes wrong, learn from it . By taking ownership of a situation, either good or bad, you are effectively giving yourself the power to deliver an optimal solution or fix the problem.
Technology moves fast and everyone knows that. The tech stack we use at Mortgage Cadence barely scratches the surface versus what’s available in the marketplace. It’s impossible to know everything but it’s incredibly valuable to both yourself as well as the company for our developers to be constantly learning and improving. We understand this requires time, effort and energy to sharpen the blade.
Please set aside two to three hours per week to focus on building career skills. The topics are primarily up to you and your interests but they should be somewhat relevant to your role and project. We can work together to choose topics (if that is helpful) and we can regularly discuss as part of our one on one. Potential topics include (this is not an exhaustive list):
- programming languages
- algorithms
- programming paradigms
- frameworks
- api design (GraphQL)
- data stores (SQL Server, document databases, Redis)
- unit testing
- cloud native (Azure)
- message queues
- writing (yes, actual writing)
- functional areas of the ELC system (pick an unfamiliar area of the system to study and write documentation).
The work we do impacts others in the organization as well as our users. It is our responsibility to verify and prove that our code and database changes update the system in a way that solves the business and/or technical problem.
There are several ways to prove that your code is correct:
- manual testing (deploy your changes and run the app just like a traditional user)
- unit tests (writing test code to actually run your functional code against mocked system dependencies and verify correct outputs
- integration tests (writing test code to actually run your functional code against a full set of system dependencies and verify correct outputs)
- hybrid approach using LINQPad scripts (my personal favorite)
Unit tests and integration tests are run as part of our CI/CD pipeline. Additional documentation is available about the different types of tests we support.
something about in-office vs work from home expectations
Please confirm with me any time off you plan to take via email. How much notice you decide to provide me is up to you. Ensure your work obligations are satisfied and communicate with your team for all time off taken.
Let me know if you’ll be away for more than two hours at a time.This is specifically in case you have a long running appointment, etc. and someone asks me if you’re around.
Communicate with your team in the event of any appointment, absense or time off. Provide your team with as much notice as reasonably possible with upcoming PTO so work can be planned successfully.
At calendar year end, Accenture generally requires employees to take PTO for the time between Christmas and New Years. This is not a strict requirement but you will be asked to take time off if you have over one-hundred-and-twenty hours of PTO available.
- professionally
- planning
- preparing
- learning
- growing
- boring
- company trainings
- timesheets
- pto requests
- ask for what you need
I'll try to follow a sem-ver style of versioning for this document: (major.minor.patch).
- A major version update is a rewrite of this document.
- A minor version update is something changed and is worth reading. i.e. new content.
- A patch version update is fixing a typo, formatting or immaterial re-word of existing content.