Management team in this context is the group of managers and leaders within an organization.

Managers do not cause this drift (in most cases), but managers can absolutely work together to control this drift and ensure alignment. The best organizations I have witnessed are the ones where managers and leaders are aligned, motivated and share common principles and norms.

This write-up presents leadership norms I strongly believe keeps teams well connected and close-knit.

Optimize for the business

Management team’s success depends solely on the business outcome. Make the right local decisions to help the company with its broader priorities. When in doubt, optimize for what’s right for the business. Ask yourself — would you do this if this was your company?

• Nothing matters as much as delivering value to customers (internal or external).

• Balance short term and long term gains. Its hard, but that’s the job.

• Understand why you sell, what you sell, how you sell, who you sell. This will enable better decisions.

• Business impact can be delivered in many ways — revenue growth. cost savings, productivity gains, tech improvement, product foundation, operational excellence, quality improvements, etc.

People and trust first

People is the first P of the three P’s of management (People, Product/Tech, Process). Earn trust of your team, peers and others in the company. Invest time in building strong relationships across the company. Your strong relationships with your peers will reflect on your teams’ relationships with other teams.

• Help build people’s careers — invest time in mentoring, coaching and guiding.

• Provide constant, constructive feedback. Ask for feedback. Offer help to solve a problem other managers are facing.

• Its ok to be vulnerable and candid — others will reciprocate.

• Keep your judgement last.

• Seek advice and mentorship from leaders across organizations.

Continuous, aggressive alignment

Teams lose sight of the big picture or make sub-optimal decisions because they are not aligned. Its natural for teams to focus on their day to day execution — so the manager needs to make an extra effort to stay aligned with other teams. This takes time and commitment (but that’s the job).

• Ensure peers understand your team’s mission and goals. Write them, evangelize them.

• Ensure you understand other teams’ mission and goals.

• Ensure PMs, Design, TPM and other functions always know what your team is working and not working on.

• Ensure everyone knows when and how to contact you/team.

• Pitch your peer’s team to external candidates. Learn to sell the roadmap of the broader organization beyond your team.

Over-communicate

Managers are bearers of organizational and business context that ICs might not have. If everyone on the team can have the same context, decisions making will be faster, direction will be clearer and people will feel a stronger connection to business.

Effective and impactful communication has disproportionate impact on your (and your team’s) success. Cater your communication to fit the audience.

• Treat people like adults, and they will behave like adults.

• Index of being transparent, direct and kind in your communications.

• Diligently use all mediums of communication (sync and async). Especially in a remote world leverage written and other async mediums of communication.

• Remember, active listening is communication.

• Repetition (of the communication) is a necessary evil.

Execute like a flat team

Management structures are necessary to scale with the business — but don’t let them be detrimental to your day to day execution. Build direct relationships across team, org and functional boundaries. Work directly with the people involved — just make sure you over-communicate with relevant people and share context. Executing like a flat team is very critical to foster a culture of quick, bottoms-up decisions.

• Talk to engineers to truly understand technical challenges/solves.

• Talk to other senior and junior leaders to understand their point of views and recognize your blind spots.

• Get facts right, reduce assumptions and eliminate gossip — by communicating straight with the source.

• Help solve problems even if you didn’t create them.

Teams are temporary, competency is permanent

Teams don’t define managers, competencies do. Focus on building competencies — they last forever. Teams and responsibilities keep changing, and competencies keep growing.

• Help with problems outside of your day to day life.

• Engage in opportunities to deliver something individually — people, process, technology or anything else.

• Build a brand for yourself — agnostic of the team.

• Every leadership role is different. Focus on what you want to learn and work towards its.

Hope you have liked this note and found value.

In all seriousness Software Engineering Management is part art, part science of how to deliver business impact, while making sure your teams are happy, while ensuring your personal career growth is taken care of. In most cases its a reflection of your ability to manage stress, and deal with the constant context switch.

In this note, I attempt to provide some structure and categorization to the day to day responsibilities of a software engineering manager. Thinking this through has helped me:

• understand my role better

• plan my priorities better

• provide thoughtful feedback to others

• grow other managers

This categorization combined with this

framework has changed the way I decide WHAT to focus on and WHAT NOT to focus on.

Note: my categorization of tasks below is based on the Pareto principle and definitely DOES NOT represent everything a manager does. The intent is to categorize and simplify, and not define a manger’s role.

Here are three categories:

• People management

• Product and Tech management

• Project management

People Management:

This category of work is the most important, and hopefully most rewarding. Being good in these set of responsibilities can help managers thrive (and survive) the challenging and difficult inter-personal situations.

The following responsibilities represent this category:

• Helping engineers and direct reports identify their strengths and ensure they can deliver impact

• Think through areas of growth for individuals, provide clear feedback and build a plan to help them grow

• Provide clear, constant and actionable feedback — to positively re-enforce strengths, and identify weaknesses

• Build career development plans to help people grow through career and corporate ladders (OMG I said that)

• Build strong relationships with direct teams, peer teams, and key stake holders in the organization. This needs investment and is seldom not appreciated

• Invest time in hiring and onboarding new talent

Product and Tech management:

This category of work can help deliver on the organization’s top goals, and leverage managers’ domain expertise. Being good in these responsibilities allows managers to shorten ramp up time and deliver impact on new teams and jobs.

The following responsibilities represent this category:

• Design, define and help drive the technical vision for the team

• Build strong partnerships with Product Managers and other functions to help identify top priorities for the organization

• Drive alignment and agreement across engineers and other organizational leaders to help justify technical investments, define scope and proactively identify roadblocks

• Improves the technical, operational and security posture of the systems owned by the team

• Foster good design hygiene and lay down principles of product design

Project Management:

This category of work helps drive execution and ensures timely deliver of promises. Being good in these responsibilities helps managers win trust quickly.

