My team lead philosophy: engineers that score successes continue to be successful.
There will always be a backlog of tickets, and you can't hit inbox zero. But you can hack it. Executives need to increase the Average Sales Price (ASP) and Reduce Churn. Your team will want to fix technical debt.
Your job is to bridge the gap: help your team understand how their work impacts customers. Help the business understand how your team's successes impact ASP and churn rates.
Tell your team they hit the goal. Tell the organization your team hit the goal. Tell the organization where your team can see you telling the organization. Many engineers aren't known for their salesmanship, and they can and should improve, but you can step in and rapidly build trust with them and the organization by selling their work on their behalf.
Instead of asking for time to fix tech debt, explain to the organization what the tech debt actually fixes: Reliability (churn), Operations/Chores (COGS), Resistance to Future Change (ASP), Infrastructure Bills (COGS), App Performance (churn), and like that.
The weekly 30-minute O3 is your new best friend, especially with non-technical stakeholders. As a team lead, I usually meet with engineers every other week—you're a team lead, not their manager.
Understand the differences between Accountability, Responsibility, and Authority. Responsibility is "yup, we're on it." Accountability means the business expects you to accept "consequences" for failure. Don't accept Accountability without both Authority to make decisions and compensation for the job risk. More than likely someone else is accountable (an actual manager or maybe a product owner.) Engineers are too difficult to hire to be holding them accountable. As an ambitious founder-turned-tech-lead I bristle a bit at this, but at least you can be aware of how things are set up.
But this also means you'll have limited authority, and you'll have to achieve alignment rather than dictate solutions. Which brings me to:
Pre-wire meetings. If you need a decision to go your way, meet with each attendee individually first and get their feedback on your proposal. Don't put together the meeting with everyone until you're confident it's a formality.
You can push back on processes that don't work for you: too many meetings, scrum ceremonies, taps on the shoulder. "I understand the importance of schedules and status updates to the business. My team needs protected time to achieve our best results. Will you help me batch our meetings into tighter windows so we're able to both put in the work and keep the business informed on our progress?"
Set up systems. Don't take on all the chores yourself. Set up a schedule for a "triage" engineer, include yourself in the schedule. I like rotating out weekly. This engineer intakes all of the bugs/questions/fire drills and provides answers and verifies things aren't on fire. They are assigned less critical tasks that week because they'll be interrupted. This gets you protected time to think.
Set up engineering "pairing office hours" 4-5x a week. You're not a manager: you still need to be on a Maker's Schedule. Your engineers will need help and rubber duck sessions, but if you drop everything every time they ask or get stuck, you won't ever be able to get in the zone yourself. Likewise, they'll know when you're available to help. Tell them you expect them to come prepared with a list of things they've already tried.
Read every MR your team submits. Don't comment on the direction 8 times out of 10 (unless you're directly assigned to a review.) You're looking for opportunities to ask Ben to talk to Samantha because they are both changing related areas. Great software is built by gardening over months, quarters, and years. You don't need every MR to be perfect (and that's subjective, anyway), and you'll achieve better results month over month if your engineers feel like they have ownership over their work.
On the flip side, if you're the one being micromanaged, try accepting responsibility for larger time frames. "We will achieve this specific thing by next Friday. We will provide confidence updates on Tuesdays and Thursdays." Then do it. Every time, if you can. The reason the CEO can go play golf on a Tuesday afternoon is because he accepts responsibility for improving the valuation of the whole company by 120% by the end of the year. The junior engineer accepts responsibility for one JIRA ticket, and is likewise expected to be available from 9-5 most days.
Read both Peopleware and The Mythical Man-Month. You're not a manager, but they will help you articulate your frustrations and give you tools to talk to management.
Email and twitter in profile, let me know how I can help.
One of the best answers on the whole thread. It is good to know the things I suffer most (no deep work because of interruptions) are quite common. Your post deserves to be much higher on the thread.
There will always be a backlog of tickets, and you can't hit inbox zero. But you can hack it. Executives need to increase the Average Sales Price (ASP) and Reduce Churn. Your team will want to fix technical debt.
Your job is to bridge the gap: help your team understand how their work impacts customers. Help the business understand how your team's successes impact ASP and churn rates.
Tell your team they hit the goal. Tell the organization your team hit the goal. Tell the organization where your team can see you telling the organization. Many engineers aren't known for their salesmanship, and they can and should improve, but you can step in and rapidly build trust with them and the organization by selling their work on their behalf.
Instead of asking for time to fix tech debt, explain to the organization what the tech debt actually fixes: Reliability (churn), Operations/Chores (COGS), Resistance to Future Change (ASP), Infrastructure Bills (COGS), App Performance (churn), and like that.
The weekly 30-minute O3 is your new best friend, especially with non-technical stakeholders. As a team lead, I usually meet with engineers every other week—you're a team lead, not their manager.
Understand the differences between Accountability, Responsibility, and Authority. Responsibility is "yup, we're on it." Accountability means the business expects you to accept "consequences" for failure. Don't accept Accountability without both Authority to make decisions and compensation for the job risk. More than likely someone else is accountable (an actual manager or maybe a product owner.) Engineers are too difficult to hire to be holding them accountable. As an ambitious founder-turned-tech-lead I bristle a bit at this, but at least you can be aware of how things are set up.
But this also means you'll have limited authority, and you'll have to achieve alignment rather than dictate solutions. Which brings me to:
Pre-wire meetings. If you need a decision to go your way, meet with each attendee individually first and get their feedback on your proposal. Don't put together the meeting with everyone until you're confident it's a formality.
You can push back on processes that don't work for you: too many meetings, scrum ceremonies, taps on the shoulder. "I understand the importance of schedules and status updates to the business. My team needs protected time to achieve our best results. Will you help me batch our meetings into tighter windows so we're able to both put in the work and keep the business informed on our progress?"
Set up systems. Don't take on all the chores yourself. Set up a schedule for a "triage" engineer, include yourself in the schedule. I like rotating out weekly. This engineer intakes all of the bugs/questions/fire drills and provides answers and verifies things aren't on fire. They are assigned less critical tasks that week because they'll be interrupted. This gets you protected time to think.
Set up engineering "pairing office hours" 4-5x a week. You're not a manager: you still need to be on a Maker's Schedule. Your engineers will need help and rubber duck sessions, but if you drop everything every time they ask or get stuck, you won't ever be able to get in the zone yourself. Likewise, they'll know when you're available to help. Tell them you expect them to come prepared with a list of things they've already tried.
http://www.paulgraham.com/makersschedule.html
Read every MR your team submits. Don't comment on the direction 8 times out of 10 (unless you're directly assigned to a review.) You're looking for opportunities to ask Ben to talk to Samantha because they are both changing related areas. Great software is built by gardening over months, quarters, and years. You don't need every MR to be perfect (and that's subjective, anyway), and you'll achieve better results month over month if your engineers feel like they have ownership over their work.
On the flip side, if you're the one being micromanaged, try accepting responsibility for larger time frames. "We will achieve this specific thing by next Friday. We will provide confidence updates on Tuesdays and Thursdays." Then do it. Every time, if you can. The reason the CEO can go play golf on a Tuesday afternoon is because he accepts responsibility for improving the valuation of the whole company by 120% by the end of the year. The junior engineer accepts responsibility for one JIRA ticket, and is likewise expected to be available from 9-5 most days.
Read both Peopleware and The Mythical Man-Month. You're not a manager, but they will help you articulate your frustrations and give you tools to talk to management.
Email and twitter in profile, let me know how I can help.