This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.
This is the blog of Adam Kalsey. Unusual depth and complexity. Rich, full body with a hint of nutty earthiness.
When your assumptions change, it’s reasonable that your project plans and needs change as well. But too many managers are afraid to go back and re-work a plan that they’ve already agreed to.
A manager received a large project that was crucial to the success of the company. Shortly thereafter all the managers then went through a company-wide planning exercise to determine staffing and budget needs for the coming year. He devised a budget and agreed to a plan with his managers and peers.
The manager felt confident in his projections and requests. Then, a few weeks later, once the team had started building the product features, he started to realize that there was a lot more work than he’d anticipated. He could still get the project done in the desired time frame, but he’d need more people to pull it off.
How to communicate this back to the company? You’ve agreed to a big plan and a budget, then a few short weeks later you come back and say you were wrong. Won’t that look like you’re bad at planning?
Especially in the early stages of a project, software development requires making a lot of assumptions. You think the existing production infrastructure will be enough. You expect a certain level of usage and strain on the system. You believe the algorithms you’ll need are like ones you built two years ago. The user authentication model will support this with only a few safe modifications. We can probably re-use most of the data model we created for the previous product. Your estimates for a budget, scope, and delivery dates all rest on these assumptions.
Once you actually start working on the project, you’re going to find out that your assumptions were wrong. Every time. But most of the time, the degree to which they are wrong isn’t a big deal. You might have even assumed something was a lot more complex and difficult than it turned out to be.
In this case, the team was integrating its software with various third-party systems. Because all the systems do roughly the same thing, it the team assumed that the implementation would be largely re-usable between vendors. This assumption was wrong. The result was that there was a tremendous amount of repetitive work required to implement each system. The team did not expect the amount of technical analysis, testing, debugging, monitoring, and general vendor management.
The assumptions were wrong, so the estimates and budgets were wrong. This is something that the company leadership should understand. The manager should go back to the company leaders and show the assumptions and the issues with them, then negotiate an increased budget, a reduced scope, or an extended timeline.
What a lot of managers will do instead is try and make the original plan work, even though the basis of the plan bad data. Rather than worry that you’ll look silly by raising issues so soon, realize that the rest of the company needs forewarning, not perfection. It’s better to give bad news now and avoid surprises than it is to give bad news later when it’s too late to do anything about it.
Feature voting is the worst idea ever invented for product management.
"If I’d listened to what my customers asked for, I’d have built a faster horse." - Apocryphally attributed to Henry Ford.
When a company starts getting feature requests for their product, it often creates two questions. How do we keep track of all this and how do we know which requests are most important?
And thus the idea portal is born. Throw up a form and let customers put in what they want. Let them look through all the existing ideas and tell you which features they’d use as well. All at once, we’ve solved how to collect feature requests and how to know which we should work on first. Just sort by the top votes, and you’ll know what your customers really care about. There are even SaaS products you can use that manage the whole process for you.
What you’ve actually done is seriously damaged your product roadmap.
There’s a lot of problems with using feature voting to drive your product.
If you’re managing other managers, encourage them to hold their own 1:1s. At a minimum, doing them with their direct reports is non-negotiable. It’s such an important tool for managing and leading that everyone needs to be holding them.
I encourage, but don’t require, them to do skip levels and peer 1:1s, too. They’ll get huge benefits from seeing the bigger picture of the company, and you’ll find that managers are less threatened by you doing skip-levels with their reports if they’re doing skip levels of their own.
Most managers don’t do 1:1s well, and like everything else, it’s a learned skill. Teach them this skill.
Use your 1:1s with them to teach by example, and periodically ask them how their 1:1s are going. Dive deep into the problems they struggle with holding a 1:1.
Create templates for agendas, distribute ideas for how to get feedback, point them at blog posts like mine, and otherwise give them a starting point for learning their own effective 1:1 style.
If you have enough managers, invest in some training time with them. Teach them how to avoid falling into talking about the tactical day to day. Walk through what a 1:1 should look like. Have them practice on each other.
This is one of a series of posts about holding 1:1s. View the rest of the series.
I’ve been blogging a lot recently about holding 1:1 meetings with your reports. Here’s the entire collection of these works.
You’re having a 1:1 and someone brings something to you that feels like it needs addressing with someone else. Maybe they’re having a problem with a teammate. Maybe they’ve been approached about a new role. What do you do? Is the discussion confidential, even if they didn’t ask you to keep it so?
Mark Rabkin, VP Engineering and Product Facebook said, "If it’s safe enough to be overheard — it’s not the right content for a 1:1." The very idea of a 1:1 is to talk about things that shouldn’t be discussed in groups. Confidentiality is a requirement.
Skip-level 1:1s are almost always complaint sessions, often about their boss or teammates. You have to keep them 100% confidential. This is hard because it often feels like you need to fix things. You’re the manager after all, and what is your job there for if not to fix things? You must resist this urge. If the team doesn’t feel they can tell you things without it getting out, they will hold back, and you’ll miss out on the benefits of the skip levels.
If Carly tells you she’s thinking of applying for a spot somewhere else in the company, you can’t go tell her boss about it or your trust is blown and the skip levels become useless.
You often have to avoid taking direct action after a 1:1, so you don’t inadvertently leak what was talked about. Evan tells you that his boss is taking forever to approve the latest plans, you’ll have to wait a while to talk about it with his boss, or he’ll think Evan tattled on him.
In 1:1s with your own reports, they’re talking to their boss, so they have an absolute expectation of privacy. Unless you specifically talk to them about bringing someone else into the discussion, their thoughts and concerns should stay completely between the two of you. If you find that you’re regularly talking bringing something up with someone else, then you either have a seriously dysfunctional company, or you’re talking about the wrong things in your 1:1s (hint: stop talking about the work you’re doing).
Of course, if something illegal or unethical is going on, address it right away. Take whatever steps you can to sanitize the source, but you can’t allow bad behavior to continue.
This is one of a series of posts about holding 1:1s. View the rest of the series.
In addition to 1:1 meetings with your direct reports, you should be hosting periodic 1:1s with people that are further down in the reporting chain and with your peers in other groups.
The skip level 1:1 is a very underutilized tool. A skip-level is a 1:1 conversation with people who report to your direct reports, and perhaps to the people who report to the people who report to your reports.
If you want to really know what’s going on in your organization, you have to talk to the people who are doing the work. You can do this by scheduling a weekly 1:1 with someone under you. It doesn’t need to be the same person each week, and it also doesn’t need to be just one level removed. In fact, it’s useful to constantly rotate between different people for the skip level. As you rise in the reporting structure, you should even schedule 1:1s with people all the way down the ladder to get a sense of what is happening “on the ground.” If I were the CEO of a 10,000 person company, I’d be talking to the most junior folks in the company at least a couple times a month.
Don’t just think of skip levels with people under you. Schedule peer 1:1s with folks in other parts of the organization that you work with. If you’re an engineering manager, talk to other engineering managers. Talk to marketing. Talk to product support.
A peer 1:1 will be different in tone than a skip-level, but the desired output is the same. Use these to catch up on what’s going on in your peer’s world. What’s going well, what issues are they seeing? Who is being particularly helpful or difficult? You’re using these to understand the big picture surrounding your work and to make sure that other teams have you in their big picture.
Peer 1:1s can be far more infrequent. For the most part, I find that catching up every 3-5 weeks is plenty, and it’s not terribly harmful if you have to skip them here and there.
Expanding your definition about who to hold 1:1s with will help you have a much better view of what’s happening in your company.
This is one of a series of posts about holding 1:1s. View the rest of the series.
This can’t be good: http://t.co/vJCJ3D2g
Am I the only one wondering what would happen if I unplugged that Ethernet cable?
Now I know why my hotel wifi signal is so good: http://t.co/ADAKVtPK
The Oakland A’s are selling root beer floats to raise money to fight diabetes. Next month, how about beer proceeds donated to AA?
Dear gmail, please sort autocomplete contacts by frequency of use. I email my wife Christina way more than I do @ChrisPirillo. Put her 1st.
My son’s school is selling or giving my contact info to local businesses. Lovely.
Two iPhones in the house took a swim this week. Opened them up, cleaned them out, they’re both working again.
If your pitch deck is more about the animations than the company, you’ve already lost.
The ER is always filled with interesting people.
Proof reading is gud.
©1999-2019 Adam Kalsey.
