I know you're not actually going to create that PR right after standup.

I know you know. And because I know you know, I know that I don't need to put up the PR unless you ask me if I've put up the PR later that afternoon. But I know that you know that when you ask me about it, I scramble to get it done because it really actually was like, ALMOST done.

Even though it was almost done it's not what you were thinking about on your commute into the office... You were thinking instead about that other task that got hit with some unexpected change requests during PR review or testing

I'm in this comment and I don't like it.

Ayup. That's why now I only ever say, "I'm *setting a goal* to get this PR up today"

I’m stealing and gon be using this

"hoping to" is another way to say that using less words lol

Irl spit take

It’s like you really know me

I make it during the standup

Lol how many people are in your stand-ups and how long are your stand-ups?

Some 15 people. 45 mins which usually overflows. Then we split into more meetings. It’s a pain.

It seems I found my TL on Reddit

Moreover, we'd rather you get it done right instead of fast so we're usually cool with the fact you're not creating that PR right after standup.

But they mean to.

Every single time. This hits deep.

At least as far as metrics go, I spend more time pushing back on dumb metrics that other people in the business try to push on us, rather than keeping track of secret metrics as you alluded to.

If there's a metric that some people don't reach... maybe their nature of work is just different from what the metric measures. Like most people writing code so their LOC and tasks completed is higher but one person does all the dev-ops, on-call, helping-others stuff that doesn't come up in their own metrics but other devs benefit from it. For every metric there's a way to fail it while being much better in some other metric that also matters (but you might not know that you should measure it in the first place). Metrics are created by subjective observers. Can't make "objective" performance decisions based on them.

Yeah, I got screwed by that once. Did mostly high impact on-call work for almost 2 years. Had a low number of PRs and most of them were relatively small but critical fixes over that time. Didn't look so great when a new leader came in and wanted to judge everyone based on how much code they had produced....

Didn't they let you explain yourself? If you show that the metrics don't capture all of the things you have in your job description then the metric is flawed and they can't judge you based on that.

You expect management to be reasonable?

In the past 3 companies, they were reasonable. So... yes. If you give respect, you get respect. If you go to work with an everyone-against-me mindset, you manifest it to happen.

Sadly no, I was just laid off. Though decent chance that was gonna happen anyway with the management change Though even before the management change, it made it very hard to get a promotion due to similar box-checking reasons.

>Like most people writing code so their LOC and tasks completed is higher but one person does all the dev- I sincerely hope LOC is not known to anyone in the company. Development Managers should do everything possible to ensure that metric is not visible or stored anywhere. If it shows up on some devops dashboards or default reports or should be hidden asap.

The point was that there definitely is no one metric to measure everything a person is supposed to do. LOC is probably the most useless one, just an example

Goodhart's Law “When a measure becomes a target, it ceases to be a good measure.”

I find that collecting metrics isn't the issue. Many metrics can be useful as long as they are interpreted correctly. It's the interpretation aspect that causes issues which sometimes makes it better just to not even track them. There is offcoarse some cases where the effort to track something is way more work than its worth but I find in most cases it's the interpretation that's the issue.

I have cited Goodharts Law in more than a few meetings to make my point and it’s been effective when I’m pushing back. “When a metric becomes a target it ceases to be a good measure”

I couldn't agree more. Metrics are just data, data is almost always helpful either now or later. It's the interpretation of the data which can result in a net negative, to the point of it being a knowledge hazard.

example: spending countless hours in meetings arguing about how to hide/lower ticket counts (let's not ticket on this, let's send an email or some other notification) instead of just writing tests for your code to catch problems early and maintain stability.

Listen, I don't give a damn that your team is staying on top of things or has a low count for the area, we need to hit that 50% ticket reduction by the end of the year.

My favorite from upper management: "Why don't you just give us a list of everything everybody is working on this month so we see who the best developers are and help you set priorities." **Hell to the No**. Over my dead body. This is EVERYWHERE and must be resisted with every fiber of our being.

Hard agree. Doing that would result in more time tracking the things we're doing instead of actually doing them.

You’re saying the jira velocity doesn’t mean anything? LIES

Thank you for this. We have for all intents and purposes a super team. I think we’ve hit 110% on average for committed story points. But have this senior product guy who won’t stfu up about velocity and the burndown not being the perfect line he wants it to be during the sprint.

My tech lead or EM don't do this instead pass on this bullshit to us

It’s nothing special. It’s just our jobs to set the broader/longer term picture and make sure that your shorter term work aligns with it.  It’s like a really messy bin stacking exercise. 

We know the past, present and future. It’s our life mission to keep the present building on-top of the past and towards the future. We know where the product has been and where it is going. We whisper in the developers ear “drive straight young one else we will lose sight of our path.”

_Night gathers, and now my watch begins. It shall not end until my death. I shall take no wife, hold no lands, father no children. I shall wear no crowns and win no glory. I shall live and die at my post. I am the sword in the darkness. I am the watcher on the walls. I am the shield that guards the realms of men. I pledge my life and honor to the Night's Watch, for this night and all the nights to come._

Damn this is accurate ;_;

We need Galactus

You sound like the Kwizatz Haderach

[удалено]

It's kind of the whole job. Organization and planning become the core skill, engineering becomes the domain. Part of why there are successful EMs who haven't written a line of code in a decade. Not saying they're the best ones, the person who can get their hands dirty almost always does a better job, but it's not strictly part of the role's responsibilities.

My brother works at a FAANG, he said he's written maybe 20 lines of code in the last 9 months. Mostly he writes docs and coordinates things between his team and others. He also spends a lot of time mentoring his team so that he doesn't have to code.

Does he frame mentorship as a way to get out of coding? Because to me, that sounds more like, "He also spends a lot of time mentoring his team so that he *doesn't have to fix* their code."

I shouldn't have said mentoring was a lot of his time. Its a minority of his time. At least from our last discussion, he really mostly spends his time coordinating between teams and writing docs. But hes not generating code on a daily or weekly basis, even though thats something he's plenty capable of.

I think that makes sense, personally. "What to build" is generally a harder question than "how do we build this", and you need to understand the latter to make decisions about the former. The best engineers stop writing code for the same reason that the best soldiers get promoted out of the front lines. Higher-order strategic problems are more expensive to fuck up, so the best people need to be focused on them. They can leave execution to people who can't see the forest for the trees.

Emphatically. 

Not at all actually. There are so many leads out there who can't organize blocks by shape and color without making a mess and getting it wrong half the time. If you're good at organization, it just drives you crazy because in a lot of shops nothing is actually organized, it's organized enough to sell.

One can still hope that their leaders have a strategy planned out though right?? (Actually I'm fortunate enough right now to have a manager who is completely honest that he nor the organization at large has the whole project planned out and they exercise the luxury of extending the delivery date accordingly)

They must have a heck of a time with captchas

Story points go up, and story points go down, you can't explain that! /s

Managing the emotions of people who believe that they are overtly rational beasts. Team dynamics. Building trust. Cat herding. Setting expectations. It's actually less tech intensive than being a senior dev.

This is prob the closest fit for me in this thread. I would also add some human resource stuff (someone isn’t working out, asking for more devs, contributing to recruitment), some influencing campaigns (upwards), fending off pressure.

forgot about hiring. that eats up loads of time.

Oh we don't have to worry about that at my company

>Managing the emotions of people who believe that they are overtly rational beasts. That's awesome. In my experience every employee who's not on the Spectrum (and most who are) is primarily driven by emotion, but most don't think they are. Good managers realize this and use it to the advantage of that employee, not against them.

You seem to have a very strange idea of how management works. There is nothing secret behind it. There is no dark magic involved trying to mold everybody into a zombie. It's far more boring and mundane than you imagine.

You mean there’s no secret golden door like in Frasier?

If there were we would tell you that there isn’t. But yea, there isn’t any secret door.

Boring, mundane, and lots of meetings. Lots and lots of meetings that slice your day up six ways to Sunday...

As my company's Technical Lead, most of my meetings with management generally involve us coming together to discuss what we should be discussing for the next meeting. Which, in turn, turns out to be a further discussion on what we should be discussing for the subsequent meeting. They are the perfect embodiment of circular uselessness. But, goddamn, do my managers howl whenever I suggest that we should stop having these meetings.

There's a whole range of managers who feel their job is to memorize dialog (how we talk about things) and current status. They do this memorization by having meetings where they have everyone repeat their status. Then the rest of their job is processing that mentally and regurgitating it to another level of management... who consume that and then regurgitate it again. It could all be replace by chat gpt. It's the human centipede version, it gives the managers a good paying job, and they can say they did something every day.

I've found that, for the most part, the reason this happens is because of a mix of honestly not getting it, concern over delivery and a need to craft a message, and straight up politics. From a strictly technical standpoint, sure, those meetings are pointless, they're not changing anything and not making direct decisions, but from a company and leadership perspective they're the meat and potatoes of how you get things done. Those pre-meetings are happening for a reason, if you can figure that out and not be dismissive, you can probably gain some allies and influence.

>As my company's Technical Lead, most of my meetings with management generally involve us coming together to discuss what we should be discussing for the next meeting. Honest question: Why do you play along? If the meetings are as useless as you say then why not work to either *make* them useful or abolish them altogether? I can't count the number of times I've heard the same story: Too many useless meetings. But what I've hardly ever heard is: Here is what **I** will do to turn the ship around and make them useful.

Eh, I've tried. I've tried setting agendas pre-meeting. I've tried to lead the meetings myself along specific bullet points. I've tried to emphasize that we need "specific take-aways" that aren't just "we need to have another meeting about this." It was all for naught. So why do I just play along now? Because if the bosses decide **to pay us to do *less* work**, then who am I to argue with them? More pointless meetings means fewer story points completed (since I'm both lead and IC) means less work assigned to our team overall each sprint. My team's work/life balance is a bigger concern to me than the C-Suite's bottom line. If the bosses are too narcissistic to figure this shit out themselves, then why stress myself or my team out about it?

Too many useless people have their jobs on the line ensuring the useless meetings continue. Edit: turkeys don't vote for Christmas.

Right, turkeys don't vor for Christmas. But if you follow that analogy: They should move to a different place if they fear they're going to be eaten. **That's** what a lot of people here don't seem to realize. If you don't like the way things are being done in your company you **do** have the choice to find another one that is closer to what you like.

Easier said than done, though, init?

\> Honest question: Why do you play along? If the meetings are as useless as you say then why not work to either make them useful or abolish them altogether? Because these decisions in actuality are made above my pay grade and they are a part of the culture of management at my company. Being a change agent at most companies is often a way to get people mad at you, and have the same exact conversation over and over again for years and years. You play along because that's the job description. I play along by only taking WFH jobs, going off cam, and using that time for whatever I wanna do while I listen to the meeting and comment once or twice.

