The Benefits of Disruptive Incompetence

In my first job after graduation, I had a boss with no formal qualifications who had not only a technical flair, but the leadership skills to share a vision & make people follow. He was also very opinionated. I remember him once saying of the engineer that oversaw the draughting office that he should be promoted or fired, on the basis that he was doing nothing where he was.  Anytime that engineer visited our project team, we'd smile, accept his latest 'brilliant' idea, & wait until he left before we pulled it apart & did something better.

However, I suspect that, without that bad idea, we would have continued on along a steady path of acceptance that what we'd been given was good enough. We knew it wasn't, so we did it ourselves to prove a point.

Disruption is good.

I don't say that lightly. Not distraction, disruption. A change in requirements often makes you rework the solution. Knowing that there are always changes to requirements makes you rethink your approach to making a solution. That's rarely going to make a worse solution. It makes you, the team, the deliverable, the process of development, all more resilient, both in terms of the deliverable & the quality of the artefacts.

Way back in the 1960s, IBM was a powerhouse of thinkers. Not just that, they delivered some extraordinary ahead-of-the-curve hardware. They did it by working through the night, being over budget, getting burnt out, & basically doing everything we are told good project management avoids. It is a well known fact that, since the introduction of good project management, IBM has produced nothing close to that kind of innovation.

When a bunch of middle-aged white guys got together to define Agile, a new way of working in software development, their aim, was to get a team to a point where it was working at peak efficiency for as long as possible, which usually means achieving a steady state: knowing what you can produce, committing to that, then delivering. Changes in requirements, etc, will always mean changes to either the deliverable or the timeline, because the steady state allows for no third option, where everyone puts their personal life aside & the project succeeds or fails by the original expectation.

Morality gets in the way of innovation. Social responsibility is not compatible with wonder.

Now, I'm trying to avoid saying that I want to force a team, or be part of a team, to over-commit & then burn out trying to deliver the impossible. I don't want that. Any honest executive does.

However, what works is the bit of grit on which the pearl is formed, the itch that keeps you scratching until you come up with the idea of flea powder (or bathe), the idiot who keeps interrupting your flow to ask 'hey, have you thought about this idea?'. Every so often, it's not the idiot's idea, it's their asking that triggers something in the creative genius (common or garden engineer) that sparks a conversation that leads to questioning assumptions that leads to redefining 'correctness' that leads to a late night session where no-one dares to go home unless they miss something that will change the world.

If everyone believes the same things, then no-one will learn anything new. If everyone thinks the same way, then no-one will produce anything new. If everyone agrees, then there can never be anything new.

Disruption is good.

Don't go out there intentionally disrupting everyone & everything, but be more open to the process of disruption.

I worked with an excellent executive once, & we were strategising how to build a brand new team that would create a new product based on a prototype. Selection was based on 60% technical match, 30% team fit, & 10% being a good person. In his experience, you only needed one bastard in the mix, & that was going to be him. Role filled. Move on.

He was the disruption. He was not a technical visionary. He was certainly an excellent leader, but I'd never seen him build anything. He was also a good corporate tactician. That team, which stayed together as is for more than a year, but many of whom remained for several years, backslid to producing mediocre output as soon as he stepped away from the role.

I will admit to my own failing in not being disruptive enough when I stepped in as designated bastard, having designated myself bastard on a different arm of the business in the meantime as a technical person with almost no grasp of market analysis.

Again, I stress that being the disruption is not essential, but being able to recognise the disruption & their role in kicking the project forward - or sideways - is key to delivering surprise & delight to your stakeholders.

The Interview Maturity Model

 A long time ago, the Capability Maturity Model was a thing, & it laid out a framework for how to measure an organisation's 'maturity' - how it had grown as an IT company to be considered 'capable'. I know, that's a lot of rabbits. It was supposed to encourage rogue IT professionals to think about their processes, & for company administrators to set achievable goals that improved the processes. At the highest level, very few companies achieved CMM6, or at least very few would advertise it, & those that did were doing so for bragging rights or were in a competitive market (like consulting).

Today, I am unemployed, which means I'm bored enough to think about interviewing from the receiving side. I've done a lot of interviews from both sides over the years, so I think I'm in a fair position to judge technique as much as assess effectiveness.

I am willing to propose a simple model for gauging the maturity of an interview process. Although I have the IT industry - or IT professionals - in mind, I am sure there is some equivalence that can be extrapolated.

• Level 0 - no process. You interview so rarely that each position is 'unique'. There's nothing wrong with that, but you could invest some time into thinking about the effectiveness.
• Level 1 - a repeatable process. You file an outline of an interview, perhaps with questions related to different roles.
• Level 2 - a delegate-able process. One person holds the process & others implement it. The process can be described simply, but the interviewers must be capable of performing the interview. For example, giving a technical question to an agent requires that the agent be able to understand the answers.
• Level 3 - effective content. The interview questions are reviewed & updated for relevance to roles. This includes querying the candidate's history as provided in the CV. The interview has structure, such as a timeline to minimise the chance of overrun.
• Level 4 - effective interview. The interview process allows for an interviewer to not only find the gaps in the candidate's knowledge, but also find out about the candidate (not just their history) & determine their 'fit' beyond technical skills.
• Level 5 - training, collective accountability, & feedback. Although the process is well-defined, an interviewer can benefit from practice, each interview result is discussed by a group of people involved (rather just reporting their findings), & this reflects both on the candidate & the process itself.

Note, I am not saying that this has to be done in one, two, or ... far too many interviews. I have worked for large companies that spread out the process across five distinct aspects (initial, technical, architectural/communications, management, cultural), or manage to squeeze this down into three. You can turn the technical testing into a take-home exercise, use a group interview, add a final executive (for a senior role), & apply all sorts of variations. That becomes your process.

The main point here is, look at where your process sits, & determine whether it's worth the investment to 'go up a level'.

Why would you?

If, for any reason, you feel that you're not getting the right candidates going through your process - failing at a late stage - or the candidates that become employees fail probation regularly or leave within a year - churn - then this is an unnecessary cost to the business that could be minimised by having better interviews. If you like, having this measurement is Level 6. It's more of a trigger that you need to review, & either you already have a review process, or you can now justify building one.

Retention

