Be specific when you assign tasks.

Multiple accountabilities equals no responsibility.

Meaning: If a task is not the responsibility of any one person, it might not get done.

Assigning tasks to specific people meant they would definitely get done.

You are an individual contributor at heart. You like writing code and solving technical problems. You dislike meetings and ceremony. Here’s what you can do to maximize what you like and minimize what you don’t: radiate information.

When you delegate a task, you (the business owner) are still responsible for it.

That's why I always ask my team to explain their thinking behind the choices.

If I understand their thinking, I can trust their decisions.

One of the things I've found hardest as a do-it-all founder:

I don't have a good intuition for how to actually divide all of the things we need to do into clear, separate roles.

Makes hiring very challenging — I often know we need help but can't clearly articulate a role.

A few reasons why software projects get delayed:

• Unclear ownership

• Insufficient scope that gets changed mid-project

• Lack of planning for bottlenecks/dependencies

• Bad communication of blockers & questions

• Too small team vs too big scope

Перше правило стартапа: краще одна задача в статусі done ніж чотири задачі в статусі almost done

Don’t manage projects, coordinate people. They’ll take care of the project just fine.

Let's just get rid of the damn sprints entirely! When you're done with the current thing, pull the next thing. The entire team works on one story at a time. It takes as long as it takes.

I don't really understand why we keep trying to "estimate" how much time building software would take

engineers know it's bollocks tech leads know they are useless PMs know it's finger the air estimations

yet so many teams still do this silly dance

We recently received this email from a REWORK Podcast listener who had a question...

...I think it was in Shape Up that the idea of delegating projects rather than tasks came up. And I'm trying to move this way, of working with my own team. I just wonder if you guys have any tips or help for making that transition, helping team members take ownership for their areas of work, maybe obstacles I can watch out for leading my team in this way as we move in this direction. We have a small team, just a handful of people. But I would love to move in this direction where they're taking more ownership and I can delegate whole projects rather than, um, me kind of owning the project and then delegating tasks...

We're likely going to address this question out loud on an upcoming podcast AMA, but I wanted to write up a response as well. So here goes.

“The real insight about managing people is that, ultimately, you don’t. The best performers are people who know enough and care enough to manage themselves.”

People with executive assistants:

What are your productivity hacks?

What apps do you use?

What unexpected things does your assistant do that makes your life less stressful?

For me: All my emails go into Front, are fully triaged, and I only get the emails that I need to.

Why did you choose Scrum instead of Kanban? If you can’t answer that question, you didn’t choose Scrum. Someone else chose it for you.

Leadership tip of the week

Be specific. People can’t read your mind for extra context. Make expectations clear and you’ll get better results.

Leadership tip of the week

Everyone works better with structure, so don’t be afraid to give deadlines, define goals, or set processes. Constraints allow people to do their best work.

Your teams are getting nothing done because they are trying to get everything done.

If you have young children, 5AM is one of the only times you can get deep work done. No one is awake, and it’s silent. And no notifications from family/friends.

Is 5AM a requirement for success? No, but that’s when I get my best work done every day.

For years I shipped boxed software. Quite literally, boxed. At Sun, we had a guy who’s job title was ‘boxologist’. He figured out what we could fit in to what kind of box and how to package it up. Not to do it, not to arrange the actual hard work of logistics. Just to figure out what could fit into a box. That’s it, a full time guy, in 2006. (Not 1996. 2006!). (Possibly one of the reasons Sun didn’t do so well, but I digress.)

When working on a project, you can pick two of three: speed, quality, scope.

When in doubt, reduce scope.

Business documentation might sound boring. But it’s your golden ticket. It’ll allow you to quickly train new hires and it will bet you a premium when you’re acquired.

As a founder and CTO, I have seen my company grow from when I used to write all the code, to the point I wrote almost none.

I am sad how well arbitrary deadlines work.

Engineers looking to grow their career in people management are sometimes flummoxed by the myriad of titles and roles out there. What exactly is the difference between a Manager and Manager II? Senior Manager and Director? This is made further complicated by these titles not meaning the same thing across companies. For example, a Director of Engineering in a 50 person startup is a very different role than a Director of Engineering in a large public company with 10,000+ engineers.

The 3 Levels of Employees:

Level 1 — You do what you are asked to do.

Level 2 — Level 1 + You think ahead and solve problems before they happen.

Level 3 — Level 2 + You proactively look for areas of opportunity and growth in the business, and figure out how to tap into them.

If you've worked in tech long enough, you'll hear praise for Andy Grove's High Output Management, oft-praised as a touchstone of technology management (Grove is often referred to as the "Father of the OKR"). A year or so ago, I got to read his book through Harrison Metal's General Management course. What can you apply from the book when you're a tech lead, and not actually a manager?

If your company requires you to work nights and weekends, your company is broken. This is a managerial problem, not your problem. This is a process problem, not a personal problem. This is an ownership problem, not an individual problem.

In the software world, “waterfall” is commonly used to describe a style of software process, one that contrasts with the ideas of iterative, or agile styles. Like many well-known terms in software it's meaning is ill-defined and origins are obscure - but I find its essential theme is breaking down a large effort into phases based on activity.

Привет! Меня зовут Сергей Алексеев, в IТ я уже 9-й год и в последнее время зачастил на DOU со своими статьями. Это обусловлено тем, что я хочу передать сообществу свои знания. В этот раз я решил написать статью, в которой будет много примеров артефактов, без которых либо невозможно сделать программное обеспечение, либо из-за их отсутствия увеличивается срок разработки ПО. Или еще хуже — будет реализовано совершенно не того, что было задумано изначально.

A core reason why it gets harder to communicate inside organizations is the explosive increase in links between people [n*(n-1)/2]:

