57 ms·

Ask HN: How to Be a Good Technical Lead?

• fenguin 11y ago
  Management is a completely separate set of skills from engineering, and a set you have to force yourself to learn. The best book I've read on the subject is Andy Grove's High Output Management [1] -- it talks about how to choose tasks with the highest leverage, how to run meetings and one-on-ones, how to make managerial decisions, and how to motivate your team. [1] Cliffnotes at http://charles.io/high-output-management http://charles.io/high-output-management
• hamhamed 11y ago
  Good read: http://dev-human.io/~pascaldevink/things-i-was-unprepared-for http://dev-human.io/~pascaldevink/things-i-was-unprepared-fo... Discussion: https://news.ycombinator.com/item?id=10223472 https://news.ycombinator.com/item?id=10223472
• mrlyc 11y ago
  What worked for me was to learn to listen to people, to let them explain the problem and sometimes find an answer as they were talking. What helped was to do lots of peer reviews of both code and documentation so the the young ones could learn from the old ones and the old ones could get new ideas or more up to date ways of doing things from the young ones. I came to realise that programming is flow based while leading a team is interrupt driven so I had to learn how to do context switching quickly and to block out areas of time when I could do my own programming. I had to learn to help people do their work and restrain myself from rushing in to do the work myself. And I had to learn that my team members were people who had lives outside work that affected the work they did. For example, I had a team member who was a good programmer but had trouble coming to work on time. He was getting married so I bought him a clock radio as a wedding gift. That fixed the problem.
  • erlich 11y ago
    Great to hear others have gone through a similar process to the one I am taking now. > block out areas of time when I could do my own programming My biggest challenge is that this time for me is evenings and Sundays afternoons which eats into the work/life thing.
    • mixmastamyk 11y ago
      Maybe take off fridays, and make Sunday a formal work day.
• dorfsmay 11y ago
  - you're going to be part of a lot of meetings, email list etc... Make sure you flow information down to your team, every day. - your main job will be to: - unblock your tam members - bring them back on track - consensus is great, but sometimes it doesn't work. Know when you need to make a decision even if not popular. - praise publicly, criticize in private - give people a chance (give warnings)
  • chetanahuja 11y ago
    your main job will be to: - unblock your tam members - bring them back on track Ditto. Note that the unblocking/course-correcting role is the real job. Depending on the size of the team, you may or may not want to be involved in architecture/design of minor projects that crop up all the time (things that might take a week or two to develop). Your team should trust and rely on your advise/insight around technical issues. Writing code yourself would be a secondary role though if it's a smaller team (2-3) people, you'd be advised to pull your weight there as well. And yes, that set of responsibilities means that this would be more than a full-time job. You should know that going in. If you're more inclined to a strict 40 hour week, you'd probably better off declining this offer.
    • hiram112 11y ago
      And yes, that set of responsibilities means that this would be more than a full-time job. You should know that going in. If you're more inclined to a strict 40 hour week, you'd probably better off declining this offer. Exactly. In my experience, team lead of smaller teams (less than 6-8 developers, testers, etc.) just means 50% more work for the same pay and status. You are not a true manager in your superiors' eyes. Also, it is rarely a way to move up the ladder. In our business, changing companies every few years is the only way to get promotions and raises. Unless the job comes with the ability to purchase resources, make hiring and firing decisions, while also being paid more, team lead is not a position I volunteer for anymore. It's better to use the extra time for your own projects / networking.
  • hluska 11y ago
    This is one of the more useful set of management tips that I have read. First, thanks for adding this information. Second, congratulations on keeping it so concise. Excellent job.
• zschuessler 11y ago
  I would stress this the most: support your team. Give your team the technical and emotional support they need to do their jobs well and have fun doing it. Some things I've noticed that had the largest impact on employee engagement: - 1. Poorly defined development processes heavily impacts morale. Define your code standards, your process for picking a library to use, how you handle versioning of code (and which methodologies), how your team should escalate problems, and expectations of individual team members. Document this in a place where anyone on the team can view it. 2. All projects require documentation on how to setup a build. If that doesn't exist, developers ramped up on the project will loathe the project from the start (and in some cases, the team lead). From scratch, setup a project before handing it off. Document everything you had to do. 3. Onboarding of new team members: make yourself or someone you appoint available at all times for the first week or so. Document and fix anything the new team member needed help with. Onboarding is hard, this will be an ongoing process. 4. Setup one-on-one meetings. Once every couple of weeks seems ideal in my experience. Don't have an agenda, but have a few questions you resort to for filling in quiet spots for the more introverted types. Don't be afraid to ask hard questions (did you have a problem with Robert in accounting last week? are you happy with your salary? what would make you happier?). This meeting is key to employee retention and team happiness. 5. Allow for an open discussion on all major decisions. Have a tool in place where anyone can raise problems. If someone can post anonymously to start a topic, that's ideal. That is where some of the best business growth will take place. 6. Read a book on mentorship. Mentor your team. If someone surpasses your skillset on the team, you've succeeded. I've not read all of Maxwell's books, but he has some really great insight in the couple I've read: http://www.amazon.com/John-C.-Maxwell/e/B001H6NROC/ http://www.amazon.com/John-C.-Maxwell/e/B001H6NROC/ 7. Become known as an advocate/mediator for those on your team and the higher-ups. Fight for your team when you need to, and fight for upper management decisions when you need to. Finding a balance is important, but never lose trust of those you lead. - In many cases, becoming a technical lead also means you are expected to learn the business side of things. It wouldn't hurt to read business-oriented books. Anything by Jim Collins is great (Good to Great is a must-read): http://www.amazon.com/Jim-Collins/e/B001H6GSHK http://www.amazon.com/Jim-Collins/e/B001H6GSHK Best of luck, and congratulations on your learning opportunity!
  • ramtatatam 11y ago
• pgbovine 11y ago
  i enjoyed reading the book Team Geek http://www.amazon.com/Team-Geek-Software-Developers-Working/dp/1449302440 http://www.amazon.com/Team-Geek-Software-Developers-Working/...
  • dochtman 11y ago
    I liked Michael Lopp's (also known as Rands, from Rands in Repose) book, Managing Humans, when I first became a team lead 18 months ago. http://www.amazon.com/Managing-Humans-Humorous-Software-Engineering/dp/1430243147/ref=sr_1_1?s=books&ie=UTF8&qid=1444939385&sr=1-1&keywords=michael+lopp http://www.amazon.com/Managing-Humans-Humorous-Software-Engi...