The following responsibilities represent this category:

• Drive project management processes to ensure work is well defined, constantly prioritized and delivered incrementally

• Ensure projects are broken down in smaller work tasks, team capacity is modeled well, and team’s work is traceable and visible via project management tools

• Inter-team dependencies are well managed and communicated

• Goals are delivered on time with high quality

• Long term team strategy is translated into actionable projects and tasks.

Closing

A software engineering manager’s job is not strictly confined to a specific definition. I am hoping this categorization of responsibilities helps managers understand their job better.

No matter what — the job definition is always fluid and full of surprises :).

“.. culture is how a company makes decisions, especially when no one is looking.. “

— Ben Horowitz

Culture is that invisible fabric that binds everyone together and provides guidance to make day to day decisions. Every company has its own culture tailored to suit its business needs, and as such the definition of great culture is subjective to the type of business, size of organization, company’s growth phase, etc.

In this note, I would like to talk about engineering culture. Instead of defining what great culture looks like, I will put forth the ingredients that — in my experience — contribute towards great engineering culture.

Of course this is my opinion :)

1. Additive and inclusive:

.. allows fresh ideas, is ready to improve with time and is inclusive of everyone on the team. Without an additive, open mindset a culture can quickly transform into a cult.

2. Focused on people:

.. fosters psychological safety and career progression for individuals — and over-indexes on transparency and humility. I personally believe — when you treat employees as adults, they deliver and behave like adults.

3. Practiced for permanence:

.. constantly demonstrated and practiced by everyone — especially the leaders. Walking the talk is probably the only way to instill organizational behavior.

4. Built on strong core values:

.. values provide a foundation for organizational behavior. As such cultures based on strong fundamental values sustain the test of time and can help weather headwinds. Cultures change with time — values typically stay the same.

5. Fosters bottoms up decisions:

.. individual contributors are closest to the actual engineering problems and have the best insight of solves. Great engineering cultures encourage bottoms up decisions and inverse pyramid management practices.

6. Leverages innovation and automation:

.. encourages innovation and automation, to reduce engineering costs and toil . Constant improvements to engineering productivity retains top talent, which in turn fosters greater innovation.

Steps to instill a new behavior / culture

Here is my take on how I approach this.

1. Set clear expectations — if you want to introduce/alter a behavior broadly, the first step is to exclusively state what you are doing, why you are doing and what is the expected end state. This way others can objectively understand your actions.

2. Walk the talk — lead by example and exemplify the behavior. This is by far the best way to inculcate changes of any form, and super impactful when it comes to behavioral changes.

3. Positive re-enforcement — recognize and reward your team members when they demonstrate the change. Publicly. Re-iterate the why, what and expected outcome of the change.

Most respected tech companies have engineers playing the Tech Lead role. Sometimes accidental, while sometimes deliberate its obvious that these engineers fulfill a specific business need and deliver business impact. Although ubiquitous every company differs in their definition of a Tech Lead. This post tries to codify the responsibilities of a tech lead.

My intent is spread awareness and provide clarity on what should be expected — and not expected of them. I hope this also helps existing tech leads better plan their careers and manage their time

Important clarifications

• Tech lead is not a formal title, but a role an engineer is playing.

• Tech lead is not a promotion or a step up in a career ladder.

• Not everyone has to be a tech lead to grow in their careers.

• Being a tech lead is not a permanent state. An engineer can play the role of a tech lead for a project or for a specific phase of a project or on a team or for a certain situation. Its ephemeral.

• An engineer can be a tech lead of a small area within a team, of an entire team’s scope or of an organization’s scope. Tech lead is a role, and hence not necessarily limited by scope/size.

• Eligibility of a tech lead is agnostic of their level. This is NOT a replacement to engineering rubrics.

Typical responsibilities of a tech lead (TL)

Responsibilities below are typical and not exhaustive nor mandatory.

1. TL is accountable for the architecture, design, code quality, system stability and resiliency of the area they are leading.

2. TL can rely on other engineers to deliver on the results — and not work around the clock to deliver everything themselves. (Being a TL doesn’t mean engineers should give up on work life balance).

3. TL understands the broader context of the team and helps set the technical roadmap for the team.

4. TL is comfortable in scoping complex tasks and projects, and break them down into smaller tangible tasks that can be easily taken up by others on the team.

5. TL (given their own experience, context and tenure) spends time mentoring and guiding other engineers.

6. TL partners with managers to help with decisions around prioritization, execution, work division, sprint planning, goal setting, tech-debt management, etc.

7. TL helps make a team stronger by leveraging (or introducing) frameworks and practices around project management, technical decision making, communication practices, etc.

8. TL continues to contribute primarily via code. Don’t panic!! — see the next section for nuance and details.

What cannot be expected

Given the added responsibilities and accountabilities, a TL cannot be expected to have the similar level of code contributions as the time when they were not playing the role of a TL. Below are some examples on where a TL’s time might be invested in activities outside of coding.

e.g. breaking down a complex idea into smaller, tangible tasks might require a TL to invest a lot of time into deeper thinking, design, POC, research etc.

e.g. helping with quarterly and annual planning, might require a TL to invest time in cross team communications, understanding product roadmaps, writing strategy documents etc.

e.g. to ensure smooth execution, a TL might be asked to spend time in organizing work on jira, clarify the definition of done for tasks, track dependencies, etc.

e.g. to help scale the team, a TL might spend a lot of time in interviewing, onboarding and other hiring activities.

Who typically plays the role of a tech lead

There are no strict level or years of experience requirements for a TL — at least I don’t want to call them out explicitly as it is subjective to situations. However here are certain qualities that help build strong TLs.

1. Ability to come up with mature, thoughtful, scalable technical designs that help the business.

2. Strong sense of code quality and code craftsmanship.

3. A drive to help the success of a project/domain/area of responsibility.

