Bullying

Featured

Bullying. We associate this with school, and childlike behaviour – but sadly it’s by no means limited to the school room.

People exerting real or imagined power to intimidate, undermine, control or humiliate others.

Legally speaking, harassment is when bullying is concerning a protected characteristic of the target – generally something they can’t change; age, sex, sexual orientation, race, religion etc.

I myself have struggled all my life with the impact of school bullying, watching kids being brutally bullied by others at school and my own work experiences. I’d like to share some of my experiences and advise, it might help someone.

Impact

We cannot downplay the impact of bulling. It has a massive impact on mental health of those being bullied and others who witness it within the workplace. As well as the direct personal impact, this also means you have stressed, demotivated employees more likely to leave or even actively interfere with the companies goals.

The combined stress, performance, culture, trust and communication impact in your organisation means senior leaders must take action.

From personal experience, I felt stressed, angry, unable to communicate, de-valued which all put me into a defensive posture. I hated coming into work. It was one of the most horrific periods of my professional life, and one of the main reasons I leapt feet first into Agile Scrum.

I had spent 6 years building the company from the ground up, working tirelessly to deliver the technology only to be harassed and bullied by a fellow director, who was – as it turned out – a massive narcissist. I had sacrificed time with my young family, my own mental health, risked monthly of loosing my house – only to be screamed at during monthly meetings, “teased” for my speech impediment and tripped up by rapid questioning and interruption. At the time I was too shocked to recognise this as harassment; and without HR I had nowhere to turn. Life became hellish.

So I did the unimaginable. After 6 years of sacrifice I left. My red line had been crossed, I took control and I left the organisation I helped create. It was hard to do, and I still struggle with the impact from a mental health perspective to this day.

The bully

From the point of view of the bully, they often don’t think they are indeed a bully. They may be frustrated by an individual, venting due to some other pressure and not realising the impact of their actions.

Or at least I like to think, giving the benefit of the doubt. Indeed, my particular bully actually got mad at me for calling him a “bully”, and proceeded to shout and scoff at me for the offense (which continued for more weeks). Wonderfully ironic, but it sure didn’t feel like it at the time.

Being a bully – rather than a grumpy sod – is about consistent poor behaviour with no consideration of the feelings of those around you. We all loose our temper from time to time – but a bully maintains a consistency that creates a negative spiral, with no concern of the impact they’re causing.

Perhaps some actually enjoy using the “rod” to motivate those around them rather than the “carrot”. This boggles my mind, but some people have this short term approach to leadership.

Perhaps they’re just narcissists.

The Victims

Hmm. Victims. It’s a term used frequently, but you relinquish any power to change your situation by taking the title. Don’t be a victim; take action. Shall we change how we communicate with the bully? Raise the issue with your leadership? If leadership isn’t recognising the problem, go to HR.

The most important thing is not the tolerate it, and take action. Even if that’s to walk out the door and never come back.

What can we do?

We need to stand up to harassment – bullying – in the workplace. Leaders and peers should look for signs of it and provide clear and rapid feedback to those committing it – and also give advice to the victims.

Sometimes leaders aren’t there to help – perhaps they are the bullies! Larger organisations usually have well established HR departments that can be confidentially approached by those impacted in the event of leadership failure. This is not the case for SME’s or smaller – often employees are stuck – made even worse if their leaders are the bullies.

If there is no HR yet in your company, then leave. Leaving is ALWAYS an option, even if it doesn’t feel like it.

Are you a Bully?

Leaders should also take time to consider if they are bullying; it’s easy to vent frustration or to give in to the demon of bravado and not realise the impact on your actions. As a leader, your outbursts will have significantly more impact to your sub-ordinates than you realise.

Those who experienced arguing parents will know what I mean!

It’s OK to loose your rag sometimes – but always make sure it’s an exception, not a rule – and it rapidly followed up by an apology and discussion with those affected.

Make it clear you’re angry at the situation, not the people around you.

What about conflict?

Its healthy to have some forms of conflict in the work place – healthy disagreement which is the hallmark of good, trusting teams, clear communications and a great inclusive mix of staff.

In Patrick Lencioni’s gripping “Death by Meeting” he underlines how important conflict can be during strategic company meetings.

As leaders we should encourage conflict to ensure matters are discussed to conclusion and decisions can be made with all the proverbial cards on the table. But there’s never a reason to not respect others, to humiliate and make people feel bad about themselves.

As leaders, we’re here to support, grow and make our sub-ordinates the best versions of themselves – at work and in their personal lives.

