Technical Excellence Programs
Hey everyone!
I hope you’re feeling well and rested. Take care as always, and learn to set boundaries!
These last few weeks have been of peaks and valleys concerning stress levels; it’s a very tiring situation to be up one moment and down another. Anyhow, I hope you’re not dealing with the same thing.
Was this forwarded to you? You can subscribe here!
These past few weeks, I’ve been thinking about technical programs, planning, and executions. I don’t think I have any answers, mostly observations and perhaps more questions than anything else. These observations come from seeing understaffed teams try to keep accomplishing the same roadmaps as in previous years.
Or they are trying to improve their systems to avoid burning out people long-term due to the vast amount of work related to keeping the lights on (KTLO).
Selling the Idea
Programs always stem from ideas to improve the product or the technical system. In the technical case, they might come from team discussions retrospectives, or you might have a lead or architect (or you’re that person) thinking about the product's future and technical system.
Regardless of where the idea comes from, it sometimes needs to be sold to the business or product organization.
Selling ideas for technical roadmaps is interesting because, in some cases, we might want to improve something by giving “maintenance” to a system or rewriting some piece of it, etc. In some cases, these ideas are about reducing short- or long-term costs, but for some organizations, it might be hard to grasp how that weighs against things that would bring more revenue, customers, etc.
Always be aware of your organization's priorities, and frame your ideas under those values! Alignment with business is generally how you get your ideas forward.
Planning, Milestones
Once you’re a line item in some roadmap spreadsheet, we start thinking about decomposing the problem into milestones to deliver value. This is one thing I see new leads or managers miss often.
Why? In some cases, they might be overwhelmed by the scope of the project or the ambiguity of what needs to be done. In other cases, people don’t limit the solution, and scope creep makes the project scope so enormous that the whole thing becomes risky to deliver.
In cases without clarity, you might want to research either source code, technologies, or who’s doing something similar in another part of the organization.
In other cases, people think something like “we should upgrade library X to the latest version,” we need to update the runtime, switch packaging method, move to Kubernetes, etc. For those cases, you might want to reduce the amount people required to make a decision and draw a line in the sand with a scope that is deliverable in a reasonable amount of time. Generally, large companies expect deliveries in quarters or less.
Once you have a scope, consider milestones to deliver things as early and often as possible. I’ve seen people say, “We broke this down,” but then they’ll only know it works once all the pieces are in place and everything “is done.” This is a risky approach and provides very low visibility until it’s too late to understand that you’re past promised dates.
Break things down to keep a constant stream of deliveries throughout your promised time frame (e.g., quarter).
Execution
Execution of a program is where teams need more teammates available to take on the work. Sometimes, one of the developers might need to choose between new features or these “tech excellence” programs, which is a tough place to be from a planning perspective.
Not having a set amount of people assigned makes it very hard to have a consistent pace towards your goal.
Teams need to have the milestones or pieces split so that we can delegate across multiple groups. Sometimes, I see managers need help with delegation to other groups. They feel that they’re responsible for delivering the whole thing.
In cases where the whole org is responsible for delivery, keeping all accountable is the job of the owner, as well as the leadership of the organization.
Keeping Momentum
With few people, you might need to juggle looking ahead and trying to secure a teammate time for some week or keep sending and asking for updates. Sync with leadership to request help, etc.
Sending a weekly update or daily even helps keep this top of mind of teammates and also makes people aware of where they should prioritize these tasks on their backlog.
In general, with a low count of people, it’s hard, and sometimes you’ll have to accept that there will be no progress for some time (one, two, or three weeks, etc).
Risks
As usual, risks in these types of projects are a lot! But we always have to keep ahead; that will help run it smoothly or maintain a constant pace.
Risks are like securing time from a teammate, syncing with another team to get help, unblocking other teammates, being resourceful and scrappy with managers, building trust, and doing even smaller tasks, like a single-day thing.
As usual, don’t try to solve everything yourself! Leadership is there to help, so learn to raise your hand or describe what specific help you need in your regular updates.
Your turn!
How do you handle technical excellence programs? Are you sufficiently staffed to take them on? Are you able to keep momentum after a few months have gone by? Do you get access to a product or program manager to help out? Let me know by replying to this email.
Happy coding!
Things I discovered in the past week
- John Cutler, about the return on investment, he never misses! I would suggest subscribing to his newsletter.
- Lethain blog with another excellent piece on Engineering leadership and how to develop your style!
website | twitter | github | linkedin | mastodon | among others