• NoNotTheDuo 11y ago
  I'm sure you will get plenty of good advice. My own (limited) experience is that your job is going from a "Individual Contributor" to a "Team Lead". This requires a pretty drastic change in thinking and is not something to overlook, or else things will not end up well. This means that there is going to be a lot of work - much more than you can do by yourself - that's why you have a team to support you. The primary thing I struggled with in the past was delegation. Learning to trust (but verify) your team to complete tasks the way they should be done. I think a lot of people struggle with this and is a primary reason for not doing well in a new role. Some other quick things that come to mind are: - Don't be a gatekeeper of information. If you learn something that would be a benefit to the team, make sure they know it and don't have to go through you to get it. That is - get the team involved. - Do take a Crucial Conversations course. You will inevitably have to deal with conflict within the team and knowing how to approach the situation will help significantly. - Do have 1-on-1's with your team on a regular basis. You determine how often, but it should be regular and should be a priority for both of you. This is where you will learn about conflicts within the team, about their career path and aspirations, about personal issues that they are dealing with, and will help build trust between the two of you. Good luck! It's a fun role and comes with it's own challenges, but can be very rewarding!
  • pan69 11y ago
    > The primary thing I struggled with in the past was delegation. Learning to trust (but verify) your team to complete tasks the way they should be done. I would like to add that the above is only possible if you "plan" the work. If you have expectations of how a certain task should be accomplished then you should be able to define the task on a detailed enough level so that you "can" delegate it and that the team member working on it actually has the ability to complete the task according to your expectations. There is nothing worse for a team member to be given some vague idea of what should be done to then afterwards having a big discussion on the expectations, i.e. how to be a mind reader.
• CraigJPerry 11y ago
  http://katemats.com/ http://katemats.com/
• austinsharp 11y ago
  Regarding people skills, I always recommend Peopleware[1]. [1] http://www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113/ http://www.amazon.com/Peopleware-Productive-Projects-Teams-3...
• deleted 11y ago
  [deleted]
• brandonb 11y ago
  I always recommend the book "Leading Snowflakes" for new technical leads or engineering managers: http://leadingsnowflakes.com It gives very concrete advice, and it explains the people side in terms of skills that may already be familiar to you as an engineer -- for example, to "code review" your management decisions with your teammates. I'm also a big fan of this video on Autonomy without Chaos, by David Singleton. David is one of the best engineering managers I've worked with, and really exemplifies a style of management that's focused on empowering your team from the bottom up: https://www.youtube.com/watch?v=RKgZmHhSD9I https://www.youtube.com/watch?v=RKgZmHhSD9I
  • pc86 11y ago
    It's always interesting to come across a book relevant to me and find that it's basically a step-by-step implementation of Nathan Barry's "Authority" guide to writing a book (I mean that in a positive way, the site is very well made).
• Rabidgremlin 11y ago
  Have a read of these essays http://97things.oreilly.com/wiki/index.php/97_Things_Every_Software_Architect_Should_Know_-_The_Book http://97things.oreilly.com/wiki/index.php/97_Things_Every_S... Basically you want to become a "Force Multiplier" for your team, thinking a few steps ahead, seeing the big picture, guiding everyone past upcoming road blocks, you need to be able to mentor/help out when it its the fan. And of course you still need to code ;) A hard job but endlessly fun
• devonkim 11y ago
  I've been a team lead for less than a year but it feels somewhat natural for me since I've handled leadership roles informally on projects in the past. The hardest thing is having to delegate when a fire's going on that you know how to fix but you have to stop trying to uh... "do work" If you embrace that you're expected to be a force multiplier for the team, you have the right mentality. But being sensitive to what role you need to play is critical. Sometimes you need to be a tie-breaker on a heated argument on a framework decision (lead by wisdom / deference to your respected authority), perhaps people are in despair and they just need someone that puts everyone at ease that something's being done right and you should just step in and write a reference implementation (lead by example). One thing I would add is that you should find out if there's a program / product manager present and ask to interview with that person if you haven't. If there's no such role, you will have to pull triple duty as a product / program manager potentially by making a lot of strategic decisions probably. At that level, you might as well be considered a CTO though rather than a technical middle manager basically.
• philk10 11y ago
  Book: Becoming a Technical Leader by Jerry Weinberg is a good read and one that I re-read often - https://leanpub.com/becomingatechnicalleader https://leanpub.com/becomingatechnicalleader
• rikkus 11y ago
  You will have people who depend on you to allow them to get on with what they do best. You will likely find that you don't write code any more, but have to trust others to do a good job - a better job than you might have done, even. You may not have the time to understand everything they produce. Even so you need to be able to understand the system at a higher level. As you say, you have some architectural responsibility. This can seem like a large weight on your shoulders if you think that it is all your job. Remember that your developers probably have a huge amount of understanding of the codebase: Don't be afraid to let them guide you, at least partially, in making improvements. There may be others at a similar level who have moved elsewhere in the company who can give you what their plan was for making things better... They might have been where you are but without your remit. It can be a role where you get to build stuff (with the hands of others), have some power and weight behind decison making, also ever-varied and even fun. It can also be stressful and extremely taxing. Good luck!
• bloat 11y ago
  This fellow writes some good articles on the subject and will send them via a mailing list once a week: http://marcusblankenship.com/list/ http://marcusblankenship.com/list/