More help

If you’re experiencing bullying in the work place, do something about it. Don’t tolerate it. Here’s some links to get started.

https://www.acas.org.uk/if-youre-treated-unfairly-at-work/being-bullied

https://www.nationalbullyinghelpline.co.uk/about.html

Infinite Architecture

Bob Martin coined beautifully in his book “Clean Architecture” that software – the products we forge from our imaginations to deliver value to other humans – can be described as a combination of behaviour and structure.

Behaviour

This is what the product does; ultimately it does something beneficial for a human somewhere, even if this is several times removed. It’s features, the benefits those features deliver.

Behaviour of the product delivers the value to the customer and therefore the business owners, and is quite rightly the main focus of software development.

Structure

The products shape, or its architecture. How the components; methods, classes, assemblies and services are inter-related. The mapping of responsibilities to deliver the functional components that combine to deliver the desired behaviour.

Every product has structure – very few have a “good” structure. Good structure allows rapid change with minimal cost, championing leaving options open and decisions late (more on this later).

Structure is often thought of and presented as flow charts in 2 dimensions. However, in most cases a products structure is actually a multi-layered 3 dimensional affair, very difficult to actually envision, to share and to design. This challenge to communicate structure and it’s importance (value) often means it falls to secondary “nice to have” objective.

In the short term, structure (architecture) appears to slow down software development. An apparent pointless activity adding effort and $$ onto a usually time constrained development process.

Behaviour over Structure

Commercial enterprises need revenue to keep the lights on. That means customer value is king; and for a start-up they need to return as much value as quickly as possible. The pressure to deliver function is extreme.

The sprint to sprint focus is customer value results, with many teams being pressurised to deliver function (behaviour) over architecture (structure). For many start-ups without technology at their core, these initial developers will also be contractors embedded with short-termism. They want their month to month contracts renewed, so they need to focus on delivering what the business wants, not what they need. In addition my experience is many developers (even Computer Science qualified) do not understand the concept or importance of architecture (structure) in software development.

This leads us to an industry full of products that have poor architecture. They cannot change – cannot evolve as the customer, the market and teams surely will.

Many times I’ve come to brown field products which were a hideous, convoluted mess. Change is very difficult or impossible to deliver. What’s probably worse is the business owners had no awareness that they owned a train wreck, completely unable to change until it’s too late.

Structure over Behaviour

Is it more important to have a product that does what the customer wants, but can’t change? Or a product which does not do what the customer wants, but can change rapidly?

That’s the question we’re asking when we are seeking to understand which we prioritise; structure or behaviour.

Last year I read Simon Sinek’s amazing book “The Infinite Game“, which I highly recommend. It inspired me in my technical leadership – and I think we have a lot to learn from his thoughts in the software industry.

As software developers we should create and maintain products which are designed with an “infinite” mindset.

To develop systems which are designed to be alive, maintained and competitive decades into the future.

Structure is the first and continuously the most important aspect of a software system. We should be focusing on the product being able to evolve and change with the minimum of cost, maximising ROI of the value being delivered to the customer (or user).

What’s next

I’m going to be posting more blog posts on this expansive subject. Whether you’re a business owner or a software developer, stick around to see how critical an “infinite architecture” mindset is to a successful technology company.

Being a CTO

When I started at Flipper back in October 2019 (feels like an eon ago now) I took the time to reflect on what it means to be a Chief Technology Officer / Head of Development based on my experience at Digital Forge.

Rather than picking up a book or looking at other peoples blogs, I did what I usually do – make something up. Ultimately everything humans do that’s worth a damn is “made up” by someone (and polished in the fire of failure!) so I’m good with that. It also fits with my personality profile on 16 Personalities of a “Logician”. I’m probably wrong in some way, but *shrug* I’m happy with the result of my musings.

I wanted something rooted in the Agile Manifesto at the heart of all agile frameworks, something that leveraged my understanding of the commercials of business, and something that ties in my understanding of the importance of systems that can change and evolve with business needs.

I’ve broken the role into 5 areas. If I was click-bait I’d put them on a separate page covered in adverts for making money at home, but we can be better than that. *<:OD

People

You may be surprised that I – of all people – start with fleshy meat bags. It is all about the people actually, the technology is secondary and detail. Motivated developers, who have fun doing their job, delivering high value, well designed change return a far better investment in terms of value to the business. There’s a mind boggling number of things to consider to create a motivated, happy, high performing team (or teams) – especially to someone like me – but it’s the core of what we’re going to achieve (and across the business I might add).

