As an: engineer at a large tech company how might the engineering work I propose get implemented?
Individual Contributor (IC) Engineers are the experts of the systems they develop and operate. They often propose what I’m calling IC Initiatives: units of work that take typically one to four weeks to complete, generally focused on improving the technical quality of the system. Examples include upgrading major versions of languages and libraries, significant code refactoring to reduce complexity, automating a previously manual task, or changes to allow the adoption of new software delivery techniques such as feature flags and continuous deployment.
In my experience, and that of other engineers which I’ve learned through conversation, is that this sort of work rarely gets prioritised. An engineer proposes the work, describes the value of it, and then it doesn’t get picked up. Feature development or the latest interrupts always take precedent. Is this bad? For a short time, no, but systems start to rust and engineers see their feedback is ignored and stop giving it.
In Communities of Practice at my work this situation is often framed as the lack of engineering empowerment. Discourse tends towards ’engineers need to communicate better’, ‘product owners need to listen to the engineers’, or ’engineering managers need to make more space for technical work’. These are contributing factors, but they reductively limit the frame of what an Engineer can do to improve the situation.
What are some frames and techniques an engineer can do to promote and get the initiatives they propose adopted? Don’t propose one initiative, propose five.
There are an incredible number of improvements, opportunities, tough technical problems, and promotion-pack-worthy initiatives that anyone can propose at BigTech. Any one of these might not proceed for any reason:
- It’s too complex
- The team has to meet a deadline
- It will take too long
- The team did something like it last year
- Another team should do it
- The team just finished completed a different IC Initiative
- It’s not the right time to do it
- The team has to focus on product delivery
- This isn’t a problem now, we can do it in a year
My model of whether work gets picked up is a combination of value and context. Where
Value factors in benefit and cost to the customer, organisation, and team.
Context is timing, luck, trust in individuals and teams involved, and aesthetics of the work.
IC initiatives compete with the known, well scoped, and highly valuable work that already exists in the backlog. When looking at value alone, IC initiatives generally lose against that in the backlog. Value for IC initiatives must be clear, but Context is where they can win.
That story in the news about the Equifax hack, the blog the CTO shared around continuous delivery, the recent whitepaper from the Architecture team that illustrated unowned code and the risks of it, the new tool announced by the Security team which automates dependency checking, the recent outage caused by lack of automated tests. Those examples are just what’s in the public organisational zeitgeist, but there’s also hidden context. Managers are asked questions by their managers, Staff Engineers are working on cross-cutting concerns, and unannounced initiatives are underway across the company. Talk to everyone, find out what’s on their plate and understand their context.
In my experience context changes faster than value. Engineers proposing a single IC Initiative have planted a flag in the ground and are waiting for the wind to change. Having multiple IC Initiatives on the backburner allows you to react to the organisational context. Has the context changed to security patching? Great, put forward the proposal on implementing automated patch management on your systems.
The basics still apply. Ensure the Value of the Initiative is clear, and that work is broken down into small parts. Smaller bits of work that can be delivered iteratively is more palatable. Are there risks or non-time costs involved in the Initiative? Present these up front and mitigate where possible.
Context is the lever to move valuable IC Initiatives from plan into practice.