Culture is not organic, it is cultivated. It is one of the most important levers you will have available to lead your team. The way I see it, these are the fundamental pillars of engineering culture.

1. Systems thinker: The ecosystem does not behave as isolated components. Changing something in one place may have cascading effects elsewhere. One must be aware of how will the system react to changes.
   
   Each layer of the system should have established software interfaces to communicate of other parts of the system. Those interfaces are contracts. Period. Full stop. End of the story. Don’t even try to argue or say “but…”. The contract is either with an external client, or an internal one. If you change something, you will be imposing unscheduled work on some other team. These are man-hours that could have been deployed elsewhere. “It is a simple change” is not an acceptable excuse. If you are still trying to come up with an exception, please stop.
   
   Do what is right. Version the interface and define a lifespan for maintaining the old one—preferably 6 months or more. Then, mark the interface as deprecated^[1] and add an expiration notice.

2. Building: What does it mean to complete a given feature or product? A clear definition of expectations is necessary, otherwise it becomes impossible to follow up progress or plan for the long, or even the short term.
   
   A clear definition of expectations allows for outside stakeholders to gauge progress, without incurring on the unnecessary stress of constant inquiring of when things-will-get-done.
   
   This is not a “shield” against communication and intra-team interaction. On the contrary, it is a layer of transparency to facilitates conversation. Rather than being confrontational, conversation becomes collaborative.
   
   The following list constitute the fundamental expectations of building:
   1. Architectural design^[2]: Think before acting. Before rolling up your sleeves and start coding, draw activity diagrams, use case diagrams, class diagrams, sketches, anything that will allow you to define all the parts and how they will interact with the ecosystem.
      
      Talk about your design with other engineers. They may have a different perspective or suggestions. Exposing it to criticism will help to strengthen your design.
      
      Design also is of great importance as the foundation of the documentation. You won’t remember all the details in your head. And even if you did, when another person needs to work on the product, they will be able to gain familiarity with the system without requiring your time and assistance.
   2. Documentation: Explain what the product, feature, or subsystem does. Sometimes documentation comes prior to implementation, some other times implementation comes first. Irrespective of which one comes first, documentation is an essential part of the process.
      
      Additionally, documentation is not meant to be a fire-and-forget solution: it should be a living piece of work that evolves along with what it describes. Attributes of good documentation:
      
      1. Requirements: what is needed in order for the system to work?
      2. Setup of the environment: how to configure the dials and knobs?
      3. Diagrams: a picture is worth a thousand words.
      4. Interaction: how does it interact with other subsystems and clients?
      5. How-to: steps to effectively use it.
   3. Implementation: Craftsmanship is the name of the game. Is it built to just work? Or was it built well? Are there design patterns applied to it? Which algorithms have been used? What data structures is it using? Is the code decoupled? Can it be reused in other parts of the system?
      Avoid creating tech debt at almost any costs. If you have to create tech debt, it must be discussed with the team and a deliberate decision has to be made.
      
      Priorities to consider when implementing (in this specific order of importance):
      
      1. Security: the data must be safe.
      2. Stability: systems should run as expected, and no one should need to wake up in the middle of the night to patch an avoidable error.
      3. Scalability: does it work for one customer? How about one thousand, one million?
      4. Architecture and design: if done properly, tech debt and refactoring should be rare and far between.
      5. Maintainability: implementation should be modular, clear, decoupled, robust, tolerant in what it receives as parameters, strict in what it sends as response.
      6. Runtime speed: yes, it should run fast, but only after all the prior items have been satisfied. As fast as possible, but not faster.
   4. Quality control: Trust, but verify. Test everything. The tests should go beyond verifying the basic functionality. Implement tests with the intention of breaking things. Test for unlikely scenarios, edge cases, wrong data types, and whatever else comes to mind. Last, but not least, if a bug is reported, immediately write a test case to reproduce it and ensure it won’t happen again in the future.
   5. Release process: Have a protocol for the release process, including a checklist with the key steps.
   6. Monitoring of execution: Measure (almost) everything. Usability analytics contains valuable information about how the system is performing, being used, and whether it is producing the intended results.

3. Mentoring: Don’t keep it to yourself, share the knowledge. However, there are times and places for that. You must not constantly interrupt your day to mentor people. You still have a job to do.
   
   Initiatives such as study groups, meet ups and so on, are of great benefit to you and colleagues.

4. Don’t be an a**hole: don’t be spineless either. Stand for tactical virtues: courage, honor, strength, and mastery.

5. Avoid isolationism: Engineering doesn’t work alone. Collaboration with other teams is paramount to your health and the health of the company. Conversation among different teams is imperative to everyone’s success.

6. Say “No”: Can you add this feature? Can you join this meeting? This is just a small change, right?
   
   Unless absolutely necessary, please say “No” to interruptions of your time and to scope creep. When in doubt, speak to your manager, your manager’s manager, and whomever else you need to speak to. Also, build enough arguments to support your point. This will make the situation clear to stakeholders and help the decision making process.

7. Growth: Always be learning, always be growing. Keep your skills sharp. What areas would you like to study? Engineering? Management? Marketing? Sales?
   
   Not only you will be benefiting yourself, but also the entire team. You will be making cutting edge contributions.

8. Empathy: Put yourself in the shoes of who is going to use the feature or product. Are you solving a problem or just shifting work to them?
   
   Giving a customer (external or internal) a data structure and asking them to code the rest to their needs may be a little too much to ask from them.
   
   Avoid falling into the Stack Fallacy^[3] trap, which is the incorrect belief that it is trivial to build the layers above yours. The occurrence of this misstep is counterintuitively common in high-tech companies.
   
   There may be cases where the product should be exactly that, as raw as possible. However, that is the exception, not the general case. Think about the complete solution, then see how far into it the implementation you should go.

9. Time and resources: Neither is infinite. Developing a reasonable ability to estimate the effort necessary to implement something is a necessity. We are not going for precision, but for accuracy.
   
   Accuracy is when you say that a feature is going to take a month and ended up taking a month and a half (could be better). However, the project was implemented as intended, involving roughly the team and materials estimated.
   
   Precision is when you say that there is a 93.57% chance that the feature will be implemented in 6 days and 4 hours. That gives a false impression of control over circumstances and generates an unrealistic expectation.
   
   Try thinking about the big picture when estimating: How long will it take? How many people? What equipment is needed? Are other teams involved (e.g. product, marketing, sales, legal, finance)? Will you need to hire personnel or an outside vendor?

10. Go to market: How would you bring this to market? What problem does it solve? Who would use it? And why? Is it an internal or external product? Perhaps this is a candidate for an open source tool?
    
    You may not be selling to an outside customer, but you may need to “sell” to another, internal, team.
    

---

[1] Deprecated means the version still works and is fully operational. However, it will not be maintained going forward, until its expiration date (save the case of a severe bug). New software should not be built using this interface, and existing software should plan to migrate to the new version within the established lifespan.

[2] Before being accepted, it is recommended that the architectural design is peer reviewed.

[3] Stack Fallacy: http://www.thelowdownblog.com/2016/01/the-stack-fallacy-why-big-companies.html

Image credit: https://pixabay.com/photos/old-antique-clock-watch-pocket-4704062/