This piece boils down to team (fostering a high performance, cohesive, collaborative team), growth (couching and mentoring, personal development) and morale (getting up in the morning excited to come into work).

Enabling Change

This is what true agility looks like. Bonus points for naming the game πŸ˜€

Businesses never stand still – like a small mammal evolving 100 million years ago – if it stands still it’s dead. It’s incredibly important a company (and it’s product and services) can change as a result of the various influencing pressures altering it requirements / objectives. Even if we stand still, the market, regulations and customers never do… so we must be able to change, and sometimes rapidly.

Agile provides the framework from a process perspective, but that’s just 1/3 of the equation. It’s also the people (above!) and the technology.

From a technology perspective, change is about the architecture of the products involved; their shape – often multi-dimensional (those flow charts you get shown only cover one perspective) they should be designed with separation of concerns and SOLID at their heart. This reaches into development, change control, quality assurance and testing, CI / CD deployment and ongoing maintenance and support.

I’ll talk about enabling change in business across several other blogs, its a deep and interesting subject to me.

Return on Investment

Getting the balance right!

Certainly for service and technical industries, development and technology forms a large part of their operational expenditure. It’s really important what we spend our time doing is returning at least equal (and usually more) commercial value back to the business and crucially the customer. If it doesn’t there needs to be a damn good reason why not (strategic, long term goals outside the usual budget rhythm).

For me, a key part of this is prioritising work frequently (also know as constantly) and ensuring we’re recording the cost and value of change. We need to plan long term, seeing the “infinite game” to make sure we’re not working ourselves down a dead end, causing us more, far greater costs in the future (Technical Debt!).

Having a great relationship with the business and the customer is critical to figure out prioritisation of work and thus return on investment.

Another key part is optimisation and efficiency. That doesn’t mean squeezing every drop of effort from our developers, that’s a fools strategy. I mean making things slick, cost effective and fun for our teams. Chop out the unnecessary process and bureaucracy, review licence costs and processes on a routine basis. The sprint retrospective is a great example of this in action.

Operations

Handling general requests from the business, monitoring the service, raising BI data to the business etc etc. We need to make sure what we deliver is running well, as expected and the business has the data they need to validate their past and future decision making.

I must say, I love a good dashboard. Getting telemetry right is hard to do – but when it all slots into place to provide a tangible representation of your systems, they can just come to life in a way that gets the IT / developers really engaged and excited.

Maybe that’s just me.

Security & Compliance

The most boring part of the job. Sure, security can be fun – and it’s certainly part of the job creating robust, secure products.

Compliance just sucks – we usually have to do something because some third party is making us do it or the company would have to pay X; they seldom actually make sense alone, or don’t actually form part of our priorities if it wasn’t for the big stick waiting to clobber us with hefty fines.

I feel for those in Financial Services, where this is a big part of the job.

TLDR

Thanks for making it to the end – let me know your comments and the bazillion other things I’ve missed out! πŸ˜€

The Good, the Bad and the Advocates

Customers. We all have them, whether our products are in retail, commercial, B2B, internal or public sector. Traditionally we’re told to always treat them as if they’re right, and to do everything to make their experience with our product second to none.

In my time being coached by the guys at Action Couch I learnt about the different value customers can give to your business. By value, we mean how much return on investment do we get maintaining that customer. Let’s break down our customer base into classes A to D.

D Customers

These guys are a pain. They constantly complain, putting strain on our service / support teams. We all know the type – and we also know these guys take up the majority of the time of our support teams / services.

C Customers

We never hear from them. They’re good as gold, but they don’t do anything for us – other than the fees / subscriptions, we get no return on our investment with them. However, since they don’t call or interact with us they cost us very little to maintain. Most customers are class C.

B Customers

These customers communicate with us via our support services from time to time, and we expend some effort to maintain their custom. They’re satisfied with the product, but they don’t talk to others about it – they aren’t on fire for us. Note these customers present the biggest opportunity to change to advocates, since we interact with them via our service desk / support.

A Customers

Your advocates. They sell your product for you – telling anyone who’ll listen about how great your product is. They stick up for you, post on your community forums and love getting involved. They positively impact your teams moral, reduce your operational costs and actively generate new sales. We can probably all think on a product we love as an advocate – if one of our friends asks for a recommendation, we’re the first to spend 5 minutes explaining why we think it’s awesome and they absolutely should use it.

