I walked out of the meeting (I forget the subject or if it was being run by NASA or DOE project management) in a slightly numb fog. Another engineer a few years my senior mused, “I think we are being mushroomed!”. Never having heard the term before, I incisively inquired, “Huh?”.
“Mushroomed”, he repeated, “kept in the dark and fed on shit!”.
It is a phrase that I have used more than once in the intervening years when I have felt that politics or incompetence have prevented someone I am supposed to be collaborating with from sharing crucial information with me, depriving me of the opportunity to make objective decisions and control my own destiny.
My objective here is to help you, the innocent software engineer, avoid being mushroomed.
I arrived in California in the summer of 2000 (Flag Day, to be precise) with the intention of spending a year working on a particle physics experiment at the Stanford Linear Accelerator Center before returning to Edinburgh to write my thesis, and parlay a Ph.D. and “international experience” into some kind of well-paying job.
I never left.
In the intervening nineteen years I have written software for a space telescope, and for prototype data centre switches. I have led teams building security products, and enterprise storage products. I co-founded one SaaS startup, and led the engineering team of another. I have interviewed more software engineering candidates that I can remember. I have argued with managers about the shockingly low pay some of my team mates were receiving, and I have explained to bold young engineers why they are aren’t getting a pay raise anytime soon. I have been inspired by great leaders, and frustrated by incompetent ones.
Over that time I have formed strong opinions on what it takes to be a successful software developer, and formulated a management philosophy that aims to enable the people who work with me achieve that success. This collection of writing focusses on what it takes to be a successful software developer.
What can you do over the course of your career to maximize your chances of being successful?
I will cover four broad areas that I have titled Arrive, Survive, Thrive and Drive.
Arrive covers things that you would ideally know before your first day of a new job (but you probably didn’t read this before you started so you are playing catch-up).
Survive talks about the basic information you need to collect in order to make it through the day-to-day at any company.
Thrive focusses on areas of growth that will help you advance within a company.
Drive looks at what you need to do to take your career to the next level.
There is a natural progression to these topics that mimics the progression of the career of a software developer, so they are probably best read in order. That said, if you are already several years into your career you might find it more productive to jump ahead to a topic that covers a challenge you are facing today.
Congratulations on being hired as a software developer in one of the many American corporations that employ such people.
There are very, very few large companies where software is still the raison d’être.Actually, the only ones I can really think of are Microsoft and Adobe. Everywhere else the software is a means to an end. LinkedIn, Google and Facebook are all about sharing data while quietly collecting meta data about users that they can sell to someone else, Apple is trying to sell hardware, AWS is trying to rent data centers, and all the other big corporations seem to make more money off the services they sell helping customers learn how to use their software and hardware than they make off the original software and hardware. So the overwhelming majority of you work for a company where what you produce is necessary to the creation of your companies product, but is not actually the product itself, while a lucky minority of you work for a company where software is the product (although even then, a significant amount of your time is spent developing software that is outside the core product).
Humans have two hands, so we like to classify things in binary trees. When I think about hiring into an organization I bucket people into two groups, college hires and experienced hires. As the names suggest, college hires are fresh out of college and experienced hires have some experience working as software developers. Okay, there are a small number of exceptional cases where the career path doesn’t fit this exact mould, the ones who skipped college or the ones who changed careers, but I think that their experiences probably map quite closely to the college hire and experienced hire respectively.
Good college hires are enthusiastic, communicative, socially well-adjusted, willing to learn, haven’t picked up any bad habits, and are grateful for a job (i.e. cheap). Bad college hires trip over one or more of these very, very low bars.
In general, I have such low expectations of a college hire’s technical competence that I rarely refuse a candidate on those grounds. What will get you bounced out of the interview is blending incompetence with arrogance; if you push back against coaching during the interview, when you are presumably on your best behavior, it is assumed you’ll be un-coachable when you actually start the job for real.
In fact, most of the different reasons for passing on a college hire come back to how good I judge the return on investment will be. Poor communication or social skills mean that I’m going to have to work harder as a coach. Lack of enthusiasm, unwillingness to learn or a belief that a high GPA from a well-known school should mean something in the real world all translate into resistance to receiving the infinite wisdom I have to offer.
In short, you got hired because you were enthusiastic, didn’t display any kind of debilitating social disorders, and correctly answered a couple of technical questions that the interviewer(s) consider “baseline”.
As you would expect, experienced hires are a much more heterogeneous collection. Enthusiasm is no-longer the primary requirement, in fact an overly enthusiastic experienced hire is downright unnerving. It suggests either desperation or an incredible insensitivity to all the deficiencies at their previous places of employment.
Experienced hires project a hint of wariness.Much like the legal disclosures on consumer electronics, questions posed by experience candidates about the position they are interviewing for are rooted in past disasters. Experienced hires don’t doubt there is something wrong with the organization they are applying to join, they just want to know what it is, and whether they can live with it.
One common route for an experienced hire into an organization is through their professional network; you know someone who already works there. The interviews in that case basically boil down to digging up embarrassing stories about your common connection, and bragging about stupid mistakes that you made at your last job. There will still be technical questions, of course, but whoever referred you is probably getting a bonus for everyone they recruit (or at least they want you to join the company) so they should have given you very clear hints about the types of questions to ask, and they aren’t going to risk embarrassing themselves by referring you if they think you won’t be able to do some homework and answer competently.
It isn’t unknown for a complete stranger to get through the initial screening process and show up as a candidate, but it is definitely less likely. During my most recent stint as a hiring manager we interviewed more strangers for open positions, but only because we received two orders of magnitude more résumés from strangers (it was a small startup), and the acceptance rate was an order of magnitude lower than referrals. These “external” candidates have to work harder and are less likely to receive the benefit of the doubt. Justified fear of the impact of hiring a toxic or unqualified candidate coupled with the absence of an internal advocate who can explain away any of your missteps means that triggering a single interviewer’s “red flags” almost certainly means a polite (or rude) rejection.
Successful external candidates need to seem like a nice enough person who will fit the existing team culture, can talk intelligently about one or more previous projects that have some applicability to the group they are joining, and correctly answer a couple of technical questions that the interviewer(s) consider “challenging” but “common knowledge”. Of course, one person’s challenging may be another person’s trivia, and I doubt you can build a group of three software developers who agree what knowledge should be considered “common”.
Whether referred, recruited, or randomly applied, as an experienced developer you got hired because you seemed like someone everyone could work with and convinced everyone that you had experience in at least one technical area that the team needs help with.
Your title and your role are at best loosely coupled. In many companies you are simply designated as some variant of “Software Developer X” where X is a small positive integer. Furthermore, the job description that was posted was probably a generic description that is used for hiring many, or even all, positions of the same title within the whole company.
After verifying your employment eligibility (immigration status), getting your company ID, filing the necessary paperwork with the payroll department, completing mandatory training, and locating bathrooms and caffeine sources closest to your desk, the most important thing to do is clearly understand your roles and responsibilities within the new team.
With sufficient experience you learn how to extract some of this information during the interview process so that you can decide before you take the job if it sounds like something that you would like to do. Note that it is not as simple as asking the hiring manager what the roles and responsibilities of this position are. They should certainly have a crisp, ready answer (and if they don’t you can take this as a sign to pass on this “opportunity”), but unless they are a truly exceptional manager there is a good chance that this answer is at best only partially true. I don’t mean that they are necessarily deliberately lying to you, just that they aren’t necessarily in possession of all the facts. If you are interviewed by other members of the same team then you can often find a way to ask each of them what they think the position entails. You are unlikely to get identical answers from everyone, but they should have a high degree of overlap with each person providing a slightly different perspective based on how they expect to interact with you once you get the job.
Even if you managed to steer most of the interviewers around to this topic, you are unlikely to have interviewed with every person you will interact with in the organization. In large teams you will have only interviewed with a small subset of the senior engineers and leadership team. Unless the position has been clearly flagged as “cross-functional” you are unlikely to have interviewed with members of teams that your team work with. Even if the position has been flagged as “cross-functional” you are likely to have only spoken to leaders of those other team, and those leaders are no more likely than the hiring manager to be able to give a completely true answer.
An early task is to identify all the people you will be working with and then find out what they actually expect you to do. Then figure out which of those expectations are actually reasonable. If the company you have joined has a good on-boarding process then you’ll be given a head start on day one when you are introduced to various stakeholders and contacts. If there is no structured on-boarding process then you have basically been thrown to the wolves; make as many friends as you can as quickly as you can.
It is important to understand your complete compensation and benefits package. This information was all sent to you as part of the formal written offer and might have been verbally laid out for you when the offer was presented, but you probably couldn’t absorb all at the time.
Your total compensation can be divided up into cash, equity and benefits.
Cash compensation is made up of your base salary plus any overtime or bonuses that you are eligible (usually one or the other but not both).
This is what you are guaranteed to be paid every year, divided up into pay periods. The most common pay periods that I have encountered are bi-monthly (15th and last/first day of the month) or every two weeks. Your offer letter will specify your gross base salary probably as an annual or monthly amount. A wide variety of things are then deducted from that gross amount.
Before tax is calculated, the employee contribution to various benefits are deducted. Things like medical, dental, vision and life insurance, and contributions to a 401(k) program are the most common pre-tax deductions. Obviously, the advantage of paying for these things pre-tax is that it lowers your taxable income and thus lowers your total tax.
“Taxes” covers Federal, State and local (where applicable) income taxes along with contributions to Social Security and possibly disability insurance. The gross income subject to social security is capped (at $132,900 in 2019) meaning that if any earnings above that do not have Social Security deducted. State disability insurance often has a similar cap. If your gross income exceeds these caps then the last paychecks of the year will be larger, since these deductions will be absent. Income tax withheld from the paycheck is a function of the number of allowances that claimed on form W-4, filed with the company payroll department before the first paycheck is issued. The more allowances claimed the lower the tax withheld. Overstating the number of deductions will result in a hefty tax bill in the April the following year, and possible penalties for under-withholding. Understating the number of deductions will result in a large refund, but that means you have essentially given the government an interest-free loan.
Finally, there may be some post-tax deductions. These are generally associated with employee contributions to benefits that are not tax exempt, such as an Employee Share Purchase Program (discussed later).
Combined, these deductions and taxes can easily add up to a third of your paycheck; you’ll need to see a paycheck for a complete pay period to get a good handle on your exact take home pay.
Overtime rules vary from state to state.
In California, employees with professional skills who are largely self-directed are exempt from overtime. It is assumed that they are setting their own hours, and being judged by what they produce, not how long it takes, so are paid their base salary no matter how many hours they work.
Very junior engineers may not be exempt from overtime. If an engineer is largely performing tasks defined by someone else (manager, technical lead, or more senior peer, for example), and receives supervision at least daily then their hours should be tracked and they must be paid in excess of their base salary if they work more than eight hours in a given day, forty hours in a given week, or six days in a given week. Specifically, they must be paid one and a half times their hourly rate for hours eight to twelve in a day, and twice their hourly rate for hours in excess of twelve in a day. They must be paid one and a half times their hourly rate for the first eight hours worked on the seventh consecutive day of the workweek, and twice their hourly rate for all hours worked after eight hours on the seventh consecutive day of the workweek. Of course, this overtime is added to the gross pay and taxes, and any proportional pre- and post-tax deductions will be taken.
If you track your hours on a timesheet then you are probably not exempt from overtime (or you work for the government).
Whether you actually perform overtime will be largely a factor of your corporate culture. Obviously, there is a cost incentive to avoid overtime, so junior engineers are often discouraged from working long hours. Other organizations are less disciplined and overtime can be good way to boost income (at the expense of a social life, hobbies etc)
In the rest of the world “bonus” means an unexpected lump of cash given to reward going above and beyond. You might get a bonus for completing a particularly challenging project ahead of time, or uncovering (and fixing) a particularly nasty bug. Of the course, the US has to take that concept and fuck it up.
You might still get spontaneous bonuses for a job well done, but they tend to be more symbolic in size. The more common “bonus” comes with a target, and is paid out on a regular schedule to more senior members of the organization. For example, a big corporation I once worked for had bonus targets that scaled with grade, 15% of base salary for a senior engineer/technical lead, 25% for a senior technical lead, 35% for a principle engineer, and on up from there. The target was then multiple by various “performance factors” (individual, team, company) that would scale the bonus value up or down. Clearly, a well performing senior member of a high-functioning team will receive a large part of their cash compensation as a “bonus”. With this level of structure the bonus forms part of your total compensation, and will be presented as such, but you can’t actually include the money in your budget until it actually lands in your bank. In reality, bonus targets like this give the company the option of cutting your salary, without notice, by 10-35% in any given year, usually due to “adverse market conditions”.
Equity covers any form of stock or options to buy stock.
The concept of employee ownership is deeply ingrained in Silicon Valley culture. Everyone has heard the stories of early employees at successful companies becoming million- or even billion-aires overnight when a company is sold or floated on the stock market. This is achieved by issuing equity to employees with highly favorable terms.
For a detailed discussion of the various forms of equity compensation along with the tax implications of each, I refer you to Carta’s Equity Education blog https://carta.com/blog/category/equity-education/
Very early stage employees (the first ten or twenty) will be given the chance to purchase a few thousandths (10ths of a percent) of the company for a nominal sum, often thousandths of a cent per share. These shares are subject to a claw-back agreement whereby if the employee leaves the company within a certain time period the company buys back some or all of the shares for the same price that was paid. The claw-back agreement expires for batches of shares at certain times. Usually the claw-back expires for the first (biggest) block on the employee’s first anniversary with the claw-back expiring on equal-sized blocks every quarter or month until the employee owns all the shares free and clear.
Restricted stock is usually taxed when it vests as ordinary income. Initially, since the shares are in a company with a very low value, this tax is negligible, but as the value of the company increases the tax can become burdensome. The recipient can choose instead to pay the tax (of $0) when the property is received, even though you may not actually get to keep all of it since it is subject to the claw-back. Choosing to pay the tax immediately is called an 83(b) election. Notice of this election has be made to the IRS within thirty days of the grant or the opportunity is gone forever.
Other forms of equity compensation can create situations where the employee is forced to pay taxes on stock that cannot be sold, usually when the company has become valuable but is still privately held. This can force employees to abandon vested equity without realizing any value or having to borrow money to pay taxes in the hopes that the equity retains its value until it can be sold.
The next tranche of employees, usually up until the company becomes public, will be issued stock options, which are effectively a contract guaranteeing the right to buy stock at a fixed price determined by the company’s value at the time the contract is agreed, rather than the (expected to be higher) prices when the stock is actually purchased. Stock options vest (become usable) over time, usually with a chunk becoming available on the employee’s first anniversary and more becoming available every month after that until all the options can be exercised. Options typical expire five to ten years after the final block vests.
Exercising options (buying shares at the strike price) is a tax event. The difference between the strike price and the current Fair Market Value is value that has effectively been given to the employee by the company, and is subject to payroll tax. Once a company is public the funds to pay for the options and any taxes due be covered by selling a portion of the shares. Employees at private companies don’t have this option. However, if the FMV of the stock is low enough (or even equal to the strike price), it can still be advantageous to exercise the options (by forking over cash), and pay the taxes immediately, in anticipation of the company (and thus the stock) becoming more valuable. The increase in value after the options have been exercised will be taxed as capital gains (at a lower rate) rather than income. However, a private company can quickly become too valuable for this to be a viable option for many employees, and of course you are gambling the stock price will retain and increase in value, otherwise you may have paid tax for nothing.
Sometimes companies will allow you to exercise your options before they have vested (early exercise) with the resulting shares then subject to a claw-back clause should you leave the company before the options were actually due to vest. This allows you reduce payroll taxes by exercising options while the strike price and FMV are close or equal.
After a company is publicly traded on the stock market it becomes advantageous from a tax perspective to issue Restricted Stock Units in place of stock options. Unlike options, the employee is issued actual stock rather than the right to buy stock. The stock is released in blocks, similar to the way that options vest, however, the value of the stock is taxed as income on the vesting schedule so it is common to sell a portion of the stock immediately to cover the payroll taxes.
Another equity-based source of compensation is an employee share purchase plan. Similar to stock options, the ESPP gives employees the right to purchase stock at below market rate. Unlike options the price depends on the FMV, and money is deducted from the employee’s paycheck to pay for the stock.
ESPP operates on fixed length periods of time, usually six months, that apply to the whole company. Employees must be enrolled before the start of the period, and most remain employed and eligible through the whole period. A post-tax contribution, determined by the employee up to a maximum determined by the plan (usually the maximum permitted under law), it taken from each paycheck during the period. That contribution is used to purchase shares at the lower of the FMV (price) of the shares, minus a discount, at either the start or end date of the period. The discount is generally 15%, the maximum allowed by the IRS. Since only whole shares can be purchased, any excess contributions are returned to the employee after the share purchase is complete. Once the shares have been purchased the employee is free to sell them immediately and no taxes are withheld, although capital gains tax will need to be paid at the end of the year.
The biggest problem with all forms of equity-based compensation is figuring out how much the award is actually worth. Hiring managers will usually come out with some rosy projections (wrapped heavily in caveats about not being able to predict the future, and stressing that this is how they personally think about it) but you are trying to predict how the stock market will react to the company performance over the course of several years multiplied by your own ability to sell at the right time.
The situation is easiest for large, stable, mature, profitably companies. They have years of financial disclosures that have been examined by experts, and the business is unlikely to either grow or shrink very much in the short term. There are various rules of thumb used to map company metrics to an acceptable stock price range, and it is rare for the stock to stray outside that range for long or change price very rapidly. 10% swings in stock price are “huge”, but don’t actually impact the total value of RSUs. Of course, these are also the same sort of companies that don’t issue much equity for the junior ranks.
Companies that have recently become public are much harder to predict. Hiring managers have often been at the company since before the Initial Public Offering (IPO), and are generally bullish about the company prospects. The company is still expecting to grow rapidly (using the money raised from the IPO to fund expansion) and everyone is hoping for the stock price to grow rapidly too. All you can really guarantee is much higher volatility than at a larger company. Swings of more than 50% in the stock price over a few months are not surprising. Another problem here is that employees are more likely to have been issued options than RSUs. If the stock price sinks below the strike price of the option then it becomes worthless, so even small swings in stock price can have a significant impact on the value of an employee’s equity.
Things get much more complex in a large, growing company that is still private. This has become more common in recent years where several high-profile tech companies have delayed their Initial Public Offering until market conditions are more favorable. Absent a public market to determine the value of the shares you are left to estimate the value of the company and then multiply that number by the (tiny) percentage of shares that you own/have options for. However, if the company is still private you can’t (by definition) sell the shares on the open market to realize that value as cash. I have heard of companies initiating buy-back schemes to allow employees convert equity to cash, and sometimes secondary markets appear for options and stock. By and large, you are just stuck until the company IPOs or gets acquired (and all your stock gets converted to cash or stock in the acquiring company - usually at a deep discount to what you thought it was worth).
For very young seed-stage companies the situation actually becomes simple again. Your equity is worth virtually nothing. The valuation of the company is so low that equity in the company is a fraction of worthless when it is first awarded, and the likelihood that the company will be successful so the equity becomes valuable over the years that you work there is so small that you may as well treat it as zero. Research the tax implications and try to make sure you can reap the rewards should you find yourself in the unlikely, and fortunate, situation that your equity turns into a windfall, but don’t bank on it until you’ve sold the shares and have money in the bank!
Everything that you get from the company that is neither cash nor equity is a “benefit”. The most significant benefits in the U.S. are healthcare related (insurance and flexible spending accounts) followed by investment vehicles like 401(k) and 403(b).
While you might consider health (medical, dental and vision) insurance to be a necessity, it is treated as a benefit by your employer (and the IRS). In addition to providing access to a group plan that covers all employees and their eligible dependents, most companies also contribute to the plan premiums. In fact, the employer contribution is generally significantly larger than the employee contribution. The employer contribution is considered by many companies to be part of the “total compensation package”.
Related to health insurance are flexible savings accounts. FSAs can be used to pay legitimate healthcare expenses such as insurance co-pays and other out of pocket expenses as well as other medical expenses that insurance might not normally cover, such as some consumer medical devices. Contributions to the FSA are deducted from your paycheck pre-tax. Some employers may also contribute to the FSA. This can be particularly attractive when paired with a High Deductible Health Plan. Such plans have lower premiums (and therefore lower per-paycheck contributions), but make up for it by having a high deductible to be paid out before benefits kick in. Some companies will close the gap by providing an FSA and contributing some or all of the deductible amount, which can lower the total employee expenses.
401(k) refers to a clause that was inserted into the the US federal tax code in 1978 to allow taxpayers to invest part of their income in the stock market and be exempt from income tax on that investment. In 1980 an attorney realized that this provision could be used to save for retirement and defer taxes on those savings. Today the 401(k) is the dominant form of retirement savings for American workers.
Contributions (subject to an annual maximum set by the IRS) to a 401(k) are deducted from your paycheck before tax and many employers offer to match contributions up to some percentage of your paycheck (subject to a cap set by the IRS). Once money goes into a 401(k) it can’t be accessed without paying all taxes due, plus a healthy penalty, except under very specific extenuating circumstances. Money contributed to a 401(k) is invested in various financial instruments that are supposed to grow the value of the 401(k) to the point that it can provide sufficient income to last through retirement.
Automatic enrollment in a 401(k) and matching contributions by employers can suggest that participating in a 401(k) is the right choice for everyone. However, like all investments, you should seek independent financial advice before contributing to a 401(k).
In particular there are four principle concerns with a 401(k)
1. Tax-deferment. Often touted as the biggest benefit of a 401(k), deferring taxes only makes sense if you expect to be in a lower tax bracket when you withdraw from your 401(k) than when you contribute. There are circumstances where this might be true, but there are equally many circumstance where this is not the case. People planning “active” retirements, for example, may well need their income to remain relatively flat from their final pre-retirement income (when they are likely commanding their highest salary and seeing healthy return on long-term investments).
2. Management fees. In order to comply with government regulations 401(k) managers face a heavy burden of recording and reporting how the program has been administered and performed. This burden gets passed along to participants in the form of higher fees than for comparable financial instruments. Unfortunately, these reports are useless for actually monitoring the performance of your investment.
3. Misaligned goals. Most participants in a 401(k) need their investment to be optimized for performance over decades, but the performance of fund managers is judged over a period less (often much less) than ten years. This misalignment of goals can result in the 401(k) investments underperforming over their lifetime.
4. Inflexibility. The tax-deferred nature of the 401(k) comes with heavy penalties for withdrawing money early, except under a very narrow set of extenuating circumstances. Whereas other investments can be liquidated (and later replenished) to bridge a career change or fund a startup, doing the same thing with a 401(k) will be costly.
Different companies will offer a wide range of other benefits that reflect the company culture. Larger, more mature companies may offer onsite daycare, subsidized company canteens or various health incentive programs. Startups may offer free lunch, snacks and happy hours. Commuter benefits and and participation in employee discount programs are also common. The precise value of these other benefits are very dependent of the lifestyle and circumstances of the individual.
The culture of your new team and company encapsulates the beliefs and behaviors that shape the interactions between employees as well as between the company, its suppliers, and its customers. Companies large and small often try to summerise the culture of the organization in an employee handbook with statements of values or guiding principles. The gap between words and actions varies from company to company. Culture develops organically over time from the cumulative traits of the people the company hires. One of the considerations during the interview process is cultural fit of the prospective new hire, so if the process has worked you should quickly feel at home in your new team. Absorbing the culture should be one of your first orders of business.
Expect to be in the office long hours for the first six weeks. You want to have good overlap with the entire team. Don’t commit to anything outside of work (social events, transporting the kids to and from school etc) during the hours 0800 to 1900 for the first week or so of a new job. You will quickly find out what the core hours of the team are and then you can make adjustments to match those hours. For the first six weeks or so you should expect to keep those core hours, even if they aren’t your own preference. You should also be prepared to attend social events that you are invited to. For parents this can be a real pain point, if you need to juggle pick-up/drop-off scheduled for the children, but it can also be disruptive for anyone who has been following a different schedule in a prior job. Consider this an investment in your future. An unwillingness to adapt to your new team’s culture during the first few weeks can become a defining characteristic of you for those you work with, and once that is embedded it can be very hard to shake loose.
Once you pass the six week mark, if you find that you want to adjust your schedule to be more accommodating to your lifestyle you will be in a better position to understand how much of an impact that is likely to be, and how acceptable the rest of the team (and your manager in particular) will find the changes.
Don’t take this as an invitation to be a doormat. For example, if you have school-age kids and your new team is currently having a weekly planning meeting from 5pm to 6pm every Tuesday, take your supervisor aside and explain that this isn’t going to work and they need to move the meeting.
If you are a non-exempt employee (that is, one who gets additional payment for working more than eight hours in one day or forty hours in one week) expect to have less flexibility over your work hours. If the company is expected to pay you extra for working more hours then they are going to expect you to be visible to a manager most, if not all, of the time. That usually means reduced opportunity for working from home or off-hours.
Many software engineers are introverts and/or avid readers and learners. When you join a new team it can be tempting to ensconce yourself in your workspace and dedicate your time to “coming up to speed”, especially if your new manager has mapped out your goals for the first ninety days. It is important not to sacrifice social time with your new team to do this. If the team has a ritual of going for coffee in the morning or afternoon, go too. Don’t drink coffee? Get a juice or water. Make sure that you are visible around lunchtime and follow the herd. Try to converse with different members of the team each time. You don’t have to like everyone that you work with, but you should know who you do like and who you don’t (and why) within the first week or two of joining a new company. You are going to be spending a lot of time with these people, it is important to invest the time to get to know them early on. Again, early impressions last, if you turn down the first few invitations to lunch, coffee, or evening drinks then you’ll be perceived as anti-social for a long time. Conversely, if you accept all the early invitations then later you can be more selective and you’ll be perceived as “sociable, but really busy”.
Since cultural fit is a consideration during the hiring process your very presence impacts the culture, even if simply by reinforcing existing norms. Just because culture evolves through a largely organic process doesn’t mean that changes have to be unthinking. Since culture is the product of the actions of the employees, you shape the culture by consciously performing or avoiding actions. Obviously, the company leadership has the greatest visibility and influence over the culture; a bullying, arrogant leadership is going to encourage arrogance and bullying among the workforce. However, it is the rank and file who embody the culture and how you conduct yourself matters. This is especially true in very small or young companies, such as startups, but within larger companies different teams tends to evolve slightly different cultures shaped by the members of that team.
You should set aside time every few months to sit quietly with the mood enhancer of your choice to think about what you like about your workplace, and what you don’t, and then think about how your actions contribute to the culture.
It has been a source of constant bafflement to me that many workers in large corporations seem to have absolutely no idea what their company’s long-term goals and strategies are, who the major competitors are, or even which product lines generate the most revenue or have the highest margins. By necessity, this seems to be less common in small startups, but even there you occasionally run across people who seem to have no idea what their company is trying to achieve.
These things inform the decisions made by the strategic leaders throughout the company and ultimately determine the relative priorities for your work and the level of support (both financial and political) that you will enjoy. Being in possession of “the big picture” empowers you to make decisions without needing to go back to your boss every five minutes and ensures that, when you do need to ask for permission or input, that you can structure the conversation around those goals and strategies.
The most basic thing you should know is whether you work for a publicly traded company or one that is privately held. Companies are formed when a small number of founders file articles of incorporation with a state government. Many US companies are incorporated in Delaware, even if they are based in other states, due to favorable laws regulating corporations in that state. At this point the company is wholely owned by the founders and is a private company. There is no requirement for the company to publicly disclose the financial health of the company, but there are still rules about how decisions are made and what information must be provided to the owners.
A few companies stay privately owned by a small number of individuals; think law firms and small consulting companies. Sooner or later most companies want to expand faster than revenues (if there are any) would allow and external investment is solicited. The company is still private at this point, but the group of people with an interest (and a voice) in the direction of the company extends beyond the founders. Again, some companies remain in this state indefinitely while others either start selling shares in the company on a public stock exchange or get acquired by another company whose shares are publicly traded. At the point new rules apply to recording and reporting the company’s financial sate.
Public companies in the US fall under the purview of the Securities and Exchange Commission (SEC), and there are strict rules about what financial information they release and when they release it. These rules are intended to ensure that investors are able to make informed decisions and that people who work for the company (insiders) cannot exploit the obvious information asymmetry to the detriment of the public.
It turns out that some private companies are also required to make public disclosures. If a company has more that 500 common shareholders and $10 million in assets then it is required to file financial reports with the SEC. This was apparently one of the reasons that Google decided to go public; since they were required to file financial disclosures anyway the founders decided that they might as well raise some money at the same time, and make employees’ stock liquid.
Public or private, the company is controlled by a board of directors and the company officers. The power dynamic between these two groups varies from company to company, but generally the CEO is in the driving seat, and the board provides advice and guidance rather than issuing directives.
Being public adds shareholders into the mix. Nominally, shareholders are the owners of the company, and dominant over the board of directors. However, unless an activist investor buys up a large number of shares, the interests and desires of the shareholders are largely irrelevant to a publicly traded company except for how trading activities affect the price of the company’s shares. A company’s total value (market capitalization) is the product of the number of outstanding shares and the price of a single share. As we discussed in in Compensation and Benefits an employee’s total compensation may also be dependent on the stock price. Unsurprisingly, the stock price is usually a closely tracked metric in any publicly traded company (although CEOs of underperforming companies may well wish it wasn’t).
Publicly traded companies, and a small number of privately held companies, are required to file annual (10-K) and quarterly (10-Q) earnings reports with the SEC. Additionally, they are required to inform the SEC whenever something happens that is expected to materially impact the health of the company. These reports, and the conference calls (called an “earnings call”) that usually accompany their public release, provide the primary source of data about a company. During the conference call the CEO and CFO will call out important metrics, significant events, and talk about changes in strategy
Earnings calls follow a predicable pattern with the CEO/CFO reporting the revenue for the previous quarter and/or year and comparing it to the quarter immediately preceding (quarter over quarter), and the same period from the prior year (year over year). Usually they will give the total revenue as well as the earnings per share (EPS), which is just the total divided by the number of outstanding shares. After that, any challenges or opportunities in the coming year or quarter will be highlighted. Most companies also take this opportunity to provide guidance on what they think the revenue numbers will be for the coming period. When those numbers are actually released the company will be judged on how accurate that prediction was,
Every well-informed employee should listen in to the conference calls and at least skim the earnings reports. However, it is important to realize that it is in the interests of the offices and board of a company to present the best possible view of the company without actually violating the law. Listen skeptically and learn to read between the lines.
Be aware that, as an employee of the company, you may well learn facts about your company that might have a material impact on the stock price before those facts are made public. The general rule is that you cannot use such knowledge for personal profit by either buying or selling shares (insider trading). There is an SEC-enforced “quite period” prior to earnings calls when companies are not permitted to make public statements about their financial health and most companies also enforce trading blackouts during these periods. Significant events (initial public offerings or acquisitions) come with a lock-in period, during which time employees cannot sell their shares. Most company’s also prohibit short-selling stock in the company since it creates a clear conflict between your duties as an employee (to increase the value of the company) and your goals as an investor (to see the company tank).
Since private companies aren’t usually required to release financial information publicly there is no equivalent of an earnings call. Of course, revenue and expenses are still carefully tracked and will be regularly discussed at board meetings. Employees are important stakeholders in the company, and it is very common for part of your compensation come in the form of some kind of equity, so it is entirely reasonable for you to be privy to lots of information about the financial health of the company. Absent the forcing function of being a publicly traded company, private companies can be a lax about sharing financial details internally so you may need to ask your supervisor, or other people higher up the food chain, to share information with you. Again, your financial wellbeing is dependent on the health of the company so you have a right to know what’s going on (and a duty to keep that information confidential).
Nuances aside, your company strategy can probably be reduced to “dominate our industry and crush the competition”. You sell more product by growing the market and/or taking market share from your competitors. If you have no competitors then you are probably in a niche/nascent industry so your strategy will be focused on developing new customers for your product. That may still be part of the strategy if you are part of a mature industry with a plethora of competitors, but now you can also profit by taking market share (customers) away from your competitors.
Knowing about your industry and understanding your product’s competitive edge provides more “big picture” context that will help you make good decisions in your day to day work.
Small or young companies often have a single product. As companies grow it is common to add additional products to solve related problems that existing customers have or to capture customers not served by the current product. For all but the very largest companies, the product portfolio is generally aligned around a single core competence.
Just as you should understand your industry and competition you should know about your company’s product portfolio. Which products drive the company’s revenue? Which products drive growth? Which products are doing poorly?
In a company with multiple product lines some are going to be more relevant to the business than others. Product lines with higher margins provide a greater return on investment so the development teams responsible for those products will be under less pressure to reduce costs. Product lines that align closely with the strategic direction of the company are less likely to be held to the same revenue and margin targets as other product lines.
Individual products, product lines, and even entire industries go though a lifecycle that starts with innovation passes into growth and ends with sustaining (also known as commoditization).
During the innovation phase the product doesn’t exist and is generating no revenue. There may or may not be a small group of customers (usually called partners, beta customers, or earlyvangalists). The product development team is operating as a cost center, but the leadership see the value of investing in this team. Most leaders are aware of the folly of under-investing (trying to develop a new product on the cheap and failing to produce anything you can actually sell) so will often set aside sufficient money to hire an appropriately sized team, but you are on a deadline. There will be milestones for releasing the beta product, making the product generally available, hitting certain revenue numbers, and achieving profitability. Miss those deadlines and the leadership team might decide to cut their losses and cancel the whole project. How likely this outcome is depends on how visible the product is, how valuable to the future of the company the CEO thinks it is, and how influential the product’s executive champions are. Obviously, for a very new company, still working on their first product, the success or failure of the project will determine whether the company dies or survives.
During the growth phase the product is generally available and generating revenue that can be used to fund further development efforts. Some of the revenue will be kept back as profit and to offset the initial investment. At this time, market predictions become market facts and the development team can be right-sized to match the success of the product. If a product sells better than expected then the development and sales teams may receive additional resources (money for headcount) in order to develop new versions of the product. If the product sells poorly then resources may be shifted away to other projects.
During the sustaining phase no significant effort is expected to be expended on further improving the product. The focus is on reducing the cost of producing and supporting the product. Most of the development team will be moved to other projects (possibly the next generation of the same product line). Those that remain will focus on bug fixes (for software) or reducing the manufacturing costs (for hardware). In the months or years running up to end of life, even these efforts will be curtailed as the company attempts to get costs as low as possible and the sales team tries to extract every bit of remaining value.
If you aren’t part of the revenue you are part of the cost.
The biggest single expense for every organization is payroll; your salary, benefits and the associated taxes. If you are not directly aligned to generating new revenue by either building products, selling products or marketing products then you are part of the cost, and your very existence reduces the profitability of the company. A company can increase profits by either increasing revenue or decreasing costs. If your function is tightly aligned to revenue generation then you can argue that the company is paying for an investment; a small up front cost to the company (your pay) will generate revenue exceeding that cost. The difference between your cost and the revenue you can claim to generate is your productivity. If your function is not tightly aligned to revenue generation then the company will seek to increase profits by reducing costs (your pay). Cost centers, such as legal, HR and IT, are necessary for a company of any size to function, but the leaders of those functions are still going to have to fight tooth and nail for budget.
Clearly it is better to be part of the revenue generating part of the company than a cost center. Sales is probably the only group that can unequivocally demonstrate that they are generating revenue, but the product development teams have a pretty solid case as well. The further away you get from the immediate tasks of developing and selling new products the harder your leaders need to work to demonstrate that they are an essential part of the revenue generating process.
Marketing? Needed to generate leads for sales, okay.
Product testing? If “quality” is a feature then testing is part of product development.
Customer support? If “after sales support” makes the product more marketable then, maybe.
And so on ..
Again, what does this mean for me?
These factors all feed into the level of both investment and scrutiny that the teams aligned with each product will receive. Teams that are innovating and whose work is closely aligned with the strategic direction of the company will get more resources and more pressure to perform than teams who are sustaining existing products. For the individual contributors on these teams this translates into the likelihood that additional members will be added to your team and the amount of pressure that your team will be under to achieve aggressive goals.
Small products lines that aren’t particularly strategic in nature, and which have healthy margins, can expect to be largely ignored, but they will also be unlikely to receive significant increases in resources. For individual contributors on these teams this translates into a fixed headcount for your team with average raises and promotions limited to filling slots vacated when more senior team members move up or out. On the other hand, senior management is unlikely to give your team much thought provided you keep plodding through the work.
As has been said before, in a very small, young company there is going to be a single product that the whole company is aligned around. Success of the entire company hinges on the success of that product so the level of scrutiny and the drive to succeed will be accordingly higher.
Private or public, the company will have some investors, even if it is just the co-founders kicking in seed money. For publicly traded companies the investors are the members of the public (or more accurately, the institutional investors) who own shares in the company. Privately held companies may have used a range of vehicles for investment.
In any case, the investors or shareholders are the ultimate owners of the company. Nominally they control the company via voting rights at the annual general meeting that all corporations, public or private, are legally required to hold. Most obviously, the shareholders vote on the board of directors.
In practice, however, it is rare and hard for the shareholders to effect meaningful change even to the makeup of the board. While a company is private major investors generally expect to be given the right to nominate one or more people to the board. Once a company becomes public the board of directors becomes basically self-perpetuating with remaining board members selecting people to fill vacancies, usually in line with the CEO’s recommendation.
Every corporation is required to have a president and a secretary. However, these legal roles can be filled by people with a range of job titles. The president is usually either the chairperson of the board or the CEO (sometimes one person serves as all three). The secretary may be the CFO or the COO, but may have another title if a co-founder has retained the legal role.
A corporation is governed by a collection of individuals known as the board of directors. Board-level decisions require the majority of a quorum of the board to assent during a properly noticed meeting. A quorum is the minimum number of board members required in a meeting for that meeting to be able to take action.
The board of directors is legally responsible for everything that a company does, although they delegate a lot of the day-to-day running of the company to the officers (CEO, CFO etc). The board is supposed to take a strategic view of the company and direct the CEO to achieve that vision. The balance of power between the board and CEO varies from company to company with some boards seeming to be a simple rubber stamp while others actively guide the CEO. At the end of the day there are certain decision, particularly financial decisions, that require board assent.
For most employees below C-level the only direct impact they will feel from the board is related to equity-based compensation and promotions. If your employment agreement includes an equity component you won’t receive the actual grant documentation until after the board has met to approve that grant. Some companies require board approval for promotion to the higher ranks of the company (VP and above).
Members of the board are usually well-known and influential within your industry. They are selected for their connections or to represent the interests of investors. You should take every opportunity to interact with them that you are presented with. It is something of a tradition in the technology startup community of Silicon Valley for founders of companies to get funding via board members and investors of companies they have been previously employed by; you are a known quantity and perceived as less risky.
One of the board members will serve as the chairperson. In theory, this is just an organizational role (they are supposed to stop board members talking over one another in meetings), but the chairperson is often a powerful partner or foil for the CEO. A competent, engaged chairperson will wield considerable influence over the decisions the board makes.
Members of the board will also form various permanent or temporary (ad-hoc) committees responsible for various areas of board business like regulatory compliance and executive compensation.
Every company has a Chief Executive Officer (CEO) and usually a Chief Financial Officer (CFO). Depending on the nature of the business there can be a veritable alphabet soup of other C-level executives. Common ones are Technology (CTO) and Operations (COO) you may also have Marketing (CMO), Security (CSO), Strategy (CSO, again), and even Privacy (CPO). Sometimes you get other C-level executives who don’t actually have “Chief” in their title, such as Architect, General Counsel, and Head of Sales.
The C-level executives represent every part of the company and are responsible for the day-to-day decision making, and the way that they interact and their personalities set the tone for the entire organization.
The buck stops here. The board of directors provides guidance and oversight, and the shareholders or investors can punish poor performance, but during the regular working week the CEO is an absolute ruler. The prejudices and preferences of the CEO directly shapes the ranks of the C-level and senior executives, and indirectly influences the whole company.
Given the influence this person has over the working environment it is important to understand what makes them tick. A good place to start is to understand their background. Did they come up from sales, product development or operations? Nothing is set in stone, but that background will typically shape how they act as a CEO. It can also be helpful to understand why they like being CEO. Someone who took on the role out of a sense of duty is going to behave differently from someone who wants to shape an industry or enjoys developing their personal brand and reputation. Ultimately, you want to understand what their strategy is and what kind of company they are trying to build. Attend company meetings and read any press about your company or the CEO to try and build up an accurate picture. If you are at a smaller company and have direct contact with the CEO at social events just ask them about their philosophy. Most CEOs are not shy about sharing their opinions on everything and anything.
The CFO is primarily responsible for ensuring that the financial records of the company are correctly maintained and filed, but their influence and power extends far beyond simple bookkeeping. Since they are also responsible for generating budgets and earnings guidance they can shape the development of the company and have an outsized role in determining which product lines get funded or axed.
In many companies the CFO is essentially deputy CEO, stepping in when the CEO is unavailable and taking responsibility for a large number of cost centers within the organization (legal, operations etc.)
As a company grows, so too does the executive team. Initially the company founders will probably be the entirety of the executive team, but eventually they will need to bring in leaders for each of the major functional organizations. Variously titled as C-something-O, Vice President, Senior Vice President, or Executive Vice President, the division of duties among the members of the executive team is driven by company need and the skill set of the team members. It is important to know who sits on top of your management chain, what drives them and how they relate to the rest of the team. It is a fact of life that many projects succeed or fail because of executive buy-in (or lack thereof) rather than their technical merits. A great product won’t go anywhere unless the sales team understand how to sell it to customers and is prepared to devote resources to selling.
Just as the composition of the team varies from company to company, the autonomy of each executive varies by company and often by function within the company, A CEO who has a strong sales background may wield a lot of direct control over the sales organization while allowing the CTO a high degree of autonomy, for example.
Every organization has a top (CEO), even if it is a lone founder wearing many hats, and every organization has a bottom (the people actually doing the work). At the inception of a company there are no layers between top and bottom; the founder(s) leads the company and does the work. With the introduction of the first employee there is a distinction between the leadership and everyone else, and once a company has about twelve employees it is impossible for the CEO to directly manage everyone one and more first-line managers will be needed. As a company grows more layers of will form between the executives and the first-line managers; these layers are filled with middle managers. The canonical middle manager usually has the title of director, but in reality anyone from manager to vice-president may be a middle manager.
Almost universally derided as lacking authority and incapable of making decisions, effective middle managers are an invaluable way of extending the reach of executives and ensuring cohesion of vision across a large organization. Ineffective middle management is actually a symptom of poor executive leadership who have failed to delegate to and empower subordinates. Each layer of management should provide context to their team, derived from the more abstract goals set by their managers and peers. Good middle managers will bring their own style and perspective resulting in a harmonious, but heterogeneous, organization capable of responding to a variety of challenges.
Every person in a company should have exactly one manager who they report to on a regular basis. Sometimes this clear situation is complicated by an appalling management concept called “matrixing” where employees report to a functional manager and a project lead. It is vital that you clarify which of these is your actual supervisor responsible for setting goals and winning pay raises and promotions.
The primary factors, by a wide margin, determining employee happiness are their relationship with their manager and their commute. A good manager will act as a surrogate for the rest of the company, providing context that allows their team make good decisions. They will act as a “force multiplier” helping the team to act in concert while empowering individuals to make decisions. Rather than treating the team as a stepping stone to personal advancement they recognize that making their team successful will, in turn, make them successful.
Inevitably every employee will experience a variety of different relationships with the managers that they work with. Some will serve as political spirit animals, providing insight into how upper management arrives at decisions impacting the employee. Others will cheer-lead for their teams and track success by the number of promotions and pay raises that they score. Still others will serve as therapists helping team members through challenges at home and at work. A good manager will combine elements of all of these. Regardless of the management style, regular contact is essential to maintaining a healthy relationship with your manager. One-on-ones should be regularly scheduled at least twice a month and should provide an opportunity for frank bi-directional communication. While is it okay (necessary, even) to discuss your work on ongoing projects during these meetings, most of the time should be spent on more strategic or personal topics.
It is important to you to make your manager (and by extension, your whole management chain) look good. Enhancing their reputation enhances their influence throughout the organization which gives them more control over your circumstances making it easier to get promotions through or to select projects that you want to do. So you have to align yourself to your managers goals and (often) methods. This means that you have to be comfortable with those goals and methods, otherwise you are going to spend your entire workday dealing with the conflict between your managers desires and your own. In addition to making you less effective, this is an unpleasant place to live. Of course, you are unlikely to achieve complete alignment with your managers goals and methods, but the closer you can get the happier you will be. If you find yourself working with someone whose philosophy (strategy and style) you cannot ascribe to, you need to find another manager.
Politicians have given politics a bad name. Most of the time they are engaged in sophistry, the art of using fallacious arguments with the intent to deceive. Politics is just the art of administering a large entity, like a country or a corporation. You cannot and should not avoid politics; making no move at all is not a winning move in office politics. Just doing your job (well or badly) changes the political balance since it either strengthens or weakens your manager’s hand when they go to ask for more resources or to change the schedule to allow you to (for example) attend a conference. Honest, timely communication lies at the heart of successful politics. The one time where just doing your job doesn’t change the political balance is when no-one hears about it. Unlike a tree falling in a forest, if no-one in the organization sees your great (or not so great) work it never happened.
Conflict will arise in any group of sufficient size. It is important to keep conflict on a civil, professional level, and not allow it to become vindictive or personal. When two intelligent developers suffer a violent disagreement over the right way to proceed it is usually because they do not share a common set of facts. If you find yourself at odds with someone you know to be competent, and pursuing the same objective as yourself, it is best to stop and gather all the assumptions and facts from both parties, and find the mismatch.
Of course, sometimes you find yourself in conflict with someone who is unwilling to correct their false assumptions or is not interested in acquiring all the facts before taking a position. In this case, punt the whole mess at your manager or technical leader.
With that said, companies are staffed by people, not robots. An individual’s motivation at any given moment is a combination of their personal long- and short-term goals and the long- and short-term goals of their organization. The leaders of different factions within an organization can choose different strategies to achieve the same goal, or may even have competing goals.
The most honest and straightforward example of competing goals for leaders would be the desire to see their own team receive the lion’s share of recognition and rewards. At each level of an organization the compensation pool for bonuses, raises and promotions is usually fixed, so if one manager scores a promotion for one of their engineers then it leaves one less available for all the other mangers. In a well-functioning team, each layer of management will work together to do the right thing for their manager’s entire team, but in many cases each manager is looking out for their own interests, and will use any means necessary to gobble up as many raises and promotions as they can. This is a fertile environment for sophistry and spin where the manager will stress their own engineer’s achievements and denigrate those of the other manager’s team. This is not a healthy state for an organization to be in and whoever sits atop that organization is failing as a leader.
That is just one example. There are lots of circumstances where the ambition of individual leaders can thwart attempts to collaborate across the organization and this can lead to conflict between organizations trying to enact conflict instructions from the leadership team.
There is no such thing as work-life separation, there is just life, some of which happens to be work.
Unless you are eligible for overtime, and thus cost your company more money when you work more than five eight-hour days, or you get yourself so out of balance that your at-work performance starts to suffer, your management chain are unlikely to care about your work-life balance as much as they really should.
You have to decide what things are important to you in your life, and that includes figuring out how much time and energy you want to devote to your job. You may need to trade off some things (like lots of free time to pursue hobbies) in order to accelerate your career progression or increase your bonus so that you can afford a nice car or a big house. If the tradeoffs become too much, if you are being forced to choose between equally important things then you need to change the game and find a different employer or a different industry to work in.
It is only human nature to try to maximize our return on an investment. In the context of your work, your employer invests in you through payroll and training, so naturally the company wants to extract as much value from you as possible. The definition of value will vary from role to role and manager to manger. For more senior roles value may come from generating unique and innovative ideas for new products and features, whilst in other roles it is the sheer number of code fragments generated, and in yet other roles the value comes from simply being available all the time. The problem is that there is a growing body of evidence that working long hours actually makes people less productive. In amongst the growing body of anecdotal evidence from startup founders and software developers themselves are studies that place the upper limit on productive work for a developer of about thirty-six hours per week.
My own personal experience suggests that it is possible to temporarily increase your productivity, to about sixty hours per week for a week or two, but that such effort is going to incur a penalty when productivity falls far below forty hours for the subsequent couple of weeks. How is this reconciled with various anecdotes, particularly from some sections of the startup community, about working hundred hour weeks for months on end? First it is important to figure out what is being counted as work. In a large corporation it is pretty easy to burn away four or more hours a week with meetings and other overhead that exercises different bits of your brain to the ones that are used for coding. Again, from my personal experience, when my job required me to perform to vastly different functions (software development plus project management) it was possible to work about thirty hours a week on each, giving a total work week of sixty hours, and sustain that for a long time. Similarly, the CTO or VP Engineering at some new startup is going to spend a lot of time in meetings (often over a meal) in addition to any architecting or development activities. After a day of interacting with investors, sitting down to a few hours of quiet coding might not only seem possible, but downright therapeutic.
For a non-manager in Corporate America the duties tend to be more singular. You may be able to shift between multiple projects, but the work is likely to be very much the same. This necessarily caps the number of productive hours you will experience. If your personal experience is very different from this, and you find that you have worked many more than forty hours every week for an extended period of time, then you are either very different from the majority of software developers or (more likely) you are conning yourself about how much productive work you are getting done. Spending eighty hours a week at work is not the same as working for eighty hours a week, especially if you don’t have a family at home and your social life revolves around the office.
Regardless of whether it is possible for you to work long hours for an extended period of time without suffering any drop in quality of work, it isn’t reasonable for your manager to expect you to sacrifice your personal time for your company. If you and a colleague manage to pull sixty-hour weeks for an extended period of time you have basically replaced a third co-worker and might get a few thousand dollars as a bonus at the end of the year, despite having reduced the company’s payroll by over a hundred thousand. It just doesn’t make economic sense for you to do this. You are better off enjoying your life, developing new skills or building out your personal network.
The need for visibility is often touted in the corporate environment. I don’t like the term visibility. I find it to be quite an opaque concept, I prefer to talk in terms reputation and influence.
Reputation is a combination of how many people know of your existence and their expectation of your skill level, likability and responsiveness. Someone with a good reputation will be widely known throughout an organization as a competent engineer who is easy to work with and who delivers on promises made. Someone with a bad reputation will be known as either sloppy, unpleasant, unreliable or a combination of all of these. A developer with no meaningful reputation is invisible outside of their immediate team (and sometimes inside that team too).
A good reputation creates opportunities, makes it more likely for you to be promoted and increases your perceived value to the organization. No reputation makes it hard for you to be promoted and decreases your perceived value to the organization, which in turn removes any incentive to spend money to retain you. A bad reputation makes it very hard for you to be promoted and makes it more likely that you will be stuck in dead-end positions until you get frustrated and quit.
Influence is a combination of reputation and authority, where authority may be extrinsic (derived from your position in the hierarchy) or intrinsic (based on your expertise in a subject or subjects). With a good reputation and a significant measure of authority you can influence other members of the organization. When you speak on your subject of expertise you are believed, trusted and widely heard. Without good reputation and authority no-one cares about your opinions, and you are unable to influence anyone.
It is easy to think of reputation as something that is more relevant to junior positions and influence as something that is more relevant to senior positions, but this would be incorrect. It is certainly true that you cannot be an effective leader without influence, at the very least within the team that you lead, but you can wield significant influence from a junior position and leaders without a good reputation are inevitably ineffectual leaders whose teams, peers and superiors will invest significant resources in working around rather than with.
Note also that in American corporations leaders generally rely on influence, rather than simply issuing orders, even within the context of their own teams. The culture within American corporations is generally not conducive to authoritarian conduct by the leadership.
There are four main reasons developers get promoted. Their leaders have a promotion budget that needs to be used, their leaders are trying to stop them leaving for another job, their leaders want the rest of the team or organization to know that promotions happen, and (occasionally) because they deserve it.
There are four main reasons developers get pay raises. Their leaders have a budget for raises that needs to be used, their leaders are trying to stop them leaving for another job, the legal department decide that the current salaries are so low the company will get sued, and (occasionally) because they deserve it.
Promotion practices vary from company to company. Some companies have one or more distinct promotion periods. Others are free to promote anytime. Even those companies with established promotion cycles will have a procedure to approve “off-cycle” promotions during the rest of the year if it is deemed necessary (usually because a manager has suddenly become fearful that a developer is about to quit).
Regardless of when you are considered for promotion you are unlikely to be considered in isolation. Rather you will be compared against colleagues who are at your current and future grade as well as against a set of more or less formally defined criteria. In any event, someone is going to need to advocate on your behalf for you to get promoted.
Understanding the how the company approaches promotion and salary adjustments should really be part of the negotiation following an employment offer, but most developers don’t think to ask, and most hiring managers don’t bring it up. Within six months of joining a new company you should understand the promotion process for your team. You need to know who makes the final determination and who is involved in the discussion. Ideally promotion and salary adjustment decisions would be made by your immediate supervisor, but in large companies budgetary control (and thus control over promotions and pay raises) often rests with directors and VPs. Whoever makes the final decision, they will invariably solicit input from people that you interact with across the organization.
You need to help your advocates to help you. Make sure that they are aware of all of your accomplishments and current responsibilities. Most companies have a formalized annual performance review and goal setting process. Usually, this exercise is a waste of everyone’s time, but in the years that you think you have a credible shot of being promoted you should take this opportunity to equip your manager with all the information that they need to make your case for promotion.
Find ways to get exposure to the other people involved in the discussion. For junior promotions the decision will likely be delegated to your first, second, or third line manager and will involve peers of your first or second line manager. Your manager will have an easier time making the case for your promotion if their peers know who you are and can provide positive feedback.
Pay raises are generally less exhaustively discussed than promotions. Your manager will track some metric (compensation ratio) that indicates whether you are over- or under-paid relative to the everyone else at the same grade. In large corporations HR will generally require that your CR be in a fairly narrow range around 1. Those who have been recently promoted will be somewhat below 1, allowing for raises over the coming years, whilst those who are ready for promotion will be somewhat above 1, ensuring that the pay jump required when a promotion does occur is not so large that it wipes out the entire compensation pool. The culture of your company will determine whether the pool of money for pay raises is spread evenly across all the members of the team, which may result in everyone getting a nearly imperceptible increase, or if it is bundled up to give more significant pay raises to a few top performers.
Smaller companies can be more flexible about the relationship between compensation and grade. On one extreme, some companies directly tie compensation to grade; there is no salary band so everyone of a given grade and job function gets paid exactly the same salary. The goal is to ensure that everyone is rewarded for performance, not negotiating skills and there is some evidence that this approach reduces gender- and race-based compensation inequality.
At the other extreme, some come companies have a stated policy that compensation and grade are completely disconnected. In practice it doesn’t work that way. Your grade should be indicative of the level of responsibility you enjoy and the kind of work you are doing so you are generally expected to be operating at the same level as everyone else at the same grade, and when it comes to compensation you will be compared to the rest of the people in that group. Even if your leadership studiously avoid the term “compensation ratio”, in practice you are going to be paid in a band around some median for your grade.
As you move from an entry-level or junior position within a company towards a more senior role you need to develop your skills in a variety of ways. There are three -ships for senior developers, craftsmanship, ownership and mentorship, plus one more for technical leaders, leadership.
crafts·man [krafts-muhn, krahfts-] noun, plural crafts·men.
1. a person who practices or is highly skilled in a craft; artisan.
2. an artist.
In essence, craftsmanship is being good at the technical aspects of software development. A software craftsman is truly skilled in creating software that is correct, robust, maintainable, scalable etc. The craftsman understands both the principles of computer science and how to apply those principles to real-world problems. Note that there is no presupposition of formal training; the road to craftsmanship is generally via apprenticeship (and dedicated practice) rather than structured learning.
A software craftsman will generally know multiple languages and have worked in multiple domains and generally works in abstract terms rather than being constrained by a single technology or methodology.
As you progress from junior to a senior developer you move from being an apprentice, with limited skills, through journeyman to a master of the craft. You mastery is usually cemented by the delivery of a single, significant project that you have been solely responsible for.
own·er·ship [oh-ner-ship] noun
1. the state or fact of being an owner.
2. legal right of possession; proprietorship.
Ownership is about being responsible for the work that is being produced. As a junior engineer you are generally following instructions from a more senior engineer, technical leader or manager. You are not necessarily following blindly, but your role is as an extension of that more senior person. The product, module or component is their responsibility, and your job is to provide the fragments that they need to make the whole.
As you progress to a more senior role you begin to take ownership of ever larger components of the system. First, you might be afforded the freedom to choose your own implementation whereas this might be explicitly laid out for a fresh-out-of-college new hire. Then you will be given ever more weakly defined requirements that will require you to design and implement ever larger portions of the product.
Ownership should not convey isolation. Whilst you may be responsible for a particular piece of the product it is still necessary to solicit the opinions of your peers and superiors, and you will need to conform to the higher level of vision handed down from the architects or leaders above you. The shift when you become an owner is that this input becomes suggestions that you can accept or reject, rather than instructions that you have no choice but to comply with.
men·tor [men-tawr, -ter] noun
1. a wise and trusted counselor or teacher.
2. an influential senior sponsor or supporter.
Everyone needs mentorship throughout their life. The formality of the relationship, the content of the conversations, and even the identities of the mentors will evolve over time, but we all benefit from input from people who are more experienced in some domain or another. The mentorship of a junior developer will tend to focus on developing their craftsmanship and ownership, while the mentorship of a senior developer will tend to focus more on mentorship (how meta!), and leadership. Leaders, in turn look for mentorship that addresses strategy (business or personal), and developing influence.
As your own craftsmanship and ownership blossom it becomes incumbent on you to start mentoring the more junior members of your team thus both enhancing your own abilities and permitting your leadership team to focus on mentoring YOU rather than continually developing the craft of the junior engineers.
lead·er·ship [lee-der-ship] noun
1. the position or function of a leader, a person who guides or directs a group.
2. ability to lead.
The final step on the road is to develop leadership. For many people leadership is something of a superset of the other three -ships. Many people see that leaders embody craftsmanship, ownership and mentorship, so they lump it all together under leadership, but the fact is you can be a damn fine senior software engineer if you have the first three and have no leadership; you just aren’t a leader.
Leadership is simply the ability to independently choose a course of action and have a team of people follow it. The key words in that sentence are “independently”, “choose” and “follow”.
If you have to go and ask someone else for permission before you do something, you aren’t leading. A leader considers all the input information, makes a decision, and justifies it to their superiors later. Of course, sometimes the decision is to punt the problem to a superior who may be better equipped to make the decision, but if that is always the decision then you aren’t a leader.
If you can’t make a decision, then you aren’t leading either. Sometimes, in order to develop a more junior engineer’s craftsmanship and ownership the right thing to do is delegate a decision. That is part of being a mentor, allowing the mentored to make decisions and occasionally fail, but if all decisions are delegated then you aren’t a leader, you are a lossy communication channel between your manager and the rest of the team.
If you make a bold decision and no else follows you, then you aren’t leading, you are operating independently. Actually, this is an acceptable stage of development from individual contributor to leader. One where you have taking full ownership of the situation and can be trusted to make the right call, but it isn’t leadership until you can use your influence to bring other members of the team along with. This is sometimes referred to as a force-multiplying effect. As an individual craftsman you have taken ownership of a problem and found a solution, but you have implemented the solution more quickly by multiplying your impact through the labor of your team than you would have done working alone.
As a fresh, new college hire you don’t get much of a say in the composition of your team. It is the group of people who also report to your manager and that is that. Over time you will gain experience and you will be asked to help interview candidates to fill vacancies on your team.
The goal of having multiple people interview a candidate is to gather multiple points of view and allow people with different specializations to ask domain-specific questions allowing as complete a picture as possible to be formed. Even though the group may “vote” on a candidate during the discussion process, you should be under no illusions that this is a democracy. The ultimate decision to hire or not resides with the hiring manager. In my view, the hiring manager should be the manager of the team that the new hire would join. Some big name companies do things differently and deliberately split these roles and in other companies the hiring decision, like promotion and compensation decisions, are made higher up the hierarchy.
The first thing that you need to understand is what kind of candidate the hiring manager is looking for. Within a big corporate the vast majority of roles are reasonable well defined. Most corporations have well documented job descriptions for the various experience levels (or grades) within each job role. Whilst this makes a good starting point in understanding the requirements of the open position, these descriptions are often deliberately vague and broad. The hiring manager needs to decide which attributes are most important and share this information with the interviewing team.
Most of the people interviewing a candidate should be of equal or slightly greater experience than the position being hired for. Most junior engineers will not have the breadth of experience to judge a candidates fit for a more senior position. Sometimes specific skills need to be evaluated and the best person to perform the evaluation is junior or a recent hire themselves. That’s fine, but the interviewing team can’t be made up solely of junior people. Of course, in a small startup the interviewing team is often the entire engineering team or even the whole company. Equally, it is overkill to use a group of very senior engineers or leaders to interview candidates for junior positions.
Time is very limited in an interview, typically forty to fifty minutes are allotted for each interviewer so it is very important to extract maximum value from time spent with the candidate. Your objective is to be able to talk intelligently to the rest of the hiring team about the candidate’s suitability for the role, specifically whether they pass muster in the area or areas that you have been assigned to evaluate. Each question should be intended to provide another piece of data that you can use to make that assessment. This isn’t something that can be done on the fly. You might see experienced interviewers just walk into an interview, have a “chat” and then come out with a strong opinion about the candidate, but if they are any good they are following a plan they have rehearsed many times in the past. The first few (hundred) interviews you perform should be carefully planned out, down to writing out a selection of questions that cover each area you have to evaluate. You can’t script the whole thing out; that would create a weird vibe and removes your ability to be responsive to the candidate and explore interesting answers. Take notes during the interview. It might seem like you should be able to remember a forty-five minute conversation, but it is surprising how blank your memory can be even immediately after the interview. For the same reason, you should write up your evaluation of the candidate as soon after the interview as possible. Most companies use tools to manage the recruiting process that include a place for interviewers to score the candidate so the hiring manager can review everyone’s notes.
There are somethings that you can’t ask in an interview. There are Federal and State employment laws that protect various classes of individuals from discrimination. You can’t make hiring decisions based on gender, race, ethnic origin, (old) age, marital status or sexual orientation. The best way to avoid being accused of making a decision based on these factors is to keep yourself deliberately ignorant by avoiding questions that would reveal such information. In general, keep to questions about things that are directly related to the job. Specifically, don’t ask about the candidate’s partners, spouses, children or childhood.
A key goal of the interview is to evaluate a candidate’s experience, but what about candidates who have no experience? For recent college graduates the ability to learn and enthusiasm are all you can really ask for so the interviews for such candidates should be tuned to test these qualities.
For candidates with experience the interview process should invite the candidate to showcase their achievements. Drill into projects they have worked on in the past and identify the work they actually performed. Pay close attention to the use of “we” and “I” when describing work done by their former team.
As an individual contributor, most of your interview time will be dedicated to evaluating technical competence. This is notoriously hard to do through interviews. One size definitely doesn’t fit all, but there are some general principles that can be applied. Technical (white boarding or coding) questions need to be carefully constructed and continually evaluated. Brain-teaser style questions (such as “how many pingpong balls fit in a school bus?”) have been thoroughly debunked as providing any information about how well someone will perform as an employee. Good questions are related to work that the candidate will actually perform and have multiple stages that become increasingly complex and abstract. The goal is to be able to accurately rank candidates against previous successful and unsuccessful candidates, and (eventually) employees.
An interview is a formalized conversation where you are trying to ask probing questions in order to evaluate a person’s education, skill level, experience and personality. It can easily become an interrogation, but that is a lousy candidate experience, and if you make it appear as though your company is staffed by arseholes the candidate will go elsewhere. Sections of the interview that are focused on cultural fit, and experience should be conversational, rather than confrontational. While it is important that the interview stays focused on the candidate, finding common ground and sharing your own experiences, when appropriate, help make the interview flow and can go a long way to persuading a candidate that joining the team would be a good decision. Technical portions of the interview should feel collaborative, rather than confrontational. Well chosen questions allow the interviewer to make the candidate feel like they are collaborating to find a solution, rather than being challenged to prove themselves. Of course, they do still need to prove themselves. That’s the point of the interview.
Industries go through booms and busts, but qualified software developers are increasingly hard to find even during economic downturns. Candidates are unlikely to be on the market for long and it is very unusual to be the only company that someone is speaking to. While you are evaluating them, the candidate is evaluating you as a proxy for the rest of the company, trying to decide if this is place they want to work. The questions you ask and the manner in which you ask them already sends a strong signal about the culture and quality of the organization, but you should use some of the time allotted to you to enthuse about the company and the role you are hiring for.
Decisions about the details of the offer are the purview of the hiring manager and the recruiter as are the mechanics of presenting the offer to a successful candidate. It is possible that you may be involved in the process of closing a candidate (persuading them to accept the offer) by participating in follow-on meetings with them or attending social events that they are invited to. You should always be yourself in such situations; the best version of yourself you can be.
Once a candidate accepts the offer and joins your team they will need to be inducted into the policies, procedures, and culture of the team (on-boarded) and then may need to be provided with additional training. The formality of this process will depend in large part on the size and maturity of your company. At a startup on-boarding might consist of a quick check of identity and employment authorization followed by instructions on how to use the espresso machine, whereas a larger company might have many hours or days of on-boarding process. Similarly, larger companies often put new software developers through a “bootcamp” consisting of a several weeks of instruction on the existing codebase, development practices, and coding style culminating in a short, supervised project before assigning them to the team they will work with. Smaller companies might use a more informal series of one-on-one whiteboard presentations to orient the new hire. More experienced engineers will often be utilized as instructors for the bootcamp and may also be asked to attend on-boarding sessions that pertain to the culture of the engineering organization.
The process of team building extends beyond hiring people to fill seats. You form a team by collecting together individuals, but the team won’t function well without mutual respect, trust, and loyalty. In essence, a group of strangers need to get to know each other’s skills and limitations, and gain confidence that everyone will fulfill their duties adequately. There are any number of team building programs that aim to accelerate this process, often by creating a shared sense of adversity among the team members (think trust-falls and rope courses). In my experience, the best way to form a team is to spend time together socially and to work together on a really tough project. Social intercourse helps to break down barriers and ensure that people are comfortable speaking openly about issues and concerns. It can come in any form of activity that is enjoyed by the whole team (coffee, lunch, dinner, drinks, sports) and taking the team out of the work environment for a few days to focus on such social events can help to accelerate the process. Working on a tough project will quickly shake the individuals on the team into their most effective roles and possibly reveal gaps in the skill set of the team.
A successful relationship with your manager should be based on mutual respect and trust. A good manager will delegate decisions about the work you do, especially how you do it, to you, and a good manager will be trusted by their team to provide all the necessary context to make those decisions, including prioritizing the things they should work on. In this sublime environment one of the tasks that your manager will (often implicitly) delegate to you is selecting the information that the manager requires, and choosing when to provide it. Information overload can quickly lead to cognitive overload and an absence of decision making, but an absence of relevant information will quickly lead to erroneous decisions.
You need to be able to identify the critical information from everything you learn during your day-to-day work and be able to present that information in a succinct manner during stand-ups, status meetings, and one-on-ones. If in doubt, it is better to provide more information than less, but part of your continual self-evaluation should include what information you disseminate, how your present it, when, and to whom. Controlling information flow is the part of managing people or situations. These days it has a very negative connotation. It implies knowledge hoarding without any additional value, but as I’ve already pointed out, passing along all the raw information you have can be as destructive to the decision making ability of the recipient as withholding vital information. I’m never going to need to know about all the lines of code you wrote and then deleted or modified; I just need to know if you think a task is achievable and what support you need to make it happen in a timely manner.
Of course, the workplace is never perfect and sometimes you need to provide your manager with a little more guidance.
If your manager is struggling to fulfill their duties then you need to find a way to help them without undermining them. Even if you conclude that the only resolution is for them to be replaced, creating an environment where it is acceptable for managers to be undermined will eventually create more problems than a single, struggling individual or team.
The most obvious way that a senior developer can help a struggling manager is by offering to do some of their work for them. Like everyone else in the organization, managers are likely to be assigned more work than they can reasonably accomplish in a single week. If your career plan includes being a manager yourself you can offer to take on a subset of your manager’s team (if there issue is having too many direct reports). If you are heading down the technical leadership track it may be more productive for you to take on responsibility for projects that your manager is overseeing, rather than people, or to help define and manage processes within the organization.
Managers who are struggling to gain or provide context for their team can be helped by direct reports who have good relationships with other teams within the organization. Liaising with other teams (formally or informally) and providing a summary of actionable information to your manager can benefit the whole team.
New managers need mentorship from peers and their own managers, but sometimes a senior developer can provide useful perspective. For most people, the biggest challenge they face when it comes to improving their performance is evaluating how they are doing right now. Senior developers have generally experienced multiple managers (some good, some bad) so can point out what their current manager is doing well and what they could improve on. In general, it is best to privately provide feedback that is evidence-based and actionable. The formula “When you do <something very specific>, it has <direct, measurable impact on me/the team>, it would be better if you did <something very specific>” often works well, but don’t underestimate the visceral emotional reaction that even the most receptive people feel when you criticise them implicitly or explicitly.
Some managers just won’t accept help. They don’t care for the opinion of direct reports or they believe that things are going just fine. You have a couple of different options under these circumstances. You can just walk away (transfer to another team or find another job) or you can reach out to your second line manager and share your concerns. You need to make a judgement call based on your knowledge of the people involved and your personal investment in the company. You shouldn’t allow yourself to be driven out of an otherwise fulfilling position by one bad manager, but some organizations take a very dim view of people who go “outside the chain of command”. As always, you need to be sure to do the right thing for you while being respectful to your colleagues, and making sure that any criticism you provide is actionable. If you just want to air your grievances pay for a therapist!
The proliferation of high-speed internet and cloud computing have made it seem increasingly anachronistic for software developers to be tethered to a desk in an office building. Digital nomads make it a point of pride to be able to perform their daily duties from virtually anywhere they can get a wi-fi signal. The acts of researching technology or writing and deploying software are basically the same when performed at home, in the office, or at a coffee shop.
There is a general movement to cloud computing where service provides such as Amazon Web Services, Google Cloud Compute, Microsoft Azure, and a host of smaller, more specialized providers replace legacy data centers and co-location facilities. There remain a few (mostly large, established) companies that for various legal, cultural or economic reasons maintain their own infrastructure, but at this point the case has to be made for keeping services on-premises, rather than justifying migration to the cloud. A natural accompaniment to this trend is to migrate collaboration and development tools to hosted services. Thus we see unwieldily Microsoft Exchange deployments being supplanted by Google Mail and internal version control systems being replaced by Git Hub accounts. When every developer in the office is relying on hosted services there is no tactical advantage to being in the office.
If you have read earlier sections of these writings then I hope you realize that, for most software developers, interacting with the rest of your team and the rest of the company is an equally important part of the role. It is much more challenging recreate the experience of sharing an office space with your co-workers from half-way around the world.
The most obvious challenge is that you can’t just turn around and talk to your co-workers. Depending on the culture of your office that might not be as big an issue as you might think. The movement to cube farms and open-plan offices has, ironically, made face-to-face communication less integral to the working day than it once was. Since no-one has an office to step into and talk conversations inevitably distract everyone unless they are preplanned, and a conference room has been booked. To defend themselves against disruptive noise everyone wears headphones all the time, so there are no open or closed office doors to serve as flag indicating now is, or is not, a good time to talk. Coincident with the elimination of the office has been the proliferation of instance messaging (IM) solutions. Most developers these days seem to prefer communicating via one of these solutions to the person sitting right next to them than starting a face-to-face conversation, at least until the topic gets so complex that higher-bandwidth communication is required. By that point you probably need a whiteboard so you are off to a conference room anyway. This affinity for keyboard-based communication benefits the remote developer, since IM works the same if you have an ocean between you, or just Ryan from Sales.
Other elements of in-person communication are harder to recreate than small-group conversations about narrowly scoped topics. One-on-ones between managers and their direct reports can be handled quite well via a cheap video conferencing solution. White boarding sessions of any kind (knowledge transfer, design review etc) are much harder to recreate. Most of the activities that are typically done using a whiteboard can be done via the creation and dissemination of documents, but the resulting process is a very different experience, and it only works if all the members of the team commit to following the process. A team that is mostly local can often fall into the trap of “dailing in” remote team members and just pointing a web cam at a whiteboard. The resulting experience is awful for the remote worker, and they are often unable to meaningfully contribute, which is both corrosive to morale and a waste of money. The situation is even worse when remote workers are in a different timezone. The more distant the worker the more likely it is that ad-hoc meetings will occur outside regular working hours, so they are forced to either follow the working hours of the main office, or miss out on a lot of discussion and decision making.
In general, a team with remote members needs to be much more diligent about documenting, proposals, discussions, and decisions.
Some elements of a co-located team are just impossible to recreate for remote team members. Management by walking around is impossible. There is no opportunity to drift pass someone’s desk and notice that they seem to be frustrated or stuck. Direct reports can’t catch their manager at the coffee machine for a quick checkin. Frequent ad-hoc social events, such as lunches and after-work drinks (or even during-work drinks) don’t happen, or exclude remote team members.
The remote worker needs to take on more responsibility for self-reporting issue to their manager. They cannot wait for an issue to be “noticed” and drawn out of them, they must reach out and ask for help. To be honest, this is more mature approach anyway, Perhaps this is part of the reason that more experience workers have more success as remote workers. They know when to ask for help and don’t worry that needing support will be perceived negatively.
Teams with remote members should expect periodic travel so that the team can come together in one place to develop trust and foster a healthy culture. Remote workers should be invited to (and transported to) scheduled team events (holiday parties, ski trips, offsite meetings). Absent any other reason, the whole engineering team should probably aim to meeting in one place for a couple of weeks every three months either at a central office, if one exists, or at a mutually convenient location.
The challenges described here are similar for teams that are entirely remote (aka distributed) as well as those that have a distinct head office with remote team members. The key difference is that with a 100% distributed team everyone has to deal with the challenges of being remote whereas on a team that is mostly localized with only a few remote team members most team members are not directly affected by the challenges of remote work so can become (or remain) insensitive to the challenges. It falls to the managers of the remote team members to create awareness and provide tools and processes to mitigate the challenges.
The challenges of remote workers are exacerbated when those workers are operating in a different timezone. The more timezones the team is spread across the more challenging it becomes to find any time when the team are all working. There are additional challenges when team members are operating out of different countries, but those are more likely to be legal (related to contracts, working conditions and travel), and so are more of a management problem.
At some point in your career you will need to decide how you want your role to evolve. Standing still is not an option. If you just perform the same task year in and year out then you will see your wages stagnate and your motivation sink. Let’s call that option zero and move on.
The way I see it you have four credible options
1. Become a specialist.
2. Become a technical leader.
3. Become a manager.
4. Change careers
and one incredible option
5. Join/found a startup that becomes so successful that you make fuck-you money.
If you really like working directly on a product and don’t want to really deal with people beyond enthusing about a cool technology that you have learnt about then being a specialist is probably the right thing to do. This isn’t the same as stagnating and standing still. Technology is always evolving so there are new tools to learn about, new paradigms to explore, and there are always more details to learn about things you already “know”. The evolution in the database world from the dominance of relational databases to the rise of document and key-value stores is a good example. If you were the company’s resident database guru for the last decade you would have had your work cut out for you following the evolution of innovative technologies into mature products, and then helping drive the migration of existing infrastructure to the new hotness (or acting as the force of reason preventing a premature commitment to immature solutions).
If you want to retain a product focus, and appreciate the force-multiplicative effect that good leadership can provide, then you are probably a good fit for a technical leader track. Technical leaders are responsible for a team (or teams) of developers focused on a the delivery of a project (or projects). The technical leadership track leads through titles like Principle Engineer, Fellow, and Chief Technical Officer, where each step up the pyramid sees the technical leader providing guidance to larger teams and driving bigger projects extending to entire products, product lines and, eventually, the technical strategy for the whole company. In additional to driving technology choices, and providing the overarching design or architecture, the technical leader is responsible for injecting the vision and prioritization from the wider company into their projects, and serving as the bridge to peer teams such as sales and marketing.
While technical leaders focus on the product, managers focus on people. If you get satisfaction from helping junior developers build their skills, enjoy building teams, and husbanding a company’s culture then you should consider the management track. For a (dark) period of time it was asserted that management was somehow discipline agnostic. Any manger of people, it was claimed, could successfully manage in any industry. I don’t think this is the case. There is immeasurable benefit to having walked a mile in the shoes of the people who look to you for advice and guidance, and I think that all managers of technical people should contribute to the projects their team is working on both to maintain a technical edge and keep an awareness of the issues currently facing their team. Books have literally been written about managing developers, and new managers should approach leaning management the same way they would approach learning a new technology, by researching best practices and finding good mentors.
Technical leaders and managers share responsibility for products, process and people. While each has their area of primary responsibility, the relationship is one of equal collaborators. Some organizations choose to delegate responsibility for process to dedicated project or program managers, but in my view this is unnecessary and possibly even harmful. Professional project managers are rarely imbued with the necessary authority to effect meaningful change so are dependent on executive sponsorship and relegated to serving as a human checklist for defined software development processes.
It has been a couple of generations since jobs and careers were for life. Many people now change career during their working life. It is important to check in regularly (every couple of years) with where you are in your career and whether you are still enjoying yourself. Jobs that we find enjoyable when were are younger can become burdensome as we gain experience. There is no shame in deciding that you have done all you want to do and it is time to try something new. Good developers are logical and focused with good communication skills, and those talents are in demand in other jobs. Be careful to avoid the Arrogant Arsehole trap. Just because you are a competent engines does not meant that you will automatically be good at the next thing. You will need formal and informal instruction to be successful. The single most important thing is to ensure that you give yourself enough runway to make the transition. You are either going to need to save a substantial financial cushion or have a partner prepared to bankroll your transition.
These four options are all well-defined paths to success (however you define success). The fifth option is poorly defined and very unlikely to be successful, but that doesn’t seem to stop plenty of developers from trying it! Founding a tech startup or joining one at a very early stage is extraordinarily risky. Most startups aren’t successful, so founders wind up losing their investment and early stage employees work for several years earning a salary that is either below or far below what they could command at an established company. Even “successful” startups often only end up generating net value for the investors and founders. Startups that create millionaires from employees are so rare that they are called unicorns. Even then, the time to actually realize that value is generally longer than people think; it takes five to ten years to build up the kind of value in a company that will convert a typical early-stage employees equity stake of less than 1% into serious fuck-you money.
Of course, there are reasons beyond the immediately financial to join a startup. Some people find the unstructured (chaotic!?) environment liberating. Everyone has to perform multiple tasks so there is ample opportunity to learn new skills and technologies. If the company does manage to survive then you have the option to be involved in the creation of an engineering organization from the ground up, giving you influence over the culture and practices of that team.
There is a vast corpus of written material about co-founding a startup, so there is no need to rehash that here. If you do decide to go that route it is important that you educate yourself before committing, otherwise you reduce the chances of success, and may find that you have been screwed out of your fair share of the rewards. Less is said about joining a startup as an early-stage employee.
The first thing to do is make sure that you are really joining as an employee and not a technical co-founder. Sometimes an “idea” person and “sales” person get together (sometimes with an angel investor), and decide that they have a great product and just need to employ a developer to build it. That’s just wrong. Execution of the idea is way harder (and more valuable) than coming up the the idea in the first place. If you are the first technical person to join a tech startup then you should probably be coming in as a co-founder. Go back to the previous paragraph! If there is already a technical co-founder (often a CTO) then you are legitimately coming in as an developer employee. You should probably still do some research into startups so you know what you are getting into.
Early stage startups have to conserve cash (aka runway) in order to maximize the time to get to a minimum viable product and start getting customers/users. As a a result, early stage employees invariably have a lower base salary than they would get at a more established company. To counter this lower salary the startup will offer equity, probably in the form of restricted stock (see the Arrive:Compensation and Benefits section for more about the different kinds of equity). For financial purposes you should probably just assume that the equity is worthless. For most companies this is true because the company will fail and either go bankrupt or be acquired by another company for just enough money to repay the investors and nothing more. If the company does become successful, you won’t be able to cash out your share for many years, and you really have no way of knowing how much it will be worth. Of course, that doesn’t mean that you shouldn’t get an appropriate amount of equity. There are plenty of resources online that help you map your employee number (1st, 5th, 10th etc) onto a typical equity range.
In addition to the lost salary, there is also an opportunity cost when you join a startup. If you are qualified to work at one then you are probably qualified to work at many so you need to maximize your chances that investing many years of your productive life into a company will yield some form of return on that investment. In addition to the evaluation you would perform before taking any position (considering fit, commute, management style, technology choices etc) you should also evaluate the company through investors eyes. Is the management experienced in either founding tech companies or in the sector the company is focussed on? Does the idea seem credible? Do they have investors, customers or even (gasp!) revenue? For the purposes of financial planning you should probably just assume that any equity will be worthless, but the decision to commit to a company needs to be backed by some kind of analysis of the likelihood of success.
It is pretty rare for a software engineer to stay at the same company for all of their career, and even rarer for them to stay within the same organization that whole time. Transferring between groups in a large company can be virtually indistinguishable from apply for a job at a new company except you don’t have to do some of the HR paperwork at the end. In fact, the only internal transfer I ever did had a more arduous interview process than all the job interviews I’ve done before or since!
There are a number of different (good) reasons to quit. For me I generally get a gut feeling that it is time to move on and then I need to spend some time understanding what is making me feel that way.
The two strongest predictors of whether an employee will quit in the next year are their commute, and their relationship with their immediate supervisor. All the other factors are significantly less important.
Changes in your personal circumstances may cause your commute to get significantly longer or less pleasant, but sometimes the commute stays the same and just becomes intolerable after a few years. If you don’t want to move your home closer to your workplace then you are going to need to find a new job.
The relationship between you and your immediate manager is probably second only to the relationship you have with a significant other. There are many reasons that the relationship can deteriorate. You may find that you misjudged them during the interview process and just don’t like them, their style, or their philosophy. You might move to a new group or have a new manager assigned to your team. Alternatively there might be a wide cultural shift within the organization that your manager responds to in ways that you don’t like. Finally, the change might be within you; experience and maturity can alter your perspective and make some attitudes and actions that were once tolerated, intolerable.
Understanding what has changed, and why, is important if you are going to find a long-term solution. If all you know is “my boss sucks” then you might end up swapping one incompatible manager for another incompatible manager. If the issue is the individual manager then you might be able to rectify the problem without leaving the company, perhaps by transferring to another team. You can also try raising your concerns with your second line manager. Just be sure to make your criticism constructive and bring a few concrete ideas for how to solve the issue, otherwise the organization might decide that the problem is you, not your manager.
If the problem is a fundamental mismatch between you and the wider organization then the only realistic option is to move on to another company. Time spent identifying the cause of the conflict is an investment in the future. It should arm you with a series of questions you can ask the hiring mangers at any companies you apply to in the future in order to avoid ending up at another company with the same mismatch.
Assuming your commute is acceptable and you have a good relationship with your manager probably the next most likely reason to leave is because you have stopped growing professionally. This may be because you have climbed as high on the management ladder as you think you will get at the given company, or because you have learnt as much as you can about the technology the company is using and the company is in no hurry to migrate to something new, or perhaps because the company or your team has changed focus and the new direction is no longer aligned with your goals.
Being employed by a company that is not financially healthy is a great reason to look for somewhere else to work. It’s probably fairly obvious to everyone that if your current employer stops paying you it is time to look for another job, but if you are still coming into the office the month they fail to make payroll then you have waited way too long. You really need to think of your job as an investment. You loan them your labor and your creativity in return for various benefits, including income. Until you are in the final years of your career you expect those benefits to grow as you become more experienced and take on more influential roles.
When a company starts to contract financially, even while they are still making regular payroll, managers will come under pressure to reduce costs by limiting promotions and pay raises. You don’t need to stay at a company that has a moratorium on pay raises for very long before there is a meaningful gap between your income and what you would be making at an equivalent company with no such moratorium. It is important to pay close attention to the financial health of your company. If you work at a publicly traded company pay attention to the quarterly earnings reports and learn how to interpret them. Whether your company is public or private ask your management for their perspective and ask for details. Experienced managers at healthy companies will be happy to share what they know (and if they know what’s good for them they will be asking the same questions of their managers). Management that is cagey about financial information is either hiding something or is immature; neither of these is a good thing.
Once you have determined that your company is struggling you can make an informed decision to stick around and try to be part of the team that turns things around or to punch out. If no-one in the management chain will acknowledge the problem, or provide a concrete plan for changing things then you should bail out. If you stay it is important that the executives recognize that employees are accepting more risk than they would be at a healthy company and should be prepared to offer something (equity, performance related bonuses) to compensate for that increased risk.
If you are leaving for reasons other than a conflict with your manager then you might be able to enlist their help finding your next position. A good manager will have been working to develop a good rapport with their team and should have been helping you evolve your role according to your professional goals. They should know as well as you if you are reaching a point where changing companies is the best option for you. Mature managers recognize that people are going to eventually move on and they don’t take it personally. I’ve even heard some managers refer to staff departures as “graduation” rather than “attrition”. When it happens, it is an opportunity for the manager to grow their professional network by getting you hired into a company they don’t have a connection to, or they can reinforce a preexisting relationship by playing matchmaker.
Whether you choose to involve your manager in the process of finding a new job or not there will come a time when you have to announce your resignation. You should tell your manager first and expect them to ask for you to give them some time to talk with their manager and peer group before breaking the news to the rest of the team. This is a courtesy you should extend to them, but set a time limit. You shouldn’t operate for weeks in this mode. Unless you are leaving for a direct competitor, most companies will expect you to stay around for at least a couple of weeks to finish off projects and hand responsibilities off to other people. Unless your contract or local law specifies a fixed notice period, the length of time between announcing your resignation and actually leaving the company is subject to negotiation between you and your manager. You should aim to leave on good terms, but you also need to act in your own best self-interests.
When I wrote this the demand for competent software developers was incredible. The question is not whether you are going to get a new job, but where you want to work and with whom. This needs to be a conscious decision. Don’t just take the first opportunity that comes along, and if you get an unsolicited offer to interview at a company that sounds interesting use that as motivation to survey the market and apply to a couple of other places at the same time. If nothing else, having competing offers helps when it comes time to negotiate salary and benefits.
With each job transition, whether between companies or between organizations within a single company, you should grow in at least one direction. If you are staying in the same industry with a team using the same technologies, then the new role needs to be a promotion.
Moving to another company in the same industry that is using different technologies, taking a different approach to solving the problem, or working on a different aspect of the problem space are all viable strategies. Most industries have some kind of eco-system of products. Security, for example, encompasses firewall products, virus scanners, threat intelligence companies etc. Moving between different parts of the eco-system allows you to gain and give new perspectives without having to completely abandon your comfort zone.
Many times one industry will be driven out of necessity to develop innovative technologies or techniques. Porting technologies or techniques from one industry to another can be an effective way to cross over to a new industry.
There is no one right answer, you need to do the right thing for you at each transition, but you should aim to grow in at least one dimension while keeping a foot in the known world.
As I said in the section on building your network, the best route to a new position is via someone you already know. If you have a good network you should use it when you are looking for a new job. Send personal notes to solid contacts within your network and make it clear what you are looking for next. Don’t restrict yourself to former co-workers at places you want to work. People in your network will often know about open positions within their network so you should reach out to everyone, but make it clear if you aren’t looking for a position with them.
If you find a position that you are interested in you should look through the employees of your target company on LinkedIn and search for a common connection, no matter how tenuous, and request an introduction. Do anything you can to get your résumé in front of the hiring manger without running the gauntlet of HR and automated filters.
Job boards are a viable alternative to hitting up your network, but they are harder work. You should expect a more intensive interview process and if there is any question about fit or competence you won’t get the benefit of the doubt and you won’t have an advocate in the room.
Recruiters, especially third-party recruiters (contractors and firms) often write impossible job descriptions (known as “purple squirrels”). Typical examples include demands for more years experience in a technology than said technology has existed, or asking for an impossibly broad range of skills. This is particularly common when a company has multiple related position open and the recruiter decides to mush all the job descriptions into one! From an engineering perspective, they have substituted all the OR combinations with AND. Instead of “expert in technology X, Y OR Z” the resulting mess demands “expert in technology X, Y, AND Z”
It is important to learn how to pick apart such job descriptions. If you have experience hiring in a prior role you can probably make an educated guess what a company is really looking for when you find an implausible job description. After you read a few (hundred) job descriptions online you should be able to separate reasonable from unreasonable and further pick apart the unreasonable. If in doubt, just apply for the position!
Whether you get a referral to the company or not, the first thing the hiring manger is going to look at is your résumé so you should invest time making it look good. First and foremost it needs to be readable. Keep the text simple with headings either in larger font and/or bold. Avoid sprinkling bold or italicized words through the text as it make it harder to read. Obviously, your résumé should be free of spelling errors and grammatically correct. You should enlist the help of someone (preferably an experienced hiring manager or recruiter) who is very fluent in the language the résumé is written in to proof it for errors and non-idiomatic phrases.
You want the hiring manager to have a sense of inevitability about you joining their company. Through your résumé and the conversations you have you want to convey the sense that everything you have done in the past is leading to this point. You want to create a narrative that runs over the past ten years or the length of your professional life (whichever is shorter) and builds to the logical finale of you being offered this job.
The résumé should focus on achievements. They don’t need to be ground breaking, but they should have a meaningful impact on customers, company, or colleagues (in that order) and you should make that impact clear. Don’t just list off the projects that were delivered without quantifying the impact.
Suppress irrelevant experience. You can list jobs outside of the narrative (especially that three years you spent running a café in Paris) so you don’t have gaps in the timeline that will naturally be assumed to be periods of incarceration or insanity, but you don’t need to provide any details. If someone cares, they will ask. Similarly, most people don’t care about things you did more than ten years ago unless you were literally inventing a technology still in common use. Set yourself a hard limit of one page. Remember that a résumé and a curriculum vitae are different things. Your résumé should provide just enough highlights of your career to make you seem worth a first phone call or interview and seed the questions you want to answer in that interview. You don’t need to list everything you ever did.
If you are applying through an online form you can include the list of technologies/languages you know as a section called skills (or just call it “keywords”) to try to get past the brain-dead filters some companies still insist on using. If you do list technologies, list the ones you would actually be comfortable using from day one or in the interview. If you say you know C++ and Python I will probably ask you to compare and contrast those two languages. If your “experience” with one of those is that two week project back in college you end up looking stupid or dishonest. This block should go at the end of your résumé since computers don’t care where it is and humans aren’t going to read it. Don’t give you skills “grades”; it looks dumb. List things you can use and ignore everything else.
Interviews are a nerve-racking experience. No matter how qualified you are or how many times you’ve done it you are still being forced to justify your life choices and prove that you are competent at your job in an unnatural, high-stakes environment.
Make sure you answer the question being asked! If you aren’t sure, ask for clarification. Sometimes the question is deliberately vague in which case the interviewer will say so or perhaps ask you how you would choose between different options (hint: the answer is always to go back to the customer)
Don’t lie. This should be a no-brainer, but apparently not. There is no point lying either about your skills or your goals to get a job. The best case scenario is that you end up getting a job that you will suck at or that doesn’t advance your career in the right direction. More likely you’ll get found out, laughed out of the building and, depending on how extensive the recruiter/hiring manager’s network is, you might find a lot of other companies don’t bother returning your calls!
When you are working through technical problems in the interview be sure to explain what you are doing. Verbalize your internal thought processes, even though it feels weird and unnatural. Getting to the right answer (assuming there even is a single right answer) is much less important then demonstrating that you take a reasonable and structured approach to problem solving. If you are writing code make sure that it is syntactically correct and legible. You need to call out error conditions and edge cases, but you probably don’t need to write explicit error handling code in the interview unless it is clearly part of the challenge. I usually just point to each line that can return errors or throw exceptions and tell the interviewer “Obviously, I would add error checking and handling code for conditions A, B and C”. Ask questions to clarify the problem, but remember that the interviewer is interviewing you and that you need to answer the question.
The interview process is very much focussed on evaluating you as an developer and individual to see if you meet the company’s (hopefully) exacting standards. It sometimes be hard to remember that this is a two way street and that you should be evaluating the company. In fact, it is much more important that the company be aligned with your goals than you fit the company. Unless you are talking to a very early stage startup, the worst that happens if they make a poor hiring decision is that they waste a small fraction of their total annual budget. If you join the wrong company you might miss out on the opportunity to join one that you would be much more successful at and will find yourself going to the effort of looking for another job all over again very soon.
If you’ve done a good job of setting the narrative through your résumé and the answers to questions during the interview process then the role and compensation you get offered should be a good match for what you are looking for, but at this point everything is up for negotiation. Check the earlier section on Compensation and Benefits to understand the different ways that you are compensated for your work and look at the Promotion and Pay Raises section to understand the questions you should ask about that process at your new company. Once the decision has been made to extend an offer the hiring manager has a good idea of where they want you to sit in the organization and that will drive the salary, bonus, and equity range that you need to fall into. There may be flexibility to exchange one of these (base salary, say) for one of the others (equity, say), but unless you are a truly exceptional individual there are limits to how far from the median they will be willing to go.
There needs to be a really strong case for taking a reduction in total compensation! Pretty much the only reason I can think of is a significant change in career, where you need to step back from master to apprentice for a period of time. That should be a temporary state as your alternative experience should then make you uniquely valuable in your new profession (as a product manager who has actually engineered and shipped products, for example).
Generally a new job should significantly increase your total compensation. Occasionally an opportunity comes up with so much more growth opportunity that you are prepared to take merely matching salary, confident that future compensation increases will outstrip your current position. Be firm on your salary expectations. Even if you love your job someone somewhere is making profit off your labors (unless you work for a non-profit) and you should be sure to get your fair share. If that sounds too selfish, think of your co-workers current and future. If you accept below market rate salary you create downward pressure on your co-workers’ salary and may cap what future employees are offered. Frankly, not doing your utmost to maximize your compensation is disrespectful to everyone who ever has or will do the same job, and is downright selfish!
Bear in mind that most mature companies don’t consider adjusting salary for employees in the first year and many startups have no process around regularly reevaluating employee salary so whatever you start with you may be stuck with for several years until you raise it as an issue and make a compelling case for an increase.
Read any employment offer carefully and check for non-compete clauses and other clauses that restrict what you can do while, and after, you work of the company. You should also ask for a copy of the employee handbook, since this describes expectations that the company has for employees and usually constitutes part of the employment agreement.
Employment law varies from state to state so you should do a little research about the rules in the state that you will be working in. Don’t expect the company you are joining to break this down for you. A general rule of contracts is that you shouldn’t give up something without getting something. In the state of California blanket non-compete clauses in employment contracts are generally considered unenforceable. For senior executives non-compete clauses are generally considered enforceable when they are partnered with some kind of compensation. One year non-compete clauses are typically accompanied by a guarantee of one year severance or early vesting of equity etc.
The California labor board has determined that companies cannot prevent their employees from taking a second (legal) job on evenings or at the weekends (moonlighting). Employers that prevent employees from moonlighting or punish them for doing so can be fined.
If the role, compensation, or terms of the contract don’t fall within your expectations you have to be prepared to walk away. If you find yourself in a position where you feel you have no choice but to accept a substandard offer you’ll be unhappy in your job and will start looking for a new position within the year. Don’t beat yourself up about it, but spend some time thinking about how you got yourself into that situation and don’t do it again.
Mushrooms are delicious. They go in salads, soups, stews and lots more. Mushrooms get eaten … or they get forgotten and rot back into the shit they are grown in. Don’t be a mushroom.
There are many metrics for success. For some people “software developer” is a phase they pass through on the way to some kind of management (product or people). For others happiness is finding a technical niche they can master completely. For yet others it is just a job that pays for food on the table and hobbies at the weekend. Regardless of your personal definition of success, unless you are well-informed and deliberate in how you choose to spend your time, you are at the mercy of forces beyond your control or even awareness.
If you pay attention and ask the right questions you can maximize your chances of being successful. You can survive, thrive, and drive your career wherever you want to go as a software developer.
Good luck out there.