There are some other dynamics that are worth mentioning here that can stand in the way of undertaking any of the steps the author recommends. I don't think they touched on any of these things so I'll list some of them out:<p>* Technical staff in an organization feel they have no authority or respect within the organization. This can happen when companies become too sales-driven.<p>* Senior technical staff feel they have no ability to delegate, either because of the previous point or because they don't trust the technical ability of less senior staff.<p>* Those in an organization who <i>do</i> have authority to delegate lack sufficient understanding of priorities or lack technical knowledge.<p>These things highlight the classic balance between technical knowledge and managerial skills. If you don't have people that bring both to the table, you're in for trouble. Not sure if I'd go so far as to say this is <i>what it's all about</i>. However, reading over the author's advice, I thought to myself, "None of this could have happened at some places I've worked." You can come up with a good plan, but if no one will listen to you or take your advice, it's worthless.<p>The author probably was that person who brought what was needed to the table. As such, perhaps the plan is not what ended up mattering so much as having someone who was willing and able to push it through. Also, having the right people from top to bottom. My feeling sometimes is that effective teams occur almost randomly. This might be because organizations rarely have the patience or the resources to assemble them deliberately.
After the MVP is found, then the real work begins in building a company. We all understand that if everything is a priority, then nothing is, but often times, business resources don't. Support wants bugs fixed to keep customers happy and to re-sign. Sales whats features to land their whales. Engineering wants to work off tech debt, refine, and innovate. Etc.. I've found that a formal "Intake" process works wonders. Engineering needs an advocate to take these disparate priorities and refine what, when and how to address. It's really that simple, and that complex. Finding someone to own it. Sometimes it's impossible depending on the Org and personalities involved.
> Be really careful with the yellows: if there is low impact, you might be confusing work for progress. If there is low urgency, you might be overestimaging the value of your work.<p>On the flipside, if only high-urgency projects get done, you end up becoming a 500+ employee IT service provider without a proper Identity and Access Management System (IAM), without a Privileged Access Management system (PAM), a haphazard, ad-hoc secrets store and so on.<p>That's all fine and good for a 10-person company, you can get by like that when you're 100, above 200 maybe it starts to get icky...<p>Yes, I understand that if really nothing progresses, you have to prioritize ruthlessly, but you cannot keep doing only high urgency projects forever.
As someone who have gone through this there is one Achilles heel: appraisals.<p>Unless the management agrees in letter & spirit on prioritisation this is a disaster.<p>When everything is a priority the message from top is "We want best of both worlds" i.e. we want productivity, quality and less complaining.<p>Now you have prioritized in seq: A B C D... The team who has C or D to deliver will have there deliverables pushed by say 6 months. Guess who will be pissed-off with this?<p>But the team accountable for D will say that this is what was agreed and signed on but the top still had those flawed expectations back of their mind.<p>There is also cross-team impact. The product manager who was championing project D now has his/her appraisal in question. He/She will point fingers to the engineering and complain to his/her boss.<p>In other words: Every one in the chain of command has vested interest. Unless they are aligned to large extent its hard to get out of this situation.
No real comment other than damn, what a solid-gold piece of writing and advice. Felt like I was just nodding along to every other sentence. Awesome stuff.<p>I particularly liked breaking down “priority” into the intersection of urgency and impact.
This was a really great article and case study. The problems (and eventual solutions) will be familiar and unsurprising to readers of <i>The Phoenix Project</i>: <a href="https://itrevolution.com/the-phoenix-project/" rel="nofollow">https://itrevolution.com/the-phoenix-project/</a>
Its not tech debt. Its rigidity and fragility.<p>If you only add features, you gain rigidity and fragility. To go fast you must go well.<p>Teams that balance maintainability against features have a competitive advantage and will beat you every time.<p>Going "fast" immediately slows you down. Right then and there. You think you're going fast but you're just fooling yourself. The DevOps Handbook goes into this - you need to spend 20% of the teams time on clean code and maintainability.
> Figuring out the impact and likelihood was something that a product management org would normally devote the bulk of its time towards.<p>Here’s a question: why weren’t they devoting the bulk of their time to it? I’ve been in sessions like this as an engineer and they end up being incredibly productive and informative for everyone as to what the priorities actually are. These aren’t things that engineers are supposed to be doing better than product managers.<p>Why do product orgs _constantly_ fall on their faces when it comes to prioritization? My guess is that the job is highly politics centric and PMs have a hard time getting out of the way of their own aspirations or ego to let the progress take precedence.<p>And no this isn’t trite PM bashing. I would like organizations to re-evaluate the incentive structures of product owners and make them look more like tech stack performance metrics (literally, as in how much is our software getting out of the way of our customers usage and allowing them to be “productive”, whatever that term may mean for the company). Also, give product owners some credit for backing off on new features to make headway for tech debt pay down.
Lots of really good points in here. I have worked at various companies who have struggled after the initial growth. Hubris can take over and we feel the need to over-extend, to sit at the big-boys table, to court the corporates with their fat (but very tight) wallets.<p>I think a common cause is simply fear. There is a lot at stake when you have 50+ employees. Maybe those one or two markets are not big enough to support what we need any more so instead of razor focus and discipline which helps, we try and build everything for everyone and a lot of it is simply wasted effort. We also start having teams so instead of a design decision being taken by the entire management (and can get shouted down), it just gets done because "the design team" regardless of the value it is actually adding or not.<p>In extremis, we see the FANG companies who have so many engineering staff, we can only hypothesize about what most of these people even do for 40 hours per week on massive salaries.
Related to this, and something I should write up in more detail one day: Priority is an order.<p>"High", "Medium", "Low" are not a priority, they are useless.<p>A priority is an ordering of tasks. Once you free yourself from trying to assign labels to the priority then you free stakeholders from worrying about putting things "very high" in case they tread on toes and you enable an honest conversation about where it belongs in the list of tasks or projects that need finishing.<p>After all, no-one ever marks things as "low" priority because they understand it'll never get done, and no-one ever marks things as "high" priority because they worry about the politics of doing so.<p>The result is you get "medium", "Just above medium", "Just above just above medium" and "JAJAM+" in your JIRA. (True story! And a shout out to anyone recognising JAJAM+).
A lot of this is, IMO, very basic - a project is not done until it’s tested and running in prod - I am surprised anywhere with engineers with any experience at all would act otherwise.<p>I don’t think having 40 people work on one thing at once is good at all. It’s like solving scaling by just getting a faster machine. Eventually you may not be able to purchase a machine fast enough to do everything you need to do… And you’re going to have a ton of deadweight.<p>I hate “agile” as practiced but, in theory, it solves this. If you scope out a project well, you should have a general sense for what cross-team dependencies exist and be able to put it on the other team’s plate. You need a decent amount of “trust” but ideally the other team will actually appropriately prioritize it, ie if it takes only two days of work to unblock a project with big business impact, they won’t push back that their Epic Rewrite v3 is too important and maybe they’ll get to it in 6 months.<p>The biggest problem I’ve seen is with bucketing all projects in long planning cycles (3 months, 6 months, 12 months, etc.). Every cross team dependency then takes about one planning cycle to be accomplished, and unexpected additional work/dependencies become nightmares. Also, while “ownership” and specialization are good to an extent, fixing a particular engineer to a specific domain over long intervals almost always causes problems because X% of engineers either aren’t skilled enough to be able to handle owning a domain, leave the team, get delayed, etc. If everybody is fully booked for a long time, there isn’t slack to help them, and it suddenly becomes a Big Deal to assign someone off a domain (because the person struggles for months and messes up a big project, rather than identifying they are messing up after weeks and course-correcting by putting them on something they can be more productive working on), and every project with more than a few people gets delayed because there’s no way to fix one or two engineers on the critical path dropping the ball.<p>What both this article and agile touch on is the benefit of having a flexible planning structure and not over-committing or trying to plan too far in advance. IMO, that is the key to getting shit done. I think you can do that without taking it to the extreme of having only one project in-flight though.
To those who are interviewing these days for a leadership position, the article has details for answering questions related to managing conflicting\multiple priorities
My gut reaction to the title of the post - fire 80% of the managers. Then announce skimpy buyouts for any employee who feels that they won't get enough face time with managers and/or time spent in meetings with the new manager/worker ratio.
Whenever I encounter issues like this:<p>> This routinely caused the team’s focus to change to whatever was the problem of the week (or to solve for whomever was yelling loudest).<p>My mind immediately goes to a lack of leadership and strategy. Why do we have pirates going around from team to team yelling, inventing new feature requests?<p>A lot of what I can read here sounds like someone (goopthink) finally took ownership and seized authority from a leadership team that had rotated out twice and had mostly given up.<p>> we had cycled through two previous heads of product and one head of engineering<p>> In fact, I volunteered for the role because no one wanted to take on a project<p>> The problem is that you need a conflict resolution and effort coordination mechanism<p>> Figuring out the impact and likelihood was something that a product management org would normally devote the bulk of its time towards. Not having that information was one of the failures of process we were dealing with<p>> adjusting the stack rank continued to be a deeply political process even after it was created<p>> “you’re a team of 40 people… surely you can do more than one thing at a time?”<p>> There was no way to scale those conversations. These 1:1s also allowed us to get ahead of influential senior managers who could have been saboteurs if they didn’t buy in.<p>This whole thing screams that there is no acting leadership in the sense of building a team focused on one goal. Allowing many managers to go around and create new business lines, not holding them accountable to drive outcomes but rather just be busy with some new idea. The issue your engineers have is identical to the one going on outside of engineering: no unified mission, nobody willing to say "no" to "some new idea that could totally make us some money and we should just try it and see".<p>It is as if the executive allowed a rabble of random managers to do whatever they wanted like gladiators in a combat arena. It's like CV driven development: "hey let's use kafka and http2 for our internal CRUD app" but instead it is like "hey let's start a new division of the business that has an entirely different workflow but exists in the same industry vertical".<p>The leadership team is absent from every point of this story and things could only improve when they got out of the way or were engineered out with pre-messaging in 1:1s.<p>Good that OP could improve all of this (which in itself is a huge accomplishment, something like 60% of change management efforts fail) but honestly until that L-team is rotated out entirely the problem isn"t solved, those pirates will go back on their habits that created a dysfunctional org full of "yeah but I have a cool idea" leaders. These leaders tend to want all of the decisions and none of the details, making everyone live in their mess. OP dove head-first into the details and this is why they could fix things.