I can’t over-sell how important Class A customers are. No one has more influence over a sale decision than a trusted friend; the best, most expensive marketing campaign cannot even come close. Sure they can only influence their friends, but it can become exponential if new customers can be shifted to Class A as soon as possible, as efficiently as possible.

Thinning the herd

As a business it seems counter intuitive to remove customers. But that’s exactly what you need to do on your Class D customers – they’re costing you money, demoralising your team and creating bad reputation. The trick is doing this without effecting your reputation or giving them more ammunition. Make sure your T&C’s allow you to terminate customers easily, have a good, fair refund process in place and make sure they leave with a positive experience (a gift of some sort?).

Love your Rock Stars

We all want advocates, or we absolutely should. Creating them and maintaining them as crazy zealots can itself be time consuming, but it needn’t be. I’ll go into techniques you can use to transform your customers to Class A – revenue earning, moral boosting super sellers in a series of blog posts.

Avoiding Boxes

Of course this type of categorisation needs to be taken with a big pinch of salt. Though boxes help us understand the world quickly, people seldom fit in boxes – and if they do they have a habit of jumping out of them. Just remember an Advocate can quickly become your worst customer if you break your trust contract with them. More on that another time.

Summary

Spend time knowing your customer base. Take steps to promote customers from D to A, or be brave and drop those expensive D customers.

You’ll see the benefits of increased revenue, a better motivated team and greater operational efficiency.

Teaching an old dog new tricks

I was meeting up with some old, long in the tooth friends of mine the other week. One of our member works at a very large “High Street” bank in the data warehousing and presentation teams. They’re employ a lot of young graduates, usually the crop of the available guys and girls coming from top establishments.

These guys burn brightly, are full of ideas and ambition. He loves working with these younger team members, and believes its the future for organisations.

We then naturally went on to talk about how old duffers like ourselves can compete / contribute against such bright, gifted individuals who require a fraction of our salary and packages. The talk about Generation Z, Y, X etc came up, and how Z’s and X’s (the latter being the “millennial’s”) are so much better in modern work places than our generation.

One of us even suggested that at our age (45+, I’m the baby of the group) it’s impossible to learn new behaviours, mind sets and skills.

I personally took insult on that one. I’m potentially competing against younger candidates for jobs – am I really now obsolete? Can I really not learn?

I think the difference boils down to how we handle the feeling of change. That knot of anxiety in your gut when you’re doing something new, talking to someone new – basically pushing outside your comfort zone.

I was once told to welcome that sensation – “Congratulations, you’re changing!”. It’s a great attitude, and leads to a personal internal culture where change and personal growth are embraced.

Young people – who lack experience – are constantly out of their comfort zone, more or less. Many times in a given month they’ll experience that feeling. Many still run from it, but many also get used to it or even (the best of us) embrace it. They are exposed to the sensation so much because there comfort zone (made by experience) is so small.

Old duffers like myself have either a wide comfort zone through experience, or a limited but extremely well trodden zone, probably fenced with barbed wire and with earth packed down as hard as concrete. The latter are specialized individuals (“I only do SQL”), the former are “jack of all trades”. Of course many people will be somewhere in between. We don’t tend to leave our comfort zone nearly so much. The feeling of change if uncomfortable and scary and probably not necessary. So we turn around and return to our comfort zone (resist change).

This is when you get a problem. But you don’t have to be like this. As old buggers we need to recognise and internalise;

  • We must constantly change to grow.
  • We must grow to stay competitive and meet our potential.
  • To embrace that “feeling of change” – the anxiety we feel when leaving our comfort zones.
  • We truly know nothing. Feeling you already know something prevents you learning.

In the last 4 months, as my journey hits multiple new cross roads – I’m getting this sensation weekly. Change is hard, but embrace it. Welcome that sensation – Congratulations, you’re changing!

This old dog can learn new tricks, can you?

Sleep

In my time working as an entrepreneur nothing has been more central to my day to day success or the general cadence of work and motivation than sleep. And yet time and again I’d sabotage myself by not getting the sleep I needed – either working late or “rewarding” myself with a long gaming session on a weekend or evening.

It’s important to reward yourself and get a good work / life balance of course, don’t do it at the cost of sleep. Though that takes willpower I often lack when it counts.

We watched an excellent TED talk by Matt Walker about the importance of sleep in our lives;

In it Matt explains that the brain must undergo a process which only occurs in deep sleep to transfer short term memories amassed during the day into longer term (I assume mRNA based) memories. The transition of memories from short term electrical impulses to chemical / physical substrates has always fascinated me, but one for another blog.

