"The most improper job of any man ... is bossing other men. Not one in a million is fit for it, and least of all those who seek the opportunity." - JRR Tolkien

"It is a well known fact that those people who most want to rule people are, ipso facto, those least suited to do it. To summarize the summary: anyone who is capable of getting themselves made President should on no account be allowed to do the job." - Hitchhiker's Guide

What Do Employees Want?

Not long ago, Bill Gates shared what he thinks is the most important perk companies can give the best employees: flexible work arrangements. Now a new study from Harvard Business School says companies that let their employees "work from anywhere" and work whenever they want wind up with employees who are more loyal, more productive, and cost less. - Inc

Managing for Success

Fight work stagnation (too correct can equal too late with some types of projects)
Make sure everyone stays on top of documentation (including well-commented code)
Regular communication is key (probably at least weekly)
Remember that the mind can handle two tasks easily, but three dramatically increases the difficulty
Beware of overweight or underweight processes
Trust but verify
Avoid lazy one-size-fits-all policies
Build community and a positive work environment

These are also leadership (stewardship) values

Drive consensus
Make rewards meaningful, not trivial
Praise publicly, correct privately
Value all contributions
Do the dirty work sometimes

Organizational Emphases for an Engineering Director

To be great, one first must be humble; once greatness is achieved, humility must be regained in order to become even greater, and so on.

Cultivate the student's mindset, and walk the path of lifelong learning. Three things will happen: 1 - people will like you, everyone likes the observant, inquisitive student; 2 - your capability and wisdom will grow; 3 - you'll discover who and what you want to be. I've never met the engineer who knows everything about everything in the field, but I have met smug engineers that are too proud that they know a little about something. They are no fun to work with and come off as unteachable.

Community is key to group power and success. If you have the right people, and they develop a bond as team, you can achieve great heights. For this to happen, each engineer must find common ground with the others and the work place must be an enriching, inviting, productive environment.

Be the best team in the market at one thing, and maintain that dominance.

Everyone needs to understand the big picture. When questions are asked that can't necessarily be answered pleasingly, turn it around as "What are we doing here? We are building a company to do _______."

My Own "Coaching" Principles

Discuss career goals and how to achieve them on a realistic time frame
Discovering what one's strengths and weaknesses are is truly empowering, but it can take years
Preach the virtues of listening to others, and not talking past each other
Become more well-versed in the field by reading books, and posts from sources like The Embedded Muse and EE Times
Follow the "Habit" of asking the right questions, and asking often
Don't tell others how to do their own jobs, communicate until they find the best path forward on their own
The choir analogy is a good one; place each member in a position to have the most positive impact with their skill set
The best teams are more or less self-organized

Training Tech Leads

