Skip to content

What is your BATNA?

When you are negotiating, you always want to be thinking about your Best Alternative to a Negotiated Agreement (BATNA). This applies in any negotiation, whether business, personal or even with yourself. When you have a better BATNA, you have more negotiating leverage and are more likely to get what you want out of it.

This is why when I was a contractor, I always had more than one client. Even if I was working with a good client who paid well, on time and was fun to work, I had more freedom if I had another client. Things might go south at the first client and I wouldn’t be out on the street. It’s also why I would always start looking for a contract 6-8 weeks before my current contract was finishing.

It’s why you should always get competing job offers. If you have a job offer and your best alternative is to keep job hunting, that’s not appealing. If, instead, you are choosing between two job offers, you are in a much better position. (No duh!)

It is also why it’s always easier to get a job if you have a job. The BATNA of declining a job offer when you have employment is, well, you remain your current position. Your current job may not be all that awesome (which is why you are looking) but for most folks being employed is a better alternative than being unemployed.

How can you use the concept of BATNA to improve your life?

First, be aware of the concept. Start to look at decisions in your life and think about the BATNA. Even small decisions, like ‘should I get coffee or nothing’? Or ‘what happens if I ask my wife to take out the garbage’? Or ‘should I ask for a raise’? In all of these cases, you can expect some kind of negotiation, and you can think about what the alternative is if that negotiation fails.

Second, take actions to improve your alternatives. If you are unemployed and want more leverage in the job hunt, start consulting. If your wife won’t take out the trash, can you improve your BATNA by making it easier to take out the trash yourself (maybe move the trash can into the garage)? Or building some kind of trash chute?

The concept of a BATNA is key to getting the most out of any negotiation. If you have good alternatives, you have more leverage to leave the negotiation, and if you don’t, you will need the negotiation to complete successfully.

More about BATNAs and salary negotiation here.

Business Contracting Basics Jobs Lifehack | moore | | Leave a comment

When should you leave a job?

Saw a great post by Kathy Keating, on a slack of which I am a member. This is how she suggests thinking about whether to stay or go at a given position:

1) Are there ethical issues? Leave.
 

2) Are there leadership issues?

 

2a) Can I have transparent/open dialog and is there hope that the leadership issue can be addressed? Timebox length of stay.

2b) No dialog. No hope of addressing issues. Leave.

 

3) Are there systemic company process issues?

 

3a) Company knows and is addressing the issue. Timebox length of stay.

3b) Company is fine being a mess. Leave.

 

4) Do I have career growth?

 

4a) No. Leave.

4b) Yes. Stay if no other blockers.

This is a lightweight framework to consider when you have a bad day or week at work. It’s important to acknowledge that:

  1. I (and most other software developers) are very privileged when it comes to job expectations. (My SO worked in healthcare and the stories, oh the stories.)
  2. The grass is not always greener and if you stay you might have credibility to effect change.

I think there are other factors that might play in here like type of work, location of work, and compensation, but in general I love this flow chart of how to decide whether or not to stay in a job. If there are other items that are important to you, add them into the decision tree, but having something like this will make it easier to make a hard decision like leaving a company.

PS No post about deciding to leave a job would be complete without referencing Shields Down and Bored People Quit.

Jobs Recruiting | moore | | Leave a comment

When is a senior engineer not a senior engineer?

The technology industry has been overloading the term ‘senior engineer’. A senior engineer is not a senior engineer is not a senior engineer.

What “senior” really means depends on what your organization needs and how it operates. Much of my experience has been in small organizations, so this list may be tilted more toward jack of all trades, but I’ve seen some of these patterns at larger companies as well. Here are a number of attributes that all seem to get wrapped up in the word “senior”.

Domain knowledge: sometimes getting up to speed on a domain can take too long. If you are operating in a highly regulated or intricate problem domain (real estate, finance, health care, government contracts), senior may mean “this is not their first rodeo”. In other words, someone who can jump in and understand complicated entity relationships and acronyms quickly.

Deep technical skill in the problem space: someone who has been there before. ‘There’ is a technical area where screwing up is going to be very bad for the company, for example, scaling an application, running a database or securing an environment.