During deep sleep these “spindles” of electrical activity are believed to be the coding of memories to these longer term storage methods, purging them from the hippocampus (which presumably keeps these electrical / transient memories running around and around).

Following this purge the ability of test subjects to absorb new information was increased by 60% (in the video he talks how those without good sleep did 40% worse, but conversely those with sleep did 60% better than those who did not. Unless my maths wrong, which is highly likely).

He then went on to explain how important deep sleep is to the immune system – and how the world health organisation has identified lack of sleep as a possible carcinogenic. That’s pretty mental. “I can sleep when I’m dead” is actually around the wrong way, and should not be the mentality of hard working entrepreneurs (or for that matter, gamers!).

So, get your sleep. Set a regular time to get into bed so you get your circadian rhythm on your side, and steer clear of coffee after mid-day (I bloody love my coffee, *sigh*). Don’t have a different time for weekends – your body doesn’t understand breaks in your rhythms like that. Don’t drink booze at night (GOD DAMN IT).

If you find yourself tossing and turning over your latest challenge, change something in your environment. Strip off. Change beds. Go sleep on the sofa. Open a window. It gives your body and mind a little reset / kick in the chuffs (a gentle, caring one).

Which delivery framework?

Should your business run Agile or Waterfall (sequential projects)? Quite often the answer isn’t black and white, and should be answered based on the characteristics of the problem / project/ situation being tackled.

Dave Snowden created excellent Cynefin framework in 1999 while he worked at IBM. I was lucky enough to meet Dave briefly at the IBM Technical Council in 1999.

The framework helps organisations understand scenarios in the world and how best to handle them / map them to frameworks.

Sketch of the Cynefin framework, by Edwin Stoop

Scenarios can be broken into one of the 4 domains. Until we decide on the domain we are in a state of disorder.

Complicated domains are not “simple” to do, but have certainty to complete their goal. Experts are available to provide insight and knowledge, removing uncertainty. Documentation is available and requirements can be determined up front with minimal risk of change during delivery. A service provider delivering “off the shelf” third party products exists in this domain – for example installing access control hardware. Waterfall is better suited to this domain.

Complex is where the problem is clearly full on uncertainty. No one has done what we’re doing before – no experts can be brought in to tell us what to do. We must work to remove uncertainty through exploration (sense / probe). Software development is typically in this domain. Agile is better suited to Complex domains.

Simple domain are highly scripted, well established and can be performed using best practices. They have little to no uncertainty. A highly repeatable sales process would fall into this domain.

Chaos is out of scope in this discussion, but does come into play with support triage / bug handling in the software / service environments.

Often organisations find themselves with complicated and complex projects in parallel or related to each other, which is fine and natural. Sometimes large customers don’t want to work in Agile frameworks, so it’s necessary to wrap internal Agile processes with waterfall like wrappers (though not recommended!).

The important thing is how the company chooses their core framework. What framework should be used to direct their ethics, their culture and way of working with customers? That’s really up to the board to determine, but in my opinion Agile leads to far more positive work environments where staff feel valued and excited about their work; customers are happier and more likely to be advocates, shouting about your team from the roof tops.

So long, and thanks for all the fish

Two weeks ago I was removed from the board of a software company I had spent 6 years building, through long days of blood, sweat, tears and personal sacrifice. I created 3 enterprise level, unique products that were selling well.

I’m OK with the end. It’s time to move on. But it’s hard to say goodbye to code, systems and a great team I’ve put so much of myself into.

So what went wrong?

Ultimately, the end came about due to a fundamental culture mismatch causing a dispute between myself and one of the other directors – let’s call him C (there were 3 of us, always bad news). The second director in the middle (let’s call him B) was – though very adept – often changing his mind when discussing things with others around him. He had a low opinion of himself, and often didn’t trust his own instincts and views. Combined with the personal friendship and the hostile communication techniques from C, B just towed the line of C. So that’s bad news for me – any dispute would be 2 vs 1.

So what was the dispute?

I came from a software architecture background, and from the start in 2013 we worked using Agile methodologies. With 1 developer, there was only so much you could adopt without it being a little silly – I was product owner, scrum master, developers etc, so much of the machinery of Agile frameworks wasn’t of use. The important thing was knowing what to work on next and working in a time boxed way, and working closely with the customer.

I was big on transparency (release notes, being honest about bugs etc) and delivering what the customer wanted over what was agreed up front.

As the team grew in the last 2 years we extended the Agile approach, but lost our foundation in the Agile Scrum framework. In hindsight I should have re-grounded us at that point as an Agile company, and all the re-affirmations to our culture that needed.

