Tons of insights, as usual! This is my favorite line: "The truth is, that developing the soft skills of a great manager is a whole journey unto itself and shouldn’t be taken lightly or neglected." So true.
I have so much time for this Jim. It’s a trap I fell into once. I believe you become a true manager and leader when you realise that the greatest leverage you have is no longer your individual skill but the combined potential of those in your team.
Fully agreed that people management should be incompatible with "day-to-day" coding.
I've made some exceptions to unblock the team when I noticed they were struggling (in terms of time to release and manual mistakes) with the lack of tooling for 3rd party code deployments. But there we're talking about a very specific problem that I was familiar with.
It's not only about "day-to-day" coding, though. It's the same thing with architectural decisions made by freshly appointed Team Leads or Middle Management (and even CTOs) behind closed doors - without consulting their Tech Leads or staff(+) engineers first. Because - even without any experience at that specific company or team - they just felt competent enough ... and how different could it be from ${BIG_COMPANY}? While I appreciate a fresh perspective: Listen first to your team mates who've been working at the coal face for years before you make some fundamental decisions.
Thanks David. Yeah it's fine to maintain some coding skills, and there's always side projects, but the best managers stay present for their team and hopefully love the human aspects of leadership.
I have managed IT teams up to CIO level for over 40 years (amazed as I do the calculation). If you lead engineering teams but have little idea of what the reality of the process you are in trouble. I had a manager on my team several years back who oversaw a team writing SAP interfaces, and my PM was told to plan for roughly two weeks FTE per interface.
I had the Spock eyebrow raise, but I didn’t pursue what I felt were wildly inflated numbers. Then during the development period we had a kerfuffle because one of the interfaces did a delete/add instead of an update and it obliterated a manicured test setup or similar. I raised my eyebrow again, it wasn’t “written in the specification not to do a delete/add”. Eventually the project got done the usual 50% late which I had planned for.
I sat down with OpenAI years later, curious, and asked it to write a remarkably similar interface (SAP R/4 to SAP IBP via CIDS). Had it in 2 seconds. Moving the code among test and deployment environments - 2 seconds.
I had a meeting with a manager a few weeks back. Asked him to use OpenAI to write a pull for ORD02 idoc into an ANSi X.12 EDI 850 order message using JavaScript, and 3 seconds he had it. Told them to wrap the code in comments, failure management, and profiling, 5 seconds. His jaws had dropped. I asked him to write a command to create the integration task. 3 seconds. He was floored, because he managed teams to do similar work and he also accepted the 2 week type response, what he accomplished in 10 seconds.
I recently “coded” to deconstruct a business document and label key entities for a vector data store (RAG) supporting different kind so analyses. I wanted to measure development timings pretending I was naive. In one case as follow-on it took me 45 minutes to develop a PDF visual analysis application. I know that another team took 6 months to try to do the same and had still not completed, and for a different project of similar complexity I saw a quote for 7 figures.
I enjoy writing code like some people enjoy crossword puzzles or knitting, and I have toy projects to keep current in technology.
It will never accept another 2 week estimate for work I can do myself in 10 seconds. My managing the manager managing the engineers instincts were correct even without AI. Hands-on is an extremely valuable assessment cycle of team planning and credibility. It really should be part of the defined planning cycles. I began using CMM models for development in IT around 1994/5 and used to use hands-on IT as part of the estimation process. That was 30 years ago.
There’s something seriously wrong in IT engineering and the house of cards is going to collapse very soon.
Sorry, but that doesn't sound like management so much as someone in management who is advocating strongly for engineers to use chatGPT. If chatGpt is as good aat those tasks as you say it is you're setting up a scenario where your other team members are not really needed. You seem more suited to being a team of one. You are "the smartest guy in the room" who doesn't trust the estimates or instincts of his team--which is exactly who I was writing about 🤷♂️
It’s very strange, it cut off your last sentence. Poor software ironically.
Estimation processes need to be repeatable, defined, accurate, and poor estimation needs to be corrected with identifying points of failure and trials of alternative methods. I don’t use estimation processes based on wrong Fortran-77, Lisp or COBOL, nor do I use estimation processes based on having no libraries or IDE tools.
got-4o contains a stunning library of code, algorithms, library contents and API semantics from complete ingestion of everything from GitHub to endless JavaScript in web pages to ERP training systems which are accessible instantly on demand; it goes far beyond ordinary IDE and “copilot”. I expect teams to be using best known methods.
Good managers in factories “walk the floor” and talk to the teams building, and roll up their sleeves when there are production issues. Chefs are in the kitchen for a feeling of what’s going on as well as talking to patrons. Shop owners walk the floor, clothing designers know the people working in the atelier and make their concerns their own.
Software is no different.
“Team of one” is ludicrous, and meant to be a kind of slur, but what it seems to reveal is that you don’t understand what good managers do. They clear away issues for their teams to do incredibly well.
Bad technique, poor estimation, shitty tools and unquestioning acceptance of poor skills is poor management.
To me, rolling up your sleeves means occassionally being down in the trenches with your team when they have a deadline or you are short-staffed and need to work late, when the pressure is really high and you as the leader can help bear the load. But rolling up your sleeve because you know better than everyone else, or only you know how to solve a problem and you want to prove it just sends the message that you're not willing to trust others to learn and grow. You're not leading so much as dictating.
Micromanagement and asking engineers to prove they can be replaced by GIGO robots seems like pretty bad management to me. How can morale possibly be high among team members who are constantly told they are not good enough and need to do things your way and to use robot toys to achieve anything because it has to be done in a matter of seconds according to you?
Tons of insights, as usual! This is my favorite line: "The truth is, that developing the soft skills of a great manager is a whole journey unto itself and shouldn’t be taken lightly or neglected." So true.
Thanks Julie!
I have so much time for this Jim. It’s a trap I fell into once. I believe you become a true manager and leader when you realise that the greatest leverage you have is no longer your individual skill but the combined potential of those in your team.
Fully agreed that people management should be incompatible with "day-to-day" coding.
I've made some exceptions to unblock the team when I noticed they were struggling (in terms of time to release and manual mistakes) with the lack of tooling for 3rd party code deployments. But there we're talking about a very specific problem that I was familiar with.
It's not only about "day-to-day" coding, though. It's the same thing with architectural decisions made by freshly appointed Team Leads or Middle Management (and even CTOs) behind closed doors - without consulting their Tech Leads or staff(+) engineers first. Because - even without any experience at that specific company or team - they just felt competent enough ... and how different could it be from ${BIG_COMPANY}? While I appreciate a fresh perspective: Listen first to your team mates who've been working at the coal face for years before you make some fundamental decisions.
Fantastic information, Jim. I enjoyed this one. I agree with you. I don’t think you can effectively be a people leader if you’re coding a lot.
Thanks David. Yeah it's fine to maintain some coding skills, and there's always side projects, but the best managers stay present for their team and hopefully love the human aspects of leadership.
I’ll tell you something peculiar.
I have managed IT teams up to CIO level for over 40 years (amazed as I do the calculation). If you lead engineering teams but have little idea of what the reality of the process you are in trouble. I had a manager on my team several years back who oversaw a team writing SAP interfaces, and my PM was told to plan for roughly two weeks FTE per interface.
I had the Spock eyebrow raise, but I didn’t pursue what I felt were wildly inflated numbers. Then during the development period we had a kerfuffle because one of the interfaces did a delete/add instead of an update and it obliterated a manicured test setup or similar. I raised my eyebrow again, it wasn’t “written in the specification not to do a delete/add”. Eventually the project got done the usual 50% late which I had planned for.
I sat down with OpenAI years later, curious, and asked it to write a remarkably similar interface (SAP R/4 to SAP IBP via CIDS). Had it in 2 seconds. Moving the code among test and deployment environments - 2 seconds.
I had a meeting with a manager a few weeks back. Asked him to use OpenAI to write a pull for ORD02 idoc into an ANSi X.12 EDI 850 order message using JavaScript, and 3 seconds he had it. Told them to wrap the code in comments, failure management, and profiling, 5 seconds. His jaws had dropped. I asked him to write a command to create the integration task. 3 seconds. He was floored, because he managed teams to do similar work and he also accepted the 2 week type response, what he accomplished in 10 seconds.
I recently “coded” to deconstruct a business document and label key entities for a vector data store (RAG) supporting different kind so analyses. I wanted to measure development timings pretending I was naive. In one case as follow-on it took me 45 minutes to develop a PDF visual analysis application. I know that another team took 6 months to try to do the same and had still not completed, and for a different project of similar complexity I saw a quote for 7 figures.
I enjoy writing code like some people enjoy crossword puzzles or knitting, and I have toy projects to keep current in technology.
It will never accept another 2 week estimate for work I can do myself in 10 seconds. My managing the manager managing the engineers instincts were correct even without AI. Hands-on is an extremely valuable assessment cycle of team planning and credibility. It really should be part of the defined planning cycles. I began using CMM models for development in IT around 1994/5 and used to use hands-on IT as part of the estimation process. That was 30 years ago.
There’s something seriously wrong in IT engineering and the house of cards is going to collapse very soon.
An observation.
Sorry, but that doesn't sound like management so much as someone in management who is advocating strongly for engineers to use chatGPT. If chatGpt is as good aat those tasks as you say it is you're setting up a scenario where your other team members are not really needed. You seem more suited to being a team of one. You are "the smartest guy in the room" who doesn't trust the estimates or instincts of his team--which is exactly who I was writing about 🤷♂️
It’s very strange, it cut off your last sentence. Poor software ironically.
Estimation processes need to be repeatable, defined, accurate, and poor estimation needs to be corrected with identifying points of failure and trials of alternative methods. I don’t use estimation processes based on wrong Fortran-77, Lisp or COBOL, nor do I use estimation processes based on having no libraries or IDE tools.
got-4o contains a stunning library of code, algorithms, library contents and API semantics from complete ingestion of everything from GitHub to endless JavaScript in web pages to ERP training systems which are accessible instantly on demand; it goes far beyond ordinary IDE and “copilot”. I expect teams to be using best known methods.
Good managers in factories “walk the floor” and talk to the teams building, and roll up their sleeves when there are production issues. Chefs are in the kitchen for a feeling of what’s going on as well as talking to patrons. Shop owners walk the floor, clothing designers know the people working in the atelier and make their concerns their own.
Software is no different.
“Team of one” is ludicrous, and meant to be a kind of slur, but what it seems to reveal is that you don’t understand what good managers do. They clear away issues for their teams to do incredibly well.
Bad technique, poor estimation, shitty tools and unquestioning acceptance of poor skills is poor management.
To me, rolling up your sleeves means occassionally being down in the trenches with your team when they have a deadline or you are short-staffed and need to work late, when the pressure is really high and you as the leader can help bear the load. But rolling up your sleeve because you know better than everyone else, or only you know how to solve a problem and you want to prove it just sends the message that you're not willing to trust others to learn and grow. You're not leading so much as dictating.
Micromanagement and asking engineers to prove they can be replaced by GIGO robots seems like pretty bad management to me. How can morale possibly be high among team members who are constantly told they are not good enough and need to do things your way and to use robot toys to achieve anything because it has to be done in a matter of seconds according to you?