I write this blog for many reasons. One of my goals is to help people learn important, hard-fought lessons without experiencing some of my pain and suffering.
According to Nvidia’s CEO, there are also times when it is important to learn those things yourself.
So when my oldest son Carson started fiddle-faddling around with no-code platforms and told me that no-code application development is the future of software development, I nodded, I smiled, and I did nothing.
I will not bother linking to the random no-code platform that captured his enthusiasm. Instead, I will smugly link you to his public Instagram page. It is even there in the name.
Over the next six months, I listened intently to him describing his no-code journey with some amount of nervousness and fear. It is one thing to hear his opinion on the future of software development and yet another to take prescriptive action and correct him.
Fast-forward two years, and all of that “doing nothing” has paid off. He has started building his APIs and platforms in Python and is running a growing business.
Somewhere along the way of coaching and teaching people, I have learned that it is important for a teacher to know when not to teach.
This is a serious problem for today’s staff engineers and architects. Many talented software developers have gone through that zero-to-one transition for creating software platforms. Many more have learned how to scale up through growth measured in thousands of percent from their current user base.
Their problem is that they need all their lead and senior software engineers to go through the same exercises to learn the necessary patterns to operate at a higher level.
For this to happen, you must let your teams propose systems that might not be ideal or forward-thinking. You can softly give them feedback that there are missing pieces and give them some gentle and subtle clues about bridging the gaps to the solution they will eventually need.
Far too many engineering leaders will do all that work themselves and lose a valuable teaching opportunity. Maybe there is some scarcity mindset or fear involved, or it is simply a lack of forethought on their part, and not in a bad way because they have never needed or wanted to grow one or more engineers to a peer level.
I guess this is just a restatement of the old saying, “You can lead a horse to water, but you cannot make them drink.”
Please make sure your mentees (and yes, your children, too, although technically, this is not a parenting blog) have enough opportunities to learn valuable lessons on their own sometimes.
When the opportunity arises, and they are either successful or not, let them know that this was an intentional opportunity and that they are wiser for it.
The explicit statement afterward is important for creating psychological safety. If your teams know they have some opportunities to grow, including some risk of failure, they will be far more impactful than a team that slips task management tickets while keeping on a narrow track.