• randcraw 11y ago
  What's a good source on becoming a software dev lead? Here are a few suggestions among the many available: Brooks' "The Mythical Man Month" is a classic in this space, though I think its emphasis is less on leadership than the difficulties in software project management. And the book is rather dated now. DeMarco and Lister's "Peopleware: Productive Projects and Teams" is also a classic, and emphasizes interpersonal team dynamics as well as software project management. Hunt and Thomas's "The Pragmatic Programmer" is highly regarded and traces the progression of a software pro from being led to becoming leader. Mantle's "Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams" looks intriguing, but I have no firsthand experience with it. I know agile is a big deal these days, but I can't recommend any books that are specific to doing it well. I'm not really a fan. But in this space, you might take a look at Rich Sheridan's: "Joy Inc: How We Built a Workplace People Love". He runs a small creative agile contracting shop that employs a variety of techniques build and maintain a positive workplace. In a similar vein is Weinzweig's "A Lapsed Anarchist's Approach to Being a Better Leader". He's the founder of Zingerman's Deli (in Ann Arbor MI) and is a very creative force toward making your workplace constructive and engaging. Not related to software, but full of good ideas. Weinberg's "Becoming a Technical Leader: An Organic Problem-Solving Approach" is an oldie but goodie in this space, though it doesn't focus on software but tech of all kinds. Finally, I heartily recommend "Code Complete" as an excellent source on how to program solid/maintainable code, especially if you hope to lead more by example than command.
  • samelawrence 11y ago
    Amazon links for the lazy: "The Mythical Man Month" - http://amzn.com/0201835959 http://amzn.com/0201835959 "Peopleware: Productive Projects and Team" - http://amzn.com/0321934113 http://amzn.com/0321934113 "The Pragmatic Programmer" - http://amzn.com/020161622X http://amzn.com/020161622X "Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams" - http://amzn.com/032182203X http://amzn.com/032182203X "Joy Inc: How We Built a Workplace People Love" - http://amzn.com/1591845874 http://amzn.com/1591845874 "A Lapsed Anarchist's Approach to Being a Better Leader" - http://amzn.com/0964895692 http://amzn.com/0964895692 "Becoming a Technical Leader: An Organic Problem-Solving Approach" - http://amzn.com/0932633021 http://amzn.com/0932633021 "Code Complete" - http://amzn.com/0735619670 http://amzn.com/0735619670
• pc86 11y ago
  This seems prescient as I will be starting a new job as a tech lead in a week, and I actually considered making the same Ask HN post! Same tech stack, no less, although it's for 2-3 medium-sized projects, not a single large, complex one. Best of luck on your interview.
• stevewilhelm 11y ago
  Being a team lead means you must manage in three directions: a) manage the expectations of your boss and shield your team from distractions and firefights, b) manage collaboration and dependencies with other other teams, and c) manage the day to day work of your team.
• ABS 11y ago
  I also recommend Patrick Kua's 'Talking with Tech Leads' book: http://blog.fogcreek.com/becoming-a-tech-lead-interview-with-pat-kua/ http://blog.fogcreek.com/becoming-a-tech-lead-interview-with... There is also this interview with him here: http://blog.fogcreek.com/becoming-a-tech-lead-interview-with-pat-kua/ http://blog.fogcreek.com/becoming-a-tech-lead-interview-with...
• tootie 11y ago
  Some excellent advice here already, but I'll add a few more. One is to avoid putting development tasks on your own plate that you won't be able to complete. Your time is now likely to be taxed at 50% or more meaning you'll have a lot of demands on your time for meetings and such and so you'll find dev tasks can pile up. Just take on less work for yourself and delegate. The other one is learning how to wield your authority. You'll now (hopefully) be invited to or least have visibility into leadership meetings, design reviews, contract reviews, road mapping. Make sure you voice opinions in terms of much time tasks will take, which people are needed, what is feasible/infeasible, if you're signing up for a mission impossible. Stop saying things are "hard" or "easy" and instead identify "risks". Notice that almost nobody in this thread is telling you to work on your technical skills :)
• joshdick 11y ago
  I really enjoyed "Notes to a Software Team Leader: Growing Self Organizing Teams." The second half of the book is advice from various tech leads.
  • c0achmcguirk 11y ago
    I can't recommend this book highly enough. This is the best book on tech leadership I've come across and I've read a lot of them. It underscores the importance of NOT trying to solve problems for your team. Instead, help your team learn to solve problems on their own--so you don't become a bottleneck to getting things done.
• marcuscreo 11y ago
  Great question! I just wrote an article on this very topic here... https://www.linkedin.com/pulse/real-work-management-marcus-blankenship?trk=pulse_spock-articles https://www.linkedin.com/pulse/real-work-management-marcus-b... If you're looking for books, I recommend Johanna Rothman's "Behind Closed Doors" as a great book about leading software teams. Good luck!
• leothekim 11y ago
  A colleague of mine wrote a useful post on this: https://medium.com/swlh/good-tech-lead-bad-tech-lead-948b2b806d86 https://medium.com/swlh/good-tech-lead-bad-tech-lead-948b2b8...
• choult 11y ago
  There's plenty of great advice already in the comments, but mine is quite simple, and quite relevatory when I made the transition to Lead: Measure your success by your team's productivity and not your own.
• charkubi 11y ago
  http://www.engineeringandcareering.co.uk/p/the-well-rounded-technical-lead.html?m=1 http://www.engineeringandcareering.co.uk/p/the-well-rounded-...
• locopati 11y ago
  Learn to listen. To your team members. To your peers. To your boss(es). To people in other departments. Not just to their words, but their body language, their activities, the way they carry themselves in meetings. I am constantly learning from the people around me how I can be a better manager. If I see something that catches my attention about the way someone handles something, I aim to bring that into my own toolkit.
• scottndecker 11y ago
  Lessons I learned as Tech Lead: http://scottndecker.com/blog/2015/04/04/Tech-Lead-Lessons-Learned/ http://scottndecker.com/blog/2015/04/04/Tech-Lead-Lessons-Le...
• wpeterson 11y ago
  As a tech lead, you're a mixture of manager and lead engineer. As a manager, you should be clear to represent your team in public in terms of giving everyone credit for success and taking personal responsibility for failure yourself. As a manager, you need to balance what technical work you assign yourself - it should be a mixture of interesting projects and valuable scutwork. Don't be the guy who takes all the good work for himself and only delegates work no one wants. As a lead engineer, the most valuable thing you can do for your team is to focus on helping them start things and finish things. Folks do well in the middle between those two, but most of the wasted time and frustration comes from not knowing how to begin working productively on things or getting lost and not knowing how to wrap them up successfully. As an architect, be able to quickly change altitude when explaining the behavior of the system or code that you're responsible for. When debugging an issue with a developer, be able to dive deep into the technical details. When explaining a schedule or cost estimate, be able to talk about the system at a high level to the CEO.
• mopoke 11y ago
  I get asked this a fair bit so I started to collect a few of my favourite links together in a blog post: http://www.andykelk.net/leadership/the-big-list-of-management-and-leadership-resources http://www.andykelk.net/leadership/the-big-list-of-managemen... Specifically to new tech lead roles, I'd recommend "Peopleware" and "Behind Closed Doors" And a couple of articles specific to your situation: http://firstround.com/review/this-90-day-plan-turns-engineers-into-remarkable-managers/ http://firstround.com/review/this-90-day-plan-turns-engineer... and https://blog.stackexchange.com/2015/08/developer-turned-manager/ https://blog.stackexchange.com/2015/08/developer-turned-mana...
  • Evgeny 11y ago
    Thanks, added your blog post to favorites. I lived in Melbourne for 12 years, still consider Australia my home.
