August 3, 2013

Beacon Technology Part 2

Tags: ,

Part 1 is available here

After a year at Beacon Technology I was fairly comfortable and looking towards the future. Halfway through a part-time MBA, I had been promised technical team leadership on the next project. It was the start of a new millenium.

Initially, things got even better. I was given a solo consulting task to suggest an architecture for a local telecoms firm. They had a couple of interesting technical issues that were resisting attempts at a reasonable solution. I spent a few days just thinking about their system; eventually realising they were trying to solve 3 problems concurrently. By decomposing the system into its constituent parts and then combining the results the whole became much simpler. Everyone seemed pleased and a soon after I started as team leader on a project with the same telecoms firm.

Our job was to create software to support a new mobile phone product from online sales through to billing. It was a Multi-level marketing product – customers could sign up other customers and receive a small percentage of any money paid by them. It didn’t sound too hard and I was fairly confident. However, there were a number of risks. Although there was an experienced team and project manager working with me, I was a new technical team leader (of course, I didn’t think that a risk). The telecoms firm hired a graphic design company we hadn’t worked with before (rather than our preferred supplier). They also required us to use Zope for the front end, despite no one at Beacon having any experience with it (normally we used Java technologies). The client was also new – they formed a few years previously and rose on the back of growing demand for mobile phones. Everyone at the company was busy – their growth outstripped even ours. This was their project manager’s first project, being a couple year’s out of university and recently being promoted from the call centre – he was smart, but inexperienced in the position.

The graphic design firm caused a number of political problems. They had recently expanded from just doing design to also producing websites (as everyone and their dog seemed to be doing in the dotcom boom). It turns out they quoted for the whole project, but lost the contract to us. They didn’t give up that easy! They offered to host an early requirements meeting that focused on design. I went as the sole representative of Beacon along with two people from the telecoms firm. On arrival we were all ushered into their conference room with their design team, website developers, project managers and a company director – about eight people in all. They spoke about how they could do the project faster and cheaper than Beacon. The client’s and I tried to steer the meeting back to the agenda, but they would not be distracted. I can now empathise with people trapped in time-share sales pitches. The telecoms people thought it was funny and afterwards assured us that the work was ours.

At the next design meeting the whole Beacon project team and senior management team came along, as did the telecoms firm’s senior management. Around 20 people crowded into their conference room. The design firm tried the same tactic again, but this time the client’s COO said the matter was not open for discussion and he just wanted to get the design sorted. We then all proceeded to eat and drink so much tea, coffee, orange juice, biscuits and doughnuts that I wouldn’t be surprised if the design firm made a loss on their contract! Subsequently, the design firm behaved itself, but never did more than the minimum. I heard a couple of year’s later they had gone bust.

Writing Use Cases was the first task. We immediately hit problems. The client didn’t have a solid idea of what they wanted. The UCs changed every time we spoke. Much of the information we required was not forthcoming. The developers got started on some backend functionality that was unlikely to change. However, the plan began to slide a little as documents were continually rewritten. At this point the project manager got sick and was out of the office. I was on my own without significant oversight. I started making mistakes.

This project was hugely important to me. It was the first time I was technical project leader and I wanted to prove myself. I was ambitious and doing a part-time MBA that further fuelled my ambition. This project was the first step up the ladder. I needed it to go well and mentally invested in its inevitable success. As is often the case, this bravado masked my own uncertainty. Unwilling to accept any impression of failure or weakness, when problems arose I attempted to control them myself. Never risking pushing back on unreasonable deadlines, or asking for help – either might imply I was incapable of doing the job required. Of course in retrospect I realise my ego was preventing the proper focus on the success of the project, irrespective of my own success. The project should come first, that makes pushing back or asking for help a great deal less scary. I had learnt that lesson by the next time I led a team, but that was 18 months later, in a different country and at a different firm.

With the UCs still changing daily and the developers quickly approaching the end of their groundwork tasks, I decided to tell the clients we needed to signoff the requirements. This seemed to work – they quickly agreed the UCs were complete and we should start the project development. Then I was admonished by one of Beacon’s for trying to get UCs signed off. At the time I thought this unfair; it had worked after all. He said that I had a false sense of security. The changes would not stop, they would just pause for a short time until I was less prepared for them. He was right. If the client is unsure of their needs, treat it like any other project risk and manage it. Crystallise their thoughts by producing a prototype or rough early version. Plan for changes, and encourage those changes to arise as early as possible.

