How to Build a
High Velocity
Development Team
Be the Quantum Leap
Your market — every market — is being disrupted by transformative new technology. Not just better apps, but quantum leaps in tech evolution that will redefine the human experience.
Be the quantum leap,
not the roadkill.
You need to bake learning & constant transformation into your dev team’s DNA. There’s just one problem:
Your organization is
afraid of change.
Shipping changes to production can be scary.
- What if you missed a critical bug?
- What if the users hate the new experience?
- What if you block a critical user workflow?
- What if the change stifles growth?
- What if you break the customer purchase flow?
- What if you crash the production servers?
These questions are running through the heads of your development team every time you fix a typo in your product’s copy.
Fear cripples developers.
Inevitably, if you haven’t planned for those scenarios, those scenarios will happen. In fact, I could rename it “Rites of passage for developers and product teams.”
But they don’t have to be.
You must eradicate
your development team’s
fear of change.
This should be your development team’s priority number one until nobody in your organization worries about changing a line of source code again. Change should be so routine that you never even think about it. You only think about improving your customer experience. You should be shipping a constant stream of changes to production every day.
Change is the reason
that DNA exists.
If you’re running a startup in the United States that’s less than 5 years old, there’s a 51% chance that you won’t ever hit that 5 year mark. There’s a 74% chance that you won’t last 15 years*… if you’re average.
Average businesses regularly lose to their competition. Average businesses can’t keep pace with changing technology. Average businesses fail to listen to the evolving needs and expectations of their customers.
But you’re not average. You embrace change. You make natural selection work in your favor. You don’t fear disruption. You cause it, because you understand the fundamental law of nature.
Adapt or die.
Organizational transformation requires education and coordination of both the engineering teams and the managers who lead them. Bill Scott, VP of Next Gen Commerce at PayPal gave a great talk at MXConf 2014 about the recent transformation that rescued user experiences that seemed to be permanently stuck in the 1990's.
The talk is a must watch for every tech company leader & dev team manager. Watch it right now. This article will still be here when you’re done.
Team Building & Morale
Nothing predicts business outcomes better than an exceptional team. If you’re going to beat the odds, you need to invest here, first.
“People, process, product.”
~ Marcus Lemonis
Without great people, you can’t build a great business.
Getting people right is exponentially more important in software because a very small production team could grow your product to hundreds of millions of users.
On a dev team, every person counts, and it’s up to you to maximize the value of every individual developer. But the odds aren’t on your side. Most tech teams fail because most tech teams don’t understand how to hire and motivate developers.
The average organizational value of a single developer at a viral startup is in the millions of dollars per year*. That doesn’t mean that every developer is worth that. It means the outlier employees at the outlier companies are worth that. Sometimes in the tens of millions*. The best companies in the world understand that value, and treat developers with the respect they deserve.
If you want to compete with the top tech companies, you need to find those outliers, and once you make a hire, communicate with each developer as if you’re talking to a $1MM developer. Don’t treat them like cogs in the machine. Treat them like you can’t succeed without their help. Because you can’t.
You will have to let some go once in a while, but every time you do, remember that $1MM/year just walked away, and it was you who made the mistake.
When you let a developer go,
$1MM/year walks away.
You hired them for a reason. If you don’t look at a developer candidate and see $1MM/year sitting across the table, don’t make the hire*.
If you hired them, you saw potential in them. Were you wrong when you hired them, or wrong when you fired them? Does it matter?
Hire the Right Developers
You need outliers on your team. You need the developers who can bring outstanding value to your business. If that $1MM/year value isn’t in your head while you’re hiring, you’re doing it wrong.
That value isn’t about experience. As long as you have enough great mentors on your team, those mentors can coach even the most inexperienced developers to successful outcomes.
But you need to start with the mentors. Your first developer hire needs to be a $10MM/year hire. Don’t pay them that much, of course — you need to conserve your runway or you won’t be doing anybody any good, but do differentiate yourself and clearly show your core team that you value their contribution.
Companies who get developer hiring right are extremely rare. Learn how.
The Biggest Mistake Almost All Teams Make
Ticket trackers
tell you about the project,
not the people.
Use metrics to make decisions for your business, but do so at the aggregate level. Don’t try to quantify developer value like a spreadsheet balance.
It doesn’t work.
Ticket trackers grossly understate the impact of your best employees, and grossly overstate the value of your least valuable developers. Why?
Your best developers spend disproportionately more time helping other developers perform at their peak. Their contributions are not easily tracked by project issue trackers.
Likewise, inexperienced developers are what I call “drive by coders.” They’re incentivized by shallow ticket numbers to close issues as fast as they can. They throw a quick fix in the general direction of the problem & leave heaping piles of technical debt in their wake.
Learn the right way to evaluate individual developer performance: “Assessing Employee Performance: You’re Doing it Rong.”
High Velocity Development
Take a hard look at your engineering team. Most engineering teams, even at “nimble” startups have a deep, organization-level fear of change, and that fear is crippling your productivity and agility. Developers are great at doing what they’re comfortable with, and they will endure serious process obstacles for as long as you allow them to exist.
- How long does it take for your engineering team to fix a bug and ship a quality fix to production?
- Has your team ever had to make live hot fixes on the production code? Has that ever gone wrong?
- Can your team prototype and test a major UI redesign on your live production product without disturbing the user experience for everybody?
- Have you ever waited weeks or months for simple changes to go out live to your customers?
Imagine this:
- Bugs in live code get fixed in the live product within 24 hours on a regular basis with near zero risk.
- Almost all bugs get caught before they have a chance to annoy users.
- New features can be toggled on and off, safely tested, and gradually rolled out, all in production.
- All changes to production code get rolled out while key business metrics are tracked in realtime so you always know the impact of product changes on the business bottom line.
In order to achieve this kind of agility, development teams must do things that they naturally resist.
In fact, dev teams convince themselves that it’s the business team that resists those things, and that the business team would not allow them to change it, because it seems like extra work in the short term. Dev teams need to feel the support of the business leadership to invest in efficient process.
Your team needs to write automated tests for every feature and every bug fix. If you’re not automating your QA, you’ll spend most of your time on manual QA and firefighting.
Automated QA is a foundation of continuous delivery, and if you’re not doing continuous delivery, your competition will run circles around you, because they are.
Automated QA is the foundation
of continuous delivery.
The intuition feels like writing tests will slow the team down, but in fact, it has the opposite effect, and the improvement is astonishing.
A little bit of extra code adds a fortress of stability to the product and deployment process. Even if it takes three times as long to develop a feature or a bug fix, it gives you compounding productivity savings.
An investment in stability and automation is an investment in agility. Stop wasting your development time putting out fires and get back to building your product.
Make your development team do the hard scary things frequently so they’ll automate them and then never need to do those things again.
Fear
is the enemy of
velocity.
Eliminate the fear, and your velocity will improve by orders of magnitude, and that impact is multiplied by the number of developers on your team.
Any time you have an opportunity for exponential improvements in performance, jump on it!
Architect for Change & Growth
There are several different styles of programming. They’re different at a fundamental & philosophical level, and those differences can set you up for success, or empty your bank account.
As the manager of developers, you need to understand enough of the broad strokes to lead your dev team in the right direction, because the truth is, most developers don’t know or understand the difference.
Most developers just do what they already know, and they’ll resist change, sometimes fiercely. And they’ll resist even the idea that there is a right way and a wrong way, because they think it limits their freedom of choice.
You know what limits their freedom of choice more? Getting laid off because you’ve gone bankrupt.
Some software architectures create rigid structures that are very hard to change safely. Others create fluid structures that are easily adapted when you need to add or rearrange software features. The language features developers choose to use can have an enormous impact on your business metrics. It can mean the difference between simple changes or extremely expensive rewrites. It’s important that your developers understand the differences.
Likewise, some architectures are built with a single machine in mind, and are very hard to scale quick enough to keep up with exponential growth. Other architectures decouple processes so that they can run independently on any number of systems anywhere in the world. Obviously, you want the latter.
Why is this hard for developers to understand?
Developers write code on a single machine — their development workstation — and in that environment, scale is invisible to them. They never see the problem until they’re frantically trying to put out fires in production.
This issue almost killed Twitter during their critical early growth phase. When the service got unreliable, a barrage of Twitter clones & alternatives quickly swooped in. Some of them (such as FriendFeed) even gained some traction with the same early influencers who helped Twitter build their early audience.
If Twitter had not fixed their scaling issues in time, they would have been crushed by their own fail whale.
I worked on a similar product and spoke with one of the people responsible for rescuing Twitter from the brink. What saved Twitter was a transformation from single-machine data storage architecture that’s awkward to scale, to distributed message queues designed with scale in mind. A distributed queue inherently spans many machines, and their location relative to the client is irrelevant.
To architect systems that scale, you must treat your application architecture like a distributed collection of channels and reservoirs, each processing application data streams independent of the others.
Decoupled, distributed architectures also make reliability a core feature, because channels can be redundant. If one fails, the message streams get delivered to alternatives while a replacement spins up to correct the load balance.
The internet itself was designed with redundancy and self-repair in mind. It makes sense that the apps we run in it are designed that way, too.
Twitter wasted precious months putting out fires and scrambling to keep users interested. Learn from their mistake.
Before you build,
plan to grow.
Language Matters
Normally I tell managers to hire great developers and give them broad freedom to implement things in the best way they know how. I have two exceptions to that rule. Language choice is one of them.
JavaScript is the standard language of the web platform, and your app should be written in JavaScript on both the client and the server side. Why?
- JavaScript is the most popular programming language on the planet*, and the easiest to hire for.
- There are more working open-source solutions in JavaScript than there are in any other language. Your team will have to write less code from scratch.
- JavaScript is the only language that can run universal code natively across the entire web platform stack, including clients, servers, and mobile.
What is “Universal JavaScript?”
Universal means that you write the code once and it works on all your platforms. Instead of building an iOS app, an Android app, a web app, and a server app, you build one app that powers them all.
There’s no such thing as “Universal Java” (they tried, but failed), “Universal Swift”, “Universal Ruby”, or “Universal PHP”.
Only JavaScript offers native access to the web platform APIs that work on desktop and mobile systems, and only JavaScript offers native access to the npm repository, where 50% of the packaged solutions work on both servers and clients*.
If your development team isn’t writing Universal JavaScript, they’re wasting your time and money.
Classical Inheritance is Obsolete
The other exception to my developer choice rule is that you absolutely must encourage your developers to avoid classical inheritance. Even better, ask potential hires to talk to you about classical inheritance, and if they say nice things about it don’t hire them in the first place.
If your dev team has any resistance to this, point them to these resources:
- The Two Pillars of JavaScript Part 1: How to Escape the 7th Circle of Hell
- Common Misconceptions About Inheritance in JavaScript
- JS Objects: Inherited a Mess by Kyle Simpson, author of “You Don’t Know JS” (O’Reilly)
- JavaScript: The Better Parts by Douglas Crockford — “The worst is class […] Those people will go to their graves never knowing how miserable they are.”
Classical inheritance is a way to reuse source code that’s already been written. It’s taught as the default way to reuse code in virtually every school and university in the world. It can be really hard to untrain, and in particularly stubborn developers, impossible. This is the primary reason I see a CS degree as a potential obstacle, rather than a selling point on a resume.
The problem is that it’s fundamentally flawed because all the code that uses it is tightly bound to that code, and all the other code that uses it.
Changing something in one place can break completely unrelated functionality in another, and that makes your developers afraid of change.
Remember:
Fear
is the enemy of
velocity.
Every large app project I’ve ever seen use classical inheritance has suffered for it tremendously.
If your team relies too heavily on classical inheritance, it has the potential to kill your company.
It will almost certainly slow progress to a crawl. You can’t fuel your rocket ship with concrete. I’ve been at this since the 1990's, and I’ve consulted on hundreds of apps for both startups and fortune 500 companies. (I used to run a software consulting agency focused on building products for viral growth). This is one of the biggest mistakes a development team can make. I’ve seen it happen again & again.
Don’t let it happen to you.
Encourage Collaboration
Developers should regularly be exposed to each other’s work. Encourage teammates to pair up on challenging problems, ask questions, share resources, and mentor each other. Code reviews and occasional pair programming are great practices I implement on all my development teams.
A culture full of collaboration and mentorship is capable of very rapid progress. People are tremendously well adapted to learn from each other quickly. You’ll find that great product ideas start to come from the engineering team, because your technology solutions will enable creative features that the product designers may not have considered possible.
Sugata Mitra tells the story of how he left computers embedded in walls all over India (and eventually the world). The result is that kids who had never seen a computer before learned and taught each other to do incredible things with no teachers other than the computer and each other.
People learn rapidly when they’re given a challenge and the opportunity to collaborate freely on the solution. Individually, people tend to get stuck on things and waste time chasing their tails. As a group, one person may get stuck, but others quickly chime in with creative suggestions. The more you can keep the team moving, the better.
Developers will still need long stretches of uninterrupted isolation when they have a good plan to get where they’re going, but nobody should ever feel like they’re on their own, and no developer should ever be afraid to ask questions. If you have a developer who never asks questions, talk to them about it, and encourage them to collaborate more. Try pairing them (as the driver) on a tough problem. A little practice could help pull them out of their shell.
Open Source All Your Modules by Default
Individual modules or components are not the secret sauce of your business any more than the business idea (don’t get me started on new entrepreneurs who think their idea alone is worth a billion dollars).
Modules are basically lego blocks for applications. Tiny pieces of functionality that you snap together to compose your unique app — but there’s nothing unique about a module or component. If you dream it up, chances are there are at least ten competing solutions already on npm.
The secret sauce of your business is your team. Your ability to execute on the idea. The way you put the modules together to create a product that users will love.
Several years ago I was hired to work at a startup that was growing like wildfire. They hired me on the strength of an open source library I wrote for my own apps.
I used that module on the new job, and a few weeks into it, another library user at a different company contributed a bug fix that was worth tens of thousands of dollars per month to us. Who knows how long it would have been before we realized the bug existed in the first place?
We were bleeding cash and didn’t even know it. If your modules aren’t open source, so are you.
One of the ways you’re bleeding cash is the tremendous opportunity cost of keeping your modules private. I have several open source modules with communities of developers who make incredible contributions on a regular basis. In other words, we all benefit because we share our most expensive resource: our developer talent.
Most companies are open to open source, but often have an approval process and legal review obstacles. The roadblocks are so high that most developers don’t bother. They happily keep all the code closed source, and that’s really bad for business.
Not convinced?
Luis von Ahn and Clay Shirky have some convincing arguments for the value of free global collaboration:
You Need an Open Source Culture
You need to bake open-source into the company culture. Everything should be open source by default except the app itself. As soon as you use a piece of code in more than one place, it’s time to turn it into a package and put it on npm. Work with your dev leaders until that process is smooth and clear with everybody.
For legal compliance, there are packages that search all your module dependencies for licenses and run automated checks to be sure that all the licenses are compatible with each other and comply with your own license policy. Don’t let legal compliance fear get in the way of a tremendous business advantage.
Failing to open source all of
your modules has a
tremendous opportunity cost.
Let your team collaborate with other amazing teams, and you’ll multiply your chance of success.
Embrace Remote Culture
It takes a tremendous amount of audacity to even try to run a startup these days. There are millions and millions of apps, but only the best of the best earn enough money to employ one person full time — let alone blossom into a unicorn.
App success follows a powerlaw curve, where a tiny fraction of app developers attract most of the users and revenue. This curve is more extreme for apps with friction, where a user has to purchase the app before they get a chance to use it, which is a driving reason that many apps have adopted a freemium model, where casual users can test drive the app for free, and purchase upgrades if they want to get more value from the app.
With so much at stake, you can’t afford to miss any possible advantages, so you should be taking a very serious look at remote work to see how it can impact your bottom line.
Productivity
I’ve been talking to a lot of Silicon Valley/San Francisco startups lately about how they hire & collaborate. Most of them still require people to come into an office every day. They sound like an echo chamber spouting the same lines about how valuable it is to have face time in a startup, and maybe someday when they’re bigger, they’ll look at remote work options.
I don’t want to insult any of my friends and mentors. People can be really brilliant about some things without being experts at developer productivity, but at the risk of ruffling a few feathers, that recycled line is absolutely ludicrous and totally disconnected from reality. There’s considerable evidence to the contrary.
What are offices really like for startups? Jason Fried says it better than I can.
But the worst part is, for startups on a tight runway, using money for office space is like piling tens of thousands of dollars together with some logs and gasoline and starting a bonfire with it. Repeat every month.
Ever wonder why they call it burn rate?
There is an alternative.
Trust Your Team
Having employees in your office isn’t about being more productive. It’s really about trust. Do you trust your employees to be productive when they’re not in a place you can watch them? Do you trust them to make the most productive use of their time? If your answer is no, why on Earth would you hire them in the first place?
Remember, you’re looking for the $1MM/year+ employees. Obviously those employees are self motivated. They want to play to win. They’re not going to sit at home watching TV when they should be working. They’re going to be obsessively thinking about the exciting challenge you’ve given to them.
They’ll be dreaming up solutions in their sleep. Innovating in the shower. Trying hard to forget about it long enough to participate in family conversations at the dinner table.
The employees you want on your team care deeply about the problem you’re solving, and they’d work hard on it for free if they could still support their families.
If you hire the right people, you can relax. They’ll get the work done and then some. The best ones will get more work done than you ever dreamed possible. They’ll find your inefficient processes and replace them with better ones, improving the productivity of your whole team.
The Talent Pool
Team building is your biggest challenge. When you make people come to an office, you put an artificial limit on the talent pool that you can draw from. It’s very challenging finding the $1MM/year developers when your pool is the entire world.
It’s orders of magnitude harder to find one in San Francisco — especially in a market where you’re competing against a huge cross section of venture backed companies advised by the most tech powerful influencer network in the world.
In Silicon Valley nearly half of startup employees (45%) are from outside the United States. I have led many global talent searches. If you require your employees to be in the office, you’ll need to get really familiar with the expensive and time consuming visa process.
Startups outside the top ranking tech cities should prepare for the same, because the best talent in the world clusters in those hotbed cities around the globe. If your city isn’t among them, you’ll be paying for a lot of moving expenses.
Happier Employees
I was introduced to remote work at Adobe. I was hired to work in the San Francisco office, but most of the team I was assigned to lived and worked in Seattle. Since all my meetings were by video chat anyway, I decided to stop commuting, and started working from home.
The moment I did that I realized something amazing. I got a lot more work done. I had long stretches of uninterrupted time to work on problems more effectively. It turns out that interruptions in the office were costing me about 3 hours per day of productivity, and virtually eliminating the long stretches of uninterrupted time I needed to clear the big hurdles.
Every good employee wants to feel like they’re making a valuable contribution to the business — that the work they’re doing matters.
Another effect I noticed was that I got to spend a lot more time with my wife. Of course that has immeasurable value that led to a tremendous improvement in our quality of life.
The surprising thing about it was that I started attributing those positive life impacts to Adobe. I had a stronger sense of belonging and loyalty when there was a better balance between my work life and my personal life.
I started to care a lot more about the company I worked for than I’d ever felt before about a company where I was not a founder. When I did see my fellow co-workers face to face, it wasn’t the regular mundane routine. It was a special occasion that felt more like a family reunion.
Good Company
There’s a company that started 100% remote which has grown into a recognized leader. It’s called Automattic, and they make the most popular content management system in the world*, WordPress. My wife and I met Matt Mullenweg during one of their regular in-person gatherings, and the energy was inspiring. Matt has a lot of interesting things to say about how they do things at Automattic.
Who else has embraced remote work?*
Adobe, Amazon, Apple, Autodesk, Dell, First Data, Intuit, Polycom, RedHat, Salesforce, SAP, VMware, Xerox, and a whole lot more. These are companies who have the resource to compare distributed teams and in-office teams. The fact that they hire remote employees clearly says that remote work can work.
If it can work for a company who can clearly afford a large number of physical offices, it can work well for a startup.
Software Quality
Modularity is the single most important technical factor in your ability to test and change your product quickly. According to Harvard Business School, “Distributed teams tend to develop more modular products.”*
You’re building software to scale across a distributed device infrastructure. Doesn’t it make sense to create a distributed team?
Social Responsibility
San Francisco is basically the epicenter of the tech world in the US. People flock to it from every part of the globe to launch their tech startups in an environment where two city blocks in SOMA have more invested venture capital than entire states and countries, elsewhere.
San Francisco’s rent prices are 3 times the national average. Workers earning less than $100k / year struggle to afford moderate housing inside the city, and every area reachable by public transportation near San Francisco also suffers from elevated rent prices.
In other words, forcing employees of San Francisco tech companies to live or commute into San Francisco contributes to the forces that are driving San Francisco’s former middle class into abject poverty and homelessness.
To learn more about how you can help turn that around, see “The Cure for Homelessness”.
Ultimately, software is about helping people. The best guarantee of success is to let empathy drive you.
Next Steps
One of the most impactful changes a development team can make is to embrace a culture of mentorship. I recommend that every developer on your team be paired with a mentor who works with the mentee at least a few hours each week with a focus on professional development, learning new things, and pair programming (with the mentee as the driver), and live, interactive code-reviews.
When you hire new developers, you should enroll them in an intensive mentorship program for the first 6 months, focusing more of their time to ramp up to the skill level of the more skilled members of the team.
Your most senior developers should also be paired with mentors who can help them take the next step — but it may be hard to find mentors to pair them with.
I went out searching for a mentorship platform to find qualified mentors to help onboard new hires and mentor senior developers, and I couldn’t find one, so I cofounded DevAnywhere.io. We developed an advanced JavaScript curriculum, started mentoring developers one-on-one, and the program has produced some spectacular results.
If you need mentors for your team leads & new recruits, we can help you out.
Level Up Your Skills with Live 1:1 Mentorship
DevAnywhere is the fastest way to level up to advanced JavaScript skills:
- Live lessons
- Flexible hours
- 1:1 mentorship
- Build real production apps
Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and cofounder of DevAnywhere.io. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.
He works anywhere he wants with the most beautiful woman in the world.