Deep technical skill in the exact technology: someone who has used your exact technology stack before. The idioms, the libraries, the warts, all of these vary enough and if you want someone senior in technology, a close substitute won’t do. If your app is in Django, you need a senior Django person, you don’t need or want someone with Rails or Laravel experience. Same for someone with PostgreSQL experience (as opposed to MySQL). I see lots of job applications where this was a belief, but fewer organizations where this is a reality. This is often just a simple way to filter applicants.

Broad technical skill in a related area: someone who has used something similar and can come up to speed quickly by making analogies between similar situations. Maybe you can’t find that exact match. In that case, you can broaden your search. At a hight level, MySQL and PostgreSQL have a lot of similar characteristics, and mapping knowledge of PostgreSQL into MySQL (or vice versa) can be effective. This senior developer works best when paired with a someone with “deep technical skill in the exact technology” person because then they can pick up idioms and libraries.

Utility player: this type of senior developer can fill gaps in your team. They notice what isn’t being done, whether that is setting up a build system, documentation, project management, user testing, design or something else, and either do it or advocate for it. Or both. Probably more important in smaller organizations.

Leadership: this is the ability of a senior developer to lead a team toward a business goal. This includes understanding why the goal is important, caring about the goal, communicating the goal to the team, and rallying the team when the goal seems unattainable.

Mentoring: this is the ability to develop other talent in your organization. Whether or not there is a formal mentorship program, skills transfer and teachable moments happen every day (and are not always performed by the more experienced party!). Doing this requires empathy. If your organization has a lot of less experienced developers, a more formal program may be useful.

Humility: senior developers are senior because they’ve made mistakes. This is the ability to acknowledge mistakes, learn from them, and try to figure out how to make only new mistakes.

Continuous learner: this type of senior developer is looking at new technologies and developments and seeing how they map into the current problem space. Often they are just “playing” with technologies on their own time. If they’re really good, they’ll acknowledge their “shiny object” syndrome and advocate for ways to explore new technology that don’t impact long term maintainability (spikes, hackathons).

Cross department communication: the ability to build a mental model of who knows/owns what in your organization. When hiring a new developer, they won’t have this map, but they may have built one for previous organizations. Someone with this knowledge knows who to ask to get something done, or who needs to be notified when changes are coming. This can prevent the significant pain of building the right solution to the wrong problem. Leveraging someone with this skillset cuts down on formal process, but eventually these communication channels may need to be formalized as the organization grows. Probably more important in smaller organizations.

Project management: depending on the size of your team or organization, a senior developer may need to be the adhoc project manager. They probably won’t enjoy this much, but someone has to do it. They’ve seen what happens when someone doesn’t (see “Humility” above).

Development support/operations/devops: this is the glue around your application that helps your application function. These tasks can range from developer focused tasks like a coding style guide or maintaining the developer docker image to operations tasks like setting up the monitoring system to devops tasks like debugging the failing jenkins job.

Deep knowledge of current application: this obviously isn’t a senior position you can hire for, but is one that a developer can grow into. This is the senior person that knows all the answers about the growth and path of the application code. If they’re really good, they document and share the knowledge.

When you are posting a job description for a “senior” engineer, think about what dimensions listed above matter. You can’t find someone who is good at everything, so what do you really need? What does your organization need?

Jobs Recruiting | moore |

Coding tests for interviews

Ahmed Fasih posted his proposed alternative to a HackerRank pre-interview test. This sparked comments in the HN discussion.

I think it is worth approaching these kinds of tests from both sides, as this topic has come up a lot in some email lists of which I am a member.

As an employee, you want to be assured of the best chance of finding a job that is a good fit, and of minimizing the time spent to apply to each job. You also want to maximize the number of jobs you get offered, so you have optionality (“well, I’d love to work for you, company XYZ, but I’m considering other offers and was wondering if you could give me more XXX” where XXX is whatever you desire, money, time off, health care, etc).

As so many employees say in the discussion, if you are a senior person, these kinds of tests can be a bit insulting and disconnected from the actual work. Who is going to transform a 2D array in their regular job? I’d reach for a library or stack overflow answer.

On the other hand, if you are at the point where you need to fill out an online test rather than talking directly to the hiring manager about how you can solve her pain points, maybe that’s a problem? LinkedIn is pretty magical in terms of finding this info out, though of course there may be corporate protocols that make this circumvention impossible.

