1. How do you interface with your team (and how frequently)?
2. How do you interface with your manager (and how frequently)?
3. Do you have some recurring meetings? What is their cadence?
4. How do you take care of documentation?
5. How do you ensure that you have time to work on your sprint tasks while context switching?
6. How do you ensure everyone is moving in the same/correct direction?
A daily standup ensures that no one spins their wheels for more than a day without giving you a chance to do something about it, which is really helpful for a junior team. However, remember that this meeting is for surfacing issues, not for solving them. Schedule follow-ups with the people who need it and let everyone else get back to work.
Document things when you get tired of answering the same question repeatedly. Focus on ROI, not some higher principle of best practice. You can get a lot of mileage out of conventions and tribal knowledge.
1-3. Try to do more 1-on-1 or small group meetings, once per week max. Unless there is a lot of overlap/cross concerns, I found having a big group meeting become "holding court" where one person speaks to the lord (you), while the others sit there waiting (or checking email). Same would go with talking to your manager, try to do more 1-on-1 if possible, or ask if you could submit a quad chart instead of a big holding court meeting. (https://researchservices.cornell.edu/sites/default/files/201...)
Other than that, if you are comfy with being pinged via Teams/Slack/whatever, that seems to work best for small questions.
4. One thing our org tries to do is have regular rebuild days. That's where you take a base VM/system and rebuild your environment and code by following your own instructions. Best way to catch what you didn't document: modules you forgot you added, environment variables, etc. Basically you want to think about the experience of a new team member or customer who lacks the oral history and institutional knowledge of the project. Once a quarter is fine.
5. Agree to have offline hours where you work on your own tasks - marked on calendars if necessary.
6. Semi-frequent group meetings and rebuild days help here as well. This is where I was luckiest in that the team was more experienced in working together, so there wasn't much shepherding needed.
My advice is that you do your best to push for actual users having their hands on the software as early as possible.
And for there to be a direct route from the users to you and your team members.
That is going to matter more than anything.
As far as the team, you should have a chat room open all the time, and people know they will get a response within a few hours during work hours, or right away if the other person isn't really in the middle of something.
It should also be easy to enter a voice chat, video chat or screen share.
Everyone should know that the chat room should be used freely when necessary but not as a distraction.
The manager should be in the chat room. If he/she won't/can't pay attention, push updates for anything that requires their attention and weekly progress reports.
As things progress, some of the users should be in the chat room also.
Try to aim for a release that users are testing at least once a week, as soon as that becomes possible.
1. Support the orgs journey - This could be everything from accross requests or ad gov queries.
2. Experiment independentl - This is critical. If you don’t have the elbow rooms to explore, you’re likely taking directions from some turd.
3. Experiment with business stakeholders - This is how you learn about what biz (thinks they) wants. - Also critical.
4.(Internally) Open-source our teams findings - Try to generalize the technical components to a degree where others can utilize.
5. Consult with AppDev Teams - Sharing best practices, methods and pointing them to the open-source components as needed.
6. Build community - We host Bi-Weekly Task Force Meetups - Focused on tech-minded business stakeholders - On the off-weeks of these Task Force Meetups, we host: - GenAI Developers Meetups. - Focused on tech tech. - GenAI Office Hours
Sprinkled in there are white-glove training and general consulting.
1. How do you interface with your team (and how frequently)? A. Daily, if not hourly. Via calls, chats and emails.
2. How do you interface with your manager (and how frequently)? A. Ad-hoc and scheduled 1:1, my manager is a C level (smallish company, ~$40 in net profits.)
3. Do you have some recurring meetings? What is their cadence? A. Yes, but this depends on the employee, high flyers I let them set the schedule. Folks that turn out to need more help, I set the schedule, anywhere from once a week to once a month.
4. How do you take care of documentation? A. I have a background in Technical Documentation... Probably drives my team nuts. But I focus on getting tribal knowledge in to Wikis at least, formal documentation as required by regulation or policy/standard.
5. How do you ensure that you have time to work on your sprint tasks while context switching? A. LOL... In seriousness I weight my story points heavier as what I am working on is usually obscure and/or steeped in regulation.
6. How do you ensure everyone is moving in the same/correct direction? A. Through 1:1 and daily stand-ups. Plus monitoring the board. Finally, communicating the overall goals and obligations of the group. If one of my team members says "I've heard this before" I respond with "Good, you'll here it at least one more time."
I took the more challenging direction with my leadership. I manage people balancing their expectations and mine. I'll give someone enough rope early on to see if they can manage themselves.
Parting thought, I work with and worked for many veterans. One thing I learned from them is find your NCO, lean on them and reward them. Consider yourself a newly minted butter bar (Lieutenant) and don't assume you know best. But use your experience to guide the ideal direction, avoiding pitfalls you know about.
In my experience junior people often wait too long to ask questions when they are stuck on something out of fear of looking bad. But if you are junior it is totally normal to not know a lot of things and thus get stuck frequently. If it is something that can be Google’d, sure let them learn to look, but often it is something internal to the company and they just need someone to point them in the right direction.
I would take note on who was having problems and call them throughout the day to unblock the situation. Sometimes I would invite 1 other person into the call to share some knowledge and preferably have them explain it to each other.
In general I would try to make these calls educational rather than just telling them the solution. You want to build up the team so they become more and more independent.
When major new topics came up (new feature, completely new use-case) I would organise a team meeting to discuss the topic and work out a design. I usually prepared these meetings to the point I more or less knew the design we wanted to go for because the team was very junior. This allowed me to led the team brainstorm and occasionally guide them or point out issues.
The key is that you want to try to facilitate rather than dictate. If you dictate too much they won’t learn or learn slowly.
Second, junior people often say they understand something without actually understanding it. Have them explain it back to you. But don’t be too critical when they get it slightly wrong, that can be demotivated.
Also try to pull involve individual team members into higher level discussions from time to time. I would sometimes invite someone to the architecture review meeting. This helps them gain perspective.
Finally I would do a meeting twice a year to discuss their progress and ask their feedback and how they are feeling in the team etc.
This mostly applies to a team full of juniors. I bootstrapped two junior teams this way.
2. Weekly/Once-in-two-weeks with your manager to update on the milestones and address any updates related to personal/professional yours or on behalf of your team.
3. TBH, it depends, if you are involved in working with cross-teams. If it's the start of the project, the recurring meetings with PMs and other stakeholders should be thrice a week to know the requirements and address any blockers from a high level and tech debts that need to be resolved as a pre-requisite to start the project.
4. There should be at least 2 documents, one the PRD (Product Requirements Document) and a technical doc (basically a technical PRD document), this can include the architecture design as well. The technical side should be handled by you (the TL) and part of your team (to lead sub-modules and upskill)
5. You need to prioritize the things and work on them accordingly
6. Having regular standups helps you know the same.
This is the daily workflow, practical, no theory. There are a lot more details when you run a team, and you need a coach to help you do it correctly. There is no silver bullet solution for these questions. The important thing you need to know is that you should follow good practices like doing science: predict, experiment, retro => make changes and keep following the loops.
2. Ad hoc chats with manager, he is hands off other than twice weekly meeting.
3. Twice a week 60 minute meeting with the manager, product owner, researchers, QA, stakeholders. We demo new features to QA, finished features, and partially complete features to stakeholders. Plan new features as needed.
4. 3-5 minute video demos every two weeks sent to all interested parties
5. I block off several hours each day as quiet time for myself to do work. When I run larger teams (+5 engineers) I do not have personally assigned tasks
6. Pair programming, live code review once a day with each dev. I always prefer to hire devs who like to pair program, so ideally they will be pairing and rotating tasks regardless. Also promiscuous pairing, with tasks assigned to a pair stream not an individual. This ensures built in training and code review. No silos or solo work without significant input from a second dev ensures a minimum level of quality, catches issues early, and builds camaraderie.
I would say, this project sounds highly risky. I would personally assume only one dev will get any work done, and plan accordingly. What would you do if you knew the whole team would disappear tomorrow? You would set expectations, deliver the most important things first and get it into the stakeholders hands immediately. Do this, and the extra features produced by the other devs will just be gravy on top. Don't try to micro plan out every dev's time feature by feature, instead just ask the customers to order the most important features first and try to get it in their hands. Trying to actually plan a project with a timeline greater than 12 months has a <10% success rate in my experience. Instead try to deliver a first working feature into their hands in 3 weeks. Repeat. Don't ever try to fix scope and time more than a month out, it's effectively impossible. If you could do that, you could just predict the stock market instead and skip all the hassle
1. Daily
2. Every other week for an hour along with meeting when things come up.
3. Daily stand ups, every other week planning, retros.
4. Anything people work on that needs to be documented is done as part of their work. Changes to the system assume changes to documentation. Systems that others need to use more require more documentation but we don't put to much pressure on all of this because too much documentation can also be a pain.
5. Some people block off afternoon from meetings, I prefer to do this work in waves, when there is lots to talk about make sure these conversations happen, when everyone understands what needs to be done they are heads down working on it and I do my best to do the same.
6. Higher level meetings with leadership to align on goals get converted into team goals which are then converted into stories by engineering leads, in weekly planning we go over these tickets to make sure everyone is on the same page, sometimes new tickets need to be made for missing work but we try to make sure that everyone has enough work for the next chunk of time. You can check in on the status in standup and if something is off adjust something by adding more people to one ticket or breaking it up.
Another key thing to take into account is how to enable feedback from the people doing the work back up. You must enable the team to influence the goals and the work they are doing, sometimes they see a better way and it is important that they feel heard even if the path isn't changed.
2. As often as the manager wants to. If you don't need anything from them, most are happy to be left alone as long as you deliver.
3. Daily, standup-like. Keep it short if there isn't a topic that affects everyone.
4. I am not a huge fan of extensive documentation, because most people don't read it anyway and it gets out of date quickly. Just cover how to get started, and the overall structure so people can navigate. Keeping it short makes it more likely that someone actually reads it. But how much documentation you need depends on the organisation and project. It doesn't really matter whether you write it yourself or someone in the team. If you're lucky, someone in your team enjoys doing it. Just use some wiki-like system to make it easy to contribute. Or keep it in the repository as Markdown, if it's only for devs.
5. Depends on the project and team. But I have often tried to minimize the number of tasks I do myself, because as you suggested, it's hard to work on something when you're constantly being interrupted. In some teams I haven't worked on any tasks myself.
6. Talk to people and review their code. It's super-important to review as soon as the code is available, to minimize downtime and reduce context switching for the team members. Prioritize team members' code over your tasks!
(Some people also suggested pair programming. If it works for you, great, but I am terrible at it. Hard to explain, but coding and speaking are two very different things for my brain. I can't write good code while talking about it, and the whole thing is very stressful for me. I prefer to discuss code asynchronously or on Slack).
1. Be clear and concise when explaining and demonstration. The more clarity, the better. Lead with examples is always the right way. And it needs time to change the mindset of the juniors. The benefit is, one day, they will bring back good ideas/feedback for you and the team.
2. Always challenging what the manager told us, because they have different mindset ! Do not assume everyone is on the same page.
3. Surely, depend on type of problems, the recurrent meeting is nessessary to make everyone on the same page. Confusion is the evil for everyone.
4. Documentation as code, code as documentation.
5. Work smarter, not harder.
6. Do not be afraid to be wrong ! Be wrong and you'll get the right explanation from team members.
2. Weekly twice or once should be good, ideally this is the time for you to talk about the challenges you are facing and also talk about the good things that are happening. Make things visible.
5. Have some focus time for yourself, may be 2 hours per day to start with and adjust up based on the team's needs.
6. Review meetings/gant charts/milestones/sprint retros
1. at least 2x a week, group meets on Mondays and Friday to set weekly expectations, 1:1’s as needed weekly or bi-weekly
2. bi-weekly
3. See 1.
4. Documentation is part of “definition of done”.
5.& 6. Start the week with making sure everyone understands their week’s tasks, have a demo Friday to see what was finished. Then pair as necessary - maybe check-in Wed w/juniors. For seniors and up, know and track the multi-week goals.
There is no need to micromanage and make people hate their job. Give them substantial autonomy, and help them along the way with code reviews. It's easy to monitor what everyone has been up to by looking at their git log without having to ask them.
4. Unless you have a somewhat detailed requirements document based on actual customer input, you will build the wrong thing. All stakeholders should be in agreement with what's on that document.
6. For the love of god, no Scrum or daily standup, unless you want your team hate you. Weekly iteration meetings for progress updates might work better. Your 1-on-1's is a better way to track team progress.
2. I had a weekly 1:1 to go over concerns individually, a weekly meeting between team leads and product to ensure alignment and be apprised of business changes or problems, and an end of week meeting with other tech leads to coordinate cross cutting concerns. More of that crap you can cut out or strip to the minimum, the better. The weekly 1:1 with my boss seemed to be most important.
3. I generally don’t mind a tight, small and organized daily stand up, and it did mostly help me accomplish #1 (since everyone could schedule around it), but these meetings are very easy to derail and are vulnerable to too many cooks in the kitchen. So that, the aforementioned weeklies, triage meetings, refinement sessions, code reviews, architectural reviews, etc… the meetings stack up fast and were one of the most miserable parts. Some were useful, some were only situationally useful, everything else was navel gazing and micromanaging. I can’t tell you what the right amount or cadence is, but kill anything that doesn’t have a firm agenda, limited attendance, or much value. Do your best to keep your devs out of meetings as much as possible.
4. I’ve never worked at a place with an organized approach, we mostly just figured out what we need as we went. Too much documentation is taking time away from work, plus it all decays as projects progress, but no documentation is worse. I tried to bring documentation into my responsibilities, but would delegate small, focused chunks to team members that did the work. Leverage things like OpenAPI, generated docs, plantuml or equivalent to do C4, ERD, sequence, etc. If you need to delegate documentation, put it in your acceptance criteria or requirements and make sure they can just brain dump and move on (rather than fussing around with what tool to use, etc).
5. I put cards in for all my sprint work, whether it was programming or a placeholder for time spent in meetings. You only have a fixed pool of time, pretending that programming vs meetings vs code reviews vs anything else all come from magic parallel pools just does not work. Anything unexpected that comes along takes time from that pool. If someone wants to add work, something else has to come out, end of story. Block time on your schedule, too, and be confident in saying no if someone tries to sneak more shit in or blow up your plan. Also, make sure it’s clear from your manager what expectations are from dividing your time between leadership tasks and technical work. Give them feedback on how that’s working during 1:1s, gather feedback from your team on how well supported they feel and how well your team is on track, recalculate and feed back into next sprint. I think it’s normal for you to do a lot less technical stuff in terms of day to day, and you have to fight the urge to get down in the dirt if your team needs leadership. I ended at like maybe 20-30% coding except during crunches. I did not enjoy that ratio and ultimately moved into architecture.
6. Well, if you’re doing something like scrum, you should have a plan before you execute each iteration. Everyone should know the priorities and deliverables expected at the end of it, and should have been able to have a say on whether it’s doable, clear, and you have everything you need. That time is your opportunity to look at all the work and figure out approx. how long it should take to get each thing done (comparing a task to similar historical work and using that as a rough estimate for how long it will take can help you here… building a rubric for your team to guide you here is a good idea). The rest of the sprint is you gauging where everything is at at least daily. Stand ups are supposed to take care of that. If you feel like there is a risk of something falling off, that’s your priority to get back on track or adjust expectations (last minute changes to the sprint should be avoided if at all possible, though). Then you’re supposed to measure how you performed the last iteration against expectations, figure out how to improve, and you feed that into next iteration. There’s a lot of watching cards in their swim lanes and activity in source control (or lack thereof) and reaching out to people when you are concerned.
The TL;DNR is a lot of planning, just enough communication, and being the glue to keep everything together.
These are the wrong questions to the wrong people. "What do you need?" is the right question when asked to your team members.
There is a magic formula. But the variables are each of the actual people on your team. Not a theory. It's going to be hard work. You are going to get things wrong. When you do, stop doing that and work hard on what seems to be right.
Good luck.
For 1., 2., and 3., as frequently and synchronously as feels reasonable. Having a synchronous ritual of closing out the day (as opposed to opening it as is all too common) is tremendously helpful ("What did you all get done today? What warrants concern? Now, go home!"), and given that you're working in sprints, that reporting period should be good enough for most of the heavier-hitting touchpoints. Hijacking your sprint retrospectives for this is perfectly fine. If you need to meet synchronously more often for housekeeping, you'll know.
One-on-ones are a personal thing. Again, use your best judgment.
If the andon cord is pulled and kills the sprint early, say, kick your manager a quick email to let them know what's up. Their time is likely more valuable than yours, and it's worth trying to have trust that they'll let you know if they feel a synchronous meeting is necessary. Otherwise, the same advice on one-on-ones and other synchronous recurring meetings applies.
Everything else can be over email or your asynchronous messaging service of choice.
For 4., find someone with an MLIS degree. Seriously. Hire a librarian.
For 5., I'd strongly recommend adopting a practice that tries to minimize context switching as much as possible: just as in operating systems, context switches here are utter killers of performance and will slow you the hell down. Namely, if you have support obligations (for "site up," say) alongside needing to work on shipping and improving a product, establish a rotation (or possibly more than one) and include fixed-date product backlog items reflecting that/those rotation(s) to be considered during sprint planning that temporarily completely remove those individuals from product work. This will help keep those facts in front of you and make sure that the sprint workload commitment "feels right" given the regular reallocation of labor.
Completely removing those folks from product work will also help with bus factor concerns.
The team captain should run interference as much as possible for other interruptions like middle management drive-bys.
For 6., the name of the game here is what's called "one piece continuous flow:" the team is what ultimately ships things, not individuals, but it's the individual contributors coming together in lock step that enable each piece to be shipped. Folks going off on their own is fine in moderation (say, e.g., when reading and subsequently formulating comments to a design document or a report), but it can't be the norm.
Make your product backlog items trackable in a spreadsheet and try as best as you can to eschew relying on tools like Jira. I've had reasonable success with just giving suits an Excel spreadsheet with some VBA macros and pretty graphs: a lot of them know that tool well enough to make it work it turns out. Jira's nonetheless pretty familiar these days, but the complexity inherent in organizing work in epics and sprints and with tags and projects and workflows and screen schemes is a little too tempting when the actual work gets hard. Cut out as much meta-work as you can. Meta-work is expensive waste, and it, like context switching or rewriting your Emacs or fvwm configuration for the umpteenth time, will obliterate your performance.
As a corollary regarding meta-work, you can't scrub your bug tickets if you don't have bug tickets to scrub to begin with.
The team captain should have a habit of "management by wandering around" if they've doled out sprint work for the day to two or more subteams, albeit in a more systematic and regular and regimented fashion than the name implies. They should have a good "feel" for when folks are stuck and be willing to break through the bashfulness sometimes inherent with impostor syndrome by jumping in to pair with them. That feeling of not being good enough or a waste of time entirely evaporates when there's someone experienced roaming around to help proactively.
This all said, mobbing or pairing is only good to start, but you really need a collaboration of someone with proper product ownership (and not merely project management) and a sort of team captain on the development team itself to chart a course and make adjustments.
Hope this helps.
It starts in planning and other ceremonies. From those meetings, you should leave with everyone understanding what they will be working on and you understanding everything that will be done in total during the next few weeks. You should be preparing for these meetings with sorting and filtering the queue of tasks. Then you should be fleshing out the tickets as a team. Over time, the team can also make sorting/filtering decisions.
You should also make sure any gaps are filled during 1:1s and check in with everyone to make sure they have a reasonable plan. As time passes and people mature, you can relax these touch points.
Other than that, you should be plugged in to all work streams from your team. This requires public conversations and sharing status before too much time is wasted. So you should encourage everyone in your team to ask the team for help if it takes >20 mins being stuck on anything. By the end of standup you should know what everyone will be doing today. You should also be able to predict some of the places people will be stuck and expect to be asked about them.
Pairing people up on mini projects is a good way to keep productivity up and get people to become comfortable asking for help and helping one another. This is crucial since you don't want to be the only person answering things.
You should be talking to EM weekly and ICs biweekly in 1:1 formats. Those should have a mix of prepared topics and random ones.
Beyond that, I would schedule pairing time weekly to work on something and round robin invite people to it. This was a good way to understand where folks are strong and to rub off on them in good ways. For example during an early session, I found one of my engineers lacked deeper knowledge of the language. So the following session with her was planned to coincide with a task that leaned on that and we paired on it. Sometimes it was a task I chose. I often would bring up the thought in 1:1s and mention that we have a pairing session coming up and give ICs the option to bring something they want to work on.
All of this gets you to people working properly and learning/growing. The goal is to rely on ICs for what they can do and continuously expand what they can do.
If you know what to build and have clear line of sight, this is enough.
Beyond that your job is also to contribute at a company/organization level to larger initiatives and get alignment on various things.
Staying productive is hard. I'd often do sprints where I'm mostly heads down and have no meetings for the first week, but batch a lot of meetings to my second week. Batching meetings is my single biggest tool here to get focus time. I will happily do 2 days of all meetings with the remainder being all large blocks of focus time. Having 2 days worth of meetings peppered into my week kills me.
Aside from this, you need some sort of way to manage your work. I would have 3 lists - sorted by importance. I would add to the lists as I go and periodically groom them (different cadence for each list).
1. tiny tasks - anything small; perfect for between meetings; if a task takes 15 mins or less, it's one of these
2. long tasks - anything that takes 1 day or less (so like 5 focused hours?); typically smallish ticketed things, but as tech lead often not always the case
3. long tasks - anything longer than above; often research tasks or exploratory things
I limit the length of the lists - different for each list.
I would do daily code reviews of everyone's PRs, not necessarily commenting since that can feel overbearing.
1. What communication mediums best fit the team and overall company culture?
2. I think this is highly dependent on you, the manager, and the viability of the project.
3. What meetings does the team think they should start off with? No matter the answer, have a recurring meeting every couple weeks to assess and adjust any assumptions you make in these early meetings. Maybe you find you’re meeting too often, or not enough… or people are confused by where documentation goes, or whatever is causing friction. Make time to talk about it and come up with things to try to smooth it out.
4. Pick a place for documentation, which I assume will be somewhat dictated by the existing company culture or available tools… but have a spot with a basic structure, so it doesn’t become a question every time someone needs to document something. Templates may also help, depending on what it is.
5. You could agree that certain days are to be free from meetings, to ensure everyone has some heads down time, or create blocks where meetings go to avoid them taking the whole day. I also found it helpful to have a dedicated meeting for the team to get together to ask random questions, share things they learn, etc. When people know there is a place to do this, for things that’s aren’t super time sensitive (that would take more time than the stand up), they are less likely to fill random other times throughout the week or derail other meetings. Of course, if something is time sensitive and someone is stuck on something, that should revert back to #1 so someone can help them get unsuck. Something like Slack works for that, and team members can meet up as needed for that stuff.
6. Make sure everyone understands the goal of what you’re trying to do and why. Make sure they have context of the world around them, so they aren’t making decisions in the dark, or at least know enough to know when to ask the larger group. One thing I found really helpful at the start of a big project was to get everyone in a room to map out where we are today (not the ideal of what it should but the reality… assuming you are starting from 0), then map out what you’re looking to build. You can then draw the map(s) on how to get from point A to point B. Having everyone involved makes sure people see all the parts, so they have context, even if they aren’t working on all those parts. It also helps to get misunderstandings out into the open and cleared up, so everyone is on the same page. Some people moaned and complained about this when we did it, but after a while they got into it, and I found it extremely helpful to make sure we were all heading in the same direction. This is also a good time for everyone to get to know each other, and their background/skills, if they don’t already know each other.
This is how we ran things about 6 years ago in my team. It started off a bit slow getting all ducks in a row, but we quickly sailed past everyone else, because things were running so smooth. It was great. For a while I had to explain to my boss we were laying some foundation and he seemed a bit impatient by the lack or tangible deliverables. But fast forward a little and he was saying we were so far ahead of everyone I could go to Europe and chill for 3 months if I wanted.
Fast forward to now, with some major leadership changes and that old team broken up. Planning is done by a few people behind closed doors, documented haphazardly, where people are expected to spend their time hunting for docs they didn’t know where written to inform their work. The plans are always 30% done, and the people making them are a huge bottleneck, as they are a single point of failure and no one knows what to do without asking, as any decision made is deemed wrong, either due to lack of context, or ego. This isn’t what you want. It’s a mess… 3 years in and it’s still a mess like day 1. Make sure your team knows what they’re making, feels like they are part of the process, and can make some decisions along the way, within reason. If you try and do it all, it’ll be too much.
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).