How to reward skilled coders with something other than people management

You have awesome engineers, and they want to advance in their career. Their team is growing because of advancements they've made, and you want to recognize the work they've done with something. The obvious answer is to put them in charge of the team they've built, especially as they're the de-facto leader of the team already. But is this what they want? Or just what they believe they're supposed to want? 

People Management Is A Different Skill

It's well known in the engineering world that engineers often will reach a technical peak, only to be asked to learn an entirely new set of skills, revolving around social and soft skills that they've spent the past chunk of their career probably ignoring. Building these skills involves a lot of trial and error, and above all, most of their time. Their time is now spent not coding, which is what they were originally rewarded for. Suddenly, they go from being good at their job to bad at it, which destroys confidence and job satisfaction. 

The problem here is that people management is a different skill than technical leadership. What you want is to reward someone with recognition that they are a thought leader, an exceptional performer- to make them an example of what others should strive to be. Everyone can't strive to be a manager, who would do the work? Additionally, you don't want to send the message that management, as a career, is somehow "better" than coding or anything else in the company, for that matter. 

What Is Technical Leadership?

Technical Leadership is composed of several aspects of purview over parts of job responsibility. Think about the day of a typical engineer- many decisions have to be made, problems have to be prioritized, solutions need to be found. Those are the fun parts of any engineer's job, and indeed all engineers must exercise some degree of technical leadership.

The rest of the job involves answering questions about how a thing you made works or doesn't work. Bugs need to be found and fixed. Documentation has to be written. Code has to be reviewed. Estimations must be made. Most of all, the longer an engineer remains at a company, the harder it is to find a few hours of isolation, free from interruption, to get work done. These parts, they are the worst parts of the job.

All of the fun work happens in these uninterrupted times, and these uninterrupted times happen only when your disappearance doesn't materially slow down someone else's work. Innovation happens when you have the bandwidth to hold the entire problem in your head- most of the time that takes a great deal of "load time" - research and contemplation about the problem. For introverts this means quiet, for extroverts this means dedicated time in a room of other people you work well with, thinking about the problem. 

So what gets in the way? Why can't exceptional engineers have more fun work, and have someone who is yet to be recognized do more of the less fun things? The key is in empowerment, and an engineer's ability to say "No". This isn't a function of courage, it's a function of empowerment - most exceptional engineers can't just let problems go unsolved, and if they feel responsible for a product or service, they end up chained to the project forever. Engineers often feel responsible for a project for the rest of its life, and this is exacerbated by the tendency for information to "silo" in one person, rather than distributing across a team.

How To Empower Your Technical Leaders

As a project grows, a technical leader might naturally accrue team members, and accidentally transform into a people manager. This is the biggest risk. The way to empower your technical leaders is to set expectations early and often, encouraging them to be clear about their ultimate goals, without sending the message that they will be less respected if they don't transition into people management. If their goal is to be the best programmer imaginable, or to create a system that scales to 10 million users, or to understand deep processes in the operating system, then finding ways to help them reach their goals is rewarding for everyone. 

Technical goals are easy to meet - there will be plenty of opportunities as a company grows to reward engineers with "fun" projects, and the ability to learn and grow as an engineer. Identify when someone will have to learn a lot for a role, these roles are rewarding and coveted. Also find opportunities to allow for professional development outside of your company, such as encouraging engineers to go to conferences and give talks, and become thought leaders in their field. Most engineers don't have an actionable plan for their own professional development, and so can benefit from advice on how to celebrate their accomplishments by putting them in a favorable position. This also will help you make the case for raises and bonuses, and will increase the esteem of your engineering department in general, which in turn attracts more talent. Seeing someone speak on something that interests them is the number one reason why mid-to-senior level engineers seek employment in an organization, rather than being recruited. Developing a strategy for positioning your technical thought leaders as the technical thought leaders is empowering, and it helps them empower themselves. 

The ability to say "No" is the second component of a technical leader - develop a strategy around handoffs. The objective here is to reward innovators by not chaining them to their innovations forever - it encourages those who create to continue creating. Junior developers are perfect to hand off smaller creations to, it helps them develop a sense of ownership without having to understand deeply the best practices that created the idea. Handoffs create opportunities in both directions- both for the person with more time, as well as the person accepting the responsibility. The incentives align well, but make sure there are expectations for the person receiving the responsibility- be honest about what it means for their career, and set up a strategy around them getting help with the project.


