In our rapidly changing industry, managers need to keep informed of the trends to make sure their team has tools to succeed. But if you’re focused on your day-to-day operations, you don’t have the time to delve into the Slacks, Discords, and other communities where people discuss and share trends. Luckily, we do. Here are nine of the most important changes you should be making today that will help you adjust to these trends and stay competitive.
1. Bring Operations Into Your Dev Team
Do your developers need to email an entirely different department just to get a dev server set up? Do you deploy things manually? If your company still has a separate department for operations, start thinking about bringing what they do into the development fold. Your dev team needs the power to architect and optimize deployment and infrastructure. Cutting-edge companies and developers created an entirely new discipline for this: DevOps. But you don’t need a separate DevOps team for this. Just implementing the latest technology and training on your dev team can make a huge difference. Consider training at least one member of your team in AWS, Docker, and other relevant DevOps technologies. The DevOps developer is the new back-end developer.
2. Front-End and Back-End Shouldn’t Be Separate Jobs or Disciplines Anymore
Does this comic illustrate your experience with front-end and back-end development?
Well, if you still think this is how things work, you’re already behind. Front-end and back-end shouldn’t be considered separate anymore. Oh, and your front-end developer is your new full-stack developer.
In 2010, front-end was your application’s look and back-end was everything else. Now, “front-end frameworks” like React and Angular require architecture and tuning from the server side to the browser. If your team has a discrete “front-end” and “back-end,” it’s probably not doing that very well. And that has consequences for performance, which in turn has effects on everything from user experience to SEO ranking.
3. Stop Ignoring Remote Workers
Even if you think your company doesn’t have remote workers, it probably does. Many companies that do software development leave policies about working from home to manager discretion. But these sorta-remote-sometimes-maybe workers are totally unsupported on a larger scale and face an insecure outlook on their long-term ability to work remotely. Pretending remote workers don’t exist doesn’t help you. Reflect on what infrastructure you have to support these people, and come up with a more formal system for managing them. A good system for accommodating remote workers gives you a huge competitive advantage in attracting the best software developers all over the world.
4. Streamline Your Interviewing System
Burdensome interviewing processes hurts you in two ways: it costs you money in the form of your developers’ time, and it also may deter quality candidates. Everyone wins when you design a better system, but you must let go of all your preconceptions on the topic of interviewing. All the stuff you’re using now? Whiteboarding, six-hour-long interviews with every single person in your department, pair programming, elaborate homework assignments you need to grade? Most studies on the subject show none of this works. Consider what you might need in order to test out potential new team members with a contract-to-hire arrangement. Or plan more structured interviews that ask questions and evaluate based on the everyday work, not brain teasers or code puzzles.
5. Audit Your Tools
Have you been using the same project management, task tracking, and bug queue software for the past decade? I worked on one project where the Jira install we used for task tracking had what felt like 40 different fields that long-gone project managers had added. Oh, and we also used Trello, Google Docs, Slack, AND Office 365. We spent too much time just wading through the clutter.
If you aren’t already doing so, you should regularly evaluate the tools you have. Are their settings full of clutter? Does your team still benefit from them? At least compare it to newer software to see how it stacks up. Don’t adopt new fancy tools just because they’re shiny, but at least see what these new tools have to offer.
6. Popularize Your Developers
Send your developers to conferences to promote themselves and their work. It’s really shocking how many companies don’t do this. At one job I had, we got a majority of our sales simply from sending members of our team to conferences. We’d present about something cool we did, and the next day our sales inbox overflowed with people wanting it for themselves. Not all developers like going to conferences or public speaking, but many do. These are also places where people learn about new technologies and techniques. Sending them is a way to show your appreciation to your developers, promote your company, and contribute to your team’s professional development.
7. Don’t Forget About Mentorship
Many dev teams no longer have junior developers. It’s because they consider them a drag rather than an asset. This doesn’t make any sense. It’s a waste of your budget to make a $250-an-hour senior developer do work a junior developer can do. The real reason that teams don’t have junior developers, in my experience, is because too many just threw these newbies on a team and then wondered why they flailed. You need a system that rewards mentorship and training, as well as works to retain junior developers as they move up in rank and skill.
8. Reward Support Skills
Software engineer Michael Lynch recently wrote a great article about why he left Google. He paints a picture of a workplace where the time he spent supporting and improving existing software wasn’t considered valuable. It’s often tough in any organization to show higher-ups the valuable work employees do to make software that (1) is reliable, (2) deploys new releases smoothly, and (3) doesn’t require having 3 AM on-call maintenance. That’s where dev managers should come in. You should be the ones advocating for the less glamorous work: for documentation, bug fixing, tests, continuous integration, and revision control. At the end of the day, these practices do lead to better, faster delivery, even if they do require an initial investment that might be hard to sell.
9. Make Sure Project Managers Are Managing Projects, Not Developers
I always like to tell the story of the team I was on that had 30-people scrums every single morning. These meetings were the worst hour (or sometimes more) of the morning, and they were a symptom of a culture where project managers managed developers, not projects. Not only that, there were “Slack scrums” given by a bot that would ask us what we were doing every morning and compile it into a report. I am not making this up.
I left and moved on to a company where the project manager was our equal at delivering the project. We worked together to figure out what tools we would use to do that. And we just had small scrums three days a week and worked together to develop the ideal tools for our needs. We ended up using style-guide-driven development, a method none of us had utilized before but which was perfect for our design-minded clients. This never would have happened if the client were our manager and not our collaborator.
As the proverb says, “The best time to plant a tree was 20 years ago. The second best time is now.” And so it goes for all these things as well. But don’t expect it to be easy. A lot of these changes require fighting against the status quo of most organizations that do development. But it’s all for the ultimate prize of a dev team that can stay competitive by delivering top projects that clients love.