1. Mostly through daily stand-ups, but I hate these: I only do them due to MBAs in suits love progress reports and have the impression developers being 'idle' i

1. Mostly through daily stand-ups, but I hate these: I only do them due to MBAs in suits love progress reports and have the impression developers being 'idle' is a detriment to the business which has costs which they have to minimize. I tell my team that anytime they have a blocker to try to resolve it - but if they can't do it quickly to come to me (and I usually resolve most issues quite quickly just by guiding them through my process so they can learn from it). 2. This once again depends on the company. I prefer not interfacing with them: my job is to deliver value to the business by serving both the staff and the businesses' customers. My number one initiative when I am on-boarded to any organization is to understand: what is your goal, what do you want to accomplish and who are you here to serve? Once I figure that out, I can think in terms of end-users and various stake-holders and try to work backwards rather than having to have many useless meetings and having to constantly wonder what I should do next. Think in terms of the customer: what can you do to improve the product for them and what can we do to improve the business in general? 3. I usually do yes, but most of them are led by upper management and I mostly think of them as a waste of time. If I need anything, I get in touch to the user or customer who has the information and find this information directly. There is one recurring meeting that I do tend to have with my team: weekly learning sessions and these are non-mandatory and not really recurring. 4. Documentation to me is very important, so any communication which I have to do more than twice I document and I put it on a wiki or shared knowledge base which both me and the team can reference and point to in case anyone needs guidance. I'm also a huge fan of written requirements but that's me. 5. 1) Minimize meetings 2) Unblock your team by helping them out when they need help and teaching them how to solve their own issues instead of always having to come to you - if they can't resolve problems themselves or they come to you every day, maybe it's time to think about letting them go and hiring someone who is able to take more ownership and has a bit more talent in solving problems 3) Keep asking the question why? What is the business trying to achieve with my team and how can I improve it? Which activities can I do which are 'high-leverage' and which will help us accomplish what we need to accomplish? I'm very hands on so the way that I play 'lead' is by minimizing micro-management and getting my hands dirty: I develop the hard stuff that I believe my team won't be able to handle and try to also foster communication between my team as well: I tell them if they ever need anything to come to me directly and I will try to get them the information they need. Communication is the number one thing that will determine a team's success so I try to keep it moving - how can we communicate what we need to develop more effectively and how do we make this process more efficient? Sprints and stories and all that other crap to me is a sign that most software firms today are broken and that most developers take 0 ownership on aligning with the business. This is the reason why we have so much broken and shitty software today as well. Hire people that are excited about developing solutions for real human beings and that WANT to see the business progress without having a 'product owner' or 'sprint planner' or some bullshit-job personnel having to either disturb you and guide you and teach your staff to do the same. Also, take ownership and pride in doing quality work and teach your team to do the same by leading by example. 6. Make sure to understand the product and business and first and foremost: the customer and do your best to solve their problems. Also, read books which aren't just about copying stories on a story board or about shitty broken agile processes; understand general things about business and human psychology and usability and design - this will equip you to make decisions without having to be micro-managed by 'the business.' If the business needs and insists on micro-managing you or your team - then leave the company and find a place that isn't broken (albeit it is tough to find these...when you do find them, you'll find a lot of rewards in working for them - autonomy and pride and not being micro-managed are all amazing things).