A framework I codified to help me manage and scale our Software Engineering team at VideoBlocks. If you're in engineering management, whether at a small startup or larger company, you'll likely find some useful tidbits that will help you on your journey.
2. The Engineering Management Framework
People
Processes
Technology
Culture
+ Hiring / talent standards
+ Talent development / mentorship
+ Organization structure
Sub-areas Explanation / details
+ Eng teams live and die based on talent / tendency towards action
+ Grow eng skills internally via L&L’s, mentorship, pair prgming, etc
+ Create well-defined roles & responsibilities that fit team member
talents and aspirations
+ Roadmap Development
+ Sprint Planning & Req Gathering
+ Dev → QA → Deploy pipeline (GSD)
+ Bug / issue reporting & resolution
+ Product leads with heavy input / buy-in from Eng team
+ Crux of making sure all teams are on the same page
+ Maximize throughput while minimizing tech debt / bugs
+ Ensure we address urgent customer issues ASAP and provide
mechanism for reporting bugs
+ DevOps / infrastructure
+ Front end architecture
+ Backend languages / architecture
+ Tools
+ Ensure uptime and agility
+ Create a great customer UX that’s maintainable
+ Create maintainable backend codebases to support your UX
+ Foster productivity with “right tool for the job” approach
+ Autonomy, Mastery, Purpose
+ Psychological safety
+ Bottoms up and top down (provide a
vision / empower the team)
+ Ensures the team is engaged and minimizes turnover
+ Psychological safety is THE most important ingredient in team results
+ Culture has to come from both directions to succeed
Details to follow on each sub-area
4. People: Hiring / talent standards
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Sourcing candidates
+ Hiring quality engineers is absolutely critical to building a successful team.
+ Hiring should be a top priority for leadership when you have open roles
+ Sourcing quality candidates can be tough; leverage platforms like Hired.com and Angelist, encourage the team to
send referrals, and use recruiters as a last resort
Interview process
+ Three rounds with a HW problem b/w 2nd and final seems to work well; keep the pre-final round screening process
the same for all candidates to ensure consistency
+ Make sure the candidate writes code!
+ Having a fairly consistent interview team is important but it’s also good to give people a “step-up” opportunity by
participating in the process; make sure to balance these competing priorities
+ Team might be on the fence about some candidates; figure out a strategy for handling this ahead of time (additional
homework, always no, etc)
Other considerations
+ Promote internally where possible - try to avoid hiring above someone unless it really makes sense
+ Culture is super-duper important so reject candidates for cultural reasons
5. People: Talent development / mentorship (1/2)
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Review process
+ Developing talent internally is super-important and should always be a consideration when making decisions
+ Regular review processes and formal / informal mentorship are both necessary
+ Ensure some sort of x-team knowledge sharing occurs on a regular basis (iron sharpens iron)
+ Review process should take place every six months to ensure people are always getting feedback they need
+ Align on a structured framework & process ahead of time that enables a holistic approach with 360 feedback
+ Engineers should be assigned mentors who will be in charge of collecting feedback and writing a fair review
Promotions
+ Regular review process provides an easy forum to review performance and assess whether or not someone is
ready for a promotion
+ Generally, a promotion should recognize a role someone is already playing (though exceptions can be made)
+ Should generally be agreement amongst engineering leadership on the promotion; strong dissent likely means the
person isn’t quite ready yet
+ Promotion recommendations should be provided to the CEO for blessing though it’s mostly “rubber stamping”
+ Comp is a bit tricky. Let’s review in person.
Performance issues
+ Performance issues should be addressed fairly quickly by someone’s direct manager
+ If problem persists, bring it up the chain to discuss potential options; if performance is bad enough to lead to
termination if not corrected, make sure to mention it to the Management Team
+ Head of Engineering should have a very frank conversation with the person. Perf. improvement plan should be
kept relatively short, 2-4 weeks, to be fair to all parties involved. Probation period afterwards of 1-2 months to
encourage continued better performance assuming they’re not let go.
6. People: Talent development / mentorship (2/2)
ENGINEERING MANAGEMENT FRAMEWORK
Mentorship
+ All engineers should have a formal mentor who’s in charge of directing their development over the long term
+ It’s also useful to encourage an informal mentorship network where strong engineers can provide mentorship to any
engineer who’s interested
Knowledge sharing
+ Encourage all engineers to share their knowledge with the rest of the team through some mechanism, e.g., “Lunch
& Learn”, documentation, Slack, email, etc
Leadership training
+ Provide leadership coaching, guidance, and training to engineers who are interested
+ Consider future organizational needs and ensure internal talent will be prepared to help address them
7. People: Organization structure
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Designing an
organization
+ Finding the right people for roles & responsibilities makes everything much easier
+ Org structure forces people into certain mindsets so design it carefully
+ First, map out what needs the team has (e.g., someone needs to own DevOps, QA, Acquisition, etc)
+ Next, try to group related stuff together where possible so that you don’t have a bunch of 1 engineer teams (e.g.,
maybe we have a team called “Strategic Tech” that does DevOps, Data, and Search stuff
+ Adjust the above if necessary for talent constraints and/or individual development needs
Other considerations
+ Make sure the org structure aligns with business needs and generally “makes sense”
+ Don’t change it too often if possible
+ Be flexible and design it so most engineers can change teams if necessary → bus factor = 1 is very scary
+ Consider development trajectories and emotions
+ Keep great teams together if at all possible → research suggests that it takes time for teams to “get in a rhythm”
and they’re much more productive when they do
9. Process: Roadmap Development
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Considerations
+ Long-term product roadmap essential to developing a great product
+ Mostly Product Management’s responsibility though Engineering should be heavily involved for input
+ Business rationale: Double check that the roadmap makes sense from a business perspective
+ Ensure that timelines are reasonable (e.g., engineering leads should do high level LOE estimations)
+ Tech debt: Ensure that it accounts for technical debt cleanup / other behind the scenes tech stuff that product may
not be as aware of
+ Think about how it might influence Engineering AMP / team morale
+ Think about how it might influence team structure
+ Consider whether or not it affects the hiring plan
10. Process: Sprint Planning & Req gathering (1/2)
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Requirements
gathering
+ Gather requirements, estimate effort for tasks, and prioritize stuff in the short term
+ Product takes lead on the “what” though we as engineering have a heavy responsibility to help prioritize and provide
an active input where we can do things more efficiently; ideally there’s a well-groomed backlog
+ Product should take lead on pulling in other stakeholders
+ Make sure we’re getting good enough requirements
+ Ideally engineers can point out when requirements are clear enough and problem solve with Product Mgmt to
resolve the issues
Handling problems
+ Unclear requirements: It’s best not to commit to something in a Sprint when the requirements aren’t clear enough to
deliver; however, high priority situations will require that we be flexible
+ Uncertainty around an ask: If you know something could come up in the future, book Sprint time (e.g., 360/VR ask
for NAB) even if it’s a bit vague; with a well-groomed backlog we can keep chugging even if we don’t end up
executing against the vague ask
Estimation
+ Let the entire team participate in point estimation where possible; it builds buy-in and ensures that the team doesn’t
feel like it’s just taking orders as much
+ Try to keep point estimations constant over time
+ Slowly but surely increase point allocations / eng / day as long as you keep delivering though make sure this isn’t at
the expense of work/life balance; you genuinely want the team to get more efficient
11. Process: Sprint Planning & Req gathering (2/2)
ENGINEERING MANAGEMENT FRAMEWORK
Retrospectives
+ Make sure to do retrospectives every Sprint so the teams can continue improving
+ What went well, what can be improved
12. Process: Dev → QA → Deploy pipeline (GSD)
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Development
+ Core engineering process that delivers new functionality
+ Where Engineers (ideally) spend most of their time!
+ Minimize meetings and distractions: Ideally, engineers should spend most of their time developing features
+ Includes Design and Code Reviews, which are crucial to building a great GSD pipeline. Otherwise you’ll leave
massive amounts of tech debt in your wake
+ Fairly tightly coupled with some tech choices (Git/GitHub for source control)
QA
+ TDD and a TDD culture are a must!
+ Unit tests, integration tests, Selenium / end-to-end tests
+ Tests should be fast!
+ Devs should do manual testing before handing it off to formal QA
+ We should have a fairly strong manual QA team
Deploy
+ Ideally our test suites are good enough for us to do Continuous Integration if we want
+ Should have push-button deploys
+ Rollbacks should be super-simple
+ Anyone should be able to deploy but there should be people available to help fix problems if they arise (e.g., no
middle-of-the-night deploys when you’re the only person awake)
13. Process: Bug / issue reporting
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Reporting
+ Bugs and other issues are certain to occur
+ We need to have a process for fixing them and communicating appropriately with stakeholders
+ There should be as few channels for reporting bugs as possible while ensuring that urgent issues are always ID’d
and resolved quickly
+ It should be easy to report bugs / issues and the “how” should be easy to remember
+ Non-urgent issues should be kept in a backlog of some kind
Fixing issues / bugs
+ Standardize a process for addressing bugs / issues that everyone aligns on. Might be part of Sprint planning, might
be it’s own process (e.g., Dev Requests)
+ Ideally all engineers help fixing bugs / issues -- don’t create two “classes” of engineers (coders and bug-fixers).
15. Process: DevOps / Infrastructure
ENGINEERING MANAGEMENT FRAMEWORK
Overview
DevOps
+ DevOps should enable the team to move quickly and ensure our products are available for our customers
+ DevOps is a strategic asset b/c it lets you move faster than the competition when done well
+ Ensure that most of the team can do at least some DevOps and understands the basic concepts
+ Makes sense to have a specialist or two once the team reaches a critical size
+ Docker rules!
+ Remember, the goal is to leverage DevOps to move fast!
Infrastructure
+ Our infrastructure should support our current needs and be prepared to scale to 10x our current volume
+ Make sure it’s flexible for new demands even within the 10x volume
+ Make sure it’s not slowing you down or costing too much
+ Know the architecture! Current architecture leads to a lot of business constraints that you have to be able to
communicate to the executive team.
+ Have a plan for the future! Even within the 10x volume constraint our infrastructure will need to evolve to support
future needs (e.g., OneAccount)
16. Process: Frontend Architecture
ENGINEERING MANAGEMENT FRAMEWORK
Overview
ReactJS / Flux
+ Our frontend architecture should support an amazing customer UX and also be maintainable
+ ReactJS / Flux combo seems to be the best option at the moment
+ The future! Easy-to-understand design pattern makes for an extremely flexible way of building web apps
+ The one downside (thanks to Kim for calling this out) seems to be CSS transitions
Everything else
+ The past
+ We should eventually migrate to ReactJS / Flux where it makes sense
17. Process: Backend languages / architecture
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Backend languages
+ Ideally, we should use the right tool for the job
+ Transitioning backend to microservices will enable the business to move faster
+ Good options for VB: PHP, Node, Scala
+ Many other options are ok depending on the circumstances
Microservices
+ Backends for frontends with microservices
+ First build a monolith then split out services once you’ve scaled (code well initially and this is much easier)
18. Process: Tools
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Tool selection
+ Super important to choose the right tools for the job because they dramatically affect productivity
+ Version control: Git, GitHub, and SmartGit
+ IDE: anything JetBrains
+ Use a debugger!
+ CircleCI for unit testing
+ Not sure for Selenium testing
+ Sequel Pro (Mac) for MySQL
+ Sublime Text for editing random txt docs, some code
+ BeyondCompare for FTP / file diffs
+ AWS!
+ Docker Hub
20. Culture: Autonomy, Mastery, Purpose
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Autonomy
+ The secret to building a happy, motivated team; HUGE for retention!
+ Straight from Daniel Pink’s “Drive”
+ The power to make impactful decisions in your day-to-day work
+ Improves autonomy: building new stuff, flexibility to select your projects
+ Decreases autonomy: processes, just following instructions
Mastery
+ Continued growth and development
+ Improves mastery: learning new technologies & skills, solving hard but tractable problems
+ Decreases mastery: simply doing the same thing over and over again
Purpose
+ Connecting work to a larger cause than yourself
+ Improves purpose: delivering value and Getting Shit Done (GSD)
+ Decreases purpose: impossible problems, working on inconsequential stuff
On all of these, what matters is how teammates feel,
not necessarily the facts of the situation
21. Culture: Psychological safety
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Psychological safety
+ Psychological safety is THE most important aspect to succeeding as a team
+ Team bonding, building trust, and having “good” conflict that doesn’t disparage people are all important aspects
+ The shared belief that the team is safe for interpersonal risk taking. In psychologically safe teams, team members
feel accepted and respected.
+ Benefits are manifold: improves likelihood that innovation will be successful, increases amount team members
learn from mistakes, boosts employee engagement, improves team innovation
+ Two key leadership aspects help create it: participatory management and inclusive management
+ Two aspects of a team that really help improve it: well-defined team structure where team members understand
their roles; strong relationships between cohesive team members
Build strong
relationships
+ Strong relationships are key to psychological safety so it’s important to ensure they exist on the team
+ Focusing on building trust / ability to have productive conflict is crucial: consider reading “Five Dysfunctions of a
Team” together
+ Encourage team interactions outside the office such as offsites, happy hours, hanging out, etc
+ Family-like atmosphere
Encourage feedback
and growth
+ Encourage team members to seek constant personal and professional growth
+ Encourage team members to provide each other feedback on a regular basis
22. Culture: Bottoms up and top down
ENGINEERING MANAGEMENT FRAMEWORK
Overview
Top-down
+ Culture must come from the top-down from leadership and be strongly supported bottoms-up by team members
reinforcing the culture
+ Team leadership needs to formally establish the culture by defining principles and values for the team
+ Leadership should also vocally support Autonomy/Master/Purpose and Psychological Safety
+ Be consistent in rewarding behavior according to principles
Bottoms up
+ A lot of bottoms up culture happens through a combination of hiring the right people, rewarding behavior consistent
with cultural principles, and supporting team AMP
+ Encourage the team to “own” culture and provide an environment where that’s possible
