What motivates “techies” as individuals and teams?

As a “techie” and a manager of techies, this is a question deserving regular review.  This topic can be a challenge as we may not fully understand this about ourselves or we may rely on conditioning to express what’s perceived to be right answer.  Of course we are all unique and not motivated by the same factors –knowing ourselves and each team member as an individual is important.  Even individual needs and interests will change over time!

What should we do?  Setting aside time to think about this is important for one’s own personal growth and also as a manager to better understand your team.   What gets us excited?  Which are show stoppers?  Which is irrelevant?  Below is a list of motivators I have seen over the years along with questions worth asking yourself. 

1. The Work & Technology – This should be a primary motivator for everyone.  If you are coming to work simply as a job the results will clearly reflect – and I would suggest one re-evaluate!  This need not imply you are working on the next “big thing” but simply does your work engage you mentally.
2. Competition – Are you motivated by a desire to be part of the “best” product in a category?  Are you willing to go above and beyond simply for this satisfaction?  How does knowing that your product is an industry leader (or laggard) impact you? 
3. The People & Team – Do you enjoy working with the members of your team?  Do you respect them, do they show respect for you?  Do you feel challenged by your team?  One way to consider this– would you be willing to take a pay cut or work on less exciting tasks to stay on a team?
4. HW, Tools & Environment – How much does top notch HW and software technologies, office environment, and office surroundings (i.e. like a campus) impact you?  If given the choice, would you choose a new advanced HW and/or tools over say a raise or different team?  Or would you change companies to work in a more collaborative environment?
5. Culture – I have seen this turn quickly to a de-motivator!  How much are the following important to you:  empowerment, decision making process, trust, respect, and realistic schedules?   Does your business actually value family balance (not just printed on a plaque on the wall)?  How about encouraging charitably giving and volunteer service?
6. Recognition – Some folks are motivated by individual and/or team recognition, much like the record books for sports teams.   They thrive on visible recognition for the work they have completed (and this is not bad).  How does your company recognize folks who have gone above & beyond?  How does your company recognize and value longevity?
7. Compensation – While folks need to earn a living, compensation may not be a primary motivator for everyone.  An interesting way to look at this – would an additional 10% (or decrease in 10%) cause you to change jobs?  No doubt there is a tipping point if your salary is out of line, but I’ve seen through experience that when it gets down to salary it may be masking other factors from above.

I would expect most would say these are all part of the job satisfaction equation, but also appreciate that each carries a different weight. 

• As employees it is important to consider what motivates you and then communicate to your manager. 
• As a manager we must get to know our team at an individual level and maintain this awareness over time. 

A stable, committed and tenured team is absolutely critical to success.  These are teams that will pull through tough times together, pool their talent to innovate in all areas, and leverage their tenured knowledge and experience to work efficiently.  Ultimately these teams will become high performing and stand out – so its important you do your part to understand your needs!

How would you rank the above attributes?  Are there any where you will not compromise?  Are there elements which do not matter to you?  Any elements you would add to the list?

 

Intangibles of great software engineers

What is it that makes the best software engineers?  I expect this question yields strong opinions and varying answers.   Over the years I have been a part of various processes and tools all created to help make better engineers, but I often wonder how effective these are.   At times it feels like the old saying “you can lead a horse to water, but you can’t make them drink.”  Ultimately I see something more intangible which exists in the best engineers.  The processes & tools then help these engineers work better together, and in some cases raise the bar of others.

Measurement of software engineers can include such metrics as # defects, code maintainability, schedule, cost, performance and usability.  While many books, processes, and classes have emerged over the years to improve each, underlying these are a set of behaviors which are critical for those processes to yield results.  My experience has shown the following intangibles exist in the best software engineers:

Desire to specifically understand what code is actually doing.  I am amazed how often engineers will work within a code base with limited knowledge of what the code “around them” is actually doing.   They rely on what a couple of tests demonstrate or others have told them.   These engineers may be using 3rd party libraries or extending existing code.  The engineer who has the natural interest to understand how it actually works will yield substantially better results.  For example, when one is enhancing existing code (i.e. adding new features) do they “wander” around the code to get a sense of the impact/risk and how the structures and algorithms are actually used?   This wandering may include stepping through a debugger extensive code and building specific test harnesses to observe code behavior.  This knowledge is what helps ensure new code does what is expected with minimized side-effects in the system.

Naturally ensure code is maintainable – even fixing others code.  This includes consistency in formatting, clarity in naming, thorough functional/algorithm comments, consistency with code organization and architecture standards, and refactoring when possible.  This is not something one performs after the fact, so it must be part of how the code is originally written.  Even with the IDE code formatters in use today, I believe how an engineer handles this reflects their approach to writing code.  Software is precise and requires thinkers who are precise and well organized – and expect this from others.  This focus on maintainability is what ensures new and updated code remain maintainable for years to come.

Can decompose a complex problem into simple sub-problems.  Does one naturally notice common code patterns and extract to a reusable block or when doing code reviews do you see evidence of regular copy/paste?  While this can (and is) taught, it is generally something one “gets” and applies or they do not.   Part of the challenge here is being able to identify “almost similar” bits of code and realize they are performing a similar function with some variable modifier.  How the problem is viewed and solved originally will determine how easily it can be enhanced and maintained in the future.

Seek to learn and enhance their programming skills.  How many software engineers actually take some time – say even 1 hour per week – to read and follow any number of very informative web sites.   Folks may be aware of these sites and might even visit them once in a rare while – but which engineers on your team actually take time each week to read and digest something new.   This can be everything from what’s new with relevant technologies to best practices for various programming methodologies.  The key here is someone who desires to advance their abilities on their own.

Understand their own limitations and collaborate around solutions.  Here I have seen examples on both ends of the spectrum – engineers who are like deer in headlights and cannot move without getting input before each step and others who are unable to sense when they have exhausted their own knowledge/experience and need help.   I can see where this attribute can also be heavily influenced by the environment including culture, processes, and past experiences.

There is no mention of languages, operating systems, colleges attended, years of experience, technologies used, size of products and/or teams…   I believe it is more about someone with that natural curiosity to understand how a system works, has the innate attention to detail to build maintainable code the first time, and aptitude to understand large and often complex problems.

Ultimately the question remains – how much of this is natural and how much can be taught effectively?