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.
I think your advice is great for tech leads at big companies, but for tech leads at startups, I have to disagree with the point about "Work for your product - not your company."
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.
As a tech lead at a midsize company (~300 employees) I have to agree with this. There seems to be a strong tendency among tech teams to always push back on everything that business wants. We need to remember that we’re on the same team.
> If you’re at a startup, your product is your business.
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.
Depends if the product is a key profit center. If your startup is making a product and it's not a profit center, it might get binned, it might get pivoted, it might postponed. The advice is great, just don't die on a shortsighted engineering hill when the decision come from emotional attachment to your work rather than what's best for the companies positioning and financial health. You can always put that love and energy into a new/pivoting of the product.
The problem is if you're at a startup you probably don't know what your product is, because you don't know who your customers are.
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.
If I may function as the devil's advocate - One can read the above as a claim that because you didn't have a good business guy engineers should have worked faster? Would a faster product iteration worked if the business acumen would still have been missing?
It might have. Part of it was arrogance and bad advice from VCs, not lack of business acumen. There was a rejection for industry practice because we were different and doing something different, but it wasn't actually different and couldn't monetize because we focused on users that couldn't pay us real money, while working in an industry that doesn't value innovation.
I don't think the argument is that engineers should work faster. It's that they should be willing to skip some of the stuff you would normally say is good practice in order to ship features super agile and make any necessary pivot easier.
It wasn't a lack of features so much as a lack of talking to people that had purchasing discretion. Never focus on users in B2B, focus on people who have the ability to approve a purchase order.
This isn't universally true. It only applies to a segment of "pioneering" startups. It will hurt a startup otherwise.
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 agree with you that you have to work for the company objectives.
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.
That only works if tech team is evaluated and measured with the same objectives as business teams.
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".
Respectfully disagree on the "write it out first" advice. I'd argue "think it out first" or "talk it out first" is sufficient.
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.
Consider that a successful product will be maintained for years. It is highly likely that a people will come and go.
Documenting already running code will inherently have less priority (both in the eyes of upper management an developers- the temptation to jump on the next project is huge). So if you don't start documenting first- odds are you never will.
I disagree with this. Writing a set of "technical objectives" that say how a thing will work takes an hour at most and it helps you think through it better than a conversation. It also helps you pass information to QA. If someone asks what the thing does, you can just send them the link. Ultimately, taking an hour to write it down pays
dividends later on.
I would like to disagree here. Got into a team which has working prototype but not a single word on document.
Which makes this hard to follow up with prototype.
Being tech lead in current position, I am stressing "document-first" approch it is either for client or tech team.
If you have remote teammates or may have any in the future (i.e. if your company allows remote engineers), a culture of writing things down is imperative.
I like the part about writing things down. There is a lot of mental organization that needs to happen when you write it down. It also forces you to make decisions.. which is also hard.
A related aspect of organization and making decisions is meetings.
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.
Amazon just assumes that nobody will read the prep material and reserves a block of time at the beginning (as long as 90m IME) for silent reading and markup. Seemed to work pretty well.
At my current company (small startup) I wanted to convince people to talk through the issues and write things down or write down at least something. Think of user stories, requirements, personas, product vision, company vision, sprint goals.
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.
Finding a way to show them might be difficult, but rewarding.
(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.
The only time I write anything with a pen and paper now a days, for the most part, is when I do 1:1s and check ins with my team. No computers for me. If I need to schedule something it comes after. The team member gets my full attention, no phones, Slack, email, or anything getting in the way.
This is about as comprehensive as you can get in terms of what really matters in a good tech lead broken down into a few paragraphs. Who needs a book?! :)
I agree with your comment and particularly this part:
> 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.
Don't forget that each member of your team is a unique individual. Just like raising kids, there is not a one size fits all formmula. Get to know each member of your team on a personal level. This will go a long way in building trust and being able to lead them effectively.
As a tech lead, you bother about building the features that the business has identified - and building it in the best way possible, thinking long term about the product. While as a business decision maker, you focus on what your users want - else you will be out of business fairly quickly.
It's definitely a balance. I should have phrased it as "make sure the product satisfies your users needs" rather than their wants. And this isn't to say you should add a thousand features, but I do believe it's important that tech leads goals line up to users, not only to the technical excellence of the code. You can't make good decisions on technical improvements or debt reduction without balancing users needs. It's easy to build a straw man example that is on the extreme end to demonstrate this, so I won't do that. The day-to-day is more nuanced.
If one defines gorgeousness as ease of grok, then gorgeousness directly contributes to the wellbeing of users through maximizing the technology's ability to quickly and effectively adapt to their needs as they arise. Agreed that it's a secondary concern to fulfilling the featureset.
Could definitely be true! I personally have a hard time imagining how code could be pleasing to the eyeballs by any other metric than how easy it is to understand.
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.
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.
Agree. I much prefer the term ‘product engineer’ to all previous titles. It shouldn’t be a cargo-cult switch where everyone starts calling themselves one, but it is by far the best title as a guiding principle to what we are meant to be doing.
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.
If you find yourself teaching your team take a step back.
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.
This does not apply in all circumstances. My jump into tech lead came as the old tech lead (15+ years xp) and young superstar(~4 years with wisdom beyond his years) departed from it.
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
> 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
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?
I'm talking about an ideal to strive for, so of course this is rare.
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 think every organisation has people of different aptitudes, intrinsic motivation and interests. Building a team of superstars is meaningless. It's the management version of "make it better" or "it doesn't work" type feedbacks that don't give any necessary insights to actually do it. Building a team of people technically superior to you? In what way. Does your devops guy need to be an expert in language design?
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.
>I think every organisation has people of different aptitudes, intrinsic motivation and interests. Building a team of superstars is meaningless. It's the management version of "make it better" or "it doesn't work" type feedbacks that don't give any necessary insights to actually do it. Building a team of people technically superior to you? In what way. Does your devops guy need to be an expert in language design?
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.
>Building a team of collaborators with a baseline of technical aptitude and a willingness to learn is what most people should strive for.
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.
That depends on what tech lead role means in OP's context. It might me a team lead, in which case you are right, or something like coding architect which is usually one of the most senior members of the team with additional soft skills. Such person is expected to teach others.
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 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.
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!