4. Understanding of broader team/company context and how it relates to specific projects within the team.

5. Ability to synthesize technical inputs from various projects/areas to benefit the team.

6. Understanding of the broader architecture, technical decisions and organizational dependencies.

7. Growth mindset and a demonstrated emotional intelligence to mentor and collaborate with other engineers/managers.

Recently I conducted a microclass on a pretty deep and wide technical topic of Microservices with ~1300 registrations! Talk about how Internet is changing the world :).

I have done multiple remote sessions, remote presentations, remote meetings and have learnt something about how to read the remote room. But a webinar is a different beast altogether. There is not much feedback from the audience, no live Q&A, no sense of engagement, no visual cues..

The craft of being effective over a remote session is pretty different — compared to being effective in an auditorium or conference room. I am still learning it. Here are some observations and tips that I believe can help make webinars a little more interesting :

Engagement

You are literally competing with youtube and netflix and instagram :).

The reality is that your audience is going to multi-task and engage themselves in a ton of other activity. It just is. There is an extra necessity to keep the content succinct. I deliberately try to use shorter sentences and crisper language to make it feel like a fast paced session.
Typically a session that feels fast might result in higher engagement.

Visuals

I learn and express better when I draw. In my experience people follow better when you draw. I have now gotten used to drawing on glass on my iPad with the Apple pencil. Using an app that allows changing colors, line widths, etc is an extremely effective tool to ensure the audience is following your thought process.
Definitely, practice and master a drawing tool on your tablets.

Transitions

Expressing complicated technical workflows and concepts is difficult just in general. Being remote and not getting the feedback or real time questions probably makes it twice as hard. Although not popular amongst engineers, presentations that are well done with delightful transitions and animations are extremely effective to ensure the audience understands your intent.

Delivering

Although universally true, the voice modulation, sentence formations, and progressive disclosure of ideas becomes even more critical when you do not have a visual feedback from your audience. Listen (not watch) your own recording to get a better sense of how people hear you.
Podcasters nail this skill.

Reading the room

Well, you can’t really read the room. But let’s not forget you are still trying to connect with the audience. The universal tips of well timed pauses, humor, sharing personal stories still apply.
Trust that people will connect :)

Hope this was helpful!

Ok fine, that was a click bait :).

Organizations are like a complex distributed system with one shared truth — something, somewhere will fail. There is really no self drive mode for organizations.

But I firmly believe there is a way to simplify and automate the mundane day to day tasks of running your org. A combination of data, metrics and signals can help managers notice trends, identify hot areas and enable corrective action. Most managers are juggling a ton of responsibilities and it makes sense to codify-and-dashboard some of the day to day operations. This simplification helps free up time to invest in value-add areas (people management, customer interactions, strategic partnerships, etc) .

Below is a list of possible metrics that you can start measuring and observing to understand how your teams are doing. I am also including certain tools and technologies that can help get that data.

As you must have guessed the underlying principle is simple: If you cannot measure it, you cannot manage it.

Notes:
* Codifying, measuring and building dashboards needs an initial investment.
* Not all data is available, nor easy to capture.

Customer facing metrics

These metrics help understand how customers are interacting with your product and the overall reliability of the system.

1. High severity, high priority customer issues — these are captured via the customer success or customer facing teams. Data should be exported into engineering work management tool (e.g Jira).

2. Critical security vulnerabilities — reported either externally or internal security operations teams. Data should be exported into engineering work management tool (e.g Jira).

3. System availability and operationalization— captured by the Observability stack (e.g. ELK stack) and reported as SLOs and trends via analytics tools (e.g. Wavefront). For availability its best to start with four golden signals: Latency, Traffic, Errors, Saturation. For operationalization best to start with mean time to recover (MTTR) and mean time to failure (MTTF).

Program metrics

These metrics help understand the progress, and monitor trends around delivering important project milestones.

1. OKR progress — progress and confidence-of-completion of most important Key Results. This data can be automatically captured via estimations provided by work management tools (e.g. Jira and Portfolio).

2. Dependency report — reports of incoming and outgoing dependencies and commitments across orgs. Having this data will help facilitate communication and flag possible delays. Jira has enough metadata and types to mark work as a dependency — which further assists in easy JQL.

3. Customer feedback — important customer feedback, dog food results and beta test (or A/B test) results to improve user acceptance and product fits. There are various tools that help capture customer behavior.

Organization health metrics

Although people organizations are complex and can never be completely codified following areas can help get a pulse on the overall working of an organization.

1. Hiring report — insights on the hiring funnel, head counts, and conversion ratios. E.g. #candidates sourced, #candidates inbound, tech-screen-to-onsite ratio, onsite-to-offer-accepted ratio, average time to hire, etc. Modern recruiting tools provide this data (e.g. Greenhouse).

2. Team composition — although this data is not frequently changing, understanding the talent composition and spread is important. Ratio of managers to engineers, ratio of seasoned engineers to young engineers, attrition per quarter, new hires per quarter, team size, etc. A simple spreadsheet with latest data will do the job.

3. Postmortem action items — a well run incident postmortem will result in tasks and actions to prevent recurrence. These action items can be captured on work management tools as a specific type of work. E.g Jira has various types to capture such work.

4. Communication hygiene — a well run organization maintains a drumbeat of communication about project statuses, milestones, business updates, etc. This can be done via various mediums like newsletters, all hands, team meetings, etc. Maintaining a simple checklist of recurring communications per month/quarter should do the job.

5. 360 feedback and surveys —typically initiated by People Operations feedback and surveys help capture the overall sentiment and pulse across the organization. Depending on severity of the feedback, necessary action items need to be followed up. E.g. my last annual survey resulted in three action items on my leadership team to be implement in a six month timeframe. We would follow up on the progress on these action items per month.

Team metrics

