This post is part of the "Viking laws for tech teams" series.
Lack of focus is the single biggest issue a team can face. It usually ranges from "we don't really know what's expected of us" to "we have to work on 10 different things at a time", although the most frequent occurrence is probably "management changed our priorities... again".
This is especially bad when resources are scarce and ain't they always? And how can you keep your team motivated if all they're allowed to do is run in circles, chase one problem after the next and never truly deliver anything but half-baked features or quick and dirty fixes? It's all downhill from there, right? Less productivity, even less achievements, people starting to leave, etc.
"How can my team be so busy and not deliver anything valuable?". Well, that's a fair question and it requires a serious answer, so the first thing to do is to assess the situation. Chopping away at priorities will not fix anything until you understand why the team is underwater.
In a previous company, I asked every team (20 teams or so, about 130 people total) to describe their workload using three simple numbers:
- "Build": % of time spent designing and building new features
- "Maintain": % of time spent maintaining their applications (bug fixing, production support, etc)
- "Waste": % of time spent on something totally unproductive (meetings, endless arguments over specs or the lack thereof, etc)
A large majority of teams came back with 30/40/30. Not a single one scored over 50% on "Build". Several ones scored 50% on "Waste"... Scary.
Another benefit of this simple assessment is that it may help teams realize how bogged down they are. Some people are convinced that they ARE doing the right thing, especially in startups: "Come on! How could we be so busy and not deliver anything valuable?". Well no, you aren't, you're just chasing your own tail and you've been doing it for so long that you can't realize it anymore.
As a manager, reducing waste is the #1 target you need to attack. Do nothing else until all your teams can spend at least 50% building stuff. Once you reach this milestone, you will have improved morale and productivity. And you will have enough oxygen to start looking at what the real priorities are.
In order to reduce waste, you have to understand exactly what it's made of. Dumpster diving is the only way. Sit down with the teams and let them explain. Everyone should speak, not only the project manager / team leader (sometimes, HE is the problem). My experience is that you'll end up hearing the same things in pretty much every team: too many meetings, too much time wasted on coding/re-coding/re-re-coding the same feature because requirements are fuzzy, poor code quality, no documentation, lack of proper tools, intrusive management or key stakeholders (wearing the "business emergency" disguise), too many or too few decisions, etc.
Some problems won't be easily fixed (code quality, etc). Cutting down on meetings can and must be done immediately (yes, I hate meetings). Same thing for decisions: you owe your team clarity and stability. Some calls may be above your pay grade, but there's a lot you can decide on your own, so do it, explain why and don't change your mind every other day: don't worry, Marketing will do it for ya ;)
Anything process-related can be improved in a matter of weeks. It's not rocket science: identify key business users, talk to them, explain Agile, start to practice it with them. Make sure that all technical requests are funneled to a limited number of well-identified people in your team, not to random individual developers. You should take the time to explain why this is a better way, but once you've done it, you also need to make sure that people follow the rule and yes, you need to raise your voice every single time someone doesn't.
Do this right and your "Waste" ratio will go down 10-20% very quickly. For a 5-people time working 5 days a week, that's roughly 3-4 additional man-days every week, and hopefully a slightly more pleasant and productive work environment for everyone.
Now that your teams can actually spend more time on building stuff, let's look at priorities. Chances are there's a long list of requests that Marketing-has-been-asking-for-two-years-but-R&D-hasn't-delivered, which is probably very similar to the list of Stuff-that-R&D-will-never-do-because-it's-all-stupid-shit-and-we-have-no-time-anyway. Fair enough. However, there's a big difference between a to-do list and a project portfolio and an even bigger difference between a project portfolio and a product vision.
Setting priorities starts with a product vision, factoring in functional requirements (aka "features") as well as non-functional requirements (aka "architecture, scalability, cost, etc"). Funny how the former is discussed ad nauseam (yeah, my parents made me study Latin for years) and the latter is usually swept under the proverbial rug.
Ah, I hear you saying that this vision thing is all beyond your control and that I'm not helping you at all here. Well, IS it really beyond your control? Have you discussed it with your fellow engineers/team leads? Have you tried raising your ideas to whoever is in charge? It's worth a shot. On top of that, what about your own scope? What is YOUR plan for the next year or so? How will you improve your APIs, your infrastructure, your agility? Don't expect these questions to be answered by anyone else but your own team.
As a more senior manager, you must build a vision and make sure your teams are aligned. A priority list without a vision is meaningless. Within this vision, making sure that non-functional requirements are properly addressed is of paramount importance. YOU build and run the platform, YOU know what needs to be done under the hood. And don't even bother about other parts of the company not being aligned, you can't do much about it anyway. Take care of your own and hope for the best.
Another important point: building the vision is crucial, but so is leaving the actual action plan to the team. Do not stand in their way, do not micromanage! Your role is to assign teams their own kill zone and let them roam the land. Trust me, your teams know best. If not, you have a hiring problem and
you need to fix it ASAP.
So at this point, you've started to reduce waste and to build your vision. You can now shed a new light on The-Long-List. How valuable is each item? Is it a step towards your vision or not? If not, is there any real business value in building it? In building it right now or 2 months from now? Time to be very critical about this and challenge the business owners!
As you know, Scrum requires User Stories to be ranked by business value. Defining business value may be easy for customer-oriented features. "Once this customer feed is connected to our platform, we expect to make x thousands of dollars every month, so let's launch this project ASAP": ok, that probably makes sense and it's quite easy to benchmark anyway. Most of the time, it's not that obvious: what business value do these new back office pages bring? Increased productivity? More technical debt? You need to find out.
Architecture work is yet another story. You can't stick to "if we don't do this, we're dead in 3 months", especially if you need to prioritize against proper business features. Getting on top on the backlog will require some extra work to explain why this is really critical and why, yes Mr CxO, you may have to trade short term revenue for long-term scalability.
Building the list of priorities is a never-ending process (aka "backlog grooming"). Don't spend 6 months planning: just make sure you have enough work for the next 3-4 weeks and get going! The future is unknown and trying to figure out what needs to be done 6 months from now is totally useless.
And remember: for any given team, there can only be one priority #1. If you have 12 priorities for a sprint/quarter/release, then you have none. The only important question is: "what is the highest-impact feature this team can deliver in the next 2 weeks?".
The viking raid, hit-and-run strategy will show real results in little time. It will also build confidence and momentum: the best sign of success is people not talking about The-Long-List anymore and focusing on The-Next-Step instead.
Attack one target at a time with full force, CRUSH IT, move to the next one quickly, repeat. There is no other way.
That's it for today. Till next time, kick ass, my friends.
I am truly and utterly in love with the Arduino project. There is no simpler and easier way to learn both programming and electronics. Believe me, the smartest gift for a 12-year old kid today is a C beginner book ("Beginning C with Arduino" is a perfect fit: read and approved!), an Arduino starter kit and some guidance to get going. If this had been around 30 years ago, a lot of innocent components would have been spared an untimely death at my n00b hands :D