As we created the system over the next couple of months, the flood of changes didn’t abate. Our lack of experience with Zope also began to tell. Progress started falling well behind plan. I worked to bring it back on schedule. Also the project manager just got sicker and sicker. He spent increasing time away and I started doing parts of his job in addition to mine. This increase in work coincided with the busy part of the semester in my studies. Just to top it off I had to move out of my flat and find a new place to live. The hours got longer as I tried to bring the project back under my control. Between work and study I was always doing more than 80 hours a week – often higher. This carried on week after week. Tired and stressed – I found it increasingly difficult to sleep at night, but keep falling asleep at inappropriate times (at the library, on the bus, once in a lecture). I became more micromanaging towards my team – why wouldn’t they work as hard as me? This was unfair. They were working hard, and becoming unhappy. The project was becoming a deathmarch.

Eventually one of the owner’s stepped in. He said there were problems and apologised he hadn’t spoken earlier when the project manager first fell ill. It wasn’t realistic to expect someone new to team leadership on what was clearly a difficult project to work without a manager. The team was complaining and the client was concerned. He nicely said I was clearly being overwhelmed and needed help. He was completely right again, but I still felt like a failure.

Other staff came onto the team to “advise”. A new manager was appointed who immediately told the client that all the changes meant they needed to descope or that the project would be late. Over the next few weeks the project got back on track with everyone’s help. The project was delivered – about a month late. The original manager recovered. I found a place to live, finished the semester with good grades, and stopped being so tired all the time. I worked on maintenance and then moved off to another project at my request (I’d had enough after 6 months on it). The client hired Beacon for more work and was quite happy with the result – it even won some industry award.

I was spent and burnt-out. I didn’t want to work at Beacon anymore – it was the scene of my failure. They said I would be a team leader again on my next project, but I wasn’t excited. There was no joy in programming for a while. I hoarded my holiday allowance and let it build up until I could take six weeks off work and planned a round-the-world trip. The company wasn’t impressed I would be away so long, but they let me go. It was a good trip, but when I got back I knew I had to leave Beacon and find work abroad – I quit two months later. I remember the first few days after getting back I did not dress appropriately for the office (jeans and T-shirt). I just didn’t care. The owners had to remind me to be more professional.

There was one possibility that could keep me in Perth – product work. I had long agitated at Beacon for the owners to create their own product rather than just consulting. The owners were not unreceptive. During the dotcom boom, people would regularly come to us with product ideas and look to become partners. I did a technical analysis of one such project – an online maths system. That never happened and neither did any of the others, normally the idea man wanted too much just for having an idea, and much more money could be made consulting with no risk.

Just after I got back from the holiday, Beacon announced it was purchasing a product company. For a few seconds I was intrigued. It was a client others in Beacon had worked with previously. They sold a program to create and manage store signs. I soon went back to my plans for leaving. I also tried to convince some friends to start a computer game company, but my pitch was not very persuasive – no one was interested.

There were a few other notable events in that last year. Beacon joined an inter-office sports league and gave everyone company tshirts. I ran around a few times as part of the (non-)competition. It was fun and we all got along. I still have mine. There was also talk of the owners giving shares in Beacon to employees. I think it was in response to people being dazzled by the options available at fast growing dotcom firms. I asked what the exit options for shares were (as illiquid shares are near worthless). The owners misinterpreted the question and replied they had no intention of exiting the company and they would be around for years yet. They seemed pleased at the chance to say this, so I didn’t clarify my question. I was fairly sure I would be leaving and thus wouldn’t get any shares anyway.

Technical annoyances increased as the company expanded in that second year. The Microsoft Outlook email servers died on us a couple of times. Similarly the Microsoft Visual SourceSafe databases got corrupted once. I have tried to avoid both products since whenever possible as the disruption both caused was massive. Also the air conditioning died and took a couple of days to fix. It is surprising how much heat comes off a room full of PCs.

Come the end of 2001 it was time to go. I felt my Perth options had been exhausted and I planned on moving to London. When informing the owners of my decision I used the word “banal” to describe the work Beacon performed. The owners really picked up on that and repeated it a few times. It wasn’t a fair accusation. I doubt I would have found any work interesting at the time. After the telecoms project, I just didn’t care. It took the half year break while moving to London for my love of programming to return. Beacon is probably the only company that treated me much better than I treated them (at least over that last year). They even paid me a performance bonus when I left.


comments powered by Disqus