5 Business fundamentals you need to understand before being promoted into management

• The difference between leadership and management
• Leveraging emotions and empathy
• Improving communication across stakeholder groups
• Development is an art
• Personal process balanced with team process

Career Path

The First Job Search

• LinkedIn, Meetups, Professional Orgs, face to face when you’re likely an introvert
• Ask for advice and connections, prioritize what you can learn over what you can earn
• Try to hold out but don’t be afraid to jump when it’s time
• Show up before the jobs are published

The Path to Partner

• Why your cards need to say more than “engineer”
• Gamification of the workplace
• Values and outcomes for each level, developing new mindsets
• Progressing up means dealing with more ambiguity and enrolling juniors in your ideas

Why you are not being promoted

• The personality tendencies of technically competent people
• Moving up in management vs. moving up in expert

Why you are not being promoted, Part II

• Going deep as an expert and going wide as a servant of the company’s success
• You have to go beyond Wikipedia
• Talk to other professionals, outside your field: learn to think like an owner

The leadership ladder

• VP: responsible for results of executing to plan, visions for the future of the company
• Director: manages managers, provides input to the VP, makes strategic choices
• Manager: executes to plan by orienting the team, provides input to the director
• Engineer: tactical and detailed choices, focused on personal path

Leadership: balancing the big picture and details

Big Picture

How do we do this better? 

• What do we do? How do we know things aren’t what they could be? 
• What’s a process and what’s a project? 
• What are our communications channels? Who else should we be talking to?
• Are we matching authority to responsibility? 
• How do we ensure standard and still allow smart people to make smart decisions? 
• When’s the last time you calibrated your engineers?

Hiring for curiosity and its pitfalls

• Value of curiosity, diversionary and epistemic
• Risk of rabbit holes and non-completion
• Employees with epistemic curiosity balance the ones who just like to prototype

Buy-in means more than one thing on more than one level

• Buy in on plan or idea, plus its framework
  • E.g. not just a vision, but what a vision is
  • Relative priorities

Servant leader vs indispensable

• What a servant leader looks like at the top of a tech team
• Never being able to take a vacation because invaluable 
• The satisfaction of developing team so you’re no longer essential 

The One Big Question: How do I make this company more successful? 

• You’re more successful when it’s not about you
• DIfferent from personal big questions like “what am I doing now?” or “how do I/we do this better?”

Applying your engineering mindset productively

• Using systems analysis techniques to think about teams and companies
• Work output flow, communication flow
• Filtering, amplification

Details

The Gallup Questions and Tech Teams

• Which apply most and how
• The 12 questions most important to successful tech teams from: “First, break all the rules”

Job Descriptions are the same as Periodic Reviews

• Job postings help team and leadership see meaningful metrics for their success
• Write a plan, execute from the plan, update the plan
• Ensuring improvement sticks: assessing change and setting up feedback 

Matching responsibility and authority

• Mismatches set your team up for failure
• Authority without responsibility leads to floundering, responsibility without authority leads to burnout and program failure
• Describing outcomes without prescribing paths

Chunking work

• Mesh with a product/system update path
• One chunk might be more efficient, but you can’t be without product and you might have to invest in older products to keep them compatible
• The allure of the hard cutoff

Balance

It is so hard to be an engineer and a manager: Management from the trenches is hell 

• Giving up technical work means giving up familiar satisfaction
• Getting to the bottom of things vs staying on top of things
• Keeping others pointed in a direction vs. making your own progress

You are no longer “one of the guys” 

• Be a shit shield, be a safe recipient of bad news
• The value of setting up outside mentors and how to structure this role
• Not a total democracy: want to know that someone competent is in charge

Emotions and Empathy

The pull of professional emotions

• You need to be emotionally invested in your work to be good at what you do.  
• You need to be emotionally divorced from your work to make rational decisions

Technical people choose a daily path of frustration

• 90% of our frustrations are puzzles we unwittingly created for ourselves
• Savor the resolutions, like an intellectual orgasm
• Let’s stay frustrated: the mantra change

Technical People Need to Understand Emotional Function

• Function and futility calculations
• Emotional functions can outweigh rational factors
• Apple’s aesthetics as an example

Empathetic Listening for Technical People

Do:

• Minimize distractions, give calm and complete attention, stay present
• Soft eye contact, supportive and welcoming body language
• Understand, then be understood
• Repeat and summarize, then ask clarifying questions

Don’t:

• Interrupt, finish sentences, tease, vent, or blame
• Analyze or make judgments
• Give advice or move right to fix-it mode
• Be right: win at the expense of understanding 

Applied

• Examples
  • Kirsten: makes a person feel heard, can switch it on
  • Isaac: listening to clients developed skills
• Product development experience helps develop the right questions

How to show you’re listening

• Summarize difficult conversations so the other person knows what you’ve heard and what’s happening internally
• How to express frustrations and concerns

Tech Manager Skills

Communicating with clients/choosing clients

• The value of aesthetics for engineers
• You need two: profitable / like the people / like the day to day activity I do there
• 4 quadrant paradigm