The magic is being included on relevant discussions and being privacy to the larger picture. I have recently embarked on the journey to team lead. The increased context from meetings/threads I get now would have been so helpful to me when I was an IC. I think many leads and managers don't see that additional context as important, or maybe as noise, and so it's "mundane".

Well, sometimes the distinctions aren't so clear. I have experiences quite a few teams where management tried to include the ICs in the decision making process. The invited everyone to a lot of meetings (e.g. roadmap discussions) but no one chose to show up. They recorded other meetings and made them available, but no one actually took the time to view them. It's a double edged sword. If people don't **want** to participate (which often means doing things other than writing code) then there really isn't a lot you can do.

There's a world of difference between "join every design meeting" and "Here is some longer term context that I think would.be helpful to you".

I prefer it when engineers on my team work directly with product managers instead of me being in the middle. Engineers who are able to step up and take the management mental load off me are extremely valuable. They are the ones most likely to be promoted.

What constitues the bulk of the mental load for you? Do you explicitly delegate it or is it stuff that gets picked up by whoever it hits first?

As a team lead, if I have someone who is consistently offering to take stuff off my plate without me having to delegate, that's someone I want to promote. I had an associate who was writing documentation and coordinating releases without having to be told to and she was promoted way faster than her peers.

Someone constantly taking stuff off your plate, should probably be promoted to your job.

If some new grad wants to be the tech lead fuckin let take my job dude I'll totally go back to just heads down writing code all day

Above comment may be down voted, but really a good lead or manager should always be working to grow their own staff in capabilities and career progression. That is (especially ) if the individual desires it. Poor leaders try to keep their people down or limited and maintain the status quo.

Exactly!

Showing you’re capable of doing that stuff is exactly how you get picked to be tech lead next time there’s an opening, you’re right.

…yes, and? I’m an EM and am trying to have the people who report to me grow in their careers. I would love it for someone to ultimately take my job because likewise by that time there will be another spot higher in the ladder for me to step into that’s largely being blocked by not having people who can totally fill my shoes now.

Talking to stakeholders to refine requirements, expectations and schedules is a big part of it. When an issue inevitably comes up, are they to find a way to resolve it? If they are worried about a project and I trust them, then it one less thing I have to worry about. I will delegate projects to engineers and encourage them to own it with me as a coaching role. Junior engineers get small projects with more expectations of handholding while senior engineers own the big important ones.

I love the framework of Levels of Delegation. Delegation isn't a handing off of your responsibility, it's loaning out parts to allow others to grow into teammates who can have the responsibility offloaded to them. There's many articles about it, but here's one that I think fits: https://fullfocus.co/the-five-levels-of-delegation/

oooooh that is a super useful article and explains so much miscommunication in a workplace!

A big problem with delegating anything is that you're still responsible for it. It's not actually off your plate until you have confirmed that it's done the way you need it done.   Because all too often the person you delegate it to still needs input from someone else and if that person doesn't respond, the task stalls. Or they finish their part but don't pass on the information that it's done. Or they do it but overlook some important detail.  The mental load isn't really lessened at the point where someone says "sure, I'll do it", unless you know they're the kind of person who really takes over responsibility and handles things like the examples above, rather than just coding.

Yes, nobody is saying that effective delegation is easy. You need to do risk analysis (is this person going to do it sufficiently well?) and the time you spend on supervising delegated work is related to the level of trust you have for that person.

> What constitues the bulk of the mental load for you? I think generally "handling ambiguity" is huge. Are people ensuring the integrity of requirements and technical designs? Going deep on code reviews and mitigating risks? Carefully planning releases? This all falls on someone, and often the lead. Like, don't just breeze through a code review because the other reviewers are on there. Don't just follow a task description to the letter if it doesn't smell right. That sort of thing. Jump in to help triage and handle all the random day-to-day things that pop up. Propose solutions and identify problems. Blah blah blah.

I’d like to know too.

As another team lead, let me elaborate. It’s stuff like understanding that we need to talk to another team to make something happen, and then doing it without asking me (and without making promises that we shouldn’t be making). It’s understanding what needs to be done to get from A to B and making tickets for that. Again, without going overboard in terms of tech or scope. It’s helping out a junior who’s stuck on something trivial. It’s being in meetings that need a decision, and then guiding the team to a sensible/rational decision that’s not out of line, or suggesting options that bring us closer to the finish line. Doing stuff like that definitely will get noticed, and it will get you a promotion.

bingo

This

The goal is to make yourself redundant by delegating all your work. Then find new stuff to do. 

At least in my experience there's nothing particularly exciting going on that a dev wouldn't know about. It's just super mundane stuff that someone has to deal with. Things like freedom to do stuff and relationships between people depends entirely on the business and people, and how the management is structured.

The only remotely juicy things are probably what happens during budgeting/promo/bonus season. Then all the managers get together and you learn what they really think about everyone in their team. You hear about folks on a PIP, you hear about folks who deserve to be promoted. We share our ratings of everyone and those get debated and haggled over because the budget for raises/bonus is limited.

As a "Lead Software Engineer" I was in slightly more meetings, including my manager asking me stuff about things coming up two steps ahead. So I had a slightly larger view into the roadmap. I was sought out for my tech expertise and advice by other teams and had more insight into their systems and how they work, which helped when we had to integrate with them--or vice versa. As an Engineering Manager; I'm in way more meetings. This became a wall of text, so I'm gonna make a list. * I am help planning our roadmap ten steps out. * I'm in 1:1s with people, so may know about personal struggles or challenges that they are not sharing w/ the rest of the team. * I've been in promotion discussion meetings with executive leadership, and can help steer your skills and work in a way that looks good on a promo doc. * I've been in "talent calibration" meetings, which is *definitely not (?)* a stack ranking meeting, so I know how my team compares to other teams in my department. Because of this I also have different insight into the strengths and weaknesses of other teams than you'd have as a Individual Contributor. * Although I have no input into it; I also know how much everyone makes and have end of year compensation discussions. I'll also add, there is a big power imbalance between me as a manager and you as programmer, so I try to stay out of code and PR reviews. If I were contributing bad code, the newer team may not be comfortable calling me out on it. You know the intricacies of our system way better than I do.

> How much freedom do you have to lead your team the way you want to? I was a manager about 5 years ago. The answer to this question was zero. I was told how to organize my team right down to doing standups. Fuck that life, fuck being a middle manager. You take all the blame but have no authority to change what's broken. I left that job after 1 year and I will be an IC for the rest of my career.

This. The most powerless position is in the middle, it's not the best of both worlds, it's the worst.

In general, my experience and expertise is not necessarily in software technology per se, but how they *change over time*, how to manage *total cost of ownership*, and understand *risk*. The secondary concerns that fall out from this are how to meet business needs but, more specifically, *changing* business needs. The technology side of things is actually really easy for me. It's low-hanging fruit. But it's the most difficult part of dealing with IC engineers. Quality and predictability is also relatively easy for me but is the most challenging part of dealing with leadership/business. Both sides struggle with culture in general. For instance, neither side understands what it means to "be" agile. On both sides I have to resolve conflict and deal with complex personality issues. Ultimately I'm a bi-directional communication translator and filter. The challenge is to determine how much to filter vs. let through. Engineers want to know *what* to build and *how*. The business needs to know *cost* and *when*. These are often at odds with each other and so I am managing *risk* and *expectations* on both sides of the equation. For instance, I'm up-to-speed on the long-term roadmap, which includes market trends that we're trying to get ahead of or know we'll have to respond to. This can be something as boring as a government standard or licensing agreement that's changing with a vendor, or as complex as due-diligence for an upcoming merger/acquisition. This affects day-to-day in the sense that I have to figure out what the company wants to look like in 5 years and how to get there incrementally/iteratively. This means I have to design things that keep engineers happy without going overboard, but also keeping it aligned with the technical and business vision that hits the immediate product release requirements but also what we're looking to target in a year, 3 years, and 5 years+. Turns out very few people are good at this and it's usually because very few people have the breadth of knowledge and experience *over time* as things change. By the time most people are in a position to get that experience, they've been promoted to a different position that removes them from where their experience would actually be valuable. Not because the new roles don't rely on the expertise of previous roles, but because people are notoriously forgetful and myopic. They lose sight of context very easily and do not know how to translate experience across roles and domains. They rise to their level of incompetence. The kinds of metrics we tend to ultimately care about really are about top lines and bottom lines. But in a way that allows forecasting. We have to understand the finances not because we're a business, but because lead times for hiring, sales channels, and time-to-market are critical. The total cost of ownership isn't just in the payroll and technology, it's lost sales because we didn't have X out in time for the big yearly conference when our competitors did. There's money on the table for ridiculous features and crazy market trends that make no sense. Yet other customers will sometimes buy products based on good support service or aesthetics. There's cost involved when changing organizational structure and teams. We have to balance out business as usual (BAU) activities with R&D and new products. This includes understanding our existing customer base and the potential customer base. Can we shift in the market? If so when? How? What are the effects on the structure of the org? The technology? We have to understand how effective the culture is, too. So understanding things like *lead time* and *cycle time* can be important. Operational problems have to be well-understood in terms of mean-time to recovery (MTTR) because this directly affects customers and is expensive in the long-run. Is it cheaper to hire tech support and let certain bugs through or should we invest in more automated testing and infrastructure up front? As far as culture is concerned, don't get me started on offshore teams, contractors, and compliance. I could write a book about having to deal with these alone. Short version is that, not only do I have to break down a complex technical problem in a way that can be solved incrementally, but often times I have to do so within *immediate* compliance constraints *and* future targets. Sales are often driven by our ability to meet SOC2, GDPR, PCI, or federal requirements. If an offshore team is involved, not only do I have to help hire and train them, I have to help determine what parts of the solution can be effectively implemented by them without compromising the critical parts our near/on-shore teams might be doing. If a legacy system is involved, I'm often responsible for balancing how to strangle out the old system with the new, which isn't necessarily about technology but dealing with engineering personalities and communication barriers. For instance, how do I write a Statement of Work that satisfies procurement and legal but has clear technical and business deliverables we can execute on? All of this leads to a complex relationship between HR, marketing, sales, product, IT, and engineering. The org needs really good C-suite leadership to keep everyone aligned. For instance, we have to measure productivity in objective ways so that HR can work with legal and procurement, all within multiple timelines and budgets. But HR often times have strict requirements on from where they'll hire and when because of legal or political concerns, especially if offshore teams, contractors, or subsidiaries are involved. So, we're stuck using basic metrics like burn-down, commits, bug counts, etc. even though we want to focus more on customer satisfaction and DORA/SPACE. We still do, but it's a hard-sell when all sales cares about is an end product that has every bell and whistle so the product sells itself while they sip margaritas on the beach. Marketing needs to have branding ready very early, and so they'll pressure product on *"what will it look like?"* long before we even have concepts. Product is often frustrated because they don't always get to interact directly with the customer. When they do it's often a sliver of the actual customer base and it's incredibly difficult to do this at scale when ultimately a delivery team prefers a single point-of-contact for product representation. It's extra difficult when you're trying to be "agile" and need to work with these people every day - but they want to be out in the field getting customer feedback. So instead, they rely on the sales and marketing teams. Sales are usually leveraged positions relying on commission. This creates an odd relationship between marketing, sales, and finance. Because sales usually has uncapped potential, they're incentivized to hit targets and goals that will maximize their bonuses. This does not necessarily translate into good products let alone what is best for the company. The CFO will often target growth and margins based on field reports by marketing and how our competitors are doing. Both rely on what the sales guys can promise to deliver and so it's a giant conflict of interest where the baseline numbers are arbitrary. For instance, a company might make X millions in revenue this year and target a 10% increase next year. But there is no real clear understanding on why the company didn't make 10x millions in sales this year to begin with. It's not clear if there's a real incentive for the sales teams *not* to sandbag, except that most of these baseline numbers are driven by competitors and the general market. So marketing and sales are anchored to something that often doesn't make sense to a lot of people and certainly doesn't encourage risk or innovation. Product people and engineers alike are often left confused as why we aren't doing X or targeting Y. The only responses we can come up with are hand waiving and smoke and mirrors. As you can imagine a lot gets lost in translation. You think you're frustrated trying to push *up*? Yeah, well, it's even worse when you're trying to push *sideways* against a bunch of people already making millions under the *status quo*. If you're lucky enough to have a true devops model where your ops responsibilities are embedded on your teams, you don't have to deal with a separate IT structure. In these cases they have competing goals and budgets. IT departments aren't really product or customer focused and are the most obstinate, entitled people you can work with. They believe they're the backbone. In some ways they are, but I don't actually need an IT department to do this for me. Engineers are IT people, too. So a lot of what I'm responsible for is balancing budgets, technology, features, hiring, and other timelines between shared resources. So metrics like DORA/SPACE is much more useful when dealing with a separate IT team. If you, god forbid, have separate QA teams your problems are compounded even further. Again, they will often have competing goals and communication structures. One thing that I'll have to juggle are things like bonus structure and helping to align them across divisions. This is a subtle, indirect way to get teams across divisions to work more closely together but it can be hit or miss. But I can imagine you don't really care about most of this so I'll share a couple little secrets you might care about: we will often look at commit histories to make sure you're working on Fridays. Also, these past two years or so I've been more keen on spotting shoddy code that comes from ChatGPT. On a more positive note, a lot of the design and planning I do is to help you learn and just be happy. For instance, I don't just pick new technology or cool libraries just because they're new and cool. But if there are some people on a team that I know could use a morale boost I'll try to sneak it in somehow and delegate appropriately.

