What makes a senior engineer at Redgate?
At Redgate, we’ve always had a very flat organizational structure. This has meant that progression at Redgate can seem unclear. To try and make this clearer we did some work within the Division to try and define what being a senior engineer really means.
So here’s what we think being a Senior Engineer means at Redgate.
Being a senior engineer at Redgate has many dimensions. It’s not just about having a strong set of technical skills, or about time served, you have to be doing more than just being a good engineer, you must become a force multiplier. That means not just doing your own work well but enabling others to learn from your skills and experience so they can then deliver more value, more rapidly, and more consistently.
A senior engineer will be consistently doing / exhibiting most of the points below.
Attitude / Approach
Role Model — Understand being a senior engineer makes them a role model. As a senior, you’re expected to communicate within and outside of your team and the product division and therefore expected to always behave appropriately. This means consistently doing all the things listed in this document.
Growth Mindset — Always looking for ways to improve.
Positivity — Approaching challenges in an optimistic way, doesn’t give up at the first hurdle but is focused on the next improvement to make. Isn’t daunted by the scale of a problem.
Proactive — Taking steps to address problems before they occur. Don’t wait to be asked / directed but explain what they intend to do. Consider coaching others during this period.
Technical Skills
Good engineering — has both breadth and depth of experience with several technologies used at Redgate. Knows when to use which ones. Has the experience to learn and quickly get productive with new technology.
Architecture and design — experience of designing and implementing clean, simple architectures that work. Has battle scars from designs that didn’t work and can explain the issues and how they could have been improved.
Problem Solver — Solves gnarly issues, doesn’t give up at the first hurdle. Will use experts from other teams / externally as appropriate. Has excellent diagnostic and debugging skills and an approach that can be applied successfully to areas of code they are unfamiliar with.
Reviewing — Provides constructive reviews of others designs and code, spots what’s missing as well as reviewing what’s there, clearly explains why they’ve made certain recommendations. Can judge what’s important to change and what could be considered a matter of style.
Technologist — applies the growth mindset to technology, doesn’t just chase the latest trend but is always looking for ideas and approaches that can take engineering teams to the next level. Experience of successfully introducing these into teams.
Code Comprehension — Can independently navigate within a large, undocumented, codebase, without necessarily requiring direction. Knows and embraces techniques to finds the interesting places to look at inside an unfamiliar codebase
Domain expertise — They have expertise in a specific domain.
Growing others
Mentor / Coach / Teach — Proactively supports the development of others on the team.
Coding Guidance — To develop and champion simple and maintainable code across Redgate. E.g.helping define and shape Redgate’s coding guidelines.
Community Contribution — regularly contributes to Open space events, guild events, coding katas, Lightning Talks etc.
Share — Shares experience with others, this could be just in conversation, via community events or by contributing to Architectural Decisions.
Team Player
Empathy — recognizes the feelings of others and adapts approach accordingly.
Great Collaborator — Be the person others want to work with. Consider how much of any task you lead and be shared.
Clear Communicator — Able to share opinions with others. Adapts style and level of information to the audience. Can explain complex technical issues to non-technical people in a way that can be understood. Communicates with roles outside of the immediate team.
Listening to others — Uses active listening to truly understand others point of view.
Strong opinions; weakly held — Always prepared to offer an opinion on what should be done, and why, but is willing to change direction based on other ideas or new evidence.
Disagree and Commit — Able to get behind decisions even if disagreed with. Never disagree and continue.
Accountable
Deputizing for Tech Lead — either individual meetings or for longer periods of time during holidays or sabbaticals.
Leads significant pieces of work — including clarifying requirements, facilitating meetings, breaking tasks down, checking progress with other team members etc.
Completer — can be relied upon to complete what they start. Gets things done.
Contribution — To technical processes such as the Tech Radar and Architecture Decisions.
Outcome Focused — helps the team get to the objective rather than getting stuck on the small day to day things.
