Appreciation

Appreciation could possibly be the single biggest reason we enjoy work, there’s nothing more precious than feeling that we truly matter. Overcoming challenges, working hard, solving problems, and receiving praise for our efforts; not just having the knowledge that we are contributing and making a difference but receiving a token of gratitude, in the form of a gift or words. This form of appreciation is very powerful to motivate employees and to ensure that they are happy. Actually, appreciation goes beyond recognition and can (and should) be used to show that you value the *person*, not necessarily what they have recently accomplished at work. Something as simple as talking and listening to co-workers can show appreciation. Appreciation is an undervalued thing in our workplaces.

First, appreciation given is *much* more effective when it is individualized and specific. A $20 gift card given to all employees is not an effective form of appreciation. Neither is “great job team”. It is much better to say “your keen eye for detail and finding those last minute bugs really helped the team deliver a quality product”. Second, express appreciation in different forms. Learn to be a good listener. It’s useful in and outside of the workplace as it shows a genuine expression of interest in that person, which is a form of appreciation. Another form of appreciation is to ask someone if they would like your help. Staying late to help a co-worker finish a project can be viewed as hugely appreciative. If you are a manager, another form of appreciation is in gifts, whether it is a physical gift, monetary gift, an experience such as tickets to a game, or even a paid day off. There are many ways to show appreciation. Finally, while appreciation starts with management, it should become part of the company culture that not only co-workers give appreciation to each other but also employees to their managers. Appreciation should be ingrained in the company culture.

It is important to note that everyone appreciates differently. Do *not* assume that people will (or should) feel and act the way you do with appreciation. Like the 5 Love Languages a la Dr Gary Chapman, appreciation of employees and co-workers is most effective if you speak their “language”. Not only do people like to receive appreciation differently (verbal, gifts, acts, time), but each form can have nuances. Some people like to receive verbal praise announced in a group, while others may find that horribly embarrassing and much prefer to receive verbal praise in a one-on-one setting. Everyone is different. You may prefer a day off work, while I prefer my manager to show a genuine interest in me as a person. While showing appreciation, especially individual appreciation, is likely never bad, it can be much more effective if it is given in the correct “language”.

Most people leave companies not because of money or location or simply a change, but because of low job satisfaction and because they don’t feel valued. The single highest driver of engagement is whether or not workers feel their manager is generally interested in their well being. In sum, happy, engaged, enthusiastic employees are employees who are appreciated.

Three Don’ts

Do not interrupt unnecessarily. Do not use foul language. Do not arrive to meetings late.

When you have a question, see if you can figure it out yourself. Generally, you learn more when you can do it yourself. Plus, the less interruptions that occur around the office, the more productive everyone is. Of course, if it will take you a lot longer to find the answer, then ask someone. While you can learn by doing it yourself, you can also learn from others, and we are a team after all. If the whole team is working faster and more efficiently, everyone benefits. It’s a balance. When you do go to ask a question, try to send the question in an email rather than walking over to someone’s desk. By wording it in an email, you force yourself to think through the problem more meticulously. Also, email provides a way of archiving the question plus it doesn’t interrupt the other person.

Foul language is unpleasant and unprofessional. I almost don’t even feel it needs discussion but I’ve also seen it used excessively around offices, so let’s discuss it briefly. I’m not talking about the occasional word used jokingly during lunch break, I’m concerned about language used as part of work, for example in meetings. Bad language encourages people to be emotional instead of thoughtful. High priority issues and emergencies can be conveyed without using bad words. If it becomes commonplace, it creates a negative culture. It’s the same reasons you keep the bathrooms clean and the kitchen tidy. It’s part of the culture and it’s a reflection on the people and company itself. Finally, while you may not care, certain words may offend others. Maintain a positive environment and refrain from using crude language.

Be respectful to others and arrive to meetings on time. When you are late to a meeting, you make everyone else wait on you. The more people at the meeting, the more people’s time you are wasting. I’ve actually seen this as part of the culture and people purposefully show up late because they know the meeting will not start on time. It’s very inefficient for the company and frustrating to employees. It also breeds an attitude of certain people’s time being more valuable than others. In sum, do not be disrespectful to other people’s time, so arrive to meetings on time.

