"Great job! Now, I have a policy of paying contractors on a Net-120 day term. So, I'll send you a check in six months. If you need the money sooner, I'll be happy to deduct a convenience fee of 2-5% from the total for each month less than 120 days. Also, I am going to need to keep that rake and hedge trimmer, too. You used it on my property, so really it belongs to me now. Sound good?"

Here’s the way to build your network that’s genuine, professional, effective, and most importantly, fun. Follow these tips, and I promise you will very quickly begin to pack your network with smart, interesting people who are genuinely interested in helping you succeed.

Feeling stuck is very common these days. A friend, a product manager in a high-growth tech company in San Francisco, confessed she feels stuck in a dead-end job.

Agile originated from a way of thinking about software development that is fundamentally anti-hierarchical, collaborative, flexible — and fast. It’s everything the traditional corporate machine, based on large scale standardization and long term predictability, is designed to remove from the system. And unfortunately, the flavors of Agile that have gained the most ground in the modern corporation are focused primarily on getting Agile to work in an environment that is fundamentally designed to stop creativity from happening in the first place.

“From the executive point of view, the decisions are bigger, and information from the front lines is less available and more coarse grained. It has been filtered up through various management layers before it gets to them. At their scale of responsibility, your ask is one of a hundred others just like it.”

The type of leadership we see in these endeavors, not just at the top, but throughout the organization as a whole, makes or breaks the long-term success of the organization.

Most companies attempting to embark on an Agile or other digital transformation skip the critical step of having a clear leadership development path for their product, design, and engineering managers.

Emotions exist in your mind as a set of thousands of statistically probable instances of a feeling (basically, predictions of a feeling) that your brain is estimating that you might feel in the next moment. It then continuously prunes down that set based on real time data coming from your senses until it arrives at a dominant feeling that matches the data. It then uses that validated feeling to make its predictions next time around.

The structure of organizations tends to reflect past decisions. Departments are created by leaders who have a specific mandate. They then hire support staff who align with their model of the world. The culture of that department then emerges as a function of the personal interactions between members of that group. Finally, the group begins to codify its work into rules and procedures which ultimately calcify into bureaucracy. Even a new leader taking over that department cannot instantly change that bureaucracy overnight.

Stress will destroy both your productivity and creative problem-solving ability — just the things you and your team need to compete in this economy. But the majority of leaders remain stubbornly in denial of the problem of stress and its effects on organizations.

For most startup founders, their key motivation is not the money or the fame of success in business. Rather, they are driven by a core desire to change something fundamental in the world. This, the need to make a difference, is what really separates the successful from those who fake it.

If you’re like most managers , you were promoted into management because you were a good individual contributor with some seniority, and you more or less figured out how to manage on the job. Unfortunately, you’re probably hindering their progress more than you’re helping. Don’t believe me? Let’s take a closer look at the problem.

The skills required to do jobs change in difficulty and complexity from entry to senior level. This is in accordance with the layers of abstraction embedded in most organizations, as you move from menial repetitive tasks at the bottom of the pyramid, to more abstract and creative tasks at the highest levels.

Product Management is a tough job. One of the toughest aspects is the fact that, in nearly all cases, you are on the hook for delivering a product, and yet have no direct authority over the team members doing the work.

“How long does it take to deploy your app from the time you first think of a feature to the moment it’s in front of a customer,” I asked? “In other words, what is the cycle time of your process?”

“Well, we can build anything very quickly. But deployment? You should talk to our DevOps team about that.”

Yeah, they’ve totally missed the point of DevOps.

Last week, I was standing in a conference room at a $20 billion company, facilitating a workshop on Agile. The group in attendance was made of the directors and line managers of each function in just one product line within this giant company. These dozen or so leaders, selected from UX, Engineering, and Product Management, represented a broader team of about 150 others who work on this product line. As a unit, they have recently embarked on a journey to become “Agile.”

It’s hard to beat the feeling of relief upon landing that first big customer, whether you’re in charge of a new product in an established enterprise, or a lonely startup founder sitting in a WeWork somewhere.

The quality of a system is very important to the business. By quality, I mean that the software is architected and built in such a way that ongoing maintenance, modification, and extension are all relatively low cost activities compared to the initial cost of building the system. In modern software development, we have well-established practices for building such systems, such as pair programming, proper use of design patterns, modularity and encapsulation of components, and automated testing. One needs only to be knowledgable about these practices, and implement them carefully, in order to produce a good system.

A good friend had been working for a startup company for about 6 months. He had been very excited about it initially. It involved robots, artificial intelligence, and some large scale computing problems. It was right up his alley. We’d gone out celebrating when he’d got the job, and he’d gushed about how cutting edge their technology was.

When will the team be ready to ship?” There is probably no question we engineers hate more than that one. For as long as I have been building software, bumping up against 20 years now, I have observed engineers, engineering teams, and engineering managers squirming in their conference room chairs, frantically waving their hands, and saying just about any words they can think of — words like “dependencies” and “technical debt” and “build process” — to avoid directly answering that question.