As an employer you want to find the best person for the price in the shortest amount of time. Where best depends on the position, but is some mix of skills, culture fit, desire for the job, and perceived amount of time they’ll stay. You also want to be fair to all applicants and have some kind of apples to apples means of comparison.

As so many managers say in the discussion, these tests weed out folks who can’t code their way out of a paper bag. If you’re a senior engineer, you’ve probably worked with some folks like that, so you can see the need. They also do so relatively quickly and in a way that scales and is equitable across different candidates.

So, as a senior engineer, I’d:

  • seek employment where I could circumvent these types of tests through my network
  • avoid these types of employers unless it was a great job
  • if I had to take the test, try to have sympathy with the employer and take it as an opportunity to brush up on my algorithms

And if I were the employer, I’d think about these tests are a filter. Just like a GitHub profile, they’ll give you some information. Whether that information is relevant to the current candidate search, and is worth filtering out good candidates who don’t bother filling out tests, is an exercise left for the reader.

Jobs Programming Recruiting | moore | | Leave a comment

Absence of evidence is not evidence of absence

I am on a mailing list of engineering leaders and someone mentioned that they have found Github to be a very good indicator of whether a candidate is a good choice for them.

Of course, every company will emphasize different aspects of software development–for some technical expertise is more important than communication, while others have that ranking flipped. Some may emphasize ability to work in large teams, while others may prefer folks who are self driven.

But I see a fair bit of emphasis on Github profiles, which makes sense–you can actually look at the code someone has written, and how they developed it.

But here are some reasons why someone might not have a stellar Github profile.  They might:

  • prefer to use bitbucket so their code is private
  • have a restrictive employment contract
  • not want to program when they go home
  • want to learn about software by experimenting on their local computer
  • learn about other aspects of software development by reading rather than doing
  • focus on answering questions on Stackoverflow
  • not have time to have anything on their profile due to other commitments

If someone has a great GH profile, that’s probably an indicator they are a good developer. But if they don’t (full disclosure, mine is kinda weak), that’s no indicator of anything other than that they haven’t made it a priority.

Jobs Recruiting | moore | | Leave a comment

When do you earn your pay?

I was driving today and saw a bus driving in the snow. I’ve never driven a bus, but I imagine that snowy days are some of the most difficult. The roads are bad. People are crabbier. Accidents happen. You are still on the hook for making the schedule. I’m no bus driver, but I bet when the driving is easy, as in the summer during off peak times, the job is easier.

However, when things get hard, that’s when you earn your pay. Since software development is such a sprawling occupation, it’s hard to generalize about the most difficult moments, but I can mention some of mine:

  • When I face a problem that you’ve never faced before and have no idea how to tackle it (like setting up recurring bookings over daylight savings time changes).
  • When I ship a bug that costs your customers money and I have to analyze how much money was lost and a game plan to fix the bug and get them their money. Then I need to contact the customers to apologize as well as let them know what the plan is.
  • When I realize I’ve chosen the wrong implementation for a component.
  • When I realize I’ve made an architectural decision which made sense in the moment but will have maintenance and performance costs down the line.
  • When the system crashes and I know the reason, but I haven’t figured out a way to replicate it or to fix the issue.
  • When a system is slow and I am unsure where to start looking.
  • When someone on my team isn’t working out and I need to let them go.
  • When I watch a user navigate around your system and totally miss features that will make their lives much easier.
  • When I join a new project/company/team and walk into an existing system of software and personalities about which I have very little clue. And yet I want to be effective and move things forward, but need to be patient.
  • When I argue with someone about the best way forward, and then my path isn’t chosen, and I have to support the plan that was chosen.
  • When I argue with someone about the best way forward, and then my path is chosen, and I have to work with people who disagreed and may not fully support the new plan.
  • When I am at the end of a project and I just want the damn thing done, and yet I have to maintain the same level of attention to detail that I had at the beginning when the idea was all new fresh and exciting.

You don’t earn your pay for the easy stuff. It’s when the going gets tough that you really earn your pay.

Business Jobs | moore |

Founding Engineer or CTO, translated

If you wanted to re-read my post about the various technical roles a co-founder can take as a startup grows in Russian, you can, here.  Thanks to Vlad for the translation.

Bonus!  Here’s discussion on Hacker News, including my favorite comment:

Having been on both sides of the situation a couple times, the distinction is pretty simple for me: do you have a seat on the board?

If you have a board seat, great, you’re a real founder/CTO!

