After 30+ years as a software developer, I have always struggled with managers needing to know how, what, and when something will be solved or delivered. I have felt the frustration deep down, but often lacked the words to say “Hey if you can’t even say what you want, how do you think I will be able to say when it’s done?”.
Everyone knows that we must manage complex things in steps. This is why we have the agile methods. I still get similar frustration within an agile sprint: what will you do today and how long will it take?
I handled this by thinking “Well, the asker does not understand anything of what I do – so I can just give them a standard answer and come up with a response to make them feel happy and secure”. That is what I usually do. I excuse my behavior with “Software is a new industry and we need new strategies to make it work”.
Today, I talked to a friend who’s not working in software – he is in supply and logistics. He threw in the towel and quit his job. He was frustrated beyond repair with the micro-management from people wanting to know “What are you going to do today – how long will it take?”.
So I understand that this is not a software-specific problem – it’s a management problem.
I heard myself supporting my friend by saying something along these lines:
“Many managers fail to understand that you can plan when and where to play tennis – but you cannot plan every stroke while playing tennis.”
Some things are structured and should be planned in detail. We have the “action” situation where you must make quick decisions based on how things evolve and the adversary’s actions. The result will depend on your talent and experience.
How a good manager reacts
A good manager can distinguish between the “structured things” and the “talent things”.
A good manager never tries to plan talent things. He or she knows it will have no positive effect and will mess things up if your player must follow an action plan.
A good manager also tries to find structure in action to minimize the action situation. This is what we normally call “the business improvement process”. It is not a “talent thing” to show up on time at the right place with the right tools. That is structure. To gain productivity in any business, we must always try to find structural patterns to reduce the unplannable talent situation. However, once we have a talent situation, we should let the talents solve the situation without management from the sidelines.
How MDriven supports structure in development
Using MDriven strategies, we have changed much of the normal software work from being a talent thing to becoming a structured thing (structure in development).
We need talents that understand and express the business in an MDriven model – but that is the main talent we need.
- We do not need talent for implementing C# code, because we made that a structured thing.
- We do not need talent for database schemas, because we made that a structured thing.
- We do not need talent to produce standard frontend UI code in HTML and Javascript, because we made that a structured thing.
- We do not need talent to figure out how to alter a database for a new system version, because we made that a structured thing.
For many, software development is 100% talent.
For MDriven, “talking to the business and modeling solutions” is 100% talent – but, the rest is structure in development.
Once you have structure, you can automate. Once you can automate, you can make things go insanely fast using IT(Information Technology).