James Damore’s Memo

James Damore’s memo about the gender gap, gender diversity, and biological differences just came out, so I thought now to be a good time to add in my thoughts about women in tech.

Let’s start with some statistics. Women made up 36% of the workforce in tech in 1991. Today, tech companies report 30% are female but only about 13-26% hold tech jobs (the statistics seem to range widely here). The quit rate is 41% for women, 17% for men – that’s more than twice as much. However, women as a percentage in tech companies *is* increasing. Isn’t it unfair to blame tech companies for the gender gap? Shouldn’t their gender makeup be a reflection of the degrees earned in college? Yes, and the statistics here seem to line up: today, of those graduating with a BS in computer science in the United States, 82% are male and only 18% are female. Let’s take a step back even further. From day one, when computers started appearing in the home, things did not look good for women. A 1985 report on the everyday usage of personal computers within the home found that men were both far more likely to use a computer and to use it for more hours per week than women. In 1985, the male/female ratio in tech was 63%/37% and the male/female ratio in tech degrees earned was about the same. Some final statistics, Intel has pledged $300 million toward building a more diverse workforce, including tying managers’ compensation to their progress in that area. Apple is donating $50 million to the Thurgood Marshall College Fund and the National Center for Women and Information Technology.

How do I interpret all of these statistics? What is my gut reaction? They’re hogwash and should be thrown away. Statistics aim to group people – something I despise – and this is harmful, dangerous, and counterproductive.

James Damore has been called a sexist claiming that he states men are genetically more suited for tech jobs. Is that fair?, he is simply looking at the data and trying to reach a conclusion. Frankly, I don’t think a genetic component is unreasonable given the large gender gap that exists, just as I don’t think it is racist to say a genetic component makes blacks more athletic. However, stating these things is harmful, counterproductive, and dangerous to society, and frankly I don’t care if they are true or not. The individual’s genetic makeup is *way* more important than the average genetic makeup of some group to which they belong. As such, what’s the point of James Damore’s memo? While it *may* be true, it serves to discourage women, even very qualified women – yes genetically qualified women – from entering the field, and in my opinion this is very sad and hurtful to our society. We still identify in groups. A woman who hears that men have a genetic advantage in tech may choose a different degree, even though she as an *individual* may have a huge genetic advantage in tech. Personally, I hate anything that labels us because it encourages more division and our individual makeup and background is 100 times more important than some group we are a part of. As such, while I like that James Damore is trying to understand the gender gap, and he clearly understands the ideas behind individuals and statistics behind grouping, he should have realized that any sort of grouping is harmful. Since he published the memo as an employee of a company, Google had no choice but to fire him, which was the correct decision.

My reaction and basic response to all the hubbub erupting around Damore’s memo, is to cool off and take a very basic approach: we should not compare women with men in tech (in fact we should stop comparing groups altogether because it only serves to divide and create prejudices), we should compare individuals and we should encourage all individuals to enter STEM fields as it benefits all of us.

Follow Your Passion, Quit Your Job, The Four Hour Work Week

There is a bit of a cultural movement that life should be all laughter, happiness, and excitement, including your job. Your job should not feel like work because it will be your passion. If you aren’t passionate and happy at work, you should find a new job. While there is a modicum of truth to these statements, the overall idea is quite dangerous to you and your health and happiness.

First off, work is healthy. It keeps you sane. It gives you purpose. Second, work, no matter how wonderful of a job, will have bad moments. The main problem stems from the new (often associated with millennials) attitude towards work and money. This new attitude that money will pour in when you follow your passion: travel the world, write about it in a blog and make millions; talk about the latest video games, create a YouTube video and make millions. A bit of research and you will see just how many people are trying to make money blogging and vlogging and very quickly realize it is not realistic. It fundamentally comes down to attitude and expectations. If you continually change jobs, chasing your passion, searching for this perfect four-hour work week, you will roam aimlessly, unhappily looking for the unattainable. Should you enjoy your job and should it make you happy? Absolutely. If you dread Monday morning and feel physically and emotionally ill, that’s a different story. I’m talking about turning down jobs and filtering out only jobs that match some ideal scenario like some make-believe job where you can work from the beach, four hours per week, sipping a mai tai. Work is not a vacation and if you treat it like it is, you will be unhappy.