• a3voices 11y ago
  Just try not to get fired.
  • dasil003 11y ago
    Come on guys, I know we don't generally appreciate humor here, but this is pretty fucking funny.
• dclowd9901 11y ago
  A good tech lead in my mind is someone with a strong technical vision who has the backbone to see their vision through, but is also very adept at ironing out the myriad issues that fracture teams. It means being an advocate for the best technical solution but compromising with the other teams in the org to meet their needs. It also means being very unpopular as a good technical lead will give commandments from on high even when they're not popular or well liked opinions. Basically your job will be reducing friction by pissing everyone off. So it's even worse than "if you've done it right, no one will know."
  • mopoke 11y ago
    In my experience, a good technical lead won't give commandments from on high. A good technical lead will consult and facilitate a discussion and mediate conflict. They will also be directive when the time is right, but only after having listened and weighed the arguments. They will also be able to explain the rationale behind those decisions.
    • dclowd9901 11y ago
      I've had your tech lead. They're a weenie and nobody ever congeals around initiatives because they have endless meetings to debate everything all the time. Sometimes you just need to say, "do it this way or find another job." I know that's not a popular idea around the democratized millennial coddling of Silicon Valley, but honestly I'd rather have someone throw down the gavel than sit through another month of research findings meetings before we finally decide git is better than svn. Your person isn't a lead, they're a diplomat.
      • angersock 11y ago
        democratized millennial coddling of Silicon Valley What does this even mean? I'm sorry that you felt your time was wasted in meetings, but you seem to ignore the equally bad outcome of blindly chasing a direction and pissing off all the devs who actually had some foresight.
• grandalf 11y ago
  There is some great advice in this thread. One thing that I've learned is that different organizations have very different cultures and ways of viewing technology (and thus technology leadership). Some are more deadline oriented, some are more bug/problem oriented, and some are more product oriented, and others care a lot about the price per head of engineers and would prefer to outsource everything to the third world if they could ever manage it. A small number of companies care about open source contribution, attracting top talent, and innovating. So whoever is hiring you probably has a very clear idea of what they want from the tech lead, so considering that the goals can be very different, you might want to ask this question. In my opinion, it won't seem like a naive question to ask because there are so many facets to people and technology leadership.
• methodover 11y ago
  OP, I'm sort of curious why they're hiring a tech lead from the outside. Why hasn't someone taken that position from within the organization? Someone who's worked on the project, who understands it, who has the moral and political authority to lead? I worry that your task will be really, really tough. If you can, in the interview, try and understand the situation over there. Why do they need an outside lead?
  • herge 11y ago
    Maybe they are hitting problems that nobody on the current team can solve. Or they need new ideas and new blood. Experience is often very useful.
  • Vraxx 11y ago
    Hmm.. I didn't necessarily read it as they were hiring from outside necessarily.. I'm sure it's not uncommon to have interviews internally even if all of the potential candidates are already employees.
    • davnicwil 11y ago
      > I'm sure it's not uncommon to have interviews internally In fact depending on location it may be legally required - I'm fairly sure this is the case in the UK (in addition to having to advertise the opening externally too, even if there's absolutely no intention of hiring anyone external) - please someone correct me if this is wrong. Probably the sort of thing early-stage startups can get away with not doing because they're very under the radar, but it's certainly happened at mid-sized companies I've worked at.
  • Evgeny 11y ago
    Thanks, that is a good question to ask in the interview. I will. One of the reasons may be that I have experience in the particular field, and also worked for a competitor in my previous position a few years ago.
• 4lejandrito 11y ago
  I would suggest to always put yourself in the shoes of the developers when you make decisions as a leader. Think about what you would have thought as a dev. Also try always to explain why you make the decisions you make. I am a dev and I hate when decisions are made without telling/explaining team members. I also appreciate a lot when I receive feedback, good or bad.
• 7402 11y ago
  Here are three rules I've followed: 1) If there's an exciting fun task and a messy unpleasant task, assign the fun task to someone else and do the unpleasant task yourself. 2) If someone on your team wants to ask you a question, always make yourself available and absolutely pretend that you don't mind being interrupted. But if you need to ask someone on your team a question, always ask first if it is a good time for them to talk and offer to come back later if they are in the middle of something. 3) If someone wants to try an approach that you think is wrong, say: "I'm not sure that's the right approach, because of X, Y, and Z. However, I've been wrong before, so I might be wrong about this, too. How long will it take you to research this approach and see if it works out?" If you're working on a tight schedule, this may not be practical, but if you want to develop good engineers in the long run, this can be beneficial for everyone.
  • spenczar5 11y ago
    How do you avoid burnout when you're being so self-sacrificial? Seems like it'd be a big risk.
    • LukeB_UK 11y ago
      You lower your expected output.
    • 7402 11y ago
      Your satisfaction changes from being happy that you've polished some nice bit of code to being happy that you've shipped a product and successfully run a group, and gained the admiration of the people on your team and in your company. Competence is it's own reward. I learned those rules from observing the behavior of group leaders I've worked with/for. There have been a few times (over many years) when I've thought to myself, "My boss is fantastic! I am so amazingly lucky to be working for this person!!" When that happens, I've asked myself, how does he/she do it? And tried to figure out the answer.
      • sliverstorm 11y ago
        There also appears to be satisfaction in cultivating new talent and watching it grow. A friend of mine is at his most excited and animated when he is talking about the new ways his reports have grown as engineers, not when he's talking about this or that technology.
• mirceal 11y ago
  also worth reading: http://www.amazon.com/Driving-Technical-Change-Terrence-Ryan/dp/1934356603 http://www.amazon.com/Driving-Technical-Change-Terrence-Ryan...
• LukeB_UK 11y ago
  One thing that I've not seen mentioned is that you don't have to feel like you're the one that has to answer all the questions, just because you're the lead. Deferring questions to those you feel may have more specific knowledge shows that you know where your weaker areas are and where the strengths of your team are. This also goes for asking your team questions, don't be afraid to ask them things you feel unsure on rather than try and power through.