If you’re not interested in the board seat or you’re aware that you don’t bring enough to the table to earn it, you’re a good candidate for a founding engineer. You should be happy!

If the other founder(s) want you to be a founder/CTO without the board seat, run! They’re just using the prestige of the title to pay you less, and will revoke it at the first convenience.

 

Jobs | moore |

Knowledge in software development: what’s your wood lot?

Gene Logsdon, who passed away in 2016, was a farmer and a wise man.  In a recent repost (originally written in 2008), he discusses why wood is more valuable than gold.  From the post:

You can’t eat gold like you can the bounty of trees in fruits, nuts, maple syrup, and various edible mushrooms and herbal treasures of the woodland. You can’t warm yourself with gold. You can’t bask in the shade of gold. You can’t make fence posts out of gold. A gold house would be mighty expensive. You can’t make a windbreak out of gold. You can’t make furniture, violins, guitars, wall paneling, picture frames, gun stocks, tomato stakes, flooring, barns, chicken coops, and hog houses out of gold. You can’t mulch a garden with gold leaf. Gold does not take in carbon dioxide and give off oxygen to preserve an environment we can live in. Gold does not provide habitat for millions of wild animals and zillions of insects necessary for a sustainable environment. And in fact, you can make methane out of wood much more efficiently than ethanol out of corn. All gold can do is go up and down in price and invariably it turns out to be a poor investment, as many panic buyers learn the hard way.

This resonated with me.  Of course when things go awry, as they did in 2008 and 2001 (in the USA), having a pile of cash feels good.  But money is not wealth (this article covers that, as well as some other key points about capitalism).  Money can come and go, but wealth, whether knowledge, relationships or wood lots, remains with you.  Some forms of wealth require more care and feeding than others, but they all have the attribute of providing value in the real world.

When you are in software development, knowledge is a common form of wealth.  I always tell teams I lead that almost every problem we’re facing is a new one, because if it wasn’t new, it most likely would have been automated or turned into a service or library that we could use.  So there are plenty of chances to gain new knowledge.

There are a few categories of software development knowledge.

  • Domain knowledge is understanding the real world problem domain.  So, if you’ve worked, as I have, in a real estate brokerage, you understand how the business works.  Who pays for what, how money and effort flow, who the main players are and what they are called.  All of these are valuable should you work in that domain again because you can come up to speed more quickly, and you understand how the real world maps to the software system.  This type of knowledge may change, but on the order of years or decades.  (I haven’t worked in real estate since 2014, but if I went back, there’d still be many of the same concepts.)
  • General technology is fundamental to software development.  I’d put abstractions like algorithms and data structures, specific technologies like distributed systems, database indices and HTTP, and best practices like automated testing and requirements gathering into this bag.  Having this type of knowledge will let you understand a typical system even if you haven’t seen the nuts and bolts of it.  Of course, the type of general technology that is most useful to you depends on your domain, to some extent.  The general technology of a chipset engineer is different than that of a UX designer.   Within the same domain, this knowledge is good for years.
  • Specific technology knowledge are the keywords that recruiters put on job postings, and what some consultants chase after.  Elm or Elixir, Rails or React Native, Kubernetes or kvm.  These technologies are very specific.  I’m of two minds about this knowledge.  On the one hand, if you pick the right tech, you can be in very high demand and get rates commensurate with that.  On the other hand, new specific technologies are constantly being born, and keeping up with all of them, let alone becoming an expert in them, requires large investments of time (perhaps the reason for the premium).  However, I have sympathy for folks looking for specific technology expertise.  Yes, any competent software developer can pick up any language in a few weeks, but the idiosyncracies, libraries and community practices take time.  Depending on your budget, you may find it cheaper to pay someone who has acquired that knowledge elsewhen.  This knowledge ages quickly.
  • Leadership knowledge is orthogonal to software knowledge, just like domain knowledge.  Since software is built by human teams, knowing how to lead such teams toward business goals, whether formally or informally, is a valuable skill. This can include specific techniques like agile development and ‘one on ones’ and more general areas of knowledge like how to connect or communicate people and how to navigate politics.  This knowledge has a long half life and can pay dividends throughout your career.

In addition to knowledge a software developer can accumulate other forms of wealth like books, videos, and relationships.  These can all serve as credentials for a new position or (occasionally) generate passive income.

