Over the past 4 months, we’ve had the pleasure of speaking with 100+ engineering managers over a one-on-one 30-minute call. If you were a part of that – thank you!
If not, we are always happy to speak with our users 🙂
Below are 8 (relatively) random findings that we’d like to share today:
- Nobody likes Jira’s settings
- Juniors want structured one-on-one’s
- Handwritten notes are surprisingly popular
- Your best source of learning are other engineering managers
- Developers need more soft skills
- Documentation is on everyone’s mind, few do it
- 50/50 on coding versus managing
- Teach your developer’s product skills if low on resources
- A bonus finding
1. Nobody likes Jira’s settings
Ever found yourself trying to get more out of Jira but were left either giving up early or investing tens of hours to get something in the Jira settings done? Well, you’re not alone.
We can’t present the exact data, but this was a very common trend across what was putting people off Jira, as well as a major “improvement” in their workflows if they do get around to it.
In general, engineering managers love to improve things, even if they’re not broken. But the Jira settings are such a nightmare, that this does not apply to the rule. When things do get fixed is when an engineering manager joins a new company and wants to quickly “improve things” to leave an impression.
Pro (sneaky) tip: got something you could be improving in Jira and a new engineering manager joining your organization soon? Suggest that as their onboarding ticket.
2. Juniors want structured one-on-one’s
Not everyone we spoke to would do regular one-on-one’s with their developers and the ones who do, differed in their opinions on how to do it well.
Based on our findings and insights of the 100 calls, there’s a very basic, common-sense rule that everyone can apply: the more senior the developer, the less structured the one-on-one.
We heard of anecdotes of some EM’s doing their one-on-one with senior developers over walks, in the pub or over a coffee, etc. These one-on-one’s are much more about keeping and engaging the developer, than providing feedback.
But the mistake many organizations and engineering managers seem to make is applying a general rule to all their developers. This rule usually comes out of their preferences, instead of what’s required.
Many would never consider doing structured, formal one-on-one’s, but we found that the ones who do, find it almost irreplaceable with anything else for junior developers. They reported it as a necessity and almost a demand from juniors.
Juniors (and generally younger people), usually on one of their first roles, are almost expecting formal feedback due to their lack of experience and perhaps some insecurity. They want to know how they are doing, preferably detailed feedback with stats and direct recommendations.
Manage one-on-one’s with Zumvie
Apart from onboarding, our goal at Zumvie is to help engineering managers manage their ongoing one-on-ones with the developers.
The main things we’re aiming to solve:
- Replace existing sheets/notepads with specially designed software.
- Get a log of all one-on-one meetings with a specific developer and see the notes on those meetings.
- The log is accessible to both, you and the developer (there’s a function for private notes) with an option to share with a 3rd person, eg: a team lead.
- The developer is encouraged to leave any discussion items from their side, for the next meeting.
- You can leave reminders for yourself from the meetings to ensure you don’t forget anything.
- Much more.
Wanna know more? Schedule a demo.
3. Handwritten notes are surprisingly popular
You’d think engineering managers, usually part-engineers themselves, would have a high-tech approach to note keeping, right?
Well, the spectrum for this was very wide, some would have specialized software to keep notes, but many sticks to the good old handwritten notes.
Apart from personal preference, many keep to handwritten notes to indicate to the other people in a meeting that notes are being made, instead of the engineering manager randomly typing something on the keyboard, during the meeting.
The logic is especially useful in a one-on-one: you let the developer know you got their full attention and are even making handwritten notes. Typing notes on the laptop does not just risk coming off inattentive and rude, it also risks leaving the developer wondering: “Is there a secret file on me? What’s in this file?”
So handwritten notes have some logical benefits, but there are some questions and risks you should consider. Is your company rigidly following compliance requirements? If so, do you have a policy for keeping, discarding, and securing paper-based notes? God forbid you’re also storing personal information on the developer in those papers!
Ditch handwritten notes with Zumvie
As outlined above under the 1-on-1 section, we could replace the existing notebooks or digital note-keeping solutions, with a robust software designed just for this.
You can switch between leaving the note as public or private and the developer will be left with a log that they can see, go back to, and review. You can even set expectations.
We’re also ISO 270001 compliant, so you don’t have to worry about controls and issues with compliance!
Let’s chat more? Book a demo here.
4. Your best source of learning are other engineering managers
The processes that each engineering manager has, are usually the results of the circumstances they’ve had so far in their careers.
Many engineering managers have a somewhat unique solution to a specific problem they’ve faced before. Consider involving other engineering managers in your organization, when coming up with solutions to issues and fires you’re currently dealing with. It’s likely someone has had this before and can help enormously.
Regular catchups or knowledge sharing between engineering managers in your organization should also be considered.
If you wanted to take a step further with this, consider networking and regularly catching up with engineering managers outside of your organization.
Sneak peek: our “marketing roadmap” consists of a Slack community for engineering managers. Stay tuned 🙂
[mailerlite_form form_id=1]
5. Developers need more soft skills
Many engineering managers mentor their developers, they want them to succeed and become better. The most common area an engineering manager believes the developer can improve in? Soft skills.
Over the calls, we heard this over and over again. The other areas would include very specific, technical skills, but nowhere near the soft skills, we kept hearing about those over and over again.
Use Zumvie for developer mentoring
With the Zumvie software, every developer you manage has their log where you can make notes, but also assign templates. The templates are primarily used for onboarding, but they can also be set up to be used for mentoring.
If there are constant areas you’re finding your developers struggling in, you’d be able to create a template for it and assign it to the developer.
The template is a list of checklist items that the developer can work on if they wish to improve in the given area. You could provide items such as “read this book/blog on soft skills” and similar.
You’d get some analytics on how is the developer doing on those tasks, are they clicking on the links the night before the next meeting (perhaps a salary review), or did they go back to the checklist for the past months and actively work on this?
All of this is customizable and perhaps won’t work in your organization – but possible with Zumvie. Book a demo to chat about this 🙂
6. Documentation is on everyone’s mind, few do it
After and during our calls, as we were exposed to the different problems engineering managers face, we had to pick some to start building solutions for. The one problem across almost everyone we spoke to was documentation.
Documentation is something every engineering manager wants to improve on in theory, but only a few do in practice. The reason, as with many things, is short-sightedness.
And it’s hard to blame that on the engineering manager – with an ever-growing to-do list, roadmap items, and tech issues to deal with, documentation simply gets pushed down on the priority list.
It’s also very hard to enforce documentation, it almost requires a cultural shift in the company. To us, it seemed like the only way engineering managers somewhat successfully implemented documentation practices, is by making it the number one cultural shift and a very big priority, in their teams.
The common thing we heard about encouraging documentation, was simply repeating it all the time, like a parrot, and incorporating documentation into the training of junior developers.
The other one, which will only work in a few companies, is making documentation an expectation for a salary increase. Make it a part of the annual or quarterly review.
7. 50/50 on coding versus managing
We spoke with a very wide range of engineering managers, so this might not be accurate to your situation, but overall, the ratio seems to be about 50/50 when it comes to managing versus development-related activities.
Naturally, the higher in the org you go, the less actual development you do.
Most engineering managers come from a developer’s background, so don’t want to give it up or even worse, fall behind. Many EM’s we spoke to said they wish they had more time for development, just to be able to keep up.
But the good news is that having people management skills and development skills drags you upwards and in no way downwards.
8. Teach your developer’s product skills if low on resources
Something interesting we observed is that the engineering managers with limited development resources, but a full roadmap, try and solve this by teaching their developers how to think like product owners.
How should developers prioritize which ticket to get to first and which feature request should your team put in the roadmap?
We found that some engineering managers, in specific companies that let the developers influence the roadmap, would make it a point to continuously explain their thought process and teach their team to be better in product decisions.
This would go as far as commenting out loud: “this bug is affecting 3 enterprise customers and is of higher monetary value to fix than the other that’s affecting 10 low-value accounts.”
Encouraging developers to bring ideas for the roadmap and commenting on their value to the users, was also a common practice we observed.
Bonus 9th thing we learned…
Engineering managers are pretty awesome! They’re very open to speaking, trying out new tools. They’re sociable, have people skills, and are extremely intelligent.
We tried building a startup in a few industries before and so far, engineering managers have been the best to speak to!
What we’re building
We’re building a tool that helps engineering managers onboard new developers and manage the one-on-ones with them. We’re about to launch in private beta and still have a few spots available to join and get a mega-discount on the product!
