11 Articles to read today if you are an Engineering Manager

Engineering Manager Reading List #4

OKRs: The Magic Key to Strategy Deployment

“So you’re passionate? How passionate? What actions does your passion lead you to do? If the heart doesn’t find perfect rhyme with the head, then your passion means nothing. The OKR framework cultivates the madness, the chemistry contained inside it. It gives us an environment for risk, trust, where failing is not a fireable offense. And when you have that sort of structure and environment, and the right people, magic is around the corner.” — Bono, U2

Strategy is basically about answering 5 questions: What is our winning aspiration? Where will we play? How will we win? What capabilities do we need? What management systems are required? (“Playing to win” by Roger Martin).

Done right, strategy defined this way at the enterprise level should also cascade down through the organization to divisions, business units, functions, teams, and — ideally — individuals. Having the entire organization conceptually aligned to key choices is a powerful step toward dominating a given playing space.

OKRs come into play to answer a sixth and really differentiating question: How will we effectively deploy our strategy, how do will act on our choices? This is a critical step, which, if forgotten, leaves any strategy to be not more than a shiny set of slides.

OKRs is about setting goals that provide measurable milestones and deliver concrete results that enable them to know whether and to what degree their strategy is on course and working. These goals should cascade in the same way as the strategies they support.

This article gives some good overview and examples for how to use OKRs to translate strategy into objectives and objectives into projects and work streams.

How to be a Career-Changing Mentor

Learnings from First Rounds mentorship learning program. Questions: How do you know when to share your own perspective and when to listen? How do you plant the seed of trust, then tend that relationship over time? As a mentor, how did you approach giving advice to your mentee? What tactics or questions did you find most useful to help target your support? What did you learn about effective mentorship over the course of the program? What’s something you’d do differently, or a tactic you wouldn’t try again?

Principles of meaningful mentorship:

• Save the troubleshooting for later: Focus on trust and relationship building first. Great mentorship is not about tactical problem solving — it’s about supporting the person holistically.
• Loosen your grip on what it takes to make mentorship “work”. Mentors need tp let go of their ideas of what success looks like. Each mentorship relationship will look different depending on the pair.
• Figure out what kind of mentor you are and tailor your advice accordingly. Mentors who are much further ahead in their careers are going to be terrible on tactics. But they can help you peer around corners that you don’t even see coming. You don’t want to serve up career platitudes if they’re looking for targeted go-to-market tactics.
• Be sure to listen for the subtext. Mentorship is all about meeting a mentee where they’re at. You have to listen to the challenge that they’re overtly telling you about, all while hearing what they’re actually saying. We often think that the challenge that we’re articulating is the root of our problem — without understanding the full landscape that the issue sits in.
• Remember that most of mentorship is getting your mentee to focus on the right problems. Nine times out of 10 the issue isn’t about finding the optimal solution, but rather ensuring people are focused on the right problem in the first place. Why does your mentee feel that this issue is an important challenge to prioritize? What’s the personal impact of this challenge?
• Hand down your hard-won context. Frame your feedback in three categories: Broad information experienced or observed in your career. Personal stories. Frameworks. Provide your mentee with context on industry norms — it makes a big difference. Just saying, “It’s okay, this happens all the time and isn’t the end of the world,” can have a huge calming effect.
• Skip the instructions — tell stories and share resources instead. So much of what time and experience gives is familiarity with process and documents. Taking the time to share them with your mentee can be invaluable.
• Hand out fishing rods, not fish. Avoid recommending a solution to a problem. Alternatives are many: Share anecdotes that are similar to your mentee’s experiences, since these are more likely to be remembered and re-applied. Recommend broad principles that apply to the situation that can be reused in future situations. Share trade-offs of the different possible solutions to build up the mentee’s toolkit. They need to understand how to involve themselves in finding answers instead of just doling out for advice.
• Give the gift of confidence and validation. Ask the right questions to reinforce what they already know.
• Help your mentee practice checking for blindspots and surveying stakeholders. Self-awareness is one of the most important qualities a leader can have. And the third-party perspective of a mentor helps you hone it.
• Recognize emotions, encourage authenticity and create space for self-care. The most important aspect of getting mentorship is how it’s a form of personal care. For someone early in their career at a fast-growing startup, balancing immediate needs, future goals, and the needs of the business can feel really difficult and overwhelming. As a mentor, you create space for your mentees to put down those pressing business needs and instead pick up their own goals and talk about themselves. It’s an important piece of the puzzle for overall growth and development. Ask questions such as ‘How does it make you feel?’ and ‘What do you think is holding you back from saying what you want to?’
• Practice your management skills and treat mentees like they’re on your team.
• Ask those questions to keep the conversation flowing: What do you need right now? If you clone yourself, what would your clone do, what not? What else is on your mind? What are excited about doing in the future? What would be the worst case scenario if you dropped this item entirely? What are your constraints? What’s getting in the way of your learning? How would you perceive this challenge from the outside looking in?