Retention rate, at the board level, is a good measure of the effectiveness of the professionals who are producing the goods & services, & may well reflect on that output quality. However, & this is important, it has to be measured as something beyond average tenure of current employees. Churn is a factor, but churn amongst new employees is the best indicator of, for example, a toxic workspace.

If you're attracting the right candidates & employing them, then you also need to measure both their continued fit & their likelihood of staying on. They were employed for a reason - skills-wise - & you don't want to lose those skills or have to replace them, because that costs resources.

But that's another topic entirely.

Empathy for the forgotten

 I just failed a coding test.

A lot of you are thinking "so what?", but here's the thing - it's quite possibly only the second coding test I've ever done, & the last one was 1998 (in C). In the meantime, I've been interviewing dev candidates quite regularly over the years, designing tests, developing ideal solutions in various languages, assessing the great unwashed brought before me.

I just failed a coding test.

Sure, I have some very reasonable excuses. I tried to set up a dev env on my Chromebook & spent so much time configuring the IDE to cope with Typescript that I forgot to actually practise some Typescript, &, oddly, Typescript would have been particularly useful on this occasion, but it had all leaked out of my brain in the process of ensuring that I could indeed run & debug said Typescript if I could actually write it. I can, by the way, along with a wide variety of languages that I have happily worked with over the last 35 years.

The problem is that I am not a <insert language> expert. I can move to a different job, dump the contents of my brain, & be quite comfortable in Chicken, for example, if that's what's required. I don't see problem solving as language-dependent. The programming language is just the tool at hand - like the IDE or the OS. Change one, & it doesn't stop me from working. It does, however, stop me from passing coding tests.

Actually, it only stops me from doing live tests, because if I spend half an hour looking at code to 'get' a language again, then I can do a take-home test easily - I've done that before. I wish I'd remembered this salient fact yesterday. Of course, it didn't help that the very kind interviewer suggested I write pseudo-code or use another language, & I plumped for Kotlin & realised that my IDE didn't have a clue where to go with that, either. I should have done Java, but I was already not thinking straight.

Live tests are supposed to give the interviewer an idea of the candidate's thinking skills & ability to communicate that thinking, rather than mastery of an IDE or even a language. If their approach to coding covers algorithm implementation, data structures, coding style, a nod to testing or test-ability, & an inkling of performance & memory implications, then you're on a winner. If they code that up like a machine, then that's confidence, at least (just check for arrogance).

However, that doesn't relate to the real world. I've just come from a large software company with products & tools & infrastructure & ... stuff. To fix a problem from the field, you analyse, you test (online, in prod or staging), you write more tests to prove your theory of what's wrong, you implement a code change to fix the problem, you write tests based on your implementation, then test online before getting peer review & such. New features only differ slightly. There's very little greenfielding where someone says "Here's a brand new problem, & I want you to start with an empty code project". Even new products & services start with a pattern, whether it's a microservice template, a plugin for the product, or a base line of configurability copied from the last such module.

Only twice in my career has someone said "Start with nothing; assume nothing". Both became patentable.

Professional developers don't get to write little algorithms in isolation from scratch. I actually think they should do it more often, though, because that's the basis of TDD & unit testing. Write an algorithm, prove it, then plug it into the code base. No-one does that, because of things like dependencies. There's a whole raft of 'stuff' that you need before you can prove that algorithm - like a test infrastructure, JSON manipulation, HTTP client or server implementations - that's already in the project. It's not laziness that makes you shy away from creating a new Maven/Gradle build to then immediately throw away, it's efficiency. I've done something like that a few times - do the work in an existing project, then copy the whole thing & pare it back to what I need as the new project.

I'll tell you who is good at writing one-off, independent, no-strings solutions to small problems: undergrads. In theory, they should be the perfect candidates to fly through live coding tests, because that's how they've been taught to code. Well, it's how I remember teaching them in the 1990s. Now, those students are, like me, giving coding tests to candidates with the belief that it's simple to pass the test themselves.

I'd like to think there's a way forward here. 

The first point is to ensure that a coding test is not simply a verification that what someone says in their resume is accurate (never assume it's a lie, either). A coding test, like any interview, is an opportunity for the interviewer to get to know the interviewee & determine the fit for the role, the company, the future. I'm not saying that the code itself is irrelevant, but it's a part of the interviewing process, not a box to tick, a criteria to match. It shouldn't be a trick question that proves how clever the interviewer is, either, because, as always, the interview has to run both ways. You, as interviewer, are being judged as a representative of your organisation.

The second point is that live coding tests only work for someone who is comfortable with that exact process, so nerves, brain-freezes, distractions (like illness), are all a part of that experience. If someone can do an offline test beautifully, then an online is useful if you're looking for someone to pair-program, for example, but not necessarily for someone to work remotely or in isolation. 

Most importantly, empathise with the candidate. You don't have to make allowances for their lack of social skills or inability to perform under pressure. That's called being human. If you can alleviate the symptoms, that's under your control, because you're in the dominant role in the conversation. Just don't make things worse by judging performance under unusual circumstances as indicative of how someone can actually perform their job - at least hold that back until you write up the review.

I just failed a coding test.

I'm human. You're human. Let's interview humans like humans should.

You've Got to Have Faith

(With apologies in memoriam to George Michael.)

I've been working through a consultancy firm recently where the CEO (I'll call him John) wanted to create a Christian organisation because he felt most comfortable dealing with people with whom he had some basis of understanding in how to go about doing business - a set of ethics, if you like.
John & I would have great discussions about everything - even work. Most importantly, though, because of our shared beliefs & the trust that we could easily build from that, the conversations were often more open than one might usually have with a colleague because "I would like to talk about something that must remain between us" actually meant something to both of us.

This is not a mutual understanding of dissembling, but trust based on acceptance of who we were as co-practitioners of a religion with a set of values we both understood & believed in. This is not a matter of two people of the same cultural background (which we may be for one generation) seeing eye to eye, but a conscious decision on both our parts to recognise the commonality & embrace the faith within ourselves for the other.

This is empowering. It is an uplifting experience. It meant that we could bring up topics that skirted "taboo" in a professional relationship & find our way through them. Then, we would each feel good about the conversation afterward - no awkwardness.

