Tech Works: How Can I Make Myself More Productive?
From DevOps to platform engineering, the refrain is that we should look to optimize at the team level and higher. A focus on individual productivity leaves tech workers feeling vulnerable, especially during a time of continued layoffs. Plus, it’s proven that happy workers are more productive.
Still, continuous self-improvement is a worthy goal. But it’s almost never about lines of code written. It’s about noticing blockers and when you are doing repeat work that could be automated. It’s about understanding if there’s anything you should learn in order to become more masterful at your craft, and making sure you feel like you’re doing creative, meaningful, problem-solving work.
Then, of course, you need to work in a psychologically safe environment that allows you to broach these topics with your managers.
How can you make yourself more productive? How can you learn to advocate for your own technical and professional growth? By figuring out how to answer these questions as individual knowledge workers and as teams, we can unlock developer productivity, strategically, at scale.
How Can I Keep My Job Interesting?
When we talk about meaningful work, it’s not just because you’re adding value. You’re enjoying work more, too.
“How can I tweak my conflicts to make me the most efficient I can be?” Jamie Tanna, senior software engineer on the engineering productivity team at Elastic, told The New Stack. Tanna has attention-deficit/hyperactivity disorder, or ADHD. As a result, he said, “I’m trying to reduce the amount of steps, the amount of data, I need to do a thing. I’ve been trying to improve the speed that I can deliver.”
With this in mind, Tanna regularly asks himself: Can I script that? Can I write documentation? So next time it’s quicker — for himself or someone else.
This scrutiny of repeat work and toil is one of the pillars of any good platform engineering strategy.
Follow the Rule of Three, Tanna recommended, which contends that it is three times as difficult to create reusable content, so wait until the third time you’ve done the same thing before you try to automate or refactor it.
Source: XKCD, via Creative Commons.
This isn’t just for the more experienced engineer. “As a newer developer in your team or company,” Tanna wrote on the Letters to a New Developer blog, “finding areas to automate and improve is a great opportunity to find out why things are the way they are, as well as illustrating how to improve things.”
He also leverages his own blog as a form of documentation that not only helps him work things out, but lets other people reference that same knowledge. For example, he recently answered for both his future self and his colleagues: How do I list all the repositories we have in our GitHub organization?
In our interview, he also observed that his colleagues who seem the most productive have dedicated time to learning how to automate things and have developed a reflex of documenting context and considering how to work best for their future selves.
They’ve built the habit of, “I’m just going to automate it, or we’re going to write a quick script that just saves me running 10 commands because I can now just run one thing in that loop.”
While working at a previous role at a bank, Tanna similarly benefited from learning about the need to establish explicit steps to the software development life cycle, including requiring everything to be source-controlled and peer-reviewed.
How Can I Help My Colleagues Love Their Jobs?
The next step then is not just automating for yourself, but spreading these developer productivity drivers. This is where CI/CD pipelines and platform engineering strategies come in.
But it’s not always easy to recognize when the problem is just yours or when it’s systemic.
The first step is to have a psychologically safe environment where people can talk freely, like during retrospectives. Repeat complaints — like “the pull requests take ages” — will begin to surface. Or, Tanna said, sometimes it’s “the manager actually understanding what the team is doing, picking up on subtle or not-so-subtle complaints during the week.”
These pain points are then brought to enabling teams, like platform engineering and operations. Just don’t offer a solution, he emphasized, before identifying the problem. Instead, platform engineers should embed with engineering teams to have further conversations and to empathize with their frustrations.
“A lot of people are like ‘Oh, let’s get Backstage. Backstage will solve everything,’” Tanna said, sharing something he commonly hears.
“No, no. What is the problem you’re actually trying to solve? Because there are a multitude of things that you can do without doing Backstage,” referring to the famously complex open source developer portal framework by Spotify.
At The New Stack, we write a lot about the importance of running regular — most often quarterly — developer surveys, but that’s not enough. Continuous improvement relies on open and continuous feedback within and across your engineering teams.
How Can I Continuously Learn — on Company Time?
Of course, this is easier said than done, as you may not feel safe to say what you really think about your work.
“One of the things that is really key in our team is being able to say ‘I’m struggling’ or ‘I need a hand with this,’” Tanna said. “Having worked in teams where we have had pretty toxic managers, that really sucks.”
“I’m white-ish man,” said Tanna, who is of mixed race, “so I am in a very privileged position to be able to flag up and challenge authority but not everyone is. Having a team where you have not only your peers, but your tech lead and your manager and some groups that you can at least talk to share concerns with, is essential.”
Organizations also need to detach the stigma around asking for help.
In the tech industry, it’s accepted that you can change jobs a lot. As Kelsey Hightower put it at Cisco Navigate 2023, it’s OK to stay at a job for just six months, if that’s all it takes for you to learn all you can.
Because there’s always more to learn in this ever-evolving industry. It’s just that tech companies don’t always provide the time or money for continuous learning and development. In fact, perhaps more than any other industry, it celebrates unpaid contributions to open source and studying on your own time.
“It’s super common to hear: ‘I’ll buy this book. I’ll read it at night. Watch this on YouTube,’” Hayley McCarthy, co-founder and CRO of Skiller Whale, a technical coaching company, told The New Stack. “A lot of insidious expectations that you spend your time at home learning because your job is producing code.”
This is ridiculous, she continued, because this learning is usually super valuable to the company you work for. Out-of-hours, unpaid study requirements also contribute to developer burnout and disregard the employee’s caregiving responsibilities, which fall disproportionately on women and other groups minoritized in tech.
“Job ads that include ‘motivated people who learn in their own time’ are just a dog whistle that means, ‘We want young unattached men,’” she said. Furthermore, “It’s really common for people to see training as remedial and an admission of weakness.”
Instead, look for a company that allows you to be vulnerable, McCarthy advised, so you can voice what you need to be successful in a role.
But how can you ask for time to study when teams are already trying to do more with less, and the pressure is on to deliver value to your end customers?
“Take it to the engineering manager and say ‘I want to learn strategically,’” she advised. “I don’t want to just be developing myself for my own career. I want to develop myself for this company.”
Skiller Whale works with teams to identify granular gaps within and then provides personalized training to fill those gaps in one-hour courses. Grouping people with the same gaps across an organization becomes part of that strategic learning.
How Can I Ask for On-the-Job Training?
The biggest hurdle to productivity is not what an individual engineer knows or doesn’t. It is engineering leadership not fostering a culture of learning and collaboration.
Learning and development are often associated with what someone is lacking, and not looked at as an opportunity for growth.
Adding to this, engineering teams — and the business side pushing them to deliver faster — focus too much on the end result and not on optimizing the process. Time and again, we see an overvaluation of the number of lines of code written, underscored last year by consulting giant McKinsey’s developer productivity framework.
Continuous learning is something necessary at all stages of your engineering career.
Catherine Hicks is the author and researcher behind “It’s Like Coding in the Dark: The need for learning cultures within coding teams,” a qualitative research project with 25 full-time engineers and developers. This research focused on three chronological stages of increased understanding of a codebase:
- Onboarding to an unfamiliar codebase
- Adding to that collaborative codebase
- Feedback cycles
In these hourlong interviews, the most frequently mentioned engineering culture event was code reviews. Respondents often spoke of this ritual as focused on criticism. Without consideration of the effort and development that went into it, Hicks wrote, “Code writers feel forced to defend their reputations and output and disguise large portions of their ‘true’ work,” like the problem-solving process and technical decision-making.
This focus on the end result — usually code delivered — and performing well in those often awkward code reviews has engineering teams avoiding “invisible work” altogether. Technical debt and documentation become hot potatoes passed around or dropped entirely. Everyone in this industry acknowledges that docs and debt are important, but engineers habitually put this “glue work” off because it doesn’t lead to career advancement.
How Can I Learn From Other Engineers?
Documentation and coaching are not always something senior developers are taking time to support either.
“Skill development starts off unconsciously incompetent,” said Meri Williams, CTO at Pleo, at this month’s CTO Craft in London. “Then you know that you’re messing up, which means you’ve become consciously incompetent.”
When you become consciously competent, it becomes a new driver — not just for yourself but for your team. The real challenge, they said, is when you eventually become unconsciously competent.
“They are automatically doing the thing right, but when we ask them to train others,” Williams said, “sometimes your most expert engineers are the least able to explain why they do it the way they do.”
This is when that invisible work becomes essential. This work is important but not always part of job descriptions — like documentation writing, coaching and code reviews — but helps onboard people and prevent single points of failure.
This results in a “learning debt,” which Hicks described as “cumulative failure to support learning, created when code writers’ investment in long-term understanding is disincentivized.”
This importance was also underscored in the 2023 DORA metrics, which now include generative culture — grounded in high trust and information flow — as a core metric that is key for high-performing engineering teams.
And explicit values stated by a company don’t usually affect the environment either. In her “Coding in the Dark” study, Hicks wrote: “Overall, participants’ lived experiences of learning looked very different from their workplaces’ stated ideals.”
A culture of continuous learning is directly tied to increased developer productivity. And while it’s important to reflect on your own productivity, only when it becomes an implicit value at all levels of an organization can you unlock success.
“Thinking about your productivity, your skills and the trajectory of your career in the context of the team is really important,” McCarthy said.
“Being a dev is a team sport. You can work as much as you like on your own. You can go to the gym every day. If you’re not operating on your team in the best way, your team’s not going to win.”