Apply the use of VRD - visual representation of the design - to give understanding and create a focal point of discussion, and create system descriptions
Emphasize the importance of correct peer review dynamics to properly identify scrutiny level, best possible speed, enable smooth integration (The Three Ss)
Communication, Communication, Communication (and it's sister Documentation, Documentation, Documentation) are the three most important facets of engineering
A software project is never completed, so it must be shipped in some near completion state
Understand the importance of revision control and keep a firm grip on that
Work WITH the team to create meaningful guidelines, select tools/standards, create thin processes, not AGAINST them
Encourage healthy debate between team members and facilitate the decision making process
Do a little managing - take on distractions to allow the rest of the team to work more effectively
See and find work-arounds for challenges the team will face, in advance
Delegate responsibility for areas of the project to capable and appropriate team members
Internalize the principle of 'trust but verify'
Wield power not by asserting position on the org chart, rather by leading and producing
Be prepared to take an active role in recruiting and hiring, at times
Help the team to be comfortable with experimentation, pushing themselves, and failure

Delegation is something people often take for granted, but not everyone is great at doing it. You need to be able to let things go, and becoming a new tech lead is where this ability starts to matter.

Organizational/Individual Archetypes in Engineering and Software Development

These are things to watch out for on a team. Most of us probably have a little of most of these inside of us, and certain roles can fool an engineer into letting one personae dominate his character too much.

The Backseat Driver: Likes to sit too close to you while you work on debugging a problem and authoritatively ask for this test and that test rather than let you try and probe, read, document, absorb and otherwise learn about the nuances of the system and problem. It feels like flailing around, but because he occasionally makes a lucky guess he keeps using this method. Frequently grabs control of your workstation from you in aggressive fashion.
The Elitist: Doesn't remember that he once went through a long learning process, or see the reason others might be still in it. The irony is that he simultaneously scoffs at the idea that there's any value in other tools or expertise. Far too comfortable in a role that doesn't challenge him any more, he has become stagnant in his career and knowledge development and holds what he has very closely. So closely, he's irritated by learners and looks down his nose at his less-informed colleagues. He over-values his specialist knowledge and does everything he can to keep the entry barrier high enough to calm his paranoia about his job security.
The Empire-Builder: Likes to pretend to be a company man, insofar as it gets him what he wants - personal power in a tiny little world. Treats other teams within the same organization as the enemy, probably because he feels he is competing against other managers for recognition. Cancerous company problem if left unchecked, destroys productivity, and it leaves managers stepping all over the careers and growth of anyone they can.
The Kool-Aid Peddler: Never questions company direction or management, and doesn't long endure the presence of those who do. Uncomfortable and awkward in trying to find a legitimate defense for poor decisions, but nevertheless will always try. Sometimes comes across as being unable or unwilling to empathize. Likely to be a "Yes Man". In certain cases this can lead to advancement, so it could be a survival mechanism for those too comfortable or unimaginative.
The Mafia Boss: A variant of the Empire-Builder, but takes a more aggressive stance in a very tribal us-against-them mentality. Displays belligerence in the workplace for no good reason. His direct reports are loyal because he fiercely protects them; when asked you'll see the look on their faces go distant, eyes glaze over, the response becoming almost robotic - "Yes, I enjoy working for him. Why would you ask?". All others cross him at their peril.
The Micro-Controller: Many engineers have this tendency and most are pretty good about trying to keep it under wraps, but production and morale can really drop when that's not the case. This type tends to get obsessed with minutiae that can be sorted out later, and if in control wants to review and gate the approval of every little thing. We are all perfectionists to some degree and love accuracy, but time and again we've learned the lesson that time to market, brand image, marketing message, quick/agile development, etc, are at least as critical as any other considerations for being successful. You might apply the description "cart before the horse" or "can't see the forest for the trees" here. However, there are certain roles in which this tendency is more desirable (such as aerospace V&V or QA).
The Micro-Manager: Loves to spend most of the day collecting status, probably because he can't find any way to contribute technically. Instead of providing the most important management service (clearing obstacles for engineers to do their jobs, campaigning for better working conditions, etc), often becomes an obstacle. Overwhelms engineers and slows productivity with communication overhead in the form of meetings, emails, etc.
The Pal: Sometimes not very technically adept, this type comes to work mainly for the social interaction. Possibly good at spinning BS to make himself look brilliant. Gregarious personality in many cases. If The Pal finds the right manager he can buddy up with, he'll hang around forever milking relationships with those in power. If he can't luck into anyone to buy his schtick, he's likely not long for his position. Could go either way.
The Phantom Manager: This less than inspiring leader makes it pretty obvious he doesn't care much about your career development as he goes incommunicado most of the time. He has kind of a detached personality and doesn't stoop to speaking with junior engineers. His team may be left trying to figure out what they are supposed to be working on at times.
The Plank: This inflexible type has a specialist set of experience and knowledge and he doesn't operate outside of that context. It's his way or no way, and he is quick in public settings to throw shade on any other proposals. Likely a chatty person who can come across as pally until you cross him by suggesting alternatives or discussing design trade-offs. Heaven forbid you are teamed up as collaborators and you do things a little bit differently than he with his pet project he's been with for 10 years or so.
The Tribal Chiefs: Most upper management folks can't resist the urge to make a struggling project run even later by assigning more middle management to the task. That's how you get the scenario of "Too Many Chiefs, Not Enough Warriors". Since giving technical work to managers is some kind of ancient taboo of mankind, you end up with X count engineers spending way too much time giving status to 3X managers.
The Wet Piece of Bread: No one's quite sure how this type was thought to be an asset to the team dynamic, and they throw a wet blanket on any social situation. You can't pry any sort of hobby or common-ground interest out of them, but if you finally do they still won't have much to say about it. This guy doesn't have much of a sense of humor and can make a work day long and boring, but at least he seems to do good work as long as it doesn't need to be shared much or understood by the rest of the team.
The Complainer: There isn’t any tool that works well enough for him, and all suggestions eventually meet with derision. Documentation doesn’t hold his hand every step of the way and it’s never good enough. Establishes a pervasive negative tone at every single meeting and torpedoes team morale. Is convinced that he has to repeat himself over and over, and let everyone know how annoying that is to him.
The Dark Arts Practitioner: Likes to pursue the usage of new or little-known tools and techniques even if they aren’t well suited to the project at hand. He is seduced by things that are fresh and exciting, though may be simply swayed by the high barrier to entry that will keep other engineers outside his exclusive club. Over-complicates designs because he’s trying to be too clever or fancy, and neglects to keep up with proper documentation, making life harder for maintainers coming along later.
The Theorist: These engineers aren’t all that interested in practical applications, and it can be difficult for them to focus on getting products working and shipping. They like to create layers of abstraction and plan out how to scale systems and designs, but struggle with implementation. Can be useful, but can also be dead weight.

Seen on the Interwebs

Many development problems have zip to do with code. Trying to fix the code without addressing those (which are often outside your ability to change) is pointless. Organizational issues, terrible overweight processes, political infighting, poor decision making by management or product teams, or even dreadful hiring practices all can make the code terrible but can't be fixed by trying to change the programmers.

What do the Christian scriptures teach us about working with people?

Love the co-worker, not the mistake.
When you fail, admit the error, get back up on your feet and keep pushing.
Service is the first, most important part of leadership.
The success of the enterprise is everyone's joy.
Contention is corrosive to the work environment, and comes from the malcontent.
Others should always be treated with respect, even when not present.
Be an active worker, with initiative, not always needing to be compelled.
With any stewardship, big or small, it's what you do with what you're given that matters.
Be grateful for and value each contribution, and express gratitude.

Team Building

https://www.atlassian.com/blog/teamwork/team-building-without-games

Over a two-year period, Google studied 180 of its teams and interviewed 200+ employees. They found that above all else, team members need psychological safety. The safer we feel taking risks and being vulnerable in the presence of our teammates, the more we will admit mistakes right away, ask the “stupid” (but necessary) questions, challenge assumptions, share information, and propose ideas that are so crazy they just might work – all of which are key ingredients for creating a high-performing team.

Fostering psychological safety is a full-team job, but it starts with managers. We coach our leaders at Atlassian to openly ask for help, try new approaches, and treat honest failures as opportunities to learn. They’re also free to share their hopes, fears, and struggles to whatever degree they’re comfortable, even when it has nothing to do with work. That sets the tone for the entire team.

Building trust and belonging is a sound investment. Just be prepared to play the long game. For the increasingly popular cross-functional team, it’s even harder. Team membership changes depending on the project, with members filling a variety of job roles. It’s an effective organizational model (one that Atlassian uses frequently), but there’s a catch: fewer shared skills and experiences means it takes longer to build trust between teammates.

Getting Stuff Done is the Ultimate Team Builder - the point is to use actual work activity instead of silly off-site games, and stay productive.

My Additions

Consider the Trust (offline) vs. Performance (battlefield) curve for Navy SEALs. The reason for this is INTEGRITY. Each member of the team must believe in the other members of the team as a person, not just as a soldier.

How is this manifest practically with engineering teams? It means once something is resolved and a task is assigned, the others on the team should not worry whether the task is going to be completed.

What's another way to describe this trait? The willingness of an engineer to take OWNERSHIP. When you take personal ownership, you relieve the burden on your teammates. Not just the burden of labor, but also the burden of thought. They can turn their mental energies to other things that need attention.

Are we really building teams? More correctly, we are building INDIVIDUAL CHARACTER. When you have the right individual level of ownership alongside the proper set of complementary skills, it is easy for a team come together.

What then is the rule of thumb for building successful teams? Combine complementary skills and expertise with the character trait of integrity, ownership, and responsibility.

So, it would seem obvious, but the most important part of team building is having the right individuals on the team. Too often we see people try to take a group of people they are handed to manage and do some hand-waving to turn them into a real team.

Mnemonics for Assembling a Good Team

BEMO
Belligerents, Egos, and Micro-managers are OUT. These are obstacles to a safe, trusting, achieving team dynamic because they don't put the team first. No one who values individual accolades above team recognition or throws others under the bus is welcome on the best teams. The problem with micro-managers or micro-controllers is that they suck the morale out of the team in a different way - by slowing the work down and taking the fun out of it. They tend to try and gate every checkpoint personally, and won't share enough creative control with others. All three of these types will cause everyone else on the team to want out.

RIO
Responsibility, Integrity, Ownership. Each member of the team should be able to rely on the others to get their part done and done well, rather than spending thought cycles worried about outcomes. These are much more valuable traits than technical ability. It's ok to make mistakes, even the most experienced and savvy will do so at times. But what happens too often is an avoidance of ownership of those mistakes. The best teams create a safe bubble in which it's perfectly fine to reach higher, make a mistake, own it, and then come out with a good learning experience.

PIE
Productivity Intelligence and Efficiency. "Getting things done" is the best team building activity and breeds momentum. So as others have said before, setting your team up for wins and helping them achieve them is far more important than busing everyone out for a half-day of rope climbing and awkward trust falls. But what is productivity intelligence? Maybe it's my way of saying "work smarter not harder". Productivity is simply working hard and pumping out greater volume. Productivity intelligence is understanding the value of quality, how you get there, return on investment, and not ignoring the causes of productivity the way many companies do. Yes, productivity has causes. For example, care should be taken to customize the work environment for each engineer so that they are most comfortable. If the office feels like a second home and a good place to communicate, this will cause productivity. Removing transitional barriers is another cause of productivity. Incentives like equity financial stake in the business cause productivity.

Explaining Management Roles

Titles do not matter, responsibilities do.

Engineering Director: An extension of the Engineering VP to assist with management, company direction, and technical leadership.
Engineering Manager: Lead for a group of engineers within one discipline, defines the implementation, the way the features are built. Does hiring, training, helps the team grow, performance reviews and career development. May also serve as project manager for small efforts.
Product Manager: Tasked with creating the product "roadmap", works closely with the marketing team and company business leadership, and sees the technology from a market strategy perspective. Successful if the team delivers the right features and the product does well in the market.
Product Development Manager: Not actually developing the product, but are performing a Product Management role in close coordination with a development team.
Program Manager: More of a technical position than Product or Project Managers, oversees the engineering development on one or multiple related projects. Figures out engineering resource needs, creates and maintains technical documentation, ensures quality.
Project Engineer: This is a technical role involving work similar to that of Project Manager, but with more responsibility for architecture and other technical details. Coordinates activities of various engineering disciplines and teams, and oversees multiple phases of the project like design, development, test, manufacture, deployment, support, etc.
Project Manager: Tasked with ensuring the execution of the project, making sure milestones are met along the way, breaking down tasks into smaller chunks. Not necessarily a strategic role. Successful if the project comes in on time and budget. Usually not a full-time role for small projects. Often a role filled by a non-technical person for a large project and full-time role.
Technical Product Manager: Describes a person, not a role. Specifically, it describes a Product Manager who has a technical background and works on a technology product.

Management Roles - Building a Device

WHY/WHERE: Marketing Manager, Product Manager
WHAT: Product Manager
HOW: Program Manager, Engineering Manager
WHEN: Project Manager

Startup Roles

Seed stage:
Broshar believes a start-up team that wants to impress a VC should bring complementary sets of expertise and experience to the table. According to Broshar, that includes at least three roles: the hustler, boasting the most business know-how; the hacker, who brings the most technical expertise; and the designer, who crafts the product’s functionality and its visual aesthetic.

Funded stage:
The CTO is the #1 technical guru of the company. He has deep insights in the technologies and core competencies of the company. He or she stays abreast of cutting edge research and development in his or her area of expertise, and in adjacent areas of interest that might have an impact on the company's technical direction. The CTO loves technology, and often keeps his or her hands dirty doing advanced development for interesting new technologies. He sometimes maintains a small “CTO office” of research engineers who can help him or her prototype things. Works with VP of Engineering on technical direction, patent portfolio, and may run the company blog.

The VP of Engineering role traditionally includes multiple aspects:
a) Personnel management – for small teams (up to 10 FTE), the VP Engineering is the direct supervisor of the technical staff. For larger teams (> 10 FTE), the VP E often manages contributing engineering managers, who serve as the direct supervisor of the technical staff. For teams at scale (> 100 FTE), the VP E’s direct reports will typically be senior level engineering directors, who in turn manage engineering managers.

