How to attract talent, hint, it’s your culture

BLUF: Build a culture that attracts the talent you want.


Provide a package to attract and keep the right talent.  The benefits package gets people in the door to make them excited about the opportunity, but it doesn’t always keep them there because priorities change.  This is a delicate balance.  I have seen pet insurance coverage, college tuition reimbursement, family leave, etc.  These are great but what if you don’t have a pet or don’t have time for college.  There are some benefits that are great for some but not for all.  Here is the biggest thing, if you say you have a benefit, then honor that benefit.  I have been a part of a company that touted that they sent developers to conferences and professional development courses, but they never approved any of the requests.  We had 100% turn over in less than 2 years for a team of 11 developers at that company.  Not because of that one issue, but you can imagine what the rest of the culture was like.


When interviewing candidates make sure you are giving them the correct information and not the smoke and mirrors to get them to accept.  If you have problems, then put them on the table.  I don’t like wasting my time on a company that told me one thing, but then I saw the truth and it was nothing like what they provided in the interview.  The interview is your first step to setting up your culture with a no BS information session.

The opposite is true.  If the candidate does not meet your culture needs and characteristics, then don’t hire them.  Your culture is what makes people happy and keeps people productive.  If you hire someone that injects their own culture and doesn’t fall in line with yours, then you will see the change.


Set your culture expectations from the start.  Have new hires know what the culture is with everyone operating the same and instituting that knowledge across the board.  You will not always be around, but you want your team to embody the culture that you need to accomplish your mission.   There is ownership in this.  It is not just your team.  It is the team.  The team members have as much ownership in the final product as you do.  You need to present that way to them and show that you are doing the same thing and providing the same day to day work ethic and culture characteristics that you expect out of them.


Build a culture that provides champions.  The strength and scalability of your team/company lies in the fact that you have culture champions.  These are the people that follow the culture rules and institute it without being authoritative.  People get on board without being persuaded or forced into the culture.  If your process was fully engaged, then by this time you attracted the talent with the right benefits package, you hired the candidate that had the right characteristics and skills, and the employees are part of the team and understand what it means to be a team player.


Culture is what makes people jump when you say jump.  Culture is what makes people listen to you and perform when the days happen that you need someone to work until 3 A.M. to get the deployment done for release.  Don’t take advantage of people’s time because you failed as a leader to plan and execute tasks well.

A couple books to check out is:

Radical Candor by Kim Scott.  Kim explains how honesty up front keeps people happy.

Team of Teams: New Rules of Engagement for a Complex World by Stanley McChrystal

Culture eats strategy for lunch – Peter Drucker

5 Delegation Techniques for Tech Leads

BLUF: Delegation is the best tool you have as a leader.

Delegation is the best tool in your kitbag.  But there are several things you have to do in order to make delegation successful.  In the military there is an absolute must that you have to be able to delegate in order to accomplish tasks.  The military has a clear hierarchical organization structure that allows you to manage your tasks and expect people to accomplish the mission and hold them accountable for their actions.

  1. You cannot multitask
    You are not different than everyone else.  It is impossible for you to multitask all of your duties to make you more efficient and successful as a leader.  You have to be willing to give others your work or tasks.  There are meetings, timesheets, and other non-technical things that need to be done that you cannot give to your team members, and frankly they didn’t sign on for those things.
  2. Micromanaging is for losers
    Micromanaging is like that annoying roommate that was always “accidentally” looking over your should at your computer to see what you were doing.  It makes people very uncomfortable.  If know that you do it, then give people the heads up.  I try to warn people when we have new tasks and deadlines that popup that I will be breathing down their neck to make sure they are on task and getting things done.
  3. Clear direction
    You have to give someone as much information as they would need to accomplish the task.  Don’t just tell them to go correct the UI on the login page.  I tend to give enough to get the job done, but I leave some wiggle room for my teammates creativity to shine through.  This is two fold.  They might teach you something and you might be able to teach them something at the end.
  4. Play to your team’s strengths
    Assign tasks to team members where they will perform extremely well or at least will be best suited for the task.  I give all of my CSS tasks to one guy on my team because he has made it clear that he enjoys writing and figuring out CSS fixes.
  5. Add in responsibility/accountability
    Accountability is the biggest part of all of this.  You have to be willing to tell people when they screwed up and how to fix it.  There is some balance and compromise here.  Don’t give people tasks that you know they are going to fail (i.e., lack of inexperience, knowledge, or confidence).  This final technique will also provide you insight into who is next up on your team for a lead role.