While on the client site, one of my closest working relationships was with Ali, a practicing Muslim (some of my relatives are Muslim, but they don't practice, so I know the difference).  Ali & I may not have discussed much beyond work, but we instantly understood each other to be ethically equivalent as people who had a faith & could be trusted to follow a set of moral guidelines.
We got along very well. We may not have always agreed in some of the procedures each of us had to follow, but we would trust each other to do so without question - or else apologise profusely for the oversight.

This is how people with an ethical code work together. They don't need to second guess. They don't fear upsetting someone accidentally. They don't hide their own failures or highlight other's. They don't undermine or expect praise. People who trust each other in the workplace get the job done together out of joy, out of commitment to each other & their shared cause, out of a belief that everyone else is doing their best to get the job done - which is different from not letting the side down.

This post may seem to be far too religious for the workplace, & it may not be easy to implement ethics in a workplace where people are antagonistic towards religion in general, but the simple fact remains that trust - between co-workers or between managers & their reports - is fundamental to both a healthy workplace & delivering projects.
Religion - the existence of any religion - is a relatively easy basis for trust, as long as it encompasses everyone. Otherwise, you have to build up another ethical construct that is inclusive, easily embraced & understood, & consistently applied. That's a tough ask.

Supermarket Software

My wife bought a custard scroll for my Saturday breakfast. I was really looking forward to eating it, but when morning came & I sat down to devour its bready-custardy goodness with my coffee, I was sorely disappointed. It had come from the supermarket, not a bakery. It had the semblance of a custard scroll, & was packaged attractively, but it was all wrong. It reminded me of the last time I bought an umbrella from a supermarket - it let me down in the first rainfall.

I fear that we too often write software just like that. We might be getting better at building & deploying, but the software quality is falling down.
One of the side-effects of agile & lean is that fast-paced often gets interpreted as cutting corners. That's simply not the intent.
Another side-effect is that if you only build what you need to satisfy the requirements, then you'd better make sure that you articulate your requirements thoroughly - & then align them with what gets created, through demo & review.

I don't think there's anyone in the supermarket who is taste-testing scrolls or opening umbrellas. They're in the business of selling stuff, not providing a quality service.
This is why we shouldn't be treating software development in that way - software is a service to your business or else your customers.
It shouldn't have designed obsolescence unless that is a specific requirement; & yet too many people build that "feature" in but saying "it will never need to do ..." without actually thinking about the use of the software. In fact, software developers don't really know what the software might be used for, & have to hold themselves back from thinking of code re-use.
Product managers are the experts, using their knowledge of the market, their audience testing, etc.

Software shouldn't go onto the supermarket shelf (be deployed) unless the product manager has tasted it & is happy with the flavour & texture & utility of the software product. I'm not just talking about BAs & testers performing another series of processes that follow the requirements, but that higher level of understanding of what the software is meant to do, relative to its consumer base.

Sometimes, we fall back on the waterfall approach & say "well, that's what you asked for, & it's too late to change", or "that's all we have the budget to deliver". In effect, you're just selling those umbrellas that only open once. It's definitely not agile.
It hurts the company's reputation & bottom line, if you're talking about a product, & it hurts the business unit's ability to deliver anything in the future, even if it's an internal release of services.

A CEO from my past once used to say "we don't have to build the Rolls Royce".
He was right - we need to build the Beetle - the product that everyone was happy to use, was reliable, & targeted at its audience. Behind the scenes, German manufacturing's precision & quality was legendary - & very successful.

We, as software developers (& I include the whole development process here) have the responsibility to work like a bakery - taking care of each masterpiece we create - rather than like a supermarket pumping out software-like things in neat packages because it's cheap to do so.
A good bakery never goes out of business. A supermarket often has to heavily discount its unsold product.

Story Cost & Story Value

I read a complaint recently along the lines of "why do we still fill in timesheets?" There was a lot of opinion from the conservative "that's how project accounting works" to the radical "we don't need them". Somewhere in the middle, timesheets are relevant, useful, & painless.
These three things are not the same, & people too often try to fulfill only one aspect.

Timesheets are useful when they reflect the reporting needs. However, if you're not reporting on the actual activity, then there is a disconnect. Either, you have to change what you are reporting, or you have to accept that the data you are reporting with is not real. That's a disconnect - & a sad fact.

Timesheets are painless when they can be done "automatically" as part of an existing process - preferably without the team member doing anything. This could be as simple as monitoring their keystrokes (big brother = no bother), but it is better if the team are clocking all of their time against tasks in an issue management system - & every activity must be in the system.

This allows you to perform reporting against what is really happening, as opposed what is supposed to be happening. This is relevance.

There are plenty of tools out there to do this type of tracking, & none of them have the word "timesheet" in them.

They do, however, all track time in minutes & hours. In modern agile processes, activities are not estimated in time, but in story points, & they are often prioritised by business value. Therefore, there is a cost - estimated effort - against each piece of functionality that provides business value. In a lean environment, if there is no business value, just don't do the task.
We use this estimated cost in planning. We also use measures like velocity to determine scheduling: the number of story points - & therefore value - that the team as a whole can produce within a sprint (a time period).

We seem to have most of the elements in place to estimate a financial cost for each unit of business value that is delivered as long as we can determine a tangible correlation between delivered functionality & ROI - in terms of market share, increased sales, the value of the IP, or share price.

How can we define that true value of each feature?

Look at the approach taken to determine story points - it comes from experience. The team - the experts who are doing the work & have been doing it - agree upon the most likely cost, using tools like planning poker & the team velocity. They rely on the fact that, over time, estimations even out & have lower variance through increased skill & practice. Most importantly, they don't estimate in man-days. Still, tracking in hours, & having two-week sprints, "works".

The equivalent must be true of business value points - looking back over what impact a feature has on the value of past releases of product, plus the appetite in the market (based on end-user interviews, A/B testing, prototyping, etc), a relative score (not dollars) could be developed that would vastly improve the input to planning product development & this would also contribute to the accountability of the process in a much more tangible way than timesheets that track activities.

Pass the (Open) Source

I have been slightly freaked out recently by the extremely positive feedback I've been getting around a project I've been working on that is based heavily on an open source solution.

I've been down the open source path many times before - almost exclusively as a consumer or indirect contributor (offering suggestions to the project owners) - but not as a contributor with a major enhancement, say. It's just never happened. Most open source "does enough" for what I want to do as is.

At first I was intrigued that my manager showed such excitement that I could take something effectively free & get it to a point where it was actually useful for the project. As I said, I've used enough projects before to expect a non-perfect solution, but usually something viable comes up.

Then, she started getting excited with the idea of me sharing my experiences with other teams to encourage them to think in terms of not just using open source, but doing so with the intention of contributing back to those projects from the outset.

Again, not that radical from my perspective ... until she explained that the company - a financial services giant in the market - never thinks of open source as an option, let alone thinks of being a part of the community of dedicated IT professionals who spend their spare time, or else contribute from their company's development time, to make stuff for other people to just find & use as they see fit.

Admittedly, there are two very different software worlds out there - vendor world, & open source world (plus some blurry bits in the middle). Those two worlds only differ in their attitude towards licensing, not in their attitude towards quality.

In fact, there is a massive industry out there effectively being the consulting services, bespoke development or customisation, or support arms of open source projects. These people are an important part of that open source community because they get direct customer feedback on what makes better product (as opposed what sells better). They drive the development in the same way that vendor product is developed from marketing strategy & product leadership.

Yet many service sectors that rely on IT professionals to provide infrastructure (in financial services, telecoms, utilities) "feel more secure" out-housing the mitigation of their technology risk to the very people providing the technology, that is, through licensing & maintenance agreements.

Once upon a time, banks in particular used to have massive in-house development creating bespoke solutions that worked exactly the way they needed. That's out of favour. What's in favour is getting in the same consultants as the competition did to build something sufficiently different .

I know that my company is not one-hundred-per-cent happy with that arrangement. Very few companies are. I can name very few enterprise solutions that "just work" to the point that you can believe the marketing hype.

So, now's the chance to try something different. Start small & look to see if there is a way to introduce open source solutions into a project - cost it out in terms of support. If that works for you, try enhancing an open source project & contributing to the open source community to become an influencer of the development of such solutions, rather than just a consumer.

The "cost" of transforming thinking may be less than you think. The benefits may be more than simply financial. The end goal is to be able to provide a better service to your customers by owning more of the knowledge around the service & being able to make your service better under your own control.

Mind Your Language

I don't like admitting this, but I feel I've cheated on a recruitment test.

A while back, I was interviewed for a role with a company that worked predominantly with NodeJS. I told them I was a novice, & they said that was OK, because they needed someone who could do some project management work, & I had that experience.
Then they asked me to do their NodeJS test. They said I shouldn't spend more than, say, four hours on it.

I learnt enough NodeJS, & a few other bits of infrastructure I'd never heard of, & produced a competent solution for their test - all in under four hours. I even specifically left out the enhancements that I'd thought of for testability & stability, on the basis that I didn't want to press my luck.
To me, NodeJs is still just javascript. It's no silver bullet.

Two things about the situation have worried me since:

• why test someone's competence in a technology that they can learn from scratch in a few hours?
• why insist on recruiting for that skill if you can train someone in a few hours?

These two questions are at the heart of my broader concerns for the software development industry in particular in the areas of trainig & hiring.

I am a Java dev. I can do lots of other things, but Java's been my core language for fifteen years. I've learnt the new features as they've come on board. I've been exposed to a lot of libraries, frameworks, & open source solutions over the years that have allowed me to develop things a lot faster than I used to, because I can leverage the experience of others' in the community.

I am aware that you can probably do the same things in C#/.Net for the same reasons, but have no interest in doing the same things in a different way if they achieve similar results.

What worries me is when someone specifically tries to do one thing in a different way because it's "too hard" to learn how to do it in the current way. If you look at NodeJS as nothing more than a few short-cuts in (server-side) Javascript, then it's really a technology that saves time & effort for a few mundane tasks. Excellent. Move on.

If you think of NodeJs as a revolution because it makes it easy to do those mundane tasks, then you've missed the point of software development in general. NodeJS is a triumph of software development, not a panacea for it. The people who developed it are craftsmen who knew their language (Javascript) & used a lot of experience & skills to solve real world problems in their community.

Only the marketing folk believes that NodeJS solves the problem of world hunger.

A good javascript dev now breathes a sigh of relief when they have to do that boilerplate for web services. A bad javascript dev (or a NodeJS dev qualifying after four hours) thinks that they are God's gift to the software industry because they can replicate some googled examples.

Whatever programming language you develop in, if you learnt it in a matter of days - or even weeks - then you cannot possibly understand why it's useful, or in what context it should be used. Even after you know the limitations, you need to learn how best to use the programming language - through patterns, best practices, software architecture, design, testing, etc.

This is not something you can learn on your own - ever. It is certainly not learnt in a short amount of time. It comes from a lot of commercial experience (where other people are your customer) & teamwork (where other professionals give you feedback).

If you can acquire "skills" that can be learnt sufficiently to pass a test within hours, then why aren't employers taking some responsibility for that training - offering guidance, mentoring, etc - to ensure that the skills proliferate within an organisation, & to encourage learning in the workplace?

If companies appreciate fine craftsmanship in their software deliverables, then why don't they encourage an environment that fosters improving the skills of the developers to make them better at what they were hired to do?

Although all developers should find out about new technologies & play around & learn constantly, they should also learn more about their craft & the technologies that they already claim to be familiar with, with the hope that they will get better, help others to become better, & contribute to the betterment of their organisation.

Death to Project Managers

Can you imagine a world where a killer virus transmitted through Gantt charts wiped out the population of project managers? How would anything get done?

The short answer is - "by doing things differently" ... & "no".

But bear with me for a few paragraphs. Taking a leaf out of an old Edward de Bono book, simply imagine that project management as we know it is impossible & we have to find another way to get things done that does not involve the skills & techniques that we currently use.
If we had to reinvent the process, would it come out the same?

We don't have to reinvent. In fact, I've worked for several companies that don't have project managers - or they have one who doesn't get involved in projects directly.
Most variations on the Agile development methodology have no room for project management as such, because teams are self-directed.

You can see project management as a top-down approach to achieving a goal. It's quite traditional. Agile is always bottom-up. There's an assumption that the professionals doing the work know more than management about how to deliver the outcome - as long as they are empowered to make decisions & effect them, & have access to the information they need.

Admittedly, agile works best in small teams, but there have been many examples of teams of teams (layers of self-organising) where a team representative is the conduit to a higher level of abstraction. Certainly, if that higher level is concerned with business strategy, for example, then its membership is made of team leaders - those who can ensure the smooth working of the development team.

In this structure, project managers are not appointed to a project. Teams are assigned a business outcome. In some cases, teams own a product or a service, & their output is a part of the overall enterprise's offering - a direct contribution to the business' viability.

The alternative to project management is product management - not someone to ensure that deadlines are met, or to negotiate budgets; but someone to ensure that quality is defined relative to the business needs (usually associated with what an end-user expects), & can understand & articulate the requirements to the team & to management (to justify investment of time & materials).

Project managers have budgets. Product managers seek investment.

Product managers are invested in the product - the outcome - as is the team. Their passion is what drives the business' value proposition to their customers & investors in turn.

We can survive without project managers. For how long can a business survive without product managers?

Arts & Crafts

If you've ever read (or tried to read) Bob Martin's "Clean Code" book, then you will realise that there's a lot more to writing good code than using the IDE's built-in syntax checker - no matter what language you're writing software in. If you're using vi or emacs, then you're on your own.

If you've never written software commercially - say, a recent graduate - you might not get the point at all.
If you've been writing software for a few years, you should get frustrated with the book, looking for that "secret" that will make you the master of your profession.
If you've been writing software for a long time, you flip through nodding your head & say to yourself "sounds about right - what's the big deal?"

That perspective on the book equates to the attitude of those different stages in a career to what should be the core of a software developer's skillset.
It might have many names - call it artistry or craftsmanship, or just experience.
The most important part of it is that you don't acquire it from a book - Bob's book tries to capture it in the same way that an artist captures a scene or a good software developer captures a requirement. Bob's book is not a how-to for the uninitiated, but a biography of an artist.
He's as much a good author as he is a good software developer.

That book - & there are very few like it - has lost popularity because it was written by a master technician for other masters. Any apprentice should have the background to understand what is being said, but doesn't have the experience to understand why it needs to be said, or what to do with the knowledge.

In a way, that's a sad thing to say about our industry.
I've used terms there (apprentice, master) that make perfect sense in a trade context, but no longer make sense even in an artistic context, let alone a software development profession.

We still have tradesmen working in some companies who are masters - they oversee apprentices, they have done their time in several establishments honing their craft, & are now considered at their peak & responsible for their deliverables.

We have lost that concept of the professional artist as an equivalent set of stages - the master sculptor with his journeyman assistants, surrounded by apprentices doing the preparation work, cleaning up & looking after tools.

We have too quickly lost the concept in software development.
I have a vague recollection of graduates being mentored by senior devs, working closely with mid-level devs to learn the skills & techniques. Pair programming was good for this.
Those masters of software development who came up with the agile methodologies have been cast aside in favour of doing things quickly or cheaply, with no time to spend on training apprentices.
The focus has been on tools that could be learnt without supervision & on the fly.

If, as an industry, we fail to train apprentices, continually employing only experienced developers, then at some point we must realise that those developers were never apprentices.
They never learned anything at the direction of a master, or under the eye of a journeyman.
No matter how many years of experience they have accumulated, or books read, or courses attended, if a developer has never worked in a team where their work is constantly under review, or they have never contributed to the review of their peers, then they are effectively self-taught.

As creative & talented as some artists are, unless someone teaches them how to use their tools - brush-stroke technique, sharpening a chisel, mixing glazes - what they create will always lack the fundamentals, the professionalism, that we should expect.
We, as an industry, need to hold our expectations for professionals up high, as a light by which we see the true artistry or craftsmanship of those who would be, or claim to be, masters of software development.

Every Start-Up has a TISM

It's often said that most start-ups go through several pivots before they get to some form of market success. That pivot might be the product, its target audience, or the delivery (such as turning the product into a service). Such outward-facing effects change the way the company is seen by potential investors as well as customers, shaping the chance of success.

It is also almost always the case that there are internal pivots that shape what the company is, & what it looks like to itself (& to its board), & how it does business. Although multiple pivots can happen, there is usually only one that stands out in the history of the company - & I would like to christen it the "'This is Serious!' Moment" (TISM) in honour of a now-forgotten indie band of twenty years ago that had nothing to do with the rest of this article. This is separate from, but often related to the "Holy Cow!" moment (HCM) when things suddenly pivot for the better after a lot of hard work.

At some point, founders will gather in the garage or around the little table in the kitchenette of the office & know that, very soon, they won't be allowed to make world-shattering decisions by scrawling on the back of a bad printout, because everything they do is now more important. Often, this internal realisation is accompanied with a flurry of very corporate activity like hiring a CFO to actually be responsible for finances, or a project manager to guide releases - a layer of governance that doesn't sit well with a seat-of-the-pants operation, but is essential when things start to become serious.

Sometimes, you can miss the "This is serious!" moment because it happens immediately after the "Holy Cow! Someone gave us money!" moment (HCM), & that heady experience of losing your doubts over success - if only for a day or two - makes you miss the fact that, not only have you asked "What next?", but you always knew the answer - things get more serious.

Some companies seem to never grow up, never have a TISM - but it's always an internal moment, & almost always before the company goes public. You'll find that moment buried in the middle of biographies & exposés. It doesn't have much significance in itself, because every company does it, but no company that succeeds didn't do it. Google's TISM was probably hiring Omid Kordestani for sales. In the case of Microsoft, it was probably the move to Washington after successfully divorcing from MITS (eerie coincidence of letters).

Strive for the HCM, plan for the TISM. Don't get left wondering "What next?"

Continuous Improvement as a Business Transformation

One of the key benefits of an agile methodology like Scrum - & something that is very hard for a non-developer to get their head around - is that the methodology encourages & assumes some form of continuous improvement. There is regular reflection on the process as implemented, & how it can be made to work better.

Something that is much better understood at a corporate level than it is within an IT team is a business transformation process (or project), which sets the goal of achieving particular outcomes in some parts of the business as a result of a specific set of changes.

These are, more or less, equivalent.
Having said that, they are never seen as such for one very simple reason - one is iterative (usually based on a sprint of, say, two weeks), while the other is waterfall (lots of design up front, big delivery at the end of the project).

It is generally as a result of this divide that there are perceived differences like:

• continuous improvement rarely plans ahead, setting goals against which they measure their progress in improving
• business transformations produce isolated results in unrelated projects
• continuous improvement produces a trend of live status which is often out of date as soon as you print it
• business transformation has success criteria defined that ensure that a project ends & its approved budget can be classified into accounting periods & closed off

There needs to be a strategic transformation to allow for an IT unit's operational cost of continuous improvement to be seen as a varying maintenance cost (or an investment) - with a return on that investment. I am not talking about big companies here - any business whose core operations are around an IT unit & its output (product development, consulting, IT services) can benefit from an agile methodology that adds value to the business.
However, it will only add value if you can measure the outcomes. Anything that adds value can generally add the right kind of value (efficiency, cost reduction) if you set the right goals & measure the effectiveness of investment.

Too often, an IT unit "goes it alone" to improve itself because there is no executive buy-in for a business transformation process that is not a project that appears in an annual budget. Too often, executives see the internal workings of an IT unit as too arcane both for them & their board.

However, when the way that IT units work becomes the focus of a business strategy - with measurable outcomes - the business can only get better at measuring its own likelihood of success.

Development Methodology as a Business Strategy

Although it may not be trendy, it is still often the case that people say that they follow an Agile methodology, but usually explain it in terms of how the product development process happens in isolation of the rest of the business.

Regardless of the flavour of agile, the implementation of the processes should - indeed, must - align with the business strategy. Without some alignment, there is nothing at C-level to indicate that the engineering department is effective, except in terms of project success rate or marketing meeting its goals. To have a measure of effectiveness within an engineering department, then there has to be something measurable at enough detail to make predictions, set goals, compare, & assess.

Agile processes generally provide a framework for being more effective at developing product. The processes themselves need to allow for reflection & adaptability in an iterative sense - continuous improvement. Even if board-level decisions are not agile, the benefits of agile processes can - & should - lead directly into corporate strategy.

To give a concrete example, the cost of an engineering department is usually considered to be linear against resources. However, it is "well known" that a more effective team produces better product (cheaper to maintain & support, easier/cheaper to extend, faster to react to market needs). If there is a company strategy for producing better product (with a goal of lowering maintenance costs), then the process for achieving this - improving the effectiveness of the development team - needs measurable goals.

Candidates for measures - from a product development perspective - might be:

• amount of time spent on rework (cost of problems found in testing)
• amount of time spent on re-implementation (problems found n the field - more expensive)
• estimation accuracy (for features or projects) - not just coming under budget
• velocity - the amount of work the team can do in a time period
• technical debt (the likelihood that something could go horribly wrong over time)
• alignment of skills to needs (training, staff turnover)
• false economies (where a cheaper option costs more because of knock-on effects)

Some of these are traditional measures, but some use a language that is often outside of the understanding of board members (or even C-level).

Now we can understand why a strategy is never applied to a development methodology - it takes a lot of effort to translate the language used in engineering into the language used in business strategy. It is not impossible, it's just the few people are doing it.

The first step is always the hardest. A board has to have goals that cover both outward-facing measures (P&L) & inward-facing (team effectiveness), & these have to be aligned by strategies that inter-relate & support each other.

Product Development Strategy

If your core business is developing (supporting, maintaining) a product (or service), then your corporate strategy is usually focused on marketing/sales-oriented measurable goals such as unit sales or licensing revenue (or chargeability ratio), market share (or growth), or ROI for projects.

Essentially, these relate to SMART goals because the outcomes are measurable, but often what contributes to these goals are less measurable strategies - or are not seen as strategies at a corporate level. Essentially, the various approaches for achieving these outcomes should be quantifiable & comparable & relate to the goal.

Let's work through some examples. If your goal is to increase licence revenue by 10%, then you have several possibilities:

• sell more licences in the current markets
• expand into new markets
• increase the licence fee

If these are the possible goals, then what tactics could support them?

• sell more licences with existing relationships (cross-sell, in-sell)
• find more customers (raise brand awareness)
• justify a price increase (added value, price restructure/passing on costs)

There are obviously more avenues for achieving the same goal. but this will do for now. Suffice to say that, for each of these, a supporting strategy that is internally focused will both support the effort & contribute to the measurability & effectiveness.

To take each of these in turn; if you want to sell more licences to an existing customer, then the product must be structured in such a way that this is feasible - that is, there are feature modules, or else the licensing is seat or transaction based. Without a product strategy that delivers these capabilities, you cannot use this strategy.

To raise brand awareness, you can market the product to new targets, but this can only be effective with good brand reputation - an infrastructure around product support & product supportability that ensures that field issues are dealt with in product planning, & that the product (or service) is identifiable (& differentiable) within the market. This can only come about in the way in which the product is developed - both in terms of its feature set, & its deployment & use (or customer engagement model).

Thirdly, to increase the perceived value of the product, you have to have a product strategy that aims to provide something beyond new features - a step up in a product's applicability or usefulness. Even if intending to pass on the costs behind providing the product (for SasS), you have to build a product that can measure its own costs & report on them. This may sound obvious, but without a strategy in place, you have no way of aligning product development to the corporate goals.

Essentially, a product is only as good as what you build it to be, but a product strategy should be good enough to support the whole of the business' expectations. If your business is wholly dependent on the product, then product development strategy becomes a board-level concern.

Top Level IT Strategy

When I started getting involved with business architects, I was excited, because I thought - this is it, this is what ties what I've been doing (product development) with what I haven't been doing (running a company).

Eyes bright with wonder & enlightenment, there is still the question: why hasn't someone gone down this path before? Why is it that we think of IT (in the broadest sense) as only a business unit that supports the implementation of a company strategy, in terms of technology, or else as a unit that supports a sales/marketing strategy, in terms of delivering products & services?

Why is there rarely a top level strategy that sees IT units as an implementation of board decisions in themselves? Let me give you some examples.

If you're a non-IT enterprise (manufacturing, services, utilities, ...) there is an understanding of the IT needs of the business supported by an enterprise architecture & a plan to implement changes to the IT infrastructure to support financial strategies (say). Is there, however, a strategy governing the infrastructure that the financial strategy must align with? If not, then, as is often the case, each new implementation is a distinct & unrelated solution to an isolated problem.

If you're an IT enterprise, then your strategies are often around the deliverables of engineering departments - product releases, product strategy to compete, etc, but are there processes within engineering that directly support those strategies? If so, how do you ensure that they align - that they have the measurable outcomes that you expect, from a business point of view, to support the objectives of the company?

The short answer is that, without some form of business architecture - an understanding of how your business functions & the inter-relatedness of all units that contribute to the company's success - then not only can you not measure the impact of strategic decisions, but it is much harder to define strategies.

Right now, you're in one of two camps - "Great, I need a business architecture - where can I get one?" or else "My company is too small for that kind of stuff". The next step is the same, regardless. If your company has strategies & expects them to be implemented, then you need a framework to ensure that they are - across the organisation. If you don't have a framework, then your strategies are written in the sand & you hope that you're above the high tide mark.

I'm not going to say what framework you need, or even whether it needs to be a formal one, but without an approach to your IT/engineering departments that incorporates decision making into company strategy, you have an unmitigated board-level risk to deal with.

Best of Bleed

Some of the buzzwords that float around when you talk about technology or process improvement are getting dated. I can recall hearing "best of breed" close to twenty year ago. I heard "bleeding edge" not long after. If they were around before then, I must have been ignoring them as a bad joke. Things have come full circle.

Still, how else do we describe the particular nuance of meaning that those two phrases in particular encapsulate?

When someone says that they want to use a "best of breed" technology or methodology, they're not being specific - which always irked me - but they're committing to discovering what works for that particular scenario. For example, if you're starting a whole new project with little more than an idea of the functionality you want to offer (not how to provide it), then there is no definitive answer to the question "what is the best of breed"? At a high level, you might go down the dot-net path, or be open source, or somewhere in between. At a low level you have a myriad languages & frameworks to choose from that are very good at solving specific problems.
There is no one right answer. That's the point of saying something as unhelpful as "best of breed" - as long as you are actually intending to research a good solution (hopefully the best) for the problem at hand. You have to take advantage of other people's experiences to determine what is right for you. That takes effort in itself. Making the choice is not just "picking the low hanging fruit" (another of my pet hates).

It's usually an executive who likes to use "bleeding edge", meaning that they're not just at the forefront, but that they're ahead of it. A similar phrase is "ahead of the wave", although this latter doesn't have anywhere near the impact of the unspoken side-effect of the bleeding edge, which is that it's fundamentally dangerous, & someone can get hurt.
I suspect that few people who promote being on the bleeding edge think of the risks, but I would like to believe that those who are taking those challenges on - implementing new processes & using new technologies - know very well that failure is not an option. When people walk that fine line that leads to outpacing competitors & getting a business advantage out of doing things before anyone else, they're not trail-blazing with the expectation that others will follow, but ploughing ahead with the hope that no-one is following too close behind, & that they can find a way through the difficulties that no-one has faced before.

If you want to be treated seriously, then you have to be a person of your words. When you use "best of breed", you imply a knowledge of the problem space that supports process & technology choices that can be backed up by results. When you live on the "bleeding edge", you are promising risk of failure. You are promising unknown outcomes.

I'm not convinced that anyone is giving a guarantee of success in the former case, or setting up an expectation of failure in the latter.

Getting Out of a Meeting

I was horrified to see a post on LinkedIn - "How to Get Out of Unnecessary Meetings". I might have been more horrified over who liked the post, but it got me thinking before I could start reading.

Regardless, don't try to get out of any meeting, necessary or otherwise - try to get SOMETHING out of every meeting. If you go into a meeting (or worse, every meeting) with the attitude "I wish I wasn't here", then you may as well not be, because you have no intention of contributing or listening.

If you go into a meeting with an open mind & a question in your heart "what can I get out of this?", then you will always find something. At the least, you will walk away thinking "if I have to organise a meeting with those people, I need a strong agenda to keep people on track & awake", or "the next time that person organises, I'm going to ask if they'd like me to chair the meeting".

Even a "necessary" meeting should not end with "I'm glad that's done with", because there should be a review in your head. Did you achieve what was necessary today? Can you get more done next time? Did people listen to you? Did you listen to everyone fairly? Who should have been there who could contribute? Who didn't need to be there? How can you better serve those people with minutes?

There is no such thing as a perfect meeting, any more than there is a meeting from which you can get nothing at all. It always comes down to the mind-set & the frame of mind (which are two very different things) - you have to want to get something out of every meeting, & you have to practice doing it.

Meetings don't even have to be that formal business context with a client or as part of a process. A good manager has a chat with team members with an agenda at least in their mind (all managers' time is precious), so the employee should have an agenda as well - use the opportunity to bring things to the fore. A one-on-one meeting is rarely a one-way conversation - even the most intense kind, disciplinary issues, are an opportunity for the employee to explain themselves before the manager has to escalate to a broader audience.