b) Program management and engineering execution – the VP Engineering is responsible for ensuring that the product vision is realized through excellence in execution.

c) Technical leadership – the VP Engineering is responsible for co-developing the technical strategy with the CTO, and for developing and maintaining a technical roadmap that will continue to innovate from a technical standpoint. The VP Engineering may personally serve as a systems architect, or may assign another engineer to assume that role.

d) Strategy development – the VP Engineering serves as part of the senior staff, working in an interdisciplinary manner with their peers in other departments (e.g. VP Marketing, VP Business Development, VP Manufacturing and Ops) as well as the CEO, CTO, and COO (if present) to develop company strategy and product strategy.

e) Budgeting - The VP Engineering is traditionally responsible for managing the annual bottom-up budget for the engineering department.

The CTO could also be considered the "Chief Architect" of the company.

Pitching Startups

The product itself is less important than the business. You are pitching the team and advisors, showing traction and advantage and income streams.

Look for a CEO to understand the ecosystem and build the company, not just the product.

Why are you the right person to solve this problem? Must have a competitive edge.

What are you looking for from investors? Bigger asks are harder sells.

Can you reach a milestone with $1M or less?

Learn about the individuals on the pitch panel, what are their interests, what impresses them, etc.

What is Culture?

https://www.themuse.com/advice/step-away-from-the-ping-pong-tablethere-are-better-ways-to-contribute-to-your-companys-culture