The Tech Lead Ego Trap

• Three conversations in the room of two people
• You are not who you think you are: their statements vs. your self-perceptions
• What’s said in your head that you didn’t verbalize

The art of managing up

• Why it’s harder than managing your team
• Being a shit shield, maintaining priorities, expectation management
• Communicating realities that affect higher-level decisions
• Checking in with peers and subordinates for feedback

A tech manager’s guide to ego massage

• Knowing your team: quirks, what keeps them engaged and productive
• How to keep smart people in sync and pointed in the same direction
• The emotional nuance that eludes technical experts

How to hire engineers, the value of testing

• Email program that helps me screen quickly and give opportunities when resumes aren’t showing the full picture
• How tests correlate to getting the work done
• Why the people that do all the work should visit with clients

How to manage a project when there is no project manager

• Engineers need to understand at least these 7 pieces of jargon
• Putting the right mix of teammates together: processes, experience, and cadence
• Knowing what is operations and what is a project

Moving from sins of commission to omission 

• After some time as a tech lead, you might stop making the traditional mistakes 
• Shift to a mindset of looking for your mistakes in the realm of missed opportunity

Principles not Rules

• The differences between the novice, the competent and the expert and the move from followign rules to following principles.
• What are our maxims for management? 
• How to grow a team that can follow principles instead of rules

Ask your team the right questions

• Managers do better with binary yes/no and a clear sense of the solution you want
• Team members won’t think creatively if you shut them down with binaries
• Use team members’ time and knowledge to explore options with open questions

Communicating across stakeholder groups

The role of good questions in technical sales

• Building confidence and communicating “I understand your need” by reflecting the landscape and turning to typical solutions/tools
• The value of visiting the customer

I am concerned that…  The preamble to successful criticism

• How to speak up about your concerns without shooting other people down
• Alignment of the mouth, mind, and heart: authentic communication
• When to overcommunicate: they don’t get it even though you think they do

Why your communication toolkit is failing you

• Conflict avoidance, introversion amongst tech workers, and poor communications outcomes. From Stone’s Difficult Conversations and Isaac’s “listening tour” experience.
• Commander’s intent
• Keeping the boss informed without provoking ire

Build or Buy?

• Your bias is likely toward build, but you don’t always need to
• Understanding canned solutions and how they might be stitched together
• Roll your own IF
• Then see who else will pay for it

Why it’s good to lose money on the first production runs

• The fallacy of premature optimization
• When a task is “soft done”: optimization vs. binary outcomes
• Have a dozen fifteen-minute conversations to get people to say why aren’t you looking over there?

Commander’s intent

• Along with the TLDR and the 5 whys, put the Big Why at the top of the document 
• Start the work that takes a long time
• Know what the project-critical path is

The Art of Development

Where development gets lost

• Using the wrong
  • Process
  • Architecture
  • Partners
  • Estimate
• Premature optimization

The two things required for your project’s success will surprise you

• Stakeholders need to believe you are competent
• Stakeholders need to believe you have their best interest at heart
• You have to communicate these things because you have information asymmetry, the gulf between professionals

Why your next product will fail: 17 Questions to Ask

• Thorough question checklist 
• Causes and common failures
• Examples

Are your programs behind schedule and over budget? I know why. 

• Statistical reasons
• Jobs to be done paradigm
• Game thinking and technical products for B2B

Stop saying R and D

• shouldn’t  be linked together though they always are
  • Research: can guarantee that we’ll look, but not what we’ll find
  • Development: can guarantee certain features, but not how long it’ll take to get them to desired level of functionality
• You need to educate stakeholders on these separations 

Why the patent system is broken.

• Original intent: information to the public, time limited monopoly for inventors
• The novelty bar is too low
• Many patents apply new tech in ways we can anticipate

Bugs and building

Building the thing right vs. building the right thing

A mountain of spaghetti code and undocumented mechanicals and electronics that solve a customer’s real world problem are vastly superior to a well engineered well documented, modular, modern extensible solution that does not.

Compilable architecture 

• Keeping documentation and code in sync is impossible
• The importance of context and chunking information
• Debugging: inspection, one-line changes, rubber duck, and architectural decisions

There will be bugs

• We’re not magic: bugs are part of the process, maybe even half of it
• Expectation management: we hope to find most before we send to the customer
• Beta testing or other large hour input is required

Anticipating the future

Estimating

• Top-down estimating vs bottom-up
• Better estimates lead to better eam sanity
• How much architecture work is required

Enthusiasm and market risk

• Product Development Maturity Assessment
• Tech team needs enthusiasm and optimism for the product
• Don’t let it conceal showstoppers

Unknown unknowns

• Turning these into known unknowns through analysis of your project history
• Taxonomies and what they reveal about our trends and thought processes

The tradeoff is between more than good, fast, and cheap

• Cheap is both in development cost and COGS
• Feature set size and good are similar
• The hidden costs of going fast

De-risk your project

• Think of scenarios and what pieces of the system could fail and derail the project,
• Create small, fast tests to ensure pieces and assumptions you are relying on will actually work so you can have time to fix them if they don’t

