What you are describing sounds like a Technical Product Manager, not a tech lead. The minute you have them “run a team”, you are combining both roles into one.
Writing a tickets is usually not owned by engineering. Some engineering managers may do this work, but it’s usually owned by Product while Engineering helps refine and turn tickets into actionable work. Engineering also doesn't negotiate features. Engineerings job is to help product determine LOE and help Product prioritize requirements for a future release. Again, strong engineering leads can do this work, but I believe Product Owner should hold these responsibilities.
> I believe Product Owner should hold these responsibilities
That's inarguable, as you haven't said why, but I'm saying the structure I described works well. My rationale is: product people don't generally write great tickets, and they also aren't in a position to negotiate features based on technical constraints.
If you’re looking for a good read, pick up a copy of Tony Fadell’s “Build”. There are a few interesting chapters where he writes about the process of selling Nest to Google.
One issue I see with your example. You say “had the IT guy chosen to work”. This statement assumes OP can just pickup more hours easily. That is not the reality. If it’s a salary based position, OP can’t put in more hours just to earn additional income. If it’s a hourly job, OP all can’t put in more hours. Usually anything outside 40 hours is considered overtime and would need to budgeted and approved by the employer. OP could use his IT skills to find more work at that rate for a different company, but now we are back to the passive income example. TLDR. The math makes sense, but the example falls flat in reality.
May I ask what you are using for endpoint management? Are you using JAMF, Intune, something else? Are you using an always on VPN to all users? All cloud based or on-prem infra? DNS security? Endpoint protection?
We use Jamf and DataJar for patch management, and we have been happy with both. DataJar’s customer service /sales is lousy, but they are the only game in town.
That title is both misleading and untrue. Infrastructure as Code is exactly that, a way to define your infrastructure definitions code. There is nothing cloud specific about that concept. You can easily write Terrform to work with VMware instances on-prem.
Sumo Logic sales once sent me a targeted email asking if I needed help getting the most out of my AWS S3 Load Balancer logs. The creepy part is I just created an S3 bucket the previous day that had the strings “load balancer” and “logs”. They must be scanning S3 bucket names for key words and maintain or pay for a list of AWS account id mappings to likely owners.
Maybe. But I’d also guess your browser history in the lead up to / around the creation of those buckets would also indicate that you were in the process of managing load balancer logs.
Free dev content exists to educate / onboard to product. It’s utilised in exactly this manner to determine what & when a developer is trying to achieve. And then sell them on suitable solutions.
It was surprising to see SumoLogic there... I used them in a previous company and the service was generally good. Sad to see they subscribed to such shady practices.
What else do you think it needs. I’ve been playing around with v1.5 the past few days in Grafana and I like it’s simplicity. Grafana now has a Loki datasource which is nice.
