Everyone has their typical 'work day' so you just get used to everyone's schedule and planned zooms around that and use slack for general communication. Occasionally I would msg or zoom outside of my core hours but we also had flex time so it worked out well. We generally always scheduled meetings through google calendar so timezones were handled there for coordination. If we mentioned a time in slack or on a zoom it was always given as NYC. It was a non-issue, motivation, sleep, food aren't related to this. Some team members worked later in the day in their local time zone by choose to overlap more with NYC.
I've been fully remote since 2012, you'll get the hang of it.
My teams have used a lot of slack msgs and slack huddles, lots of zoom meetings so everyone feels pretty connected.
It's great if you can meet up together at least once a year, work out of an office together and go out, grab drinks, eat meals together for team building.
You'll need a routine, exercise, taking breaks, leverage flexible hours, take a trip and work remote from somewhere cool and interesting.
Take breaks to cook a meal, laundry, play guitar for 10 minutes, get outside for a quick walk, enjoy your pets, say hi to your family, have lunch with a friend, you won't go stir crazy.
Being remote is one of my favorite things about my career, I love it.
Why is the siloing so important do you think? I think with all the use of LLMs now, entire functions or multiple functions can be done by 1 person. Those people can get a lot of task and skill variety in their work.
Every team member has a job to do in the software process. Each speciality can leverage AI to perform faster and better moving the whole process forward. I think everyone can expand outward with what they are able to do enhanced by AI but they need to stay around their core expertise where they are bringing the most value. Things still need to be maintainable and secure.
My mental model of the 'new normal' is end users using AI to get their work done.
So if I re-worded the OP's description and replaced 'internal tools' with 'internal AIs' then this would at least seem like a more reasonable process to me...
> At our startup, engineers don't build features anymore.
> They build APIs that internal AIs can connect to.
> Most "features" like running an SQL query, sending a push notification when product X is ordered gets built by ops or product folks using those tools.
To me this describes a team of engineers that use AI-capable tools and that are building 'features' for themselves.
In the way that us dinosaurs used to write build scripts.
I'm not saying that my mental model is right or wrong, just that working this way seems reasonable if you buy into my model.
If you've been there a while and have some latitude start a 'Labs' initiative.
I've been doing this at every company I work at. Ask for 10% or 20% time to spend building prototypes to leverage technology to solve problems that provide a huge value to your org.
Compile a list of problems and look for the lowest lift and highest value to org.
Build one and if it's a success you'll get full buy in.
You can pick the stack you want to work with and integrate with ServiceNow as needed. Not familiar with service now but there are always things you can do with multiple stacks/services that provide value to the org.
Maybe this will scratch your itch and possibly open up a new position/group you could develop inside and run.
You're going to have to embrace some of your director's approaches at least initially, deliver some wins to show him your team can meet his expectations.
Once you have some wins and build trust you can collaborate more on future projects.
The director has a responsibility to implement his vision that's why they hired him. That will be make or break for his success. Your team is responsible for implementing his vision with some collaboration along the way of course but directors have the autonomy to guide their ship.
You'll need to duplicate existing code and make it your own or risk adding one piece of new functionality and breaking things that were using that code in 20 unexpected places.
Build new isolated code with best practices.
You'll slowly become familiar with it and get a feel for the best way to make updates and changes safely.