• digital_ins 11y ago
  At the core of it - you're going to be leading engineers. A lot of how this leading happens depending on the organizational makeup of the firm you're going to. (This is super super important!!!). So figure out the organizational culture before you join. Understanding this helps you understand the confines within which you will operate (for the first couple of months, atleast). If you're replacing someone, understand how they worked, what gaps were there in that person's performance and how you could cover those. If you're the first tech lead, then figure out what problems they're having that necessitated the creation of the tech lead position.
• rickette 11y ago
  Checkout https://leanpub.com/becomingatechnicalleader https://leanpub.com/becomingatechnicalleader
• frankus 11y ago
  I've found this a really good discussion of how tech leads' responsibilities differ from front-line developers: http://madeofmetaphors.com/shapes http://madeofmetaphors.com/shapes
• brandall10 11y ago
  Many times a tech lead isn't about being the smartest or most knowledgable person in the room - it's about getting your team, your boss, other departments on board with a plan and executing. In some environments it may be that you have to be the sharpest depending on the team you're given, but often times it's best to be the most judicious and compassionate. Think of it more like being a mini-manager - perhaps 30% management (where you're like an extension of your supervisor) and 70% software. Also be prepared to bring your boss into issues you may have with external teams/organizations, but try to shield your team itself from that activity. Be prepared to handle considerably more email, process work, signing of documents, etc. I'm going to share a personal story - it might not have much directly actionable advice, but it may give you some thought on how to approach this strategically. I spent about 15 years as well on windows software for enterprise health care systems (starting back in VS6 C++ days back in the late 90s) before jumping ship to do Rails development a few years ago. Right around the 10 year mark in my career I was a run of the mill sr. dev... the only 'lead' experience was on a couple projects, rarely with more than another dev and most of the time solo. I just never really had much confidence in my skill set as a whole, esp. when it came to telling other devs what to do. In 2009 as a 33 year old I felt pretty deflated and was considering a career change. One thing I caught wind of was this book called "The Passionate Programmer" by Chad Fowler (not related to Martin). It was ~200 pages, and it was separated out into 50 or so little chapters of tidbits of mostly, well, soft skills, but also general career advice. I absolutely loved it and finished it in an evening. In short order a whole bunch of things about my working style changed, not only my demeanor working with other engineers, but key key people in other departments in the projects I worked on(ie. QA, System Engineer, Documentation, Product, Project Management). Ultimately I realized at that particular organization the biggest problem was that departments were silo'ed a bit too much, and as a result schedules slipped because coordinating resources was always a challenge. Six months after reading the book I was given a lead role on a medium sized project at that company (had 6 engineers on the team and about 20 people working on it for 9 months, ~$15M per annum, 300k LOC over the prior 10 years). One of the engineers who reported to me during on that project was one of the 2 Fellow Engineers at the company (3 titles above mine!). It went well, and my next review had a recommendation from my supervisor to go into management. I politely declined and a few months later was promoted to a principal dev. One of the reasons why I believe this worked so well was 1) I did underestimate my skills as a whole - I was not the best, but I was certainly good enough that my suggestions held weight and I felt ok with admitting to things I didn't know and delegating 2) I had, as you say, seen other people in this position and already knew what success and failure looked like. I wasn't just given a position as a lead, I had assumed it to some degree on another project I was on at the time (not entirely and not to usurp the authority of the actual lead, but I just became helpful on things that needed to be done but were getting brushed aside, esp. things that were important to other departments). And as such, people started to pay attention to what I was saying. It sounds like you think it's slated toward being an architect. It can be, but many times it really isn't - you may want to delegate that overall to the stronger members of your team and help them work through the process - be the person who asks questions and helps poke holes. Give the most challenging work to your brightest people. Isolate the more 'dangerous' members from mission critical stuff, and if they have the passion and smarts but they're just a bit misguided give them a nudge of encouragement in the right direction and challenge them accordingly. Pay attention to your devs' key strengths and delegate accordingly, but also remember to provide a degree of work that is challenging and exciting. So that's my advice - check out that book. It's a quick read. It is about 6 years old now but the advice is mostly generic. Try to put some of it to effect in your current job... assume the role where you can. Even if it's just a week or so, I think the best practice is actually trying it out in real life.
• samstave 11y ago
  You need to read this... http://www.altisinc.com/resources/rules/ http://www.altisinc.com/resources/rules/
• erlich 11y ago
  I think it can be summed up as "code less". I want to stress that this is much more easily said than done. - A lot of programmers gain immense satisfaction from writing nice code, and getting into "flow". There will be less of this, and you have to rewire your reward system and vicariously experience this through your team. If you already get more satisfaction from shipping and having users use your product/module/apis rather than how elegant your code or apis are, then you are heading in the right direction. An earlier comment on this page sums up the goal: > Your satisfaction changes from being happy that you've polished some nice bit of code to being happy that you've shipped a product and successfully run a group, and gained the admiration of the people on your team and in your company. Competence is it's own reward. - You must prepare yourself to watch others implement things you would love to do yourself, in a less-optimal, and less-clean way than you might have. Its harder if the codebase is your baby that you wrote from scatch. Instead of coming out of a project with new skills, new familiarity with modules, code that you could open-source, satisfaction from having written nice modular, maintainable and testable code, you will only have the satisfaction of the hitting a deadline. - Coding less allows more time for you to ask your team what they need, think about what they need but don't realize, and get that for them. - Giving feedback is an art. You want to keep a positive, upbeat repore with your colleagues. If you empathize too much about how the developer will feel when you deliver criticism you will end up doing it less and not being as honest. Finding the right words will make it easier for yourself to deliver, and will create less tension. - Hiring people like yourself who write code similar to you will make life much easier - but often you have to money-ball your team, and make do with what you have. - Creating an atmosphere where employees can all talk about problems, and personal mistakes, without feeling judged by their peers is important. Encourage everyone to acknowledge their failings, and identify improvements. "What did everyone learn this week/sprint? What could you do better?". As soon as employee holds back, everyone will start because they will fear they are underperforming. If someone is falling behind, others in the team should be thinking how they can assist their colleague, rather than looking at it as an opportunity to stand out. Standups are great for this. Make sure its not only one person asking for help at the standup.