The idea that you should turn your passion into your job is, to be succinct, stupid. Passions change with time. Also, people generally become passionate about what they are good at, rather than some innate thing. People become passionate when they see their work helping others, when they become an expert in something, and receive praise for what they do. Passion evolves and changes. With the right attitude, your job can be very rewarding, it will help others, will give you a sense of purpose, and quite likely, if you weren’t passionate about it at first, a passion for your work will grow with time.

Overall, work is healthy, don’t treat it like something to be avoided. Passions change and grow, they’re not something to be searched for and formed into a job. Don’t be fooled into thinking a four hour work week is a goal to be attained, but rather that work is, ultimately, an enjoyable experience, keeps you sane, and that you’ll want to work much more than four hours per week.

On Advocacy, Criticism, and Acceptance

In this blog, I talk a lot about process, the best ways to do things, efficiency, industry norms that I think are overrated, and so on. However, beneath all this advocacy and criticism lies something very important: acceptance.

No organization will have every aspect of the process to your liking. Even if you’re the manager who defines processes, there are often company-wide processes that you must adhere to. Every company is riddled with inefficiencies. While it’s nice to fix these inefficiencies, do not become too caught up with it. Have you seen an engineer or manager who constantly brings up the tabs vs spaces issue, yoda conditions, one line if statements, or spacing between characters? Do yourself a favor and avoid such arguments. These are incredibly minor inconsistencies. Your company has more important inefficiencies and even some of these you need to learn to live with. Simply put, do not became wrapped up in making a 100% efficient company exactly to your liking. It won’t happen and it will drive you and your co-workers batty and you’ll eventually develop a poor reputation as a pedant.

Scrum inventor J Sutherland said that most companies run at around 15% efficiency and if you can bump that to 50% efficiency you are doing a great job! These numbers are generally shocking to most who first read it but I think they’re correct, though maybe a bit higher today. From these numbers, don’t ever think to get to 90% efficiency. Your emotions will roil as you combat the bureaucracy and people in your organization, to your own detriment. Do not be complacent and accept everything. Mention what could be better but then accept what is. Do not moan and groan every time you are asked to do something you do not want to do. Mention the worst inefficiencies to your boss, do not be surprised when nothing happens, and live with it.

A key component to all of this is setting an example to your employees and dealing with bad attitudes. Any bad attitude shown by employees who dislike certain processes needs to be addressed. Have you ever encountered such stubborn employees who say things like “If I’m forced to fill out these useless timesheets, I’ll quit”.  Address this quickly and help those employees understand the value of acceptance.

Just remember that no company will have processes that perfectly match your liking or your team’s liking. Work on those processes that you truly believe will improve the company, not just pet peeves in coding style. Encourage the corporation to allow groups to have autonomy (one of the three metrics to happiness) which will allow each group to define processes that appeal and work for them. And finally, accept those processes that you cannot change.

Don’t Miss Deadlines

Build a reputation of delivering on time. Whether it’s an important part of the culture at your company or not, you should deliver on time. This is almost a personal thing for me – if you commit to something by a certain time, finish it by that time. I’m not going to talk about why delivering on time is important (hopefully, that is obvious), but I will say this – think of it as disrespectful to others who are dependent on you.

The first part of delivering on time is to plan and commit to deliver a reasonable amount of work. You should be able to perform estimations without having to break down a task into Fibonacci hour increments, without defining story points, and without voting and obtaining consensus on these time estimates. My team and I have bypassed the meetings used for time-estimation and tracking steps for years, on several projects (including new projects that we knew little about) and delivered on time, every time. I’ve seen daily stand ups and burndown charts in action and with it I’ve seen teams and projects strictly follow Scrum processes and *still* fail to deliver, repeatedly! If you can’t divine that you’re behind schedule unless you have a burndown chart, the problem is that you don’t understand the project and people well enough. Get to know your team, the project, and the features to be delivered, and you will know with better accuracy your team’s status compared to any burndown chart.

