Three kinds of turpetine.
As an executive, writing code is never the highest impact thing I can do. Selecting the right problems for the team to work on, hiring the right people, and managing escalations are all much more valuable, and problems that I have a unique advantage to solve as an executive. However, optimizing for efficiency is always risky when you don’t understand why a process exists.
There’s a meme that many executives don’t understand the actual product they are responsible for, perhaps never having used it, and I think that meme is both misleading and also surprisingly accurate. I’ve never worked with an executive who’s been at a company more than a year who wholesail doesn’t understand their product, but I have worked many who don’t understand the details of how their software works. Similarly, I’ve worked with many who don’t understand the details of how software development works at their company.
…
However, high-quality problem selection gets increasingly difficult as you get further away from the details of your technology. This is especially true in a fast growing organization with unreasonable software, where reasoning about the software accurately rarely leads to accurate conclusions.
/coding-at-work/
3 kinds of understanding:
- domain – gotta learn that. Understand users and customers deeply via data and discussion
- architecture – how software is designed. easy/hard depending on whether you have reasonable or unreasonable software. relentless, unending migration towards reasonable software
- process – how do things happen? you can learn by doing, albeit easier when people respond to you :-). Actually get in details and do the things yourself, on an ongoing basis