Every team is a unit — made up of people, driving certain priorities and operating in a specific model. Although every team is unique, I believe the following criteria can help get a strong sense of how a team is doing. This data is best captured in a simple spreadsheet with every criteria marked as green/ yellow/red and visited every month. As you capture month over month, you will start building trend lines and patterns.

* If a criteria is yellow keep a watch and build a plan to get to green.
* If a criteria is red, invest time asap and implement corrective action.

Below is a snapshot of an actual team’s tracking in June 2019 (gsheet magic and scripts). I group criteria into three categories: People, Priorities and Process. Read more here about why this categorization. .

Code metrics

At the very core, status of codebase defines the engineering culture and calibre. Although not absolute, the state of codebase and engineering practices have a huge impact on software quality and engineering happiness. Following are metrics that provide a good sense.

1. Test coverage — code coverage provided by various forms of tests. This data can be captured during Continuous Integration (CI). My teams have successfully used JaCoCo to capture test data and send it over to the SonarQube for easy reporting.

2. Number of rollbacks — in a CI/CD system a rollback is a result of failures or bugs not caught early in the software development process. Most rollbacks are an indication of a missed testing opportunity, unmonitored metric, unknown scenario etc. Simply tracking number of rollbacks drives the discipline on teams.

3. Release status — for a modern SaaS business the ability to release frequently and reliably is a massive advantage. Reliable and dependable releases provide a strong signal of developer velocity. Tracking a ratio of successful releases to attempts will provide lots of insights. My teams have used Jenkins for CI and Kubernetes for CD.

Conclusion

Most of the metrics mentioned in this blog provide a quick gut check on the overall state of the org. They are meant to be at a high level and invite a deeper conversation about the specifics.

I also want to acknowledge that not all data is available in the same format or machine readable. But that can be your pet project :).

Let me know what you think.

“Management is doing things right; leadership is doing the right things.”
Peter F. Drucker

I love this quote — except right is subjective and ambiguous.

Leadership is hard. So is our ability to correctly define its success criteria and measure its effectiveness . On several occasions, I have introspected and struggled to define my own success criteria as a leader — and realized I am not alone. This post is my attempt to structure and formalize a criteria to measure leadership success.

Note: This note attempts at defining success for a typical software engineering leadership role.

What does a leader deliver?

The first step is to understand what does a leader deliver to the business — an amazing organization. The organization is prime product/deliverable. So the leader’s scorecard is tied to that of the organization. If we break this down further, here are the top criteria to measure a leader’s success:

1. Organizational health

2. Objectives and outcomes

3. Consistent execution

Let’s look at these criteria in detail and discuss the possible metrics. The questions should encourage further thinking.

1. Organizational health

How people feel belonging to an organization determines the overall health of the organization. It’s no secret that people are the biggest asset and healthy orgs disproportionately ensure that the people are happy and effective in their jobs. Some metrics of organizational health:

Career growth: Is the org providing opportunities, and an environment for people to grow in their careers?

Psychological safety: Do people trust their managers and colleagues? Do peer reviews and surveys show a healthy trend around psychological safety?

Talent composition: Is there a good balance of senior and younger talent? Is the overall workforce diverse and inclusive? Is there a stable leadership in place to support teams? How does the succession plan look like?

Hiring and closing: Is the leader actively engaged in hiring? How long are reqs open? What is the interview to close ratio?

Effective communication: Is open, transparent communication encouraged? Are they right mediums and channels for various forms of communication?

Partnerships: Do individuals partner and collaborate within and outside the org? Can people easily cross team/org boundaries to work together — or does process and territories come in the way?

2. Objectives and outcomes

Understanding the broader business context and, then prioritizing the right projects to invest is the leader’s key responsibility. A conscious choice of selecting the right projects — and ignoring the unimportant ones is critical to provide deliver strong business value. Some metrics for outcomes:

Business impact: Are the objectives providing actual business impact? Are they solving a real problem for customers?

Constant prioritization: Are objectives constantly and ruthlessly prioritized to justify the investment? Are there areas which are actively divested? How nimble is the team to react to unexpected demands/situations?

Quality: Are products built with quality in mind? Is there constant re-work? Do the products scale with demand?

Technology: Are the technology choices standing the test of time? Are technology investments attracting new talent? Do the software outcomes provide leverage to rest of the business?

Customer happiness: Are customers happy with the products? Are there planning practices in place to support customer priorities?

3. Consistent execution

Execution truly separates the great teams from rest of the pack. Building the right processes, practices and habits to ensure consistent execution is a key factor of leadership success.

Execution is its own topic, but here are some key pointers:

Managing work: Is the work effectively managed and planned for? Is there a unified practice (e.g. OKRs) to manage and track work?

Operational excellence: Is it easy to track and manage work on a day to day basis? Do teams have practices to deliver reliably over time? Is there clear visibility and traceability of work?

Dependencies: Is there a well defined structure to manage dependencies? Can dependencies help predict product velocity and delays?

Performance management: Is there an established practice and process to manage people’s performance?

Read more for detailed thougts on effective execution.

Conclusion

A large part of leadership is loosely defined and driven by the broader business context. Although abstract, the criteria and metrics in this note probably provide food for thought.

Let me know what you think.

I am sure they will deliver. They always execute well.
— someone in my org about others

This was the story of my life. I was clueless. I didn’t even understand what execution meant. Coz in my mind things were fine!

It took me a few failed projects, difficult feedbacks and lots of guidance before I really groked the meaning of effective execution on teams.. And it took me successfully and consistently delivering over time, to truly understand and form my opinions on good execution.

In this note, I would like to share a some rules and principles, which I believe are the ingredients of effective execution.

Objectives:
Make sure every individual understands the team’s most important objectives and why they are important to the business. Clearly defined objectives are super critical to align everyone — and get started.

