MarkedUp Analytics’s customers are developers and so are most of the people who work at the company, so I spend a lot of time thinking about and refining my answers to the following two questions:
- What are the lowest common denominator skills and programming knowledge that my customers have?
- What are the lowest common denominator skills and traits that the developers on my team need to have in order to best serve our customers?
As I’ve been exposed to more customers and as I’ve turned over members of our team I’ve started refining my answers to these questions.
Turns out that most of our customers are fairly sophisticated and thus I expect the developers on our team to be one step ahead of them.
I’m sure every company says this, but in our case it’s true: we need elite developers in order to solve our customer’s problems.
MarkedUp builds distributed systems that integrate into native third-party applications, written by our customers, on multiple platforms and use machine learning to create insights in as short a timeframe as possible, a task that’s many orders of magnitude more challenging than your average iPhone or web application.
There are companies like DataStax or Liquid Robotics that have to deal with radically harder problems than ours, and I’m amazed by their ability to attract really great engineering talent. So this problem is solvable, but how do I identify elite developers who are going to be able to contribute to the business and tackle these challenges?
I’m still figuring it out, and I’ve made some big mistakes along the way thus far. But I’ve had some successes in attracting great engineering talent to our company too. Here’s my opinion on what makes a software developer elite (your mileage may vary!)
An elite developer is determined more by their character, attitude, intellect, and diligence more than anything else. Knowing any specific framework, programming language, design pattern, development platform, and so forth isn’t nearly as relevant.
So what character traits does an elite developer have?
Humility – the best developers I’ve worked with know that they are talented but don’t know just how good they are relative to their peers. Even if they did know, it wouldn’t change their attitude. They do the best job that they can and do it knowing that their work isn’t perfect; contains bugs; might not completely meet the spec; and might be changed in the future.
Able to accept criticism – part and parcel with humility is the ability to accept criticism, whether it comes from a peer, a customer, a manager, or anyone else. Whenever you do anything of consequence you should expect criticism from some corner of the universe. Elite developers not only accept it, but they listen to it and try to distill actionable insights if possible.
Doesn’t let good be the enemy of perfect – a lot of talented developers struggle with perfectionism, myself included; over time the great ones learn to live with impurities and get software deployed to production while the perfectionists piss time away on remote edge cases and other activities with no economic value.
Inquisitive – some of our interview questions at MarkedUp are live-coding exercises, and here’s a little secret: we really don’t care very much about the quality of the code produced by a candidate during an interview.
But we care a lot about the questions a candidate asks about the programming challenge.
If a candidate starts coding right away without asking us any questions about the scope of the challenge or the technical details, it’s usually an instant fail. Inquisitive developers do a much better job of learning how their code fits inside a larger system and learning about the real-world use cases for it.
Independent learners – the developers who’ve delivered the most value for me are ones who constantly want to learn and improve their skill set; they ask if they can pair-program with me while I work on our API or on the SDK; independently review some of our code and create JIRA issues for me when they find bugs with my own code (!); they buy O’Reilly books on some of the technologies we use, like Hive and Hadoop, and read them over lunch; and they ask if they can leave work early to attend a tech talk or even give one themselves (!).
Everyone needs help along the way, but the truly great developers are the ones who learn for the sake of learning and the satisfaction of self-improvement. It’s humbling to work with this type of developer, because typically they get other members of the team excited about learning too and turn this into a group activity.
Able to break down large projects into small tasks – people don’t launch rockets or build massive systems by setting out to do everything all at once; they break down massive projects into smaller milestones and small, fine-grained tasks. Really strong developers have the ability to visualize the end in mind and the steps for getting there. It’s an essential skill for an architect of any sort.
Able to visualize relationships between abstractions – part and parcel with the previous point, really great developers have the ability to visualize relationships between abstractions in the systems they work with and build. This can be as simple as being able to see how services interact with each-other in the course of fulfilling an end-user’s request or how classes should be composed inside any given system. This allows a developer to work on a small part of a really large system and understand how their work will integrate with components that aren’t finished or haven’t been started yet.
Embraces challenges – great developers can operate outside their comfort zone, even if it means failing initially. Challenges are viewed as an opportunity to learn and improve, not as a threat to appearance and performance.
Focuses on immediate results – sticking with the previous analogy about launching rockets, great developers break up their work into small deliverables and ship small pieces immediately and frequently into a development branch. They don’t hoard commits or wait until “it’s done.” They ship small deliverables often.
The traits above are the most important ingredients of a great developer, but there are learned and acquired behaviors that every developer must develop before they can become elite.
Unconsciously, religiously commits everything source control – the greatest sin you can commit as a developer is failing to put something into source control for you deploy it. Most companies try to automate deployment in such a way that it’s impossible for deployment to occur without source control involvement, but this isn’t always feasible. Little things like shell scripts, SQL queries, configuration files, and others often fall between the cracks since they aren’t considered part of “the app.”
However, a great developer is religious in their use of source control – anything that gets used in the course of regular business, even a one-off business intelligence script, finds its way into source control when an elite developer is behind the wheel. They rack up pull requests and HipChat spam with religious fervor, because they live in perpetual fear of being the stupid asshole who forced someone else to reverse-engineer a critical backup / restore script during an emergency.
They master their source control system, make liberal use of feature branches and version tags, and clean up after themselves once a feature goes into production. Source control is as natural to them as breathing.
Writes README files, comments, and docs even for internal tools – I tell every developer this when they start at MarkedUp “your code will be a part of this organization longer than you will.” The point of that is that people change careers, companies, and jobs frequently – so when we write a piece of code that does something important, we need to make it possible for someone else to use and modify it without us present to answer questions.
Great developers recognize this and make it easy for other developers to leverage their work, during and after their time on the job.
Embraces bug tracking and agile processes – organizing your work is just as important as performing it, and bug tracking / agile tools like Pivotal Tracker and JIRA enable teams to prioritize and distribute workloads across large projects.
But more importantly, they allow PMs and peers to see what work has been completed / performed without having to hold numerous meetings or calls. Bug tracking, pull requests, and agile boards are communication tools – and great developers embrace them for efficacy in measuring, quantifying, and communicating progress.
Masters debugging, tracing, and monitoring methods – just because the code is in production doesn’t mean it’s finished. Great developers master the tools they use for debugging, logging, tracing, and monitoring apps that are in production or are about to be.
In the .NET universe, this means mastering the Visual Studio debugger, Fiddler, IntelliTrace, the Windows Event Viewer, performance counters, and others. In the OSS world this might mean performance monitoring tools like Graphite and Nagios, or others.
Great developers understand the necessity of these tools and master them, which enables them to respond more quickly to infrastructure failures and bugs.
Communicates concisely and asks relevant questions – most developers are not social butterflies; like any STEM field, it’s often populated with introverted people who like to spend most of their working hours concentrating on issues at-hand.
However, the elite developers are ones who recognize what needs and doesn’t need to be communicated – if there’s something contradictory in a customer spec, it needs to be raised with the stakeholder. If someone broke convention and used camel case instead of PASCAL, just go fix it and send the offender a note, not the entire team alias.
Engages other developers on the team – programming is a team sport, and elite developers love working with other people whom they can help and who can help them. They ask for and solicit help when necessary.
Now for the programming part – what skills does a programmer need to have before he or she can be considered elite? This is subjective and sometimes domain-specific, but there’s my take.
Experience with multiple languages and platforms – diverse taste in tools is the greatest skill that a developer can have, because it keeps the developer on a position where they know how to learn new things if necessary (and it often is!)
Being a one-trick pony and limiting yourself to a single platform will naturally limit your ability to grow and learn, so great developers try their hands at new things even if it’s just for fun.
Understands language / framework implementations – the most powerful .NET developers I met prior to joining Microsoft all highly recommended that I read this book: CLR via C#. I did, and the content from this book was directly responsible for passing my technical interview at Microsoft. Above that, it’s changed the way I look at all of my .NET code.
Understanding your how code is executed at the OS or hardware level can provide some huge benefits, especially if you’re doing a lot of work with concurrency or native programming. For instance, understanding how SQL Server’s row / table locking algorithms and its journaling system work allow you to design around potential performance bottlenecks in high-performance systems. Great developers learn these implementation details and leverage that knowledge to write more robust code.
Writes code for patterns, not specific instances – it’s an intuitive skill that can’t really be learned, in my opinion. You either have it or you don’t. Really talented developers infer the patterns in a system, even before a module or a piece of code is written and they code for those patterns, rather than specific instances. This skill limits technical debt and results in a tighter, more usable codebase.
Knows how to learn – this might seem obvious, but I’ll reiterate: there are a lot of developers who simply do not know how to learn something new. They can ape examples they’ve seen before and often need to be hand-held along the way, and they can’t truly internalize a new concept and form the muscle memory to code independently with new technologies.
Great developers know their mind and know how to teach it something new – what works for one developer may not work for another, but nonetheless they all know how ot learn.
Has experience with multiple types of software (native, distributed, web, etc…) – a great developer is a well-rounded developer; if your only experience doing software development is with simple CRUD applications, then you’re missing out on a lot of the corpus of modern software development. A great developer isn’t necessarily an adept professional in each domain area of programming – they might focus primarily on web development and dabble in native, but they take away new lessons from each experience and understand more about computing overall.
Until I wrote the MarkedUp SDK, I never had any practical experience with advanced data structures in production like concurrent binary heaps and circular buffers; I likely would never have encountered those had I stuck to doing just ASP.NET MVC or Node.JS development all the time. Now that I have that experience, who knows – I might find some applications for those in a distributed program or a Web API application in the future.
Experience with multiple types of development tools (IDEs, Text Editors, command line compilers, and more) – I have some bad news: if you’re an EMACS ONLY or VS2012 ONLY developer, you’re limiting yourself. Experience with multiple types of development tools is a good thing, because great developers recognize that improving your workflow habits over time is just as important as improving your programming knowledge and experience.
Some sysadmin / operational knowledge – writing the code is only the first step; deploying it or releasing it comes next. Great developers are not often expert system administrators also, but they know enough about their operating environment to avoid pitfalls and execute a basic deployment if necessary.
Knowing how to run a build / release process, deploy a piece of server software to production, or how to configure a piece of COTS software like Apache or IIS to host a web application is critical to ensuring that the software actually meets its functional requirements. If you aren’t able to produce a development build of a native app using compiler flags, then you can’t very well participate in that part of the QA process, can you?
The point is – great developers don’t wait for someone else to solve their problems; they can do enough sysadmin work to build and test on their local environment, and are self-aware enough to not proceed any further if they don’t know enough to run a live deployment.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Since going full-time on my own startup 6 months ago, I’ve spent a lot of my time recruiting, evaluating, and working with a lot of different developers. My startup, MarkedUp, is an analytics provider for Windows 8 apps (and eventually, other platforms.)
Our technology is sophisticated and difficult even for large companies to master, so the bar is pretty high for developers who join our team. We’re selective about who we work with, but even with careful recruiting practices it’s still difficult to find developers talented enough to pull their own weight on a complex product like ours.
So I want to help average developers who want to improve by calling out 10 performance-killing behaviors that stagnate the careers of most developers.
Most developers stagnate both intellectually and productively after 4-5 years in industry; they adopt some tools, pick up some patterns, learn a language or two, and maybe they’re even able to work at a successful company and contribute to some important products. Great!
But what happens when you hand a developer a blank sheet of paper and the opportunity for them to own a product?
Most of the time: chaos and failure.
Many developers fantasize about being able to own a product and make big technical decisions, but the truth of the matter is most of developers can’t handle anything more complicated than building formulaic CRUD Rails websites using the same 30 gems each and every time.
So what are the behaviors that limit the growth of average developers?
You’re too afraid of failure to learn new tools / languages / frameworks.
During my first quarter at Microsoft I gave a talk to the LA .NET User’s Group on ASP.NET MVC3, which was in beta at the time. For the most part the attendees asked me thoughtful questions and showed a legitimate interest in what the ASP.NET team was cooking up in Redmond.
However, there was a trio of attendees who kept asking me a very suspicious set of questions:
“What are the weaknesses of ASP.NET MVC3?”
“Isn’t ASP.NET MVC too unstable for use in the enterprise?”
“But doesn’t ASP.NET WebForms already do a better job?”
I realized shortly after the Q&A was finished, when I had a chance to speak to them privately, that they were attending my talk to actively look for reasons why ASP.NET MVC shouldn’t replace WebForms at their place of work!
These developers were so afraid of trying something new and possibly failing that they actually went out of their way to research just the talking points they needed to not have to learn it!
This is an extreme example, but the point is the same: average developers cling to their favorite tools and stop learning new ones because they worry that leaving their pet languages and tools behind invalidates their years of experience.
Strong developers embrace the challenge and opportunity to learn new ways of doing things.
You won’t push your commits until the feature is “done.” (It’s never done!)
We call this “commit hoarding” at MarkedUp. This happens with developers who don’t have the confidence to tolerate criticism or scrutiny from the rest of the development team try to hide their work until it’s in a “finished” state.
Ultimately these developers hurt the productivity of the rest of the team, because we lose visibility into their daily output and they tend not to ask for help in the course of regular development. They’re responsible both for delays in shipping and for lots of last-minute bugs.
Strong developers recognize that they are not their code, and thus will put code out in front of the rest of the team more frequently and take criticism and suggestions with dignity and confidence.
You know just enough to be dangerous.
In an age where it’s become a lot easier for developers to work with threads, concurrent programming, distributed databases, and so forth you run into a lot of devs who can talk a good game. They can tell you all about thread pools, a hot new design pattern, or why a headless database is better than a masterful one in some scenarios.
They are able to know what something is and its potential benefits, but they don’t understand it.
I’ll give you a recent example: in C# 5.0 Microsoft recently introduced the async and await keywords, which make it radically easier to create and manage asynchronous callbacks. These keywords have even lead to the rise of some exciting new concurrent programming patterns like the TAP pattern.
However, do you know what this keyword has also lead to? A ton of average developers who suddenly think they can harness the awesome power of multithreading simply by wrapping every I/O call into a Task object in C#. They do this blindly, without any thought as to the costs of context-switching, multi-thread access to shared resources, and more.
And this creates dangerous, unpredictable, and very-difficult-to-test code in the hands of average developers who blindly uses this new toy everywhere.
Good developers not only know what something does, but they seek to understand why it was done this way and under what conditions it should be used.
Sometimes you’ll hear a member of our development team say “dude, stop Gandalfing the documentation and start coding something,” referring to the scene from The Lord of the Rings depicted above.
Analysis paralysis is a classic problem that affects lots of average developers; it’s often a problem of over-analysis, but in my experience the root cause is usually fear of making a bad decision.
Research is easy – implementations are hard! As a developer, you don’t want to make a mistake when it comes time to do the actual work. So just research the issue until the heat death of the universe and you’ll make a perfect decision for which you won’t ever be criticized!
Average developers worry about looking bad or making a mistake – they want to get it right on the first try.
Strong developers who are in unfamiliar territory don’t care – they’ll write shit code, unit test it, and throw it away in 45 minutes if they don’t think it can get the job done. Strong developers actively limit the amount of time they spend researching, because they recognize that it’s a trap – it feels like work but often isn’t.
You don’t invest in your tools or development process.
Average developers will spend a lot of time learning how some fancy new language feature or API works. They’ll invest a ton of time mastering the minutia of the Windows runtime or some new D3-based charting framework, but at the end of the day that doesn’t change the fact that they’re still average developers who churn out mediocre work at a glacial pace.
If you want to be a talented developer, you have to invest time into improving your skills and knowledge, and the number one factor that separates the men from the boys in most software markets is the ability to turn out production-grade code quickly. You can have both good code and speed – but you have to invest in your process you use for building it first!
Average developers don’t invest in their tools, their process, or their environment.
Think about it – when was the last time you took a step back and thought about the way you test your code or how you look for bugs? Have you tried experimenting with different types of abstractions for the same problems and seen which one produces more maintainable code? Have you tried picking up a new IDE or text editor to see if it can help speed up common tasks? What about investing in build or deployment automation?
Often times, the biggest improvement you can get as a developer isn’t focusing on improving the code you write – it’s optimizing your process for writing it.
Free protip for anyone who follows my blog regularly: the biggest improvement I’ve made in my own development process easily is decreasing my usage of interface-driven design and dependency injection. I do a lot more work using static classes and compositions these days and it results in radically less code to test and maintain.
You’re too embarrassed to ask for help.
When we started digging into the guts of Hive for some of our work at MarkedUp, we got a little stuck on how to tackle some problems we had specific to our use case. So what did we do? We reached out to one of the guys who wrote the O’Reilly book on Hive and asked him over LinkedIn. And he replied back!
We try to be self-sufficient developers to the furthest extent possible, but we also know when it’s more economical to simply ask someone for a favor versus beating our heads against our desks for hours on end.
Average developers get embarrassed and don’t want to reveal their ignorance, so they pretend they know what’s up until they commit some sort of horrible fuck-up in the codebase itself.
There is nothing wrong with saying “I don’t know how to do this.” Strong developers know this, so they go and ask for help when they’re stuck.
You don’t know how to make it easy for other programmers to work with your code.
Like an only child growing up, you never learned how to share your toys with anyone else. The same goes for your code – you developed some bad habits and an over-abstracted style that is impossible for other developers to follow.
An important part of working on any technical team is human parallelism – the ability for multiple people to be able to work simultaneously on the same codebase. But it’s also important for teams to be able to work asynchronously too – I should be able to make changes to your code when you’re away, and vice versa.
Average developers don’t think about their code this way – they simply set out to do a task and write it through to completion with the assumption being that they will always own that piece of code. Strong developers understand technical debt and try to limit it by designing code that is as maintainable and self-explainable as possible.
Writing readable code really requires developers to change their outlook – your code should last longer in the organization that you.
You don’t know how to read someone else’s code (or don’t want to.)
It’s an interesting paradox – average developers can’t handle a blank sheet of paper very well, but they can’t write the last 30 pages of a novel in progress either. Average developers are really hesitant to try to learn an existing codebase and often have to be handled all the way through it until they’re able to produce something.
A drastic example is when an average developer is brought in on a codebase written in a language / framework that they aren’t familiar with and will immediately want to rewrite it without a second thought to business value or time to market. It’s a type of pain avoidance – having to live with the precipitation of some other programmer.
Strong developers accept that the business costs in a rewrite are usually unacceptable and should be avoided, and they’ll diligently try to understand, learn, and modify the existing codebase sitting in front of them.
Reading code is harder than writing code, but strong developers invest time into learning how to excel at it.
You can’t code from the end-user’s point of view (you think too small.)
Average developers who manage to make it a lot closer to the “great programmer” end of the bell curve usually trip up here. You may have mastered some of the technical details and you may know how to work with other developers, but you’re still missing the most important piece: being able to see your code from the point of view of the real-world.
As a programmer, you job isn’t really to solve technical problems – you solve technical problems in order to solve business problems.
An average-to-bad developer will chase technical problems down deep rabbit holes without remembering why they were solving the problem in the first place. You’re not upgrading the version of MongoDB you’re using because there’s inherent value in upgrading – you’re upgrading because your team agreed that it was worth taking the risk to upgrade because of potential business upside due to new features / performance / reliability / whatever.
More offensively, average developers struggle and fail to produce anything of business value from scratch. When asked to design a new feature based off of a simple customer story average developers will take a rigid, literal interpretation of the story or spec and ship something that is barely useable by a human.
Average developers don’t anticipate other related use cases; don’t think about the end-user’s experience; and basically have to be managed heavily when working on anything user-facing. This is why so many of them get stuck writing line of business apps instead of products.
Great developers look at their code from the perspective of the end-user. How do I make this easier to solve my user’s problem? What are some other facets outside the literal content of the story that might make this feature even better for an end user?
If you’re a developer and don’t ask yourself these questions, then you’re not a great developer. You’re passable at best.
You aren’t able to judge the business value of any programming task.
Related to the previous issue – many technically strong developers fail to realize their potential due because they aren’t able to take a step back and look at their work from the perspective of the business or organization itself.
Strong developers are able to self-manage and make good business decisions about how they choose to invest their time. They’ll ask questions like:
Is this the most valuable thing I should be working on right now? How much time should I invest into doing this? Given the deliverables I have due in two weeks, is there something I can invest in right now that will make it a lot easier for me to hit that target?
Average developers don’t – they’ll take a spec and blindly implement it until it’s finished, without accounting for how their work relates to the company’s business goals and impacts other members of the team / other business groups.
The highest cost of any engineering team is development time, and average developers waste lots of it on minutia and technical tasks that are ultimately low business value.
If you want to be a better developer, it starts with changing the way you look at your code and how you program.
You have to understand and appreciate the business costs behind each line of code you write. You have to be able to step outside of your text editor or IDE and look at your work from the perspective of a customer or end-user.
You have to accept that your code will outlast you in any organization your work with, so design everything to be inherited by other developers one day.
Most importantly, never be afraid to take on new challenges and ask for help along the way. You won’t improve working alone in the corner on technologies you’re already familiar with. Software development is inherently social – learn how to bring other people into the experience.
If you enjoyed this post, make sure you subscribe to my RSS feed!
I posted a little while ago about the job market for technical talent at early stage companies, and I promised a follow-up post on what you should look for in a developer when your company is at a critical, early stage. This is that follow-up ;)
Our company, MarkedUp, is still in the process of building out its early engineering team; however, we’ve had some success in finding the right type of people we want to work with – a process that wasn’t quick or easy, but will pay off massively in the long run.
When it comes to hiring developers for your early stage startup, here are the questions you need to think about:
1. What are you optimizing for?
At this stage in the evolution of MarkedUp, we optimize for changeability and reliability – the ability to change things on the fly quickly and do it in a way that doesn’t interrupt the service of our customers.
This means that we have to recruit people who are architecturally sound with .NET, are able to learn new technologies quickly, and are good at socializing / articulating problems and design considerations to the team.
When we evaluate a developer for who’s considering joining our team, we look to make sure that they have experience with multiple technology stacks, have a well-written technical blog or are at least conversant in their respective technology areas, are versed in design patterns and can explain their architectural thought process on-demand, and have well-defined goals with regard to how they want to grow and develop.
For your company, you might need to optimize your engineering team differently – if you’re building a big consumer app, you might need to optimize for developers who have a good balance of front-end and back-end skills initially.
Make a deliberate choice about what your engineering priorities are and let that set the top of the spec for your recruiting.
2. Do you need soldiers or chiefs?
One mistake a lot of startups make is the seniority issue: hiring people who are too senior or not senior enough.
People who are too senior might demand a lot more equity / money / power / titles early on in the life of your company, which creates problems if you ever need to bring in even more senior people over them if you don’t manage it correctly. Additionally, senior developers bring a career’s worth of habits and experience into your company – which isn’t always necessarily good.
Conversely, evaluating a fresh-out-of-college CS grad to CTO isn’t a great decision either sometimes – they might not even know just how horribly they’re screwing up your company’s technology until years after the fact.
On top of the issue of experience, you also have to consider the person’s ambitions – do they want to be an executive in the company one day and have people reporting to them? Are they even capable of doing that one day?
Again, make a decision: do you need people with experience and authority who will lead the engineering team or do you need people who just want to do the right thing and make a difference, but don’t yet want to be involved in management? Recruit accordingly.
3. Can your company afford to train developers on your technology stack?
Do you need people who’ve been working on a single technology for 5+ years, or just people who are smart and want to learn?
If you’re a really early stage company, then you don’t have the luxury of time or money to invest much into a new employee who is totally unfamiliar with your chosen technology stack.
If you have the time and money to invest into training good employees, do it.
Investing into training will widen the pool of acceptable applicants dramatically because you can tailor your recruiting process to target a smaller number of things. Be realistic about your resources and the availability of your existing engineers to train the new folks, and then decide accordingly.
4. What’s important for your engineering culture?
You know what makes a huge difference in MarkedUp’s culture? Being passionate about development – we like people who have pet projects in their spare time; take the time to learn new languages and platforms; and love to talk about what they’ve done and what they’re doing.
We build products for developers – passion for development makes us more relatable to our average customer, who is typically someone building a Windows 8 application in their spare time because they love doing it.
Your company may be different – you may want to recruit people who are really into music if you’re building a media-oriented company, or people who are very algorithm / math-oriented if you’re doing a lot of work in a field like NLP or predictive modeling. Maybe you want to run a really structured environment and want people who are going to be in the office every day.
Company culture is ultimately something that will take a life of its own, organically, but during the formational stages you have a massive amount of influence over it as a founder. Pick people who fit your vision for what the culture should be and be conscientious about it.
5. What’s your level of urgency?
Trick question. The answer is “super urgent” in every early stage company. Unless you’re profitable / growing, every day is a race against the clock and the bank account.
You can’t afford to keep people around who don’t get that and won’t work hard to make sure the hard problems are solved on-time.
A lot of developers, particularly ones who’ve been in industry for a while, approach startups with the expectation that they can still work from 9-5, get the same benefits they got at MegaCorp for some relatively low level of output, but get a giant chunk of equity and work on cool, consumer-facing startup products without any bureaucracy or managerial overhead. Avoid these developers.
Hire people who want to race the clock, because they believe in your company’s vision and want to work with other competent people who can move quickly. They’re out there.
If you do a good job coming up with clear, thoughtful answers to these questions then good fits and bad will be obvious.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Shortly after leaving Microsoft to work on MarkedUp full time, my founding team and I joined an early stage accelerator here in Santa Monica. We’ve gotten a tremendous amount of value from it so far, and the directors of the accelerator have done a great job helping me prioritize and do all of the things I need to do in order to launch MarkedUp properly.
One of the things they’ve had us do is gradually step up our recruiting efforts, and for the little we’ve invested into the recruiting process so far the results look pretty good.
Most startups at this early stage are founded by 1-2 people who have unique insights and connections into a market, have done some work to validate a new business concept in said market, and are now trying to form a team to help them execute and eventually scale it. Usually the first hire a startup has to make is a founding engineer who can help them build a customer-ready version of the product.
MarkedUp is a little different. Our engineering team is the entire team, at the moment – I’m also our “business guy” in addition to being the technical lead and Erik, a founding member of our team, is 100% committed to technical endeavors. However, we still have to recruit developers! MarkedUp is solving a big, complex problem – analytics and data visualization are problem domains with large technical surface areas, so even early on in the lifecycle of our company we have to expand the engineering team.
I’ve been asked a couple of times recently by founders in the first category of startup “how do you find and recruit developers?”
The short answer is “I’m still figuring this out, being new to running a startup myself, but here are some ideas.”
So in that vein, I thought I would share with a wider range of people how I try to recruit developers for MarkedUp and what I think is most important.
Take everything I say with a grain of salt – I’m new to running my own company and am figuring out much of this as I go.
Things You Should Know about the Market for Software Developers
Before you start recruiting, you should wrap your head around the market for software developers. Having this information will decrease the likelihood of you making an ass out of yourself when you start recruiting in earnest.
1. It’s an employee’s market – there’s far more demand for developers than there is supply.
The demand for developers has always been high since the PC revolution and the past few years have been particularly high. So what’s the practical implication for your startup?
The answer is that any competent developer in the US can get a six figure salary, with amazing benefits, from a variety of well-funded, stable employers. Before you even start recruiting you’ve already lost the battle of benefits and compensation.
So when you’re recruiting, don’t even bother leading with the promise of wealth, big exits, or any of that sort of puffed-up-chest nonsense. The reality is that most startups fail and if any developer evaluates the prospect of working for you versus their six-figure employer, you will assuredly lose on opportunity cost every time.
2. All of the competent software developers you want to hire already work for someone else. Not only do you have to convince them to join you – you also have to convince them to leave a paying gig.
Let that sink in for a moment. How hard is it to leave a job? If you give a shit about what you do, then the answer is “pretty hard.”
Convincing someone to leave a gig, even if you have a great opportunity that is more interesting, is a challenge unto itself unless that candidate is utterly miserable with the state of things at their current job.
So, be prepared for a long, dragged-out process for each technical hire – you will have to deal with counter-offers, ludicrously good counter-offers even. Don’t hardball your candidates with “join us now before we raise money and offer you less equity” – keep them sold on the things that money can’t buy: working on projects that they find meaningful, working with people they like, learning new things, and so on.
3. The best source of “available” developers are recent graduates.
If you followed point #2 above, then what I’m about to say next should resonate: the best source of developers who are openly looking for work is recent college graduates.
Many of them get passed over by big software development shops like Microsoft / Google / et al because they don’t have enough time behind the wheel; this is exactly what happened to me when I was graduating from Vanderbilt with good grades, a successful freelancing track record, apps in market, and good recommendations.
On top of being available, recent grads have the absolute best risk profile for working at a startup. They have no obligations, no mortgages, no expectations of six figure salaries out of the gate – they just want to work on something cool and take home enough money to start building a life for themselves.
There is a downside to hiring recent grads, however: having no experience means what it means! You’ll have to invest a lot of time into training them all of the things they didn’t learn in school, which in some cases includes the ability to code.
Truth be told, I only recommend going the route of hiring recent grads if you already have a CTO or another veteran onboard who’s willing to train and coach them.
It’ll take a while before you can get an acceptable level of output out of a recent grad, but as long as you continuously invest in making your new hires better they will (1) stick around because they’re learning and improving and (2) will deliver output at startup speed.
4. It is phenomenally easy to start a company and raise money in 2012 compared to earlier years, and the most senior technologists who fit the risk profile for startups are able to start their own companies.
One important facet that’s overlooked about the technology market for software talent, especially among startups, is just how easy it is for top-tier technologists to start and launch their own companies.
All of your prospective founding CTOs who are interested in startups and have an idea they’re really committed to could probably raise money and build a v1 product themselves; so how does this affect your ability to recruit?
It dilutes the market for talent – spreads the small slice of the Venn diagram of all developers who are willing to work for free on a high-risk idea across a much larger number of smaller companies. So what’s a startup founder like you to do?
Invest some effort into helping any talented developer who’s trying to build their own company be successful, because even if that developer is unavailable to help ease your pain now they’re someone you want to build a good working relationship with and maybe work together later.
I never try to steal someone away from a project they’re deeply, personally, and fully committed to, nor do I ever suggest something stupid like merging two totally irrelevant ideas together into one company just so we have more developers on the team. Recognize that recruiting is a long-running process – it takes a long time to find the right people.
It’s in your best interest to be someone developers trust, not a self-interested jack ass who constantly tries to poach them away from their passion projects.
“Pay it forward” is my advice here, and for your short term needs – don’t even bother with people who are trying to get their own projects started. If they decide to can their project, they’ll come and approach you if you’re someone they trust and would want to work with eventually.
I’m going to write a second post on our philosophy when it comes to actually recruiting developers and what we think is important.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Earlier this week I made a pilgrimage up to the Bay Area to visit some mentors – I came seeking advice from entrepreneurs who’ve done work relevant to our interests at MarkedUp, mostly to learn how to address some “known unknowns” that have been keeping us up at night.
One of the people I had a chance to speak to is an experienced CTO and we started talking about development priorities in early stage companies like ours. Mid-way through our meeting we had the following exchange (paraphrased:)
Me: so I’m trying to figure out my priorities in terms of what I personally spend my time working on – I have to juggle recruiting, product, fund-raising, customer development, project management, and working on the actual codebase all myself until we start expanding our team.
CTO: what have you been working on most recently?
Me: this weekend I learned how to script against a build system we want to use to help automate the complexity out of our deployment process; I prioritized that ahead of working on MVP features and am not sure how I feel about it.
CTO: two startups ago, we were building a service in the telephony space. We had a lot of trouble recruiting engineers who knew anything about low-level telephony protocols – they were hard to find, thus we had trouble expanding our team.
Ultimately what I decided to do was to build an abstraction layer on top of all of the telephony protocols themselves, our goal being to simplify the amount of work a developer on our team had to do to make things happen with our service.
What this allowed us to do was recruit younger, smart people who had no prior experience at all with telephony systems – and they were able to be successful in our development team because they could get the work done without the overhead of having to learn these telephony protocols. And this solved our recruiting problem.
The lesson here is fantastic, and I suspect lost on a lot of engineering team leaders: if you have only one place to spend your (development) time, spend that time on tasks that increase the effectiveness of everybody else on the team.
So this past weekend, I spent my time:
- Developing a component that takes an easily-fuck-up-able task from our application runtime and makes it more predictable and reliable and
- Learning a build system that we are going to use to make our build and deployment process standardized, predictable, and less dependent on human factors.
Turns out, working on those things instead of developing a handful of features necessary for our MVP was the right call – even though it’s painful to defer work on the product with impending deadlines looming. It was the right call because it eliminates errors and speeds up the work of every person on the team, including me!
If you enjoyed this post, make sure you subscribe to my RSS feed!