As a team, tackle the most important features first giving priority to those tasks that require cross-team interaction and leave features that are fully in your domain toward the end. You do not want to fail to deliver something because some other team was late. I’ve seen many burndown charts that are on track all the way until the end. Engineers have a weird tendency to please, so they will pick off easy tasks so they can claim progress at every daily standup, but by the end of the sprint, the big task is left unfinished. Also, engineers have a weird tendency to complete the task that’s fully in their domain, that they have full control over, before interacting with the other teams. Do exactly the opposite – attack the big tasks with a lot of cross-team interaction first.

The inevitable happens, the deadline approaches, and you aren’t quite on schedule. What do you do? First, hopefully you’ve instilled a culture of delivering on time within your team. This culture will create diligence and hard work ethics throughout the sprint, rather than just at the end – thus these events should be rare. Second, most engineering work schedules are flexible. Deliver on time by working late and weekends if necessary. Because of the flexible work schedule, let your team know that if you work late for several days, after delivering the product, take Thursday and Friday off and enjoy a 4-day weekend. Don’t demand your employees to work more than 40 hours per week, but do require some flexibility in work hours to ensure on time delivery.

In sum, make delivering on time a priority. Understand the project and what is needed to succeed. This is superior to relying on Scrum-like processes to estimate time and track progress (while I deride Scrum specifics, I am an ardent proponent of Scrum principles). People love the comfort that a rigid process provides (it makes it feel like the team knows what they’re doing) and there is a stigma in the industry for not following Scrum-like processes of time estimation, time tracking, daily progress reports and status updates – do these if they help, but they are not a panacea to quality and delivery. Remember, the important thing is the end result and delivering quality to the customer. Make on-time delivery ingrained as part of your team’s culture. Don’t let down those who are dependent on you. Make delivery a priority and in the end, perhaps not only will you deliver on time, but ahead of time.

Pros/Cons of Scrum

The Scrum framework revolutionized the way large projects were managed and made them incredibly more efficient. However, it is important not to blindly adhere to Scrum principles – even Jeff Sutherland would agree with this comment. Very briefly, I want to discuss where Scrum comes from, its core principles, why it’s excellent, and when not to follow it.

Scrum came out of improving software development for large companies (think Toyota or the US Government) implementing multi-year contracts with hard requirements. Scrum is designed to fix the ubiquitous problem of projects running late and over budget. Or even worse, the problem of canceling projects because they are so far behind schedule and over budget that the funds run out. While there are a lot of great concepts in Scrum, since it derived from very large, multi-year projects, be careful not to apply all concepts to your project.

The main principles behind Scrum come from the Agile Manifesto: Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan. A fundamental part of “Individuals” is that they “take responsibility” in achieving their goal, something I touched on in the Engineers Are Not Fungible blog. While Scrum itself suggests implementing processes, even Jeff Sutherland knows “in a theoretically perfect world, there would be no process” and “any process that people use is wasteful, including Scrum”. I love all these ideas. Light process, concentration on individuals, working software, agility. They are fantastic and I’ve seen them work!

What I don’t like about Scrum are the specific methodologies that it suggests. The weekly sprint, which includes planning, effort estimation (via story points instead of hours), velocity calculations, daily stand ups, sprint demos, and post-mortems. Even if you only do it once per month (though Scrum methodology advocates the shorter the better), it is too much overhead and process in today’s fast-changing world. The backlog should already be prioritized, so no planning is necessary, simply grab the next priority item after you finish a task. Remove completely effort estimation and velocity, however, instill in your engineers to speak up once a task becomes more complicated than at first glance. Instill in your engineers to speak up if roadblocks are encountered. Instill in your engineers to speak up on interesting issues that arise. Basically, communication within the team should be event driven, not poll based. You should not wait until the next daily stand up to hear about an issue, the issue should be communicated immediately. As such, remove the daily standup. Replace sprint demos with emails containing screen shots or videos. Demos are momentary and live, whereas emails and videos can be archived and referenced in the future. And finally, remove post-mortems. Again, instill in your engineers to speak up when they see something that can be improved. Meetings are the #1 killer of productivity so minimize them. Despite their popularity, face to face meetings are highly overrated. It’s becoming clear (through data) that employees not only like to work from home but they are often more productive working from home. To get back to topic, Scrum has a lot of processes that in 2017 with today’s knowledgeable employees, specifically employees knowledgeable with Scrum-like process, many of the mandated processes are just no longer necessary.

