Things to consider: What size is your company? How big is this Director's org? Is the arrangement temporary or permanent? Are you going to be the most senior engineer in their org? Is the Director hands-on or mostly focussed on business strategy and execution?

The following answer is general; I'll be happy to refine it based on your specific situation.

Yes, a fair bit changes!

A Director will have lot less time for you in many ways: to onboard you, to assign you work, to keep tabs on what and how you're doing, and to give you advice and advocate for you. At the same time, their view of the org and problems to be solved with me much larger than a typical Engineering Manager or Senior EM.

So, you'll need to deliver value more independently. You'll need to communicate differently—in a way they can understand and get interested in. There's a lot to say here, but **communicating the what and why would be much more important than the how**.

The Director will have a lot less time to "listen" and troubleshoot things for you. So, any interpersonal issues, stalled projects, differences in opinions, etc. will need to be handled by you. **Bring the problems + how you solved them to the Director, and not just the problems.** 

**Build a support system aside from him but within the company that can act as a sounding board and guide you, if needed.**

If you're going to be the only most senior engineer under them or one of the most senior engineers, consider it fair game that **they will look to you to solve technical challenges and for advice on technical matters in their *entire* org**. This usually comes with rapid context switching, exposure to technical breadth, and interpersonal skills to advocate for the solutions you deem right—now we're getting into Staff territory without the official title plus a lot of influence without authority.

I don't mean to scare you because this is everything that *can* happen but won't necessarily happen all at once or ever. :) I'd meet with them earnestly to clarify their expectations of you along the lines mentioned in my answer.

Remember, these transitions can open up huge opportunities for you, esp. since you're already senior! Good luck, and feel free to ask follow up questions. I am excited at this expansion of your horizon!

Mentor Coach for SWEs | Former Staff Software engineer

Shine Garg

This is vulnerable and it's extra hard in this job market. Thank you for opening up.

First, there's nothing wrong with looking for a chill company and doing enough to earn your keep. You're ahead of those who don't want to do even that much and just want a paycheck somehow. Hopefully this gives you some confidence.

What is your plan to avoid getting into a perf-related layoff again? I think reflecting on this is as important as choosing what offer to accept.

I'd start by identifying the recurring patterns in your bad perf reviews. What are your peers and managers saying about you in those reviews? 

In your own assessment of your work, where do you see gaps between how you operate vs. how an average performer on the team operates? Have you thought of enlisting a buddy on your team who is 1-2 steps ahead of you and can provide you with feedback and measurable interventions? 

You're being prudent by choosing a "safe" place to land, and please don't disregard the importance of ensuring your safety there!

I personally think data engineering experience is worth having as long as it's legit DE, like Sai said.

Unlike full stack (which comprises of the vast field of backend engineering), DE is more "contained". It becomes increasingly hard to develop **breadth** in BE as you progress in your career because of the vastness of the field. 

DE is easier to be an expert in. :) The complexity in DE is also lower since a lot of cloud-provider services are available as "lego blocks" to orchestrate pipelines. There are fewer technical concerns such as memory management, threading, etc. 

DE is here to stay and it's actively evolving. A lot of DE engineers today are not necessarily well-versed in strong "software engineering" skills, so you can bring a lot of technical excellence to the DE team. 

Together with DE and ML, you develop a rare understanding of software engineering *and how software at the company-level works*—I have personally benefitted from being in this position!

If you try out DE only for a while, you won't be siloed away from SE. Depending on the lay of the land at your workplace, you might position yourself as an asset! Going forward, you'll likely have a choice to interview for either role and regardless of which you take, you will have a clear edge over those who know only one or the other.

Check out <https://www.deeplearning.ai> as well.

Are you talking about your LinkedIn profile or posts?

The responses seem to be in the context of posts, but your examples appear more relevant to the profile. :)

I wouldn't add them to the profile, the same way I wouldn't add them to the resume. They're OK in posts, esp. when not spammy to add visual elements in the absence of being able to format text otherwise.

On your resume, you could say: "Co-led the migration of X to achieve Y", like Alex suggested, or even "Significant contributor to..."

In the actual interview, I'd focus on the pieces you designed, the migration plan you created, *and the impact it delivered toward the larger project*. I think it's less relevant whether you were the tech lead or the right hand of the tech lead. 

What's much more relevant is the **business importance** and **technical complexity** of the pieces you owned and how they helped the larger project move along. 

"The larger project needed X because...

It required many design decisions, a migration plan, and a series of steps were necessary to achieve it. The team composition was Y (split of senior/junior engineers).

I helped the tech lead design the new replacement in A, B, C ways. Get into the weeds of A, B, C to illustrate why they were important to the design. If the TL missed them or there was a difference in opinion between the two of you and your approach was better, highlight that. If the TL delegated it to you or you were more familiar with those parts, highlight that."

Follow the same script to describe your contributions to the migration plan and the smaller projects you led. Bonus points if you can put some numbers on these: $ impact on the business because of revenue or engineering time saved or future product potential unlocked, N gigs of data moved, %age efficiency achieved, whatever."

Give specific examples of how you mentored the junior engineers. What behavior were they exhibiting before vs after your mentorship? 

You can also give examples of how the TL and the other senior engineers relied on you and why.

If you helped resolve any conflicts along the way or facilitated stalled conversations/progress, highlight that.

Thinking along these lines should help you craft a compelling narrative. Feel free to follow up with more questions.

A few other angles to consider are:

1. **What skills do you want to develop?** If you plan to continue working in this domain, what team would be best positioned to help you gain domain and business knowledge that will make you an expert in this field over time?
2. **What's on-call like (or WLB)?** For example, the accounting or integrations teams *might* have a busier pager than 1, 3, and 5.
3. **How do you want to spend your work day?** What percentages of time do you want to spend to solve deep technical problems, mentor others, give a direction to the team, etc? Getting clear on this pie chart can make the identification easier.

If all the choices score close to each other, a good front-line manager (Rahul's answer) and healthy team dynamics (Alex's input) are excellent tie-breakers!

This is an incredible question!

Today, you're making decisions in software design, tomorrow they will be about large system architectures, and some day perhaps business decisions. Not to mention the countless life decisions we need to make along the way. 

Making decisions that are *almost* always 'right' is a key skill and it can play a big role in determining our life trajectory. It comes with experience, but you can fast track it by asking on forums like these.

On the **tactical front**, I'd identify the desired outcome and use that to reverse-engineer the properties of the desired system.

For example, for the database schema, write the down the queries you need to run and let that inform the schema. 

For websocket libraries, identify your current and projected need for latency/throughput and devex to make a list of the properties the library must have. Then it becomes a matter of sifting through the docs to identify the right candidates quickly.

This approach will keep you from going down rabbit holes to identify the "best" candidates that might have features you don't care for.

The **deeper answer** is to have an easier relationship with "best." :) 

By nature, all software requirements are not understood ahead of time. So, we will be wrong from time to time—and it's not a personal failure or lack of diligence. Researching too deeply comes with the additional cost of indecision and burnout, and yields diminishing returns with time spent. 

Working backwards from the identified properties will enable you to balance "best" with "good enough" or "right for now" and make progress quickly while feeling reasonably confident about your choice.

Does this answer your questions?

In terms of accountability, these approaches can really help you stay committed:

1. How will pulling off this app make you feel about yourself?
2. How does it align with your career aspirations or higher aspirations on how you want to live your life and the impact you want to make.
   1. If you can envision this and stay focused on the outcome, it does wonders for commitment.
3. How will it change the story you tell about your life to yourself and others?

Nearly every commitment in my life has its roots deep in one of these questions.

Back in the day, I wanted to build an app that would tell me the carbon footprint of a given choice. My original idea was to do it for my food choices, but it can also be done for flights or if you drive a gas car or even for things like time spent on ChatGPT or mining bitcoins.

Yes, I'd google some articles on its usefulness and look through a few templates until you find the one you like.

If your manager doesn't have experience doing this, then I'd say it's a great opportunity to collaborate with them and "teach" them. This will also give you a flavor of what it's like to work with them early on. 

(Them seeing you as a collaborator is an important step toward partnering with your leadership regardless of the organizational "power" structures. Done well, it can position you as a strong collaborator and partner to the leaders down the line.)

The Manager's Path also has some great information on becoming an effective mentor and tech lead. I recommend reading the first few chapters of the book, but here's a [summary](https://www.runn.io/blog/the-managers-path-summary#chapter-3) I found.

Does this answer your questions?

So sorry to hear about your layoff. It's a terrible experience to go through.

Taro has a ton of content to navigate these challenges. But if you're looking for personalized guidance, you can set up a free discovery call with me. I offer job search coaching as well.

Rahul's point about translating physical notes into digital is very important for consolidation! 

(This is part of why I rarely take physical notes. :) )

I do keep post-its around for visual cues to change some persistent behavior though. For example, one of my notes said "Yes, and" for a while until I learned to pose counter-arguments that way. Visual cues like these are *very* effective!

Some time ago, I had this use case where I had to read a bunch of books and take notes. I got the books on Kindle/Apple Books and used the iPad pencil to write to make sure everything could be digital and in one place. I found it very helpful. 

I also find Speech to Text very useful on iPad. Often times, I'll speak what's on my mind and it's transcribed.

1. I wasn't interested in going back to big tech :). Like I said above, I terminated my loop with Meta even though they were considering me for E6 (or potentially E7 based on my interview performance). I could've shaved off 2-3 years to get to Staff at another mid-level company by leaving the startup or the fintech sooner. But this is how it worked out due to a variety of reasons and I understand and value the contribution of that phase to my career and life.
2. I don't think I can predict my career progression at any other place. AFAIK, none of the folks I started my career with at Microsoft are Staff now. Most of them are still ICs though. Of course, it's possible that they didn't try at all. See more on my take on this below.
3. The only job I ever applied for was the startup! I had been looking for the right opportunity outside Microsoft for a while, so I went through a phase of mass applying and this startup worked out. 

   All my other positions were either though campus placements or recruiter DMs on LinkedIn, including my most recent Staff role and all the other offers I had in that round. I wasn't even active on LinkedIn until recently; I'd only filled out my profile to a reasonable degree. Very fortunately, I have had more recruiters reach out than I could entertain for most of my career. Of course, the market is very different right now.
4. The startup went though a series of acquisitions unless the last company that acquired it got the short end of the stick and basically killed the product. But the primary revenue earning product did live to its late teens. Pretty incredible!

**My perspective on predicting career progression**:

This might be a hot take, but my long experience has showed me that our dynamic work environment makes it so that success in one environment doesn't guarantee success universally. 

It's possible to do very well with your skillset in one team (with a specific manager and team mates and culture) and struggle on a different team within the same company! Even a manager change on a team you're successful on can drastically change things.

Added to this is the fact that different companies treat career trajectories different and value progression differently. There are also D&I aspects at play when it comes to who is set up to progress quickly and who isn't.

Does this answer your questions? Anything you'd like to add?

PS: Thank you for your patience in getting this follow-up. :)

Here are some tips that have served me well:

**To assimilate and retain what I just read**: Pausing after reading and taking time to remember what you just read. Revisiting the material in your mind reveals gaps in your understanding as well as memory. Re-reading those parts improves understanding and retention of the whole picture.

**Pattern matching**: What else do you know that looks/works like this? This is very helpful in learning new languages or software tools. It also helps in interview prep, esp. system design and algorithmic problems (where else this design/code pattern appears, etc). Associating new things with things we already know making assimilation and retention easier. It also improves our understanding of the world in general.

**Note taking**: Taking brief notes on books you read is a great way to jot down key takeaways and refer to them months/years later quickly! While summaries on sites like 4-minute Book Summaries or Blinkist help, I have found that my own notes work better since they are personalized to what I get out of the book. Yes, it does slow down book reading, but cost of reading the book all over again in the future would be much higher. 

**Creating visuals**: This mode can be used to retain flows of information. Think AuthN, AuthZ flows, designs of common distributed systems at scale, etc. Block diagrams are much easier to remember over mounds of text.

Identify an archive that works well and build it up over time. For me, it's my personal Google Drive. Organizing by topics and being able to search through them is very powerful.

You can also try apps that bookmark links, etc. but I do not have a favorite one.

What are your thoughts on this answer?

First, congrats on the up-level through job search! Incredible work, esp. in this job market!

I'd say the biggest mindset shift is to think in terms of the $ impact of your work. Creating a culture of engineering excellence would be second.

If your work happens to move the needle on the company's revenue goals directly, you're already in luck! If you happen to be on an internal team, like Platform, no need to sweat. In that case, identifying the work that would be the most impactful to the teams you're supporting would win. Are there software or process inefficiencies you can remove or infra/ops cost you can save?

Engineering excellence matters because small inefficiencies snowball into great slowdowns that cost millions in vendor bills and eng org's salaries. Think in terms of code review turnaround times, testing inefficiencies, developer experience, CI/CD, deployment speed, observability, etc. 

Also note that you don't need to wait to be technically excellent yourself to create a culture of engineering excellence within your team (and then your org). See a couple of my LinkedIn posts below.

I'd also look at the career ladder for Senior to make sure you understand how you'll be evaluated. Having a candid conversation with your manager about what they value and asking them to give you frequent feedback would be a great step toward building trust and showing your commitment to doing well.

Make sure you create a 30-60-90 day plan with your manager! I have done this time and again in my career, even when I was quite senior and it was *very helpful* at every stage. Besides technical work, the plan should also have names of people you should meet and the 3rd party systems and tools you should learn about. Google some templates, if you need to. 

Taro is a great place to network with other senior engineers from your company to learn about their experiences and successes. You might also want to find another senior engineer buddy from a sister team (like your manager's peer's team) to orient you to the new role.

Taro also has a lot of content on being an effective senior engineer; Rahul and Alex would be able to link the most relevant threads. :)

How does this answer sound?

LinkedIn posts:

1. [Unlocking technical excellence](https://www.linkedin.com/posts/activity-7206324319113678848-Vo0v)
2. [How to become technically strong over time](https://www.linkedin.com/posts/activity-7207049113006198784-pNCX)

Rahul has a great answer with great pointers. 

I want to underscore his point of business context: "*but you **also** you have tons of business context since you led engineering for the entire company*." Once you get a role of your liking, you'll be able to identify impactful work very quickly, which will make you a great engineer as well as an effective mentor and coach to rising engineers.

You might come across some hurdles in convincing some engineering leaders that you'd be a great SWE or TLM hire (over another tenured IC candidate) unless you've been in the code at work or outside. 

They might also wonder about your motivation to switch back to IC. This is important because Head of Engineering can mean a lot of things. If your role already maps to a Director/Sr. Director/VP, you might be asked more questions :). 

Not knowing more about your exact situation, I encourage you to *get really clear with your intent and how you'll to convince them that you'll make a strong SWE*. You might want to line up a SWE reference or two from your past IC life to vouch for you. Or perhaps the senior most IC at your current place can also be a reference.

You might know about this article already, but I want to surface it again for ideas on how to make your case for an IC role: [The Engineer/Manager Pendulum](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/).

PS: Rands Leadership Slack is another great place to source help on this front.

PPS: If you're a non-male, [SheTO](https://www.sheto.org/) is a great network to join as there are folks in that network making a similar switch at this time.

I also found <https://www.pramp.com> to be very helpful in getting paired with people of similar experience for free, mutual mock interviews. 

I last used it in 2020. Back then, there used to be a form that asked about my experience, the kind of role I was looking for, and the area I want to interview in. IIRC, the choices were coding, system design, and behavioral interviews.

Once you select all that, you'd select a time and be paired with someone of similar experience and looking to mock interview in the same area. Both people would interview each other on the same question (that would be revealed at the start of the session) and share their feedback. I think the sessions were 90 mins long to allow enough time.

You could have your video on or not; I liked to have mine on. You could also connect with them offline if there's mutual interest.

Hope this helps.

Alex has some great answers already!

I am a living example of someone who learned more and expanded their scope tremendously at a startup, so I want to chime in as well. :)

I started my career at Microsoft. All the tools I used were proprietary to Microsoft. My scope was limited to writing my code, making sure QA tested in, and "throwing it over the wall" for deployment. Occasionally, I'd monitor the deployments. A little later into my tenure there, I learned the production alerts and monitors and could troubleshoot quite well. I even got a promotion there.

Three years in, as I was interviewing for other jobs, nearly every company wanted to talk to me because I had Microsoft on my resume. This being Seattle in the early 2010's, many companies had began using the same internal tools as Microsoft to align with the skills of the available talent.

If any company used 3rd party/industry-wide/open source tools, I was clueless! I couldn't speak to the software pipeline end to end because my scope had been so limited.

Next, I went to a tiny startup of only 80 people in total (go figure!). My scope expanded like crazy—everyone did everything because that's what was needed to ship the product and generate revenue for the business.

At this startup, I also did DevOps for 1.5 years where I wrote Ansible deployments to deploy the AT&T product to 150+ bare metal servers. I did Android development. I did frontend work. I did MySQL database failovers! I worked with IT to provision new servers and set up low level networking and firewalls. I set up web servers like Apache. I interfaced with product managers and engineers on the carrier side (AT&T and Sprint) to identify the right thing to build.

I ended up staying at that startup for 5+ years because of the learning and the "tight-knit community." I am still friends with some folks I met there and we hang out regularly. Fast forward to the last few months in 2024, when I launched my coaching practice, I wrote to several people from that startup. Nearly everyone responded with whatever help they could offer!

From that startup, I went to a 500-person Fintech company. Most often, I was the only engineer in the room who could speak to the entire software pipeline end-to-end because of my exposure at the startup! When the mobile team couldn't use my service APIs, I got them unstuck quickly. When I ran into MySQL issues in my service, I sat next to the DBA to debug quickly.

I became the *de facto* tech lead of my team within weeks of joining (over folks who had had a longer career than me, or were tenured at that company)! All that reputation of cross-functional leadership in this new role paved the path for Staff engineer in my next role.

When I interviewed after that FinTech, I had multiple offers at Staff (all at startups; Meta was also interviewing me for E6 but I terminated the loop) even though I didn't have the Staff title at the fintech—and I didn't ask for it in my interviews.

My next Staff role was really where all that learning and increased scope paid off. I was one of the handful of Staff engineers (in the Staff, Principal, Fellow bucket) who played an advisory role for the entire engineering org of 400 people.

Why? Simply because I knew "how things worked in general." The exact technology or stack no longer mattered because I had gained enough exposure to internalize the shared, cyclical concepts underlying a broad range of things like AuthN, AuthZ, logging, build tools, CI/CD pipelines, you name it.

I know this came out to be a long read, but if you made it this far, I hope this story was helpful. :)

Edit: Made a few minor edits to fix grammar, etc. a few hours after posting the answer.

Is it possible that their team takes a 5 min break in between 30-min meetings? Some teams do a 25-5 and 50-10 calendar. 

Ah, Alex made some great tactical points. 

On the point of buffer, I recommend adding at least a 20% more buffer for relatively well-defined projects, and more for the nebulous ones. 

It's also better for the on-call to not be expected to do very much feature work during their on-call week. This reduces their context switch, and they can apply any free time toward improving the on-call resources like alerts and documentation. A clean hand-off to the next on-call is also highly valuable.

This is an interesting problem to have!

Since you mentioned "quick to code" and "quick fixes" a couple of times, have you tried to dig into why he wants to solve things so quickly? I am wondering if he misunderstands the incentives! 

Sometimes, people incorrectly pick up cues that skew their understanding of incentives. Is velocity highly rewarded in your team or the larger engineering culture at all costs? Do engineers tend to be fast and loose with quality and not mind accruing tech debt? Does he want to impress you with his quick turnaround time? Is he impatient in waiting for your feedback?

