![Artwork](/static/images/128pixel.png)
Работайте офлайн с приложением Player FM !
Succession Planning: Delegation Skills and Technical Ownership with Max Kanat-Alexander (2/3)
Manage episode 431457974 series 2409143
What should we consider before taking on a new work-related or personal project? Max Kanat-Alexander, our guest this week in episode 286, thinks about the end of his involvement in a project as a first step. The only way to focus on bigger things that could make a larger impact is to offload what you’re working on now. Succession planning is about offloading a responsibility or specific work to another person in a way that helps them grow and simultaneously gives us the chance to work on something new.
In part 2 of our discussion with Max, you’ll hear more about the role and responsibilities of a technical lead in software engineering. Max will share the story behind his move away from consulting and the decrease in focus on Bugzilla, how he became the technical owner of engineering documentation at Google, and the decision to author a technical book.
Original Recording Date: 06-30-2024
Max Kanat-Alexander is a Principal Staff Software Engineer at LinkedIn and is one of the technical leads for the developer productivity and happiness team. If you missed part 1 of our discussion with Max, check out Episode 285.
Topics – More on the Tech Lead Role, Tech Lead and Communication Skills, Interactions in Software Engineering, Delegation and Assessing Growth Potential in Others, Leaving Consulting and Passing the Bugzilla Torch, Technical Ownership and Succession Planning, Becoming a Published Author
2:35 – More on the Tech Lead Role
- So to progress up to technical lead, it’s about technical depth, a willingness to coordinate resources to solve a problem, and a desire to make others better?
- Many of the senior most engineers care deeply about what they work on and are experienced technologists. Max has written professionally in 10 different programming languages, for example. It’s important for the technical lead and other experienced engineers to remember not everyone will have the same technical background as you, and they will have skills that you don’t.
- “It’s really important not just to be able to coordinate resources but to figure out and understand how best to utilize and employ all of the different engineers that you have available to you to cause work to be done effectively and to recognize that people have strengths and weaknesses. Don’t be surprised if you assign a task to somebody who is not strong in that task and they don’t do a good job. Or, be aware that they have that weakness and either you’re going to mentor them through it or you’re going to find someone else to mentor them through it. Because it’s not just your job to deliver a product at that point. It’s also to cause a team to exist that can deliver the product.” – Max Kanat-Alexander
- Managers create and sustain teams by performing their essential job activities – hiring, firing, and performance reviews. These are not tech lead duties!
- Remember – you may be more technical than the managers you work with.
- “The only person who’s going to judge the quality of the work and to describe how people are going to up level their craft of engineering is you. And you have to really care about the people who you lead.” – Max Kanat-Alexander, on the responsibility of the tech lead
- Max has seen technical leads get frustrated at the team members around them and their skill level, and he reminds those tech leads it is their job to help others get better.
- Nick says a tech lead is a stakeholder in performance review discussions even though managers own that process overall. Input from the tech lead on someone’s work and performance will be through a different lens than the manager.
5:46 – Tech Lead and Communication Skills
- Nick says it seems like communication skills are very important if you want to be a tech lead. We’re talking about communicating well with other people who do the same type of work as you as well as people from other teams. Did Max’s role as community lead for Bugzilla help him build the necessary communication skills for being an effective technical lead later in his career, or was it something else?
- “It is extremely hard to rise up the technical ladder without excellent communication skills.” – Max Kanat-Alexander
- Max has always loved writing, and he feels like this really helped develop his communication skills. He would write short stories in elementary school. Max viewed writing essays in college as just writing practice and would turn in rough drafts.
- “In real life, you’re going to be sending out first drafts of a thing you wrote every day, and they are called e-mails.” – Max Kanat-Alexander
- Can someone improve communication skills by writing code?
- Max says writing code is a very different discipline.
- “Writing code is like a computational meditation with yourself. It is…for me one of the most beautiful and fulfilling experiences that I have in my life, and I love doing it. But it is something I am doing with myself…the actual process of writing code. However, the reality is, software engineering is much more of a human discipline than it is a technical discipline.” – Max Kanat-Alexander
- Max says working on a software engineering project involves spending just as much or more time interacting with people than writing code.
8:38 – Interactions in Software Engineering
- Do most people get surprised by the amount of interactions required to work in software development / software engineering?
- Max says yes and that it is shocking to most all who enter the industry. Many people got into programming because they did not feel socially competent or didn’t want a lot of social interaction.
- “There is a tremendous amount of social interaction involved in team software development.” – Max Kanat-Alexander
- Rather than the social interaction weeding people out, Max sees people grow into it most of the time.
- “There will be a point where your career cannot grow past a certain point until you become a great communicator.” – Max Kanat-Alexander, on being a great technologist but not progressing as a communicator
- An extremely talented engineer without good communication skills would need to have a champion internally defend them in performance reviews. Listen to the way Max describes this happening in his experience.
- How can software engineers learn to develop the communication skills they need in addition to learning from interactions at work? Many of the other guests we’ve spoken with highlighted the importance of communication skills in their career progression.
- Max says there a number of training programs that can help people improve their communication skills. He mentions Effective Training Solutions by name as having one of the most effective programs to teach people how to communicate in corporate environments.
- “You’ve got to find some training or information that works…You can’t just be like, ‘well, a smart person wrote this. So it must be true. You have to decide for yourself.’” – Max Kanat-Alexander
- Max mentions we need to try things and see if they actually work because there are many in the industry selling programs based on pseudo-science that don’t work.
- Reading Dale Carnegie’s How to Win Friends and Influence People may not be what you need. Max says using the techniques inside will eventually cause you to run into barriers.
12:25 – Delegation and Assessing Growth Potential in Others
- Following the theme of technical ownership from Bugzilla, into consulting, and then when Max worked for Google…
- Did Max and his co-workers own both the scoping and delivery of any consulting work at the consulting firm he started?
- Max refers to consulting work as freelance work.
- Max did all the scoping at his consulting firm focused on Bugzilla as well as all design work for customer projects. He would handle implementation of small projects on his own and leverage contractors when needed for larger projects.
- Was it hard for Max to learn to delegate after having done so much with the Bugzilla project?
- The Bugzilla experience made Max thankful when people showed up to do work because it was way more work than he could do on his own, and he had become skilled in delegation as a result.
- “You also learn to detect people who are bad but will get better and people who are bad and will never get better, which is really an important skill to have as both a tech lead and I think a manager…. You can see if an engineer is improving or not, and that’s a really important skill as far as delegation goes…. You’re going to delegate something, and somebody’s going to do it wrong. And so there has to be a review process.” – Max Kanat-Alexander
- Any time someone did work for the firm’s customers, Max would code review the work before it was released on behalf of his company to be used by customers.
- Part of this is deciding what contractors you will hire. Do you know them and if you can trust them? Do the contractors you are working with have potential to improve and a mindset that will support them improving, or do they have a fixed mindset about everything?
- “You are in a position where you can delegate because you are competent, and you are probably more competent than the people you are delegating to. And you have to know this person’s going to get better, so as a result, I will help this person. This other person, I’ve helped them enough. And they are never going to get better, and I am going to fire them.” – Max Kanat-Alexander, on delegation and competence
- Did Max and his co-workers own both the scoping and delivery of any consulting work at the consulting firm he started?
- Is there a way to determine if someone has the potential for improvement in an interview? How can an interviewer determine this?
- Max encourages interviewers to give candidates something similar to what they would be doing.
- “You don’t just want to be sure that they solve it correctly. You want to watch how they do it and especially how they do it when given some independence. So don’t give them every answer along the way. Act a little bit like you aren’t there and you just want to see how they do work when nobody is watching.” – Max Kanat-Alexander
- Max conducts interviews differently depending on the level of the person he’s interviewing and the open position. Max mentions giving someone a piece of paper with requirements and allowing them to ask him anything they want, answering only what the candidate asks.
- Nick suggests the honing of the interview based on the job role and level is a skill both the technical lead and manager would need to master over time even if they had not done so upon taking a role.
- Should the technical lead be sitting in on job interviews?
- Max says the tech lead should be directly interviewing people. They should be conducting interviews by themselves.
- “If you don’t know how to do interviews, you should sit in with other sand follow them for a little while and figure out what the company process is for doing interviews. But you absolutely need to be involved in interviewing people.” – Max Kanat-Alexander, on the tech lead’s responsibility in the interview process
17:27 – Leaving Consulting and Passing the Bugzilla Torch
- Max and his mother were the only full time employees of his consulting firm. His mother had experience running multiple companies and doing organizational administration.
- Max’s mother spent a huge amount of time working to get other companies to pay Max’s firm for services delivered.
- “The hardest part of being a consultant is getting people to pay you…. I wanted to get off of that roller coaster. When you are a freelancing consultant, I like to say you have infinite vacation days, and none of those days are paid…. If you don’t work, you don’t get paid. And sometimes you do work, and you don’t get paid…. I wanted to get out of that world.” – Max Kanat-Alexander
- Max enjoyed the independence and being able to work from home.
- Max had no issues staying motivated because he loved Bugzilla and the work that focused on it (which was the majority of his company’s focus). He also loved coding.
- Max eventually had to hand over Bugzilla to someone else (the baby he had looked after for so long).
- When Max joined Google, there was something called 20% time. As long as it benefitted the company in some way, an employee could work on whatever they wanted. Max had negotiated to spend that time working on Bugzilla and did so for about the first year he was with the company.
- “But eventually the things that I was working on at Google became so interesting to me that I just really wanted to work on those.” – Max Kanat-Alexander
- There were around 10,000 companies using Bugzilla at this time.
- There was a bigger impact to be made through involvement with the products at Google (i.e. working on a product that would have 50 million users upon release), and that was more fun for Max. He liked the technical challenges, the work he was doing, the company, and the people.
- Anticipating he would eventually lose focus on Bugzilla, Max made sure Mozilla hired 2 developers for Bugzilla so that the project could survive.
- How can we be ok with laying something down that we’ve worked on for so long?
- Matt mentions two ways out – the good way and the bad way. He has tried to take the good way out of scenarios like this in his career.
- “The good way out is I feel confident that others will take the flag and run with it and it’ll be beautiful. And I love the thing that I work on now. I’m really excited about this thing that I work on now, and everybody else is going to take it.” – Max Kanat-Alexander
- The bad way out is thinking no one can replace you in a specific role / project and then hitting a point where you can no longer work on it (i.e. life situation, etc.).
- “As a result, every time I take on a project…the first thing I think about, the very first thing I think about for every project I ever take on is, ‘how am I going to get rid of it?’” – Max Kanat-Alexander
- How did Max learn to think this way and ask himself how to get rid of a project before starting?
- Max likely learned this during his time on the Bugzilla project when he had more work than one person could possibly do.
- Max feels he learned some of this at Kerio while working as 2nd level technical lead for the 3-person technical support group.
- Max knew he could not work every ticket and learned to delegate them to other team members.
- He later got an idea for writing a document outlining the tech support processes for the company but knew he would have to stop working tickets to write that document. There was also the Bugzilla work Max was doing that needed to be factored into how he spent his time.
- “I think you see over time unless I can at some point get rid of the thing that I work on I will never be able to move to bigger things.” – Max Kanat-Alexander
- Maybe this is a good exercise to keep our identity from getting tied up in a thing we do? Having our identity tied to our work is a problem, especially if you have worked on something for a long time.
23:00 – Technical Ownership and Succession Planning
- What did technical ownership at Google look like when it came to ownership of the engineering practice documentation?
- Max had written a document with tips for doing code reviews from his time working on Bugzilla and his brief time doing code reviews at Google. The document became very popular.
- Max also participated in a weekly code health group, and the leaders of the group (who had deep connections within the company) recommended Max make his document the official code review guide for Google. They encouraged him to contact one of the senior technical fellows at Google to gain approval.
- Once Max got approval to use his document as the official guide for code reviews, he wanted to put it in a centralized location. But in doing this he also noticed other standardized documents like his code review document. These were documents for things like testing and style guides that needed more visibility and in some cases better ownership.
- “I think we worked in many ways by popular acclaim. And I never tried to…force a standard on the company that it didn’t agree with. I would always try to have conversations in advance with as many engineers as I possibly could….” – Max Kanat-Alexander
- Max tells us no one was doing what he ended up doing (making pull requests more visible and collaborative, etc.), and it was very well received.
- “It’s amazing that sometimes you can just get a responsibility by finding a thing that’s really important but that nobody else wants to own and then be granted it, and then it is legitimately yours.” – Max Kanat-Alexander, on becoming the owner of documentation
- When the leaders of the code health group Max participated in left the company, they asked him to be the group lead. Max had successfully owned the documentation and rolled it out to the entire company at that point and was a published author.
- “If I had to have a core piece of advice for people’s career, it would be just do the thing you want to do. Whatever the thing is that you want to do, find any way you possibly can to do it. And if you just do it enough, eventually it will be your job.” – Max Kanat-Alexander
- Max wasn’t asking someone else to create a standard like back in the days of the Fedora FAQ. He had merely written a very popular document because he cared about code reviews and felt others could benefit from his experience. As it turns out, many people benefitted from it.
- The ownership of the documentation was something Max did because he wanted to do it and not because it was part of his formal job responsibilities.
- Following the mantra of thinking about how to get rid of something before you commit to working on it long term, eventually Max handed off the documentation ownership to a colleague (Adam Bender).
- “I remember the moment that Adam Bender showed up in the code health group and he started posting and we started having conversations. Immediately I was like ‘if I ever leave this person is my successor.’ It took me maybe 2 weeks of interacting with him to be like, ‘oh, it’s definitely going too be Adam.’” – Max Kanat-Alexander
- Nick suggests succession planning extends beyond being something organizations and managers need to do and can apply to many different things (like technical projects / things that require owners). The technical owner almost needs to be a talent scout and keep watch for people who would make good contributors and future owners.
- “As life goes on and you work at a company and you’re trying to succession plan things, it often still works just like it works for volunteer projects and open source projects. You’re actually looking for the person who is the most passionate and wants to be the most involved. You’re not looking for a manager to appoint somebody your successor. You ideally want to convince a manager that somebody should be your successor.” – Max Kanat-Alexander
- Should someone seeking a technical lead role have mastered the skill of succession planning?
- Max says in the long it is important to master succession planning.
- “The people who succeed you become really important connective tissue for you in your career.” – Max Kanat-Alexander
- Max mentions he continues to stay in touch with Adam, for example. They continue to have a great relationship and help one another. Though Max has fallen out of touch a little bit with people from his time working on the Bugzilla project, he is confident the relationships would continue if he were to work with them again.
- “In the short term, you don’t need to be a master of this. It depends on how much you want to leave the world better than you found it. If you want to build a sandcastle that gets knocked down when you leave, you don’t need to master this skill. If you want to build a cathedral that everybody can walk in and admire and enjoy and love long after you’re gone, you need to master this skill.” – Max Kanat-Alexander, on mastering succession planning
- Nick says the above is legacy building.
30:45 – Becoming a Published Author
- Writing a book seems like a form of legacy building. What was Max’s motivation to become a published author?
- Max isn’t interested in work that he feels does not affect the world in some way. Even if it was part of the world or the impact would be made / felt in the future, that is the type of work he would rather be doing.
- When Max came into programming, he had 10 years of previous IT experience and had seen many different ways in which a computer could break. He did not like it and did not want other people to keep experiencing these problems.
- Max felt the problems he had seen boiled down to complexity, and once he worked as a programmer this was confirmed.
- With Bugzilla they took a code base that was challenging to write in a well structured way and transformed it into a code base on which people enjoyed working. Max wanted to share that with the world.
- Max developed a habit of interviewing programmers and had interviewed probably 100 by the time he wrote his book Code Simplicity.
- The work Max and others had done with Bugzilla was something almost no one else had done. Maybe there was something there he knew about that he could write about and share with others.
- Max had a background in epistemology and enjoyed breaking things down into fundamental principles (i.e. enjoyed it so much it was almost like a hobby).
- “I can take this experience, and I can use it to reduce it down to a set of principles that caused this work to succeed. And I can publish those, and if other people can benefit from those, that would be great.” – Max Kanat-Alexander
- O’Reilly had been wanting to launch a number of programming books like the one Max had written. They accepted his proposal, and Max says they were wonderful to work with.
- How long does a book proposal have to be?
- Max says publishers have a template they use for book proposals that authors can follow.
- Does the book have to be written when you submit the proposal, or can it be thought of like a conference talk (i.e. just write the abstract)?
- You do not need to have a book written to submit a proposal to a publisher, but Max had already written the book by the time he wrote and submitted the proposal.
- Max’s mother was already a published author and helped him with the publishing process.
- For those thinking about writing a book, what would Max recommend be taken into consideration before starting a project like this?
- “Any professional author will tell you that the only way that you’re ever going to get through the process of writing a book is if you love writing books.” – Max Kanat-Alexander
- Max recommends writing a book because you want to do it. And in the technical field you should not expect to make a significant amount of money with a book.
- Max tells us having written a book for O’Reilly is a nice calling card that can be used to establish technical credibility in his case.
- One way to make money is through paid speaking engagements after writing the book. You would also need to figure out how to market your book since publishers usually don’t do much to help.
- “If you have a message that you really want to get out to the world, technical or nontechnical, a book is a great way to do it.” – Max Kanat-Alexander
- Does writing a technical book immediately create pressure to publish a revision because of our changing technology industry? Or should an author try to create something with content that is more evergreen?
- Max mentions this is a constant problem for technical books. Books are often pushed aside for more up to date websites and reference materials.
- Max mentions books are a much better teaching mechanism in technology and can be presented in a cohesive story to the reader. We can “learn it through a system somebody has spent hundreds of hours refining.” The book is a better experience than just reading through online documentation in Max’s opinion.
- Max mentions publishers have consistently tried to make it easier for authors to update books after the initial publishing, adding print on demand options for example to prevent ordering too many physical copies at once.
- “My book was evergreen by its nature. I as a person care much more about writing and creating things that are timeless and will help everybody. It just doesn’t interest me as much to write something very narrow about a specific technology even if I was able to.” – Max Kanat-Alexander
- Nick feels like the evergreen focus and desire to make an impact for the good of the world aligns with the heart of the principal engineer.
Mentioned in the Outro
- The pre-mortem exercise reminds us we can work on something for a time and then be open to working on other interesting problems.
- Succession planning is delegation that gives someone else an opportunity for growth just like participating in a specific project was a growth opportunity for us. Handing off a project is building others up.
Contact the Hosts
- The hosts of Nerd Journey are John White and Nick Korte.
- E-mail: nerdjourneypodcast@gmail.com
- DM us on Twitter/X @NerdJourney
- Connect with John on LinkedIn or DM him on Twitter/X @vJourneyman
- Connect with Nick on LinkedIn or DM him on Twitter/X @NetworkNerd_
10 эпизодов
Manage episode 431457974 series 2409143
What should we consider before taking on a new work-related or personal project? Max Kanat-Alexander, our guest this week in episode 286, thinks about the end of his involvement in a project as a first step. The only way to focus on bigger things that could make a larger impact is to offload what you’re working on now. Succession planning is about offloading a responsibility or specific work to another person in a way that helps them grow and simultaneously gives us the chance to work on something new.
In part 2 of our discussion with Max, you’ll hear more about the role and responsibilities of a technical lead in software engineering. Max will share the story behind his move away from consulting and the decrease in focus on Bugzilla, how he became the technical owner of engineering documentation at Google, and the decision to author a technical book.
Original Recording Date: 06-30-2024
Max Kanat-Alexander is a Principal Staff Software Engineer at LinkedIn and is one of the technical leads for the developer productivity and happiness team. If you missed part 1 of our discussion with Max, check out Episode 285.
Topics – More on the Tech Lead Role, Tech Lead and Communication Skills, Interactions in Software Engineering, Delegation and Assessing Growth Potential in Others, Leaving Consulting and Passing the Bugzilla Torch, Technical Ownership and Succession Planning, Becoming a Published Author
2:35 – More on the Tech Lead Role
- So to progress up to technical lead, it’s about technical depth, a willingness to coordinate resources to solve a problem, and a desire to make others better?
- Many of the senior most engineers care deeply about what they work on and are experienced technologists. Max has written professionally in 10 different programming languages, for example. It’s important for the technical lead and other experienced engineers to remember not everyone will have the same technical background as you, and they will have skills that you don’t.
- “It’s really important not just to be able to coordinate resources but to figure out and understand how best to utilize and employ all of the different engineers that you have available to you to cause work to be done effectively and to recognize that people have strengths and weaknesses. Don’t be surprised if you assign a task to somebody who is not strong in that task and they don’t do a good job. Or, be aware that they have that weakness and either you’re going to mentor them through it or you’re going to find someone else to mentor them through it. Because it’s not just your job to deliver a product at that point. It’s also to cause a team to exist that can deliver the product.” – Max Kanat-Alexander
- Managers create and sustain teams by performing their essential job activities – hiring, firing, and performance reviews. These are not tech lead duties!
- Remember – you may be more technical than the managers you work with.
- “The only person who’s going to judge the quality of the work and to describe how people are going to up level their craft of engineering is you. And you have to really care about the people who you lead.” – Max Kanat-Alexander, on the responsibility of the tech lead
- Max has seen technical leads get frustrated at the team members around them and their skill level, and he reminds those tech leads it is their job to help others get better.
- Nick says a tech lead is a stakeholder in performance review discussions even though managers own that process overall. Input from the tech lead on someone’s work and performance will be through a different lens than the manager.
5:46 – Tech Lead and Communication Skills
- Nick says it seems like communication skills are very important if you want to be a tech lead. We’re talking about communicating well with other people who do the same type of work as you as well as people from other teams. Did Max’s role as community lead for Bugzilla help him build the necessary communication skills for being an effective technical lead later in his career, or was it something else?
- “It is extremely hard to rise up the technical ladder without excellent communication skills.” – Max Kanat-Alexander
- Max has always loved writing, and he feels like this really helped develop his communication skills. He would write short stories in elementary school. Max viewed writing essays in college as just writing practice and would turn in rough drafts.
- “In real life, you’re going to be sending out first drafts of a thing you wrote every day, and they are called e-mails.” – Max Kanat-Alexander
- Can someone improve communication skills by writing code?
- Max says writing code is a very different discipline.
- “Writing code is like a computational meditation with yourself. It is…for me one of the most beautiful and fulfilling experiences that I have in my life, and I love doing it. But it is something I am doing with myself…the actual process of writing code. However, the reality is, software engineering is much more of a human discipline than it is a technical discipline.” – Max Kanat-Alexander
- Max says working on a software engineering project involves spending just as much or more time interacting with people than writing code.
8:38 – Interactions in Software Engineering
- Do most people get surprised by the amount of interactions required to work in software development / software engineering?
- Max says yes and that it is shocking to most all who enter the industry. Many people got into programming because they did not feel socially competent or didn’t want a lot of social interaction.
- “There is a tremendous amount of social interaction involved in team software development.” – Max Kanat-Alexander
- Rather than the social interaction weeding people out, Max sees people grow into it most of the time.
- “There will be a point where your career cannot grow past a certain point until you become a great communicator.” – Max Kanat-Alexander, on being a great technologist but not progressing as a communicator
- An extremely talented engineer without good communication skills would need to have a champion internally defend them in performance reviews. Listen to the way Max describes this happening in his experience.
- How can software engineers learn to develop the communication skills they need in addition to learning from interactions at work? Many of the other guests we’ve spoken with highlighted the importance of communication skills in their career progression.
- Max says there a number of training programs that can help people improve their communication skills. He mentions Effective Training Solutions by name as having one of the most effective programs to teach people how to communicate in corporate environments.
- “You’ve got to find some training or information that works…You can’t just be like, ‘well, a smart person wrote this. So it must be true. You have to decide for yourself.’” – Max Kanat-Alexander
- Max mentions we need to try things and see if they actually work because there are many in the industry selling programs based on pseudo-science that don’t work.
- Reading Dale Carnegie’s How to Win Friends and Influence People may not be what you need. Max says using the techniques inside will eventually cause you to run into barriers.
12:25 – Delegation and Assessing Growth Potential in Others
- Following the theme of technical ownership from Bugzilla, into consulting, and then when Max worked for Google…
- Did Max and his co-workers own both the scoping and delivery of any consulting work at the consulting firm he started?
- Max refers to consulting work as freelance work.
- Max did all the scoping at his consulting firm focused on Bugzilla as well as all design work for customer projects. He would handle implementation of small projects on his own and leverage contractors when needed for larger projects.
- Was it hard for Max to learn to delegate after having done so much with the Bugzilla project?
- The Bugzilla experience made Max thankful when people showed up to do work because it was way more work than he could do on his own, and he had become skilled in delegation as a result.
- “You also learn to detect people who are bad but will get better and people who are bad and will never get better, which is really an important skill to have as both a tech lead and I think a manager…. You can see if an engineer is improving or not, and that’s a really important skill as far as delegation goes…. You’re going to delegate something, and somebody’s going to do it wrong. And so there has to be a review process.” – Max Kanat-Alexander
- Any time someone did work for the firm’s customers, Max would code review the work before it was released on behalf of his company to be used by customers.
- Part of this is deciding what contractors you will hire. Do you know them and if you can trust them? Do the contractors you are working with have potential to improve and a mindset that will support them improving, or do they have a fixed mindset about everything?
- “You are in a position where you can delegate because you are competent, and you are probably more competent than the people you are delegating to. And you have to know this person’s going to get better, so as a result, I will help this person. This other person, I’ve helped them enough. And they are never going to get better, and I am going to fire them.” – Max Kanat-Alexander, on delegation and competence
- Did Max and his co-workers own both the scoping and delivery of any consulting work at the consulting firm he started?
- Is there a way to determine if someone has the potential for improvement in an interview? How can an interviewer determine this?
- Max encourages interviewers to give candidates something similar to what they would be doing.
- “You don’t just want to be sure that they solve it correctly. You want to watch how they do it and especially how they do it when given some independence. So don’t give them every answer along the way. Act a little bit like you aren’t there and you just want to see how they do work when nobody is watching.” – Max Kanat-Alexander
- Max conducts interviews differently depending on the level of the person he’s interviewing and the open position. Max mentions giving someone a piece of paper with requirements and allowing them to ask him anything they want, answering only what the candidate asks.
- Nick suggests the honing of the interview based on the job role and level is a skill both the technical lead and manager would need to master over time even if they had not done so upon taking a role.
- Should the technical lead be sitting in on job interviews?
- Max says the tech lead should be directly interviewing people. They should be conducting interviews by themselves.
- “If you don’t know how to do interviews, you should sit in with other sand follow them for a little while and figure out what the company process is for doing interviews. But you absolutely need to be involved in interviewing people.” – Max Kanat-Alexander, on the tech lead’s responsibility in the interview process
17:27 – Leaving Consulting and Passing the Bugzilla Torch
- Max and his mother were the only full time employees of his consulting firm. His mother had experience running multiple companies and doing organizational administration.
- Max’s mother spent a huge amount of time working to get other companies to pay Max’s firm for services delivered.
- “The hardest part of being a consultant is getting people to pay you…. I wanted to get off of that roller coaster. When you are a freelancing consultant, I like to say you have infinite vacation days, and none of those days are paid…. If you don’t work, you don’t get paid. And sometimes you do work, and you don’t get paid…. I wanted to get out of that world.” – Max Kanat-Alexander
- Max enjoyed the independence and being able to work from home.
- Max had no issues staying motivated because he loved Bugzilla and the work that focused on it (which was the majority of his company’s focus). He also loved coding.
- Max eventually had to hand over Bugzilla to someone else (the baby he had looked after for so long).
- When Max joined Google, there was something called 20% time. As long as it benefitted the company in some way, an employee could work on whatever they wanted. Max had negotiated to spend that time working on Bugzilla and did so for about the first year he was with the company.
- “But eventually the things that I was working on at Google became so interesting to me that I just really wanted to work on those.” – Max Kanat-Alexander
- There were around 10,000 companies using Bugzilla at this time.
- There was a bigger impact to be made through involvement with the products at Google (i.e. working on a product that would have 50 million users upon release), and that was more fun for Max. He liked the technical challenges, the work he was doing, the company, and the people.
- Anticipating he would eventually lose focus on Bugzilla, Max made sure Mozilla hired 2 developers for Bugzilla so that the project could survive.
- How can we be ok with laying something down that we’ve worked on for so long?
- Matt mentions two ways out – the good way and the bad way. He has tried to take the good way out of scenarios like this in his career.
- “The good way out is I feel confident that others will take the flag and run with it and it’ll be beautiful. And I love the thing that I work on now. I’m really excited about this thing that I work on now, and everybody else is going to take it.” – Max Kanat-Alexander
- The bad way out is thinking no one can replace you in a specific role / project and then hitting a point where you can no longer work on it (i.e. life situation, etc.).
- “As a result, every time I take on a project…the first thing I think about, the very first thing I think about for every project I ever take on is, ‘how am I going to get rid of it?’” – Max Kanat-Alexander
- How did Max learn to think this way and ask himself how to get rid of a project before starting?
- Max likely learned this during his time on the Bugzilla project when he had more work than one person could possibly do.
- Max feels he learned some of this at Kerio while working as 2nd level technical lead for the 3-person technical support group.
- Max knew he could not work every ticket and learned to delegate them to other team members.
- He later got an idea for writing a document outlining the tech support processes for the company but knew he would have to stop working tickets to write that document. There was also the Bugzilla work Max was doing that needed to be factored into how he spent his time.
- “I think you see over time unless I can at some point get rid of the thing that I work on I will never be able to move to bigger things.” – Max Kanat-Alexander
- Maybe this is a good exercise to keep our identity from getting tied up in a thing we do? Having our identity tied to our work is a problem, especially if you have worked on something for a long time.
23:00 – Technical Ownership and Succession Planning
- What did technical ownership at Google look like when it came to ownership of the engineering practice documentation?
- Max had written a document with tips for doing code reviews from his time working on Bugzilla and his brief time doing code reviews at Google. The document became very popular.
- Max also participated in a weekly code health group, and the leaders of the group (who had deep connections within the company) recommended Max make his document the official code review guide for Google. They encouraged him to contact one of the senior technical fellows at Google to gain approval.
- Once Max got approval to use his document as the official guide for code reviews, he wanted to put it in a centralized location. But in doing this he also noticed other standardized documents like his code review document. These were documents for things like testing and style guides that needed more visibility and in some cases better ownership.
- “I think we worked in many ways by popular acclaim. And I never tried to…force a standard on the company that it didn’t agree with. I would always try to have conversations in advance with as many engineers as I possibly could….” – Max Kanat-Alexander
- Max tells us no one was doing what he ended up doing (making pull requests more visible and collaborative, etc.), and it was very well received.
- “It’s amazing that sometimes you can just get a responsibility by finding a thing that’s really important but that nobody else wants to own and then be granted it, and then it is legitimately yours.” – Max Kanat-Alexander, on becoming the owner of documentation
- When the leaders of the code health group Max participated in left the company, they asked him to be the group lead. Max had successfully owned the documentation and rolled it out to the entire company at that point and was a published author.
- “If I had to have a core piece of advice for people’s career, it would be just do the thing you want to do. Whatever the thing is that you want to do, find any way you possibly can to do it. And if you just do it enough, eventually it will be your job.” – Max Kanat-Alexander
- Max wasn’t asking someone else to create a standard like back in the days of the Fedora FAQ. He had merely written a very popular document because he cared about code reviews and felt others could benefit from his experience. As it turns out, many people benefitted from it.
- The ownership of the documentation was something Max did because he wanted to do it and not because it was part of his formal job responsibilities.
- Following the mantra of thinking about how to get rid of something before you commit to working on it long term, eventually Max handed off the documentation ownership to a colleague (Adam Bender).
- “I remember the moment that Adam Bender showed up in the code health group and he started posting and we started having conversations. Immediately I was like ‘if I ever leave this person is my successor.’ It took me maybe 2 weeks of interacting with him to be like, ‘oh, it’s definitely going too be Adam.’” – Max Kanat-Alexander
- Nick suggests succession planning extends beyond being something organizations and managers need to do and can apply to many different things (like technical projects / things that require owners). The technical owner almost needs to be a talent scout and keep watch for people who would make good contributors and future owners.
- “As life goes on and you work at a company and you’re trying to succession plan things, it often still works just like it works for volunteer projects and open source projects. You’re actually looking for the person who is the most passionate and wants to be the most involved. You’re not looking for a manager to appoint somebody your successor. You ideally want to convince a manager that somebody should be your successor.” – Max Kanat-Alexander
- Should someone seeking a technical lead role have mastered the skill of succession planning?
- Max says in the long it is important to master succession planning.
- “The people who succeed you become really important connective tissue for you in your career.” – Max Kanat-Alexander
- Max mentions he continues to stay in touch with Adam, for example. They continue to have a great relationship and help one another. Though Max has fallen out of touch a little bit with people from his time working on the Bugzilla project, he is confident the relationships would continue if he were to work with them again.
- “In the short term, you don’t need to be a master of this. It depends on how much you want to leave the world better than you found it. If you want to build a sandcastle that gets knocked down when you leave, you don’t need to master this skill. If you want to build a cathedral that everybody can walk in and admire and enjoy and love long after you’re gone, you need to master this skill.” – Max Kanat-Alexander, on mastering succession planning
- Nick says the above is legacy building.
30:45 – Becoming a Published Author
- Writing a book seems like a form of legacy building. What was Max’s motivation to become a published author?
- Max isn’t interested in work that he feels does not affect the world in some way. Even if it was part of the world or the impact would be made / felt in the future, that is the type of work he would rather be doing.
- When Max came into programming, he had 10 years of previous IT experience and had seen many different ways in which a computer could break. He did not like it and did not want other people to keep experiencing these problems.
- Max felt the problems he had seen boiled down to complexity, and once he worked as a programmer this was confirmed.
- With Bugzilla they took a code base that was challenging to write in a well structured way and transformed it into a code base on which people enjoyed working. Max wanted to share that with the world.
- Max developed a habit of interviewing programmers and had interviewed probably 100 by the time he wrote his book Code Simplicity.
- The work Max and others had done with Bugzilla was something almost no one else had done. Maybe there was something there he knew about that he could write about and share with others.
- Max had a background in epistemology and enjoyed breaking things down into fundamental principles (i.e. enjoyed it so much it was almost like a hobby).
- “I can take this experience, and I can use it to reduce it down to a set of principles that caused this work to succeed. And I can publish those, and if other people can benefit from those, that would be great.” – Max Kanat-Alexander
- O’Reilly had been wanting to launch a number of programming books like the one Max had written. They accepted his proposal, and Max says they were wonderful to work with.
- How long does a book proposal have to be?
- Max says publishers have a template they use for book proposals that authors can follow.
- Does the book have to be written when you submit the proposal, or can it be thought of like a conference talk (i.e. just write the abstract)?
- You do not need to have a book written to submit a proposal to a publisher, but Max had already written the book by the time he wrote and submitted the proposal.
- Max’s mother was already a published author and helped him with the publishing process.
- For those thinking about writing a book, what would Max recommend be taken into consideration before starting a project like this?
- “Any professional author will tell you that the only way that you’re ever going to get through the process of writing a book is if you love writing books.” – Max Kanat-Alexander
- Max recommends writing a book because you want to do it. And in the technical field you should not expect to make a significant amount of money with a book.
- Max tells us having written a book for O’Reilly is a nice calling card that can be used to establish technical credibility in his case.
- One way to make money is through paid speaking engagements after writing the book. You would also need to figure out how to market your book since publishers usually don’t do much to help.
- “If you have a message that you really want to get out to the world, technical or nontechnical, a book is a great way to do it.” – Max Kanat-Alexander
- Does writing a technical book immediately create pressure to publish a revision because of our changing technology industry? Or should an author try to create something with content that is more evergreen?
- Max mentions this is a constant problem for technical books. Books are often pushed aside for more up to date websites and reference materials.
- Max mentions books are a much better teaching mechanism in technology and can be presented in a cohesive story to the reader. We can “learn it through a system somebody has spent hundreds of hours refining.” The book is a better experience than just reading through online documentation in Max’s opinion.
- Max mentions publishers have consistently tried to make it easier for authors to update books after the initial publishing, adding print on demand options for example to prevent ordering too many physical copies at once.
- “My book was evergreen by its nature. I as a person care much more about writing and creating things that are timeless and will help everybody. It just doesn’t interest me as much to write something very narrow about a specific technology even if I was able to.” – Max Kanat-Alexander
- Nick feels like the evergreen focus and desire to make an impact for the good of the world aligns with the heart of the principal engineer.
Mentioned in the Outro
- The pre-mortem exercise reminds us we can work on something for a time and then be open to working on other interesting problems.
- Succession planning is delegation that gives someone else an opportunity for growth just like participating in a specific project was a growth opportunity for us. Handing off a project is building others up.
Contact the Hosts
- The hosts of Nerd Journey are John White and Nick Korte.
- E-mail: nerdjourneypodcast@gmail.com
- DM us on Twitter/X @NerdJourney
- Connect with John on LinkedIn or DM him on Twitter/X @vJourneyman
- Connect with Nick on LinkedIn or DM him on Twitter/X @NetworkNerd_
10 эпизодов
All episodes
×Добро пожаловать в Player FM!
Player FM сканирует Интернет в поисках высококачественных подкастов, чтобы вы могли наслаждаться ими прямо сейчас. Это лучшее приложение для подкастов, которое работает на Android, iPhone и веб-странице. Зарегистрируйтесь, чтобы синхронизировать подписки на разных устройствах.