Anyone whose professional career is built around networking - consultants & salespeople, in particular - know the importance of having something in mind every time they meet with someone or get an unexpected opportunity to meet with someone. It's a not-exactly-hidden agenda that ensures that they get something out of every conversation, every greeting - even if it's only "remember me later when I might want to discuss an opportunity".

There, of course, is the crux of getting something out of a meeting. Everyone who attends the meeting with you will remember you. It's your chance to shine, to show what you can contribute to the project or the company, & how you can be looked upon as a team player.

It's your choice to take something away from every meeting for your benefit, but only through your efforts will others take something away from the meeting to your benefit.

Bring Back the Boffins

I was at a party recently when someone mentioned that in his transition from a technical role to management, it worried him that the relationship between business units & technical teams was often fractious & showed a lack of understanding. I was quite dismissive at first, suggesting that the old model of client-server approaches to IT activities was getting rather dated; but he assured me that it was commonplace for IT departments to be under-valued & generally less than ideal places to work in as a result.

I've worked predominantly in IT companies, where IT people form a large portion of the staff & are usually treated quite well, but even I had to admit that there are instances where an HR person or marketing/sales, for example, will look down on the engineers who produce the product or service on which the company was built. How strange.

Why?
One of the reasons is pure jealousy. HR people are generally clever enough (IQ) to understand people, as well as personable enough (EQ) to be effective. IT people are too often smarter (IQ) & oblivious to networking & communications skills (EQ) outside of their technical circles. There's an obvious clash. HR people work on the same level as sales people. They don't 'get' technical people, & sometimes are intimidated by both that failure & the realisation that they're not in the right sphere to be an effective communicator - they don't speak the same language. I used to work with a psychologist who referred to technical people as aliens. It actually made her a more effective communicator because of it.