I came up with these ideas by helping Simple activate and reward their talent with things they actually want, rather than taking the obvious-but-wrong path. If you need help developing strategies for creating opportunities for your technical leaders, email me. I'm a consultant and I'm also an engineer myself, so I can provide insights into how to keep engineers happy and productive.

How 'The I to We Ratio' provides quick cultural insight

I'm doing some consulting for Simple in Portland, and I'm struck by how cohesive their culture seems to be. I couldn't put my finger on it at first, where this impression was coming from. I figured it out after attending a few meetings and watching team interaction, and I have a theory. I call it the "I to We" ratio - basically, how many times in a meeting, or a gathering, does someone say "I", vs how many times they say "We". 

This is a good barometer of how connected to the company an employee feels, and how they perceive their level of integration in the team. It also indicates feelings of ownership, empowerment, and how an organization treats the idea of blame. Simple's We to I ratio is about 10:1, which I think describes how connected to each other they seem. It creates the feeling of warmth I notice, that they have each other's backs. Work being done is the focus, over "root cause analysis", which all too often turns into a witch hunt.

Think about when you use the word "I". Often at work, it's to talk about something you did, or didn't do. It might be about how you feel. In an integrated, healthy organization its usually something like "I filed a pull request" or "I updated that documentation". In an unhealthy one, it's "I didn't know I needed to handle that" or "I'm taking longer than I thought to get done, I'm trying." "I" is more often used defensively, whether to defend your actions or to defensively self promote - "I made a tool that handles that", "I fixed the certificates problem."

The word "I" isn't the problem in and of itself - it's when it's concordant with defensive tones. This is a difficult thing to notice, but an easier metric to test for is the absence of the word "We", alongside "I". "We" sounds like collaboration, and it evokes the sentiment that We Are In This Together. "We need to handle that 2-factor auth bug", "We just deployed to prod", "We don't know why this error happens", "We got the batch processor up again". The word We is powerful, and it helps make a team feel a sense of ownership, instead of burden. 

You can listen in on a few conversations, status meetings, boardwalks or scrums, and get a feel for this metric. I've noticed that Kanban as a productivity management technique is more conducive to a high We to I ratio than Agile/Scrum, because the focus is on the work that needs to be done over the individual doing it. 

If you use Slack, Hipchat or IRC, you can run a quick analysis on your per-team channels. Check how many times people say We, and how often they say I. Check the concordance of "We" and "I" with Python's NLTK library(http://www.nltk.org/book/ch01.html), which will show you the words that appear around the words you search for. Notice how often you see defensiveness around the word I, rather than empowerment. 

All in all, this is a trailing indicator of how your team interacts, and how healthy your culture is. It's a subtle distinction to notice, but once you know it's there you can't un-see it. It's a great indicator for per-team cohesiveness, and if you do periodic checks, you can proactively address breakdowns in communication before they occur. 



I do consulting for engineering process, management, and culture. I mostly work with companies in the process of growing from startup to mid-size company, and help keep them from losing their soul in the process. I also help with issues around diversity, including neurodiversity. Email me if you want to know more.


Onboarding Junior Developers

3 months after leaving Hackbright, and I'm still running triage for many of my students who've been hired in the past 6 months. Not that partner companies are mistreating them, or that their skills aren't up to snuff. Most of my triage stems from a lack of real mentorship. Everyone knows that "time-to-useful" with any engineering hire is usually around 2-3 months, but no one really understands what is happening during that time that takes so long, and why some people don't really make it. 

So I'm going to write a book about it.

In this book, I'm going to discuss some of the programs I've seen work, ways they could be better, and most importantly, how to make junior developers useful, quickly, while making sure they understand how their performance actually is throughout the entire process. There will be case studies, research, fun charts and graphs and instructions on how to cost-and-time-effectively hire and onboard junior developers.

But this is a blog post, not a product announcement, so I'm going to drop some insights on you before that. 

A culture of teaching

Mentorship

How many mid-to-senior level developers reading this right now feel like they know everything they need to know to do their job? That they could functionally program without any reference materials, or debug without Google? Anyone who raised their hands probably doesn't work well with junior developers. 

