Author: Pawel Brodzinski

  • My Biggest Mistakes

    Have you ever wondered what were your biggest mistakes in your professional career? Which things you should do another way or at least try to change? It’s usually easy to judge others, especially looking from a perspective of time. Hey, he shouldn’t have left the company then, because now he’d have been promoted at least twice. Easy to say, because it’s about him and you know exactly what happened during those two years after he left. Back then the decision probably didn’t look like a mistake.

    With the same schema we can judge our own decisions, however it’s much harder. First, for most of us it’s difficult to accept that we actually made a mistake. Second, it’s even more difficult to be unbiased when you consider yourself and your own actions. Nevertheless it’s worth a try.

    There’s one thing more – people usually tend to share with others their successes, not failures, so your own experience is even more precious – you have unlimited access to it. You won’t find a lot of “failure stories,” so I thought I’d share some of mine.

    Personal interactions

    When I was leading a support team I had a couple of conflicts with developers partially based on personal background. I thought that if I’m so dedicated and if I struggle to do my best everyone should too. It’s not so hard to imagine that it was rather naive point of view (we worked in a corporation then). Instead of letting other managers to resolve the problem with their people I was making my private tiny war. E.g. we did some performance tests to prove that one of developers didn’t make optimizations, just to show he’d ignored the task. Why didn’t I ask him if he had done that and spent much time for useless tests? Bah, don’t ask me now. You should have asked me then. I can recall several similar situations, all of them having source in my personal likes/dislikes and resulting in, let’s say, not optimal business decisions.

    Building a team

    I was once a department director, building a team and a product from a scratch. By the way it was a great job. I think my biggest mistake then was too slow promotions within the team. For me it’s very hard to promote someone unless I’m completely sure she’s the right person. However I should overcome my resistance instead of waiting too long before official promotion for a couple of the leaders. Not mentioning that I didn’t even thought about potential successors of any of the leaders. Subconsciously I tried to direct my people through the way I passed once: first informal role of leader with real manager controlling whole team and then eventually getting own team and formal managerial role. Unfortunately, I and one of my colleagues changed the job leaving over a dozen of people with no junior and middle management. The promotions were soon carried out, but with people rather unprepared to managerial role and little supervising it wasn’t a vast success. Some time was wasted too.

    Communication with sales

    As a manager of operations team (development, implementations, quality assurance and project management team) my biggest mistake was poor contact with several sales people. I know there’s always a conflict between sales and development, but I’m far from thinking that the technical side is the one which is infallible. Quite the contrary, I even wrote that in general it’s better to have a business person as a CEO and sometimes having a geek as a leader of a company isn’t a great idea. I know all of that, but still I haven’t managed to be on good terms with few sales. And by now I still don’t see how I could get it done right with those people. I’m not even sure if it was possible. Maybe more time has to pass and I’ll find out the answer then. Maybe our characters are too different and we hadn’t even a chance. Nevertheless, the fact remains, it’s my failure too.

    Choosing an idea

    I was working with my friend on a piece of software. Whole thing was intended as a micro-ISV idea, but none of us decided to leave everyday job. In this case our biggest mistake was choosing an application we worked on. It’s not about a market for the application – I still believe we had a chance. It’s about our attitude – we had little fun while working on the software we’d chosen and we reached the point where none of us was still motivating himself, not mentioning about motivating a partner. The software died unfinished. We’d chosen the application only because some of work (part of the code) was already done, so we thought it’ll take much less work to finish. Now I think we had about 5% of work completed, so the choice wasn’t a well-thought one.

    Depending on situation my mistakes were followed by different consequences – in the first situation results were negligible, in the last example whole initiative ended up as a failure. It’s just a bunch of examples, but I can think about a list of others based on both my experience and my observations. Generally, it’s not shame to err – making a mistake once is an occasion to learn, but making the same mistake twice becomes a stupidity.

  • How to Make Decision with a Team

    Short but very interesting discussion with Piotr followed my post about leading a team of developers. Piotr accurately pointed that a leader should listen to his team and the team should participate (more or less) in decision-making process. At least that’s true in most cases.

    Despite the last word belongs to the leader, the team should feel they’re important. They should feel their opinions matter. They should feel the leader wants to listen to them. To be honest, more important is what they feel, not what’s the truth. Even if the leader doesn’t really listen to the team he should try to create impression that he does. That’s better than nothing.

    When I was learning the MSF, one of sensible yet surprising principles was that there’s a team of peers and every decision should be made by achieving a consensus. That’s of course utopia, but if by any chance you’re able to proceed with a decision in this way, you should. Even if it’s easier just to force your opinion.

    How to make the decision with the team then?

    • Ask teammates about their ideas, not suggesting them yours. This can give you fresh look on the problem. You aren’t a smart Alec (oh, if you believe you are and you’re still reading – give up the rest). Someone from the team can have a better idea.
    • Encourage them to contribute. In many cases if you don’t directly invite your teammates to participate, they won’t find enough courage or will or whatsoever and they won’t even say a word.
    • Discuss all ideas with the team. You’ll sometimes find that people would have changed their mind after discussion. Even on their own ideas. That’s much better than telling him that their concepts are worthless. Even if they are.
    • During discussion drill down every idea until you feel you understand it. If something is ambiguous let it be explained. If explanation is ambiguous too – drill deeper. Force them to drill with you (that’s what my boss keep asking me to do and believe me – it does work).
    • Think about all possibilities and make the decision. Team of peers is nice idea, but unless the choice obvious or there’s countless amount of time to discuss, someone just has to make find the way out. You won’t guess who it could be…
    • Communicate the decision but give reasons for it. If there was another hot option that was turned down motivate it either. People should know what the motivation behind the choice was.

    Sounds easy? It is not.

    • Usually you don’t have enough time. Not enough for discussion. Not enough for thinking it over. Not enough for managing all risks.
    • Sometimes not every factor can be known by whole team. Especially when decision is rather organizational than technical. In this case you can have your team against you. Even if you’re the one who is right.
    • Sometimes you don’t have your own opinion and none of provided ideas is convincing enough. Choose one and act like you were convinced, then. Your team needs convinced leader.

    If it was easy the leader wouldn’t be needed.

    Feel free to add something to both lists (especially to the first one).

  • Almost Completed

    One of projects I’m contributing to is a micro-ISV service. Maybe it’s not the perfect example of micro-ISV, because at least several people are engaged. It’s not single-person business, but the basis is the same. Whole idea was in its origin a world-changing service (or close). The main person working on the idea is a guy who loves it and strongly believes that the service will be great success. The rest of team keeps adding new brainstormed ideas to current concept, keeping ourselves on fire.

    Just like most of micro-ISVs. Just like most of micro-ISVs which failed. I wrote some time ago that faith and will to contribute in the long run are essentials when trying to build a product or service as the micro-ISV. But that’s not all. Another factor which is probably even more important is consistency.

    I’ve seen different “micro-ideas” (like you can call micro-ISV’s ideas for products or services) which had potential at least to earn for themselves. I played my role in those projects as a co-author, as a supporter, as a user. Range of ideas was wide – from a very fresh look on Internet entertainment services to yet another communicator. All of them I can call (more or less) failures. None of them fulfilled author’s expectations in area of revenue, number of customers or users etc. Many weren’t even born to be shown to the world – they died during pregnancy.

    When you have your application completed in 90% it’s usually much less than halfway to successful release. And when you’re 90% completed all the fun is the past. You developed the most enjoyable and the most challenging parts of a code. You exploited all your creative ideas during design. Now you have to focus on boring little improvements of website. Now you have to force your creative soul to think how to make your customers happy instead of thinking how to enjoy yourself with the work. Now you have to fix all those unrepeatable tiny little bugs which allow your frustration to grow. Now you have to deal with The Boring Time. And if you allow yourself to become bored – you lose.

    90% of completeness is just the beginning of the road. In this case 90% finished often means 100% failed.