Originally posted by Forter.
- Entry-level Software Engineer
- Software Engineer
- Senior Software Engineer
- Staff Software Engineer
- Principal Software Engineer
Impact: self
- Architecture
- Code writing skills
- Tests
- Operations
- Security
- Observability
- Costs optimizations
- Ownership
- Being a Chief
Responsibilities:
- Focus on growth and learning the team's tech stack
- Contribute meaningfully to well scoped problems (with help from others)
- Write clean code and tests; iterate based on feedback
- Participate in code reviews and technical design sessions
- Learn the basics of debugging and the tools used for it
- Know when to pause and ask for help
Examples:
- Deploy a high-quality scoped feature to production (including tests, CR, etc.)
- Investigate and fix an interesting bug in one of the team's systems
Anti-Patterns:
- Not self-motivated; needs someone to tell them what to do next.
- Constantly veers into the weeds.
- Disregards the team processes.
- Forgetting Pull Requests during review (working on other tasks), without it getting to production.
- Working on too many things at once, not getting the important stuff done.
Resources:
- Code Complete (Book)
- Clean Code (Book)
- Refactoring (Book)
- Design reviews
- Project management
- Getting things done
- Communication
- Alignment
- Delivery
Responsibilities:
- Able to deliver well-defined small tasks, holding themselves accountable.
- Makes steady progress on tasks; knows when to ask for help in order to get themselves unblocked.
- Learns relevant tools and resources, while developing their productivity skills.
- Builds effort-estimation skills.
- Seeks input from colleagues with area expertise.
Examples:
- Able to scope a feature in Asana, including tests, monitoring, alerts, code-review and everything else needed to deliver a high quality feature.
Anti-Patterns:
- Moves to writing code too quickly, without first fully scoping the effort/project.
- Avoids raising a flag when stuck in the same problem for too long.
- Fails to communicate needs to colleagues or manger(s).
- Fails to report on progress in a timely manner ("going dark").
Resources:
- Product
- Market understanding
- Precision
- New initiatives
- Scale
- Costs
- Security
Responsibilities:
- Seeks to understand what our product actually solves and how our customers (merchants) interact with it.
- Understands the high-level roles of the different departments at Forter: Ops Analytics, CS, Research, DS, Core Analytics, Engineering.
- Understands and can explain to others (e.g. in our Weekly session) the business impact of their current task.
Examples:
- Completes Forter Academy sessions around non-engineering departments at Forter, and can explain the concepts to others (e.g. their manager).
- Asks questions about how different departments at Forter contribute to the product — either precision or offering.
Anti-Patterns:
- Has a "code-monkey mindset" — knows how to deliver features but cannot explain or doesn't care why they're worth doing.
- Looks "down" on other departments — doesn't understand their work, thus discounting their needs/pains/contributions.
Resources:
- Collaboration
- Knowledge sharing
- Team play
- Communication
- Mentorship and Sponsoring
- Processes
- Continuous improvement
- Recruiting
- Evangelism
- Well-being
- Onboarding experience
- Employees experience & retention
Responsibilities:
- Builds a good relationship with others in the team.
- Able to maximize feedback from more experienced team members.
- Proactively tries to learn from others: takes advantage of the team members' knowledge and experience.
- Learns and understands the team's processes and offers help where possible.
- Good natured attitude: positive, welcoming, open to learn/listen.
- Takes an active part in the company's events and activities.
- Is friendly to others and seeks to get acquainted with people in and outside their group.
- Takes the time to introduce themselves and talk to others.
Examples:
- Captures in writing insights learned from others (e.g. how a system/process in the team work) .
- Offers to join the on-call rotation to learn the team's systems.
- Joins company board-game nights, all-hands meetings, etc.
- Takes special care to get to know someone outside the group.
Anti-Patterns:
- Unwilling to join a team's efforts when not part of the task/project.
- Asks the same questions or demonstrates a lack of knowledge-gathering due to "laziness" (e.g. not writing things after being taught them).
- Has a "lone wolf" attitude — doesn't seek to interact with others, in and outside their team.
Resources:
Impact: team
- Architecture
- Code writing skills
- Tests
- Operations
- Security
- Observability
- Costs optimizations
- Ownership
- Being a Chief
Responsibilities:
- Consistently follows the best coding practices.
- Able to defend technical decisions in Code reviews.
- Writes maintainable code (i.e. code that's easy to read, refactor, add features to, etc).
- Provides helpful, timely code reviews.
- Contributes to technical design, thinking through edge cases.
- Participates in the team's on-call rotation, as applicable to their domain.
- Understands how code fits into a broader technical context.
- Breaks large tasks down into sub-tasks; gives higher-level status updates.
- Has a high-level understanding of Forter's major systems ("system overview").
- Able to participate and contribute to design reviews in near-by scope.
Examples:
- Joins PagerDuty's teams (on-call rotation) for at least 2 services within the team's responsibility.
- Can guide a new team member on working effectively in relevant areas.
- Understands how the team's systems are being tested and deployed via CI/CD pipelines.
Anti-Patterns:
- Fails to identify or communicate big roadblocks.
- Has an us-vs-them attitude.
- Doesn't take operational excellence seriously.
- Provides solutions that are more complicated than necessary.
- Prefers shallow progress over an in-depth understanding of code and context.
- Prefers patching symptoms than mitigating the core issue.
Resources:
- What can developers learn from being on call?
- Excellence Through Code Reviewing
- Release It! (book)
- The Effective Engineer (Book)
- Design reviews
- Project management
- Getting things done
- Communication
- Alignment
- Delivery
Responsibilities:
- Able to work autonomously to estimate and deliver medium to large tasks.
- Masters the ability to break down tasks, plan, estimate, and cut scope in order to ship on time.
- Detects problems in requirements and notifies the relevant stakeholders. Attempts to identify major pitfalls in the project ahead of time.
- Understands how people use the product/service they're building, and is able to adjust accordingly.
- Proactively informs on issues, risks and delays in tasks.
- Able to deliver design reviews for small projects.
- Includes in the project planning/estimation work such as documentation, tests, monitoring, alerts, costs, security considerations, and anything else that is required for maintenance.
Examples:
- Conducts a high quality Design Review (DR) for a 2-3w project.
- Leads the execution of a medium-size project (2-4w) with 1-2 more people in the team.
- Continues to support (as an owner) a project beyond shipping to production (a few weeks after the project is deployed and running).
Anti-Patterns:
- Places blame on project delays elsewhere.
- Gets stuck on unimportant details; doesn't utilize the 80-20 rule.
- Doesn't communicate progress related to the project, whether the lack of progress is due to them or their teammates.
Resources:
- Product
- Market understanding
- Precision
- New initiatives
- Scale
- Costs
- Security
Responsibilities:
- Understands the role of the team in the larger business context.
- Initiates ideas affecting the team, explaining their urgency or priority with business justifications.
- Begins to understand the pains of other teams around them (immediate internal customers).
- Has a basic understanding of where Forter fits in the eCommerce world: what is our complete offering (not only TX decisions), our differentiators vs. competitors, etc.
- Deepens their understanding of the high level roles of the teams in their department
Examples:
- Completes and understands well Forter Academy sessions on Market Competitive Analysis and Product Offering.
- Can clearly explain to others (e.g. new employees) not only Core Analytics role but also what's Velocity team's responsibility is versus Person Attribute.
- Knows, at least on a high level, how their team's systems impact the business (e.g. enabling others, directly affecting precision/offering).
Anti-Patterns:
- Promotes ideas with purely technical merit, discounting business justifications. Makes it hard to support their ideas.
- Doesn't consider or verifies costs when suggesting new ideas.
Resources:
- Collaboration
- Knowledge sharing
- Team play
- Communication
- Mentorship and Sponsoring
- Processes
- Continuous improvement
- Recruiting
- Evangelism
- Well-being
- Onboarding experience
- Employees experience & retention
Responsibilities:
- Understand the different roles each individual in the team has. Points to areas with a clear vacuum (lack of owner or knowledge).
- Onboards new teammates.
- Takes an active part in the team's day-to-day operations (on-call, urgent production issues on Slack, etc.)
- Demonstrates concern for the team's well-being. Personally tries to help people around them.
- Able to communicate early teammates' issues to their direct manager
- Understands the importance of having hard conversations with their peers, to provide and receive useful and authentic feedback.
- Asks for feedback from others to continuously improve, both in craft and team work. Doesn't wait only for DRs/PRs to collect that feedback.
- Willingly shares domain knowledge with other teams.
Examples:
- Helps to promote the company on social media (in an authentic way).
- Spots that one of the team members is not feeling great about their progress or an assignment, tries to be friendly and assists with resolving it. If necessary, suggest talking with the direct manager.
- Tries to see if there are emergent patterns in the team, and reflect on those to the direct manager in order to verify we're working on resolving them.
- Able to clearly provide useful code-review comments. If spots a pattern, can articulate it f2f, to share higher-level feedback ("it's not only this PR, it's also a pattern that shows ...")
- Builds a short Python course for analysts.
- Promotes a job opening in the company on LinkedIn.
Anti-Patterns:
- Feels comfortable with not taking a fair share of the team's operations (or any other burden).
- Talks behind teammates' backs instead of trying to resolve issues directly.
- Difficult to work with due to the "high tax" people need to pay to provide feedback: always argues instead of asking more questions, not taking responsibility, etc.
Resources:
Impact: team
- Architecture
- Code writing skills
- Tests
- Operations
- Security
- Observability
- Costs optimizations
- Ownership
- Being a Chief
Responsibilities:
- Expert in our processes, while also helping to define and improve them.
- Writes meaningful code reviews.
- Makes well-reasoned design decisions, identifying potential issues, trade-offs, risks, and appropriate levels of abstraction.
- Proficient in all relevant technical skills, and able to move quickly due to a deep understanding of large portions of the code base (cross teams).
- Maintains awareness of industry trends and tools.
- Debugs expertly within their primary focus area.
- Writes tech specs and identifies risks before starting major projects.
- Sets technical standards for the team.
- Goes out of their way to reduce complexity within the team's systems.
- Become a Chief of at least one of the team's primary systems.
- As a Chief of a system, defines and drives the roadmap / vision for that system.
- Produces high-quality BetterNexts from production incidents (or interesting wins).
- Takes Security and Cost (cloud resources & time investment) into considerations when designing a technical solution.
Examples:
- During a code-review, able to supplement comments with links to relevant resources or other examples, and thus instructing the code committer.
- Offers a quarterly roadmap of the system of which they are a Chief.
- Can reason about "buy vs. build" when promoting technical initiatives (i.e. should we build a solution ourselves or buy an existing one).
Anti-Patterns:
- Doesn't delegate. Always says “yes” and suffers from burn-out or continuous loss of focus.
- Lets details slip through the cracks.
- Over-emphasizes scaling or high availability far beyond the requirements (project/business needs).
- Prefers local solutions to more global problems, especially if a problem is an obvious issue to multiple teams.
Resources:
- On Being A Senior Engineer
- Design Docs at Google
- Patterns of Enterprise Application Architecture (Book)
- Working Effectively with Legacy Code (Book)
- Design reviews
- Project management
- Getting things done
- Communication
- Alignment
- Delivery
Responsibilities:
- Able to take ownership to lead and deliver large projects (>4w of work) that spans multiple systems, with support from peers.
- When acting as the Project Lead on a project, communicates progress to stakeholders and ensures alignment.
- Persistent in the face of roadblocks; dispatches them efficiently, pulling in others as necessary.
- Scopes and stages work into well-defined milestones to avoid a monolithic deliverable.
- Accountable end-to-end, through planning, development, deploy, monitoring and maintenance.
- Sets realistic deadlines, estimating methodically based on iterative learning.
- Able to question and push back on tasks/requirements.
- Able to reduce complexity and prioritize in alignment with company goals.
- Handles well open-ended problems and ambiguity.
- Suggests steps to mitigate impact of delays in projects.
- Requires minimal direction / oversight.
- Ensures projects don't lose momentum.
- Delivers design reviews for complex projects.
- Seeks empirical validation through PoCs, tests and research.
Examples:
- Able to separate requirements/pains from the solution, and, if needed, agree on the former before the latter. Avoids coming up with a solution that many people will think solves the wrong requirement (or are confused due to not knowing what the requirements are).
- Leads a Design Review of a fairly large project (more than 6 weeks of engineering time).
- Mitigates risks of a complex DR which requires a new technology or uses a new capability, by doing proper research as part of the DR process: e.g. running a small-scale PoC to validate a risk/concern that might affect the DR.
- Gets buy-in from other lead developers before presenting a DR to a wider audience.
Anti-Patterns:
- Rushes to work on the solution before gathering and understanding business/analytical/technical needs.
- Doesn't clearly state the risks in the project and how they will be mitigated.
- Unable to lead other teammates in the project. Has problems with e.g. delegation, tasks assignment, solving roadblocks, communications around progress, etc.
- Doesn't push back (and provides alternatives and justifications) on requirements that might add risk, add a lot of time to the project or make it extremely hard to maintain it in the long run.
Resources:
- Stepping Stones not Milestones
- No Kings: How Do You Make Good Decisions Efficiently in a Flat Organization?
- Product
- Market understanding
- Precision
- New initiatives
- Scale
- Costs
- Security
Responsibilities:
- Understands well the pains of other teams around them (first circle / immediate internal customers)
- Proactively seeks to talk with internal customers to understand their pains and how the team can serve them better
- Can clearly document and share their insights and suggestions from talking with other teams, so the team can learn from it and initiate ideas around it - some will be solved within the team, some will be given as feedback to other teams.
- Takes an interest in Forter's business performance: understand our ARR, how margins affect the business (covered vs. uncovered), knows the big logos we sold to, etc.
- Understands the roles of all the departments at Forter, with focus on the sales pipeline, with good understanding their responsibilities, where they influence as part of the sales cycle, etc.
- Takes costs, security and other business impacting aspects into consideration, e.g. when suggesting new initiatives, as part of DRs, etc.
Examples:
- Can draw on a whiteboard the systems involved in Forter's precision mechanisms (e.g. VT, AxTx, Attributes, Velocity, Models, Decision Manager, etc.)
- Can explain (high level) the full cycle of selling Forter to a customer: marketing (generating a lead), pre-sale, sale, onboarding (CS/Ops) and serving the customer for the long run.
- Shares a document with the team, and other relevant teams, around information they got from their internal customers. With well-crafted summary of the biggest pains (with priorities), relevant suggestions (with high level cost/estimation and gain from that), and basic priorities as they see fit (with business justification).
Anti-Patterns:
- Doesn't spend enough time to document proper pains & suggestions, keeping it all in their heads and relying only on their memory.
- Spends too much of their time focusing on the team and the team's needs, instead of trying to increase their impact circle with other teams around them.
Resources:
- Collaboration
- Knowledge sharing
- Team play
- Communication
- Mentorship and Sponsoring
- Processes
- Continuous improvement
- Recruiting
- Evangelism
- Well-being
- Onboarding experience
- Employees experience & retention
Responsibilities:
- Brings their unique talent to improve employee experience (consults with HR / team's manager to look for areas of pain).
- Shows willingness to mentor less experienced teammates, either in technical or execution skills (e.g. communication, buy-in, task management etc.)
- Sponsors a less experienced team member with their direct manager. Helps them to take on more challenging tasks, step outside of their comfort zone and build their confidence.
- Has a significant role in the team's operational excellence: production issues, knowledge capturing and sharing, providing context to others.
- Helps to create and promote visibility of the team's achievements in the group/company.
- Can act as the team's point of contact in various discussions — has both the EQ, know-how and tech skills to take commitments, figure out open questions and, above all, take ownership (or at least drive to a resolution).
- Plays a part in the recruiting process: assists with the hiring process, crafting a Job Description, recommending missing skills that the team needs (to manager), etc.
- Helps to build Forter's external brand by leading or assisting the effort (e.g. write a blog post or review one by a team member, provide feedback on others' efforts).
- Consistently shares information that can enrich others' knowledge and skills.
- Able and willing to notice and alert relevant engineers/managers to a lack of proper documentation (FAQ, Q&A or more in-depth), or over-reliance people's memories.
- Reduces organizational memory by committing knowledge to writing, and sharing it with the team/group.
Examples:
- Improves the developer experience by creating tools that would reduce tedious work.
- Come up with hackathon swag for all of the Forter employees.
- Sets up a fun team event.
- Provides evidence (specific PR links, Asana links, etc.) when trying to sponsor a less experienced team member to their manager.
- Sends an email to the group with an interesting milestone for the team (why it's important, what does it mean for us, etc.) Even better — helps someone else to write such an email, so they'll get the credit for it.
- Reviews blog posts written by others; recommends topics to write about; writes blog posts to cover interesting aspects of the team's challenges.
- Suggests new ideas or content for https://forter.dev/ or our technical blog https://tech.forter.com/ .
- Joins #rnd-reading and shares interesting blog posts / videos with takeaways worth noticing.
- Writes posts in our Knowledge Base system on solving problems that many people deal with (e.g. CI issue, or how to use a tool).
- Writes a System Overview and a Developer Handbook for the systems they own.
Anti-Patterns:
- Unwilling to bend to the team's needs. Focuses only on the ideal ("pure") solution and neglecting adoption and other considerations.
- Talks down to people, making them feel insecure.
- Takes credit for work done in cooperation with others (especially less experienced team members).
Resources:
- Being glue
- The Hidden Costs That Engineers Ignore
- How to Have Impossible Conversations (Book)
- A Guide to Mindful Communication in Code Reviews
Impact: teams
- Architecture
- Code writing skills
- Tests
- Operations
- Security
- Observability
- Costs optimizations
- Ownership
- Being a Chief
Responsibilities:
- Focused on technical decision making, leading work that affects one or more complex systems and mission-critical areas.
- Consistently delivers code that sets the standard for quality and maintainability.
- Has a broad understanding of our architecture and how their domain fits within it.
- Systematically thinks through potential design impacts on other teams and the company.
- Go-to expert in an area, with an increasingly strategic mindset.
- Explores 3rd party vendors and new technologies with a sizable potential impact on the company.
- Proactively offers ways to optimize the team's systems for costs saving, scale and operational stability.
- Constantly keeps in mind the company's security orientation (preferences, requirements, current tools, certifications) when designing and building systems.
- Controlling security permissions (saying no when needed) within the team, to reduce attack surface
Examples:
- Integrates a new monitoring solution, including the understanding of the business needs, gathering of requirements/pains, getting buy-in, performing a DR, educating the users, and leading the execution end to end. Post-production measures impact and satisfaction.
- Leads a cross-teams effort of documentation standardization.
- Leads a conversation and implementation around shared libraries across teams.
- Leads a conversation and implementation around how we develop in a specific language (tooling, dev experience, best practices, etc.)
- Migrates a huge project of ours to use a newer technology stack that will help increase our engineering velocity.
Anti-Patterns:
- Forces their opinion (potentially abusing their "title") without giving enough attention to tradeoffs and hearing others.
- Focuses only on 1-2 teams or areas, instead of looking at the bigger picture (long-term horizon).
- Gives up too quickly when trying to convince people (e.g. multiple teams, many opinions) due to high friction.
- Falls in love with the solution instead of the problem. Cannot adopt others' opinions and execute on them.
- Builds solutions that are too “short-term” oriented or not robust enough. This is usually due to not enriching the requirements enough - or not providing the proper solutions.
Resources:
- Design reviews
- Project management
- Getting things done
- Communication
- Alignment
- Delivery
Responsibilities:
- Able to plan and execute large projects with complex requirements and inter-dependencies across teams and systems.
- Consistently delivers on-time and at a high level of quality.
- Defines key metrics and measures the project's impact.
- Consistently able to reduce the complexity of projects in order to get more benefit with less work.
- Contributes to all major architectural decisions and reads all tech specs within their domain. Tracks status and considers implications for other systems.
- Enables more junior engineers to take a leading role in designing solutions, by helping them understand requirements and organizational context.
- Able to effectively prioritize their own workload and focus across many streams of work.
- Markets and advertises projects. Creates excitement for users and driving adoption.
- Helps define roadmaps and set visions for long-term projects.
- Works closely with relevant Product Managers to gain context and understand business needs. Able to then represent the business/product in future meetings with their teammates.
Examples:
- Able to explain a project's business impact ("why do we do this?") and trade offs to a wide audience. Builds decision making context for others
- Knows how to utilize meetings effectively (e.g. status meetings, daily, weekly sync) to drive project momentum and keep everyone aligned.
- Acts as a single-point-of-contact in the organization for a project. Doesn't require multiple managers to be involved in understanding the project's progress/status.
Anti-Patterns:
- Struggles to raise flags and find alternative solutions when a teammate or a dependency is not keeping up, either in terms of quality or availability.
- Avoids confrontations: struggles to resolve disagreements, explicitly stating their needs, etc.
- Tries to achieve too many things on their own, instead of relying on others around them: either by asking help or delegating tasks.
- Inadvertently suppresses innovation by other engineers, for example by giving their own ideas first and loudest, criticizing without truly listening to new ideas or by giving the impression that there is only one right solution to a problem.
Resources:
- Design it! From programmer to software architect (Book)
- Leading without Authority (Book)
- System Design Cheat-sheet
- Product
- Market understanding
- Precision
- New initiatives
- Scale
- Costs
- Security
Responsibilities:
- Understands the yearly goals and main projects of many of the group's teams, including their business impact.
- Aware of yearly organizational growth (e.g. new headcount) within the group, aimed at supporting business needs.
- Can clearly articulate and explain to others (e.g. new or less experienced ICs) the motivation and business needs of our main systems.
- Can lead one of the main pillars in the group and become a point-of-contact for it when talking with others (e.g. product offering, scale, costs, security, precision, etc.)
- Continually involved in the team's backlog grooming — helps the direct manager to balance tech debt, areas worth to invest in, areas where we should de-risk/mitigate potential threats, etc.
Examples:
- Leads the group's FinOps effort: tracking expenses, creating visibility, suggesting new ideas to cut costs, getting the buy-in, executing, reporting progress to the entire group, etc.
- VPs (VP Precision, VP Ops, VP Product, etc.) in the org feel the need to invite them to relevant meetings, instead of inviting their direct manager. The IC is the point-of-contact, and we don't need managers in every conversation.
- Takes an active part in quarterly planning — suggests areas that are worth investing in, helps with high level estimations, consults on priorities (with good reasoning behind them).
Anti-Patterns:
- Lets things live in a "limbo" for complicated domains (where ownership is a bit fluid). Is passive or unclear about time estimations, or makes excuses on why we've reached this state.
- Doesn't create momentum in areas they lead: waits for someone else to pick it up for them (e.g. their manager).
- Acts as an owner (design & decision making) but avoids the responsibility that comes with it (i.e. continuously supporting and pushing it forward).
Resources:
- Collaboration
- Knowledge sharing
- Team play
- Communication
- Mentorship and Sponsoring
- Processes
- Continuous improvement
- Recruiting
- Evangelism
- Well-being
- Onboarding experience
- Employees experience & retention
Responsibilities:
- Strives to become a "Bar Raiser" for the team (see resource below)
- Can suggest big changes to the way the team works by collecting feedback internal customers, or by adopting good practices from other teams.
- Able to represent the team's interest in larger discussions.
- Able to detect a vacuum that the team can pick up and increase their ownership, and thus impact.
- Comes up with ideas for processes the team needs to add to support future growth or current pains/needs. Leads their buy-in and adoption.
- Can act as a backup for the team's manager in various discussions and assisting team members.
- Understands well the team's problems and is able to take ownership by constantly trying to improve them.
- Has a significant role in recruiting talent. Consistently interviews potential hires.
- Can be an evangelist for the company in events.
- Improves the recruiting process by avoiding waste, reducing false positive (bad hires) and false negatives (hires we should have done).
- Show willingness to mentor experienced engineers in the group.
- Improves or creates documentation on important processes (e.g. write Better Nexts, conducting Design or Code Reviews, leading a Project, etc.)
- Mentors those that take part in the hiring process, striving to improve the quality of the interview: proposes questions to ask, pitfalls to avoid, things to look for in candidates, summarizing an interview, etc.
Examples:
- Improves the team's process and tools for dealing with tickets.
- Has the maturity to pick up and lead a high-impact project that no one else wants to lead (e.g. due to friction of different opinions, a lot of legacy code, etc.)
- Proposes tools and processes for using common libraries in the company, even if the owner is in a different team (e.g. forter-X package in python).
- Takes the time to understand and improve processes when internal customers complain about them. Able to provide some options on the spot, to see if they solve the majority of the problem. Summarizes the feedback internally to create visibility and suggest improvements.
- Can suggest questions we should use in different phases of the interview process (including "good answers" and "bad answers").
- Prepares home assignments for interviews.
- Prepares onboarding resources for new or less experienced employees.
- Able to provide a well-crafted (concise, clear) document with relevant pains and requirements to someone working on a DR in a related area (e.g. a new tool that the team will use on daily basis, or one that has production implications).
- Able to join a meeting instead of the team's manager. Has the context and confidence to provide answers on the spot; can take notes on open questions (and get them resolved quickly); has the trust and confidence of other members in the meeting.
Anti-Patterns:
- Only concerned with delivery without considering the pains and needs of the team. Doesn't invest time to discuss areas of pain with the team's manager. Doesn't think about increasing the team's velocity or happiness.
- Demonstrates immaturity when speaking about the team's process, tools or problems with other teams or people outside of the organization. Is a judge and a (gossip) reporter instead of an owner.
- Too quick to rule out ideas or suggestions, without coming up with well-thought alternatives.
Resources:
- Amazon's Current Employees Raise the Bar for New Hires
- Lessons from Keith Rabois Essay 5: How to Become a Magnet for Talent and Assess Talent
- 6 Lessons I learned while implementing technical RFCs as a decision making tool
- Organizational Debt is like Technical debt - but worse
Impact: group/groups/company
- Architecture
- Code writing skills
- Tests
- Operations
- Security
- Observability
- Costs optimizations
- Ownership
- Being a Chief
Responsibilities:
- Act as the last line of defense - Persistently debugs the toughest issues throughout the entire stack, regardless of the environment. Finds the root cause or a viable workaround when others are unable to do so.
- Incredibly knowledgeable both inside and outside of the company in their area(s) of expertise.
- Is the primary expert in multiple areas of our stack; deeply knowledgeable in several domains.
- Owns (as a Forter Chief) cross-team shared infrastructure.
- Leads large (multi-year engineering effort) and complicated cross-teams/groups architecture changes.
- Helps the Security team by participating in the company's Risk Analysis. Provides useful insights on topics such as PII, change management, vulnerabilities, SSH/VPN access, Disaster Recovery, etc.
Examples:
- Leads a multi-year engineering effort such as Multi-region/cloud transition and support.
- Leads a successful adoption of a system (high impact on day to day development and ops) that will drastically change the way everyone in the group (or groups) works.
Anti-Patterns:
- Acts only from a technical viewpoint, without considering the business needs or needed impact, e.g. comes up with suggestions that might not be relevant for the company in the next 12-18 months.
- Doesn't invest time to come up with concrete vision and ideas for improving the way we work.
- Focuses only on R&D, without trying to understand the impact on other groups (where applicable).
Resources:
- Undervalued Software Engineering Skills: Writing Well
- Some Thoughts on the Principal Role
- The SaaS CTO Security Checklist
- Design reviews
- Project management
- Getting things done
- Communication
- Alignment
- Delivery
Responsibilities:
- Able to succinctly explain to management the project's goals, KPIs and milestones at the right level of abstraction.
- Able to successfully plan and deliver complex, multi team/system, long-term projects, including ones with external dependencies.
- Is the go-to person on company-wide critical projects or initiatives.
- Creates a compelling technical vision with a company-level impact, anticipating future needs.
- Is a role-model for balancing product and engineering concerns/risks and mitigations.
- Initiates new projects: creates buy-in, drives delivery and adoption.
- Demonstrates great skills in project/time/energy management on multi-months projects, while keeping high momentum.
- Able to organize and lead a large group of people from multiple teams/groups when working on a project.
Examples:
- Deals well with high friction as a result of cross-cutting concern, by motivating and energizing themselves and others.
- Able to distill large amounts of concerns/feedback into well defined actionable items, while solving the actual business needs of the project.
- Respectfully and clearly explains why certain concerns or suggestions will not be done as a part of the project (due trade-offs of time/value/risk).
Anti-Patterns:
- Lets friction (disagreements, unclear requirements) stall the project and kill momentum for the team that works on it. Doesn't lead others well, leaving them feeling lost and unsure of what needs to be done.
- Avoids presenting dilemmas, trade-offs and taking an active part in making a decision in a timely manner. Waits for others to make the decision.
Resources:
- Hitting the right level of abstraction
- Making Engineering Team Communication Clearer, Faster, Better
- Product
- Market understanding
- Precision
- New initiatives
- Scale
- Costs
- Security
Responsibilities:
- Understands the yearly business goals, using those to define the main projects the group should invest in during the year.
- As a leader of a main effort at Forter, can represent it to management and outside of Forter (customers, press/media, conferences, etc.)
- Continuously involved in the group's backlog grooming — helps various managers to balance tech debt, areas worth investing in, areas where we should de-risk/mitigate potential threats, etc.
- Provides feedback to extended managements (VP level and above) on things that might impose risk, ideas for better offering/precision/security/scale, etc. Has a seat at the table when it comes to such conversations.
Examples:
- Puts healthy pressure on management (VP level and above) to promote big ideas that are strategic to the company.
- Involved in quarterly planning of the group, relying on business needs. Can consult multiple Team Leaders. Note: might need a different planning process (and maybe more people / structure) to enable that.
Anti-Patterns:
- Struggles to build good working relationships with the Team and Tech Leaders in the group, impacting their ability to initiate cross-team projects.
- Unable to translate their vast tech knowledge to the managerial level, making it harder for management to understand their value or why they should have a seat at the table.
Resources:
- Scaling a Technology Business is About Unscaling Technical Debt
- Shape Up - Stop Running in Circles and Ship Work that Matters
- Collaboration
- Knowledge sharing
- Team play
- Communication
- Mentorship and Sponsoring
- Processes
- Continuous improvement
- Recruiting
- Evangelism
- Well-being
- Onboarding experience
- Employees experience & retention
Responsibilities:
- Promotes (by getting buy-in) successful processes from on the group level (or at least in multiple teams).
- Creates opportunities for others to shine, by helping them identify areas we can afford to innovate and take risks for potentially great rewards.
- Can act as a mentor for other experienced engineers in the team, or recommend them for mentors outside of the team (or even company). Either in a specific skill/technology, or more broadly around how they promote their ideas and projects.
- Takes a proactive role in showcasing the team's strengths and achievements. Able to represent them within the company (e.g. All Hands, or Extended Management sessions) or outside of it (e.g. conferences, blog posts).
- Plays an integral part in the recruiting process for multiple teams (as a "Bar Raiser") — has a clear process and is able to provide clear feedback on candidates (biases-aware, strong examples, etc.)
- Can "sell" the company extremely well to potential hires.
- Consistently reduces organizational memory by producing high-quality knowledge capturing (docs, lectures, arch topics) around the most critical parts of the system.
- Acts as a role model when promoting new initiatives for technologies or processes — can create buy-in, produce high quality content around it and implement the idea end to end.
- Acts as a leader around building an external brand for the company: takes time to work on blog posts, lectures, open-source projects or anything else that might help us attract talent.
Examples:
- Perceived as a true believer in the company's mission and talent when talking with others outside of the company.
- Creates momentum by writing proper documentation ("documentation spike/blitz") in areas that desperately need it. Writes a few docs and convinces others to join. Announces it to others and proactively seeks feedback on that.
- Offers an experienced engineer to work together to help them improve a skill.
- Presents a big accomplishment of the team in an All-hands meeting.
- Contributes to Reading Material for a new Forter Engineer
- Affects in a meaningful way the KPI of "did you hear about Forter" (i.e. improves the chances that people will say "Yes! I've heard a talk by X or read a blog post by Y that was fantastic..")
- Contributes to https://forter.dev/teams/ pages to better attract talent.
Anti-Patterns:
- Only focuses on the pains of the group, while neglecting the needs of the team, which might lead to resentment by the teammates.
- Is passive about promoting the team members and achievements to the group or company.
- Creates the impression that big innovative new ideas should only come from Principal Engineers.
- Constantly fails to get buy-in for new initiatives due to lack of proper reasoning behind them (technical and/or business needs). Relies too much on their title.
- Become numb to problems because we've been living with them for a long time. Convinces themselves that there's no real problem there.
Resources: