tyroh

The design made me thought I was in one of those placeholder sites for domains that were on sale.

This is great! I actually made another sheet in the same file to track historical changes in one of the values by manually checking based on Google's own version history. Of course, I would probably use this but the price tag isn't a match to how I'm going to use it (just for personal expenses)

In my team, the role is a Lead who essentially leads the creation process, like you're doing. They do PoCs, R&D and technical requirements while also guiding the ICs in building out the product.

Seems like Director would be a good fit as well if you're in a more advanced stage of your career.

All of my planning is digital, so that it's easy to see across devices and by other people.

Important + Urgent = Add as event in calendar for today Important + Not-urgent = Calendar event but for a later date, or todo list Not Important + Urgent = Calendar event for someone else in the team Not Important + Not Urgent = Todo list

I find that leading a remote team means most adhoc syncing done between members go away so standups are required. Also, the higher up you go, the more of these meetings you need to be in if you want to stay aligned with everyone.

For me, I spend around 6+ hours on team sync up and 5 hours on 1:1s with DRs. But that's because I am very involved in most parts of the org.

You can replace meetings with documentation but you need to be disciplined to read all those and digest them. Or just think about the sync meetings as a time to build rapport with them.

You're not an IC anyway, you're measured by your team's work so alignment is necessary if you want them working on the right thing all the time.

For #1, 1:1 will help a lot but it will take time as you need to build the relationship enough for them to open up to you.

But I agree with #3. The problem is getting the seniors to RTO just for this express reason. Though having an always-on call for that day would help with adhoc questions from juniors.

1:1 are for building relationships and talking about long-term goals, in work or otherwise. It's also a good time to discuss big picture goals, seeing where the work you're doing fits into the grand scheme of things (at least within the company)

This goes both ways: if you're the direct report, it's best to build rapport with the manager so you can work more smoothly and especially to get that raise or promotion later on.

I guess sometimes its hard to build the relationship for some people, but often it does take time.

I'll add these two if you're pursuing a manager role:

- The 4 Stages of Psychological Safety

- Nonviolent Communication

Personally, having a servant leader mindset is one of the most important things to practice when taking on a leadership role.

What stuck with me are my wellness habits:

1) Regular push ups and planks, except when I was injured or on trips. 2) Tracking my diet which helped me lose 10 kgs. 3) Reading tech-related books which only stopped during crunch time at work.

I think seeing results is the main reason I continued these habits. I have tried some other habits like those related to finance or social media but since I could not see any results, they fizzled out.

For the initial push, looking forward to achieving your goals for your habits is crucial. Making sure they align with your own value set is key, so you don't slack off (or pick it up immediately when you do, and that's okay)

And another thing was making the habit small at the start. I didn't go full intermittent fasting or lifting weights since cold start doesn't work for me. It's easier to just improve on the habit as you get the hang of it.

This is precisely what's happened in our company. The project management head was not a servant leader and actively avoided doing real work while telling others what to do and promising to do things that never happened. Sadly, this person is still with our company at the time of this writing, but thankfully not anymore in a role where they can derail work.

What really struck a nerve in me was that I had to catch all the work this person wasn't doing, and I only realized it after I got burned out from all the extra work.

The bigger issue then is that you can't solve this because often, the person does a good job of hiding the bigger issue by deflecting to smaller, more pressing ones.

As someone in a role that has this as a goal, you've nailed it on the head.

Developers can be super productive at home but will miss out in the random discussions and water cooler topics discussed with other teams, even their immediate supervisors. It leads to building the wrong thing which frustrates everyone.

For me, it's getting some devs to become team players. Many of them are good at what they do but sometimes they become big blockers to the progress of others in the team.

I try my best to unblock people but you just can't unblock someone's attitude to working. Maybe they just need time to understand, but time is also a luxury our projects do not have.

You probably should set your sights more on becoming a lead developer, where your experience as an engineer will be respected but you can transition into management later on. Also focus on discussing your mentoring experience a lot, including the outcomes you've helped achieve (ex. 200% growth in X, 50% fewer bugs in Y, etc.)

As someone who hires for this role, I look for people who can handle teams well and deliver outcomes, not just code. This means I need to be able to trust you with the careers of the team and the project results.

A good transition is actually consulting on tech teams, which is somewhat a leadership role that will give you the management experience needed later on. More often that not, companies absorb good consultants if they jive well with the team.

1. If the original authors are still around, we do a knowledge transfer. 2. Create diagrams about the relationships between all the systems involved. UMLs, ERDs, and all the rest of them 3. Clone the system locally and trace how the data flows from one point to the next. I'd go with logins first since we all know how it should work so it's easy to follow. 4. Lots and lots of trial and error when contributing new features. If it's well made, tests will catch your bugs. If you have a good team, they'll cut you some slack since you're just new and they were also new, too.