Ask HN: Advice for a new and inexperienced tech lead? I'm only a mid-level developer. I've been offered a position as a tech lead with the aim of building a team. What advice would you give a new, inexperienced, and ambitious tech lead? Thank you HN |
Ask HN: Advice for a new and inexperienced tech lead? I'm only a mid-level developer. I've been offered a position as a tech lead with the aim of building a team. What advice would you give a new, inexperienced, and ambitious tech lead? Thank you HN |
https://www.bitlog.com/2017/10/12/what-does-a-tech-lead-do/
The TL;DR is that you are now responsible for anything that is not moving your team forward. If nobody knows what "forward" means, it's your responsibility to define it. If a code review is languishing, that's your responsibility. If a person has a technical question and they're junior enough that they don't know they can ask it, that's your responsibility. If your team doesn't have a good technical strategy, that's your responsibility. If your team is having trouble getting technical help from another team, that's your responsibility.
It's not your job to do all of these things, but it's your job to make sure they get done.
Your job will no longer be primarily about creating good code, it will be about making it as easy as possible for everyone else on your team to do so.
Writing well is very important. I literally spend half my day writing: tickets, pull request comments, upstream status reports, explaining the cost/benefit of various options to project managers.
Get basic functionality locked down early and then build from there.
Don't micromanage tech decisions but do make it easy for people to be consistent with one another by providing a style guide.
If all you do is prevent a few foundationally stupid decisions from making their way into the project, you're already way ahead. [hint: most really stupid decisions are not actually any one person's conscious decision].
After all else: listen.
1- Put your team before anything else.
2- Be as honest as you can about deadlines and limitations.
3- There is time for crunch mode, not all the time is crunch mode.
Be very good than most team members in your tech skills and demonstrate it when chance presents, that will make them respect your judgement. If your tech skills are not on par with some of the team members that's fine, but you need to handle them differently. Time and time again i have seen skilled members of the team will question authority if they don't get along with team leads. Remember the cost of replacing a manager or techlead is low compared to skilled people because they get paid lower usually. You may have to delegate work but you must be the most skilled guy in the team or you should have a very likable personality.
There will always be a backlog of tickets, and you can't hit inbox zero. But you can hack it. Executives need to increase the Average Sales Price (ASP) and Reduce Churn. Your team will want to fix technical debt.
Your job is to bridge the gap: help your team understand how their work impacts customers. Help the business understand how your team's successes impact ASP and churn rates.
Tell your team they hit the goal. Tell the organization your team hit the goal. Tell the organization where your team can see you telling the organization. Many engineers aren't known for their salesmanship, and they can and should improve, but you can step in and rapidly build trust with them and the organization by selling their work on their behalf.
Instead of asking for time to fix tech debt, explain to the organization what the tech debt actually fixes: Reliability (churn), Operations/Chores (COGS), Resistance to Future Change (ASP), Infrastructure Bills (COGS), App Performance (churn), and like that.
The weekly 30-minute O3 is your new best friend, especially with non-technical stakeholders. As a team lead, I usually meet with engineers every other week—you're a team lead, not their manager.
Understand the differences between Accountability, Responsibility, and Authority. Responsibility is "yup, we're on it." Accountability means the business expects you to accept "consequences" for failure. Don't accept Accountability without both Authority to make decisions and compensation for the job risk. More than likely someone else is accountable (an actual manager or maybe a product owner.) Engineers are too difficult to hire to be holding them accountable. As an ambitious founder-turned-tech-lead I bristle a bit at this, but at least you can be aware of how things are set up.
But this also means you'll have limited authority, and you'll have to achieve alignment rather than dictate solutions. Which brings me to:
Pre-wire meetings. If you need a decision to go your way, meet with each attendee individually first and get their feedback on your proposal. Don't put together the meeting with everyone until you're confident it's a formality.
You can push back on processes that don't work for you: too many meetings, scrum ceremonies, taps on the shoulder. "I understand the importance of schedules and status updates to the business. My team needs protected time to achieve our best results. Will you help me batch our meetings into tighter windows so we're able to both put in the work and keep the business informed on our progress?"
Set up systems. Don't take on all the chores yourself. Set up a schedule for a "triage" engineer, include yourself in the schedule. I like rotating out weekly. This engineer intakes all of the bugs/questions/fire drills and provides answers and verifies things aren't on fire. They are assigned less critical tasks that week because they'll be interrupted. This gets you protected time to think.
Set up engineering "pairing office hours" 4-5x a week. You're not a manager: you still need to be on a Maker's Schedule. Your engineers will need help and rubber duck sessions, but if you drop everything every time they ask or get stuck, you won't ever be able to get in the zone yourself. Likewise, they'll know when you're available to help. Tell them you expect them to come prepared with a list of things they've already tried.
http://www.paulgraham.com/makersschedule.html
Read every MR your team submits. Don't comment on the direction 8 times out of 10 (unless you're directly assigned to a review.) You're looking for opportunities to ask Ben to talk to Samantha because they are both changing related areas. Great software is built by gardening over months, quarters, and years. You don't need every MR to be perfect (and that's subjective, anyway), and you'll achieve better results month over month if your engineers feel like they have ownership over their work.
On the flip side, if you're the one being micromanaged, try accepting responsibility for larger time frames. "We will achieve this specific thing by next Friday. We will provide confidence updates on Tuesdays and Thursdays." Then do it. Every time, if you can. The reason the CEO can go play golf on a Tuesday afternoon is because he accepts responsibility for improving the valuation of the whole company by 120% by the end of the year. The junior engineer accepts responsibility for one JIRA ticket, and is likewise expected to be available from 9-5 most days.
Read both Peopleware and The Mythical Man-Month. You're not a manager, but they will help you articulate your frustrations and give you tools to talk to management.
Email and twitter in profile, let me know how I can help.
https://www.youtube.com/channel/UC4xKdmAXFh4ACyhpiQ_3qBw/vid...
(more seriously, it's mostly just amusing)
Don't let ambition get in the way!
1.) Delegate. Have nothing to do.
This is not about being "lazy" or not doing "actual work," it's about giving autonomy to your team. If you do not delegate, your team will constantly be blocked by you and you will not retain them. If you delegate properly, and trust your team, it'll feel like you (sometimes) have almost no job at all.
A pretty solid way to delegate, is to find out where people want to go next in their career, and offer up decisions/work based on helping people get there. It also prevents #2 on my list...
2.) Do not horde work.
It's shitty, I've done it, and learned from it. Every-fucking-time I accidentally did it, it sucked, it would (a) take forever because meetings can eat your life, (b) stress you out because of the time constraints, and (c) MOST IMPORTANTLY someone on my team would have benefited from, and enjoyed, doing the work more.
3.) Hire people smarter than you.
Don't be afraid to hire people with more experience than you or who are "smarter" in some specific field of expertise than you.
You will learn so much by being open to others knowledge, your team will benefit even more by having other people able to guide/mentor/coach them.
4.) Blame process, not people.
When shit hits the fan, you should ALWAYS be cool as a cucumber. It doesn't matter what the reason is, if someone pressed the wrong button, configured something badly, whatever it was cannot be undone.
What you need to do (AFTER) is a root cause analysis; I have always been a fan of the "Five Whys" but to each there own (you can probably google that to get started if its new to you or to find others). You can then implement, document it, and develop new process so that shit storm doesn't happen again.
Just in case the focus here on process wasn't clear, let me spell out the other part to be clear: do not every fucking blame your team. Do not ever blame an individual. You will fix nothing, and your team will grow to hate you as you toss people under the bus.
5.) Shit rolls down hill, it also rolls up hill, and you're always stuck pushing it.
Depending on where you are in the org, this isn't quite so heavy, but truthfully, as a manager/lead the bullshit you weather for your team is what defines you. The more you prevent rolling downhill onto your team, and the more you prevent rolling uphill to your boss(es), the more loved you will be by both.
At some places, without bullshit densities strong enough to make a strange-quark, this won't be an issue... At other ones, this will very likely be what keeps your bosses and your team happy in an otherwise (i.e. other departments) not-fun workplace.
6.) Be kind and be honest.
Don't treat people like family. Treat them better. Families have bullshit, families hide things, families have history, families might be kind, but they can also be brutal. You also can't fire your "family," but you might have to your co-worker... So, just fucking don't.
What to do instead? It turns out, when push comes to shove more than anything they want (a) honesty about the state of the company and their status, (b) to be communicated with kindly. Don't yell at people, or talk about them behind their backs, don't marginalize people or groups you don't think are in the room (I cannot believe what some people will fucking say when they think "no one" is listening)...
And we all can have a bad day and maybe rudely reply to someone or do something not our best-selves, and in those situations you just gotta learn to proactively and meaningfully say "I am sorry." It's even good for you if people find out you did, because it means you're not an asshole, and again they'll trust you more.
The best will be when people give you that same respect because you've set the standard and they want to uphold it...
7.) Your title doesn't mean anything, your experience does, it is the real investment here and completely defined by what you do and how much you put into it.
8.) If it truly fucking sucks, leave. Don't be afraid to jump shit; with a "lesser title." See #7 again, as long as you've done it right, you'll very likely be getting paid more anyway :)
- not kidding
Your #1 priority is to be a _facilitator_ in order to keep things on track. Clear the hurdles and engage with developers on the problems they are solving. And be humble. Don't treat others like they are less than you just because you are a lead.
And congrats! Enjoy it and be fully engaged. Also don't step on your superiors' toes or make them look stupid in front of their superiors. If you disagree with them, make sure to do it in private.
If you don't know what to say or are feeling angry, don't say something just to have a response. Its super rare that you need to commit on the spot. If you get negative feedback from your boss, wait a day before you try to start panic-changing things on the team. Bosses are flighty and under pressure, try to keep it constructive.
Your main job is to keep the team productive. If you do this, you can leverage having a team that delivers into raises for yourself and your team -- eventually.
From my experience having kids helps a lot. Look into your past. Did you enjoy organizing stuff? Do you like to communicate with people? Do you have experience lobbing your ideas?
If you ain't scared of that then go and find yourself a mentor. Best would be if that is somebody you already respect.
Sometimes telling people what to do is right. Sometimes it isn't.
We can bring up a thousand cases proving both.
I recommend the OP reads "The Dichotomy of Leadership" by Jocko Willink, which is about understanding where the balance lies.
https://www.amazon.com/Dichotomy-Leadership-Balancing-Challe...
This may sound very pedantic, but please spend a week reading “High Output Management” by Andy Grove.
The biggest change that happens when you move from a individual to a team lead is that suddenly you have a team which you can leverage to get the needle moving.
This is a great opportunity to punch above your weight but also fraught with peril if not planned well.
There is a need for a mix of comradeship and accountability which is not easy to grasp. But please spend a week reading the book
Meaning: Make sure that you're either running, or involved with, ticket triage. No ticket should go to an engineer without a basic review. (Edit: 2-3 minutes a ticket)
What are things that you should look for, before assigning a ticket to an engineer?
- Is the title and description coherent? Written in decent English (or whatever language your office uses.)
- Did whoever submit the ticket do an appropriate amount of troubleshooting for their role? (Or are they just trying to pass work off on your engineers?) Specifically, if this is a support escalation, did the submitter follow any troubleshooting steps that you've already documented?
- If this is a bug, do the steps to reproduce make sense?
- Do your processes require things like logs, screenshots, videos, ect? Are they present? (Edit: QE and support need to be trained on what kind of information to collect before passing a ticket to your team. Being a "team player" means holding other groups accountable for providing your engineers what they need to do their jobs.)
- Is this a duplicate of a well-known issue?
- Is the bug steered to your team appropriately, or should a different team take the first attempt?
- [Edit] Are there multiple bugs / support requests in a single ticket? (I have a firm one-bug-per-ticket, or one-escalation-per-ticket rule. It just gets too confusing otherwise.)
The above shouldn't take long. Specifically, during triage, you aren't trying to understand the bug or escalation. You're just making sure that whoever wrote the ticket put in enough knowledge that you're comfortable handing it off to your team.
When a ticket doesn't make sense, just send it back to whoever wrote it. You might need to meet with other managers to make sure that everyone understands what you need, and expect, prior to assigning work to your team.
The point is that you should be the filter blocking other teams from sending crap to your engineers. You can also involve your team members in triage, as long as your team members understand the difference between triage and actively working on a bug.
What happens when you don't triage well? Bugs pile up on your team and don't get solved. Some engineers will be good at asking for clarification for bad bugs, other engineers will just let them sit.
In this case, when tickets aren't being resolved, the solution is to re-triage and send back poorly-defined tickets.
In my experience, it makes a world of difference when you have someone you can reach out to and bounce some ideas off of..
I haven't read the book, but it has 5 stars on Amazon.
So what's wrong with the book that multiple people downvoted the suggestion?
If it's company large enough that it has managers who primarily talk to other managers, you're not going to be able to figure things out quickly enough to survive in that role.
Trust your team. Never break their trust. If you do that, you will not make it.
Never put yourself before your team (i.e. make your needs more important than the team's needs)
First thing to do is go to your new boss and get them to give you an exhaustive list of your new duties, responsibilities, what success look like, etc..
Also go to other people who have done well in that role at your company and ask them the same questions.
Tech leads work through their team to deliver. To work through their team, they need to drive to consensus. To do that, they need the support and understanding of their team, so they need to lead. To lead, you need to manage. That doesn't make a TL responsible for firing or resolving interpersonal disputes, but it certainly makes them responsible for coaching/mentorship/up-leveling in a much more direct and often valuable way than a manager.
There's a lot of interesting discussion on that thread that might be useful to you as well.
Share new and fresh ideas with them and be attentive when they share time-tested techniques and horror stories.
The horror stories will teach as much, if not more, than all of the above.
- The Manager's Path
- Managing Humans
- Radical CandorSo, a few (sorry, not that few) notes:
* Too much information around You will feel lost in a sea of information. There's an infinite number of posts, blogs, threads talking about tech lead. You will want to read everything before doing any action. However, it's impossible, and you'll quickly feel overwhelmed with all that info.
* Listen your team and know their pains More than knowing everything about tech lead, what's really important is to know your team and where you're going. 1on1's with everyone will bring the knowledge for that. They will tell you their frustrations and pains. These will be the first insights on where to start your job.
* Delegate and communicate Just because you're not coding, it doesn't mean you are not working. To me, that was a big issue. So, in order to sort it I try to communicate regularly so that the team has visibility of what I'm doing. Also, most of the times you will have too much on your plate. Feel free to delegate. I'm pretty sure that you will have volunteers for certain areas (in my case, infrastucture, front-end,...)
* Iterate fast Iterate and fail fast. One of the biggest pains I felt was the fear of releasing something which was not perfect or that I was not secure of. However, it will never be perfect. Your team is not like any other team described in blogposts. Teams are always different, which mean different approaches. Instead of waiting too long for releasing something almost perfect, release, fail and improve more often. Be aware that if you iterate once each quarter, at the end of the year you have 4 iterations and 4 data points. If you iterate monthly you will have 12 iterations. Way more precision to fine tune your team.
* Are we engineers, or are we humans? (terrible pun with The Killers song) Each person of your team is different, each one of them has a different life with different problems. We all have our own different battles in life and sometimes we need to spend energy and focus on other things rather than work. Keeping that in mind some are more shy, some not. Some will think that they own you something, that they are behind schedule and hurting the team. Usually these people won't feel comfortable about talking their pains. Be their leader and help them. Actively listen each one, give them space and support when necessary.
* Align expectations Make sure that there's a common goal, and that everyone understands it in a crystal clear way. At Whitesmith, more than knowing how to master a couple of techs, our team must be critic about the product. Our good engineers will then find the best tools for the job and then you can step in to define boundaries on which tech is better for that specific problem. But it depends a lot on the company. Question yourself what's your most common project type and what's your best set of tools. Do you want to be really good at just that? Or do you prefer to be more flexible and allow other tools? Define standards, some role models of your team so that people know where the team is going and consequently where they are going too. It kind of reminds me of Ryanair. All planes are 737 to minimize differences, processes and overall complexity.
* Growth aka learning, enineering manager, space for your team to improve Give your people space to grow. Try to find time for them to learn something new. However, it's also important to find a place for this knowledge to be applied. Learning without a purpose and not being able to apply it regularly, seems to be almost as furstrating as not growing at all.
Sorry for the long post. A lot of things coming to my mind atm. Feel free to reach out and disagree. That's actually what I do as a tech lead with my team. Also, I've been told the book "The Phoenix Project" is a really nice read for tech leads.
All the best!
1. Checklists make everything easier. What needs to be in the checklists should be the most common issues that come up during code review or have been related to defects that made it past the dev environment.
2. Good agile documentation means all business rules/application behavior requirements should be in the story/task and in a centralized wiki. This makes it possible for new team members to familiarize themselves with application behavior quickly, and that list of behaviors is also the documentation on what needs to be tested so QA can implement integration and regression tests.
3. Every major code review needs an organized explanation of code changes per business rule. I've got my team using a OneNote where they initially write down each stories business rules at a high level for non-technical people in a list format and add sub items that describe an architectural overview of changes like design patterns and technologies used, and an addition sub level briefly describing code changes. I also have them provide links to an articles they used to make decisions or that describe design patterns used rather than needing to rewrite them. This rarely takes longer than an hour for a large story and it provides a semantic map between business logic and technical terminology for non-technical people and a sort of historical stream of consciousness that can be looked back at to get a feel for the history and direction for a given project.
4. Assess how team members are doing with technologies they use and get them whatever training they need.
5. No matter how experienced a developer might be before they join your team, new team members should always start out by getting the project to run and fixing bugs. Expecting too much too fast is a guaranteed way to lose high quality talent.
6. Always keep your ego out of everything and if someone is getting defensive about code, remind them that there is no such thing as perfect code. There is always room for improvement, and the focus on any changes or development/architectural decisions must always be about the potential future cost of each decision. Principals like Dry and Solid are important, but over implementing them will always result in difficult to maintain code. Abstraction is only good if it doesn't lock you into a design pattern that might not apply to the future state of all application behaviors you might need in the future. Also, reflection based code is cool to implement and a huge pain to get right let alone maintain or update.
7. Always beware implementing anything you're excited about. Code should always be focused on efficiency and maintainability, never on how cool or familiar a specific tool is. This is sort the same as keeping your ego out, but more about keeping your excitement out of things.
8. Developers should talk to customers, and logging should be implemented in ways that enable analyzing feature usage and user feedback. Many feature request come from managers, but the end users are the people that really need to feel like your software improves their lives.
9. Beware any list that has a psychologically pleasing number of items because it is definitely padded out or shortened to reach that number.
Doesn't ask from the team things that he wouldn't or isn't capable of doing.
And as many of the other comments have said you are there for the team. They will produce the real value.
What can you do to get them all the things they need to succeed? What can you do to shield them from the nonsense? Poor requirements, unnecessary meetings.
I think you want to give chances to fail but also provide that safety net so they don't fail too hard.
As a former Google tech lead (and I know this sounds like a YouTube parody): my advice is don't be a "tech lead" for long. Either be a dev or move into management. Make up your mind. Google "tech lead" is defined above.
As a tech lead in such informal position, you'll end up doing 2 jobs and you'll eventually find that the level of effort required is not commensurate with compensation. You can make much more and have a faster career progression as a manager. You can make the same money with less effort and headache as a dev. Your IC career won't move any faster just because you're a "tech lead", indeed the opposite could be true, because now a non-trivial fraction of your productive capacity is taken up by intangibles which are very difficult for an IC to articulate the value of come performance review time. Being a tech lead makes no logical sense whatsoever, at least not at Google, unless you're aiming for a manager position in the near future, and you need to demonstrate your "leadership qualities".
Other companies may differ, of course, but I bet it's like that at most places that have "tech" leads. In contrast, at Microsoft there's "dev lead", not "tech", and it's a frontline manager position, with reports and authority, and with the aim to move upwards on the management ladder.
Google-like informal "tech lead" is not even a title, it's just a SWE too stupid to understand that they're basically doing more valuable work, and more of it, for the same money.
What have your experiences and tasks been so far as a mid-level developer? What were you in charge of? Did you have a regular rapport with other departments, with clients, stakesholders? Did they talk to you directly when they "wanted things done"?
What are the sizes of the companies that you've worked in already? How big over all, how big were the teams you were on?
I'm surprised no one is asking these questions to see what existing experience you do have can contribute to this, because it is possible that this might be a natural extension of what you already do. It's company-size specific, but good to ask all the same.
In smaller companies, being a mid-level developer means occasionally having to make a call that directly impacts the bottom line and talking to the CEO and clients in a very matter-of-fact way. You wouldn't know that from just the title of a person however.
If you ask them to put work ahead of family or faith or rest, or if you somehow expect more than 100% effort from them, you're going to drive away the ones who have other options. And the reason they have other options is because they're the best ones.
If you feel that you are a mid level developer then positioning yourself as a newly minted and inexperienced tech lead is a recipe for failure, someone else will be called in later on to clean up the mess, assuming the company survives.
I'm only responding to the content of the post, if there is more that I'm not aware of then you're free to point me to it but for now this stands unopposed based on the facts available. After all, what better way to interpret the question then to answer it truthfully?
Often this will be a case of one person having all the knowledge of a specific thing and needing to pick up any bugs around it, sometimes it’ll be that they’ve been given a task they’re not equipped to do. Occasionally they’re just not very good. Those are the cases that are reasonably easy to deal with.
The worst cases are the true believers - people who are so bought into the company, or the work they’re doing, that they just want to be working every hour of the day. The temptation will be to shrug your shoulders and count yourself lucky that someone is willingly doing a bunch of extra work for free. Don’t let them do that, because otherwise they’re going to burn out at some point, at which point you’re stuck with a bitter wreck of a person dragging the rest of the team down, and also suddenly lost a massive chunk of productivity that was carrying projects.
This sort of thing is especially common in early stage startups, and I’ve on occasion had to go round the office kicking people out. On one occasion I had someone go on holiday but continue popping up and doing things, eventually I had IT disable all their accounts for work systems until they got back.
The other thing around this I’d suggest is not to let a culture of rewarding heroics to build up. You should see every case of someone having to work a 100 hour week as a failure, even if it meant the project got shipped on time, or whatever fire was burning got put out. Post-mortem it, and then fix the root cause.
This applies to creative work: development, document writing, content production and similar. Meetings, sales, email and other types of interactions are less taxing.
People who do great work tend to think about their work all the time. No one thinks about their fourth priority all the time.
I have observed an inverse correlation between consistent, unasked overtime and ability.
It's okay to make mistakes. Really, you're going to make loads of them, and your team is going to make loads of them and you're going to own those mistakes.
It's now going to be more about getting the best out of your team than it is about squeezing out more code. I spent a lot of time beating myself up over how much code I wrote dropping off, there is a nice sweet balance you'll find.
Learn to delegate, and learn to do it early. You'll burn yourself out super quickly otherwise.
My primary advice is a strong "most people asking this question should not do this".
Not because you won't be good enough or grow into the job, but because it's a completely different job - and one that many programmers who actually like programming don't enjoy and in many cases aren't well suited for.
There are two toxic traps I should confront. The first is that titles like "tech lead" and "CTO" flatter your ego and impress your friends and parents. The only thing I can think of that exceeds this on the "sounds amazing today; tomorrow you'll start the rest of your miserable life" is an idealist taking money from a VC. Find a different way to impress your dad.
The second is that many companies do not understand how to incentivize programmers beyond "junior/intermediate/senior" (even architect is mostly just a senior who has to spend time managing, eg are distracted and less productive most days than a senior with a closed office) and you get to the point where the upper reaches of the programmer food chain are managing other programmers. Very few things could be more destructive. Honestly, it's fucking obnoxious.
You know what the very best programmers should get? A salary twice as big as the next best programmer, a quiet private workspace with permission to work from home, paid childcare and spousal assistance, and firm dedication from the management to insulate them from as many meetings and distractions as logistically possible. There should be penalties for disturbing them. Now that's tech leadership.
Also, the folks saying that you're working for the product, not the company are high as a kite. They are painfully wrong.
Long story short: if you love what you do, thank them politely for considering you and ask them for a quiet workspace and insulation from meetings. Then get back to work.
2. Lead by example - be the change you wish to see
3. Focus on strengthening your team members (designers and product managers included!)
4. Ensure your engineers are given ownership and leadership opportunities
5. Do not be afraid to let someone else lead - actually encourage this
6. Do not overload yourself (surprisingly easy to do)
7. Expect the amount of time you spend developing to decrease
8. Expect the amount of time you spend in meetings to increase
9. Actually spend time learning the business your code supports
10. Become a resource to the non-technical ppl your team supports
A lot of good advice in this thread, but remember to have patience with both yourself and your team as you take on this new role. Nothing changes overnight and it might be a number of weeks/months until you find your groove.
Congratulations and best of luck.
So understand your own manager's approach to management, and make sure you're aligned with it. Recently I was in a job where my own "servant leadership" style clashed quite badly with my boss, who was much more focussed on management "driving delivery" of projects. It did not end well.
If a team member comes to you and says that they feel disrespected, discouraged, ignored, or even _bullied_ by a more senior team member, take that seriously. Immediately schedule a 1-on-1-on-1 and don't give anybody any time to prepare. Create a safe space for people to voice their concerns, and express to _everyone_ that if they are not capable of treating others with respect, they can be made redundant.
I'm going through this right now and it sucks. I wish my team lead had my back, but they don't.
You doing their work is sometimes going to be needed, but a 'good team' has an equitable workload. Be willing to do any of it.
The biggest thing a team leader can do is help the team communicate with itself. The worst thing a team leader can do is create conditions where team members are not communicating.
The point I am getting at is that it is OK and I'd argue optimal if the team leader knows less than the person they are leading and the team leader has to ask them questions about how something works, but their job is to know enough to be able to make decisions and get a feel for things.
(Examples include things like magic numbers instead of #defines, use of strings instead of well-defined enums, pull requests with lots of commented out code. They can also go to deeper topics, like bad database schemas or poor data access patterns.)
Why must you pick a side quickly? If you treat incompetence or inexperience as an interpersonal dispute, you aren't managing. Instead, your team will quickly view you as appeasing incompetence, and this will quickly drain morale. This is especially the case if one person should be moved to a less-challenging role, or fired.
From personal experience: In these situations the technical lead fixed the code before merge, and management eventually pushed the other person out. But, it was a long slog while management tried to be diplomatic with someone who just wasn't willing, or able, to be professional.
In the case I was involved it was two very competent senior developers and the dispute was between a iterate-fast-and-learn approach, and a build-for-the-future approach. It wasn't clear which one was right at the time and I respected both their opinions. It became clear that it was growing from a technical disagreement into something much more personal. I let it go too far and felt like I needed to step in and pick a side. I believe that I missed an opportunity for them to come to a compromise and learn something about that experience, instead ending up with one very pissed off dev, and one that thought I was on their "side" from then on.
Sometimes you feel like you have to make a decision just because your in a position of power, when actually in many cases you can be there as a mediator, lowering the emotion and keeping things professional and let people work it out themselves.
If it's not safe enough to try, then understand when you use your authority to stop them there will be a strain on your trust relationship that you need to deliberately rebuild.
[0] https://randsinrepose.com/welcome-to-rands-leadership-slack/
I respectfully disagree. A good leader hires, nurtures and grows individuals that are better than himself. The goal of course always is to have the team be more than the sum of its parts. In doing so it should be the goal of taking it much further than the leader could ever have gone alone.
This should leave you time to plan, teach and review as well as attend the meetings and do the paperwork that inevitably comes with a leadership role.
Enjoy.
- Treat your team like their adults, not children, and respect them like such.
- Also, be transparent and clear with them. Hiding things or beating around the bush just wastes everyone's time.
- Give them autonomy to explore new tech when they get the itch, and you'll likely get better results and keep your team active and engaged.
- Embrace the blameless culture. Failures and bugs happen. Being hostile about it means people are more likely to hide stuff and not be up front about things. Not to say it shouldn't be addressed if it becomes a problem, but everyone's going to mess up sometime. Also, it's your job to make sure that any heat from on-high doesn't come down on them.
1. have your team's back, no matter what. They (and you) are going to screw up but your team is counting on you.
2. make the team better, every single day. Whether it's technical, emotional, productiveness, it doesn't matter. The team just needs to be better every single day.
3. get rid of the assholes, acquire those who want to be better
4. see the forest through the trees. Understand and appreciate how the work your team does translates into dollars for payroll
also, a while back someone posted this link on leadership from the Army. It's more straightforward and clear than any airport bookstore leadership book you'll ever find.
If your project pipeline has a non-coding architect, they better be your subordinate. If they are not, be prepared to push back on their design decisions. Ideally they should have a stake in the project delivery.
When some estimate, deadline or feature complexity feels off to you, listen to your inner voice and stand your ground. No matter what others, with more seniority/authority/clout in the company think.
Take care of your team. Get rid of slackers, but don't overwork the others.
Accept responsibility for the failures, and share success with the team. "I failed", "we succeeded".
1. Collaboration is key:
1a. When there are differences in opinion on how to implement something, your desired outcome is that the right thing happens for the company, and that everyone feels like their opinion was heard and legitimately considered. You don’t want to alienate even the most junior engineers even if you have absolute power over them.
1b. You need a good relationship with your business partners/customers, with your boss, and with your direct reports. Make this a top priority. Productivity improves drastically when the customer loves you. You need the upward, downward, and lateral relationships healthy because it’s crucial that you and your people feel safe to talk about the truth and work on solutions together. Counter example: people don’t want to ask for help or talk about what they’re feeling uncomfortable about because they think they’ll be judged as incompetent or a problem child. It’s important that you don’t feel that way when talking to your customers or boss, and that your people don’t feel that way when talking with you and each other. Foster a culture of love, respect, and acceptance to help with this.
1c. Pick your battles. Figure out for example when a design decision really matters strategically and when it can go either way. Give your people as much latitude as you can to give them a chance to learn from their mistakes.
I drone on here about collaboration because some of my larger failures in the last few years are because of running afoul of these ideas. Forgetting these ideas often leads to winning the battle but losing the war.
2. Constantly work to empower your people And figure out how they need to grow. Figure out their target growth areas, keep notes on those, give them opportunities to grow and learn in those areas. Watch how they do, and give them feedback every chance you get about what they did well and how they can do better. Never miss an opportunity to show them how pleased you are with positive things.
https://hbr.org/podcast/2019/08/the-challenges-and-triumphs-...
The Making of a Manager: What to Do When Everyone Looks to You
I'm not a manager and I found a lot of value in this. I now ask my manager and my peers for immediate feedback anytime I lead a meeting. I've also adopted the habit of providing unsolicited feedback.
There are people who have a very different life, which I deliberately choose to avoid. Talking to these people diverges into talking about myself as there is always something exciting happening somehow, and they do ask about it (maybe out of politeness, but I'm a bad judge for that). These people sadly form a majority of people around me.
However, there is a much smaller number of people who I can listen to for hours and I genuinely care about what they have to say, so I ask a lot too. These people are really excited about their lives and have stories to tell. In my experience, not a lot of people have that. Also, they tend to care about things that I can say least imagine someone caring about.
So overall, maybe there is nothing to fix on your side here. At least, I think, there is a possibility of this.
Do try to keep things simple. By that I mean if you have the choice between a simple rpc framework and "the netflix microservice architecture with message queues and scalable container orchestration", do learn the latter, set it up, scale it to multiple sites over a vpn, but in the end,
you know what to pick.
In addition to others' recommendations about reading "The Manager's Path" (this is a must-do! An excellent book) I would take a look at how the team makes technical decisions and make sure that's healthy, and also make sure you have an understanding of the core value your product is trying to deliver by talking with your Product Manager.
If you are the defacto Product manager, make sure you know what the business is trying to accomplish so you can build the right thing and prioritize appropriately.
The more I do this work, the more a clear, open, decisionmaking process and a clear understanding of the value increment power everything else. Context and a way to talk about it.
One other note: your job will change. Know that. Be OK with it.
Good luck!
Decisions which carry little risk and are easy to undo or pivot in the future, make them quickly and confidently.
Decisions which carry non-negligible risk but are easy to undo, give some thought but don’t fret too much. If the risk starts becoming reality, you can change your mind later.
Hard to change decisions with low risk are tricky. Make sure the time spent on research and decision making is proportional to the risk, which in theory is low, but that needs to be double-checked.
Decisions that are hard to undo and carry significant risk should be the ones you spend as much time as necessary thinking through, planning out, coming up with contingency plans, building in safety checks and making sure that you can avoid making those hard-to-make changes should you decision prove incorrect.
One additional resource I would recommend is https://devtomanager.com , which is a list of interviews with other developers on how their transition was like.
Good luck on your career move!
I’ve even had medications turn meetings and such social interactions around for me. So I know it’s not a universal truth one or the other way.
It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself).
Ask your team to write out everything they plan to do before they actually do it. Reason with them on what they wrote and what approach decisions they plan to take. Teach them to think long term. Writing before actually doing the task helps get a lot of clarity to them and also helps you in assessing what they were planning to build. (It also makes for a great log of what we did and why we did it. This will be the product documentation for your entire product tomorrow.)
Treat your team like your family. Do not stress them out with too much work. Be respectful of their time and effort. Give them breaks post completion of major tasks. Every second that you let them rest and breathe is a second you have invested in the future. They will recharge and put their best in the next task.
You have a tough job of standing up for the right long-term tech decisions. Stay loyal to your product. Work for your product - not your company. Take tough tech decisions that will stand for the long term stability and robustness of your product. But occasionally make allowance for your business team too.
Sometimes your teammates might shy away from a big daunting challenge - step in and work side by side with them to tackle it. But do this infrequently.
There is a lot to add to the above list but in general the idea is to help your teammates grow, help them think critically, stand for your product - make the tough calls.
All the best!
At a startup, the business objective has to come first and the engineering team has to keep the bigger picture in mind. "Long-term stability and robustness" won't matter if your company is dead. Build for the short-term and build fast while you are figuring out product-market fit. Move fast and break things.
If you’re at a startup, your product is your business.
The point about not hesitating to move fast is the biggest difference between startups and mature companies.
There are different types of startups. Not all startups are working on novel discoveries and exploring new frontiers. Zoom built a better video conferencing platform by not moving fast and breaking things.
I think at a start-up the correct decision early on is to take on a bunch of tech debt, but then pay it down as the horizon of the company expands.
Early on, you need to iterate fast on a few key flows and make a product that people want, but once you get product market fit, things like scalability and reliability start mattering a lot more and you need to pay down the debt.
The issue comes when the company's objective is actually to build a reliable, stable, long term product, but it is still in startup mindset of "ship this feature by yesterday at all costs", and expects the rest to come for free.
I've heard so many times "think of bigger picture".. but when we did the tech team got kicked down - as we didn't achieve our own objectives because we sacrificed them for "bigger picture".
I found while scaling my team tended to bury themselves in miles of docs that really did not serve the customer or the company. A janky kind of working prototype of a solution is worth a ton more than a well thought out doc.
A simple 2-3 line github issue is often enough. what and why.
Being tech lead in current position, I am stressing "document-first" approch it is either for client or tech team.
Meetings, other than 1 on 1 meetings/collaborations, are best for making decisions, NOT for sharing information.
Information sharing relevant to the decisions to be made should happen before the meeting via group emails (or possibly through a software tool like Jira) with questions and responses. Written information is easier to reference, quicker to search through, and can be multiprocessed in that multiple people can share information or ask questions simultaneously. If additional information is needed after the fact, you can email after the meeting.
Going into a meeting about building a feature or product for example, you should know the constraints on that, and be able to weigh them in making the decision. When is it due? Who is available to work on it, who will test it, who will maintain it, and who is it for? What aspects/functions are necessary, and what are merely desirable? What resources are available? Why is the feature being added? How might it be constructed?
Finally, be ruthless about moving forward in meetings to get to decisions. If a couple of people agree on something, and begin to quibble over the details? Ask if anybody is opposed to that general idea or has a better one to offer. If not you have made that decision, and can decide on the details, but if so, the detail discussion is premature. It's quite probably also premature if you haven't decided who is going to work on it; the point is you want to nail down the higher level decisions, not get lost in the weeds.
In my opinion, writing things down helps to clarify your thinking and lets others understand how you think. It also reduces the risk of the devs implementing something that doesn't fix the users' issue.
They think writing things down is overhead, too much "process", too much time. What they (IMO) don't see is that discussing requirements, assumptions before developing a feature (or even prioritizing a feature) helps to establish a common understanding of the issue and the proposed solution.
> It will no longer be about you. It will all be about your team. Make sure you create a great team, nurture them, train them, teach them how to think critically (in doing so yourself).
When I had a TL job, I basically relearned the word "team" during my very first weeks. It was an amazing experience.
It is important to listen to your users, but not necessarily do what your user’s want.
Especially in the context of the user’s role.
Adding a thousand requested features also has its drawbacks.
If you stand up for your product, you are standing up for your users, or your clients if that's a less ambiguous term.
For some teams, for example a lot of teams in Google and Facebook, the end-users are often different from the Product's clients; the client of Google's Chrome is Google's empire. The programmer that added the X-Client-Data header undoubtedly improved the product, at least short-term-business-wise, while actively harming it for end-users. Someday end-users may leave if they continue to erode trust, but for now it's a boon for the Product.
Edit: Please don't work on those products. Please develop products that respect people. If you develop trust, and actively respect people; I posit that a lot of people will opt-in to reasonable analytics, and even advertising. If many don't now, they might when the dust settles.
The one caveat is to be sure to also think about your team members as "users" of the code base.
The best managers build super star teams and gives the teams ownership and autonomy. You are in a good position if the team is teaching you, not the other way around.
Try to build a team made up of people technically superior to you. And give them ownership, this is key. It is not just about finding engineers who take ownership. It’s about giving engineers ownership and getting out of their way.
The replacements were a developer just coming off a PIP and a new graduate with zero industry experience, having not interned. I still kept the focus on developing the team as much as possible but the candle needed to be burned on both ends: taking on a large majority of implementation whilst quietly fixing mistakes made as to not shake growing confidence were commonplace throughout the first 6 months.
Towards the end of our involvement in our product I’m proud to say that both developers had outgrew their ranks and delegation and trust came without thought. I was pretty close to burnout by the end of that year if I’m honest with myself though and my own career progression has without doubt stalled due to it
On the subject of teaching your team you're right however. Instead aim to create an environment that fosters sharing. In my team I created a weekly tech share which the team does on rotation. It's been great for harmonising the team.
Ask your team to write our everything they plan to do before they actually do it. Reason with them on what they wrote and what approach decisions they plan to take. Teach them to think long term. Writing before actually doing the task helps get a lot of clarity to them and also helps you in accessing what they were planning to build
Treat your team like your family. Do not stress them out with too much work. Give them breaks post completion of major tasks. Every second that you let them rest and breathe is a second you have invested in the future. They will recharge and put their best in the next task.
You have a tough job of standing up for the right long-term tech decisions. Stay loyal to your product. Work for your product - not your company. Take tough tech decisions that will stand for the long term stability and robustness of your product. But occasionally make allowance or your business team too.
Sometimes your teammates might shy away from a big daunting challenge - step in and work side by side with them to tackle it. But do this infrequently.
- Not delegating. New leads often feel that if they're not writing code (or doing whatever it means to be an individual contributor), they're slacking off. The definition of "work" has changed. It now means "helping your team succeed". If you try to be an individual contributor, you are doing your old job instead of your new one, and you'll get overwhelmed and sink.
- Not asking questions. New leads often think that being a lead means being an expert, so they're embarrassed to ask or consult someone else about their team's domain, for fear of looking inadequate. Your team and your peers are the experts— it is your job to ensure that expertise prevails, whether it's yours or someone else's. You'll look much more dumb if you're too insecure to admit what you don't know, or fail to ask basic questions that allow you to get the job done.
- Hiding problems. When things aren't going well (and often they don't), don't hide this from the leadership above you. They are there to help you and guide you, and can save you from crashing and burning. You will look much worse if a problem comes to light months after it could have been communicated and dealt with.
- Not communicating. Share what's going on with your team. Share what's going on in the big picture. Don't keep people in the dark, either above you or below you.
Some leads (moreso if they're prone to impostor syndrome) think they have to wait for permission to speak, or to be offered something that they need— don't do this. If you have something important to say/ask, it's your responsibility as a leader to say it and get what you need.
- Forgetting the big picture. As an individual contributor, you often only have to think about near-term or small-scope problems. It is an easy mistake to make as a new lead to spend priority on those things instead of keeping in mind what's necessary for the entire team to succeed at its high level goal.
Good luck!
1) You will not need to trust others to write better code/systems then you and that you will very likely be unable to code anymore.
2) Establish a good relationship with your team members. Seek for people who you can delegate to and trust. Trust and reliable people are really hard to find. When shit hits the fan - and it absolutely does - you'll need that.
3) You need people who will push and people who will follow. Having just one group and not the others is a recipe for disaster.
4) Establish what things you should care for and what not. The amount of shit is insane and it only gets worse you need to have a threshold on when and on what to react.
5) Do you own research as much as possible on key things.
6) Keep asking "why". It annoys me as f* but also forces you to go deeper with explaining and understanding of the problem. (don't wanna say google "Five whys")
7) Encourage people to go deeper, to learn more to become experts.
9) Have 1-on-1s. Regular. Scheduled. Talk about life/work. Try to find how you can make the place and challenges better. Help them grow in an organisation and professionally.
10) Sketch things out. Write em' down. Otherwise, you'll go insane repeating stuff.
I sincerely wish you good luck.
P.s.: People have more bugs and are sometimes even more broken than software. :D
It's also very important to know more about your employees on a personal level. Are they going through a tough time, do they feel unchallenged or bored? Do you have issues between team members that need resolving? All this can come out in these 1-on-1s.
1. https://pragprog.com/book/jsengman/become-an-effective-softw..., which had a good conversation here (https://news.ycombinator.com/item?id=22033129).
2. https://managinghumans.com/ by Michael Lopes
3. https://leadingsnowflakes.com/, which also has a good weekly newsletter - http://softwareleadweekly.com/.
4. https://www.udemy.com/course/practical-leadership/
5. https://tomdemarco.com/Books/deadline.html - quite old now, but it's still hugely insightful.
May I wish you the best of luck. It's an exciting and really difficult challenge, but can be hugely rewarding in the end.
He also hosts a slack that's up to something like 100,000 people. Ask a lot of dumb questions.
https://randsinrepose.com/welcome-to-rands-leadership-slack/
They assume the best of others.
They lead by example.
They are a facilitate as much as they delegate, and they don't lose sight of the fact that you can't lead from the trenches.
A good leader remains objective when it's hard to do so, and doesn't take it personally when somebody disagrees with them.
A good leader is kind, humble, and willing to help.
A good leader doesn't back down from using a firm approach when it's needed.
A good leader doesn't apologize for doing things that have to be done (discipline, firing etc).
Agreed. Unless a leader is taking the responsibility for a failure (which they should!), the leader should never say "I". When talking about a success it should focus on the team, and is okay to point out individuals who did great work.
I cringe every time I see a lead/leader present team work and say "I" over and over.
Not sure why this analogy is applied to software development. The best managers I've had lead from the trenches where we all work.
I don't believe this statement... I generally assume and believe the best in people but after years of working at large tech firms... some people are literally there to put in minimum effort needed to not get fired. Some people are actually even worse and will actively drive away the high performers with negativity and nothing you do or say will change their opinion.
Being a tech lead is only partly about the tech, and mostly about the lead. You'll ultimately succeed or fail based on your team.
Being an effective leader requires a completely different set of skills than being an effective engineer. This, as silly as it sounds now, took me by surprise. You may have a decade-plus of dev experience but still be starting from zero when it comes to people. (Or not; some people will be better equipped for this than others. I wasn't so much.)
Find a mentor. Someone you can be completely honest with, and who will be honest with you. Bonus points if they know your team well too -they'll see things that you won't.
You may have to be pretty intentional about finding out what's going on in your team. Once you're in a position of authority, people won't always feel free to tell you.
Share as much context with your team as you can. They'll be more motivated if they understand why their work is important and has value. Even if you understand this... people aren't mind readers. They don't know what's in your head.
Part of your job now is to be available to people. This may mean you don't get to actually work on the tech yourself as much (or at all). It may mean you get interrupted more. That's may or may not annoy you, but you need to make the best choices you can for your team now, not (just) for you.
Share success when you can. You may find yourself in situations where people attribute your team's success to you... and while that's not wrong (you're the lead after all) it's also a great opportunity to share credit with those in your team. It's worth so much to people when you do this.
People are not interchangeable, and treating them as if they invites trouble. You can have great people, who still have a hard time working together for whatever reason. Be aware of inter-team dynamics; they can sink you. (Situations like this are why it's great to have a mentor.)
It's important to keep a close eye on how things are going, but don't confuse that with micro-management. Your best people are going to want some autonomy, and it's best for everybody if you find a way to give it to them. If things aren't going so well your instinct may be to tighten your grip... not necessarily wrong, but consider that may come across as a lack of trust on your part.
Above all: think of your job as less about being in control (though you may be) and more about fostering an environment where your team can do your best work. Get them what they need, shield them from the crap, give them what opportunities you can. Don't be selfish or mean. Be kind, be empathatic.
Good luck.
A leader is best when people barely know that he exists, not so good when people obey and acclaim him, worst when they despise him. Fail to honor people, They fail to honor you. But of a good leader, who talks little, when his work is done, his aims fulfilled, they will all say, “We did this ourselves.”
Your role is now defined by what your team needs you to be. Listen to them, care, and see what you can do to help them thrive.
As a manager, this won't be the case. You won't get that instant reward like you did as an engineer. It might be months or even years between when you started something and you see any reward for it. It might be weeks before you even get feedback that something changed at all. Hell, you might never get to see the reward for a project you have in the oven. This can be very challenging to deal with when you are used to getting near real-time reward for your work.
You will have to adjust to the new reward cycle as you step out of coding for a day job. It's okay to have mixed feelings about it too. Just know that you will have to find other ways to find reward in what you do.
You get bombarded by everyone outside your org who has a question vaguely related, and by your junior devs for anything they don't want to figure out themselves, and by your manager wanting to know whether we can release this half baked component X to some other team even though it will break production. You get maybe a little extra recognition but it's just not worth the 3x extra work.
You succeed when your team succeeds... if they don't, then you don't.
In my case, I don't have any authority other than influence. That's ok, it also takes a lot of responsibility off my plate.
If you have authority over people, know that you can tell them what to do if you have to, but if you reach the point where that's all you can do, you've failed.
I have a Lead title at work, but like you I don't have any authority over anyone. So I don't really have any advice for the OP, as it seems what "lead" means varies so much from company to company, and to me as soon as you get in the business of authority you really need to start thinking about management, not tech, to which I can only suggest read Deming.
I think my ideal model for 'tech lead' is something like how (I've heard, could not actually be the case) Bryan Cantrill at Joyent operated. Even when he was VP Eng, and later CTO, he still was involved in code, and generally engineers there both "led and were led" without very hard cut roles on that axis.
People are the only thing that matters. Deadlines come and go, companies go bankrupt or get their entire C-suite arrested in midnight raids, competitors come in and break everything and turn the company into a zombie. The thing that endures is the people. If you have good people on your team, consider yourself lucky; being a great boss is one of the best ways to cement a lifelong connection to the best people, and you'll get way more benefit from it than you deserve.
Nothing is straightforward or face value. Understand this and don't try to change it. There's a lot that you'll have to learn for yourself, but keep your priorities and loyalties straight, don't buy into anyone's bullshit too far, and you'll be fine. Good luck.
I would say what that means is, internally, you run interference to shield your reports from management incompetence and thrash, you take responsibility for failures, and internally promote (in the "promoter" sense) them. And externally, proactively provide professional advice and support, even if that means losing someone important to your team.
More than anything else, those are the qualities I strive to as a manager. (Not saying I'm perfect at it)
General advice without a specific individual in mind is useless. That's like saying "do the right thing".
I’m only half joking. Hopefully your company is ‘one of the good ones’ and it will work out, but they are few and far between.
The tech lead job varies a ton from one company to the next, but all too often it comes with high expectations without enough autonomy or authority to deliver on them. Make sure your boss provides clear expectations and work with them to clarify boundaries over time. I’ve been on both sides of this process and it is difficult and necessary.
Too often, tech leads are expected to wear more hats than they are able to wear well. Delegate all that you can and if there is still too much work to do, ask for help.
It’s all about communication so actively work on this skill.
1. Remind yourself daily that the metrics you've used to gauge your own productivity or success until now do not apply. It's really hard. Resist the temptation to do non-TL things if it will affect your TL responsibilities.
2. Find other people who have more/broader experience than you do, and pay attention to the perspective they provide. There are many people who know more than most TLs but don't want the role themselves. You can help each other.
3. Remember that lead is as important as technical in your job title. Your role is to bring people to a place they're not already. Figure out what's missing in your project and/or your team members' skillsets. Those are the things that it's your job to address.
Also, remember to reserve time in your day to deal with problems raised by the team. These will often occur when you are least expecting them. And some may be outside your own comfort zone.
On a positive note I found that being a tech lead made me a better team member for my own management, since I better appreciated some of the leadership challenges they were under. You'll sometimes be left stunned by how hard or well your team members are working to solve problems, and this can make it all worthwhile.
Make sure that technical decisions are documented (e.g. via an ADR), making sure to document what you and your team know and consider at the time of writing. This is a pushback to hype-driven development; you don't want to be stuck with a bad decision just because one team member showed up at work one day with a feature implemented in technology X without proving they've done the work for it. And you don't want to have to waste time with future employees explaining (again) why technology X is used - you can refer to the docs, and if they want to challenge it, have THEM come up with counterpoints, have them sell it to you and the team, and have them defend the time / effort investment to change the technology.
Re: hiring, always do a technical interview, even if you're hiring internally. Involve your existing team members, they have to work with the new candidate after all. Have the applicant do a small project (4-8 hours) representative of the technologies and context of your project in their own time, and challenge them during the interview (the goal being they can prove they wrote and understood the code they produced).
what is an ADR?
1. Read the book Extreme Ownership by Jocko Willink. I'm not the first to suggest this book but it has fundamentally shaped how I work and how I interact with others.
2. Try to write. I'd start with writing your "Manager Readme" file even if you don't plan to share it with anyone. Defining expectations is critical and it's start with understanding your own psyche. What is important to you? What are your expectations for someone? The internet is filled with examples of Manager Readme's along with posts that are totally for this idea and totally against. You can find mine without too much trouble if you check my comment history and find my GitHub.
Good luck.
That idea and set of principles is something I'm kind of surprised hasn't become more widespread. It also changed my approach in a fundamental way and is one of those things I wish I had learned a long time ago.
Also I've found his Good concept a useful way to stay positive:
Oh, the mission got canceled? Good… We can focus on another one. Didn’t get the new high-speed gear we wanted? Good… We can keep it simple. Didn’t get promoted? Good… More time to get better. Didn’t get funded? Good… We own more of the company. Didn’t get the job you wanted? Good… Go out, gain more experience, and build a better resume. Got injured? Good… Needed a break from training. Got tapped out? Good… It’s better to tap out in training than tap out on the street. Got beat? Good… We learned.
fist bump
2. your job is transitioning from "doing" to "enabling". You'll be responsible for issues of governance AND operation. Learn the ropes equally. As you introduce successful operational concerns (bottom up) start to generalise them so they can be used as a top-down concern (i.e. i do devops -> we all do devops here, it's part of the training)
3. leading by example doesn't scale - stop. Embrace a teaching method that ends in trust: i.e. 1. introduce a concept to dev A, 2. get dev A to demonstrate it back to you independently (monitor and prompt as appropriate), 3. from afar passively observe future implementations of said concept and revert to steps 1..2 if required, 4. inform dev A that they are trusted explicitly with this concept and that it is theirs to run with - encourage them to onboard dev B in a similar fashion.
4. at the top you're more responsible for team morale than you can possibly imagine - random acts of kindness and/or direct conversations go a long way... whether it's donuts or "a quick catchup" over lunch, do it... regularly (if you find your postponing these kind of meetings you've got a priority inversion issue to sort out ASAP).
5. if someone is dishonest in any way take it to HR before they walk over you and your team/product/department suffers. In other words, with HR's help, address slow/no work or unapproved "wfh" days as a threat.
6. push back against harmful designs and rushed/skipped processes.
In fairness, this could be a good advice for roles that are easy to hire for (e.g. minimum wage manual labour).
Separately it's a HR problem because of the nature of certain types of work. I'm struggling to fit my view with neural diversity though - some devs say dishonest things without malicious intent because they lack skills to effectively communicate.
Interesting advice with #3 - have not considered this before. I like how your approach empowers dev A and, as you say, "ends in trust".
* Code in production = value. *
And the following (I am not the original author):
Ship small (seek the shortest path to show and deliver value to your customers)
Ship imperfect products (perfection is the enemy of done)
Ship for your users, not for you
Ship every day (it creates momentum!)
Focus on finishing (shipping), not starting
A shipped product is worth a thousand of blog posts
Ship first. Then iterate
More practically: I write down feedback that is given to me regarding leadership style and write down things that I think about at the 'moment of impact' (assumptions, reasoning, and metrics for success/failure of decision) when decisions are being made. Read over these notes often enough that you are aware of those things when they happen again. Anecdote: Developers often want time to create a quality feature and if they are frequently pressed for time due to business requirements, they are unhappy and the product suffers, often in less than obvious ways. It was only really obvious that this was a problem when we tried other ways of planning and prioritizing because the assumption was that development pressure was a given for a tech company, turns out that some development work can be offloaded by better planning and prioritization based upon better thought out business objectives. These learnings came about because we kept took notes of decisions that were made, and could refer back to them as crucial points of pain/cost/failure.
If you don't have some structure to your approach, you'll find it difficult to call out specific changes that need to happen.
There's a lot more that could be said. Tech leads are often interfaces for other parts of the business so respecting the context of other's roles and aligning incentives is more important than proving your job is being done 'correctly'.
He also just published another article about quality technical communication, which I'd highly recommend both you and your team read through: https://medium.com/@tpagram/a-guide-to-improving-your-techni...
1. Listen - Learn to Listen to Your customer and Team Members. Understand the reasoning behind what they are asking for.
2. Show, not only tell - I used to sit next to devs and see that problem they are mentioning is actually is problem. Sometimes issue could be business requirement. If technical issue, explain throughly teach how to go about solving such kind of problem. If they are still not able to do it fine, work with them while continue to explain. You want to teach - how to go about "solving problem".
3. Learn, Learn More and Learn More and Keep Learning and then Share - Learn about the business domain. Learn about technical domain. Learn about everything which lets you 'get things done'.
4. Delegate - But delegate properly, once task is assigned, make sure the team member understand what needs to be done. And they understand 'how it will be done'. You don't want to figure out at end of day that because of misunderstanding or lack of information task was not done correctly or worse has to be redone from the start. Reworking sucks big time and will suck big amount of time for everyone - you, team member and customer.
5. Get Details - Try to get as much as detail as possible, based on information take decision based on 'who is right for this job'.
6. Don't play favorites.
7. You dealing with Humans. People make mistakes. Find way to reduce chances of happening mistake in first place.
8. Be cool. Never get Angry. Anger drives out reason.
Good Luck.
If you are going to do it, read a ton of books. Minimum in my opinion are: 1. The Managers Path -- general advise 2. Coaching Habit -- for performing 1 on 1s 3. Extreme Ownership -- for building an effective culture that delivers results.
some dev organizations I have use a rotating release shepherd osition (gatekeeper). it usually works out pretty well, and junior engineers get a taste of what its like to live on the other side. its perfectly functional for a senior engineer to mentor a junior manager.
the one thing that concerns me about this story is hiring. my first tech lead position they gave me some heads and I promptly hired two smart-talking bozos with years of experience that wasted my time for several months until thankfully one of them quit and I got up the courage to fire the other.
You can't shortcut these things.
I transitioned into a tech lead a year ago and at first it was kind of annoyed by all the requests from the team regarding technical assistance.
I realized there were two paths I could take. 1. Continue to be annoyed and try to get as much coding in as I can. 2. Sit down with each individual, help them, give examples of how things should work etc.
Luckily I chose the latter option and I have a great relationship with all the team, I have strong coders that are more self-sufficient, and I enjoy more time coding now.
I think the lesson I learned is that you get out of your team much more than you put in, strive to inspire your devs.
This is one of the important skills to have and will have huge impact on "engineering atmosphere".
I'm realizing I'm not quite sure what is meant by a "tech lead" role.
Second, tech lead is probably the highest position you get to without choosing management vs technical career paths.
You can grow in technical depth and authority without managing more teams, and still stay in connection with the code; or you can try and enable teams to succeed, and steer things towards the business objectives, and spend a lot less time coding. But most companies (at least those that try and retain tech talent) will force you to choose, or choose for you.
(unsolicited advice) What I've learned in working on that skill; avoid coming from a position of supremacy, and rely on actions/results to communicate most of the message. Also, a lot of acceptance and patience.
I like to write a lot of pseudo code before real code, gradually digging down into lower level implementation details, so as to not waste time worrying about syntax while making higher level decisions. However, it's taken me a long time to develop what I have of that skill; to feel out the different layers decisions will be made, then write pseudocode with the intent of eeking out and resolving most of them.
Doing so, things end up feeling more like trade-offs than compromises.
Good luck!
For me as long as people have one or the other I can work with it. I've often been in scenarios with people that aren't good and won't collaborate and THAT'S the hell.
Obviously both is best but the skill set is rare. I'll happily take someone that defers to me and trusts my judgement over the HELL. Its not ideal and doesn't result in the best outcomes but its still workable.
There is a line between this and manipulative dishonesty, of course. Bad faith (when it's clearly that beyond reasonable doubt) should be treated with close to zero tolerance.
Also, I think we are going to see further evolution in the software industry where the current middle-mgmt layers get wiped out. You are either contributing directly to the product - and you can easily measure that - or, you need to get out of the way.
DevOps is a drive to reduce the number of vertical organisational ‘layers’, ProductEngineering would be a drive to reduce the number of horizontal organisational layers.
IMHO.
Where I worked, as a lead I was probably doing up to 50% individual contribution and the rest "management". But I have seen new leads in the same role do 150% individual contribution, and then let their team down on leadership tasks because they've let themselves become swamped. This is a very common error for any newcomer to a job that involves leading other people (which OP specifically says is their role).
I don't think it's an error to put a coder in a position of leading others; it's just that being a productive coder is a weak predictor of being a good lead— you have to look at other markers. Having that kind of "on-the-ground" understanding can be a great strength that can't be had any other way.
IMO a clever one-liner or a hyper optimal routine that takes minutes of staring to decode isn't gorgeous, but you're certainly right that many would disagree with that. IMHO this philosophy runs directly contradictory to the one in which leaders empower those around them.
Sounds like you had a tough time but empowered the team to succeed. Maybe with some personal cost to yourself.
How would you approach the situation knowing what you know now? What would you do differently?
If you want to do management long term and manage bigger and bigger teams without burning out this is what you need to strive for and ultimately impliment aspects of this if you can't impliment it fully.
For bigger teams you even need people with superior management skill sets in order to delegate.
I'm not saying that you have to find the spark or that even everyone has the ability to find it. Sometimes, the challenge is so great that it's just not worth it or beyond your abilities.
But it's still there for everyone. If you're really really good, you can find out what it is for most people and trigger it.
Yeahhh. Sometimes, as you try ever harder to enable someone to succeed, you eventually realize you're becoming their therapist. Sometimes, you realize that enabling this one person to succeed would involve neglecting everyone else. Sometimes the necessary acceptance, equanimity, and nurturing are of such an absurd degree that it looks like special treatment, or indulgence, to any third party.
Your product is whatever you end up with after the long tenuous period of being startup, which often evolves/pivots drastically over time. Your product is your ability to execute.
My last startup died because we committed too hard to the product and the business model, which while innovative and one that I still believe could have succeeded - we utterly failed because we didn't understand our customers and we didn't pivot fast enough, ran out of runway and then everyone but the founders got laid off. Waiting on hearing about the equity.
I'm just talking about the ideal you should strive for. Given the opportunity this is what you should try to do. Of course like many ideals, you rarely have the ability or resources to fully implement the ideal.
What I meant to say is, your philosophy of building teams is for inferior managers. People who cannot perform above the baseline.
Normal and high performing managers always strive for hitting something above the baseline. Not to be insulting, but logically if you think this way than you must be inferior. Just speaking out of pure logic, no malice intended.
In order to approach the ideal you must have intrinsic knowledge of the baseline as well. Good point.
It’s very much not an IC role - we might throw together the odd prototype, and we’re all very capable of rolling our sleeves up and helping out if a project needs an extra person for a bit, but the general rule is that if we’re on the critical path for implementing a project something has gone wrong.
Make me a proper leader with the ability to truly delegate and alter scope, workload and the timing of work or pound sand.