• 10 people: 45 links
• 67 people: 2211 links
• 250 people: 31.125 links This kind of complexity requires radical changes in how you operate.

It’s a classic manager mindset: if I don’t SEE you doing work, then you’re not doing work. I hate that mentality.

When it comes to delegating, invite your team into both the thinking and the doing.

Don’t be fooled: Becoming a new manager is deceptively difficult.

No matter how many leadership books you’ve read or conversations you’ve had with mentors – the transition to becoming a manager is precarious.

When I was getting ready to join Kickstarter as VP of Engineering, Chad Dickerson (who was the CEO of Etsy when I worked there) offered to send me a bunch of advice. Chad had been a CTO multiple times before being CEO; he knew that this executive-level role was brand new to me, so he offered to help give me a steer and a foundation as I walked into this totally new territory.

First: some basic definitions.

There’s a difference between leaders & managers.

Managers are about ensuring the team’s efforts are effective.

Leaders lead the team to achieve the vision.

Managers: want productive devs and fewer bugs? Make sure they have frequent 3-hour blocks with no interruptions. Quiet spaces.

Congratulations - you’re a new manager! No, really, I’m being sincere. You can hear the sarcasm in my voice? Sorry, I tried, but I know that along with some excitement, there’s plenty of doubt and angst. You have likely followed a path that’s similar to mine and many others. You‘ve been a software engineer (or insert role here) for many years. You became the “go-to” person, earned a senior title, and were known as an informal leader by those outside and within your team. Probably played the “tech lead” leading up to this point. You may have even been fighting this “promotion” for some time, didn’t want to get out of the code, lose your skills. But really, you were afraid that you wouldn’t be as good in the new role. Finally, somehow you were convinced to take the chance, and now here you are. From senior engineer to junior manager.

Advice to new managers:

1 earn trust by giving it
2 inspire, don’t tell
3 eat lunch with your team
4 show their work matters
5 be a player-coach
6 feedback in private, praise in public
7 in victory, lead from back
8 in crisis, lead from front
9 be the manager you wish you had

I remember talking with an acquaintance a few years back who had recently graduated from college about how she envisioned her career progressing.

You have to choose between speed & quality. Don't kid yourself.

Speed is desirable at the start of a project because the deadline is so insufferably far away.

Quality becomes desirable at the end when you finally see all the ugly compromises you've made along the way.

Many of us know the vague benefits and aim of delegation — to build teams who can share the workload so that you do the highest expression work that only you can do. But in practice, we hoard tasks and become a bottleneck. Conduct an audit using the six T’s to determine what tasks make the most sense to offload: if a task is tiny, tedious, time-consuming, teachable, time-sensitive, or you’re just terrible at it, delegate it. Check in with yourself frequently (even daily) to examine what’s on your plate and ask: What can you and only you do? How can you delegate the rest? For two weeks, keep a list of all the things you’re doing that might fit one of the six T’s, and notice how much time you can free up for your most important priorities.

There’s a famous story about an executive that hired Edward W. Deming to spend a week with his team and offer recommendations on how to improve both their own performance and the performance of the organization they led. Word has it that Deming arrived on the first day, said “hello,” and then walked straight to the corner of the executive’s office to sit down. He stayed there, sitting silently for the entire day as the executive went about his daily activities.

Deep Work Wednesdays has been a powerful concept at @buffer:

A few months ago, the engineers @Buffer started a "deep work Wednesday" experiment. A resounding success, it's since permeated many areas! 👌

“How do you guys actually work? How do you choose what to do? How big are your teams? How do you structure the work itself” are questions I get all the time. I’ve been sharing the details in small group workshops and 1 on 1, but figured it was time to write something up so we can share it at large.

I remember working as a developer at a company and complaining that I had no idea what the bosses did all day. It felt like while we engineers were working hard and shipping stuff, managers just talked to a lot of people all the time, or sat in their offices behind closed doors, and I had no idea what their work looked like.

One day, I was having my weekly 1:1 meeting with my boss, Andrew Bosworth. We were going through the regular updates about my team, things going on at Facebook more generally, yada yada. Then he asked me a somewhat startling question….

Most managers attempt to minimize an employee’s bad work instead of maximizing their good work. When 98% of an employee’s work is great and 2% is not, managers give feedback on the 2%.

I read Agile is the new Waterfall at first with disgust, then with horror, and then finally with a meager amount of very qualified approval.

As a teenager, I remember playing strategy games like X-COM, Civilization, and Red Alert.

These games use a mechanic known as “the fog of war.” When a player starts the game, they are immersed in an overhead map that is shrouded by darkness. The only way to reveal your surroundings is to explore. As you make moves, more and more of the map becomes visible.

Even with a stellar team, chock-full of strong expertise, it’s hard to create a long-lasting company. The tenacious workers that make it through the initial challenges of forming a company face the complicated task of aligning the company towards a common goal that seems ever-changing (in a competitive and fickle landscape).

Do you ever wonder how successful companies continue to navigate and grow? I often wondered how the companies I admired knew what direction to go — and it became apparent that the trick was being almost irresponsibly aggressive in growing key objectives with a talented group of people.

Giving people instructions creates dependence. People giving intent creates independence.

Just learned about the Dunning-Kruger effect. It’s why un-skilled people think they know more than experts in a particular subject

“We want to limit the length of a review in the product to 140 characters, because we may want to use SMS at some stage. That’s a small change, right?”

Wrong.

"If everything seems under control, you're just not going fast enough." - Mario Andretti

Why is it that managers are typically running out of time while their subordinates are typically running out of work? Here we shall explore the meaning of management time as it relates to the interaction between managers and their bosses, their peers, and their subordinates.