• skapadia 11y ago
  In addition to everything already said, I reemphasize: - allow your team to focus - provide just enough structure (and no more) - help shorten feedback loops - try to remove hurdles to acquiring information Deep focus unleashes creativity, passion, and great work. I know that's when I'm the happiest.
• mtabini 11y ago
  In no particular order: 1. Listen before you speak. The people you manage are prone to giving your opinion more weight than it deserves. 2. Give your subordinates problems, not solutions. People like to own a task, not to be told what to do; treating them like adults and professionals empowers them and brings out their potential. Besides, if one person only ever makes all the decisions, no decision can be better than that one person's knowledge. If you're afraid of delegation, institute a tight review loop to ensure that people don't go off-track. 3. You're a facilitator, not a doer. People will come to you with their problems, and you must be available at all times to help them through it. As someone else has pointed out, your productivity is secondary to that of the team. It's your job, among other things, to ensure that your team has a good working environment, including good tools, practices, and access to uninterrupted “flow” time. 4. Be aware of politics. The moment you manage a team, politics become a part of your daily job. This is not a bad thing—“politics” just means managing interpersonal relations; it becomes a bad thing when you ignore it. 5. Never be in a position to take. Success belongs to your teammates; failure is all yours. 6. Face problems head-on. People don't like confrontation, and let problems fester until it's too late to fix them. Instead, provide frequent one-on-one time with all your teammates, exhort them to confide in you, and show them that you're trustworthy. Also see #1. 7. Offer clarity. Explain what you expect others to do in a measurable way to make it possible for both you and your team to understand how well everyone is doing. You can use a method like OKR[0] to track your goals internally. [0] https://en.wikipedia.org/wiki/OKR https://en.wikipedia.org/wiki/OKR
• edw519 11y ago
  Technology 1. Know your apps. 2. Understand your domain. 3. Understand your technology under the hood. 4. Have an idea of how you'd approach each project. 5. Write detailed technical specs for juniors. 6. Write general technical specs for seniors. People 1. Be nice. 2. Understand you are a resource provider, not a boss. 3. Get shit done. 4. Ditch team building gimmicks (see #3 for what's important). 5. Listen! 6. Share. Share. Share. 7. Teach. Teach. Teach. 8. When you need a bad guy/gal, you're it. 9. When you need a good guy/gal, your people are it. 10. Know how to run a project as needed. 11. Know how to run a meeting as needed. 12. Don't be bashful. 13. Don't be (too) stubborn. 14. Stand your ground with users/bosses. 15. Have fun & foster an environment for others to too. 16. Always do the right thing. 17. Never stop being a programmer. 18. Never stop loving building stuff.
  • hanswang2013 11y ago
    I would like to work for a leader like that. In that way, I would rather stay there as savy engineer for as long as it holds. What impresses me the most are, 8. When you need a bad guy/gal, you're it. 9. When you need a good guy/gal, your people are it. It is natural for good leader to think for engineers. But also thinking in the position of users/productivities wise is important.
  • robryk 11y ago
    These seem to be terribly vague, e.g.: 16. Always do the right thing. Some of these I either misunderstand or contradict each other, e.g.: 1. Be nice. 8. When you need a bad guy/gal, you're it.
    • jpatokal 11y ago
      I think 8 means that if you need to find someone to blame, you're it. (Whereas 9 means that the praise goes to your team, not you.)
    • vincentkriek 11y ago
      I think number 8 (& nine, because they are heavily related) mean that when higher ups want to blame someone, they should blame you as technical lead (and not individual team members) but when someone needs/is going to be praised make sure it's the team member that deserves it (and not you!). I heavily agree with this.
• moron4hire 11y ago
  1) Solicit ideas from everyone. Admit when you don't know the best way. Attempt to achieve consensus. But be steadfast in the face of majority opposition when you're sure you do know better. 2) Insist on always doing the right thing. Never compromise your standards or your ethics [0]. You set the example for everyone else. 3) Treat your customer like an honored guest in your home. Bend over backwards to understand them. But never let them anywhere near your developers. It's not good for anyone, especially the customer. 4) Always take the heat for your team (which is easier if you're the single point of contact for the customer). Always spread credit around. 5) Don't get personally involved with your team [1]. You might have to fire one of them one day. And your praise will mean more. You can socialize with the whole team on occasion, but don't do anything that could ever allow the appearance of favoritism to develop. 6) Trust people to do their work. Give them a chance to succeed... or fail. But the few that repeatedly and consistently fail to live up to expectations or even improve, get rid of. [0] If anyone ever tells you "we might as well do this unethical thing, because the customer will just get someone else to do it," your reply should be, "well then, it doesn't have to be me" and walk away. I have done it twice now and have regretted neither time. [1] I would like to think this goes without saying, but NEVER EVER EVER make sexual or romantic advances towards anyone under you. It is extremely unethical. If there is any chance of something happening, wait until you're no longer on the same team. Best to wait for them to make the first move, too, if you're still at a higher authority level after the team change.
• yareally 11y ago
  1) Learn as much about the people on your team as you can. That can be sometimes hard while at work, so I end up going out to lunch with them or occasionally grab a beer afterwards. 2) While at lunch or after work, my team and I end up talking about random stuff, but it pays off when you can sense if someone is having a bad day/week or is stuck on a particular issue. Also helps to build mutual trust with your team and keeps the communication lines more open. 3) It's hard to sometimes tell how well you're doing as a technical lead, but one way I do it is by how often people come to me for help to things that can't easily be Googled. If developers are seeking out your help, they trust you and consider you reliable source of help. 4) If it comes down to doing more work or helping your team. Always pick your team. Helping them will likely be more productive overall than any amount of additional work you take on yourself. 5) Every developer is different. Recognize that when communicating with them and approach each differently. A true tech lead isn't a managing position, it's a mentoring/leadership role while still being a developer. 6) Be concise. Your team needs help, but they have work to do. Save the long explanations for later. That doesn't mean you should avoid the "why" in your responses, just don't make your answers a monologue. 7) If asked by a team member why you think a particular approach or solution is correct, give them an explanation. I always feel if I can't explain a particular subject, then I don't really know it that well and may be incorrect. 8) You don't always have to be correct. Admitting you aren't when you can't explain something reflects better than all other responses you could give your team. 9) Making yourself available to your team for assistance is also a must as already mentioned. Everyone communicates differently, so adjust to your team as much as possible. 10) Don't deter someone outright from pursuing a potential solution, even if you're pretty certain it won't work. Instead saying no, apply some rubber duck debugging[1] and talk them through their idea aloud. If all goes well, they'll either realize it's not feasible and learn the value of communication or they'll convince you that it will likely work. If they win me over, I'll try to help them devise a way to small way to test their idea further. [1] https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