In sum, the overarching and guiding principles of Scrum are spot on. Every project should adhere to light process, emphasis on individuals, collaboration, responsiveness to change, and ultimately, the end result. Avoid the Scrum-specific methodologies that are rooted in making large, behemoth corporations and governments better, rooted in forcing communication via scheduled meetings, and rooted in poll-based feedback from engineers. Most likely your company and project – today in 2017 – do not operate like these behemoth corporations did twenty years ago and would not benefit from these methodologies. Don’t just blindly adhere to the processes of Scrum but understand the principles behind Scrum and apply them to your project.

Engineers Are Not Fungible

As part of many SDLC framework planning phases, tasks are estimated and then engineers are assigned those tasks depending on how much work load they have. Those engineers with free time will pick up extra tasks until their hours for the sprint are filled. If implemented poorly, these frameworks commoditize engineers, remove accountability and responsibility, and indirectly reduce happiness, all of which are detrimental to a project. Let me explain.

First, not all engineers have the same proficiency. But let’s put that aside. Now, any reasonably-sized code base means that engineers will have a deep knowledge of some parts of the code but only vague knowledge of other parts. The expert in an area will be able to implement a feature 2x, 3x, maybe even 5x times faster than an engineer not familiar with that part of the code. Anytime the engineer is unknown, the time estimate of a task becomes much less precise. If you counter this by saying you don’t have experts in your organization and that everyone owns the code equally, you’re wrong. Even if this is your policy, there is always a natural drift for people to specialize and revisit code areas in which they are familiar. Most importantly, when an organization is structured to have fungible engineers without areas of expertise, you lose accountability and responsibility, and indirectly you lose happiness.

Engineers are efficient creatures and they hate wasting time. This is great for the company. Engineers also like to please and receive praise for their work, who doesn’t?! However, some side effects arise from these two things that all managers, team leads, and scrum masters should be aware of: hacky code. Hacky code is perfect for one-time demos, proof of concepts, or for changes to a code base that is known to end of life. However, for a code base that intends to live on for years, hacky code will slow down development in the long run and create defects, often very difficult-to-diagnose defects. Engineers will produce hacky code under certain conditions: they are lazy (beware this engineer) or if it is much faster to produce compared to a clean fix and either management is pushing hard for a quick fix or they have no responsibility for that part of the code. In this case, the engineer will make the hacky fix, receive praise for solving the problem quickly, and move on. This tendency towards hacky code is doubly true when the engineer is not familiar with a certain part of the code and is not responsible for it. Why would an engineer create a bigger change, which carries higher risk (greater chance for bugs), spend more time doing it, and more time testing it, when he can do it quickly? He wouldn’t unless he was responsible and accountable for that feature and knew that he would be making changes to that code for months or years to come. There is a common, though diminishing, belief that code should not be owned, and while fundamentally true (everyone should be able to contribute to any code), this idea has been taken too far such that no one is responsible for anything; only teams claim responsibility. An examination of the source code shows that a no-ownership policy results in poor code. In sum, fungibility creates poor code.

Finally, an indirect, but perhaps the most important aspect, is happiness. Scrum inventor Jeff Sutherland outlines the three points of happiness as autonomy, mastery, and purpose. While you can try to emphasize that what matters is how the team performs (and in fact it is more important), people crave individual praise and purpose. By owning, i.e. being accountable for, a component of the project, one can be proud that their component was delivered on time and functions flawlessly. They are happy to say “I, and I alone, was responsible for creating that feature”. We all know that how the team performs is more important. However, happiness is derived from owning something (autonomy), being the go-to person for that something (mastery), and seeing that something contribute to the overall product (purpose). In sum, do not disregard the individual. While hearing that the company did well or the team did well is important, it is equally important to hear that *you* did well.