Prototyping 

The 100 meanings of prototype

• Expectation management
• Is it bench-level proof of concept or pre-production? 
• MVP: Proof of concept, alphas, beta

The long distance from working prototype to shippable product

• Manufacturability, manufacturing support, cost engineering
• Often we propose going to alpha or beta so we can recalibrate
• This doesn’t mean we’ll have a revenue stream at the end

Software vs hardware

• The feedback cycle is longer for hardware: you can’t put it out with a few key features
• The decisions you make now might mean a crash you can’t avoid
• Regulatory burden differences

The limits of Agile hardware projects

• Rapid prototyping rather than working to “perfect” spec, setting integration points
• Need cadences and estimating time frames longer than two weeks
• Working with offshore manufacturers affects time frames

Technical Tools 

Locating using RSSI

• Triangulating between receivers
• Possibilities and difficulties with different location uses
• How AoA and TDoA should be building on what we’ve learned of multipath and transmission through non-uniform materials

Tools for Today

• Technical: bug tracking, versioning, automated test, release
• Process: documentation, project management, communication
• What’s working now and where we’re headed 

Why engineers can’t use a phone

• How to get engineers to pick up a phone and get outside help rather than trying to solve all their own puzzles
• How to manage people outside your area of technical expertise

Building yourself into a better team member

• Regression test your product changes
• Do an end to end check before saying your done so your team learns to trust you

Getting out of black and white thinking

Be an idea omnivore

• Taking what you’ve learned and applying it to novel situations
• A wise man parlays limited personal experience into a wide variety of novel situations
• A smart man can’t apply a much larger experience and knowledge to new situations 

Make your ideas pay rent

• What you believe about “how things are” should allow you to predict how things will be
• Can you test your beliefs about your team members, market opportunities, customers?
• Can you test your beliefs about yourself?

All you can do is shape the odds

• Tech people might respond to the idea of probabilistic thinking about life decisions.
• You can only control your thoughts and actions; everything else is just odds
• Live your life as though you’re writing a book and you’re the lead character

The Wisdom of Monty Python

• Oasis of time and space
• Urgent but unimportant
• Interruptions and recovery time

The Wisdom of Maria Bamford

• How giving people the benefit of the doubt helps you function better
• Makes mental health issues hilarious

If it’s worth doing, it’s worth doing poorly

• There are more things worth doing than we can hope to do well
• Not being able to excel in all of them doesn’t mean you should allow any of them to languish completely 

The Law of Leaky Abstractions applied to creativity

• Being an expert means being able to dig in and understand
• You have to know something for your associative memory to make links
• Knowing where to look everything up is insufficient 

Your teacher was wrong: #ThereAreStupidQuestions  

• Questions that encapsulate bad assumptions
• There’s really only one question: what am I going to do now? 
• Your time: 80% heads down, 10% thinking about the year, 5% the month/quarter, 3% the year, and 2% the longer term

To Succeed You Need to Leave Flatland

• You’re not always seeing all the angles from the space you’re working in
• Ignoring other dimensions can sink you
• N dimensional space: finding the other dimensions can explain what appears as chaos

When black and white thinking isn’t enough

• Tech folks tend black and white
• Nuance and self-definitions are necessary
• Wisdom, situational ethics, confusion: contradictory narratives

Habit building

Stop wasting your and my time

• Tricks for reclaiming some time
• Failing at time management and trying again
• Pushing yourself into places that don’t fit you wastes your time but can still be worth it

Personality traits are strengths and liabilities

• In the moment it’s hard, but in hindsight we can distinguish stubborn from determined
• Know your own proclivities and where you can likely add value
• Enhance your self-awareness by working with feedback

Your Personal Process

• Companies have process, but employees don’t always think about their own patterns
• These need to be connected: heads up to heads down
• Do you regularly ask “how can we do this better?”

Getting Things Done

• What to listen for and capture in meetings. Why volunteering to be secretary gives you power.
• Ticklers: use calendar items to make time for closing the loops and seeking feedback
• Make your calendar and to-do list work together

The pros, cons, and realities of self directed teams

• I worked with a self directed team of machinists at Johnson and Johnson that operated at a higher level than other service providing groups in the plant. The machinists had seniority and professionalism on their side to start, and the responsibility and autonomy upped their game.
• I helped setup a self directed software group at an IoT company. This pulled them out from under a reporting structure that lacked software architects and gave them a sense of autonomy, but that empowerment had a limit.
• Self directed teams require more than a copy of Robert’s Rules of Order, the level to which they can make their own internal policy needs to be evaluated and frequently their method for interaction with outside groups and their “customers” that consume their work output. We must also be prepared to plug the team into the higher goals of the company.

My other sources for articles

1. Lunch and learn topics from Syncroness.  Buzzword bingo for ME EE ID PM and Systems Engineering etc.
2. The most useful audible books that have tools, paradigms and ideas that I actually use. 
3. My midnight missives email collection from containing real time, working in the trenches, insights for a growing consulting engineering team.