Mochary Method Curriculum
docs.google.com
docs.google.com
>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.
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. .
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.
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.
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.
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.
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 don't know Matt, and haven't been coached by him, but I do know a lot of the founders he's coached, and have read his book https://www.amazon.com/Great-CEO-Within-Tactical-Building-eb... which covers much of the same material.)
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.
[1] "Mochary Coaching Methodology (CEO 1-1)" page https://docs.google.com/document/d/17AfqFdrx0lb6aYb786lY3a-1...
[2] CompanyOS https://companyos.app/
[3] https://mocharymethod.notion.site/Work-at-CompanyOS-419da897...
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.
So pick and choose what you need I guess.
We'll be adding more curriculum documents over the next few months — follow @mattmochary or @nateforster_ on Twitter for updates!
https://www.lennyspodcast.com/how-to-fire-people-with-grace-...
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.
He fails the Cedric Chin test:
https://commoncog.com/verifying-believability/
Definite guru vibes:
You'd probably have to read a few different books to get what's already combined here in my opinion.
I use my real name here. You can read my past comments, blog, LinkedIn etc.
[0] https://www.lennyspodcast.com/how-to-fire-people-with-grace-...
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.
(Not a critique of this particular post, just a meta problem that comes up frequently here)
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.
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 ...
This is the ultimate no-code deployment.