• Jackrabbit1981 11y ago
  As a tech lead your job is to support the developers in your team so they are as effective as possible. This means: 1. You must know the code. Say 'no' to meetings - spend most your time coding 2. Be honest - When you know the answer say so even if that means someone will have to redo a lot of work. If you don't know the answer, say so (there's no point pretending to be cleverer than you are - you got the job so you deserve it, never try to prove your abilities to others) 3. Remember your job is to support others so fight for your team's interests even (especially) when unpopular higher up. 4. Lead by example - take the shit jobs and write awesome code. 5. Let your team members review your code AND TAKE THEIR ADVICE! 6. When team members ask you questions attack their problems with the same determination as you would attack your own 7. To inspire your team members you need to be loyal to them. 8. To inspire your team members you need to be loyal to the business (often forgotten) 9. '7' is more important than '8' 10. Be the best developer you can be (note the word 'be' not 'appear to be') Ultimately, if your team regularly invite you for beers after work and your boss respects you then you are doing ok. Never, ever assume that 'team lead' is anything more than a specialist role within the team. Your job is to support others. That does not make you more special or important. Respect is earned not given. Being a good team lead is much the same as being a good developer. If you find the job hard then you weren't really a good developer. This is why a lot of companies don't externally recruit tech leads, preferring to recruit from within.
• tlinton 11y ago
  A great technical lead is a great therapist. They're kind, supportive and know how to focus your energy to help get a really difficult task done. They don't dictate, they don't prescribe, they listen. Your job as a tech lead is to listen and help figure out a way to make testing, compiling, deployment, support, and escalation easier.
• scardine 11y ago
  Do you have a few kittens? Managing developers is like herding cats. The truth is you don't really have real control.
• eitally 11y ago
  After you get the job, here's something my old team learned through experience (failure): modular is good, but in practice, abstracting things to the theoretical max results is software that none of the developers understand, is impossible to maintain, and probably doesn't perform any better than if you didn't "optimize" near as much. (Source: I was a programmer, then a tech lead, then moved into managing about 100 of them.) Another tip: it's your job to help the programmers make you look good. You do that by making them look good. It should be a virtuous cycle.
• royosherove 11y ago
  http://5whys.com http://5whys.com - I'd recommend a lot of the advice there (I'm the owner of that blog so I'm a bit biased). http://teamleaderbook.com http://teamleaderbook.com is a book that I wrote for software team leaders
  • Evgeny 11y ago
    Well, that's too amazing to be true - as part of my preparation I started reading "The Art of Unit Testing" just a couple days ago (not that I did not write tests before, but got a suggestion that the book will help me better understand dependency injection, inversion of control etc.)
    • royosherove 11y ago
      heh! It's a small world!
• thecourier 11y ago
  You can get a summary of this discussion here: http://sevcode.tumblr.com/post/131264031520/the-30-laws-of-software-management http://sevcode.tumblr.com/post/131264031520/the-30-laws-of-s...
• flashman 11y ago
  Read this set of articles: "Things I wish I was told when I became a manager" http://fractio.nl/management/ http://fractio.nl/management/
• dpweb 11y ago
  On management, it's tough to find good info - some is trite leaderhip strategies. I tend to favor the order writings cause they've stood the test of time. I keep this one saved and re-read it pretty regularly. http://philip.greenspun.com/ancient-history/managing-software-engineers http://philip.greenspun.com/ancient-history/managing-softwar... My team is remote, a couple of us been together 10 years and most of us at least 5 years. My managing style I picked up from my mgrs in the company. Pretty hands off. Stars are stars and don't need me meddling - so the general style - let them do their thing. As far as the average or underperforming employee, I view my job not as trying to "improve people". I need to empower people. As a leader you have some influence on your team, but I think that's a bit overblown. A person's performance is really a result of their mindset. Their IQ as well. That's important, but some people are just motivated for excellence, others not. I think the key is - understanding where you have opportunities to influence this in your team members' and when not. One thing I did notice - moving to a mgmt position. It is very temptimg the idea to just get rid of them. It's tough but easier then getting someone truly hopeless to make the necessary effort to improve.
• arnonejoe 11y ago
  I just took a technical lead role with a bay area SAAS company. It's been a difficult adjustment having worked on contract where all I did was write code. Now, I sit in a lot of meetings, do code merges, interview/hire developers and worry about blockers on two Jira boards. Here are a few things you might want to try; If their branching strategy is screwed up, help them fix it. You are going in to a .net shop and there is a good chance they have TFS. There is the ALM Rangers branching guidelines you can refer to. Hold a brown bag and show the team how to write unit tests. Many of the junior developers on the team probably do not understand how to write tests. Hold a team code reviews. Initiate common architectural components like a logging or instrumentation framework. Take on tiny bites of technical debt. Push to get your team re-sharper licenses.
