If you’ve ever wondered how to attract and retain engineering talent, this post is for you.
Engineers are notoriously difficult to find, screen and onboard. Every candidate who receives your job offer has likely received several others too. And once they do accept, it’s only a matter of time before another company tries to poach them.
It’s time to ask yourself if your developers are really happy, or are your company’s development processes driving them away?
Let’s take a deep dive into the world of Daria the Developer, discussing five common workflow problems, and giving you tips on how to manage developers.
Problem #1: Too Many Meetings
Daria the Developer was a freelance software engineer for a few years, but she recently got a new full-time job. She’ll miss her clients, but she’s looking forward to the stability of full-time employment.
On Daria’s first day, the project manager loads her inbox with calendar invites. Daria’s calendar is now jam-packed with meetings and events. There are hardly any meaningful blocks of time for her to just write code and actually do her work.
Daria befriends another developer, Dave, and asks him if it’s okay that her calendar leaves her so little time to work on her deliverables.
“Yeah, that’s normal,” says Developer Dave. “But during most of these meetings, I just ignore everybody and write code so that I don’t fall behind.”
Daria doesn’t understand why Dave doesn’t just decline the meeting, like a normal person.
“I don’t decline it because you just don’t decline meetings here. They want you sitting in the meeting, no matter how little you contribute to it or how much work you need to do.”
Daria tries writing code in meetings during her first week. However, she notices her manager’s disapproving looks as she tries to ignore everyone to get her work done.
Dave shares some advice with Daria: “Make sure you type quietly, sit in the back, and don’t get TOO in the zone with writing code. You have to act like you’re paying attention.”
The solution: Have less meetings
Developers can get more work done in a single three-hour stretch than in three one-hour stretches. If you fragment their schedules with meetings, they will get less work done. Period.
Organizing your engineers into some type of Agile Workflow where they know what they are doing for longer periods of time such as a 1-2 week period will give them the space they need to focus on their actual work instead of preparing reports and reading meeting notes.
Problem #2: No breaks from Cleanup Duty
Instead, the two developers with the longest tenures at the company are always assigned the fun work to build new features. So Daria figures she must pay her dues before getting any feature work.
While the two longest tenured developers — we’ll call them LTDs — work on features, the other developers are on cleanup duty. Sometimes they do refactors, rewrites, and performance tune-ups, but mostly it’s endless bug fixing.
Eventually, Daria realizes that all the technical debt that the other developers clean up was created by the LTDs. They weren’t the best developers, but they wrote the product’s first lines of code. They know the most about the codebase and are trusted to continue expanding the product. They churn out a lot of mediocre code.
To everybody outside of engineering, the LTDs were rockstar programmers. Their feature work gets all the credit and praise. They’re regularly told that they are “crushing it.” They don’t see the technical debt left behind for the other developers to scrub away.
“It’s the 98/2 rule of this company,” Dave tells Daria. “98% of the credit goes to only 2 developers. They think the rest of us are cost centers.”
The solution: Share both the fun and un-fun work
It’s tempting to always give feature development to your most senior developers and leave cleanup duty to junior developers, but that means your junior developers will never grow. That will encourage junior developers to look for more job opportunities to advance their careers. Additionally, your senior developers are still responsible for cleaning up technical debt, especially that created by themselves.
Invest in your junior developers if you want them to grow into senior developers.
Problem #3: No Respect for the “Iron Triangle”
As the weeks went on, the workload started overwhelming Daria. She saw her work fall behind and her project manager become less and less patient with her.
Daria knew she was performing her best, but the expectations were unfair. The LTDs leave behind a massive wake of gnarly technical debt. Daria, being the newest on the team, failed to sniff out the hairiest of their bugs, and she got stuck with them on the next sprint.
To be proactive, Daria arranged a one-on-one chat with the project manager to reset expectations. She wanted to explain that her bugs take forever to fix because she’s learning a new codebase which she didn’t design. The Other Developers stuck on bug fixing duty agreed that the LTDs didn’t do a great job.
“Daria, you don’t understand how talented those two are as developers,” said the project manager, who hasn’t written a line of code since college, but insisted on defending the LTDs. “I realize you find these bugs challenging, but we need you to finish your work each sprint.”
When she was freelancing, Daria maintained the “Iron Triangle”. Resources, time, and scope are all competing factors. You can have your work done well, or you can have it done quickly, or you can have it done cheaply, and you can pick only two of the three. All of Daria’s clients knew about the iron triangle.
As Daria’s salary is fixed already, Daria offered to trade off either the timeline or the scope of her work. She wanted to find a reasonable compromise.
“Daria, you’re not a freelancer anymore,” says the project manager. “You can’t offer us only two of three. You work for us. You need to give us all three.”
The solution: Be prepared to trade off time or scope
Since compensation is usually fixed, the remaining variables in the iron triangle are scope and time. Software estimates are notoriously difficult and inaccurate, but most teams still estimate software development anyway. When work is underestimated, the developers are the ones to suffer, and it’s not their fault. However, they will still be blamed.
Always know whether time or scope is more important, and then trade off the other.
Problem #4: Writing Fake Glassdoor Reviews to Attract Talent
The engineering manager was stressed out. He was supposed to hire three more developers by the end of the quarter. Despite extending a number of offers, none of the candidates accepted it. A common reason stated for not accepting his job offer was that the Glassdoor reviews were bad.
The engineering manager held a meeting with the engineering team to address the negative Glassdoor reviews. He spoke about how lucky everybody should feel to work at the company, and how they would realize how great their company was if they changed their perspective. The engineering manager even asked everybody to write five-star Glassdoor reviews to make up for the damage done by the recent one.
Daria couldn’t believe what she was hearing. She interjected and said that writing fake reviews isn’t the right way to attract more engineering talent. Everybody should work together to address the problems listed in the Glassdoor reviews, and then the company will not only attract but also retain talent.
The engineering manager apparently told HR about Daria’s opposition to writing fake reviews. Later the same day, HR pulled Daria into a small, uncomfortable conference room that she had never been inside before. Usually HR is very friendly, but today they seemed a little on edge.
“Daria, we heard that you were defending these negative Glassdoor reviews. Can you tell us how you feel about this company?”
Daria is good in delicate situations. She insisting that she misunderstood the situation and that she was already planning on writing a stellar Glassdoor review.
HR’s usual happiness was restored immediately, and they ended the meeting. Daria went back to her desk as if nothing had happened.
The solution: Accept criticism
Employers expect employees to take their criticism with grace. However, few employers are capable of receiving criticism just as gracefully.
Accept criticism, as it’s an opportunity to improve.
Problem #5: Silence Is Rewarded
After a few months, it was performance appraisal season. The VP of Engineering shared his feedback to Daria. Daria’s work output was good, everybody liked her, and it was obvious that she cared about doing well at her job. The only thing they didn’t like was that she wasn’t enough of a team player, and she was difficult to manage at times because of her vocal opposition to several of the company’s processes.
“Daria, if you can adjust your perspective to understand how things work here, I think you could be up for a raise and promotion in the next review cycle.”
Daria was annoyed that he didn’t value her desire to improve company processes, but she definitely wanted a raise and promotion. She decided to keep her mouth shut when she was unhappy.
Six months passed by until the next review cycle. Daria was diligent about biting her tongue and keeping her complaints to herself. It wasn’t easy for her, but she did it. She really wanted that raise and promotion.
During Daria’s next performance review, the VP of Engineering said he was very happy with Daria’s improvement from six months ago.
“You’ve grown so much in the last six months. You’re a great team player, and I love working with you. Your manager loves working with you. Thanks for your hard work!”
He didn’t offer Daria the raise or promotion.
The solution: Reward difficult conversations
At many companies, the tallest blade of grass is the first to get cut. You will condition your developers to stay invisible and keep quiet rather than tell you what they actually think. During lunch, cigarette breaks, and coffee runs, your developers will talk amongst each other about all your company’s problems and wanting to apply to new jobs. If you don’t listen to their complaints, then you won’t hear about them interviewing at your competitors.
When your employees have complaints, be empathetic and use the complaints as feedback for improvement.