I've been selective in my career, & worked in predominantly tech companies, & even when I haven't done, I've been in consulting where those tech skills are still the service that the company is selling (along with co-workers accounting skills, etc). That's essentially no different - the individuals' talents are the core of the success of the business. In effect, I work in departments of boffins - the people who solve a business' problems.

In many enterprises whose core business is, say, finance, IT is considered a service that supports the core business. These are very large, diverse, companies. Their IT people don't seem to directly contribute to the company's bottom line - they're often seen as a cost centre! Yet, the staff in IT departments are the same kind of people who staff tech companies.

These are definitely the staff that corporate HR will pigeon-hole as uncommunicative, difficult to deal with - perhaps even arrogant. As I said, these are the same technical people, so they're as likely to be at least as smart (IQ) as HR people. In a large corporation, though, the HR people are likely to be (or believe themselves to be) well above average in IQ across the staff.

Conflict.
Worse, not only are the IT people not directly contributing to the company's core business, but the new, exciting bits of product that do get touted as breakthroughs in the way that the business is conducted  come from external consultants - those companies whose core business is their employees' skills. The IT staff are considered second rate - obviously not as clever as the consultants. Generally, this is just not true.

It's taken me quite a long page to describe the problem. At least I do have a solution. In successful tech companies, the engineers who come up with the ideas & implement the product or service are often treated by management as aliens - can't be understood, don't try - but as aliens who you have to respect if you don't want to be hit by a ray gun.

