Category: Project Management

Dare Obasanjo talking about what it takes to be a leader.

Many people want to be managers to grow their careers but in reality being a leader is more important in the long run. A leader is someone whose authority is earned and people choose to follow as opposed to someone people have to follow because it’s their job.

Good leaders are…

• focused on the team instead of themselves. Good leaders want to develop others and help them grow. They are ambitious but it’s for the team’s success not just their own career.
• effective and transparent communicators. They also understand listening is part of communicating
• self aware about their strengths and weaknesses. Self awareness is coupled with a growth mindset. Weaknesses aren’t limitations but opportunities to learn.
• respectful to their team and act with personal integrity. They set positive examples of how people should be treated.
• effective at both short term execution and long term strategy. There is a vision for where we’re going and a path for how to get there.
• effective delegators. Good leaders encourage autonomy and avoid becoming decision bottlenecks while giving the team growth opportunities.

This comment by socketcluster on HackerNews on how seniors can ask dumb questions and why juniors hesitate to do the same.

…I find that it’s seniors who ask the ‘dumb’ questions. Everyone is worried about losing face in this precarious economy… But seniors are able to ask really smart questions as well so even their dumb questions sound smart… They can usually spin dumb questions into a smart questions by going one level deeper and bringing nuance into the discussion. This may be difficult to do for a junior.

My experience as a team lead working with a lot of juniors is that they are terrified of losing face and tend to talk a big game. As a team lead, I try to use language which expresses any doubts or knowledge gaps I have so that others in my team feel comfortable doing it as well. But a key aspect is that you have to really know your stuff in certain areas because you need to inspire others to mirror you… They won’t try to mirror you if they don’t respect you, based on your technical ability.

You need to demonstrate deep knowledge in some areas and need to demonstrate excellent reasoning abilities before you can safely ask dumb questions IMO. I try to find the specific strengths and weaknesses of my team members. I give constructive criticism for weaknesses but always try to identify and acknowledge each person’s unique superpower; what makes them really stand out within the team. If people feel secure in their ‘superpower’, then they can be vulnerable in other areas and still feel confident. It’s important to correctly identify the ‘superpower’ though because you don’t want a Junior honing a skill that they don’t naturally possess or you don’t want them to be calling shots when they should be asking for help.

Martin Fowler’s foreword on the book Frictionless.

The key to this book is that they don’t think in terms of how to whip people into greater productivity, but how to find the sources of friction that slow them down. Friction is when I have to submit a pull request that sits for a couple of days while I forget about the code, or spend two days wrangling some infrastructure that ought to be a simple API call. Smoothing away these points of friction is the essence of improving Developer Experience – and thus speeding up getting useful software into the hands of its users.

They describe effective developer experience in terms of three elements: feedback loops, flow state, and cognitive load. We can only find out whether we are on the right path by getting rapid feedback. The longer the delay between that blue dot moving on my phone-map, the longer I walk in the wrong direction before realizing my mistake. If our feedback is rapid, we can remain in the second element, a flow state, where we can smoothly and rapidly get things done, improving our products and our motivation. Flow also depends on our ability to understand what we need to do, which means we must be wary of being overwhelmed by cognitive load, whether it comes in the form of poorly structured code, flaky tests, or interruptions that break our flow.

Focusing on developer experience is about finding what gets in the way of these three elements. Improving developer experience leads to better outcomes for the business. Those lost hours wrangling with infrastructure is money wasted on developers’ salary, and revenue lost because the software took longer to get into production.

Sandra Knispel talking about the study done by American Economic Review.

Two financial economists, from the University of Rochester and the University of Wisconsin–Madison respectively, created a model that explains how reputation, information, and retention interact in professions where skill is essential and performance is both visible and attributable to a specific person, particularly in fields such as law, consulting, fund asset management, auditing, and architecture. They argue that much of the professional services world operates through “intermediaries”—firms that both hire employees (also referred to as “agents” or “managers”) and market their expertise to clients—because clients can’t themselves easily judge a worker’s ability from the outset.

[…]

At the start of an employee’s career, the firm has an advantage, Kaniel and his coauthor Dmitry Orlov contend, because the firm (“the mediator”) can assess an employee’s talent more accurately than outside clients can. During what the authors call “quiet periods,” the firm keeps those who perform adequately and pays them standard wages.