People first:
Ensure good talent composition on teams. Establish clear roles and decision-making framework. I follow the DACI model.

Communication:
Communicate progress, gotchas, dependencies, victories and failures transparently and regularly using different channels to customers, stake holders and teams. Communication is the key to building close knit teams.

Foster local, quick decisions:
Teams need the ability to make quick decisions (and revert them if required). Provide a decision tree to every team to help locally prioritize and ensure timely delivery.

Clarity over correctness:
Engineers excel when there is clarity on direction and goals — even if it’s based on limited information. Optimize for speed of execution by providing the much needed clarity.

CAP theorem:
Features, Timelines and Quality form the golden triangle of execution (just like the CAP theorem for distributed systems). Quality is non-negotiable, so pick between features or timeline. My blog here

Plan enough:
Depending on the maturity of product strategy, plan enough to help engineers execute on a day to day basis, but stay agile and nimble to react to consumer demands.

Do less and not spread thin:
Limit number of swim lanes and parallel tracks across the org and team. Ruthlessly prioritize and fund high priority tasks completely. Prefer few but well funded teams.

Definition of done:
Focus on the outcome and establish a consistent definition of Done. Its only done when a real customer problem is completely solved with high quality, reliability, durability, scalability, etc.

Visibility and traceability of work:
Ensure all the work is traceable and visible. Use common, coherent work tracking principles and tools. Optimize for simplicity and ability to report on the data.

Execution discipline:
Split KRs (based on the OKR model) into multiple milestone in a quarter. Every week track progress on every KR and mark them red/yellow/green. Take corrective action on reds, follow up on yellow and ensure success of green.

Hope these are helpful. Would love to hear what you have done to improve execution on your teams.

Gaurav is a VP of Engineering at Confluent - previously tinkered at Box, Microsoft and his own failed startups. He loves a great conversation, and enjoys sports that demand hand eye coordination!

Sign up now so you don’t miss the first issue.

Subscribe now

In the meantime, tell your friends!

Infrastructure requirements are dependent on next set of business scenarios and capabilities. Business scenarios and capabilities are in-turn dependent on infrastructure maturity and availability. Classic chicken and egg.

Although not a silver bullet, IMO dividing infrastructure roadmaps and tasks into categories might help make progress and clearly think about the next steps.

Bonus: also find a questionnaire to navigate the common planning questions.

Roadmap with incremental business value

Basic foundation work:

• This work helps build the base layer of what Infrastructure should be. These are the fundamental capabilities around security, monitoring, observability, config management, build/release, reliability, scalability, durability etc. This is the infrastructure’s version of the twelve-factor methodology.

• For most companies trying to build new infrastructure there is enough evidence of how systems work currently — which can help define the requirements in this category. Companies can leverage existing patterns in the product (e.g rate limiting) to mature infrastructure offerings.

New business capability work:

• This work enables new business capabilities on the infrastructure. This type of work is also hard to visualize, without an active customer or internal org completely dedicated to provide guidance, requirements and feedback.

• Building new infrastructure capabilities without a dedicated customer might result in wrong capabilities being built — and the producer getting ahead of the consumer.

Some steps to help in this area:

1. Customer interviews — figure out what our customers are trying to build and distill infrastructure capabilities required to support. Listen to their feedback and recognize gaps.

2. Industry patterns — understand what infrastructure offerings are built outside across the industry and consider if they fit well for your organization. There are lots of blogs and knowledge articles shared by the big brothers of the valley that can help identify gaps in your infrastructure offerings.

3. Cloud vendors — look at the offerings from vendors who offer cloud compute platforms and look for inspiration. AWS and Azure have a ton of feature sets which can provide inspiration on what a mature infrastructure looks like.

4. Academia — although not exactly relevant, research and books are a great inspiration to direct us in the right direction.

Developer on-boarding work:

Infrastructure and framework offerings often miss out on thinking about the developer experience. Just for fun, try analyzing an image with Google and Azure Vision APIs and check out the difference in developer experience. MSDN is the gold standard for making developer’s life easy.

Investments to ease developer on-boarding is a cross cutting concern across above categories of work. Without an easy on-boarding process and developer experience, any new infrastructure offering provides no incentive for engineers to adopt.

In terms of pure planning, we should prioritize on-boarding as a foundation of what we build. Considering developer experience, as a required attribute of every feature we build. IMO, an amazing developer experience can make up for lacking the last 20% of functionality in your infrastructure offerings.

Common questions to enable planning

Here are some handy questions to ask as you through planning.

• Who is our customer? Does this customer exist today or is it a future customer?

• What is their major pain point? What’s broken today?

• What can accelerate/unlock new development w.r.t developer experience?

• What new features or scenarios are you enabling with your foundation investment? What is the alternative without this foundational investment?

• What’s the opportunity cost of not doing this now?

• Are you fixing technical debt? Can you categorize it for a business justification? e.g. improve security posture, reduce toil on teams, improve uptime, improve manageability, improve customer engagement

Conclusion

There is a certain challenge in planning and executing on multi year projects, and still delivering incremental value to the business. Although not a silver bullet, I am hoping my thoughts help you in your next challenge.

Feel free to share your thoughts! And don’t forget to clap :).

Note: As a software engineer, everything (to me) comes down to an interface. A well defined interface clarifies unknowns, level-sets expectations, and helps plan better. Approaching management with a software architecture lens is my way of keeping my sanity.
Read here about what is an API in computer science.

Why bother defining an API

Managers are accountable to consistently deliver high quality, business impacting results - on time. But they also have a critical responsibility of building and growing their teams for the future. They need to foster an environment where their teams have:
— the liberty to run experiments
— get creative with new ideas
— make micro-decisions independently and quickly
— grow and learn
— understand ultimate business goals

Given this (sometimes) vague nature of the problem, its critical for managers to clearly understand what they need, and succinctly communicate expectations to their teams.