I have touched on a lot of topics, namely the importance of accountability, preventing hacky code, and happiness, and how they relate to engineering fungibility. The worst side effect of fungible engineers is the loss of accountability, which in turn leads to hacky code, and believe it or not, less happiness. Teams are immensely important but do not diminish the individual in praise of team. Do not commoditize work. Do not make engineers fungible.

Unreproducible Defects

I’m writing this second blog post as an example of a post not directly related to process. While many of these posts will be process related, these posts are simply thoughts and ideas that I’ve developed over time.

One common occurrence in software development is the case of unreproducible defects. Especially when reported by a customer, how do you go about resolving this bug ticket? First, obviously, you *do* try to reproduce the issue. The engineer and tester most familiar with the feature should be the ones working on it. However, use time boxing to prevent spending too much time attempting to reproduce the issue. The next step is to obtain more information from the customer. However, in many cases this is not possible. So, what do you do? As the engineer you then review the code. Thoroughly comb through the code with this specific defect in mind trying to imagine how on earth such a defect could occur. Specifically think about race conditions and timing issues. You should be able to find a defect, a possibility, with regard to how the customer-reported issue could have occurred. Then you fix that defect knowing that it may not be *the* defect and report the issue as fixed. Will the defect come back? Possibly. But you’ve done several things: you’ve fixed an issue, you’ve become more familiar with the code, you have trained your mind to think about those hard-to-catch race condition bugs, and you don’t have lingering bug reports. Do not simply put the defect in a “watch” state and close it as “unreproducible” after a fixed amount of time, say 3 months. Yes, I’ve worked at companies with this policy. Think about this from a customer’s point of view. No response for three months, then finally a “we were unable to fix your issue” response. The impression received by the customer is that your company doesn’t take requests seriously and are not capable of fixing issues. However, by closing the issue as fixed, won’t the customer be annoyed if the defect still exists? Perhaps. But this time, if the customer sees the issue again, they will be more apt to report the issue again and, hopefully, with more detail. Why more apt? Because they see that your company is responsive, diligent, and attentive to customer requests, which is key here. Do not sit on bugs, especially customer-reported bugs, for long periods of time. In sum, fix a bug related to the issue (hopefully it does in fact fix *the* issue, but perhaps not), don’t lazily place defects in “watch” states, and never ignore your customer.

Over Processed … The Beginning

Once upon a time, there was no source control, bug tracking, documented features, etc, and the new processes that introduced these things improved productivity and end results. These are good processes. Unfortunately, the pendulum has now reached the other side and development is over-processed. The new processes seem to have stemmed from trying to make poor programmers better. As a company sees too many defects in their product and too many disappointed customers, they look to root cause a bug and solve any future occurrence via process. This fix-by-process attitude is the root cause of over-processing the software development cycle. The problem is not the process but with the people. New processes that force everyone to follow a “proper” programming, testing, and automation paradigm, just slows down development and frustrates the good people in your organization. Not every feature, change, and bug fix fits into a prescribed step-by-step process. It just doesn’t. The end result are engineers bypassing processes, attending unnecessary meetings, lazily (and inaccurately) filling out fields and forms that are required, scoping out features that will never make it into a product, and so on. So how do you produce better software with fewer bugs and on time? You definitely don’t create more process. Instead, you start with the people, fully enabling your best engineers and developing processes around them (not the worst engineers), understanding the product and *not* falling into the feature bloat trap, pushing for full attention-detailed testing, defining and vetting interfaces (which is where most bugs occur), requiring modular and preferably object-oriented coding, and minimizing meetings and interruptions to be as productive as possible. This is how you deliver a great product.

If it sounds that I am against process, I am not. I believe in a lightweight process as I have seen it succeed and I have seen products using heavyweight processes fail miserably. I have had the advantage of being able to define just about the entire software process for my product and was able to tweak this process every release. I have seen what works and what doesn’t. I intend this blog to be the (mostly) non-technical story of what I have learned over the years about the software development life-cycle, and I want to share what I have learned.

I am extremely aware that I have worked only at a handful of companies and within each, a handful of projects. It is not enough data points to make universal claims about all software. While I may state things as universal, I know they are not. You may find processes that work for your team that I adamantly advise against, and vice versa. I’m not here to push an agenda or tell you what is right. I’m here to tell a story and share opinions. Enjoy!