Over time, however, an employee’s public performance—measured by successful cases, profitable investments, or well-executed projects—reduces the firm’s informational advantage. As the informational gap shrinks, the firm needs to pay some employees more because clients are now able to observe an employee’s good performance and hence update their beliefs about the employee’s skills.

“At some point, the informational advantage becomes fairly small,” says Kaniel, “and the firm says, ‘Well, I will basically start to churn. I will let go of some employees, and by doing that, I can actually extract more from the remaining ones.’”

Ironically, to the client these churned—or strategically fired—employees look just as good as the ones whom the firm kept. Churning happens not because these employees have failed but because they may be just somewhat lower-skilled than their peers. Subsequently, churning heightens both the reputation of the firm and of the employees who remain.

I found the concept of information advantage and its subsequent shrinking intriguing.

Will Larson arguing that the role of engineering manager changes based on the realities of the industry. He then goes on to share the core skills (essential to operate in all roles) and growth skills (whose presence–or absence–determines how far you can go in your career) for engineering managers.

The core skills are:

1. Execution: lead team to deliver expected tangible and intangible work. Fundamentally, management is about getting things done, and you’ll neither get an opportunity to begin managing, nor stay long as a manager, if your teams don’t execute.
   Examples: ship projects, manage on-call rotation, sprint planning, manage incidents
2. Team: shape the team and the environment such that they succeed. This is not working for the team, nor is it working for your leadership, it is finding the balance between the two that works for both.
   Examples: hiring, coaching, performance management, advocate with your management
3. Ownership: navigate reality to make consistent progress, even when reality is difficult Finding a way to get things done, rather than finding a way that it not getting done is someone else’s fault.
   Examples: doing hard things, showing up when it’s uncomfortable, being accountable despite systemic issues
4. Alignment: build shared understanding across leadership, stakeholders, your team, and the problem space. Finding a realistic plan that meets the moment, without surprising or being surprised by those around you.
   Examples: document and share top problems, and updates during crises

The growth skills are:

1. Taste: exercise discerning judgment about what “good” looks like—technically, in business terms, and in process/strategy. Taste is a broadchurch, and my experience is that broad taste is an somewhat universal criteria for truly senior roles. In some ways, taste is a prerequisite to Amazon’s Are Right, A Lot.
   Examples: refine proposed product concept, avoid high-risk rewrite, find usability issues in team’s work
2. Clarity: your team, stakeholders, and leadership know what you’re doing and why, and agree that it makes sense. In particular, they understand how you are overcoming your biggest problems. So clarity is not, “Struggling with scalability issues” but instead “Sharding the user logins database in a new cluster to reduce load.”
   Examples: identify levers to progress, create plan to exit a crisis, show progress on implementing that plan
3. Navigating ambiguity: work from complex problem to opinionated, viable approach. If you’re given an extremely messy, open-ended problem, can you still find a way to make progress? (I’ve written previously about this topic.)
   Examples: launching a new business line, improving developer experience, going from 1 to N cloud regions
4. Working across timescales: ensure your areas of responsibility make progress across both the short and long term. There are many ways to appear successful by cutting corners today, that end in disaster tomorrow. Success requires understanding, and being accountable for, how different timescales interact.
   Examples: have an explicit destination, ensure short-term work steers towards it, be long-term rigid and short-term flexible

Will also shares a framework on how to assess yourself on each of those skills.

Scott Kosman talking about how, as a manager, he uses AI.

Management work happens in your head with dozens of open loops spinning at once, and suddenly using AI gave me a safe way to unload that noise without judgment or consequence. Some days my brain becomes a bag of cats and I can quickly spin myself in circles with too many scattered thoughts competing for mindshare at the same time. Being able to hammer those down into a prompt window in no particular order and ask “what am I really trying to say here?” has saved me literal hours of effort in a single day.

I’ve come to think of it as cognitive offloading. By pushing my internal monologue into a medium that reflects it back to me more clearly, I preserve energy for the parts of leadership that actually matter: listening, coaching, connecting.

This is similar to the approach that I use.