I prefer to think of IT people as scientists - the boffins who solve the company's problems. They are the ones that management turns to when the business has a hiccough. More importantly, large enterprises need to have their boffins in house, rather than simply have an IT service that can be out-sourced with the stroke of a budget pen.

If you don't have your own boffins, then your company's problems won't be solved - the technical issues, the business issues, the future products & services, & the staff happiness level.

Doing it Quickly Takes Longer

It's an irresistible expression - we don't have time to do it properly, so just do it quickly. Leaving aside the word 'just', which I dislike, I want you to cast your mind back & think of a time when "doing it quickly" actually was quick.
In the majority of cases, it takes longer to do things quickly. That's simple history, if you go through your catalogue of past failures. In fact, given that half the time any project that is not rushed is done on or under time, it would certainly sound as if it's much more likely that a project that isn't "done quickly" will be.

This is not counter-intuitive. Here's why.

1. Pressure. The reason people want things done quickly is because there is a time pressure. If you apply pressure to something it is far more likely to explode.
2. Corner cutting/risk taking. The first thing that "doing something quickly" doesn't do is follow all of the good processes that are supposed to give a higher likelihood of success.
3. Monitoring. Everyone is under pressure, including management, to ensure that the project completes. Given the tight deadlines, everyone (at once) tries to find out what's going on so that they prove that they're on top of the problem, thus distracting those doing the work.
4. Bad estimates. Most people, if rushed for an estimate & told that a job needs to be "done quickly" will automatically underestimate it. It's a part of human nature, a part of professional pride, & it's the way such things have always been done.

