• A boss came to a worker: – Would you come to work on weekend to rescue project? – And what would be the reward? – asked poor little worker. And there was no answer. Actually the unspoken answer was “I don’t really know” or “I don’t want to say” or “Don’t mess with me, kid.” […]

  • There was a company, which was doing reasonably well. When times were good they were growing stronger. Some people were leaving, as it always happen, but more were coming on board. Since things were rolling fast no one really had time to stop and verify whether all new faces are doing fine. Some time passed. […]

  • While explaining another thing which I thought was obvious for everyone in the team but appeared as not clearly communicated the question came back to me: is it possible to over-communicate in project? I dropped the question on Twitter and expected answers like “Hell no!” Or “Maybe it is possible but no one seen that […]

  • I’ve already told you that writing test cases is worth the effort. What I haven’t stressed are shortcomings of test cases. If you take time to prepare test cases you most likely do it for the reason and I guess not for “my manager will fire me if I don’t” one. You want to invite […]

  • Test cases are here for a long time. Used equally willingly by these who work with heavy-weight processes and those who choose the agile way. They can be stored in an appendix to documentation in BDUF (Big Design Up Front) project or be written on yellow cards along with user stories. Where’s their main value […]

  • That’s the old story: we suck at estimating. Our schedules tend to be wrong not only because there are unexpected issues but mostly because we underestimate effort needed to complete tasks. There’s one simple trick which allows improving quality of estimates. It’s simple. It’s reliable. It’s good. On the minus side you need some time […]

  • It’s always a difficult situation. The last project was late and I don’t mean a few days late. People did a very good job trying to rescue as much as they could but by the time you were in the half you knew they won’t make it on time. Then it comes to these difficult […]

  • Unit testing is such a nice idea. Developers create tests as they develop working software. Then they (tests, not developers) are executed during every build and it’s verified whether something hasn’t been broken over the way. Unfortunately unit tests very often doesn’t work well even when team formally boast they employ this practice. Why? 1. […]

  • Vast majority of people working on software products contact their customers directly or indirectly. Yes, software developers included. Each time we do it we play a role of salespeople. Of course customers don’t see us making product presentations or negotiating prices. What do they see then? In my case answer is pretty easy since my […]

  • A developer who sends an email to a customer to elucidate some details of proposed solution. He is a salesman. A project manager who goes on biweekly status meeting. She is a saleswoman too. A support engineer who answer for ticket submitted by one of clients. Guess what, he’s a salesman. A manager of software […]

Hi, I’m Pawel and I’m your host.

Leadership in Technology is a blog dedicated to wide variety of topics related to running a technology business.

Among others you will find here: product management, agile and lean, leadership, organizational design and more.


Search


Recent comments