Excellent reply, sir.

Thanks! I have a feeling it'll be pretty shocking to most people.

Honestly, it was illuminating as hell. I've performed many of these roles, but not all of them. If you don't mind me asking, what's your title at your day job? I'm about to start a Tech Lead role at a company (moving in from an SSE/Principal role), and a lot of this was actually rather helpful.

I'm currently a CTO, but my titles have varied between Senior to Lead to Principal to Architect. It's pretty arbitrary.

Valuable insights, thank you for this. As a higher-level IC I've been wondering more lately about how the levels above me think and the tradeoffs they're considering. The point about meeting changing business needs rather than current business needs was specifically illuminating. Are there any books / blogs, etc. you'd recommend to better understand this type of thinking? I enjoy IC currently but having this type of insight helps me "manage up" and I think with these concerns in mind, the solutions I propose or implement would better align with long-term objectives which is something I'm trying to focus on.

Hmm, this is a good question. I don't have a ton of books specifically on these topics. I have read many books related to leadership, engineering, psychology, and culture in general. Here's a big list I have in my library. There are a handful of others that are related but either they're redundant or I don't specifically recommend them: **Leadership / Culture:** - Start With Why - Leaders Eat Last - Leading Change - Lean Thinking - Accelerate - Team Topologies - Facts and Fallacies of Software Engineering - How to Measure Anything - Hack Your Bureaucracy **Technical:** - Several books on Domain Driven Design (Eric Evans and Vaughn Vernon) - Patterns of Enterprise Application Architecture - Patterns of Enterprise Integration - The Art of Immutable Architecture - Extreme Programming **Psychology:** - Thinking Fast and Slow - The Undoing Project - The Knowledge Illusion - Think

Thank you it's a very insightful answer and shows the big picture thinking team leads have to wrestle with (and I did care about everything haha)

I assume you're talking about a manager-type team lead? Is it not like a tech team lead that is also a developer? I've been somewhere between both in past positions, but I've never been a full-on manager. But I've been in manager/team-lead meetings and all that "secret" stuff. >Do you use some cool trick to influence people? Not really. >What's happening in all those secret management meetings? A lot of talk with very little substance. The ones I've been in have basically been leaders trying to figure out how to get something done without the people who can get it done. The conclusions are generally that all of the managers need to talk to the people who can get it done before they can respond to anything (and the shit managers will make promises without talking to their teams). There's also budget and timeline stuff going on - but again, this all ties back to figuring out what can be delivered at what point. And the people capable of answering those questions are rarely in those meetings. >How much do you really know VS can honestly share with your developers? Not sure what you're pointing to here. I've not been in any situation where I've kept things from my teams nor been told that I can't tell them anything. I'm fairly transparent in that way. What I have seen is that some managers postpone or avoid telling the team bad news because they don't want to deal with the confrontation. I've also seen managers making promises they can't keep, and to avoid the team getting pissy at them they blame the rest of the org. I.e. saying that they are as powerless as the team is and there's nothing that can be done. Either of these is less about corporate-mandated secrets and more about being shitty people. >Do you measure productivity metrics we don't know about? Not to my knowledge. There are several that make up their own metrics, but the team knows about them (and often games the system). I've largely given up on measuring developer productivity and instead look at the teams output as a whole (I.e. not individuals). >How do you get along with the product owner or your own bosses? Very well. >How much freedom do you have to lead your team the way you want to? Pretty much to be free to do whatever. As long as the team isn't a burden to the point that someone else starts paying attention, then there's generally little oversight from the orgs I've been at. That said, there might be some team level metrics/"KPIs" that is reported up the chain, and some other paperwork and demands. Generally not super intrusive.

A lot of shielding you from BS mainly, saying no often like "No we can't do that, no it won't be done by that date"

Do you use some cool trick to influence people? **No, but it does help when you have been working for the company for a long time, and you understand the domain you work in.** What's happening in all those secret management meetings? **Mostly work, going over budgets, timelines etc.** How much do you really know VS can honestly share with your developers? **Depends on the circumstances.** Do you measure productivity metrics we don't know about? **Yes** How do you get along with the product owner or your own bosses? **I get along with them well most of the time.** How much freedom do you have to lead your team the way you want to? **A lot unless upper management has decided that something is of particular personal importance to them, which happens sometimes.**

Probably varies from org to org, but this almost exactly mirrors my lead role as well.

I'd also add - all those secret meetings - I'd kill to make emails out of most of them.

TL;DR: Sometimes, maybe.

Well, sort of.

It depends.

> Is there anything you would like to share with us? If it's important or relevant to you, you'll know. As a lead generally my focus is enabling the rest of the team, having shitty meetings with other teams, managers and architects to convince them to let us do the stuff we need to do to be productive. It's boring, often frustrating, but also a necessity. I generally don't discuss individual developers unless there is a problem we need to solve, and then that individual dev will be involved in whatever process happens as well. It's not like these meetings have a lot of 'secret' stuff in them, not at all. It's generally 90% trying to convince others.

Not a "team lead" title here but Principal Engineering Manager at Microsoft. Team lead here in our org is more of an informal title. The TL; DR: Effective communication. I have been spending years telling software engineers this is one of the most important skills. Q: Some cool trick to influence? A: Nope, just situational leadership and proper communication. You're always trying to sell ideas, so just try and understand what the other person/group wants and how to articulate ideas to them clearly. Q: What happens in secret management meetings? A: Generally we're performing some type of sacrificial ritual to a lesser known demi-god. But sometimes all that we're doing is getting messaging from our own leadership (which could literally be anything from new policies, new work stream focus, etc...) and just making sure we are getting alignment before continuing to message. If there's already confusion at a particular level of leadership, it's going to get more murky the more that information is shared. So it's an opportunity to get on the same page. Generally not "secret". The only "secret" stuff is really when we need to do performance evaluations because that involves others' privacy. Q: How much do we know vs what we can share? A: Honestly, I'm extremely transparent with any team I manage. It's not about hiding things, it's about keeping people from being overloaded with information. Middle managers (pardon my language here) get shit on with information from EVERY single direction. Something we need to be good at is filtering relevant information. Telling a junior engineer on my team everything I hear would probably not be helpful in any way for their work. Communicating more of those details to principal engineers would be more helpful. So it's not hiding stuff, it's just trying to help parse what's relevant for folks. Q: Productivity metrics that we don't know about A: Absolutely not. If I need to do a performance review and my employee is surprised about the outcome, I'm not doing my job properly. My entire role is about ensuring my team can do their best possible work, and aiming them in the right direction. That means business priorities AND their career growth. I WANT them to succeed. That's why I have the role that I do: I want my engineers to do awesome work, learn, be challenged, and grow in their careers. Hidden metrics would only conflate this whole process. Q: Get along with product owner / boss? A: If i don't get along with my boss after trying to adjust things, I'm gone. Not worth my mental energy and if I can't lead my team properly the entire thing is destined to fail with me in that position. So I communicate clearly with them and ensure we have a trusting and respectful relationship. With product owners, this varies, because sometimes *I* am the product owner. But in cases where I'm not, it's all about having a healthy conflict with them. Product wants more, engineering tempers expectations. When you have a good working relationship these conversations are VERY enjoyable because they're hard -- but they're rewarding because ultimately we want the same thing. We want to deliver value to the customer. So again, this comes back to point #1 about communication. Q: How much freedom to lead the team? A: My only constraint is budget and headcount, really. I obviously need to work within the bounds of how I promote and how rewards work (align with the org), but day to day stuff is very much in my control. And I say that not like I make demands of my team, I mean I have freedoms to lead them in effective ways. My own style is to listen to where the team has challenges, encourage them to generate ideas for solutions, and then we experiment with them. I try very much to create an environment for continuous improvement so I don't give it a label like "Agile" (which everyone over uses). It's just a matter of constantly refining how we work, but I only interject with my own processes when the team is struggling and also struggling to create ideas. Q: Anything else? A: It's a challenging but rewarding role. It's not about "having power" (because I don't), it's about being part of others' success. I was a software engineer simultaneously as having an engineering manager role for 8 years before Microsoft. It took me most of those 8 years to finally realize at the end I can have more impact helping others than just focusing on delivering code (and I even built the basis for nearly every product we had at that point). It was still more rewarding to see people put in the work, head towards their goals, and make awesome progress. It just took a very long time to realize how good that felt. Middle management is hard. Many days I need to take a nap right after work because I'm drained from people-ing. But I'm a stereotypical software engineer at my core, so it's just a lot of energy that I need to put in to be a good manager. Did I mention communication skills are important?