I'm sure there are other things that we automatically do when someone says "do it quickly" that we wouldn't dream of doing otherwise. None of these things will improve productivity. Most will make it worse. Projects "done quickly" rarely are.

So, what do we do about it - as managers or project managers?
If you have a time constraint, then invest more resources with the expectation that no more effort will be delivered. That's a bargain where faster time needs more effort for the same output. It's a simple equation. However, I don't mean putting more people on the task, simply more people on the project. Those people have the job of ensuring that the work gets done, & nothing more.
A manager's role, for example, would be to stand guard at the developers' desks & ensure that the people who need to be informed of progress get their regular updates only from the manager, & with expectations set by the manager. Those doing the work can then get on with the task knowing that they have a schedule of reporting to only the manager once a day (or once an hour), & no more to distract them than that.
Odd bodies added to the project are there as assistants - to get coffee, collect printouts, do research, run tests, chase down experts that need to be consulted (possibly even liaise with them) - but their contribution to the deliverables is effectively zero. That's a tough call for a manager, & it's a big ask for a professional to put their ego aside & simply be at the beck & call of a peer.

That is why it is so hard to change the way that we "do things quickly". There are a lot of bad practices & ingrained habits that we have to throw away. But it will be worth it. Each time you look at how you did something quickly last time, recognise the mistakes, correct them, & get better at it - become more reliable in your "quick" tasks through creating a repeatable process for dealing with emergencies.

