1 on 1 Meetings

1 on 1 Meetings

1 on 1 meetings are one of the most important mechanisms for any successful career in tech. As a senior engineer in particular, you will need them to build deep relationships and alignment.

How to Balance Responsibilities: Prioritizing Personal Work vs. 'Glue Work' in a New Team Environment.

Senior Software Engineer at Ex-Apple profile pic
Senior Software Engineer at Ex-Apple

Hello everyone,

As a senior engineer L5 in my company for 1 year, I recently found myself in a new team with a new direct manager but report to the same Director in the same Org due to the recent company restructure/company reorganization as part of layoff changes. My Director and I are the direct responsible individuals for the Backend Platform System for the last 1 year. However, I am finding that a significant portion of my time is being taken up by "glue work," such as onboarding new teammates, updating the Wiki, documenting On-call Runbook, mentoring cross-functional team members, providing code reviews for new developers, and unblocking people in their code development. While these tasks seem important, they are making it difficult for me to focus on my own projects.

In my first one-on-one, my new manager expressed a desire for me to take on new initiatives. I am eager to do so, but I need to be able to focus on my own work to make this possible. My manager understood that the frequent on-call support was a blocker for me and asked me to train and onboard a new teammate to take over the on-call support, as well as field requests from users and help others with their work. However, I have still found myself doing a lot of training and providing support even two weeks since my last meeting.

I would like to hear from others who have found a way to balance these responsibilities effectively. How can I prioritize my own work while still contributing to the team's success? I know this will be a difficult decision, and I'm not sure how to approach it. I'm worried that if I stop doing some of these tasks, it may impact my relationship with my manager and team.

If anyone has faced a similar challenge, I would appreciate hearing about how you approached it. Did you stop doing certain tasks and responsibilities, and if so, how did it affect your relationship with your team? Any advice would be greatly appreciated.

Thank you.

Show more
411 Views
9 Likes
4 Comments
7 months ago

How to effectively onboard and train 20+ engineers for production on-call support?

Anonymous User at Taro Community profile pic
Anonymous User at Taro Community

Hi everyone,

I work for a company that offers online web and mobile apps for US-based customers. As part of a recent re-organization, all mobile, web, and backend engineers have been combined into a single on-call rotation. Even though most of these 20+ engineers (mobile + Web engineers) have not much context about the backend system, my director wants to alleviate the frequent on-call rotation, and he proposes having a healthy size of on-call rotation that uses the "follow the sun" model approach, which involves training engineers in different time zones to have knowledge transfer about the backend system and potential issues. I'm curious to know how I can effectively onboard and train over 20 web and mobile engineers for the on-call rotation while following this model.

The Backend team has compiled a comprehensive support run-book log for each corresponding issue/alert, which shows the severity, priority, and range of the issue. The on-call rotation involves acknowledging alerts and following the steps outlined in the run-book.

Please note that the support run-book is not a 100% comprehensive source of truth since the production system is integrated with multiple 3rd party APIs and systems, and the backend platform serves as middleware for both mobile and web applications. There may be instances where issues are caused by third-party vendors and cannot be solved by the on-call person.

I would love to hear your thoughts and perspectives on this matter. I'm also meeting with my boss for our one-on-one to talk about his idea. This is still an experiment, but would like to get people's perspective. Thank you!

Show more
89 Views
3 Likes
2 Comments
8 months ago

How do I turn SWE roles behaviors/descriptions into concrete actions in a startup environment?

Entry-Level Software Engineer at Series B Startup profile pic
Entry-Level Software Engineer at Series B Startup

Question: "For being promoted from SWE I to SWE II, how do I take the behaviors my company has associated with each role (below) and make that more concrete for a growth plan, taking into account the changing & flexible timelines startups have?"

For context, I already have weekly one-on-ones with my manager (who is new at being a manager & is also my mentor), and a growth plan (that I created with him) that roughly outlines (meets most expectations, meets expectations and exceeds expectations for my role). Additionally, keep in mind I work at a startup w/ <30 people so highly specific concrete goals set on a particular date can change in 2-3 weeks as priorities change. Also, my company has defined a series of behaviors as to what each SWE level should be able to accomplish. Here it is.

Software Engineer I (<1 year - 2 years)

  • Technical Skill
    • Broad knowledge of CS concepts
    • Focus on growing as an engineer, learning existing tools, resources, and processes
  • Getting Stuff Done
    • Develops their productivity skills by learning source control, editors, the build system and other tools as well as testing best practices.
    • Capable of taking well-defined sub-tasks and completing these tasks
  • Impact
    • Developing knowledge of a single component of our architecture
  • Communication & Leadership
    • Effective in communicating status to the team
    • Exhibits company’s core values, focuses on understanding and living these values
    • Accepts feedback graciously and learns from everything they do

Software Engineer II (2-6Years+)

  • Technical Skill
    • Writes correct and clean code with guidance; consistently fellows stated best practices
    • Participates in technical design of features with guidance
    • Rarely makes the same mistake twice, begins to focus on attaining expertise in one or more areas(eg. embedded , testing, algorithm, support code, commlink).
    • Learns quickly and makes steady progress without the need for constant significant feedback from more senior engineers.
  • Getting Stuff Done
    • Makes steady progress on tasks; knows when to ask for help in order to get themselves unblocked.
    • Able to own small-to-medium features from technical design through completion.
    • Capable of prioritizing tasks; avoids getting caught up in unimportant details and endless “bikeshedding”.
  • Impact
    • Self-sufficient in at least one large area of the codebase with a high-level understanding of other components
    • Capable of providing on-call support for their area including systems that they are not familiar with.
  • Communication & Leadership
    • Gives timely, helpful feedback to peers and managers
    • Communicates assumptions and gets clarification on tasks up front to minimize the need for rework.
    • Solicits feedback from others and is eager to find ways to improve
    • Understands how their work fits into the larger project and identifies problems with requirements.
Show more
120 Views
3 Likes
1 Comment
a year ago