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.
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.
A senior developer in my book is someone with both leadership skills and the experience to back that up. Most of your work is enabling other developers with a bit of actual dev work sprinkled in.
You're still chiefly a problem solver like any dev, but your problems now are more than code. Hence, your toolset expands to implementing new processes, talking with non-devs, creating PoCs, teaching, and more.
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.
Surround yourself with good supportive people and avoid those who put you down.
In my younger years, you can't avoid the people who tend to project their insecurities on you: bullies, primadonnas, etc. Schools and workplaces are mixed bags, where often people make friends based on superficial characteristics.
Places where I found supportive people:
* Startup scene
* Church groups
* Tech groups
* Mentorship groups
These folks helped me see life in a more balanced way. People aren't out to get you, they are just thinking about how others think about themselves. Same as you.
The Speed of Trust by Stephen Covey: Made me realize that trust is essential in human interactions. Helped me through my businesses, career, and community building.
Atomic Habits by James Clear: Read a lot about habits before but this really kickstarted my focus on living healthy and staying consistent.