I’ve noticed many articles, books and blog posts for Technology Leadership / Management are written people who now or recently worked in Big Tech (Maybe they have more time and job safety?). Some contain good advice. Whilst these are interesting to read and explore, they are not very practical for most Small to Medium sized technology companies. Whose choices are often focused around getting and ensuring market fit, business survival (i.e. the plan changes a lot, especially pre market fit), limited budgets, limited true innovation/research budget, limited engineering time, incomplete systems in supporting the whole of business (e.g. operations support, sales support, business analytics, etc), recruitment and retention without huge buckets of cash, limited power for negotiation with vendors, etc.
If the vast majority of the businesses on the planet are Small and Medium and don’t have:
- multiple recruitment teams or fully flushed out leadership training departments
- pay and benefits that most humans cannot even imagine or
- large blue sky research budgets or have access to or budgets that don’t run in the Billions
- writers having time to write about their experiences, failures and wisdom at small and medium technology firms
then there is a big gap in supporting small or medium technology companies who want to practically scale their companies.
My aim is to write a number of presentations and blog posts to explore business leadership, Technology Leadership and Management with tactics that I have used time and time again – over 10 Startups and Six Executive roles.
I will not do this alone, I will continue to learn from others in Software Engineering at all levels and of course those that work with Engineering Departments i.e. Product, Finance, Sales, Marketing, Operations, Legal, People and Customer Services – because in the end we succeed or fail together. And maybe in the end of this journey it will be a book and a set of videos.
My personal motivation is to write, reflect, learn from others and share. Learn more, update – rinse and repeat. I come from the open source community and my goal is not to make money on this or build a personal brand – but help all of us be better (yes including me).
Over the next year I will write to cover these topics. If you think there is a topic missing, DM me and if I know something about it I will add.
My goal is to share a runbook for each area, covering patterns and anti-patterns.
Series Hypothesis
“Most books are written by BIG Tech people, in large businesses, with the aim to build global architecture, large People teams and with lots of money (and little concern for costs). Most of software development is done in Small and Medium Tech companies. “
Series Principles
- Use of Technology to create Revenue
- Understanding the technology choices and what they do to the businesss
- Pragmatic approach to building the company
- Layered approach for different sizes of companies
- Will explore B2C, B2B and Marketplaces
- Initial focus to be growing from 1 Software engineer to 200 Software Engineers
- Collaboration is key to success for both the individual and the Business
- That we build Products, and the goal is to be a Product led Organization
Audience
Founders, CTOs, VP Engineering, Head of Software Engineering, Directors, and Executives who want to understand Software Engineering to a greater level.
Topics
The main topics I am aiming to cover:
Ownership
Delivery
Financial costs
Culture
As I create posts for each topic I will add the link above. The following areas will be interwoven within the above main topics, these lists will likely grow and shrink as I throughly explore each (this list is not in order of importance):
Software Engineering
- Documentation and System Understanding
- Who knows your whole system
- Tribal Knowledge and shared ownership
- Who are the experts
- How are the boundaries drawn between systems
- Change Logs
- Onboarding
- The balance of when to document and when not
- The power of event storming
- Ownership of Systems, Stacks
- Systems Observation and Performance an
- The importance of Metrics
- The danger of metrics
- Observation journey
- Dashboards
- Engineering Reviews
- Data
- Ownership
- The cascade
- Setting Finance and Business Analytics up for success
- Data Engineering
- Data Science
- Privacy and Permissions
- Quality
- Pull Request comments
- Testing
- Runbooks
- Incident management
- Dev Ops Culture
- Technology Lifecycle
- Experimentation
- Pilot/POC
- Product
- Adaptation
- Rebuilds
- Sunsetting Products
- The cost of not
- The opportunity to evolve
- Architecture
- Who makes the decision?
- Creating good Technical Evaluation and Comparison
- Importance for Request for Comments
- Effective Peer Review
- Architecture and People are deeply intertwined
- Infrastructure
- Increasing complexity
- The importance of tooling
- Cost of Architecture
- System Engineering
- Security
- Who owns it
- Security vs Revenue
- Compilance
- Protection
- Education
- Fraud
- Privacy
- Technology Ownership
- Programming Language choices
- Domain Driven Design
- Tech Leaders
- Community of Practice -> Language/Stack Guilds
- Estimations for Product
- Engineering Enablement work vs Product work
- Platform vs Engineering Enablement
- Scaling
- Complexity
- Tech Debt
- Maintenance
- Introducing new Technology
- Technical Evaluation
- Engineering Vs. Science
- The importance of Reporting, Insights and Prediction
- The importance of Data Engineering
- Data Science is not Software Engineering
- Web vs Mobile
- iOT
Humans
- Recruitment
- Setting the tone
- The market and trends
- Sourcing
- Pre Interview materials
- Interview Process
- Recruiters
- Diversity and Inclusion
- Cultural Add vs Cultural Fit
- Roles – Generalist and Specialist
- Retention
- Career Ladders and what is next
- Management Time – 121s
- Goals
- Communication
- Community
- Culture
- Transparency
- Valuable work
- Curiosity vs Judgement
- Clarity of Expectations
- Benefits
- Shared Understanding
- Short Term vs Long Term
- Impact on Recruitment and Retention
- Appreciation
- Opportunities for growth
- Engineering Leadership – Leading People
- Psychological Safety
- Feedback Loops
- Career
- Part of something bigger – Involvement in Engineering Strategy
- Connection
- Toxic personalities
- Performance Improvement Plans
- Firing
- Acquisitions and Mergers
- Engineering Management – Managing Process
- Labels and the need for reporting
- Agile vs Project management
- CI/CD vs Waterfall
- Sprint Reviews
- DORA Metrics
- Post Mortem’s
- Incident management
- Technology Stacks
- System Design
- Expensive Control and impact on culture
- Working with people from different countries and or cultures
- Career Development beyond the company
- Engineer Lifecycle
- Onboarding
- Engineer Growth – Improving capabilities
- Discovery Days – Space to experiment
- Technical Mentors
- Training Budget
- Performance
- Promotion
- Offboarding
- Career Support
- Layoffs
- Growing New Engineering Leaders
- Management
- Try it out Program
- Tech Leader
- Coaching & Mentoring
- Ambiguous
- Growing experienced Engineering Leaders
- Senior Manager
- Director
- Staff Engineers
- Senior Director
- Principal Engineers
- VP
- Influence vs Control
- Giving others autonomy to fail and succeed
- Space to step up
- Leading through others
- Your replacement
- IC
- Staff to Principal
- Engineering Management to IC
- Stakeholders
- Reporting
- Demos
Finance & Legal
- The need for fully understand Enterprise Metrics
- OKRs and KPIs
- Budget
- Headcount planning
- Recruitment strategy
- Cost planning
- Vendor management
- Promotion cost
- Scenario Planning
- ROI Analysis
- Headcount communication and impact
- Vendors
- Evaluation
- Process
- Legal
- Reliable Financial Data
- Payments
- Fraud
- Business Analytics
- Centre of Excellence vs Distributed analysts
- Market Data analysis
- Ad hoc Analysis vs dashboards
- Coping with all the priorities
- Supporting other departments
Product
- The most important partnership
- A platform that accerlates Revenue
- A platform that shares understanding of delivery potential and capability
- Estimations
- Building Roadmaps
- Shared Understanding
- Engineering Structure
- Useful tools for working together
- Agile vs Project
- Program Management
- Ready for Development & Ready for Release
- Formulation of the Product Plan
- Recap of the Product Plan
- Design
- Research
- Product led Organization
- External Partnerships
- Peers
- Working with Big Tech
- The everything else Team
Governance
- Your Boss
- Who is the boss i.e. CEO, CEO, CFO and patterns
- Shared Understanding
- Clear Expectations
- Professional CEO vs Founder
- The Executive
- Is it a Sales, Finance, Product led organization?
- Getting to shared understanding
- Managing perception vs reality
- Managing expectations
- Effective incident management
- Power dynamics
- Giving opportunities for future Executive
- The impact of stage
- The Board
- Funding
- Giving useful information
- Impact of trends
- Leading an Organization
- Airtime and influence
- Inspiration for the emotions
- Concrete for the the logic
- Getting past Ego
- Opportunities for Leadership development
- Organization Culture
- Goal Creation
- Transparency level
- Response to failure
- Motivation to achieve the goals
- Economic impact
- Social impact
- Diversity and Inclusion
- Corporate IT
- Onboarding
- Supporting the Organization
- Change of roles
- Security
- Corporate IS
- Moving from departmental fiefdoms to alignment
- Shared Documentation
- Shared Dictionary
- Data Council
- You
- Survival the job
- Thriving in the job
- Overcoming hierarchy
- Executive Coaching and who do they work for
- When to leave
- Exiting
Succession Plan
- When to Leave
- The Act of Leaving
Eric Brooke's Blog 
1 Comment