As we head into 2018, think about how you can build longer term wealth in your career by picking the right kind of knowledge.

Business Jobs | moore |

Founding engineer or Founder/CTO?

I’ve seen a number of great posts about the contrast between VPs of Engineering and CTOs for startups.  Here, here and here. The short version, if you don’t want to read those posts, is that a CTO is technology oriented and a VPE is process and team oriented. At a young startup there is significant overlap. If you are a software startup, you need to be aware of this split.

How quickly these roles need to be delineated depends on the size and growth of your startup. If you have one or two technical folks, no need to do this (but you do need to determine who is in charge of technology). If you have ten engineers and are planning to add five more in the next six months, you should have already split these roles up. But today I wanted to write about the difference between being a CTO, the typical title for the founding technical member, and founding engineer. This is based on some discussions I’ve had or read, most notably with Jason Cole, who runs a consultancy focusing on technical leadership (all erroneous thoughts are of course mine).

When you are early in a startup (seed or pre-seed), you want a developer who can ship product. Nothing is more important than choosing the right market and getting a solution out to that market so that customers can give you feedback (with their dollars). CTOs of bigger companies actually don’t spend any time coding. They work on strategy, partnerships, hiring and other higher leverage activities. But that won’t work for a startup–you actually need someone to build product.

That person is really a founding engineer. Such a person is a special breed. Like an engineer on a larger team, the founding engineer needs to be able to execute and build product, quickly. They need to be aware of technical debt and when assuming it makes sense. They need to write code that works, is testable and performant. They need to evaluate whether to build or buy or download from Github. They’ll be performing devops tasks as well, such as monitoring the application, troubleshooting performance issues, and making sure deployments and rollbacks happen cleanly.

In addition to all of that, the founding engineer must communicate with non technical folks, both within the organization (including the CEO) and outside of the company. The founding engineer may or may not be doing tier 1 customer support, but will be doing tier 2 support. They also have to be willing and able to drive decisions, especially around technical issues. They need to be able to understand and give feedback on the business strategy at some level, as that will determine technical decisions. The founding engineer also needs to able and willing to take market feedback. This may be filtered through others, and any response should be discussed with the other founders, but market feedback and quick iteration is a strength of a startup. The founding engineer may be doing some product management as well, depending on the other team members’ strengths. They’ll be the de-facto UX designer. They also will be interacting with vendors and contractors. They may review budgets and will hire technical team members. It’s possible they’ll interact with investors if funding is sought.

For all the additional responsibilities, the founding engineer should be compensated, well, like a founder. With not much money and gobs of equity. (Not much money is obviously relative, and depends on market value.)

But, at some point the company will either grow or fail. If the company fails, there’s obviously no worries about future roles! But if the company succeeds and grows, the founding engineer can take four paths.

1. CTO

They can grow into the CTO role, focusing on technical strategy. Until there are significant numbers of engineers (10ish) the CTO may continue to code. They may be doing code reviews for some time thereafter. But at some point they’ll be focused on technical direction of the company, competitors and partners, and large scale technical trends that may affect the company’s business.

2. VPE

They can grow into the CTO role, and then transition to a VPE. The reason they have to go through the CTO role first is that it’s unlikely the company will need the process and team building skills of a VPE until a bit later. But at that point they can focus on delivery, team building and process. They’ll likely work with product managers and the CTO on strategic direction of the company.

3. Technical lead

They can choose to remain a technical lead. This will mean that someone is hired over them into the CTO and/or VPE roles. This will be tough on the ego. However, it’s important to realize what brings them joy in life. If they want to stay close to the code, a technical lead role is best. In this role, the entire team needs to be very aware of who is in charge, especially if this transition happens after the CTO or VPE path is attempted.

4. Leave

An early stage startup is a magical thing. Everything is on fire all the time, but the ability to wear many hats, have a direct impact on customer lives and ship quickly may be what they value. If so, as the startup gets bigger, some of these opportunities will disappear. Specialization happens.

There’s nothing wrong with title inflation, but CTO (and CEO, for that matter) titles at a startup aren’t equivalent to the same titles at a company of 100 let alone 500 or 100,000. If you are joining a startup as a technical founder, realize that whatever your title, you’re really the founding engineer, and that, when success occurs, you need to choose.

Jobs The Food Corridor | moore |