It takes some experience to get delegation right.  Apply it everywhere you can to see what works for yourself and doesn’t make you have OCD about control of your team’s tasks.

Contingency Planning

BLUF: There are times when you won’t have 100% of the answers to create a plan.  Creating a contingency plan is to account for the remaining percentage of the answers you couldn’t find.

Contingency plans are critical to any operations or projects.  It is the “if X, then Y“.  You have to be able to account for these possibilities.  Play devil’s advocate or punch holes in the plan.  In the military this is a common practice.  After we devise a plan a group will provide all of the counter plans that the enemy will execute.  This is all in the process of war-gaming.  In war-gaming you answer all of those IFTTT questions.

In software development you can also apply contingency planning.  Have you ever been creating an architecture design that requires other teams to provide services or architecture in order for your design to work?  I run in to it regularly.

  • What if we don’t have access to a SQL Server database?
  • Who controls federated logins?
  • When will customers transition?

What is your plan at certain decision points?  At some point you have to just build your solution knowing that you no longer have the ability to talk to a SQL Server instance and you have to use PostgreSQL.  You have to run with it.  Do you extend your deadline claiming you couldn’t get it done?

Always have a contingency plan for your project critical paths.  A contingency plan is not pivoting.  It is providing a solution to get over blockers or hurdles, and sometimes that solution is compromising with the product owner that there will be risks in the application if we cannot do things a planned way.  Eventually you need to accept the risks or mitigate some or all of them.  Only after that will you make the decision to not deliver on time because the risk is catastrophic to cause customer issues – exposing confidential data.

It doesn’t take long to run through some simple scenarios where you think something might go wrong.  Cover your bases in the situations that you don’t have accurate or unknown answers.  What database will you use if you don’t have access to a SQL Server instance at the current moment when you are designing and planning.

Entitled Developers

BLUF: You have to try.  You cannot not just play the part and get a job.

Last post I talked about interviewing candidates with a simple, or what I thought, data structures problem.  Since starting to be involved in the interviewing process I am noticing that there is becoming a staggering number of candidates who think that they can ask for high salaries and do minimal work to earn that salary.  I have only hired 7 candidates in the 80+ phone interviews that I have performed over the last 2.5 years.

Should a candidate who asks for $120k a year in salary know the difference between static and instance fields?  Yes!  I get that some people think white boarding a problem is a waste of time, but a simple white boarding problem has a lot of information about a person.  Can you communicate your code?  Can you implement with minimal instruction and ask questions to get to the end?  Can you even code at the foundation level?

The projected growth of software developer jobs, on average, is 17% in 10 years.  The industry is not being over saturated with qualified or over qualified candidates, so the need is rising but the candidate pool is being diluted with unqualified candidates for the needs of a most companies.  What’s my take away?  Sometimes you have to compromise on candidates that are not going to be the best fit because you have to deal with the delicate balance of needing the people to get the work done and the skills of a candidate.

My criteria for a candidate in all situations that I have interviewed is the need for a “full stack” developer.  My “full stack” definition is a candidate that has strong skills in one of the 3 main pillars.  These pillars are front-end, back-end, and database.  Those candidates need to possess enough understanding in the other 2 pillars to make them a compatible candidate.  I have never been looking for a subject matter expert in T-SQL or Linux, so my opinion might be skewed compared to a larger software development firm that is building a product backed by a team of 50 front-end, back-end, data, big data, UI, UX, QA, QC, testers, technical writers, scrum masters, and product owners.

I perform at least one task for all those positions in a week’s worth of work.  As I have always said though, this causes me to be dangerous enough to get me in trouble.  There is a balance in my work that keeps me up to date with what is going on in the industry, but i try to stay focused on one piece and that is web development.  I have pet projects in mobile development but my 40+ hours a week are dedicated to the former.  I have also mentioned that I always try to do an interview or two for a well known software or product company each year.


If you have been in the industry for a while and cannot write a NodeJS application, then you might be out of touch with what is going on.  I am not saying you need to be an expert, but do the “hello world” example to get an idea.  Out of the need for NodeJS we are now seeing WebAssembly coming on with full force.  I’ll counter this with that there is always a need for legacy coders that need to upkeep an old code base.

Extra  Yes, they exist.  I think this list points to all of the most common things that a faker will do, but they only need to exert one of these characteristics for you to realize that it is a problem.

I thought it was a simple interview question

