One of the biggest challenges to growing an engineering team is dealing with technology choice. Some organizations stop time at the moment they chose their current stack, refusing to add any new technologies. Others allow everyone to use whatever they want, leading to an explosion of unmanageable technologies. Both of these are terrible, but what is the alternative?
Ideally, you want your technical portfolio to change with both your problem set and with the progression of technology outside your organization. To do this, you need three things:
- Hire developers primarily motivated by business value (as opposed to shiny tech)
- Provide an internal technology radar that documents the who/how/what/why of all the tech you are using
- Create an experiment-based-during-the-workday process for adding new and alternative technologies.
Let’s see how these work.
Hire Developers Motivated By Business Value
It’s fun to play with new technology, and every engineer should be doing so when they can. It’s a great way to grow as an engineer and keep abreast of what’s going on in the rest of the world.
But, engineers who are primarily motivated by technology will make the wrong tradeoffs in their day-to-day work. They’ll sacrifice delivering results, understanding business need, and cutting scope in favor of digging in on the latest framework that catches their eye. Take care not to read a false dichotomy here—engineers should be interested in new technology, but it should not be their primary motivator.
Software exists to solve a problem for its users, and an engineer must be motivated by solving that problem. Using new technology can make it difficult sometimes, but then, so can using the same old thing. That’s why this problem is hard.
So, hire developers interested in solving problems, and who derive intrinsic value from user delight. Such developers know that many times the best way is to use what you know and what is in use. Only occasionally is something new called for. Assuming you don’t have a dysfunctional interview process, you can easily suss out where a developers motivations lie. You can also carve out time in an interview on designing a solution to a hypothetical problem. Good engineers should focus on the problem and the user-facing solution more so than that technology used to implement it.
With solid developers, you still need to easily understand what technology is actually in use, and a wiki page or shared document won’t quite cut it.
Document Reality Using a Technology Radar
You can’t change your technical portfolio without knowing what you are changing.
Your documentation needs to answer the following questions:
- Who is using what in production?
- How is it working for them?
- Is there anything else we tried on our problem-set?
The Thoughtworks Technology Radar is a framework that does just this. Thoughtworks is a large consultancy that publishes a report on technologies they feel are either successful, merely interesting, or not working well. It’s called a radar because they visualize it as a round radar-like diagram with quadrants and rings.
The rings (the distance a technology is rendered from the center) are where the most value lives1. Technologies in the innermost ring, Adopt, are ready for prime time (again, this is in the opinion of Thoughtworks). The next ring out, Trial, are technologies that are on the cusp, but need a bit more real-world vetting. Continuing out further from the center, Assess documents technologies that are either interesting and promising, or have lost their sheen over time. The outermost ring is Hold, and it’s essentially technologies they feel aren’t worth pursuing or should be avoided.
This is exactly what an engineering team needs to focus conversation, but instead of creating the radar to evangelize technology, it can be inward-facing, to document where the team stands and what it’s experience is.
In a sense, if you group all your technologies into one of these rings, you can communicate pretty clearly about your team’s landscape:
- Adopt - favor these over anything else, as they are tried and tested. A Stitch Fix example is Rails.
- Trial - If nothing in Adopt will help, look here. A good chunk of the team is having success, but it’s not ubiquitous. An example is Angular—my team uses it heavily, but the other teams don’t.
- Assess - Someone somewhere has this in production but strong opinions haven’t formed. Find them if you are interested in the tech here. An example is BassCSS—our styling team is using it on a few views, but that’s it.
- Hold - These have been tried and deemed not a good fit. Don’t use them, and consider removing them from your projects. An example for us is Airbrake—it doesn’t fit our monitoring and alerting style, and we’ve moved to Bugsnag.
You can manage this in a lot of ways, but the way that works best is not a wiki, but as a file in source control that can be pulled into your team’s internal or external website. We’ve created a Rails Engine called tech_radar that will do just that.
This engine reads the radar file and visualizes it in several different views to allow ease of navigation. You can see ours here. To play around with your own, look at the gem’s README; you can literally click a button and have a default example radar running on Heroku for free. Then, tweak it as you like.
The good thing about having it be source code, as opposed to a wiki page, is that you can use your normal development process to control and manages changes to it. You can have discussions focused around PRs instead of wiki notifications.
But, your internal tech radar is just a document, capturing a snapshot of reality. More interesting is how it’s changed. Which is really to ask: How do you add technologies to your portfolio in a safe way that’s not overly bureaucratic?
Be open to changes, honest about the amount of time involved, and schedule it with your regular work.
Run Scheduled Experiments During Work Hours
In organizations open to change, you often find that change is driven by people with a lot of free time outside of work, or by people who sneak the work in amongst their regular work, likely to that work’s detriment.
Instead, you should be more intentional and more honest about this work. It should be scheduled like a regular project, limited in scope, have clearly defined metrics of success, and done during the regular workday.
This concept likely needs little evangelizing to the engineers on your team, but the non-engineers need more. Think about it from their perspective: you want to stop doing “real work” and play around with some shiny technology for a week or two.
Here’s the thing: most professions have the notion of continuing education. In fact, some professions like mechanical engineering, medicine, or law require it in order to keep practicing. This ensures (in theory) that practitioners keep up to date with the latest findings in their fields, making them more effective and more valuable to their employers.
Software Development is no different. If the engineers on your team do nothing but deliver business value and don’t spend time on their profession, their value to the organization falls over time. In a sense, the organization should expect that the engineering team use the best tools and techniques that are reasonable, and keep themselves up-to-date on what’s going on in their field.
It seems reasonable that if the company pays for employees to take vacation and sick leave—which don’t generate any direct business value—paying for time to experiment with new and alternative technology shouldn’t be a hard sell.
Making this work requires a healthy relationship between engineering and their stakeholders. If that’s not the case, you may need to take steps to repair the relationship before proposing this. If you can’t make this happen, it could be that you aren’t in a place where you can do your best work.
If you can get buy-in for this, you want to get a lot of value out of a little work:
- Be honest about the problem the technology solves. Convince a few other engineers as a test for your own thinking
- Be explicit about what your experiment will reveal. It doesn’t have to uncover everything, but what will help you make a decision?
- Make sure it’s meaty enough that everyone will trust the results. Something you can do in a day isn’t likely to be convincing.
- That said, keep the scope to a minimum. You don’t want to go off into a hole for a month.
- Don’t forget about what introducing new technologies does to your team. It has a real cost, especially in the short-term. It has to be supported in production, developers need to know how to use it (especially those that don’t want to), and you have to have a way to figure out how to deal with something going wrong.
- Then, schedule the work.
Having it explicitly on a roadmap allows its priority to be negotiated against higher-value or time-critical work, but make sure it gets done. Be honest about the results and share your findings, even if they turned out negative.
When you are done, either add your new technology to “Assess” on your Radar, or put it on “Hold”.
Conclusion
Managing technical change is hard. Someone is always going to be disappointed that their pet language or framework isn’t embraced by the team, and someone is going to be upset at having to use something they don’t particularly like. Just be OK that some really great technologies just aren’t the right solution to your problems.
By hiring engineers with the right mindset, creating a technology radar for your team, and using an experiment-based approach to keep up with the times, you can navigate your way.