Whats the API?

APIs for managers to set clear, well defined and measurable expectations

The manager provides Objectives and Measurements.
The teams/directs figure out the How and a Plan to deliver on the How.

The API is pretty simple. It is generic enough to work at any level of leadership abstraction. You can use it to work better with your manager as well as to work well with your directs.

Details

Manager responsibilities
Objectives: A manager is in the best position to figure out objectives that can deliver business impact. She can collate information from markets, consumers, future roadmaps, immediate needs, etc. to define WHAT needs to be built.

Measurements: Every objective needs a matching measurement to assure it meets the actual business and consumer needs. Without a clearly defined measurement (or metrics in some situations), objectives are not useful. Measurements provide guard rails to ensure high quality and timely delivery.

Team responsibilities:
How: The How constitutes the actual steps, designs and actions taken to achieve the Objective and meet its Measurements. The How is best understood and figured out by people closer to the problem statement (and in most cases not my their managers). Having liberty of the How helps teams experiment and surface their best ideas.

Plan: Plan is a series of steps the How is divided into, to incrementally deliver the Objective, while meeting the Measurements. Again, people who are figuring out the How, are in the best position to build a plan and execute on it. The Measurements can be used to ensure the Plan is made to deliver the Objectives.

Conclusion:

The API is simple and almost intuitive. However having a definition and structure helps clarify doubts, and most importantly refines accountabilities and responsibilities between managers and teams.

Try it out and let me know what you think!

Unless you build a framework to help you tackle your challenges.

In my case, my framework is made up of three Ps: People, Priorities, Process. These three Ps, in those particular order, help me diagnose most of my challenges and design solutions, remediations as and when needed.

The post below provides quick, handy details about this framework with easy actionable pointers.

PEOPLE

This is the foundation of my framework. Without an iota of doubt, my success as a leader is directly proportional and amplified by the people I work with. People have a disproportionate amount of impact on the success of any organization — and as a leader its only fair to focus on your biggest value add.

Provide psychological safety. There is a ton of research that indicates psychological safety as the number one ingredient of a successful team. A leader’s job is to foster open communication and build an environment for interpersonal risk taking.

Provide constant, clear feedback. Clear, direct and timely feedback is the critical fuel for your team’s acceleration. A leader’s job is to observe behaviors and either nudge towards course-corrections or encourage the positives. Check this out for more on how to deliver feedback.

Show path to achieve personal goals. Everyone has personal goals and ambitions in their careers. If you do not provide a path for people to achieve what they want, or build the skills they need - someone else will. Make your team’s current job a huge learning experience! It comes with a huge pay-off.

Right team, right role. Jim Collins has beautifully put the importance of having the right people on the bus. In addition to keeping a high talent bar, a leader’s job is to identify strengths in people and map them to fitting roles/teams. Don’t worry about org boundaries. Mapping talent to right opportunities is in itself a huge learning experience.

PRIORITIES

Without the right priorities in place, your top talent will be bored. And bored people quit. Stop boring people. Be ruthless in prioritization and help your teams achieve results that matter.

Align projects with business goals. Your team is always excited to make a real impact to the business. Identifying and demonstrating a clear connection between day to day tasks and broader business goals will motivate your team to go above and beyond!

Encourage focus, reduce context switch. Multi-tasking, too much work in progress and context switching will bring productivity to a grind. Reduce parallel play, and rally your teams behind few but clear goals. A common goal for everyone will unify teams and bolster cooperation. Read more here.

Balance mundane and creative work. Every team I have worked on, has tech debt, grunt work, on-call responsibilities, non-shiny work.. Its not going away. But an effective leader can manage and balance this with creative, problem solving opportunities. Measure the mundane work on your teams and balance it with equal or more creative engineering projects.

Provide clear future roadmap. Your team is desperate to know whats next. They are looking for their leader to build a roadmap (even if hazy) to reach to a distant north star. As a leader you might not know where all land-mines are, but you should clearly point to that next valley the team needs to cross!

PROCESS

I used have an allergic reaction to the word process. BTW your team still does.
But when you demonstrate a simple, minimalistic structure and discipline to solve a real, sticky problem, your team will love you! They might still dislike the process, but they will appreciate efficiency it provides.

Project planning tools. You and your team should really care about tracking current work, visualizing progress and identifying bottlenecks/dependencies. Invest and introduce simple tools that are common across the org, easy to use and not on the critical creativity path. Keep it simple, keep it useful.

Build clear communication channels. If your org has n people, you are looking at n * (n-1) / 2 communication channels. Unless you like to repeat yourself every hour, build a strategy to scale yourself to tackle this problem. Leverage people across disciplines to convey your thoughts. Allocate time for open office-hours. Incentivize a culture of written communication - internal wikis, regular newsletters, meeting notes, well documented design trade-offs, etc.

Release frequency and cadence. If you are a software business, invest in a CI/CD system and improve your org’s ability to ship products in small, incremental iterations. Shipping frequently will prevent pile-up and will improve your ability to control the production flow. As a leader your first job is to prevent wastage. Check here for more inspiration.

Closing

Every leader has their own way to manage and scale themselves. It took me a while to figure out what exactly works for me. Ask me next year and I am sure I might have some changes. Continuous improvement!!

Would love to hear what you think!

PS: In future notes, I will be expanding a lot more on each of the three Ps. Stay tuned!

Engineering management does not escape from its golden triangles. The fun however is that there are a ton of iron triangles out there to guide your management decisions. As a manager the trick is really to pick what works best for you.

Influencing factors

There are multiple factors when considering what kind of iron triangle works for you. Here are some factors that you might want to consider (not exhaustive):
— Do you build a product or offer a service?
— Do you ship frequently, continuously or on a pre-defined single date?
— Are the engineering teams stable or constantly changing?
— Is the budget fixed or flexible?
— Is your product mandated by any regulations and compliance needs?
— Do you have a culture of rapid experimentation or consistent product development?