At the start of this period C came on board full time, after waiting for the products to be sufficiently finished in relative low risk safety of his existing employment. He came from a consultancy and hardware installation background, where services are black boxes taken from the shelf and installed. He had never heard of Agile, and worked using Waterfall / sequential delivery techniques (as is right in that problem domain).

We should have discussed this then – should the company be Agile? What is Agile? etc etc. That never happened – I’ll take the blame on that one. Instead C took 12 months working on a pointless pitch deck (we had expired our EIS qualification by that point) where he eco-chambered his own beliefs into pretty presentations, backed up by Gartner and industry leading statements from other service providers (note, not software developers).

A year ago (October 2018) an argument came up in the office where I stated we were a software company delivering software products. C believed we were a consultancy first, who happened to do software products. I walked away grumbling, but I should have pushed for resolution on that fundamental (and very damaging) differences in direction – more importantly a change to the companies previous direction.

C continued to push the consultancy / services angle, stating in the last 6 months that the Sale was the single most important thing for the company.

Crucially, B and C failed to attend any internal meetings, Sprint Planning or otherwise – since it’s not a software company, why bother?

Many disagreements occurred between myself and C, where he continued to sell things we simply didn’t do, moving into new markets continuously, putting pressure on our tiny support and delivery capabilities. He had no appreciation for the time and effort my team put into software development, frequently sent rude, belittling emails (just do it) – basically acting like the atypical nightmare boss. Bear in mind I was a fellow Director. He refused to engage in tabled meetings, ignored emails or flat our lied to customers or my team (many written examples, all ignored by B). Of course, simple incompetence can look like a lie, but I’ll give him the benefit of the doubt here. When he did attend a meeting, it often broke down into C shouting abuse at me or attempting to “trip me up” and humiliate me. Often work had to be prioritised based on these tantrums.

Enter the last straw. After many disagreements separately, I was engaged in an open conversation with a customer. Though I’d spoken to this customer on a weekly basis, his expectations always seemed on the high side. I advised that there will be bugs as they were an early adopter, and we’re working hard to address the issues (which he knew). Enter C, telling me to stop talking to the customer (as Head of Development!). This was because he had withheld that the customer was an early adopter, leading to the unusually high expectations. Suddenly it made sense.

Another argument kicked off, where I suggested the company needed to split into consultancy and software, so the toxic combination of these conflicting cultures could be resolved. As a minimum I suggested the following as a company manifesto of conduct (this never got hashed out, so apologies if its a bit messy).

  • We are polite and respectful to each other. 
  • We listen and value each other’s opinions. 
  • We interact with honesty, transparency and integrity. 
  • We treat each other as equals, regardless of our position. 
  • We lead by example. 
  • We encourage and build each other up. 
  • We work to foster a positive working atmosphere.
  • When we provide critique, we do so positively and constructively. 
  • We sell to need, but sell often. 
  • Existing customers are more important than sales. 
  • Staff and their well being are more important than existing customers. 
  • Internal meetings are more important than customer meetings.
  • We deliver what the customer wants, continuously. 
  • We foster transparent, friendly relationships with our customers to better capture feedback. 
  • We follow the Agile development disciplines and project delivery techniques. 
  • We accept it’s OK to fail. We learn, we resolve and we improve.

2 weeks of no communication (emails ignored, messages ignored, phone calls ignored) I’m called to a meeting by a third party.

I had turned up to the meeting with handouts to discuss culture, the manifesto and direction, and how we could promote better team work at the board level.

B and C are there, and I’m told by the third party that they had voted me out of the board. They utter not a word for the duration of the meeting. A hostile take over basically, rather than actually have a conversation about a reasonable manifesto. Complete madness.

I think C expected me to stick around as an employee, but that wasn’t going to happen. I did the right thing and handed in my resignation, effective immediately. I was calm and walked out without shaking any hands (C actually offered his hand, unbelievable). I could have done this differently and had them for unfair dismissal, but the outcome would have been the same. More importantly and I was able to leave with my dignity and move on; you can’t put a price on that.

And so here I am. Culture mismatch and my own shortcomings recognising the importance of alignment early on.

The developers have all left with me. I’m proud of the team and the products I built, and wish them all good luck in their future.

I wish B and C luck. Running a software company using Waterfall / sequential development driven by sales and specs rather than what the customer wants is going to end in tears, but I’ll let them find that out themselves.

I owe them that much.