You can exhibit leadership and all those things at a much lower job tile.
On a semi-related note: I really dislike job titles. They make people think in labels. The most powerful feature of a team of creators is their idiosyncrasies. The best way I found to build something as a team is to adapt the work to the strengths of the individuals. Job titles squash the peculiar strengths and differences into a label and make organizations treat people as fungible units of work. Too many organizations define the work first and then assign it to the individuals, rather than define the work based on the individuals.
Indeed, an ideal scenario for actually getting work done is when everyone knows each others abilities, and they collectively divide responsibilities (including leadership responsibilities) as peers.
Others have pointed out various reasons for titles, including:
- communicating one's level of responsibility to those outside the organization
- determining pay bands
- something to put on one's resume
Just for these reasons alone I would still insist on having an appropriate job title. It may not help me get work done, but it still impacts my career.
However, the reason why I like the idea of technical career ladders in general, is that (when done well) they should tell me how I can succeed in an organization beyond just hard work. I want to know that, if I demonstrate some ambition and initiative, that I am doing so in a way that the company will appreciate my work and I will benefit from it.
It seems to me these days that job titles are more an indicator of time-served rather than technical abilities in many organisations in addition to a method of retaining staff.
I recently observed a company move from 'everyone is the same title' to specific jnr, snr, distinguished engineer titles. The primary reasons for this was to create a framework for salaries and provide a defined track for 'progressing' as the organisation got bigger.
But if you think about it - it really comes down to a method of retaining staff and salary banding, I have yet to see any organisations where the titles of engineers defines their abilities, all engineers have the same say.
Netflix gives every engineer the same title: Senior Software Engineer. That worked out beautifully: everyone focuses on getting things done and doing the right things. One's total package depends on how important this person is to her team and to the company, and of course Netflix makes sure the person gets paid more than the market can offer. If the person disagrees with the market price, Netflix encourages the person to seek external opportunities.
Can't find a better system for those who don't about titles.
Zappos tried getting rid of titles and hierarchy. I interviewed there, and it felt unworkable to me. Power structures exist whether you define them or not. To be fair, I only got to observe it for a day, quite some time ago. Would be curious if anyone knows how that's going for them.
> Job titles squash the peculiar strengths and differences into a label and make organizations treat people as fungible units of work.
I'd think having clear job titles and differentiation would have the opposite effect of treating people as fungible units of work. I'm sorta with you on job titles, but my experience is that they enable organizational clarity, and people tend to like to show this reflected on their resumes/CVs. I'm curious to hear more about your thoughts on this.
Job titles/level are really nice at my company because they have a help provide a language and social acceptable way to talk about the scope of tasks someone can accomplish AND a way to talk about the scope of a task or project.
I think it is some measure of the quality of an organization how easily they allow and even encourage employees of all titles to take on leadership. It becomes a business advantage when done well.
That's because people do think in labels.
Mother, Father, brother, teacher, sister, uncle, boss, manager, CEO. More primitively, tribe member, tribe leader, enemy, scary cat thingy, dangerous crawling thingy. It's part of our evolution.
> then assign it to the individuals, rather than define the work based on the individuals.
I would imagine this is impractical trying to run or build a large org then because you need to be able to define the work you have to do first, then assign it, it doesn't work the other way around.
Our company has two titles, one internal that's used in the HR systems for salary etc.
The other is the external title, that's mostly used to communicate what you are good at in a compact way. My title, for example is "General Specialist" =)
It comes out of the very true reality of needing to pick a direction and lean in hard. For example, Postgres vs MySQL. Almost anywhere either would do, but you can't split the baby. Pick one or the other and carry on.
The part that breaks down for me is when people start talking about having strong opinions. Why on earth would I have a strong opinion that I hold weakly?
I'm just honest with people. We went with Postgres because we had to choose one or the other, but both would have worked.
The things I have strong opinions on are the very things that are not weakly held. "One shouldn't use Ruby for feature extraction on video at scale." It would take a lot to convince me otherwise, hence the strong opinion.
I find some people have trouble thinking in non-discrete ways. For example, I know this smart guy but he's just irrationally pissed off at five star rating systems and he only ever gives 1 star or 5 stars. He considers it a usability failure because he'd rather do a thumbs up or thumbs down. I discovered this only after complaining that the five star system was not continuous enough for me. I wanted to give something 4.8 stars because it was great, but had some slight flaws.
You make a good point, but I don't think loose = weak here. Loosely held, to me, indicates that you are willing to consider other options when presented rather than ignoring what's out there. So have a strong opinion, but be ready to listen when other options are presented. This, in my mind, does not equate to _weakness_ of opinion, just ensuring you are actually _hearing_ things.
I think it's more about committing to a direction/approach but being willing change directions in the face of new data or changing circumstances.
If there's no one making decisions that's obviously a problem, but if there is someone making decisions and they're unwilling to reevaluate those decisions that's also a problem.
It's not that as a leader you should have a strong opinion about something you know nothing about. Rather, you should gather data and fully commit to a decision that is supported by that data, while being willing to revisit the decision in the face of new data.
It's a decision making framework that places the "Anything is fine. You choose" option at the bottom in terms of value.
By the way, weakly is not a synonym of loosely in this context. Weakly/strongly here is having no opinion vs having one. Loosely means "ability to be convinced is high".
Weak: I don't care where we eat tonight.
Strong, non loose: I'll only go if we'll eat at Tadich.
Strong, loose:
- I want to go eat at Tadich.
- That's mostly sea food and I have an allergy. How about Hakkasan?
>Community
Good technical leaders are also leaders in the outside communities.
Well, why would they be ? I mean, they can be, but I fail to see it as a requirement.
I'm a bit concerned that nowadays the dev culture is that you should be working ten hours a day, and also go to meetups/brown bags lunchs/user groups/whatever another 3 hours to show off how passionate you are.
I feel like the author's prose right underneath that heading explains it really well:
If you silo yourself to only learning within your company, you are missing out on a world of experiences and expertise different than yours from the external community. Technical leaders realize this and place importance on learning from the larger world of computing than just their solo.
New ideas get introduced to orgs in many ways. In my experience, it's primarily through hiring new people, but making it an expectation of distinguished eng is clever, because you can also expect them to practice and apply discernment.
Part of the distinguished engineer's role in the company should allow them the time to do such things- attend conferences and meetups, participate in research, meet with vendors, etc. If a company needs someone focused internally on product for 8-10 hours a day, then that company cannot afford a distinguished engineer.
You can be concerned if you like but you can't change it. Some people are 9-5 engineers but the best aren't. It's just a competitive advantage to care about something a lot.
Your framing sort of reveals it. It isn't "to show off" because no one is going to know that you went to your local LUG. They're only going to know that you told them about this thing called cgroups and how this other thing called Docker allows you to develop faster and it worked.
It's utterly exhausting to do these things if you aren't into them. I, for instance, couldn't go to my local Ruby group after the first couple because it was positively unexciting to me. But the other guys there were pursuing their avocation, not their vocation, and their knowledge and skills in that dimension are probably far beyond mine as a result of the Cross-pollination of ideas that inevitably happens when vokers converse.
I think that point has more to do with having well-rounded leadership skills than being a workaholic.
In fact, I would argue that demonstrating hard boundaries when it comes to over-working is an exponentially better skill to have than working non-stop.
The best managers I've had have known when to be done for the day and disconnect from work - and lead their teams to do the same.
If you don’t understand the external context in which you work, be it customers, competitors, new ideas, new priorities, and just focus on what happens in your organisation or team then you will fail.
I'm not huge of Bryan Cantrill's often provocative tone and advice. The author links to a talk by him where Bryan deliberately misdirects the audience so he can introduce a false dichotomy about whether Software Engineering Middle Management is a toxin or a cancer. While fun if you're the kind of engineer that sneers at management I would hardly consider it a guiding post for becoming a leader.
Being a leader is hard. Being a good technical leader is harder. Programmers are like cats and their opinions are more important and refined than anyone else's. And I don't think it's sustainable to work in an environment where your every mistake or bad day will make you seem like a dipshit to your team. It can be demotivating to work under someone who has a toxic attitude problem, for sure, but it's also hard to be perfect all the time.
One thing I would add to the Humility and Empathy section is that you don't have to be all these things all the time. It's okay to have a low-energy week where you don't feel up to mentoring junior developers. It's normal to get frustrated when you review code that consistently exhibits the same patterns and bad habits you've been coaching your team out of for months. Part of building humility and empathy is creating a team where it's fine to be vulnerable: the team knows you're having an off week, that your energy is low, and they trust you that you're going to recover and bounce back from it.
There is an assumption here--one that Bryan Cantrill mentions in that toxin vs cancer talk--that management and leadership are the same.
In my experience, they have nothing to do with one another. This is especially true with technical leadership. Having people whose primary concern is organizational stability leading technical decisions is a recipe for resentment and dysfunction.
I would go even further and say if a person is concerned with making technical leadership decisions as opposed to people management decisions, they shouldn't be in "management". This includes being a CTO. Most CTOs are not as natural people managers as their VP Eng brethren, and CTOs are not best described as managers of other managers: they're entirely different roles.
This is a very good point! I'm trying become a better leader and reading this list was actually not motivating. I felt I had to be perfect all the time. I thought if I was this good I would start my own company instead of being a corporate cog.
In your first paragraph you’re asking for more respect:
> Software Engineering Middle Management is a toxin or a cancer.
In your second it seems that you don’t respect those lower on the ladder:
> Programmers are like cats and their opinions are more important and refined than anyone else's.
As a leader it’s important to distill good ideas from bad and be able to bring those lower on the ladder along. Give them the respect they deserve and you’ll get it in return.
That's a really interesting final point that I've been trying for a long time to ingrain in myself. If someone is grouchy or irritable, it might not be that they're a bad person, it could be simply a bad time, day, week. The best bit for me about being in a software team for the first time has been learning to work with people. Consistently tough but rewarding.
While the blog post is well-intentioned in its message, I can't imagine why it resonates much with the author because their professional history seems to indicate that they've never been at a job for more than a year. This isn't an ad-hominem and I'm not trying to say you need to be a faithful old fart at a company for decades to reach the rank of a technical fellow; but there's something to be said for barely being around to learning the problem space let alone having a deep impact. Seems to me a high ranking technical leader should have the experience of influencing, aligning and leading large teams on complex cross-vertical projects. Some of these things take months to design with key stakeholders, launch and finally "land". And that doesn't include the phase where you learn from said projects.
I'm not sure what a 'Distinguished Engineer' is, but in the places I've worked with 'Principal Engineers' (above the other 5 ranks or so) I've noticed that their main job is to go to meetings, be on standards committees, go to conferences, and give the folks who've been at the company a long time but don't want to work on a product team something to do.
I think that's because you don't understand what a PE is doing (or you work in a very broken org). As an example:
Imagine you're the driver of a car. You're an expert at driving that kind of car. Someone gets in the back and says, "Please go to 123 Main St.". Another person gets in next to you to tell you how to get there, they are your navigator.
You are the software engineer. You understand the mechanics of actually making the car go. The person next to you is your manager, and the person in the back is the PE.
So what has the PE and your manager done here? Well, what you didn't see is that your manager went to a bunch of meetings before getting in the car to find out that 1st avenue is blocked up and will help you avoid it by navigating you around it. And the PE? The PE had 12 meetings before getting in the car with both internal and external leaders to figure out where the car will go.
Without the PE, you would just be driving wherever you want, and maybe you'd get to a useful place and maybe you wouldn't, but with the PE there, you'll go directly to a useful place. And if you ask them why 123 Main St is the most useful place, they would probably be happy to tell you.
To you it may look like the PE is just sitting in the back, but that's because you don't see all the work they did before they sat in the car, and you haven't asked (or they're bad communicators and haven't told you).
> A technical leader should be able to have strong opinions loosely held on designs and architecture. They do not need to have opinions on everything, that would be pedantic.
Pedantry has nothing to do with having opinions on everything, but has more to do with an obsession on minutia :)</pedantry>
Does this article mean an engineer at the same comp level as a director or something else?
When pondering the expectations of an engineer at your organization, consider the expectations of a manager at the same level and how many engineers vs managers there are at that level in your company.
At large tech companies like Amazon (and possibly Microsoft), you'll find that managers reach higher levels significantly faster and in higher numbers, maybe because of unbalanced expectations of engineers at the same levels compared with other roles.
The call out about being "Customer focused" is key! Many engineers use the Individual Contributor path as a means to just solve engineering problems and an exit route from product teams. No matter if your customers are internal (other engineers) or external (actual clients), understanding the business is equally important.
An Engineer's goal is to solve problems. Technology is their tool to do so and the more you understand the business' problems, the more effective you become at using the right tools in the right ways.
A Distinguished/Principal Engineer's role is a multiplicative technical leader whose use of these tools in an effective manner will impact solving customer problems in a more effective and streamlined manner. Thus, building customer empathy is very important.
I wonder how this posts overlays with Jess' experience at GitHub. She only worked there for a couple of months and I've heard from insiders that there was a lot of tension. It would be great to hear her side of the story and see if this post was partially a comment on GH's culture or her own growth after the experience.
I realize there is a need to stratify engineers based on performance in order compensate accordingly each year during raise time, but having been in the tech ranking system for ~30 years, it turns my stomach. About 40% of the time the people promoted are really not that good, they just waited long enough or knew the right people (or were in the right division that needed to boost its clout so it promoted everyone arbitrarily). This whole "special name" business is so very misleading. You want the title of famous engineer? open source your work, let us see what you made. The masses will decide.
(And before you say "sour grapes", at my last job i rejected promotion to principal because I like my work/life balance, but eventually dropped in ranking because I refused to work 60+ hours a week in my 50's.)
All these things are important, but this misses the important distinction - the higher up the leadership chain is about the scale you operate at, whether you affect one team of developers, a couple of teams, a director level organization, executive level organization, or the whole company.
"A technical leader should also make time for growing and mentoring others."
I like this. From reading The Idea Factory, I learned that at Bell Labs it was compulsory for even the most established scientists (e.g. Shockley and Shannon) to mentor newer recruits from time to time. Mentorship is one of the highest leverage activities one can possibly do. Even if you're a high muckety-muck, you're mission is still well-served by teaching others part of the time.
Most all of these are expected of principle if not senior engineers across the board. I think the point of a distinguished engineer is more about accomplishments and value generated for a company or industry and less about exhibiting all these qualities. But I understand the frustration.
[+] [-] DVassallo|7 years ago|reply
On a semi-related note: I really dislike job titles. They make people think in labels. The most powerful feature of a team of creators is their idiosyncrasies. The best way I found to build something as a team is to adapt the work to the strengths of the individuals. Job titles squash the peculiar strengths and differences into a label and make organizations treat people as fungible units of work. Too many organizations define the work first and then assign it to the individuals, rather than define the work based on the individuals.
[+] [-] lliamander|7 years ago|reply
Others have pointed out various reasons for titles, including:
- communicating one's level of responsibility to those outside the organization
- determining pay bands
- something to put on one's resume
Just for these reasons alone I would still insist on having an appropriate job title. It may not help me get work done, but it still impacts my career.
However, the reason why I like the idea of technical career ladders in general, is that (when done well) they should tell me how I can succeed in an organization beyond just hard work. I want to know that, if I demonstrate some ambition and initiative, that I am doing so in a way that the company will appreciate my work and I will benefit from it.
[+] [-] allyant|7 years ago|reply
I recently observed a company move from 'everyone is the same title' to specific jnr, snr, distinguished engineer titles. The primary reasons for this was to create a framework for salaries and provide a defined track for 'progressing' as the organisation got bigger.
But if you think about it - it really comes down to a method of retaining staff and salary banding, I have yet to see any organisations where the titles of engineers defines their abilities, all engineers have the same say.
[+] [-] g9yuayon|7 years ago|reply
Can't find a better system for those who don't about titles.
[+] [-] tyingq|7 years ago|reply
Edit: Found a 2016 update. Sounds like it was controversial, with lots of people leaving, but also sounds like they are still doing it. http://money.com/money/4183246/holacracy-zappos/
[+] [-] leothekim|7 years ago|reply
I'd think having clear job titles and differentiation would have the opposite effect of treating people as fungible units of work. I'm sorta with you on job titles, but my experience is that they enable organizational clarity, and people tend to like to show this reflected on their resumes/CVs. I'm curious to hear more about your thoughts on this.
[+] [-] Veelox|7 years ago|reply
[+] [-] dv_dt|7 years ago|reply
[+] [-] jimmy1|7 years ago|reply
That's because people do think in labels. Mother, Father, brother, teacher, sister, uncle, boss, manager, CEO. More primitively, tribe member, tribe leader, enemy, scary cat thingy, dangerous crawling thingy. It's part of our evolution.
> then assign it to the individuals, rather than define the work based on the individuals.
I would imagine this is impractical trying to run or build a large org then because you need to be able to define the work you have to do first, then assign it, it doesn't work the other way around.
[+] [-] theshrike79|7 years ago|reply
The other is the external title, that's mostly used to communicate what you are good at in a compact way. My title, for example is "General Specialist" =)
[+] [-] lenocinor|7 years ago|reply
[+] [-] 3pt14159|7 years ago|reply
> Have strong opinions loosely held
It comes out of the very true reality of needing to pick a direction and lean in hard. For example, Postgres vs MySQL. Almost anywhere either would do, but you can't split the baby. Pick one or the other and carry on.
The part that breaks down for me is when people start talking about having strong opinions. Why on earth would I have a strong opinion that I hold weakly?
I'm just honest with people. We went with Postgres because we had to choose one or the other, but both would have worked.
The things I have strong opinions on are the very things that are not weakly held. "One shouldn't use Ruby for feature extraction on video at scale." It would take a lot to convince me otherwise, hence the strong opinion.
I find some people have trouble thinking in non-discrete ways. For example, I know this smart guy but he's just irrationally pissed off at five star rating systems and he only ever gives 1 star or 5 stars. He considers it a usability failure because he'd rather do a thumbs up or thumbs down. I discovered this only after complaining that the five star system was not continuous enough for me. I wanted to give something 4.8 stars because it was great, but had some slight flaws.
[+] [-] sailfast|7 years ago|reply
[+] [-] lemoncucumber|7 years ago|reply
If there's no one making decisions that's obviously a problem, but if there is someone making decisions and they're unwilling to reevaluate those decisions that's also a problem.
It's not that as a leader you should have a strong opinion about something you know nothing about. Rather, you should gather data and fully commit to a decision that is supported by that data, while being willing to revisit the decision in the face of new data.
[+] [-] scarejunba|7 years ago|reply
By the way, weakly is not a synonym of loosely in this context. Weakly/strongly here is having no opinion vs having one. Loosely means "ability to be convinced is high".
Weak: I don't care where we eat tonight.
Strong, non loose: I'll only go if we'll eat at Tadich.
Strong, loose:
- I want to go eat at Tadich.
- That's mostly sea food and I have an allergy. How about Hakkasan?
- Sure, let's go eat at Hakkasan.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] C4stor|7 years ago|reply
>Community Good technical leaders are also leaders in the outside communities.
Well, why would they be ? I mean, they can be, but I fail to see it as a requirement.
I'm a bit concerned that nowadays the dev culture is that you should be working ten hours a day, and also go to meetups/brown bags lunchs/user groups/whatever another 3 hours to show off how passionate you are.
Any opinions aroud that ?
[+] [-] jcoder|7 years ago|reply
[+] [-] panzagl|7 years ago|reply
[+] [-] scarejunba|7 years ago|reply
Your framing sort of reveals it. It isn't "to show off" because no one is going to know that you went to your local LUG. They're only going to know that you told them about this thing called cgroups and how this other thing called Docker allows you to develop faster and it worked.
It's utterly exhausting to do these things if you aren't into them. I, for instance, couldn't go to my local Ruby group after the first couple because it was positively unexciting to me. But the other guys there were pursuing their avocation, not their vocation, and their knowledge and skills in that dimension are probably far beyond mine as a result of the Cross-pollination of ideas that inevitably happens when vokers converse.
[+] [-] protonimitate|7 years ago|reply
In fact, I would argue that demonstrating hard boundaries when it comes to over-working is an exponentially better skill to have than working non-stop.
The best managers I've had have known when to be done for the day and disconnect from work - and lead their teams to do the same.
[+] [-] justincormack|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] agentultra|7 years ago|reply
Being a leader is hard. Being a good technical leader is harder. Programmers are like cats and their opinions are more important and refined than anyone else's. And I don't think it's sustainable to work in an environment where your every mistake or bad day will make you seem like a dipshit to your team. It can be demotivating to work under someone who has a toxic attitude problem, for sure, but it's also hard to be perfect all the time.
One thing I would add to the Humility and Empathy section is that you don't have to be all these things all the time. It's okay to have a low-energy week where you don't feel up to mentoring junior developers. It's normal to get frustrated when you review code that consistently exhibits the same patterns and bad habits you've been coaching your team out of for months. Part of building humility and empathy is creating a team where it's fine to be vulnerable: the team knows you're having an off week, that your energy is low, and they trust you that you're going to recover and bounce back from it.
[+] [-] abernard1|7 years ago|reply
In my experience, they have nothing to do with one another. This is especially true with technical leadership. Having people whose primary concern is organizational stability leading technical decisions is a recipe for resentment and dysfunction.
I would go even further and say if a person is concerned with making technical leadership decisions as opposed to people management decisions, they shouldn't be in "management". This includes being a CTO. Most CTOs are not as natural people managers as their VP Eng brethren, and CTOs are not best described as managers of other managers: they're entirely different roles.
[+] [-] msoad|7 years ago|reply
[+] [-] bluejekyll|7 years ago|reply
> Software Engineering Middle Management is a toxin or a cancer.
In your second it seems that you don’t respect those lower on the ladder:
> Programmers are like cats and their opinions are more important and refined than anyone else's.
As a leader it’s important to distill good ideas from bad and be able to bring those lower on the ladder along. Give them the respect they deserve and you’ll get it in return.
[+] [-] raehik|7 years ago|reply
[+] [-] palimpsests|7 years ago|reply
[+] [-] cimmanom|7 years ago|reply
[+] [-] fbn79|7 years ago|reply
[+] [-] draw_down|7 years ago|reply
[deleted]
[+] [-] BestischMensch|7 years ago|reply
[+] [-] PorterDuff|7 years ago|reply
[+] [-] jedberg|7 years ago|reply
Imagine you're the driver of a car. You're an expert at driving that kind of car. Someone gets in the back and says, "Please go to 123 Main St.". Another person gets in next to you to tell you how to get there, they are your navigator.
You are the software engineer. You understand the mechanics of actually making the car go. The person next to you is your manager, and the person in the back is the PE.
So what has the PE and your manager done here? Well, what you didn't see is that your manager went to a bunch of meetings before getting in the car to find out that 1st avenue is blocked up and will help you avoid it by navigating you around it. And the PE? The PE had 12 meetings before getting in the car with both internal and external leaders to figure out where the car will go.
Without the PE, you would just be driving wherever you want, and maybe you'd get to a useful place and maybe you wouldn't, but with the PE there, you'll go directly to a useful place. And if you ask them why 123 Main St is the most useful place, they would probably be happy to tell you.
To you it may look like the PE is just sitting in the back, but that's because you don't see all the work they did before they sat in the car, and you haven't asked (or they're bad communicators and haven't told you).
[+] [-] fizwhiz|7 years ago|reply
Pedantry has nothing to do with having opinions on everything, but has more to do with an obsession on minutia :)</pedantry>
[+] [-] wellreally|7 years ago|reply
When pondering the expectations of an engineer at your organization, consider the expectations of a manager at the same level and how many engineers vs managers there are at that level in your company.
At large tech companies like Amazon (and possibly Microsoft), you'll find that managers reach higher levels significantly faster and in higher numbers, maybe because of unbalanced expectations of engineers at the same levels compared with other roles.
[+] [-] ankimal|7 years ago|reply
An Engineer's goal is to solve problems. Technology is their tool to do so and the more you understand the business' problems, the more effective you become at using the right tools in the right ways.
A Distinguished/Principal Engineer's role is a multiplicative technical leader whose use of these tools in an effective manner will impact solving customer problems in a more effective and streamlined manner. Thus, building customer empathy is very important.
[+] [-] msghacq|7 years ago|reply
[+] [-] iheartpotatoes|7 years ago|reply
(And before you say "sour grapes", at my last job i rejected promotion to principal because I like my work/life balance, but eventually dropped in ranking because I refused to work 60+ hours a week in my 50's.)
[+] [-] Bahamut|7 years ago|reply
[+] [-] jessfraz|7 years ago|reply
[+] [-] swiftcoder|7 years ago|reply
[+] [-] uasm|7 years ago|reply
[+] [-] ericsoderstrom|7 years ago|reply
I like this. From reading The Idea Factory, I learned that at Bell Labs it was compulsory for even the most established scientists (e.g. Shockley and Shannon) to mentor newer recruits from time to time. Mentorship is one of the highest leverage activities one can possibly do. Even if you're a high muckety-muck, you're mission is still well-served by teaching others part of the time.
[+] [-] howard941|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] dcow|7 years ago|reply
[+] [-] W-Stool|7 years ago|reply
[+] [-] edoo|7 years ago|reply