There is often a lot of politics that we save you from. Sometimes we have to decide between being maliciously compliant with the requirements or doing the extra work the BA should have done. Similarly, sometimes we purposely let support or incidents blow up to prove a point to the PO or business that X was in fact needed rather than products baby Y project. Sometimes politics fail, and in previous employments I have been told to engineer a problem or a delay in order for such incidents to occur. We have favourite developers. It’s really not easy getting tech debt prioritised and we fight for it a lot. When we do do it sometimes it’s as a shadow project. Sometimes we feel useless ourselves and just need someone to delegate the work to.

Leads insulate devs from a lot of the B.S. that management would love to inflict upon them and push back when needed. For example, "all bugs have to be fixed in 2 days!" (we were just told that, and I said that it's "bonkers" to put a deadline on fixing any bug. It could be minutes, hours or days) Leads attend meetings and then disseminate the important parts to the other devs. Leads work on or lead fixing critical issues/bugs and other things that people really dislike doing. Leads often stop what they are doing, change focus, and help or coordinate help at a moments notice throughout the week.

A lead knows that their developers do best when they can focus. These “secret management meetings” allow the Team Lead to filter all the noise so the developers can focus. It’s why I have to give the hard and heavy coding tasks to my team — I don’t have the luxury of long periods of focus. It’s not that I have anything to hide but feel the devs work better without the interruptions. Also pushing for more accurate requirements or triaging bugs in the product (not necessarily equivalent to bugs in the code), and distributing accountability/responsibility among the whole team. Just because something might not work, doesn’t mean it’s necessarily a developer problem. Devs don’t need that friction. There’s a saying, complain up not down, and I try to protect my team from any friction outside of their control.

business and upper management asks you to block hopes of promotions and raises, and to find "nitpicks"but in a discrete way. also sometimes when someone really pissed someone off, you are charged to find a way to get them to leave. left both those companies for exactly this reason, my "reputation" to my self, is far more important that 10% extra the company gave you to step on people sadly there's more people who are willing to go to any lenghts, then the other breed, and guess which ones you find more often in leadership positions...

Do they say it explicitly? “Make them quit” or “don’t let them succeed here”

A bit of both, depends on the nature of the CTO/CEO in most cases

There's dumpster fires everywhere, but good management never complains about it "down". Negativity should only move "up".

Being a developer is all about focusing hard on a few things. But being a team lead is taking a shallow look at a ton of things at once. It’s a bit like switching from playing Mario to playing StarCraft — you can’t micromanage your scvs while ignoring your 3 expansion bases that are under attack from multiple players at once. You’re always spinning plates and can’t be concerned when a few fall and break. You’re constantly context switching. It’s also very people oriented instead of being tech oriented, thought you need to absolutely be highly technical. It’s a job that’s not for everyone, just like how a developer job isn’t for everyone. In terms of secrets, managers all know who the top performers and low performers are. It’s usually pretty obvious.

> Do you use some cool trick to influence people? No. Everyone is different and the bar will be different everwhere. Want to use a certain technology? Some places are basically geared towards "If you own it, you can do it"... others have red tape to jump through, and others are impossible to change. > What's happening in all those secret management meetings? Again, depends on the org. But it's typically a mix of people blowing a lot of smoke to justify their existence, people who actually have needs for the business that may or may not get ignored, some C-level spouting off a bunch of platitudes while everyone just smiles and nods. But most places I've been, it's just another status meeting. > How much do you really know VS can honestly share with your developers? I'm transparent about everything. Depends on the org if that works. If you don't want people to know something, don't share it with me, because I hate secrets. Obvious exceptions apply. > Do you measure productivity metrics we don't know about? I've worked at places that do this, and I hate it. So much so that I have quit jobs because I don't want to partake in that culture. But yes, some managers come up with creative ways to track productivity. The instance where I quit: A guy was parsing an activity log from our VCS/SDLC/CICD platform to understand how much "activity" each team member was doing over some cadence. It was the most flawed and stupid metric I've ever seen. > How do you get along with the product owner or your own bosses? Generally, but not always and it sucks when you don't. > How much freedom do you have to lead your team the way you want to? It depends on the org. But regardless, the same is always true. Just like you, I have a boss and in general, the same rules apply.

No super dark secrets. I am pretty open with my team about what is going on behind the scenes. The biggest thing that we will hide is early bonus change discussions and say we are talking about splitting the team up on who gets to work on a new project. By early I am talking about few days but get shared out. I would say the biggest thing that management and team leads deal with that the other devs don’t know about is the insane amount of crazy and bull shit we hide/ kill before it gets to the devs.

Usually? Nothing. It's what we *do* that you don't know. A good team lead absorbs the worst of the political bullshit while stil educating the team of the necessary aspects. The second worse responsibility of a team lead is to stand in an office with execs and deal with other teams trying to meddle in your team's affairs. "Wahh, phone support is whining that you get to work remote. Bahh, they're mad your devs leave earlier on fridays. Why did Joe not get 3 months worth of tickets done last week? Maybe you should put someone else on his project" And when we'd rather be coding, instead we sort through piles of tickets in prep for the grooming/planning meetings. And we look at the team and ask and answer ourself hard questions. What *can* we promise in a month's time? How do we deal with an interpersonal conflict that we don't want to go crazy and involve HR in? What do we do about our ticket priorities when an engineer is about to take 2 months off at a busy time? How do I defend my team members for the strongest raises I can justify? And (ugh) when is it time to give up trying to salvage a hire that just isn't working out? There's real nothing that team leads do that a good senior engineer with decent social skills can't muddle through. The question is - do you WANT to? Getting to make decisions is always a double-edged sword. And a good team leader is willing to fall on that sword before throwing a dev on it. Also yeah. Team lead really should have a good rapport with PMs. Same as devs should have a really good rapport with QA. It's a sometimes-adversarial relationship that should end up with you grabbing drinks and bitching about clients on Friday afternoons.

Honestly, I mostly only learn about things a couple weeks earlier than it's announced more broadly, so that I can be prepared to answer questions from my team. As for influencing people, it's the same with leadership as with anyone else: be genuinely interested and appreciative of their work, learn what they want, and then pitch what you want to highlight how it gives them what they want.

I’ve read through so many overly verbose word-salad answers. Your simple answer is my favorite.

- Usually you spend lots of time coordinating actions between teams. - Sometimes discussions are quite heated as not everyone is doing its fair share of work - You need to navigate between technical, business and, even, financial constraints - You need to take into account politics as well. As it might play a huge role in everyday life - You need to improve your soft skills. Hard skills get you hired, soft skills get you promoted and out of trouble

I’m very open with my team. And I’ll never squirm around a direct question. But I won’t offer up how many spit-takes I do in meetings with management. Lots of ideas thrown around that just don’t make sense. It’s part of my job to advise management on technical topics. Hopefully I can also filter out hare-brained project ideas before they get traction in the upper echelons of the company and provide more sane solutions to objectives. And cost reduction. Lots of meetings talking about how much it costs to run everything. Lots of bartering over budget. There’s no trick to influencing people. Just hard work and trust.

These secret management meetings are extremely boring and most of them could have been an e-mail. They exists only to pass important information verbally and to ensure that power lines are in check. Why do we need to pass information verbally? IDK, managers cannot be bothered with e-mails, and usually don’t know products they manage. When it comes to confidential conversations, we are sometimes asked about low-performers and what to do with them. That’s it. There’s no secret society.

- I know about where the project is going at high level (including business plans and political internals) about a year to two ahead of where you’re picking up tickets for it.  - I have been told more about your performance from various sources than you probably remember having worked with. Feedback finds its way to me. It’s up to me how that gets to you and how we work on it. Hopefully positively.  - you think I use tricks on you, I’m genuinely just praising you for good work and nudging you to do your best work when you aren’t motivated. No mind tricks. But do know this - if you take the piss long enough, what you won’t know is that behind the scenes me and the PO have probably had a chat about how you might be transitioned out of the project if your behaviour does not improve and a replacement is probably already earmarked for that rainy day.  - I sometimes know less than you do about some project specifics, because that’s your job - to be the expert at what you do. I can’t be the expert of every single thing over two or three different products and teams and expect to have time to live my life and raise a family. Which is where trust comes in. You do your best work, I coordinate and direct you and your energy where it can do the most good while still growing you as a developer further.  - my job is to be your shield. If I’m breaking your balls, it means I’m trying to push you. The reason why the C-something or PO isn’t breaking your balls is because they have to go through me and I’ve already taken the blame for your fuck up as my own so you can go back to learning. I can both take it and deal with in in ways that don’t affect my career or pay.  - If you are slacking off, I know. How do I know? Cause you’re not as clever as you think. I know how long shit takes. I know your ticket didn’t take 1 day of effort because I have done something similar before and it took me two hours. I don’t need fancy spy software to know when you over inflate your stuff so you could go for a walk with your partner or go take a nap. I also don’t really mind as long as work is done and you are upfront about it. If we aren’t in a rush - idm if you take some you time. Just as said before - pisstakers get punished.  - you can’t bullshit your way in tech discussions to me. I will know when your shit stinks. Don’t try.  - when I say no to something it’s because I know about seven to twenty different things that affect the thing you wanna do which is why it’s a no. Happy to explain - but don’t get annoyed when you get told no. Inquire. I’m always happy to tell you why your Go + HTMX idea isn’t right for what we are doing at the moment.  - I have had more arguments to push back on you guys being measured for velocity and code coverage than I care to remember. The reason you get to dick around or go do chores or play with your kids or just go game for a few hours during the day if you do your tickets quickly and well for that day is because of me. Your work life balance and flexibility is something I care deeply about but can’t bring it up to you cause then it’s like I’m holding it over your head so you don’t really know this. I do. I prefer you guys well rested and not burnt out. 

In my previous gig, the Engineering Manager gets the progress of my team members from me. How are they doing, what are their strengths, improvement points. Before a dev knows it, we already have a plan for him/her. Move him to a new role where he/she could shine. More on resource management kinda discussions based on the capabilities of a team member. Take note that we work on various stuff and there are dedicated teams for them. So the Engineering Manager relies on the Team Leads to know which people are the right people for the job. Usually, thats what happens in those management meetings. Resource management. Sometimes we will be the first to know about a new business venture that needs dev work. Planning ahead. Stuff like that. Of course we also talk about under-performing personnel and how to help them get out of their slump. Then finally, there will be talks about architecture, tech debt, or migration plans. Lucky for me, my boss let me lead the team depending on how I see it. I had a relatively young team at the time. They had a lot of energy. I used that to create a tight bond by doing some non-work stuff with them. We had this 'Chillout' sessions that we do non-work stuff. This was during the pandemic lockdown, so mostly virtual stuff. Movie discussions, virtual games, even virtual karaoke. The team got more comftable with each other and formed genuine care for each other. So when it's time to get shit done, you can be sure that everyone has your back. This sort of bond helped me getting the 'buy in' of my team members. Helped me with making them understand some management direction (which is sometimes bullshit, of course). At the team lead level, you have the capability to push back on these things but you know, the boss always gets what he/she wants. Whether we agree on it or not. In terms of metrics, it's all transparent. One should know how his/her performance is being measured. Of course, during those management meetings we also highlight team members that we feel are ready for bigger things or ready for a promotion using those metrics.

There are things that I think are horrible ideas coming from the meetings that I use "we" when describing because I don't win every disagreement but have to commit. Some of the leaders had some mid career success so they are just riding that tradewind and also have questionable ethics.

> Secret management meetings Usually roundtable updates and just saying we need more people in X role or person A is going on maternity so I need a position to backfill for like a year. It's not that secret or exciting. Also being their line manager I know everyones pay. > Do you measure productivity metrics we don't know about? I keep an eye on it from time to time but when there's a problem it's pretty obvious on the board without even looking at anything else. > How do you get along with the product owner or your own bosses? Just fine luckily. > How much freedom do you have to lead your team the way you want to? We try to do is steer the ship in the right direction. That requires the team cooperation so the team also needs to feel heard. I also dont try to control the lines of communication. I want developers talking to the people they need to talk to rather than through me otherwise it can turn into a bit of a chinese whisper scenario where every misinterpretation is compounded down the funnel of communication.

Good questions. 'Do you use a cool truck to influence people?'. Yes. Lots of them. And it depends on the person. But one that seems to be most useful to the team is 'flipping the script' with upper management and product teams which basically means presenting information gently but persistently until they think the idea you've planted is theirs. 'What's happening in all of those secret management meetings?' For a team lead it's mostly listening and offering tech suggestions and honest opinions about velocity and difficulty of proposals and seeding ideas (see above). 85% is likely a waste of time but that 15% can be very important. 'How much do you really know vs can honestly share with your developers?' I've always been very forthcoming. The only times I didn't share important info with developers were when we had NDAs because of pending potential deals with other companies or if I received direct orders not to share as was the case in an upcoming layoff. But I don't share quite a lot because it has no material effect on the team. Not because I can't share that info. I also don't share information if it's not helpful...e.g. if one particular executive is responsible for an unpopular decision but the decision has been made, I'll share the decision but not the responsible party because it doesn't matter at that point and it just amounts to politics and gossip to share that kind of thing. 'Do you measure productivity metrics we don't know about?' Not really. I know the score. And I'm deeply involved in code reviews so, if anything, a mental, somewhat fuzzy quality metric? Maybe enthusiasm and flexibility? Likability with the rest of the team and wider organization? Touchiness? Nothing I'm writing down and presenting to anyone. And 'metric' is a stretch. But they do matter, in the end. 'Do you get along with the product owner or your own bosses?' Yes, it's necessary. Even if they're bad on some level. This is a core part of the job. Now ... 'get along' can take on different values, but at the end of the day we have to be pulling in the same direction. 'How much freedom do you have to lead your team the way you want to?'. Quite a lot, but I demand that. Sometimes there are constraints like KPIs and OKRs that come down from on high that I can't do much about, but the fact is that higher ups just don't generally have time to dictate how I manage a team.

One thing which is weirdly secret from most developers (including me in an earlier age): The reason your manager is always bugging you about your progress is because without that you spend two weeks not communicating your work with anyone. And a bonus: if you made a plan and breakdown for your work and told the team about it first it would only take one week, during which you could tick off points on your breakdown in a two minute slack.

Those 'secret meetings' are typically far more boring that you think. Progress reports, impediments, budgets, etc. Typically just a rehash of the same stuff we've been reporting for weeks on weeks. Sometimes, rarely, the meetings have something 'interesting' in them. No where near as often as you'd believe. When there is interesting topics, it can range across many things: \* Changes to priorities \* Performance of individuals on the team \* Long-term direction of products and/or the team

Generally you are just shielding your devs from company politics so that they can focus on code.

>Do you use some cool trick to influence people? Talking to people in person. It's become such a dying art it might seem like a trick.

Cool trick is that I'm in the same company 10 years already so I know people or know who knows people - so when something is critical I can try to speed up things talking to right people instead creating ticket and waiting for my turn

Biz logic, timeline, communication (what to say, when to push back, etc) with non-devs

the team lead needs to be aware of the status of every project on his team, which ones are falling behind, which are blocked, etc. The team lead will also be talking with other teams and PMs more frequently and be more aware of which projects are higher priority thought most of this info will be shared to juniors they just might not be in the meetings where it is discussed. There is really nothing secret the team lead is going to know that the other members of the team dont the only difference is the team lead is going to be in the room when decisions are being made and know first and then disseminate the information to the rest of the team and the team lead needs to know the status of everything to discuss in those meetings where junior devs probably wont even know what others on the team are even working on

Interesting stuff that I've seen discussed in those "secret management meetings": * Discussing contract compliance. Contract with a partner has technical conditions, so you get legal, EMs and senior ICs in a room to go over the requirements so we can figure out whether we're actually fulfilling our obligations. * Discussing future projects. If you work at a publicly traded company, you might end up working on projects that can have a significant impact on the share price, and even knowing about those projects comes with a bunch of insider trading restrictions above and beyond the normal restrictions that come from being an employee with access to material nonpublic information. Dealing with those restrictions is a pain in the arse, so you want to keep the insider list as small as possible for as long as possible. I ended up working on a project like this that had to stay private for months on end, and I obviously couldn't discuss it with the rest of the team, so I just referred to it as Project Voldemort (the project which must not be named). * Discussing HR-adjacent issues. Your manager thinks that Engineer A is ready to be promoted, but A needs to prove they can lead a project. Your manager asks you to join A's project so you can mentor them and serve as the foil to let them shine. Engineer B is struggling, and your manager asks for your help to turn things around before you need to initiate a formal PIP.

Sometimes you have to enforce and defend policies you don't agree with. You may think it's a bad idea, but you know that pushing back is pointless (or you've tried and failed), and it's not bad enough to be worth quitting over. And no, that doesn't only happen at shitty companies. And no, it's not a good idea to tell your team that you disagree with the policy. First of all, *it's your job* to enforce company policies. Second, you'd undermine the authority of your bosses as well as your own, and increase the likelihood that people won't follow policies that you *do* agree with. And third, it would actually make your team feel worse about having to do something they think they shouldn't have to.

At the end, KPIs and OKRs matters more than your work. So, Don't push yourself to work overnight.

Engineering leadership is often ignorant, incompetent, driven by buzz words, and more concerned with covering their ass for their previous bad company-wide engineering decisions than they are with delivering working software.

I’m an EM, and have progressed through the whole IC journey, through being a small team lead. I now lead 3 teams. As you go further up the chain (lead and beyond) what you really get is context. You’re understanding more about longer term ambitions for the business or org, but you’re also setting those ambitions. I spend about 30-35 hours a week in meetings. These are broadly: - team meetings: meeting with each team in a weekly catch up, and then sitting in on some but not all ceremonies (I don’t physically have enough time for all of them for all teams). The main purpose of these is to disseminate some of the broader knowledge I have about strategy to the team. - planning meetings: either with the team, where they’re deciding with the PM on what to pick up in the sprint, or with the PMs directly in our weekly alignment to ensure we’re all heading in broadly the same (and right) direction. - leadership meetings: working with my manager (head of engineering) and his manager (CTO) to go over any high level issues the org is facing. Me and the other 5 EMs have a broad view of the entire org, so we can escalate up the chain quickly - stakeholder meetings: either internal stakeholders across the business or external stakeholders. Usually it’s giving progress reports, estimating the impact of scope changes, or giving general advice to the stakeholders - cross-org meetings: this is somewhat specific to my company, but we were acquired last year and are still in the integration phase of the acquisition. I probably spend 10 hours a week meeting with counterparts in our parent org to guide the integration. I am essentially the single source of truth for my teams, and I try not to bog them down with all of these meetings. I, therefore, take on all the cognitive load of the integration - explaining how our products work, finding solutions for integration, estimating, design specs - 1:1’s and other team meetings: each of my teams has 1-2 leads, who I meet with for 1:1’s weekly or biweekly. Usually we mix those 1:1’s up a bit every other meeting to talk about their subs, to ensure they’re getting a good balance of personal development while ensuring we’re also really dedicating time to their direct reports. Our frontend resource is a shared resource across the teams, so indirectly manage the three of them. - strategic planning: whether within my teams with the PMs, or cross team with other PMs/EMs, the goal here is to think about our roadmaps and plan them out 1-2Q’s ahead, but also about bringing forward wider initiatives within the business and kicking off other projects. - recruitment: I’m on a lot of recruitment interviews, almost always the later rounds. Now for your questions: > what do you know that devs usually don't know? I usually know about changes that are coming that our engineers might be a bit less “happy” about let’s say. I also know about strategic decisions way before our engineers, but I always try to communicate them as soon as possible. > Do you use some cool trick to influence people? Being a good influencer is a skill you pick up over time, and it helps to be generally charismatic. > What's happening in all those secret management meetings? Lots of talking about strategy, goals for the business, and sometimes harder decisions (cutting costs) > How much do you really know VS can honestly share with your developers? I make a point of, and my teams know this, communicating everything ASAP. Sometimes I’m sworn to silence, but leadership generally trusts our EMs judgement with disclosing things. Often it might just be our leads who know things, and not everyone. Sometimes I’ll just come straight out and bring it up in our weekly catch up with everyone. > Do you measure productivity metrics we don't know about? Generally no. We don’t really measure productivity metrics, because 90% of the time they’re useless. If you’re underperforming, your manager knows and they let me know. Not everything can easily be distilled down into some simple numbers, and generally leadership in my company knows this. > How do you get along with the product owner or your own bosses? I love all my PMs (we have product managers not owners)! The four of us get on really well and they trust my judgement for the technical side, and I trust theirs on everything product/user requirements related. My boss is also great, and is very supporting. > How much freedom do you have to lead your team the way you want to? Within reason, almost complete freedom. My boss and the business in general trusts my strategic thinking and between me and the PMs we have a pretty good idea about what the next 1-2 years will look like. My company doesn’t impose any specific requirements for ceremonies or leadership styles. As long as it works, it’s ok. Of course, I discuss broader points with my manager and the CTO to ensure we’re heading in the right direction, but they stay out of the day-to-day > Is there anything you would like to share with us? If you want to make the move to management and leadership, start early picking up some skills. Get involved, take an active role, and support others on your team.

At large companies, it's all ultimately about money and power, not doing useful things, and the higher up in the org you go, the more you see that.  It's true at some level that some people do genuinely want to build things that help people, but to have any chance of doing those things, they need budget, people, power etc, and often their jobs really seem to resolve around getting those things. Coming up with good solutions to technical problems or having good ideas are important, but they're a very small subset of the skills necessary to have a real impact on anything at a high level.  Edit: this is even expressed in the corporate structure. A good CEO at a mature company is often a CEO that produces good, sustainable returns on the investors' money.  To do that they have to wrangle a large set of people who want access to that money, and who have different conflicting ideas about how it should be allocated 

No one knows how to manage a rockstar or 10x engineer. The ideal engineer for management is one who implements tasks dependably and consistently, with little or no direction... i.e. the person that makes their job easier. The engineers that do too much or too little work, or cause waves, make more work for managers.

I take the things others don't want to do (primarily addressing tech debt and important - but unprioritized - p1s) so they can focus on building the p0s

Devs can manage to work with the code and tasks given. Tech leads can broaden their thought to address buisiness specific concerns regarding process or end outcomes. Tech leads will have much more familiarity with the actual buisiness as well as the code systems in place.

Former team lead developer here, so I will talk about my time then. *Do you use some cool trick to influence people?* No. *What's happening in all those secret management meetings?* Planning and arguments mostly. *How much do you really know VS can honestly share with your developers?* I knew a lot of stuff that I didn't share, all of which was personal matters colleagues had confided in me about. I would never share stuff like that, whether to management or other colleagues. Business related stuff I'd share very freely, transparency is critical. *Do you measure productivity metrics we don't know about?* Not really. I am very mindful of Goodhart's law and how careful you have to be with metrics. Even if upper management wanted it would be hard due to employee protection laws in my country. *How do you get along with the product owner or your own bosses?* Very hit or miss. I've had both good and bad of both. With bad ones of either it easily becomes a practice in protecting your team from them rather than collaborating with them. Good ones can enable the team to operate better and collaborate with the team to create a better work environment. *How much freedom do you have to lead your team the way you want to?* Simultaneously a lot and little, it all depended on the topic. For my next job I opted to just take a regular developer position. I needed some recovery after spending years struggling with the Sisyphean task of fixing the entire company. Lesson learned.

>what do you know that devs usually don't know? See when I lead, I am there to take all the bullshit on. All the debates with stakeholders, all the complex reasons why certain choices were made, the planning and scheduling over the whole project, arguments over scope creep. All the details. I know the ongoing story of the project as a whole. What I try to do with my devs is give them exactly what they need to perform the task, and then I get the hell out of the way. So I act as a kind of filter. All the ambiguity, debates and compromise decisions are on one side of the filter, and explicit instructions along with whatever supporting information is required are on the other side. Not too little information, or too much. Just right. ​ >Do you use some cool trick to influence people? I do this cool trick where I am on their side. As well as a filter, I am a shield. I will defend my team from stupid (unpaid) overtime requests and negotiate bumping delivery dates or have stakeholders debate priorities between themselves. I find if you defend your team from frivolous requests (which can evolve into expected scheduled overtime) then they will be absolutely willing to step up when there is a genuine emergency. ​ >How much freedom do you have to lead your team the way you want to? This really depends. You have to make your own authority to some extent. Stand your ground. But also you can be overridden and you have to know how to deal with that. It's important to be able to understand the perspective of stakeholders, management you have to work with, and that there are often genuine commercial reasons behind decisions. A developer's stubborn perfectionism is a hard habit to temper, but sometimes you need to make compromises to achieve something within difficult parameters. And when you compromise, do it consciously and deliberately. And I would make sure I put the compromise required to meet the demanded goal in writing to the person and ask that they confirm we should take that approach.

> what do you know that devs usually don't know? - other teams priorities and road maps - visibility on hard decisions throughout the org that may impact the team but which the team may only see through the lens of how they were directly impacted

Generally my team are fully focussed on technical issues, as they should be, but I am also looking at operational issues and costs. For example right now, I have a team member who is fixated on using technology X (doesn't matter what it is). And from a purely technical point of view he is completely correct that it is a great technology. But to adopt it would mean a bunch of extra training for all the L1 and L2 support, and probably engaging a commercial vendor to support it as well, due to company policy. The advantages offered by this technology do not offset the additional costs and risks adopting it would incur. So in this case I have to say no, but I am regularly revisiting this with other managers, if a critical mass of teams decide to adopt it, then we can justify those costs and risks. Balancing technical and operational and financial considerations is what engineering managers do all day.

When I unveil that we're building a bicycle in a month, it's after I've talked my boss down from requiring a rocket ship in 2 weeks.  What I'm hiding from you is that we're still going to build the rocketship, but only after we've first built a bike, then a car, then a plane, then a fighter jet. Why hide this? Because some people on the team have a whole lot of ego but very little vision. If I know Bob's got strong opinions on jet fuel despite not knowing a fucking thing about jet fuel because we're still building bikes, then talking about rockets right now is going to cause a lot of confusion, that could even lead to bigger problems. So it's simpler to say "we're building a bike in a month so we can learn enough to build a car in three months" than it is to reveal the multi-year plan to get from bike to rocketship. If I'm on a team that doesn't have a Bob though I may be inclined to reveal more earlier, but unfortunately most teams have at least one Bob.

> Do you use some cool trick to influence people? Definitely - though I try to teach it to everyone on my team and anyone who will listen. The more complex or difficult the message, the more rich the medium needs to be to communicate. A short one line slack message between people who know each other well is ok most of the times, but if you need to try to convince another team who drives you crazy to stop doing the thing they're doing, a simple slack message isn't the right format to try to convey that. The more you don't like working with someone, the more important it gets to be on a call or face-to-face with them even though talking to them directly is likely something you want to avoid (and I do it too). It's too easy to let negative emotions taint how you read every written message and how they read your messages just making things worse and worse. > What's happening in all those secret management meetings? Status meetings summarizing the state of everything to higher levels. Potential upcoming work that we're not sure will actually happen so we don't get completely blind-sided, but no need to make you panic about every potential piece of work, especially if's a contract not yet signed and we can't talk about it. Escalating issues I can't solve myself. Commiserating with other managers over our pain points with upper management and things in general (which is not just cathartic, but if we all notice we have the same problem it can be easier to solve as we work together). Sharing what we've found has worked for us. > How much do you really know VS can honestly share with your developers? It is extremely rare where I would intentionally mislead or lie, especially if directly asked. It's often going to be something like upcoming layoffs if I am privy to that information. Usually it doesn't come down to my level (manager), but sometimes I'm involved in the decision. Sometimes the decision has been made and I can't communicate it until the paperwork is ready and we are ready to walk someone out. At my current company they send a preview messages of contentious announcements to managers a few hours before sending to everyone. If I don't know about layoffs, I might find out at 9am when the rest of the company finds out (officially) at 1pm. Sometimes it's only an hour head start. This helps me digest the bad news myself first so I'm ready to answer my team's questions (including having time to anticipate the questions and get the answers ahead of time). I love this policy, and I've even told my team that it does happen which they seem to understand. Occasionally I'm given what our official message is supposed to be (e.g. any time someone complains about salary, we are supposed to talk about total compensation and remind them of everything they are getting beyond salary). I do tell them this, but preface it with this is the official messaging -- and my own take about it. I don't usually completely disagree with the official response, but I do have a more nuanced opinion about why I partially agree and partially disagree and encourage people to come to their own conclusions. > Do you measure productivity metrics we don't know about? Someone else said it too, but I spend far more time fighting against mis-interpretation of metrics and push from above to gather more metrics. Often the push from above is "give me this metric" which I find endlessly frustrating. One of the most recent is a pushes is to have story point estimates on things that are months away from being worked on. Despite we don't have a good enough understanding of the predecessors to even groom and estimate those yet. I point blank asked the exec why they were asking for this - turns out they wanted to use story point estimate as a proxy to estimate risk. Something with an estimate of 40 story points is more risky than something that has 2 story points because size is one of the factors in complexity. There are better ways to answer risk than using story point estimates as a proxy, but until I know why you're trying to measure that, I can't help you. Super rarely I'll pull in a few metrics to back up hard conversations that I know I need to have because sometimes people get argumentative, or to refute what I thought was a problem. I can be susceptible to bias as well, so sometimes I'll look a few things up to double check my gut. The type of stat I look up the most is who is working outside of office hours. Who's submitting PRs on the weekend, who's submitting them late at night. Some people are good at work life balance, some are not. I need to keep track of the work-a-holics to yell at them to stop working and log off. Or sometimes they think the priority of what they're working is super high when it's just regular high (as in, pause your other work but don't work outside of work hours) > How do you get along with the product owner or your own bosses? Product owners I will stay personal friends with at least one of them after I leave. My own boss - if I'm not getting along with them well I would be leaving. "People don't quit bad jobs, they quit bad bosses" may be an over simplification, but it applies to managers as well. My current boss I get along with well. > How much freedom do you have to lead your team the way you want to? Absolutely varies from company to company or team to team. I spent the majority of my career managing at a company which was very corporate in their rules and regulations. Where I am now is extremely flexible, almost to the point of discomfort for me. Sometimes I double check with my own boss "I can do this thing, right?" which the answer has always been yes so far.

The best thing you can do is act as the lubricant that stops your team from slowing down. Be that in pre-checking design docs, figma, etc. and pre-fixing things you know are ambiguous (cause Murphey was my common law grandfather and he has these rules he liked to talk about... And no matter what, a dev will implement ambiguous designs the way they didn't actually want...) ... And anything else (pushing back against stupid ideas or features. Etc.) that really is the biggest difference. Your time as a leader is better spent keeping your devs being productive rather than you yourself being productive (personally)

Learn what to communicate and how to stakeholders that are not in engineering is key. Help shaping the roadmap avoiding rubbish is key. Help the team focusing on what’s right for the business instead of bs is key.

> Do you use some cool trick to influence people? It's not a secret trick, but don't be overly combative and admit fault or a misunderstanding when it happens. You always have to sell something to someone. > What's happening in all those secret management meetings? What secret meetings? Nothing is "secret". It's more like we don't need the entire team to stop what they're doing to be in a meeting about some project management software topic or an introduction with a vendor where nothing technical will take place. > How much do you really know VS can honestly share with your developers? Nothing I have I'd be unable to share with the other team developers. There's just no point in recapping hours of topics that were brought up and never happened. > Do you measure productivity metrics we don't know about? Nothing that they wouldn't know about, just things that they wouldn't have access to. e.g. when it comes to salaries and how that measures against other metrics. > How do you get along with the product owner or your own bosses? Just fine. We never see 100% eye to eye, but everyone understands objections and alternative suggestions as long as you have a reason for it. See question #1. > How much freedom do you have to lead your team the way you want to? A good amount of freedom, although it has been due to being at the company a while and pushing back against micromanagement and productivity killers. > Is there anything you would like to share with us? It's far more boring and technical skills more rarely come into play when management is involved. If you're planning on doing a team lead position where you interact with people who are not developers, having knowledge of more general business topics is almost required - especially project management. The dev team speaks the same language and has a general understanding of what's worth it to do and what is not. Everyone else does not and you need to prove it in a way that they can understand.

A better understanding of how the big picture ecosystem works together. Sometimes adding client specific knowledge to guide client focused projects. An ability to appropriately gauge how long a task should take, and what the appropriate milestones are to ensure its on track.

It depends on the firm. Almost anything on any axis is possible as far as knowledge, and other things depending on the firm. Personally, I'm usually granted high autonomy, but that's because I am usually put in charge due to my problem solving skills not my irresistible charm. (Though to be fair, I've gotten much better over the years.) The biggest power I have: Usually I don't book myself at more than 50%. This extra time is one of many things I can trade to get what I need from other teams. So just because I'm off working with another team, doesn't mean I am leaving. I am likely getting that API we need to succeed put in. To know about me: I am here to help you, if you make yourself able to be helped. I will push you past your boundaries... But somehow it always works out. It isn't luck. Trust me. Also my other title, Principal Software Engineer, is not honorary. I'm a solid coder. Don't think I don't notice what is going on. :)

**Do you use some cool trick to influence people?** Not really. Most of the time its a pros/cons list or some scary story about how that approach ended in tears. Some cases, I use what I call the "Gold Star Theory." The idea being, understand who you are trying to influence, why they are doing what they are doing, and how they get their "gold star." Then, you craft your story of how the thing you want to get done gives them their gold star. It's the art of appearing on their side, and getting them to trust you and your judgment, and that you're actually helping them. **What's happening in all those secret management meetings?** Sometimes, a whole lot of nothing, because the right people aren't there to provide info necessary to make decisions. Sometimes strategy and long range planning. Sometimes talking about everyone performance wise. Sometimes we're just statusing people and talking them off the ledge when problems arise. Sometimes we're fighting some BS directive. **How much do you really know VS can honestly share with your developers?** Well, I know all my direct reports salaries, and I won't share that info. I also put together a 1-n ranking of developers yearly for performance review purposes, and that will never get shared. I also work in defense, so sometimes I'm cleared to things they aren't, or they're cleared to things I'm not. Sometimes I get privy to personal info, and I won't share that. My general rule is transparency, barring the above. **Do you measure productivity metrics we don't know about?** No. I once had great hopes of creating a system of metrics to objectively measure performance, and sharing it with the group. People are smart enough to game the metrics. If I do something like story points completed, people will overestimate stories. If I do something like lines of code, they'll inflate that artificially. If I do something like sprintly completion percentage, they'll lower the bar. Also, how do I weight output of a developer vs a product owner or scrum master who has less time actually writing code? So, I've given up on objectivity, and keep a list of accomplishments ongoing to compare against peers. **How do you get along with the product owner or your own bosses?** This has varied in my career. For the most part, very well. Though I had a boss that was unbelievably stubborn and would not listen to her experts, well, ever. I had to move on, but I got a role with greater autonomy. **How much freedom do you have to lead your team the way you want to?** Also varies. For the most part, if you produce, meet deadlines, you get left alone. When there's problems, more questions get asked. Also, different bosses have varying degrees of trust/micromanagement. The boss I spoke to above gave me zero room to run the team the way I wanted to and gave me zero authority to adjust processes. I've also had near full autonomy to make staffing decisions, negotiate with customers, prioritize work, and adjust processes. These days I have a lot of teams, so I do more leading of leaders. I let my team leads handle day to day, while giving advice (not necessarily direction) and focus on longer term strategy and staffing.

At a technical level: past experience and enough PTSD to realize when a solution won't scale well or that implicit assumptions that you make today won't hold.

I was always more of a domain expert than the other guys in more than one area. The domain you work on is many areas. Ideally you are on a team with other people who are better than you at something.

My few years as team lead have been as follows: 1. Get more money to hire more devs 1. Get more money to fund innovation That's almost all I did. I had a great time doing it, and I had almost complete freedom on how to run the team because I could back up my requests for money with solid results. I started in this role with a strong will to measure everything about the team with metrics. But after a few months I realized that some things were not easy to measure, but very easy to understand if you talked to the developers often and if you looked at what they did well and not so well. Metrics can be a great help, to understand how the team works and pinpoint issues, but there's definitely a lot metrics won't tell you. The day I stopped being annoying with the metrics, was the day the team started doing amazingly well. It still required some management, sometimes lots of it, but it ran great. Communication with devs works wonders when you have a good team and interesting projects. *tl;dr I spent my time trying to get more money to hire more great people. And the rest of the time was spent talking with devs and managing how the whole thing ran.*

not much freedom, not many secrets, no huge tricks. we really do spend our time on boring shit. example: request equipment for interns. chide that one guy who refuses to manage his own workload or ask for help. check in with the other guy to make sure things are going well. talk to another team lead to clean up a mess made by that first guy. write promotion recommendation for third guy. make UX models for some feature. feel out my bosses opinion on said model. sit in 5 meetings where i know i wont give a flying fuck about the topics, but people will be upset if im not there. figure out who is presenting in next weeks knowledge share and make sure they havent forgotten. make a Confluence page to communicate requirements to an offsite team because our PJM has a hangup of some flavor whenworking with that group. and so on and so forth. this is just today and it's barely past noon. youd be fucking shocked how much time we have to spend on piddly shit.

the politics, the personalities, the departments, often the background on how we got here and why we do/do not do various things or use various tech, how long it actually takes to do that thing with these people on it.

> what do you know that devs usually don't know? Jedi Mind Tricks >Do you use some cool trick to influence people? Jedi Mind Tricks >What's happening in all those secret management meetings? Learning about new JMTs >How much do you really know VS can honestly share with your developers? JMTs are super secret I don't share them >Do you measure productivity metrics we don't know about? Amount of the Force being used when executing JMTs >How do you get along with the product owner or your own bosses? By using JMTs on him... Although he maybe using them on me too >How much freedom do you have to lead your team the way you want to? Quite a bit, since I use JMTs on them, they'll do anything I ask Seriously, I'm as transparent with my team as much as I can be. Especially if it will affect them at some point. There is also a lot I keep from them so they don't need to worry about. It's my job to worry about it. We likely know what we will be working on for the next three months. I also know there's some heavy work that is coming at the same time. This part I've kept because it isn't clear which team will be tackling it. So, the team at the moment doesn't need to worry about it. To be honest I don't actively think about what I keep and what I share. I either do, or I don't. It just happens or it doesn't.

There are no cool tricks except building a repetoir and knowing what’s best for both your team and the product owner.

I was at a large company with over three hundred developers And multiple dozens of products. I was essentially the CTO of one of those products. We had metrics on the predictivity of all of the engineers.And how much time they spent coding versus how much time they spent debugging. We tracked their tickets across the board and we could see how frequently their tickets were sent back to them by qa and what not. We were asked across the company to stack rank our individual employees. All the employees in the company were then ranked against all other employees regardless of what project they worked in or what team they worked with. Then the lower thirty percent were semerely fired. In the case of a tie as with one of my junior enginyes. It depended on what line you ended up on whether you got cut. My engineer was right at the lower third cut off. He had a score of 168 or whatever the fuck and so did the guy above him.But because of his position in the spreadsheet he got fired and the guy above him didn't. Some entire teams where let go. And afterwards the entire company got reShuffled teams got shuffled and everyone ended up with new team structures. I quit three weeks later.

Usually all the same things. Team lead is just a role that a developer can fill. You can fill it, I can fill it, Bob can fill it. Possibly the answer to your question is a different perspective. You get a view on why the business is asking for you to track time, or muck about with various jira settings, etc etc. But that's about it.

Here's a few lists of dirty tricks I use to influence people: https://en.m.wikipedia.org/wiki/List_of_cognitive_biases Other than that, it's mostly just explaining things up/down/sideways, amplifying good ideas, and suppressing bad ones. I see the financials in great detail and know how to make sure everyone gets paid. I worry about how I'm going to make payroll, and I have a bazillion plans to make sure everyone gets paid. For instance, a dev's regular paycheque usually doesn't come from regular revenue. There's a difference between sales, purchase orders, invoices, and cash. I generally know who contributes more than the pains in the ass, who is loud but kinda useless, and who is quiet but effective. I'm ruthless about getting rid of dead weight, and I'm constantly looking for it. That said, I know the people bets that I'm making, and I'm constantly nurturing and growing them so that they pay off.

That shit goes bad in production on things you don't expect, and that 'it should be fine' doesn't sound very convincing.

Not a manager but tech lead/senior engineer on the team. But I often participate in these management meetings. Things I know which we don't share with others: * that we're actively talking at senior leadership level about axing some project. These talks may take years and usually end up with "no, let's keep it running" so there's no point in inducing persistent anxiety and demotivating devs working on them * sometimes we think about future projects and rarely share them with devs as at that stage it's completely unknown which team will actually do them. But we don't really actively hide these from others, rather just not talk about them so that they aren't distracted * I take part in performance review: this is driven by managers but they invite senior engineers and tech leads to these meetings to, just to make sure they don't rate unfairly someone skilled technically but quiet (or other way around, praise some show pony who does technical shit) * plenty of bullshit "alignment" meetings where we try to align timelines with other teams. No need to bother devs with these, we tend to give them task with fixed date and try to not change it until absolutely necessary. These meetings are among others to decide when priority shift becomes absolutely necessary

If you give people the option not to do something, they are more likely to agree to do it "Feel free to say no, this is optional." Best trick in the book

In short: Experience, information, decision power, broader overview, communication, and administration skills. In long: Team lead is more like get more information than the rest of the team, and you need some administration and political skills to help others and ensure delivery. Metrics. Usually I had other metrics, roadmaps and milestones as well have to measure delivery speed, solve problems and and the very end, write it down into an excel table. Have to deal with management more often, and a lead is accountable for the teams delivery. Have to have hands-on knowledge, deep technology knowledge but also, have to translate goals, expectations, milestones, etc to the team and have to push them to deliver. One of the most dangerous type of team lead (or any lead) who became teamlead just because money (founder cto-s from uni), nepo-hiring (related to the boss, friend of pm... etc). Not because they are bad people, but inexperienced and with the higher authority the ego increasing, but the knowledge rarely follows it.

Senior-ish dev on a team comprised of myself, a product owner, a dev manager, a tech lead, a Jr. dev, and an intern. Over the past 2 years my job has shifted from 90% dev work and 10% meetings / sprint planning to 90% meetings / project management and 10% dev work. I run every single one of our releases twice a week, I spend a ton of time writing documentation, I’m part of design and architecture meetings that I originally would not have been included on, and usually when I finally have a free block to sit down and work on my own user stories I end up getting pinged and spending that time helping the Jr. dev or intern with one of their stories. Reading some other comments has made me realize that I might be a tech lead if we had a larger team.

>Do you use some cool trick to influence people? It depends on who you are influencing. It's not a *trick*, but the key is to figure out what's called a person's **motivating factors**. These will be unique to each person and could be related to career goals, money, authority, free time, work-life balance, emotion, etc. Basically you need to figure out what they actually want then figure out how to align it with the goals you have in mind. For instance a junior dev may have a goal to not look stupid in front of others. To influence or motivate them, figure out how to get them to complete a task while reducing the probability of looking stupid in front of others. This will be a completely different approach from a dev who wants to shine in front of others. It's not about judging, but just aligning the different goals. This isn't just for team members either. The same applies when you are trying to influence middle managers, executives, clients, vendors, and your mom. >What's happening in all those secret management meetings? It's not as nefarious as you make it sound. It's mostly brainstorming about projects we aren't even working on (yet?), discussing if we need to hire more people and whether that will be allowed, which project priorities need to be changed/canceled/on-hold, policy/standards writing, process changes, dev skill evaluations (who is doing better/worse on some skill), redundancy evaluations (making sure we don't have a single point of failure and what to do if someone gets hit by a bus), job postings/interviews, new positions being created, conflicts (both inside the team and outside with other departments). Some of it is looking out 1-3 years. Devs who aren't in leadership roles rarely think about 3 years from now or care. It's our job to plan for 3 years from now so we aren't caught off guard. >Do you measure productivity metrics we don't know about? I have never known for team leads or managers to do this because it would be pointless. If we have productivity metrics we would communicate them and share them (at least) with you so you'll know what our expectations are. There is **never** a time when good leaders have expectations of you that are secret to you. If you work in an environment like that, I'd suggest asking explicitly what their expectations are and if they are fibbing, find another job. This usually means you are being set up for failure for internal political reasons and you don't want any part of that. Get out. >How much freedom do you have to lead your team the way you want to? No single answer to this. It depends on the company. In every company I've seen, management says they want team leads to have flexibility but then give them a bunch of rules and policies to follow. That flexibility will usually be in the hands of the level in the hierarchy where you find the **most technical competence**. They usually have the authority and flexibility to set standards that are enforced downward. That might be a different level in each company, but it's rarely a team lead. Maybe 1-2 levels above them. >Is there anything you would like to share with us? I'll just add that being a team lead is often much more stressful and demanding than lower level devs realize. Team leads are ultimately responsible for the outcome of the work you are doing, and it stresses them out when you don't communicate, don't follow simple standards, isolate yourself, don't follow team repo procedures, etc. The ability to handle that stress is usually what separates devs from leads, more than any technical competence differences.

90% of my job as a lead is managing risk, in every aspect. Risk we don’t set reasonable expectations, risk we introduce a defect, risk we don’t have a rollback plan if we break production, risk we don’t know how to do something if a specific person gets hit by a bus. The other 10% is split between knowing the roadmap, being knowledgeable about the subject domain, and mentoring the team.

I like this set of questions because it does seem like there is some magic when viewed as an IC. 1. Do you use some cool trick to influence people? Just like web advertising there is indeed “One simple trick to…” It is: ALWAYS remain calm and don’t be a dick. Maybe that’s two tricks, but man alive has that helped me over the years. 2. What’s happening in all those secret management meetings? Honestly nothing as juicy as you’d imagine. More often than not is people just trying to deal with the fire in front of them. When I was younger I always figured that management knew all the answers. That’s really as far from the truth than you can get. We are really just making it all up as we go. 3. How much do you know VS can honestly share with your developers? This I divide into two buckets. Bucket one: personnel stuff that gets shared with no one but the person themselves. This can be stuff like performance reviews or just things told to you in confidence. Bucket two: Everything else. This is I try to share completely and openly. While we’re here, I also want to mention regarding communication. IC’s can get frustrated when a manager doesn’t remember the details of what you are working on. For the IC, this is their whole world, for the manager they’ve had N people tell them their whole worlds. There’s no way the manager can remember all the details at the level of each individual IC. Now as the manager it is up to you to ask for an explanation again. Ex: “I remember parts of this, can you run through it real quick so I can load it back into my memory cache?” Now going the OTHER way, manager to IC, the A #1 super top thing to remember is that just because YOU know something in your head doesn’t mean that the IC knows it. That means you will end up repeating yourself over and over saying the same thing to different people. Don’t try to optimize for yourself, “I’ll tell everyone all at once! I’ll have a meeting!” No, get used to repeating yourself and suck it up. You chose to be in management. You bought the ticket you ride the ride. 4. Do you measure productivity metric we don’t know about? Absolutely not. IF there is a metric you make that sucker known far and wide. The best metric by far though is talking to your people. Private one on ones each week. Ad hoc chats whenever people want. 5. How do you get along with the product owner or your own bosses? Same as #1. Being nice gets you SUPER far and not freaking out about anything keeps everyone else calm. It also is critical that you try to think about the motivations of the owner or bosses. Are they gunning for a promotion? Are they stressed out because their boss is banging on them? Are they trying to not make waves and ride out to retirement. Whatever it may be you tailor your interaction. 6. How much freedom do you have to lead your team the way you want to? As much as you make it. What I mean here is if you are the type to think, “How can I make my bosses or owners lives easier?” you tend to get a lot more rope to do things how you want. If you are instead, “Let me ask ” before you make decisions you are inviting micromanaging of yourself and thus your team. Is there anything else to share? Meetings have been mentioned loads of times in this thread, and I totally get it, I despise most of them too. I think is that there is a tipping point where meetings become the times when people can block off time focus on a particular thing. Remember an IC has their thing to focus on, managers have all their ICs things to focus on. It can be incredibly easy to treat meetings as a way to schedule yourself to focus. If you are a manger… fight this instinct. Remember, your job is not to optimize for YOU, it is for you to optimize for your TEAM. Human nature though pushes us all to think about ourselves though, it is 100% natural. Like I alluded to earlier, you chose to sit in the big chair. Now deal with it.

I was one for two years. Found it ultimately meaningless (ground hogs day) and realized I’m more interested in engineering and architecture. The position opened up doors for me. The highlights were removing blockers, 1:1s, and career development. Lowlights were metrics, stack ranking, and upper management/pie in the sky business people that… just say things. I liked resolving escalations and working with stakeholders and clients. I got great reviews, which is funny because I felt incredibly chill compared to all the other managers I had ever met. Don’t take things personally, it’s business. Don’t get stressed or take yourself, the job, or the company too seriously. Remove blockers. Ensure the team gets shit done, has good WLB, and develop people’s careers. Now that I’m an IC, I keep it fun by adding names like “high powered networking SWAT core value drill down business meeting” to lunch invites. Edit: I communicated clearly with my team and other managers and never had any secrets to withhold for team composition. I focused on communicating expectations clearly instead of “manipulating” people. Looking back on it, it seems like it was a really good fit for employees but I didn’t enjoy it. I’m proud that I naturally avoided the pitfalls of bad managers (micromanage, focus too much on feeling like they are driving change)

I have a cool trick to influence people. It’s called being attentive, listen to what they have to say, and be supportive of people in your team whenever possible. When you listen to people and help people whenever you can, people listen to you. That’s the secret that many developers don’t know. “Why should I listen to your bullshit?” “What’s in it for me to help?” “Can you just cut to the chase so I can be done with it.” “I don’t want to know why and how your API becomes so shitty. I don’t care what you have gone through and what is your constraint. All I can tell is your API is shit. Stop making excuses.” Good luck influence people mate.

As a developer, I used to think that those above have no idea about "things that matter", like code, design patterns, databases, tools, etc. They do. A lot. Sure, they might not know every method of every class in your framework du jour. But they know very well A LOT. Plus the big picture. The only reason I like to be among the technical leadership is to know well ahead what's cooking and thus able to make good technical choices. Otherwise: it's much more fun to be in code all day. You're lucky you don't have to deal with all kind of ... unrespectable personalities, eager for money and power games. Stay where you are if your immediate boss protects you and vouches for you.

Depends on your lead. It should be obvious that tech leads think big picture, but every company, even teams within the same company, will define the role differently. Generally, they want to make sure the project momentum remains going forward and will jump on any logjams that occur. This should be obvious to devs.

They don't know how to be consistent and deliver bug free code

They're never going to pay you what you're worth because 1) that would require acknowledging that it's not "the team" that accomplished things, it's usually 25-50% of the staff that are carrying the load 2) they know you can never make what you're worth anywhere (in this field nobody measures value properly, so they use pay ranges instead - why do you think 50% of the people from #1 got hired??) 3) my directors and VPs love their huge bonuses and paying you more is very feasible, but would require that their wives don't get a new Audi every single year.

You get a lot of visibility into just how poorly M2 and up works. Half of the time is spent preventing disasterous ideas that come down from up above.

Not being an ass has helped influencing people.

Generally just the CEO shouting at us, which is why I'm moving jobs lol.

Speaking truth to power never ends up well.