I am working as a project manager for a project where <insert the project description with client background>. I need to <insert problem statement, it can be vague but needs to include all your thoughts in any order>. I have an idea of using <some framework>. Can you use that as a reference and give me some guidance?

The above prompt gives a pretty good starting point for me.

Jade Rubick explaining why we should strive to maximise collaboration within teams and minimise collaboration between teams.

To the maximum extent possible, teams should have what they need to succeed within the borders of their team. And where that is not true, you need some structure to ensure the team can get what it needs in a way that will scale with the organization’s growth.

As companies grow, communication and dependencies proliferate. Companies start out with many-to-many communication. As they grow, the communication patterns within the company must necessarily switch to being segmented and defined. Otherwise, the communication burden on teams will grow at an exponential rate, and the increasing complexity will degrade the effectiveness of the company.

Andi Roberts explaining the difference between pilots, probes and experiments. He then goes on share guidance on how to manage each of them.

Pilots: A pilot is a small, time-bound test to determine whether a product, process, or service can work in practice. It is used when an idea appears promising but remains unproven.

Think of a bank that tries a new mobile feature in one city before a national launch. The trial exposes what could not be seen on paper: user confusion, system issues, or compliance gaps. The value of a pilot lies in its realism. It bridges the space between concept and operation, letting leaders see what truly happens when an idea meets the world. From this, they can refine and strengthen the design before committing at scale.

Probes: A probe begins with curiosity, not certainty. Drawn from complexity thinking, probes are small, safe-to-fail actions that explore what might work when the path ahead is unclear.

A city struggling with congestion might try three different approaches: a cycling subsidy, staggered work hours in one district, and AI-driven traffic lights. None is guaranteed to succeed, and that is the point. Each test offers a glimpse of how the system responds. The power of a probe is its capacity to uncover patterns that analysis alone cannot reveal.

Experiments: An experiment is a structured test designed around a hypothesis. It is used when a leader wants clear evidence about cause and effect.

An online retailer, for example, may compare two website layouts to see which converts more visitors into buyers. Experiments are precise, controlled, and measurable. They do not explore the unknown in the same way that probes do, but they provide reliable evidence where outcomes can be quantified. Their strength lies in giving leaders grounded answers to specific questions.

Matheus Lima explaining politics at workplace.

Politics is just how humans coordinate in groups. It’s the invisible network of relationships, influence, and informal power that exists in every organization. You can refuse to participate, but that doesn’t make it go away. It just means decisions get made without you.

Think about the last time a terrible technical decision got pushed through at your company. Maybe it was adopting some overcomplicated architecture, or choosing a vendor that everyone knew was wrong, or killing a project that was actually working. I bet if you dig into what happened, you’ll find it wasn’t because the decision-makers were stupid. It’s because the people with the right information weren’t in the room. They “didn’t do politics.”

Meanwhile, someone who understood how influence works was in that room, making their case, building coalitions, showing they’d done their homework. And their idea won. Not because it was better, but because they showed up to play while everyone else was “too pure” for politics.

Ideas don’t speak. People do. And the people who understand how to navigate organizational dynamics, build relationships, and yes, play politics? Their ideas get heard.

When you build strong relationships across teams, understand what motivates different stakeholders, and know how to build consensus, you’re doing politics. When you take time to explain your technical decisions to non-technical stakeholders in language they understand, that’s politics. When you grab coffee with someone from another team to understand their challenges, that’s politics too.

Good politics is just being strategic about relationships and influence in the service of good outcomes.

I too thought of politics at workplace is something to be avoided. But politics doesn’t meaning backstabbing your opponent. As per Wikipedia it means:

Politics is the set of activities that are associated with making decisions in groups, or other forms of power relations among individuals, such as the distribution of status or resources.

Ibrahim Diallo sharing tips on how to lead a room full of experts.

By definition, leading is knowing the way forward. But in reality, in a room full of experts, pretending to know everything makes you look like an idiot.

Instead, “I don’t know, but let’s figure it out” becomes a superpower. It gives your experts permission to share uncertainty. It models intellectual humility. And it keeps the focus on moving forward rather than defending ego. It’s also an opportunity to let your experts shine.

Saying “I don’t know” is truly a super power. Every time I have said it, the person in the front has excitedly shared all their knowledge with me.