• SonicSoul 11y ago
  all of these lists sound nice and all, but think back to the people that you really respect that have taught and influenced you to become who you are today. what was the most important part? for me it was the person who was many degrees smarter than the rest of the team and pushed everyone to be their best. In my case he was not the most diplomatic or encouraging, hell he yelled at me a few times (and trust me, i don't appreciate being yelled at even by my parents). but anyone who was interested in software engineering was in awe of his skill. He devoured tech books and prototyped things on the train to work so that he always had good ideas and answers. I was sold right from the interview where I could tell he just knew his stuff inside and out. My point is that having the necessary knowledge to actually teach people is so much more important than all those other things. For most of us that means a lot of hard work in the trenches during free time. New technology? there goes Saturday and Sunday. It's the only way to have all the answers to the ones above you, and the ones you're leading. Additionally try to get your team the best development/infrastructure tools money can buy and the best learning resources (such as pluralsight, egghead.io, all-you-can-read online books subscription)
• endymi0n 11y ago
  Some gems from when I asked something similar 4 years ago... https://news.ycombinator.com/item?id=3407643 https://news.ycombinator.com/item?id=3407643
  • dasil003 11y ago
    Nice link. How have the last four years gone for you?
  • Evgeny 11y ago
    Sweet. Honestly, I did a search - must have used wrong keywords. More reading for me. Thanks!
• lifeisstillgood 11y ago
  Candour, honesty and therapy. And enforce ridiculously high standards. Most of us are not as good as we say/imply we are. All of us are terrified that someone will find out, and terrified that we will slip. So there is often a refusal to say "I don't know" or a refusal to accept that we might need to slow down and think about the work we are doing Your best bet is to make a team that is willing to try something that will make them look like they don't know what they are doing, send off signals to "management" that are opposite of what all the other teams are sending. (This is the other point about a tech lead - you will be compared to the other tech leads - if they are hiding their faults, you will look bad by comparison as will your team - how you persuade management this is not the case is hard. My best suggestion for that is ridiculously high standards - perfect test coverage, documentation, linting, enforced peer review and more. For every commit. Enforced by scripts not by you.
• hndl 11y ago
  I've been a Tech Lead for a year now. I'm still learning but some of the things I've done which I think will help are: 1. Start by setting up the development environment and getting the software you'll be working on to run locally. Then, fix a couple of easy to medium level bug fixes as soon as possible. This is the fastest way to learn what your team is talking about. 1.5 If you don't understand something that's being said at a meeting ask, but don't hijack the meeting, make a note and talk to someone who can explain in more detail. 2. Think at a high-level -- what is the product supposed to be doing, abstract away -- some engineers will talk in code -- which you may not understand early on but interpret what they're saying at a high-level. 4. Be available and approachable to everyone on the team. 5. Understand the impact of a bug fix or a feature -- how much QA effort does it require, what is the operational impact of the work, does it break backward compatibility etc. 6. Participate in product meetings and consider designing any new features as homework so you can better discuss it with the engineering team you're leading. Good luck! Edit Some DO NOTs: 1. Do not complain how bad the code base is. No one likes someone new walking in and saying that at once. 2. That said, understand what technical debt there is and address it incrementally. Don't say "we should re-write XYZ." 3. Do not suggest alternate platforms and frameworks unless is absolutely makes sense -- this is especially true if the team is big and no one knows this new framework besides you. You need your existing team to contribute to and maintain projects.
• thejerz 11y ago
  - Be flexible - Prioritize everything - Simplify code, processes, and infrastructure at every step - Build a well-rounded, emotionally stable team - Loosely follow scrum & agile - Be realistic - Be honest, even when it is inconvenient - At the tech lead level, the most important skill is your own psychology. Hone your personality, establish work-life balance, and take some courses in positive psych - Have an opinion - Learn when to talk, when not to talk, when to put it in writing, and when not to put it in writing - Adopt a "good enough, and let's move on" design approach - Build strong relationships with non-technical management
• z3t4 11y ago
  You lead the way and when you have half of them with you, the rest will follow.
• qznc 11y ago
  I heard about this model from Michael Church, which I like. The idea is that there are three forces, you need to balance as a manager. 1. Your team. This is obvious. Acknowledge they are humans. You have to worry about them. Try to keep them happy and safe. 2. The Business. This is the cold-hearted inhumane entity which only considers the free market. You need to satisfy that beast, because otherwise everybody loses their jobs. It only wants to squeeze the maximum productivity out of its employees. Often its goal are in direct conflict to your teams goals. 3. The Organization. These are all the other people in the company. Your boss, collegues in other teams, etc. They have their own needs and agendas, usually different to The Business. Do not forget to consider these.
• twicezero 11y ago
  My summary, after many years thinking about it, is: Build technical leadership in depth. What ever you do, what ever the problem. It's a key-person problem unless your team can do it. If you have to tell your team what to do. You are failing, and you need to do something about it. The leader sets the vision, makes as start, demonstrates good and keeps people on track. The coach makes people the great person they want to be. A leader can use simple coach techniques to grow an resilient team who can work to build something great. I've noted down some of my learnings: http://www.engineeringandcareering.co.uk/p/leading-and-guiding-groups.html http://www.engineeringandcareering.co.uk/p/leading-and-guidi...
• twicezero 11y ago
  I guess I should really answer your question though :) I collected some interesting blog posts that I loved and stuck them here http://www.engineeringandcareering.co.uk/2013/07/technical-lead-articles-and-blogs.html http://www.engineeringandcareering.co.uk/2013/07/technical-l... Talking with Tech Leads might interest you also: https://leanpub.com/talking-with-tech-leads https://leanpub.com/talking-with-tech-leads
• acjohnson55 11y ago
  A couple articles I've seen previously on HN on the subject: Things I was unprepared for as a lead developer -- http://dev-human.io/~pascaldevink/things-i-was-unprepared-for http://dev-human.io/~pascaldevink/things-i-was-unprepared-fo... Becoming a Tech Lead – Interview with Pat Kua -- http://blog.fogcreek.com/becoming-a-tech-lead-interview-with-pat-kua/ http://blog.fogcreek.com/becoming-a-tech-lead-interview-with...
• elrikdante 11y ago
  Wow, I can't say I'm surprised at the quality of the answers. I'll add a couple of my own: .) be mindful that different members of the team are on different trajectories skill set wise. (beginner Exs -> juniors -> mids -> seniors -> etc) I like to pair members with technology whose stability is inversely proportional to their experience. More experienced engineers design tighter interfaces in the face of increased variability in final spec. Whereas technology that is older will usually have a good breadth of info either in house or available on Stack Overflow which means the problems (and communally derived solutions to them) are accessible. This I've found results in having to clean up less code overall, which helps build team momentum. Which is my next point. .) Team Momentum You're leading a team, which can be assessed as a set of quantities at any given point in time (viz. velocity in Pivotal Tracker for instance). The team however is a dynamic interplay of business expectations (from the principal, boss, client) technical debt (recurring known issues), and the team strength (which waxes and wanes based on moral, environment, etc). Always look for ways to make the lives of the engineers around you easier. -) build tooling yeoman generators build tools etc. enriching internal tooling makes each engineer more effective, which means it has a compound effect. You can cover a lot of ground just focusing on addressing pain points in your team. ]) One last point actually, you're a leader so remember that means you're expected to have finer grain control over your ego, it helps if you take an objective view towards the technology that comprises your stack rather than a predominantly fanatical view. Congratulations by the way! Regards, Dante Elrik
• Amio 11y ago
  Most of all, make your contribution visible to your leader, or to KPI, or to anything evaluating your contribution. If no one knows your great works, It worth nothing to your career. First, know how they evaluate your works.