In any moderately complex software product in a medium-to-large company, you're talking about teams, not just a singular team. You want folks to have as much freedom as possible, but at the same time, there needs to be a high degree of coordination and planning between teams, especially when it comes to software. You want to "change the balloon from red to blue" to use an example from the article? But what about the marketing team that already sent out the teaser video with the red balloon?
Honestly, one of the most demoralizing things I've seen affect software teams is not micromanagement, but what I call "whiplash" management, where priorities and directions change so frequently that teams feel like they have to spend more time replanning that actually building outputs.
Seems to me that the best way to combat it is to provide leadership with as much feedback as possible from both internal and external sources so they can evaluate options rather than jumping to the first "solution" or "next best thing" they think of.
What do you think?
- pretty complete domain knowledge
- all the relevant information
- to not conflict with decisions being taken elsewhere.
As an obvious example, if you task the team who "own" the login page with an outcome of "50% fewer account lock-outs due to forgotten password", there are good ways and bad ways of achieving that outcome. Crucially, do they have enough knowledge / information / decision-making power to decide that a "reset password link sent by email" type feature is OK from a security perspective? That it won't conflict with the registration team's outcome to increase sign-ups (because they're thinking of doing away with requesting email)? What about an opportunity to allow people to sign-in on the web via the app (via QR code, a la many challenger banks) - this team doesn't "own" the app, how do they do that?
Having small teams is wonderful if the teams can be autonomous. If they suddenly need lots of outside co-ordination and discussion to ensure that their deliverables for outcomes don't tread on the toes of other teams, then they're coupled up again like a larger team and effectively lose the autonomy.
The role of management is exactly to provide this autonomy by pre-supplying the co-ordination and ensuring the work requested from the various teams makes sense as a cohesive whole. You generally can't delegate high-level business outcomes like "increase profits by 10%" to a single team, or multiple teams, without that level of agreement or co-ordination.
There is a reason for management by output: it's honest. The manager decides what the output is, which is what's going to happen anyway, and if the direct labor made that happen, then the outcome is on the management, not the direct labor.
Pretending otherwise, will not result in the direct labor determining how to get to the outcome, it will just result in:
1) determine, through an elaborate game of corporate charades, what output I want, and pretend you chose that
2) deliver that output
3) insure that output results in the correct outcome
Managing by output is far more honest, and only judges the employee by what they are in fact actually allowed to have any control over.
Tell dev teams 'why' and they complain about not having 'what.' tell them 'what' and they complain about not having 'how.' tell them 'how' and they complain about not having 'what' and tell you to mind your own business.
The problem is that it's too much for one person to define. i think the solution is having technical ux people (yikes) work on the 'how' with the devs and users.
And if you don't have a good why, no amount of design or development will save you.
To me this is why OKRs work more effectively (so long as you take the metrics with a pinch of salt) than traditional roadmaps. You're focused on achieving a business state rather than chasing a set of arbitrary deadlines for "Feature X". Smart people suddenly have space to use their brains.
In fact typical product roadmaps end up a source of toxicity in most organisations I've worked in...
- Out-of-date the moment they are published.
- Tying down product managers with moving little boxes around PowerPoint; people who'd be better off getting out of the building and talking to customers or working with engineers
- Causing a blame culture around missed deadlines, sapping everyone's morale
- Needing multiple versions depending on the audience; low granularity for top level management, high granularity for engineers, carefully worded for customers and users e.g. "Add ad tracker" or "Fix bug causing data loss" may not be what you want sales people to present
- Always subject to (mis)interpretation
- Based on wild estimates of how long things will take 3 quarters ahead through the year
- Too focused on shiny deliverables and ignoring things like "We need to have to this quarter for re-writing a major component that blocks everything else"
- Often unread or poorly reviewed
- Bad at visualising dependencies between things being worked on
- A source of silliness like "Why are wasting time doing X when we know we need to be doing Y?" ... "Because it's on the roadmap"
... and probably loads more.
If a tactic isn't actionable, then it might have several substrategies. This can map well to an org structure.
1) We are assuming dev teams want to do the extra work of defining what to make, or put another way, are happy with being responsible for it. Also for the people that do think that way, it assumes their teammates are likewise motivated.
2) In my experience, developers are not people-oriented and therefore will naturally resist collaboration at some level, especially with with customers.
3) Does any developer really think their time is well-spent participating in investigatory market research, advocated in this presentation?
Disclaimer: I am a developer. I can get enthused about these approaches, but often gravitate back to the hermit-like mentality that drove me to programming in the first place. I can't help but think that a lot of this non-programming activity would be better served if organisations today just embraced the Business Analyst role more.
The best developers I've worked with have proactively requested to be involved in user research and feedback sessions. They want to know the customer. They understand why they are building what they are building, and provide valuable feedback when they encounter issues during development that weren't accounted for during the design phase. They behave as partners rather than line workers. Anecdotally, these have been the developers that are most respected internally and promoted to leadership as well.