2 min min read - October 1, 2014
Probably I won’t find an answer to given question, as many cases may differ. Anyhow I hope this article will trigger proper discussion in your team about healthy boundaries and delegation.
You can find hundreds of articles about problems with delegation and micromanagement. Very often experts point out that managers stick too close to production process and spoil it by random and not organized influence. But I have a feeling that political correctness doesn’t allow us to raise one important question. Is everyone involved in shaping the product able to understand given questions and challenges? Does being experienced in non-technical areas help in shaping the outcome.
Of course yes, it does. But not like we used to think about it. I wouldn’t like to refer to any specific project of my friends, or mine as this topic is very generic. If you watched any of Kitchen Nightmares by Gordon Ramsay, you remember common cases when owner without proper cooking knowledge made hell in the kitchen. Gordon had very simple solution expressed by four words starting with F, T, F and O. Did Gordon ever asked owner to not try dishes as customer? Did he ever refuse owner to say opinion about look of the place. Not really. Did he allow owner to cook, hardly ever.
We need to remember that we all have valid skills and experience. But often we waste (yes waste time) on describing things over listeners’ abilities. I wouldn’t even try to understand way how neurons work. If I do software for neurologist I base on schemas given – I don’t question. That is not my area. But I don’t ask him about data security, user interface or colors. I will observe him using the app. I will measure his engagement. I wouldn’t ask, because we speak two different languages.
My opinion? Take all non-technical people out of delivery. Ask them for goals, if they own project (not for solutions). And review how they use the result. Don’t ask, observe and measure. What’s your opinion?
I have been working in IT for about 10 years and worked with plenty of great developers, architects and designers. Many of those people formed my current skills and way of thinking. They also have shown me the biggest obstacles for developer to grow. Funny enough during the years I started to see, that few colleagues who didn’t fight those issues ran into kind of developer limbo. More successful have made one product/project and do it for years alone. Others wonder from team to team and always end up leaving because conflicts. Despite anyhow character and cultural challenges, there were always some habits that refrained them from breaking that circle of madness:… read more…
3 min min read - September 29, 2014