It may be what you really are looking for is values, not just culture.

It's how workers interact with one another, company values, what type of behaviors are encouraged and rewarded, the office environment, dress code, et al. Here's one description:
There are typically four categories of culture: beliefs and values (i.e., your company's overarching vision); structures, processes, and norms (“How things work around here"); symbols and language (office acronyms and slang); and habits and expectations (like the dress code and email etiquette).

Does a company invest in training and growing and retaining employees, or are they expendable cogs?

Does a company want to share successes and profits, or is it about milking everything out of a worker and discarding them?

What's rewarded, hours of physical presence or actual results?

Are cheesy cliches or business jargon a focus of the management?

What about drama and sacrificing of team goals? Is it punished?

Here's one writer's idea about values at https://thriveglobal.com/stories/job-seekers-next-time-you-ask-about-company-culture-ask-about-this/

INNOVATION & FLEXIBILITY-Is the organization innovative, agile and committed to growth? Do they have their ear to the ground and able to make changes to adjust to market conditions and customer needs quickly? Do they listen to the suggestions of the brilliant people they hired at all levels? Are they open-minded and willing to consider a new path if the current one is not yielding results? Are all departments mutually accountable for the company’s growth?

HONESTY & TRANSPARENCY- Is leadership transparent about company challenges and how they are working to address, or is there an information vacuum? Does leadership say what they mean and mean what they say? Can those within the organization have honest, direct and respectful dialogue with one another? Will you know where you stand? Can you tell another employee if they are letting you down? Seriously. Do people talk to each other? Honest and transparent communication is a must have for building trust and your buying into the company.

COMPANY PRIDE – Are the employees genuinely proud of the company? No, really. I mean it. They don’t necessarily have to be skipping down the halls wearing company swag every day, but is there a palpable sense of pride across the company and mass adoption of its mission? Are employees complementary of the leadership? Are they appreciative of the talents, wisdom and skills of their colleagues? Do they have confidence in one another? Do employees like telling people they work there?

UNITY- “Us vs. Them” can be fairly common, unfortunately. “Us vs. them” can be cross-departmental, management vs. non-management, corporate vs. local offices, west coast vs. east coast teams. I’m not talking about a healthy competitive spirit. I’m talking about the blame, resentment and lack of shared vision & accountability that poisons a company’s culture, creating gridlock. And once divisiveness invades the culture, it only proliferates. So how does the company seek to bridge this gap? What is the connective tissue that binds together all practices, offices, and various roles within the company? How do various departments collaborate to “GET THE THING DONE?” Does the company breed a sense of humility and grace, valuing everyone’s contribution vs. my job is more important than this person’s contribution?

EMPHASIS ON SELF DEVELOPMENT/SELF-IMPROVEMENT/BEING A GOOD CITIZEN- Does the company or leadership care about your “why?” Do they care not only about your being success at work, but also your successful at life? Does company leadership embrace self-development and personal growth? Does it invest in ongoing training? Does it favor authenticity and vulnerability? Does it encourage your being a better citizen, allowing margin for volunteerism, generosity and using your gifts outside of the office for good? Does company leadership recognize that personal health and happiness make you a better employee? Is your organization generous? How do they contribute to make the world better?