Everyone who didn't raise their hands understands that knowing isn't the important part, reasoning is. Mentorship makes up the space between a productive jr. developer, and an unproductive one. Mentorship mostly consists of style guidance, help in navigating the typically awful reference materials for a given language, and institutional knowledge about the codebase and it's quirks. Junior developers need this, and it's a people skill to be a good mentor. Not everyone is suited to mentorship, but those that are can multiply the output of a junior developer by their own, and end up with much more than either would have produced alone.

Mentors should plan to spend at least 8 hours a week with a junior developer for the first month of their employment, and 5-6 hours for the next two. That's at least an hour a day, preferably in the morning. This should mostly be spent pair programming, or doing an overview of what you expect them to be able to do, and how they might go about doing it. Usually, an honest end-of-day check in is also important, but this can be done over email. Encouraging honesty about what they are having difficulty with is imperative, so that you can give further reading, or explain concepts that might not yet have solidified.

Workshops

Fostering a culture of learning doesn't end with mentorship, however. Everyone on the engineering team is a learner, and everyone has the capacity to share knowledge. Having workshops and lunch sessions taught by your engineering staff helps encourage senior staff that sharing their knowledge is important, and helps set expectations that it's not just up to them to handle the hard stuff. Teach a mix of beginner and advanced topics, such as explaining how the complex recommendation engine you use works, as well as a primer on your front-end JS framework. This prevents siloing, and also helps jr. developers to feel they can be honest about their actual skill level. You want to foster the idea that you don't expect them to just know, but that you expect them to ask. Junior developers should also be expected to teach, and asking them to explain in depth things you know they will have had to learn on the job will help them with both their credibility and confidence. 

Re-teaching language fundamentals is a good idea- most developers have to learn a new language for their first job, and going over both basic and advanced techniques will help new developers become more effective, faster. You can lean on your existing talent to do this, over lunches and in afternoon sessions, but you may be able to bootstrap it by inviting user groups to put on classes in your office in the evenings. Asking your junior talent to teach things they don't yet have confidence in causes them to investigate deeper, think more critically, and helps others. Having junior talent do a series of short talks that other junior staff is required to attend allows you to parallelize the effort they're individually putting in, as well as give them expectations to measure up to.

Hiring In Groups

Junior developers work best together, in pairs. Hiring a group of 2-6 (or more, if you have the budget and inclination to take on "classes") can be many times more effective. When working together, two jr. developers can more easily ascertain if they need help, learn faster, and have twice the working memory space. When hired together, most jr. developers are net positive twice as fast than when hired alone. 

New developers need someone who they can realistically compare their knowledge against, and who they can freely toss ideas around with. Many jr. developers don't feel comfortable or feel intimidated by other members on their team, out of a feeling that they are wasting time, or their ideas are primitive and too obvious. Most developers probably can remember a time they didn't speak up because they thought their idea was too obvious (and obviously wrong) and so hadn't been covered by the team, only to bring it up later and be told they could have saved everyone a lot of time.

Setting (real) Expectations

Honestly discussing and setting productivity milestones within the first few weeks are extremely important. Understanding what is expected of them in terms of productivity is important, because most new developers will spend most of their time learning the skills they need to accomplish what is expected of them, and they need to know if (for instance) they need to spend more hours at work getting things done, or if they can go home and learn more about the skills their job demands, or if they can rest their brains. 

Realistic milestones are important - if you feel like your junior developers should be blowing away your milestones, then your expectations aren't real, they're just a minimum that you'll ultimately be disappointed in. 

Hiring a consultant

Ultimately, these things are hard to implement. It's tough to look at your existing team, and know who will make a fantastic mentor, what your junior talent should be learning (and teaching themselves). It's hard to know what they'll be capable of 2 months from now, based on where they are now. Hiring an engineering onboarding consultant, or an educational consultant, can be a fantastic option for those running teams strapped for time, or whose teams lack the empathy capital to spend on hours of mentorship. 

Fortunately, consultants exist who can do this kind of thing. I'm one of them (shameless plug) and can help you design an onboarding process, or help your existing onboarding process accommodate developers from a more diverse set of backgrounds than it currently does. These processes can help your existing team save time, identify stars (and bad apples) faster, and help foster the growth of your entire engineering team. 

If I can help, shoot me an email at lizTheDeveloper@gmail.com.