Consistency is the Lazy Manager's Trap
Ok, I clickbaited a bit, I should have said “too much consistency” or “consistency in the wrong place”, but let me explain:
The above is 100% correct thinking, and consistency is everything … if you're in charge of a sausage factory and your job is to produce as many identical sausages as fast and as cheap as possible. And that's not bad in itself in any way, and I'm using "sausage factory" for dramatic effect, but you get the idea: repeatable, cvasi-commoditized services or products.
And this is not the topic for today, but I also want to tie this to the recent discussions and alarms about the dangers facing the Romanian IT market. Are you an IT Manager/Leader and is your main concern consistency and efficiency? Ask yourself then, are you sure you’re not the manager for an IT sausage factory? How do you compete? Produce the same thing 2% faster and cheaper than the next guy, or offer something different? Something different doesn't come from an obsession with "consistency".
But come on Andrei, Consistency ain’t bad! And what would you replace it with?
I wouldn’t replace it with anything, because?consistency is great at what it is good for: for the repeatable, non innovative, commoditized parts of your business. It's excellent there. ?
But if you want to be a successful business, a successful department, a successful team at more than just running an efficient sausage factory, then you also need: Creativity, Innovation, Experimentation, so you have a chance to once in a while come up with a new idea and to provide some value to your clients that is not so commoditized that the only reason you won the deal was being 7% cheaper.?
领英推荐
And if you want this, consistency in the wrong places becomes your enemy.
Because if you want this, then you might have to let Jane and Mike work in a team in a way in which is not your “standard” team structure. And they might not want to follow your “standard” processes. And one of them might want to work on a Mac and the other one on some other thingy and none of them are according to your “IT Policy”. And your IT guy might complain that he’s got to now maintain two types of anti viruses: fire him. Just kidding, teach them to see things in a new way. Or fire them.?
And over there, Jeff, Isabela and Danny might form another team and want to do all that, and more, in an entirely different way, their way, whatever works for them at that point in time.?
And you might have 4, 5, 10, 15 such small teams (good teams = small teams) working on different projects, for different clients, individually or collaborating, solving non standard problems in non standard ways, delivering non-commoditized valued, that you can send big fat invoices for.?
And you won’t be able to compare these teams between them, you won’t be able to collect it all together in one big backlog with a normalized story point (take that, SAFe!), you won’t be able to “centralize your metrics” in one neat, cute dashboard.
And what kind of a manager will you be then?
A damn good one.
Software Development Manager at Gemini CAD Systems
5 个月While having the same dev toolchain is important across teams (i.e. git, Jira, Jenkins, whatever... ) and usage of Agile good practices and ceremonies, it's equally important to let each (small) team self organize. Scrum or Kanban, sizing or effort estimation, different story points 'values', split or don't split tasks at the end of the sprint... let them decide. I often see them as small experiments and see how they evolve inside each team. Some will work fine and some won't, but you can always bring the teams together for knowledge sharing and what worked will inspire the other teams.