Some of the approaches you are applying can be more effective if you could dig into what's actually driving his behavior. This will also help you become a better mentor because you will help people uncover their unconscious habit patterns and address them in addition to providing tactical suggestions. The change you bring about will result in a lasting transformation in your mentees.

As for tactical suggestions, have you considered giving him a set of questions in writing? I'd try writing down the questions around consequences, risks, and other strategic aspects that you'd like him to consider. Ask him to write down his answers in return and have a working agreement that he wouldn't begin coding until the two of you have discussed the answers. 

Writing down his answers will force him to think more clearly than in his rushed, discursive thought. If this approach is successful, he will start seeing patterns in the questions you ask and his answers, which can teach him to think strategically through practicum. Since you're officially mentoring him, you can also ask him to find common patterns among the written notes after you've done this exercise with him a couple of times. 

Your idea to give him some well-defined problems along with a strategic task is also a good one. He will be able to scratch his coding itch and keep showing progress.

I understand your concern. Here are a few things to consider:

1. Does every direct report get the same amount of 1:1 time with the manager right now? If yes, it doesn't solve your problem but at least tells you that you're being treated equally among all their reports. :)
2. How do you want to use the additional time with them? I'd get clarity on this first. Identify your needs, how quality time to discuss those topics would actually help you, and then have a conversation with your manager focusing how the help would empower you. 
3. Lead the conversation with "I'm looking to get X from our time together. X will help me in Y way. How do you recommend we do this?" The manager might ask your more questions at this point, offer more 1:1 time, or suggest other options. I'd say be open to other options as well. At the end of the day, you are looking for Y. It doesn't sound like getting more time itself is your goal. Asking an open-ended question will probably be more productive than asking for more time upfront. You also don't want the manager to get defensive and say no (which will close the conversation preemptively!).
4. Can you make better use of the time you do have? Like have a shared document where you add your top of mind the day before and have an agreement with the manager to respond on the doc. This will give you the full 25 mins to have the conversations important to you.

Hope this helps.

Tenured Staff Software engineer

First, congrats on your promotion! 

It sounds like you are off to a good start, so I'd relax a bit and not constantly scan the horizons anticipating something bad :). This will conserve your energy toward more productive work, trust me.

Now, to your actual question. Here is my top 3 pieces of advice:

1. Trust the engineers who are following you. Let them know that you're there to help, but give them autonomy so that they can have a purpose and are motivated to achieve mastery. This will also help you scale yourself as you'll be able to pick up work they are not picking up. Be open to wear multiple hats in addition to your TL duties given that you're at a small place.
2. Do what only you can. Very soon, you will have many competing priorities and you might be inclined to do it all by working longer hours and trying to stay on top of everything. This is not scalable. Delegate the work others in your team can handle so that you can focus on impactful work for yourself and differentiate yourself. See my LinkedIn posts on delegation at the end of my response.
3. Keep learning technically and show your team that you, too, are learning with them. TL activities and the the resulting glue work can become all-consuming. But cultivating technical depth and breadth are essential in this line of work. So, schedule 2-4 hours every week to learn something new or dive deep into the technical work that your team did for the week. Internalize your learnings. Try to make some active time in the team to learn & teach/share; maybe a lunch & learn or some such forum every 2 to 4 weeks.

Some more reading resources for you down the line:

1. Camille Fournier's Manager's Path has a chapter dedicated to TLs.
2. Will Larson's book on the Elegant Puzzle of Engineering Management. The [cliff notes](https://github.com/keyvanakbary/learning-notes/blob/master/books/an-elegant-puzzle.md) on Github are a great resource.
3. Influence Without Authority by Cohen and Bradford

My LinkedIn posts on delegation:

1. [Superficial beliefs that keep us from delegating](https://www.linkedin.com/posts/activity-7212122554856062977-FDVw)
2. [Deeper beliefs that keep us from delegating](https://www.linkedin.com/posts/activity-7212122554856062977-FDVw)

Hope this helps! Feel free to ask follow-up questions.