My factors

My decision making has been shaped by these foundations:
— My teams ship infrastructure services and frameworks
— We ship software continuously, at will
— Other teams rely and build on top of what we deliver. We cannot break anyone
—Engineers on teams usually remain the same for multiple quarters
—We believe in failing fast and changing things if things do not work out

What I choose

Considering the factors that influence my day to day, my iron triangle is composed of Quality, Features and Timeline.

My iron triangle for effective engineering and happy teams

Quality: Quality of design, quality of code, quality of user experience, quality of maintainability and extensibility of the product.
Features: Number of features to be shipped, number of user scenarios to be addressed, breadth of functionality to be supported.
Timeline: The final calendar date to deliver.

My iron triangle comes with these defaults:

IF you want all the features with high quality — you need to be flexible on the exact timeline.

IF you want software to be delivered on an exact date in future — you need to be flexible with what features will be included.

IF you want all the features possible and on an exact date — well, quality will suffer and we do not want to build or deliver low quality products.

In my iron triangle, the Quality corner should be non-negotiable. This means only the number of features and timeline will be flexible.

Why?

There are multiple factors that make high quality software. Some are well-known, while some not so well known:
— features prioritized to provide user value
— solid engineering practices around documentation, user studies, customer feedback
— well designed architecture
— modular code
— testing hygiene with appropriate unit tests, regression tests, end to end tests, etc.

Most importantly, de-prioritizing these quality factors have a huge snowball effect in the product’s later life. This snowball is harder to manage and costlier to fix (or get rid of). A product without the focus on quality in its early days might have some of these amazing properties:
— features users hardly care for, but still pay for (and hence start looking for alternatives)
— shaky software foundation which does not allow for easy composition
— bad designs in code which do not scale well and hence need to be rebuilt
— code bases which no-one wants to work on
— more time being spent on fixing and fighting bugs than creating anything new

In the long run, the cost of fighting an ill-designed product or an unwieldy code-base is much higher than the one you pay upfront, to focus on quality and engineering hygiene.

How does your iron triangle look like?

My father, a mechanical engineer, was VP of Quality Control and Process in the manufacturing industry. Growing up, I often heard about Six Sigma, ISO certifications and process improvements. Its only after managing teams for years did I actually appreciate and implement his teachings :).

For this post, I am taking inspiration from the principles of Maintenance and Six Sigma. I have adopted these principles to explain various phases of software engineering management. These phases represent the maturity and effectivity of management teams:
- Reactive Management.
- Preventive Management.
- Predictive Management.

What do I mean..

If businesses want to be ahead of the curve, they need to see the curve before the competition. This needs continuous, deliberate vigilance and pro-active action. Engineering management is no different. Leaders need to invest time and energy to be offensive in their corrective actions and stay ahead!

Phase 1 — Reactive Management
Young, inexperienced management usually begins here. Corrective action is usually an after effect of failures. Depending on situations, there are various reasons why this can happen. In the nascent stages, thoughtful management is often missed with a mad rush to deliver products and catch up with delivery expectations.

Most of the reasons can be attributed to lack of experience and lack of thoughtful prioritization.

Corrective action taken too late, after catastrophic events

Simplified practical examples of reactive management:
- simplify the product UI and interactions after product engagement falls.
- implement code quality practices after constant production failures.
- kick off recruiting efforts after significant attrition.

Phase 2 — Preventive Management

A majority of well run management teams are at this phase. Corrective actions and improvements are swiftly implemented, but after early failures. Although late these actions prevent wider potential loss. At this phase, management teams have a good understanding of short term and long term gains.

Although mostly reactive, the speed of recognizing a pattern and quickly taking corrective action helps control the blast radius of the original problem. To have sustained success, management teams need to build the following strengths:
- recognize patterns from minimum available data points: this helps understand the root cause of early catastrophic event.
- implement decisions quickly and broadly: this helps accelerate corrective actions and quickly regain control.

To achieve the strengths above, organizations need effective communication and change management structures in place.

Corrective action taken swiftly after noticing a catastrophic event to prevent further damage

Simplified practical examples of preventive management:
- implement strict security review processes after security flaws are reported by the white hats.
- invest in simplifying code bases and architectures, after developer productivity has slowed down.
- automate critical data center operations and processes, after engineers burn out from long fire-fighting nights.

Phase 3 — Predictive management

This phase of engineering management is partly inspirational, and needs continuous, diligent effort to attain. In this phase, management teams leverage their prior experience, mine past data on people, projects, and technology to build patterns, and use their judgement to practice continuos improvement of the organization. This in turn avoids some of the problems other phases experience.

In this phase, the motive is for leaders to be able to predict challenges, problems and potential threats and implement corrective actions immediately. Instead of acting after a catastrophic event, leaders develop a muscle to notice early signs of failures and act fast.

To get to this phase of management, managers need to:
- Clearly define success criteria and measurement metrics for their teams.
- Constantly collect and monitor the key success metrics.
- Invest in regular, ongoing employee feedback.
- Understand and retrospect deviation in the key metrics and quickly implement corrective actions to fix them.

Corrective action taken predictively to prevent any failures. Managers leverage their experience, judgement and past data and patterns to time this well.

Simplified practical examples of predictive management:
- Re-structuring and organizing teams to prepare for upcoming business requirements and demands.
- Developing and investing in growth of emerging leaders to help future-proof org leadership.
- Constantly measuring and balancing shiny-feature-work with grunt-maintenance-work to prevent employee burn-out.
- Modernizing the software stack to prevent system rot and improve go-to-market velocity.

Food for thought

Although the three phases are listed in order of improved management effectivity, some teams might make deliberate choices of how they operate. Composition of the team, maturity of product, market demands, competition, might demand different management techniques.