Top-Down on Top Again

It's a little old-fashioned, but I remember when we used to think of procedural languages as "top-down", & object-oriented languages as "bottom up". In the former, you looked at the verbs - what needs to be done - & then you broke these down into smaller units of work, etc. In the latter, you looked at the nouns - the things in the system - & modelled these to provide the basic operations that were built up to create bigger relationships.

It's a long time since I taught this ... stuff ... so I do hope we've progressed. I'm not convinced that everyone's aware of the progress, though.

I'm a keen BDD follower - every product I build follows the general principles of answering

• What does this product promise to do? 
• (what is its behaviour?)
• How is it going to be used? by whom? 
• (what is the context?)
• How does the company make maximum benefit from (justify) any given feature? 
• (what is the value proposition?)

These are very top-down questions. I don't care about the technology or even the problem that it tries to solve. The architecture of the solution, its maintainability, etc, are not a priority; that's for engineering's expertise. Performance probably is interesting - or at least the importance of performance needs to be determined.

From a project management point of view, I have other questions -

• How do I know when it's ready (enough)?
• How do I prove that it's ready enough?

This is strictly BA/QA work. No devs need be harmed in the making of these decisions.

If you look at that approach, you might think that I am a non-technical manager (product or project). I'm not. I'm a top-down developer at heart.

I believe that, even if a developer is not involved in higher levels of abstraction directly, they need to be exposed to the helicopter view, be able to provide feedback on it, & always keep it in mind with their deliverables. Without an understanding of how a release (candidate) moves the product closer to its user base or marekting's promises, there is the increasing chance of disconnect between the product that is being developed & the expectations that are being set outside of engineering.

The days of "I can prove that this software solves the problem you gave me through statistical modelling of outputs correlating to the results provided by business analysis" are in the past.

The days of "You said you wanted a user to be able to check their status anywhere" are here.