The last two jobs that I have had I have experienced numerous interviews where I am phone screening and performing face to face interviews with candidates. These candidates are anything between a brand new graduate right on the job market to engineers with 20+ years of experience. I have read the articles and I have come to move away from the old way of thinking that says experience on the job relates to how good you are. It is just not true anymore with all of the libraries, frameworks, SDKs, devices, archi… . If you are still doing COBOL and only COBOL are you worth anything? Yes. Someone is looking for your skills.


If I ask a candidate “How do you store a list of integer values?” (don’t judge, this is the first question I ask) most of them respond with a common answer – List (note: I interview for C# and Java positions). Not that this is a wrong answer, but is it the best answer? I have only had one, count it one, candidate out of 100+ give me a very thorough answer that hit all the points you want any candidate to know if you are lucky. If I had my choice between arrays and lists to store integer values, then you have to start asking questions. Can you sacrifice direct control of the array and hand it off to a list? Do you have a finite number of integer values that need to be stored? Is there any reason for optimization? In most cases the right answer is List, but from a computer science foundation the answer is array. The next question is “What if I only wanted the unique numbers from the list of integers?”, survey says! The top answer – “Iterate through the list and check to see if it already exists.” Whomp! Whomp! I have only been in this industry for 8 years now, and I have 10+ years experienced engineers that don’t know the common definition for a set/hash table and how it works from a high level. I am not sure where the void is? Did you just look at blog sites on how to use syntactic sugar to create websites and then call yourself a web application developer on your resume? I am really lost on this. The weird part is that they know the answer for the map question more times than not. A map uses the concept of set as an internal data structure!


1 – LAZY

No need to explain. You just don’t care enough. In the Army we call that an oxygen thief.


Ok, so not everyone can keep up with everything. So you do what you can.


Self explanatory. You went to the Ruby on Rails bootcamp to learn how to be a web developer and now you want $120k+ in salary for spending $5k-$7k on an 8 week course. I can see the debate here if you are applying yourself to learn the intricacies of what is going on under the hood. I might have gone the bootcamp route myself if I had the same passion I do now that I didn’t back in college. I can self reflect and say that I had no idea what I was doing in most of my classes and somehow just made it work so that I graduated. The optimism is that I would have failed out of college more than likely had I pursued any other major.


Are curriculums lacking to teach data structures and algorithms properly? I can’t imagine that is true. My university had a course specifically for each of those subjects. These are must knows, right?


Where I currently reside there is an inflation in what software engineers should earn in salary for their job position and performance. If you don’t know the difference between an array, set and map, or you cannot answer basic questions around that concept, then you are a no to hiring. If you can somewhat answer them, but then you tell me you want $130k in salary, then you are an absolute hell no to hiring. Your experience of 20+ years doesn’t mean crap to me if you cannot answer collegiate level questions. If you are the next startup co-founder about to make millions, and you can’t answer these basic questions, then you are hacking it to the top.


If you have made it this far, then I can tell you that I am not the best software engineer out there. I failed miserably on a Palantir interview 4 years ago, which led me to be better about what I am doing and learn where my voids are. I failed on several technical interviews since then, and it help me refocus again about what my next steps are and it is also embarrassing so it reinvigorates my passion for this stuff. I say all this because I think people need to do technical interviews in order to find their weaknesses. If someone doesn’t want to hire you, then find out why and figure out a pathway that fills that void that was discovered. Furthermore, I would gladly hire a high school candidate that can prove he knows what he is doing and pay him the salary that comes with that knowledge. Yes, there will always be years of experience taken into account because that’s how business works. If a high school graduate can create an awesome web application and architect third party services to boot, then he is getting paid, but I don’t expect him to be a tech/team lead. There is still a business understanding that most young candidates don’t know the ins and outs about. This business understanding is where you move from being tech savvy to a business enabler. Can I rely on you to have the best interest of the company in mind when you say no to new features or delay the product timeline for unforeseen blockers.

Leaders are Teachers

BLUF: You won’t be able to scale without being able to teach in order to grow.

Becoming a great a leader means that you need to be able to teach.  Not teaching anyone about your experiences is a selfish approach to not spread your knowledge and understanding.    Jack Welch introduced many to the idea that leaders are teachers.

They have to see their roles as a combination of teacher, cheerleader, and liberator, not controller. – Jack Welch

Teaching team members fosters team communication and imparts a sense of “you know what you are doing” and gives team members a sense of confidence in a leader.  We have talked about how you are not going to know everything and you rely on others knowledge and experience to complete projects, but imparting your experiences is key as you are the more than likely the senior leader and have been involved in enough situations to apply past experience.

In my experiences in the military you see senior non-commissioned officers (NCO) that teach brand new lieutenants the ways of the force.  These NCOs have over a decade of experience in the military.  I had multiple NCOs during my time on active duty that pointed out my many flaws and showed the right way to execute.  You rely on your NCOs more than anyone else when you are a young lieutenant  My one caveat is that you cannot rely on every NCO to point you in the right direction.  Always apply common sense when choosing those that you want to be your inspiration in your career and life.

Everything that you teach your team are small dividends that you are investing back into your culture.  If you have teaching points and not demand points, then you allow your team to learn from the past and filter those experiences in order to provide a more productive environment in the company.  Give them the leeway to make their own mistakes and learn from those, so that they can pass on experiences to the new guy.

I keep going back to this book – Jack Welch: Winning.  This is one of my top books to read to learn how to be a understanding leadership and learn how the people you are leading will make you great and that you need to take care of them.


I do think there are issues in the OSS community for those new developers that are trying to get involved with projects.  If you are the one making snarky comments about a pull request or make the commit so complicated that no one wants to put aside a week of free time to fix a label misspelling, then you need to take an inner look at what you are trying to accomplish and if it is truly open source.  Yes OSS projects are “free” libraries to help out others, but open source also means that others have the possibility to help if you give them the platform and culture that allows for that help to emerge.  It takes more than just adding a tag that says “newbie” or “low hanging fruit” to get people to help out.  If they have questions or look lost, then don’t chastise them, guide them.

Servant Leader

BLUF: Provide your team members with servitude so that they get to where they want to be mentally, physically, and emotionally.

I was listening to Tim Ferriss’s podcast featuring Ray Dalio this week.  Ray laid out a great way to think about being a leader; be a servant leader.

What does it mean to be a servant leader?  You establish a position in which you put the needs of everyone else in front of your own.  Lifting your team members up and allowing them to efficiently and productively perform their work is going to keep you far ahead, then pushing them down below you all the time.  This is not a cream rises to the top situation.  If you are never providing your team members with a culture for them to grow and give them what they need, then you are ultimately telling them that they don’t matter.  This in turn reduces productivity and esprit de corps.

Your job as a leader is to provide many of things to your team members with one being to provide mentorship.  Your guidance and feedback to a team member is crucial in building a strong culture.  You should always want to see your team members succeed even if it is moving on to a new opportunity outside of your team.

This mindset goes with my previous musings about being a participant in your leadership and not a dictator who doles out tasks and just oversees.  I cannot stress enough how it looks to team members when you hand out all the work and then go have a nice 2 hour lunch break and then come back and sit on the phone for a while talking to a “customer”.  Finally, they sit back and take all the credit for the great work the team has accomplished.

I am pushing all of my chips in on servant leadership and participative decision-making.  Here are two books to help out with this subject.

  1. Leaders Eat Last: Why Some Teams Pull Together and Others Don’t
  2. Start with Why: How Great Leaders Inspire Everyone to Take Action

Accept Failure and Learn

BLUF: Failure is not a purposeful mistake, but you need to be able to learn from those failures.

No matter how much you plan it will never be perfect and sometimes failure is an outcome.  I have failed.  Too many times than I can count or even care to admit probably.  I probably would not be where I am today without those failures.  Every failure I had I came back stronger from them.

As a leader you have to know that failure is always a possibility, but how you respond to those failures is what makes you a leader.  If you become the one who turtles into your shell and cannot rally the troops, then you’ll lose the team right there.  You can be pissed off, sad or disgruntled about what happened, but your attitude cannot resonate that same tone in front of the team.

If you do fail at a task or project.  You have to be able to look back on it and make things better.  Answer three questions.  What was suppose to happen?  What did happen?  How can it be better?  You also have to be able, at a minimum, to provide 3 positive things that happened and 3 negative things that happened to help lead into your answers.  I have been a part of or used this procedure for my entire 16 years of experience in the military.  The outcome from this process is to learn from our mistakes and update the process, plan or procedures next time that allows for a better outcome.

In the military there are tactics, techniques and procedures (TTPs) that are built from learning from past events.  “Doing the same thing over and over expecting different results.”  You cannot apply the same procedures to the same problem every time if failed already.  It WILL fail again.

There are times at which you have to lean on team members to help get you through the hard problems.  Without being able to lean on others to complete the tasks, then you can definitely accept failure.  The best part about utilizing your team and failing is that you did it together.  The worst part about failing with a team is either you do it alone and you are the sole loser because the team knows they didn’t play a part or you blame the team for actions that you had control over.  If you are delegating appropriately and not asking for the moon, then you have given it your best shot at completing everything and you have to accept that and learn.

Tasking – Edge of Success

BLUF: Give team members tasks that put them on the edge of success or failure.

Providing the right level of task to the right person is always a tough decision because there has to be thought that goes into it; time, priorities, experience, and knowledge.  Not only these definitive decision points, but also do you have the right team makeup to provide a solid foundation to solve problems.  You have to build a team that makes sense.  If you are using C#, then don’t hire the technical expert that has been building Java Applets his entire career.  Unless you have the project runway for him to learn C# first and then get going on the project, they will fail.  Either because you are pushing them to fast and then don’t have the knowledge and experience to provide productive coding or because they get fed up and leave with the environment that they are working in.

When assigning tasks out take into consideration which ones will put team members on the edge of success, but a critical step left or right could put them in a failed state.  Having team members that you are excelling to succeed, then you are doing no favors for them or yourself.  They will not have challenging work and you will ultimately have a product that falls flat.  Engage each member equivalent to their technical needs and wants as well as their experience.  Once again you have to have the right team make up to make this achievable, but that includes still be able to solve problems that occur that no one knows how to solve.  You just need the team members that are willing to venture into new lands.

It becomes a team balance to provide the best culture and environment for your team to both have technically sound and creative work that they are proud of.  You have to know when to back off on the pressure and let your team have a break.  Software engineers have a known ebb and flow in projects.  You are going to have days or weeks where there needs to be full pressure to get something done or fixed, but there has to be a down time for them after the fact.  If you don’t provide that type of environment, then you run the risk of too much stress and fatigue for too long and they start to hate the job and career.

I treat my team like they are my kids.  You have to be able to teach them and give them life experiences without dictating how to perform every task step by step.  If you start to fall into the realm of micromanaging or dictating, then either you are the wrong leader or your hired the wrong people for the team.  Take a look at yourself first and adjust to see if people will break out of their shell to provide productivity and creativity.

“Watch the ice rate meter.”

BLUF: Utilize everyone and if you aren’t, then let them go so they can flourish somewhere else.

It used to be in aviation that even though there were two pilots needed to fly only one was actually flying.  You would get a very experienced pilot that has over 5,000 hours and turns to the inexperienced pilot and says “Just sit there and watch the ice rate meter.”  The ice rate meter tells you when there is ice forming so that you can turn on your deicing system.  Obviously this doesn’t make sense to get someone to watch it during the summer because you don’t need to.  This means you are only relying on someone’s ability during a partial time during the year.

As a team lead you have to be willing to give people tasks.  It is your job to make sure you give the right people the right task to succeed.  Sometimes people will fail, but if they failed horribly, then there are many factors that you need to look at in order to determine who’s fault it actually was.  If you hire a software developer straight out of college don’t expect them to know how to do everything and don’t expect them to have a quick solution.  It will take them longer to solve a problem and they might come into a situation where they don’t know anything and they want to learn but the timeline will take even longer.  Be able to accept that when you give them a task.

A couple months ago I had a team member that was fresh out of college and did not have a lot of experience with web development.  When I hired her I accepted all of this because she graduated #1 her class.  What the problem was is that she felt overwhelmed and/or unguided as a junior developer.  I was giving her task that took her a while to get done, but I never complained about her timeline or the final product.  They were all learning points, but I was bad at helping her progress and she was working on large problems that needed just a little bit more experience.

In this situation I can’t just tell team members to work on things that don’t matter.  Most people that look at software development as a career are not looking to be subject matter experts in a specific language with a specific design pattern (…or maybe it is just me).  And what I mean is you don’t want your whole career to be creating Factory patterns in Java for the rest of your life.  You know what else?  Employers don’t want that either.  You have to be dynamic and be able to market yourself in multiple disciplines so that companies feel like they are getting a valuable asset.

If a team member is not performing like you expect or want to and it is not because they don’t want to try, then you need to look at yourself as a leader and ask if it is your fault.  If you are attempting to give them tasks, then you need to have the conversation to see if they are happy with the tasks/work.  If not, then find the solution to get them to a new team or help them move on to another opportunity.  This becomes an investment they will talk good about you to others because of their experience.  Help them with their career that is your job as a leader.