7 things you don’t know about agile architecture

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change — Grady Booch

Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other — Ralph Johnson

Good architecture can be described with the following criteria:

• Change (incl. adding new features) should not be expensive
• It should have a feedback loop. It’s a cycle. Architecture is a hypothesis (an expression of an idea), that needs to be proven by implementation and measurement .
• Make it agile and lean as thinking that way emphasizes teamwork and response to change. Lean focuses on the elimination of waste and improvement of flow. Sustainable agility requires good architecture; fast initial development does not — these are often confused.
• Aim for sooner rather than faster.
• Work in smaller teams to produce good software. The bigger the team, the harder it is to be flexible. Having more people on a project does not mean that the project will be completed sooner. There is no linear correlation. Bigger teams require more communication. When there are more points of communication, the original message can be lost or become inaccurate between the source and receiver.
• Do not use speculation to add extra complexity to the architecture. Use speculation and future requirements to decide between design alternatives. Use past change to forecast future change etc. Really structure the system with respect to rate of change and (un)certainty.
• Always think of 3 things that might go wrong. “Nothing is more dangerous than an idea, when you have only one idea. Try to propose three things that might go wrong and use these scenarios to validate your hypothesis. If you can’t think of at least three things that might go wrong, then there’s something wrong with your thinking.

Sustainable development is development that meets the needs of the present without compromising the ability of future generations to meet their own needs — The Report of the Brundtland Commission

Maintaining productivity as engineering teams scale

Often, when software engineering teams grow beyond a point, you find that productivity (defined as the amount of work produced per person) dips. Any feature addition seems to take forever. This is always true. So, are you doomed? Is it a waste to even try and add people to an engineering team?

The answer is no, when you understand to organize for scale. It is even possible to accelerate growth and to increase velocity in proportion (or almost in proportion) to the increase in team size.

First of all the pain of growth is mostly not at all about technology, but about people and how they work with each other in the overall system: reviews, processes, team structures etc.

Scaling engineering teams is all about maintaining the startup mode of working where people collaborate, innovate at a fast pace:

• Technical Debt
  You need to build a trusted partnership between business and engineering to successfully deal with tech debt. Show the value that you are adding. which is typically the increase in velocity in the future and increase in flexibility. There is also product debt, which is about bad feature decisions — as engineering be aware of those.
• Distractions for Engineers
  Engineers in most companies spend less than half their time in what they used to do: build features. Now, they are spending a lot of time dealing with production issues, customer issues and sudden high-priority requirements. So you have to design for making those realities less painful: Is a bug really a bug? Is the ops team big enough? Does your dev process allow for feature changes without pain?
• Change for old hands
  Because of the depth of context and knowledge acquired in the early days, the presence of those early engineers is much more valuable than you probably think. Their sense of loss of control is natural — you should hear them out and spend time with them, talk to them and align them to the new realities, one of which is that shaping features is not their job any longer. In the end, it’s all about communication. Just that a larger team needs more of it. Things like customer context, business context and user context must accompany the roadmap. All hands meetings and team meetings may seem a waste at first, but when you look at each individual engineer’s perspective, you’ll see why they are needed.
• Separate the Managers from the Techies
  You will find that some of your “good” people are given the additional responsibility of having to manage others to get work done. Maybe they do a decent job of it, but you’ll also find that you are losing out by not utilizing their technical abilities to the fullest. To make the distinction, a Team Lead is responsible for managing the team, leadership and delivery of the product (or subsystem). A Tech Lead is responsible for ensuring things are done right.
• Communication Breakdown
  Avoid multi-location teams. Invest in documentation. Always write down all the things that you don’t want to forget.

13 things I learnt moving from Agile Coaching into product management

Even if this article is not about Engineering Management, it touches on some of the most relevant aspects of that domain: What is Agile Coaching, what is the role of a Product Manager and how to switch careers in fast growing tech companies. Here are the key points of this writing, which I think would be 100% the same for becoming a Manager in Engineering:

• You are accountable for everything and shield your team
• Alignment is everything
• Big teams create more work for the PM — and it is not always “productive” work
• Know what you’re being measured on
• Publicly credit the team at every opportunity
• Books might not be the answer
• Act on your ideas as fast as possible
• Overcommunication is key
• Learn to be defensive about your calendar
• Sometimes you decide
• Vision is hard
• Learn SQL
• Don’t forget about your old role

Situational Leadership

The author (Rushabh Doshi, former Engineering Director at YouTube and Product Director at Facebook) describes Situational Leadership as the most effective management framework as it can be applied to a broad range of scenarios, is practical enough to be easily understood and applicable.

People are different, they all need different approaches to being managed. Situational Leadership is the solution to this problem. We can segment the engineers along two axes — ability/competence and willingness/confidence/security. Depending on where they are in their journey, you can use different techniques to help them. This theory is not new. Ken Blanchard and Spencer Johnson wrote about this in One Minute Manager, first published in 1982.