This article is a great read about deliberate management choices.

However our actions don’t always match our intent. We may want to deliver feedback which is constructive and helps bring a positive change, but what we actually deliver might not help that cause. I have experienced this problem personally, as well as on my teams. All good intentions, just not thought through and constructed well.

Here are some examples of bad feedback:
“Wrote bad quality code!” ….
“.. is aggressive and defensive.” …..
“.. and favors other team members”

Dissecting feedback

If I were to dissect feedback into parts based on intentions, here is what I would see.

Dissection of a typical feedback

Almost every feedback has a factual start and an emotional end-state.
We experience a situation which impairs our ability to do work. We witness something that makes us feel uncomfortable. We notice actions that are against our beliefs…
We get into a fight or flight situation.
We generate strong feelings and emotions.
We develop judgements.

If we deliver feedback full of emotion and judgement, and lacks underlying facts or any constructive action, we cause more harm. This feedback does not help the person it was meant for. Also, its worse for you because the situation you disliked might not improve at all.

Constructing good feedback

Construction of good feedback

Good, constructive feedback can be divided into four parts in order of importance:
Facts: Focus on data and situation. Build a timeline if necessary. Think objectively. What happened? What was the situation? What was the result? How did the situation impact the team?

Requests: What can this person do to help achieve your common goals? How can your work environment get better? What can this person not do?

Feelings: How does the situation make you feel? How is this impacting your work? How does this affect your morale, psychological safety?

Judgement: Do you need this at all? In most cases, its best to not throw a judgement :). The challenge is to differentiate between feelings and judgement. But, if there is any judgement, keep it last!

Example

Gaurav slowed down team’s progress. He was late to deliver his tasks. Now I feel obligated to put work harder to make up for lost time.

Lets analyze this feedback:

Gaurav slowed down team’s progress — This is a judgement.
He was late to deliver his tasks — No clear data and facts.
Now I feel obligated.. — Feelings.

This feedback does not help Gaurav understand what was wrong, what is expected of him and how can he improve the situation… Lets try to put a structure around the feedback and run through a thought exercise. This will help make it actionable.

Facts:
Project FooBar had tasks A, B and C. Task B and C were dependent on task A. A was assigned to Gaurav. B and C were assigned to others. Task A was delivered one sprint later than its original delivery date. Thus dependencies B and C were subsequently delayed.
Project FooBar was delivered one sprint late.

Requests:
I request Gaurav to be aware of the dependencies of his tasks. I request Gaurav to communicate delays early and ask for help from his team mates.

Feelings:
Not delivering tasks on time makes me feel unproductive. I feel like I am not doing my best.

Judgement:
Maybe Gaurav lacks expertise in technology needed to finish task A.

After this thought exercise, we have a better sense of what impacts us and what Gaurav can do next.

In conclusion

Feedback is difficult to deliver, but extremely useful. If we put a little more thought on how to structure it, focus on facts and requests for constructive corrective action, it will make help everyone involved.

And of course, resist your judgement!

Ever since then, this group has moved mountains and keeps delivering on all its goals. The technology we are building demands a dedicated story, but what really stands out to me, are the other invisible victories that helped mature the entire organization. I put these victories in three buckets: Technology, People and Process.

Maturing an organization

Industry best practice recommends Conways law when designing and forming organizations. Once formed however, the growth and maturity of an organization depends on a multitude of factors and principles.

In our case, the foundational principles for organizational maturity were Technology, People and Process. These principles although separate, are not really independent. Growth on any one of them, had an eventual causal effect on others, resulting in an amazing resonance - which in turn re-fueled an overall organizational growth.

Positive re-enforcement cycle for organizational maturity

As we formed this new group to focus on new technology, we simultaneously invested in specific people roles and processes — and its paying off!

Technology

In an age of fast moving and abundant technology choices, we chose to focus on product velocity and engineering productivity over the new hotness. A boring stack is a real pleasure, especially at 2am when you are debugging a live issue.

Right from the beginning we mandated every component of the architecture to be self service - with useful documentation, dedicated on-boarding support, well defined contracts and SLAs. Teams built centers of excellence around their work, and publicly showcased performance and quality metrics. We invested in building (or improving) rapid experimentation environments and continuous delivery pipelines.

Our technology choices and design decisions created a culture of accountability, discipline, rapid experimentation and trust.

People

Without a doubt, people provide the highest ROI. We started the program with a handful of foundation engineers and then built teams around them.

We re-worked our hiring and on-boarding strategies. We focused on hiring and up-leveling with right talent — and not just more talent. The intent was to develop catalysts for a longer, future acceleration of the organization. Going through a rigorous, thorough engineering regime and working on bleeding edge technology forged everyone with fire.

We introduced lean decision making models, emphasized continuous improvement and encouraged candid feedback (technical and personal). This resulted in broader collaboration and an attitude of challenging the status-quo.

Process

Process usually gets a rolling-eye. However when done right and with clarity of the problems to solve for - improves productivity across the board.

With time, teams tend to diverge (drastically) in how they operate. Our audacious goals needed teams to be highly aligned, but maintain loose coupling. We re-visited our agile practices and emphasized on teams’ ability to succinctly define success criteria, flesh out unknowns, and understand engineering velocity. We embedded (part-time) agile coaches in teams to fine-tune practices and simplify inter-team dependency management.

A tighter and predictable work hygiene helped everyone be grounded with the challenges and unknowns. Our process investments helped design and plan with a consumer back perspective, and focus on delivering incremental user value. This in turn resulted in higher people engagement.

Looking forward….

We have long way to go and a ton of challenges to solve. Drastic architecture changes need bake time before they can deliver 10X value.. But what already feels great is the org’s momentum and people’s attitude to do things right! And that is the foundation of every high performing organization.