>You are now likely thinking: "Matt, there just aren't enough senior engineers in the world. We'd love to hire only senior folks, but we can't find them. We need to bring on junior engineers so that we can eventually train them to be senior."
>That is absolutely true. But then recognize that you are training. Create an actual training program. Do not sap the energy and time of your senior developers with this process. Have it happen off to the side, where the teachers are only those who actually derive energy from the process of teaching and mentoring.
I'm stoked to see someone preaching this to CEOs. I don't know how common this advice is given to other CEOs, but it's the first time I've seen it.
There is the ideal, and then there is the reality. Only the very largest enterprises have the scale necessary to develop comprehensive engineering training programs. Doing it right is tremendously expensive, so it can generally only be justified in organizations that onboard hundreds of new engineers every year. And even then, some level of program specific training will always be needed after completing the initial standard training.
Another perspective is to consider training junior engineers to be a core job responsibility of senior engineers. There are always going to be tasks that need to get done even if we don't "derive energy" from them. That's just part of being a professional. Most engineers who complain about teaching and mentoring shouldn't be promoted to senior level in the first place; in the long run they would probably be happier and more successful as independent consultants.
"Another perspective is to consider training junior engineers to be a core job responsibility of senior engineers. There are always going to be tasks that need to get done even if we don't "derive energy" from them. That's just part of being a professional. Most engineers who complain about teaching and mentoring shouldn't be promoted to senior level in the first place; in the long run they would probably be happier and more successful as independent consultants."
All fine and good but you need to actually get the time and be recognized for the time you put into mentoring. In the companies I have seen senior devs are still measured by their output and setting time aside for mentoring younger devs doesn't really help their ratings. A lot do it anyways but the incentives are against doing so. .
I think the advice can be more general than just "make a training program", too, because the point is that you can't stick a junior next to a senior and hope knowledge will transfer by osmosis. That's lazy management. Instead, responsibilities should be clear ("Bob will spend 4 hours a week mentoring a junior") and employee strengths should be factored in ("Steve prefers not to mentor, but knows the software internals very well and will spend some time improving documentation for Bob").
I don't think "4 hours mentoring per week" works well. From my experience some weeks you need way more and some weeks way less. I would much prefer if I would get evaluated by the progress of the people I am mentoring.
> Another perspective is to consider training junior engineers to be a core job responsibility of senior engineers.
This is, I believe, a major reason why software sucks. Just as a person becomes somewhat competent at writing software, they're told to stop the very job they're finally good at, and focus on helping juniors become... teachers for the next batch of juniors. Unless you have a point in the process at which seniors stop teaching and go back to writing code, your software ends up being written entirely by juniors, putting a cap on the quality and delivery speed of your product.
> Most engineers who complain about teaching and mentoring shouldn't be promoted to senior level in the first place; in the long run they would probably be happier and more successful as independent consultants.
Most engineers who complain about this would be even more happy and more successful as "independent consultants" with an employment contracts and a monthly salary. I.e. those engineers are just asking to be allowed to continue to do the work they're finally proficient in, under conditions they worked so far (i.e. employment contract). Instead, they're being offered a choice of pivoting to unrelated activities they're likely not good at - either teaching or managing financial risk.
Come on, real organizations aren't asking senior engineers to spend all their time on teaching juniors. It's like 10% time on average.
Growth and turnover is a fact of life for any healthy organization. Someone has to teach the juniors or else forward progress will grind to a halt. And usually the senior engineers are the only ones with the skills and knowledge necessary to do that teaching, even if they don't particularly enjoy it and it impacts their other work.
I think a good startup (I might even persue this idea) is a corporate-mentoring program that basically does code reviews w/ junior/mid-level team members esp - ones that maybe are having performance issues to go over code, or maybe even soft skills or productivity skills like communicating better or prioritizing and staying on scope.
The mentor would maybe take on 10 people in an org, and every other week go over some of their code 1:1 and offer suggestions, etc..
Basically Uber for Senior Devs (but only as mentors/training purposes).
Company could also help businesses build their own internal training systems to make juniors grow faster.
I do some of this in data science when I'm giving strategic support to teams. Be aware that managers generally see you as a cost who doesn't bring financial benefit to the team (whilst the team are desperately asking for practical training so they can deliver quicker).
Find ways to couch your offering in business benefits - you've helped teams avoid expensive bugs or via pragmatic refactoring they've responded to market change faster. Finding believable examples IMHO is actually quite hard.
I've found managers far more open to strategic support (to help the team "go in the right direction"), with things like teaching code reviews and best practices bolted on as secondary benefits.
There's probably room in the market for others, so if you want to start a business in that space then go for it. But what you're describing wouldn't really be considered a "startup" because that high-touch model can't scale up rapidly and there are minimal economies of scale. Companies doing training and coaching can only grow slowly because the service can't be automated and consistent quality depends on hiring the right type of employees. There aren't a lot of senior engineers who have the necessary experience and want to be full-time mentors, and those who do exist are expensive.
A "training program" starts with good onboarding. It might even start during the hiring process. A company with 10 devs can be training less experienced folks.
Yes, even the smallest organizations can have a decent onboarding process in terms of making sure new hires understand company policies and have the tools they need to work. But at that scale it's impractical to run a formalized engineering training program with assigned instructors teaching a defined curriculum. Realistically most of the training will have to be 1:1 mentoring delivered as needed by senior engineers. All senior engineers should be expected to participate, but of course that takes time and competent managers will plan for some temporary reduction in team velocity.
This is why pair programming is so popular, but this is presuming that the more senior in that relationship is maybe good at teaching/coaching/mentoring.
A better solution might be have a set person, or even outsource the pair programming with some mentor-in-the-middle who has teaching experience and also can build more user-centered training for that person. Like a vocal coach for music, but for software.
I agree. If management wants software development to be more like the trades they need to recognize that training is a line item cost that needs to be paid as part of the employment arrangement with both time and money allocated for it.
Not supporting or condemning but different than other markets, we can either just import cheaper seniors or offshore the work to seniors in another part of the world.
This strikes me as a good place to start, both for founders who are running something for the first time and also for more experienced execs as a good review of the fundamentals. In other words, I wish I had seen something like this when I was starting Dropbox in that a lot of our scaling problems would have been prevented by doing these basic things properly and consistently.
Mind sharing some of the lessons that you thought would have been the most valuable to know from the beginning, instead of having to learn the hard way?
> To make our meetings more effective and efficient, we have created Mochary Method software. If you find the software effective, feel free to use it with your reports as well. [1]
Does anyone have any references for this software?
> Typical reactions to the software are:
> Meeting 1: “Why are we using this software? Let’s just use a Google Doc, it’s easier.”
> Meeting 2: “Oh, I see why this software is better than a Google Doc. Let’s keep using it.”
> Meeting 3: “This software is awesome. Can I please use this throughout my entire company.”
Seems interesting.
Edit: I think it's "CompanyOS" [2]. The homepage is nearly a replica of the Mochary Method website.
But, I haven't seen anything about how the software works. Does anyone have any information about it's features?
From the hiring page [3]:
> Each is paying $150,000/yr for access to our product.
The Great CEO within is a great book. Honestly, also for non-CEOs. One of the better (and short) Startup/B2B/SaaS self-help books.
But one grain of salt: If you are at a smaller startup like me (~35 people) implementing all the lessons and tips would required doubling head count just for all the reporting, training, engineering, sales and marketing support staff you would need.
They work nothing like he says. It makes me doubt all his other advice. I used to like to read Mochary. Now I think he is selling a line of bull that tech people like to read.
Mostly because he's too high-level and he doesn't have enough windows into the company. "Amazon is good at innovation"... Really? People don't need equity to get motivated? Really?
Amazon employs more than one million people and I guarantee you that many of its teams suck at innovation. Many are full of bozos led by the blind. That's why they buy so many little startups. They failed to build it themselves.
People don't need equity to be motivated? Well, cheap hiring managers want to believe that. Good luck hiring that crucial engineer...
Mochary's experience as an operator is out of date, and his updated opinions depend on news reports and self-reporting.
This is amazing content. Short yet detailed. I've read his book multiple times, and implemented some of its advice, but I'm still finding new nuggets in the curriculum.
Thanks took a quick skim seemed rather interesting. Always good to get others opinions before putting time in, even if they are anonymous internet people (no offense intended).
I've read a bit of his book. He definitely combines the good parts from various other frameworks and leadership books. Overall a solid foundation of everything you might want to know as a person in a influential position.
You'd probably have to read a few different books to get what's already combined here in my opinion.
As a coach at Mochary Method (which I know is coming from a biased perspective, so please take it with a grain of salt), I think the important thing to emphasize here is having the conversation with your senior engineer first.
In some situations, the senior engineer may love training and can allocate some of his/her time to up-leveling junior engineers. In other situations, the senior engineer may like to do 1:1s, but hates building the system/curriculum to train others. Find the win-win that meets both of your needs.
As a general rule of thumb, it's best to keep every member of the team in their zone of genius (i.e. high competency AND enjoyment) as much as possible. Have the conversation so you can optimize for that.
Is there a way to look at a google doc without using my google account? Clicking the link asks me to choose one of my Google accounts, and I don't want to give that information out to random posts. It would be nice if there was a service that could pdf it or something and let you download that.
(Not a critique of this particular post, just a meta problem that comes up frequently here)
I was able to view it in firefox focus on an android with no google account. i presume a private window and / or a browser that you haven't signed in to google should work just fine.
These are all the frameworks you need to run and scale a company. This is the tactical stuff that never gets shared, yet actually forms a company’s habits and operations
Mochary is CEO Coach to companies including Coinbase, Opendoor, Bolt, and Clearbit.[1] Mochary was a co-founder and Chairman of Totality Corporation, founded in 1999 and acquired by MCI Inc. in 2005.
The t submissions calls him a CEO coach. So I assume one of those life coach, success consulting people that regularly advertise on Youtube? Or on LinkedIn, in case he has a high enough profile?
The difference between Mochary and Campbell is stark.
Campbell did not receive compensation for his coaching. He used to say "I don't take money, options, or bullshit."
There was a reason for that. Campbell knew that if he took CEOs' money, he enter the circle jerk of people telling each other what they wanted to hear.
Mochary is part of that circle jerk, unfortunately. He is passing on received and second-hand wisdom, supposed lessons that he didn't learn the hard way, and may not be true at all.
He is well known in Sequoia circles, and you might say he's their in-house coach. But Sequoia, well, they also backed FTX ...
That's a pretty huge claim to make without any sort of evidence. Bill Campbell had an enormous impact on the Valley and a stellar reputation as a coach.
>https://docs.google.com/document/d/1yL_m10CT6bIVsvSfjsCcm_Q4...
>You are now likely thinking: "Matt, there just aren't enough senior engineers in the world. We'd love to hire only senior folks, but we can't find them. We need to bring on junior engineers so that we can eventually train them to be senior."
>That is absolutely true. But then recognize that you are training. Create an actual training program. Do not sap the energy and time of your senior developers with this process. Have it happen off to the side, where the teachers are only those who actually derive energy from the process of teaching and mentoring.
I'm stoked to see someone preaching this to CEOs. I don't know how common this advice is given to other CEOs, but it's the first time I've seen it.