3 ms·
This is an interesting article, but I do not agree with a number of its points. On the main one: servant leaders are not required; they work on some teams, and
by ptero 8y ago
This is an interesting article, but I do not agree with a number of its points. On the main one: servant leaders are not required; they work on some teams, and this is great. But other teams need a strong leader who knows what he wants and directs the execution. And team members are often OK with it when probed -- "he is an asshole, but sharp and gets things done. We rarely work long hours and are respected by senior management for delivering. I am not changing teams".
Many topics follow a theme: leave us developers alone, we are working. Do not negotiate with our estimates, etc.. This may not work in the real world. When a project involves several teams (one builds hardware, second UI, third computation, fourth preps algorithms and tools for analysis, etc.), there are common test events and mid-course corrections. Blowing past schedule affects others -- canceling a test event for a geographically distributed team is expensive.
In such cases when the developer says that they need an extra 2 months do X, "what can you do in 2 weeks" is a reasonable counter question. It may be an unreliable junk and those 2 weeks of work will have to be tossed and redone, but this may still be the best option in the grand scheme of things. Here developers often dig in and start throwing articles and links on technical debt; making them finally write a quick, limited capability prototype is a MAJOR effort. My 2c.
- humanrebar 8y ago> ...making them finally write a quick, limited capability prototype is a MAJOR effort. Fair, but why is that. I've been talked into just-for-now solutions over and over in my career. Rarely does the org actually go back and clean it up in a timely fashion. It's possible, regardless of servantness, that leaders don't have a good reputation for following through and finishing things.
- AndrewUnmuted 8y agoThe market doesn't any longer condone leadership where finishing and following through matter the most. We're in a race to the bottom as we barrel ever further down an economic rabbit hole. I can't, therefore, blame "leaders" for the conditions you correctly point out.
- dfjliasjg 8y agoThat is 100% a leadership problem. There is a cult around Minimum Viable Product but that can be mitigated by technical leaders who are willing to stonewall the business leaders on unit tests and documentation. I don't even bother telling them that testing and documentation are separate tasks and roll it into development time.
- hobs 8y agoRarely? Try never. Then its now your job to support the mess from now on. You can call me a recalcitrant developer if you want, but its like asking "Oh, well what bridge can you build in two weeks?" Sometimes you should build a raft instead of trying to pretend you can build major infrastructure in no time flat.
- andyidsinga 8y agoThe raft metaphor is a good one. I've often used a similar one: "first we build a go-kart. It's a cool little go-kart, and will help us overcome certain barriers to adoption with a certain kind of customer for whom a go-kart meets their needs." I find that the main arguments against the raft/go-kart strategy (from the the business leader) are along the lines of "we need a Ferrari man! not a go-kart; our target customers won't even consider a go-kart". Its at this point that an very important discussion has to be had about how customer development and barriers to adoption are overcome. BTW - the applies to both new product development and features for existing products. This is not easy. This discussion must include "Look, the experts who are building this are telling you ________ and ________; you can choose to accept that or continue down a path of uncertainty and investigation until they come up with another set of recommendations...". The goal for the technical leader is to setup a set of options for the business leaders to choose - none of which are allowed to be chaos. If chaos is the norm, either the business leader or technical leader will be removed - or the business will likely fail due to that chaos and its effects on the team.
- s73v3r_ 8y agoI don't know if this is a good time in history to be referring to "experts".
- andyidsinga 8y agoHmmm. I understand why you say that - alas, yes in the political environment experts are cast negatively. In the above context, I'm talking about the people we hire to do the things that need to get done to move a business forward - we hire them for their expertise and skills. When I'm talking about the people I've hired - to management, peers in other groups etc - I refer to them as "the experts who are building the ________, tasked with accomplishing ________" and so on. It reminds people that they're here for a reason - to contibute ..and not here by random coincidence.
- gwbas1c 8y agoThere's a big difference between developing yet another e-commerce storefront versus something that requires legitimate research and development. Far too many confuse the two, and the discipline and flexibility needed for both.
- rednerrus 8y agoServant Leadership doesn’t mean you don’t hold your team accountable for their deliverables.