If all you do day in, day out, is write code, you might wonder at some point if this is all you are here for. Writing code is fun, and software engineers should enjoy it - otherwise, they will have a problem sooner or later. However, if every day looks the same, and every week looks the same, then you are probably not using the full range of your potential, or growing as much as you could. It is hard to feel unique when you do the same as everybody else, and the same holds true for them. Instead, you feel more like a cog in a machine - fulfilling its role, but exchangeable. A workplace should encourage everyone to bring their individuality to the table, and to grow beyond their current role. One way to achieve this is to introduce little changes into people’s work schedule that let them take over new responsibilities, allow them to try out new skills, or give them some new purpose in their jobs.

Jason Evanish, CEO of Lighthouse, writes about how to help people grow without promoting them. He has some great ideas related to skills growth, channeling passions, and making use of people’s intrinsic motivation. He also mentions lateral moves and role switches, where people take on an entirely different field - for example, move from software engineering to marketing. This is great if people want to do that. However, personally, I hope that most of my developers want to stay developers (recruiting is hard enough already). But even in this situation, there are little things you can do to bring some change to an employee’s working life. I am listing a couple of these “special assignments” below.

Presentations

It’s true, some developers are not born communicators. However, some are pretty good at it, and others want to become better at it. Giving presentations can be a great exercise, and often enough, exercise plus some feedback is all it takes to see massive improvements. Encourage people to hold presentations. Sometimes, even if they are shy, they secretly want to try it anyway, and only need a little push or an opportunity.

Presentations that occur regularly are especially helpful for exercising your skills, because over time you know the contents of the presentation very well, and can focus on the technique. Maybe your department presents itself regularly to newcomers, or you offer regular courses to the rest of the company (see “Teaching” below). Events like this are a good way of introducing regular presentation exercise into people’s schedule, and get them to refine the presentations as well as their style of presenting.

Onboarding

As your organization evolves, the tools and processes that new employees have to get used to will change. If you have already prepared an onboarding program with teaching material for newcomers, that’s great. However, it will have to be continuously updated. If nobody is in charge of that, then you, as a manager, definitely are. Why don’t you get some help with it?

Developers working in the trenches are best suited to teach others about the development culture in your organization. Have them prepare some material for the onboarding. Give them clear goals (like “newcomers should push code live within the first week”) and check their progress at regular intervals.

Mentoring

Mentoring is one of the things you can always ask people to do. You might not have a new position to fill that you can offer to somebody, you might not have a new project coming up that you can ask somebody to run. But you can always ask them to act as a mentor for somebody else, because all you need for that is two people with different levels of experience. It helps if the mentor-to-be can explain well and actually wants to help somebody else to grow.

How do you ask one of your people to be a mentor? It is relatively straightforward: Tell her what the goal is, and why you think she is the right person to guide the mentee. Maybe the mentee is not great at using your tool chain in an efficient way, and the mentor is one of those people who set this tool chain up originally. Suggest them to do pair programming once a week or so, and they will probably figure out what to focus on.

Teaching

Teaching can and should happen among tech people, so that they can learn from each other. However, in organizations of a certain size, there are probably many more opportunities for software developers to teach. For some people unfamiliar with the topic, programming is not far away from magic. Some are awed by it, others are curious. Take away the awe, and make use of the curiosity, by teaching basic programming skills. Some non-tech departments could benefit a lot from programming knowledge, because there are lots of menial processes and tasks that could be automated, resulting in huge time-savings for the organization.

Therefore, consider picking a couple of volunteers who want to get into teaching, and have them offer programming courses explicitly to non-programmers within the company. These teachers and the participants together could identify some low-hanging fruits that bring large productivity gains to their departments, with moderate effort.

As Eric Elliott wrote: “The best way to be a 10x developer is to help 5 other developers be 2x developers.” This is especially feasible with people who are not yet developers, and learn quickly. Getting them to 2x should be as easy as teaching them “Hello world!”. But be careful: Not everyone will be successful at picking up programming.

Employer branding

In a job market where all the advantages are on the side of qualified people, it helps a lot if you have a good reputation or a brand as an employer. The more people in your organization help with this, the greater the effect will be. So get people involved. Is there someone on your team who is especially sociable and open to talk to people? Send them to conferences and job fairs to chat with people and get them interested. Got some people who know a lot of frameworks and programming languages? Ask them to spend two hours a week on posting answers on StackOverflow, using a company branded account (an idea I first got from Leading Snowflakes).

Writing

Writing can count towards employer branding, as well. For example, if you notice that somebody writes elaborate code review comments, you could ask them to write an article for your company blog (or start it, for that matter). Potential new employees want to know what you are working on and what your current challenges are. Other opportunities for writers are documentation writing, or authoring of department updates in your company social network.

Wearing a hat

Several of the examples mentioned so far are instances of somebody wearing a certain hat. If you are the main contact for improving the departmental onboarding program, then you wear the departmental onboarding hat. This follows a famous management principle stating that every task must have ownership by a single person (also known as “whose monkey is it?”, named after a book by Ken Blanchard).

However, there can be many more hats. If you run code workshops or guilds, then these events require somebody to run them. If there is not one “go-to person”, then everybody and nobody will be responsible. There will be a high chance of these events not happening regularly, and eventually dying. So, you should find somebody to wear the code workshop hat, or the JavaScript guild hat.

Other possibilities of hats to wear include:

• Conference talk proposal hat: Agree with one of your people on a goal like “As a company, we want to submit at least 8 talk proposals next year.” This person can then research conferences to submit to, make this information prominently visible to everyone, help people to identify promising topics, and encourage them to actually submit proposals. This is not a huge time investment, but having such a person can make a big difference.
• TechBlog hat: The same function can be useful for goals like “We want at least one TechBlog article every month.”
• Metrics hat: It is important for a development team to know how their product is doing with respect to non-functional aspects over time. These aspects include code complexity, performance, accessibility, startup time, average response size, and many more. While it should be in everybody’s interest to be aware of these numbers, the truth often is that some care more than others. Ask somebody to gather the numbers of interest regularly, and publish them prominently for everybody to see.
• Clean-up hat: The person wearing the clean-up hat can, at regular intervals, check for things that have piled up and should be removed: Outdated branches in version control, outdated documentation, outdated team pages, calendar entries, etc. Either they do it manually, or they write a cronjob so that the cleaning up gets done automatically. Therefore, this one can be closely related to the…
• Automation hat: Designate somebody to automate processes in your department.
• Recruiting hat: Ask people to help you filter resumés and conduct interviews.
• Toolsmith hat: Related to automation. Ask somebody to design productivity tools that facilitate common tasks in the department. This can quickly turn into a full-time job, so be careful.

Conclusion

In every organization of a certain size, there are a lot of things that ought to be done, but that are somehow everybody’s and no one’s responsibility. Appointing somebody to be responsible can solve this problem. The person should be willing to take over the task, and ideally have some talent for it. However, if things do not work out, you can usually just swap the person out without causing a lot of interpersonal damage or hurting feelings - all of the special assignments I have mentioned so far are relatively low-profile, so people will probably not attach their entire ego to them.

Which are other activities that you could engage your colleagues in so that there is more growth and change in their work life? Share your thoughts in the comments below!

Time investment

This blog post took me around 3.5h to write.