How should our behavior change when working with Amy or Bob taking into account their different stages? We can think of leadership on two axes (surprise!): Supportive and Directive.

Psychological Safety: A prerequisite for high performing teams

Can a team of talents who are suspicious of each other solve complex problems together and innovate? The answer is simply, no. When people protect themselves from embarrassment and other possible threats by remaining silent, the team doesn’t engage in collective learning behaviors and that results in poor team performance and inability to innovate.

Psychological Safety (aka trust) is a foundation for High Performing Teams and Individuals!

In such an environment people can openly and candidly talk to each other without fear if judgement and reprisals.

Solving complex problems is the bread and butter of any cutting-edge business, where constant experimentation is required: Intense phases of trial and error until teams gets things right, which by definition is the very basis of business innovation. Faced with uncertainty, psychologically safe teams are propelled into a performance spiral: where making mistakes is not considered as a failure, but rather as experimentation and learning opportunity.

It is not about creating a weak and cozy environment: It is all about creating a culture of openness where teammates can share learnings, be direct, take risks, admitting you “screwed up” and be willing to ask for help when you’re in over your head.

The author describes “Team Contracts” as a tool to create Psychological Safety:

• What are the rules and behaviors we want to abide by in our team?
• As individuals, do we have preferences to work in a certain way?

14 Sprint review Anti-Patterns holding back scrum teams

The Sprint Review is one of those meetings when used well, can add a lot of value to an organization. Teams are able to receive feedback, development cadence becomes visible, people are inspired to think and produce even more ideas.

This short articles lists 14 Anti-Patterns for this kind of meeting. Useful for creating one that actually works.

The ‘law’ that explains why you can’t get anything done.

A general article about organizational productivity and efficiency: It starts from the well known concept of “Parkinson’s Law” which says that work always expands so as to fill the time available for its completion”.

In his original essay he (Parkinson) pointed out that although the number of navy ships decreased by two thirds, and personnel by a third, between 1914 and 1928, the number of bureaucrats had still ballooned by almost 6% a year. There were fewer people and less work to manage — but management was still expanding, and Parkinson argued that this was due to factors that were independent of naval operational needs.

Parkinson argued that if you have 6% growth rate of any administrative body, then sooner or later any company will die. They will have all their workforce in bureaucracy and none in production.

Parkinson pointed to two critical elements that lead to bureaucratisation — what he called the law of multiplication of subordinates, the tendency of managers to hire two or more subordinates to report to them so that neither is in direct competition with the manager themself; and the fact that bureaucrats create work for other bureaucrats.

When the organizational pyramid gets very large and expensive it might eat up all the company’s profits. If the bureaucratic body is not drastically reduced at this stage the company will die.

“When you have a deadline it’s like a storm ahead of you or having a truck around the corner. It’s menacing and it’s approaching, so you focus heavily on the task.” And you may well pull off a great job, but the problem is that everything else gets moved to the periphery. “If you’re focusing so heavily on a big project you may at the same time forget to pick up your kid from school, your mom’s birthday, to feed the dog etc. That may be the price you pay for the success you’re achieving with your focus.”

The 3 elements of trust

Much was written / said about trust as a key factor for good leadership. The equation is simple: You want the people working in your team or organization to trust you — so you need to trust them. I’ve always seen trust as a result of good competence and good character. This article describes three different aspects:

• Positive relationships
• Good Judgement / Expertise
• Consistency

While all aspects are important to have to build and maintain a high level of trust, it is the skill of building positive relationships that matters most. What does that mean? It means, that in order to build trust with others you need to understand that you need to invest into others: Stay in touch with their issues and concerns, balance results with concern for others, generate cooperation with and between others, and to give honest feedback in a helpful way.

Estimating a Software Deadline is really hard

Yeah — this is not news. It is not just hard, but almost impossible. However, as an Engineering Manager you have to do it, you have to have a sense for when your team is able to finalize their work. This article lists a few concepts and theories I believe Engineering Managers (and Product Managers) need to know to manage and estimate time.

• If you have a forecast, forecast often
• Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
• Murphy’s Law: Whatever can go wrong, will go wrong.
• Parkinson’s Law: Work expands so as to fill the time available for its completion.
• Sturgeon’s Law: Ninety percent of everything is crap.
• Brooks Law: Adding manpower to a late software project makes it later.

Here are some good practices for estimating project times:

1. Involve the team as a whole when it comes to estimating upcoming work to increase the sense of collective ownership and better validate the estimates.
2. Always try to estimate smaller pieces of work (within reason), to have better estimates.
3. Always add some contingency to project work to cater for the unexpected.
4. Keep the contingency separately from the rest of the estimates and do not distribute it to each piece of work.
5. Be careful when adding extra resources to an already-late project as they can lead to the project being delayed further.

Enjoyed the list? See my previous ones as well:

• EM Reading List #1
• EM Reading List #2
• EM Reading List #3