Tuesday, April 26, 2016

Management work: Strategy and Planning?

In my list of management work last week I left what some people will think of as a major omission: strategy and planning.

There is a school of thought that says that managers spend, or at least should spend, a lot of their time engaged in thinking big thoughts, having big discussions, creating company and product strategy. Sure thats why they need those big offices? Where else can they think deep and plan?

This school of thought would acknowledge that not all managers create strategy but since all managers think big thoughts those that don’t spend their time creating strategy are planning. Specifically they are planning how to implement the strategy set by more senior managers who do set strategy.

And since managers spend so much time planning they must also spend a lot of time communicating those plans - communicating downward that is. How else can you roll-out a strategy? How else do you implement a plan?

This school of thought is particularly powerful with people who aspire to be managers, people who want to be managers so they can think big thoughts, so they can step back and play a small part in the running of the world. Those who are fans of Michael Porter’s work on Strategy often subscribe, Porter sees strategy as conscious, inherently a top-down activity.

For those who hold this view is also follows that managers need authority: authority to decide the strategy, authority to tell others the strategy, authority to plan and authority to tell others to implement the plan they just made.

So why did I omit this important, and time consuming, aspect of management work?

I omitted it because this view of management is fantasy. It doesn’t exist.

Managers don’t spend their time planning and even fewer spend their time strategising. Sure many managers say they want to do this but very few ever find time. Thats why they feel compelled to create “offsite days” to plan and create strategy because day to day they are caught up in firefighting.

If you don’t believe me do and read the work of Henry Mintzberg, specifically read his book Managing, or the short version of the same book, Simply Managing. In these books he details his findings from following actual managers around and looking at what they do. He find they do very little planning and strategy.

Which is hardly surprising because in his earlier book Mintzberg demolished the idea of strategic planning: The Rise and Fall of Strategic Planning.

For software developers the story this book tells is oddly familiar, it starts with the idea that a strategic objective can be decided, that having decided the objective people (managers) can rationally decide what needs to be done to achieve the objective. They can then rationally allocate resources. The resources can then move them towards the objective. Sound familiar?

While Mintzberg agrees that organizations can have strategic objectives, and may even put in place plans to achieve them he shows that achieving the objectives is far from a rational planned activity. And, perhaps more important, strategy is not just a forward looking process (“We want to be the world leader in widgets!”) but an iterative process (“How can we increase our widget sales today?”) and backward looking, sense making (“Hay, our widgets are selling well, what did we do?”).

Most management work is far from planning and strategy creation. Most managers spend their days on administration, on working out problems, on applying their knowledge of a problem - a domain, solutions, history - to the problems they face today.

And if managers are spending their time engaged in strategy, planning and deep thinking then it follows that there is a lot less for them to communicate. And since the plans don’t exist there are no plans to deploy and no need for authority to order people implement plans.

Mintzberg also demolishes the idea that manager work hierarchically, that they need authority to do things. He shows how managers work without authority, they cut across hierarchy, and they work with their staff more than they direct their staff. Management is at least as much about persuasion as it is commanding.

Once you start to see managers as co-operative problem solvers they look much more like any other team member. Albeit one with some elevated status.

In fact, I’d go as far as to say: any manager who tries to work purely through authority is a) not going to be popular and b) find it hard to get things done.

Take away strategy formation, planning and roll-out from the work managers do and an awful lot of the power managers supposed have goes too.

In a software development teams an awful lot of this work can be push down to teams and the NCOs that work with the teams. Authority can be distributed to the people who closer to the problems, who need the authority.

Now perhaps it becomes easier to see managers as team members too.

It just so happens that their skills are a little different form other team members, their skills are more in administration, firefighting, working in ambiguous areas with limited knowledge and yes, to some degree organizing.

Wednesday, April 20, 2016

What is management work?

Continuing my discuss of management, broadly speaking my argument is:

There is management work to do - the same as there is coding, testing and customer understanding. To pretend there isn’t such work to do, that all software development might be reduced to rational engineering is naive.

Much of management work may be administration, we might be able reduce the amount of work, we might be able to delegate it or disperse it but there is still a rump of work to do.

A lot of management work involves decision making, and a lot of those decisions require authority.

So what is this work?

Here are some examples which I think are legitimate, possibly intrinsically, management work:

  • Managing the client-supplier relationship: whether you sell your software product directly to customers or not your company will have suppliers (paper-clip vendors maybe) and customers/clients (well I hope you do, a few companies may have none but that is another problem).
  • Managing expectations of stakeholders (with BAs, POs, etc.)
  • Coaching staff
  • Governance of work
  • Information hub and firewall: information aggregation, filtering, dissemination
  • Organizational structure: creating the environment for success
  • Dealing with higher authority: for negotiation, for leveraging (unblocking)
  • Finances: even in companies which have gone beyond-budgets there are still finances to “manage”, if anything a beyond-budgets approach will increase the amount of attention paid to finances
  • and various administration issues

You do NOT have to have “manager” in your title to deal with these issues, these are examples of management work. You are a “manager” then you are more likely to deal with them - you might even attract such work.

This is not an exhaustive list — how can it be? - feel free to expand the list in the comments section below!

Some of these might be not be agreed by everyone. For example: should managers be information hub?

I’ve spoken to many developers who complain that their managers don’t tell them the full story, they selectively filter information, perhaps to retain their own power. But I’ve spoken to many, probably just as many, developers, who complain that their managers tell them too much, call them to pointless meetings to hear pointless messages.

And there are many who would argue that with modern technology (e-mail, mobile phones, etc.) that the information hub is redundant, after all messages can be communicated nearly instantly to everyone. But this cuts both ways. If message can be communicated instantly at very low cost it may well lead to more pointless messages and information overload.

So before anyone complains that they are not being told enough please check your mailbox, and mail filters, and ensure that you are not receiving too much communication.

Some of these items may be a sign of organizations in transitions from one organization style (maybe called traditional, top-down or hierarchical) to another (maybe called agile, self-organized, or holacracy). Such transitions don’t happen instantly or just because the CEO says “Lets be a holacracy”. And some organizations might simply want a little bit of “agile” in the software development teams in the basement but they don’t want self-organization anywhere else.

In any of these cases there will be management work dealing with the old-world and interfacing it to the new, and quite possibly expanding the new-world.

Some would even suggest that bring about such changes is itself management work and I don’t think I’d disagree.

Few managers will do all of the things I have listed and even fewer should do all these things! These are just a selection of the type of work I would expect to see managers doing.

What all these things have in common is they are nebulous, they deal with unknowns and unknown unknowns, they require working with incomplete information and they require a degree of intuition, some a little some a lot.

If these things weren’t ambiguous and nebulous then they could be formulated as a set of rational decisions, with known inputs and knowable options - as I described last time, lots of management work is about the fuzzy world out there. In so doing much of this work would move from the management space into the engineering space and might even, one day, be automated.

As time goes by we are finding ways to reformulate some of these issues so they can be tackled by engineers. And we are finding ways to reduce the ambiguity - the test driven techniques in Lean Startup are great examples.

Big data is another tool we are using to move decisions from the ambiguous space to the engineering/rational space. But, big data has a soft underbelly.

While this work rests in the ambiguous space then intuition is required to make decisions.

Keen eyed readers will have noted two omissions from the list and the discussion which followed. One I’ve ducked before: Leadership, the question of management leadership deserves a blog all of its own.

The second also deserves a blog all of its own: strategy. Many people have argued that one of the primary roles of management is to provide strategy, I’m not so sure. The full discussion will need to wait another blog.

Monday, April 18, 2016

Thoughts on the nature of management work

Returning to my Management, my mini-series of blog… (Non-Commissioned Managers, Analysts aren't managers and Managers who are not managers)

Lots of Agile advocates have a real downer on Management. I think (like myself) they dislike the authority conferred on “managers”. This may be dressed up as a rational dislike of top-down reasoning - and they have a point - but this also throws the baby out with the bath water.

Look, I dislike authority as much as the next person, actually, I probably dislike is a heck of a lot more than the next person, its probably one of the reasons I find it hard to stay in the same organization for a long period. But in order to reason about management work we need to divorce management work from authority and consider such work in its own right.

At its heart management work is administration. Thats why the most prominent management degree is not a “Management” degree, sure there are “business studies” for undergraduate degrees and Master of Management degrees but the most prominent management degree is actually an “Administration” masters degree.

To an engineer much of this administration looks pointless, or needless, or counter productive. An engineer looks at administration and sees a things which can be engineered away by a rational process with rational decisions by rational people.

But… Not all activities are rational.

Not all processes can be decomposed in an analytical fashion and rebuilt.

And since there are people in these “systems” rationality often goes out the window. What is rational to ME is not always rational to YOU.

Sure, as the knowledge in society increases, as engineers understanding increases, and as our computational power increases, more an more processes and activities can be examined rationally and subjected to rational, engineered, solutions but the devil is in the detail.

During the late 1980s and into the 1990s the Business Process Reengineering movement thought it could reengineer businesses along rational, engineering lines. It was an abysmal failure. Yet remnants of this movement still exist, perhaps most clearly seen in the ERP and CRM space.

The problem is: the world is messy.

More specifically, people are messy.


A lot of what we call “management” is about interfacing the messy world to the rational engineering world. But even the rational world isn’t what we think it is. The rise of the behavioural economics has done much to debunk economists faith in homo economicus.

For me management work sits at that point where the logical world meets the fuzzy world, where binary meets analogue, where Turning machines meet non-deterministic processes, and where homo economicus and Robert Lucas meet homo reciprocans and friends The Undercover Economist, Gerd Gigerenzer, Kahneman and Tversky, Mullainathan and Shafir and a bunch utility-deniers.

“Managers” aren’t the only people in this space. By the way, Business Analysts and Product Managers inhabit the same space but their aims are different. All these roles work to make the messy, fuzzy, emotional and irrational world interpolate with the logical, rational, emotionless world of machines and deterministic processes.

Perhaps more interestingly Scrum Masters and Agile Coaches operate in this space too, that’s why I consider them managers, or at least non-commissioned managers.

I pushed authority to one side before. Many coaches and Scrum Masters - as originally defined but not always implemented - deliberately leave authority at the door. They attempt to fill a management like role but without using authority.

In some ways this is good, it brings a different approach, sometimes better but sometimes worse.

Personally I learnt a lot of my management philosophy in similar position: Branch secretary of a political party. I had very little authority - its a community of volunteers, while I did control much of the administration I could also be ordered about by the massed ranks of comrades.

And there in lies the point.

In many environments those who control the levers of administration have power, and conversely, some leavers of administration require authority to be used properly. There is some work which can be done by manipulating administration (no authority needed) but there is some work which requires authority to control administration.

Administration may decay into bureaucracy, and we all dislike bureaucracy don’t we? Except some bureaucracy may be necessary to smooth running of organizations. I recently came across this quote:

"One person’s bureaucracy is another’s empowerment." Andrew Mullinger, co-founder Funding Circle

Authority, administration, bureaucracy and management aren’t automatically bad, a little of each might be helpful to smooth operations but take too far they can be counter productive.

Now depending on the organization in question - the culture, the systems, the history - exercising administration may require more or less authority, ultimately it is not possible to administer without authority, so administration begets authority. It becomes difficult to disentangle administration from authority.

Notice I’ve said nothing about Leadership here, that is another - but related - topic.

Thursday, April 14, 2016

Agile Project Manager/Scrum Master - Wrong, so, so wrong

I shouldn’t do this, it raises my blood pressure, I have better things to do, I have better things to blog about but I can’t help myself….

I made the mistake of opening a mail from a recruitment agent, the title: “Agile Project Manager/Scrum Master”, let me dissect it for you…

“My client based in the West Midlands are looking for an Agile Project Manager/Scrum Master for a long term project opportunity starting in May.”

Agile Project Manager/Scrum Master? - this is a pretty confused role, it is one thing or another, its one thing for a good project manager to act as a facilitator or for a Scrum Master to take on project responsibilities but to start out like this, well is just messed up.

Long term project? - there is no such thing, projects are temporary!

“The successful Agile Project Manager will be responsible for the planning, organising and managing of IT projects within this matrix resource environment. My client is looking for a technical Project Manager with strong experience in leading and managing multiple complex projects in agile environments. To be suitable you MUST have strong process and project management skills with experience in SCRUM.”

Planning, organising and managing of IT projects…? - what happened to self-organizing, empirical control?

And note “projects” not project (as it was before). Multiple project is a bad sign.

Matrix resource environment? - Matrix management, this organization has shot itself in the foot already.

Technical Project Manager? - so this person is a Scrum Master, a Project Manager and Technical, do they also make the tea and wash up?

And why all the SHOUTING? - Scrum is spelt Scrum, as in Rugby, it is not S.C.R.U.M. or SCRUM.

“As the Agile Project Manager/Agile Coach you will have ownership of the full life cycle project process, including the Software development lifecycle.”

Coach too? - as well as a Scrum Master, Project Manager and Technical? I’m not even complaining about the use of Agile and Scrum as if they a synonymous.

Ownership of the full life cycle… including the software development lifecycle, really? - except for the fact that the contract is for 6 months, the company is matrix managed, there are multiple projects and that some bastard hotchpotch process of SCRUM and traditional project management has been mandated.

In other words: you have as much ownership as a homeowner who’s house has just been repossessed by the bank.

Anyone taking this job would have their hands ties behind their back on day one.

“Key requirements:

  • Demonstrable experience managing complex Projects in fully Agile environments
  • SCRUM Master with previous experience of running Agile project teams
  • Excellent presentation skills & competence in project management tools
  • Full life cycle delivery experience
  • Ensure all SCRUM ceremonies are adhered to throughout project lifecycle
  • Collaborate with project teams (both on and offshore), create and maintain project plans and schedules”

Fully Agile environments don’t have projects, Scrum Masters don’t run Agile teams and “maintain project plans and schedules” sounds distinctly Gantt chart-ish.

Saying “all SCRUM ceremonies” sounds like the people doing the asking don’t actually know what the ceremonies are, just they must be “adhered to”. Anyway, Scrum isn’t a full lifecycle model so good luck here!

What is interesting here is what is not said:

  • No mention of facilitation, unblocking, coaching
  • No mention of technical skills (TDD, ATDD, BDD, refectoring, etc); this is supposed to be a “technical project manager”
  • No mention of empirical process control or forecasting
  • No mention of value
  • No mention of prioritisation
  • No mention of the Product Owner/BA/Product Manager

Normally I would be pleased that the recruiter wasn’t asking for a Scrum Master Certification, a Prince 2 certificate, or, heaven forbid, a “Agile Project Manager” qualification but on this occasion I read it more as a sign that the company doing the recruiting don’t actually know what they want.

Similarly, no mention of tools or technologies - Agile in PHP is very different Agile in embedded C, let alone the ERP Agile I’m working on now.


“If you are interested to find out more, please reply…”

Should read:

If you are a traditional project manager (who used to code in the dim and distant past) but can’t get work now the world has gone agile, but think you know what agile is (mini-waterfalls) then please give me a ring, you probably know more than the people doing the interviewing anyway.

Bottom line:

  1. Unfortunately this is the state of our industry, it is what many organization do and want. But it is far far from what the best teams do.
  2. Don’t blame the recruiter, their industry is based on failure, most recruitment agents are failed real estate agents.
  3. The organization requesting this role have such a poor understanding of what they need they shouldn’t actually be allowed to hire anyone.

Monday, March 28, 2016

Opportunistic salvage driven by tests

Taking a break from my recent series of blogs about management, I’d like to discuss something that has come up with my current client - OK, I’m bending my rule to and blog about live events but this isn’t about the client, its about an idea.

Opportunistic salvage

Many readers will have seen this scenario before: there is an existing system, it has been developed under a previous approach, a non-Agile, an approach that didn’t give quality a high priority. Some believe that the new work, based on an Agile approach, can take the current system “as is” and build on it, maybe some patches will be needed but why throw away something that has already been built?

Something customers have? Something you’ve paid for? - they have a point.

And there are other people who believe, perhaps with good reason, the existing system has poor code quality, poor architecture, significant defects (bugs), and in general takes more effort to maintain than it would to rebuild.

As always the truth lies somewhere in between, and as always, determining what the truth is is not easy. The best that can be said is: some parts of the system are good and can be built upon, and some parts of the system bring more costs than they do benefits.

Anyone who has ever owned an old car will know the problem: you take the car to the garage and you are told “Ooo…. this is expensive to fix” - not as expensive as a new car but expensive. Nor it this the first time you’ve taken the car in, this time its the steering, last time it was the electrics, next time… the clutch? the gear box? And maybe there is rust.

You have to make a decision: should you spend the money to keep the car running or invest the money in a new car?

This is the question we face. Our solution is: Opportunistic Salvage.

We will look at each part of the system on a case-by-case basis and decide whether we can bring it across or whether we rebuild.

Critically this is driven by tests, automated acceptance tests to be specific.

Faced with a request, a requirement, we develop a series of acceptance tests - based on the acceptance criteria that go with the requested story.

These tests will be implemented in an automated ATDD fashion using a tool like Cucumber, SpecFlow, FIT or Selenium. We will then take the part of the existing system and run it through the tests.

Two points to note at here:

  • Building an automated acceptance test system is needed for a proper Agile approach. So building this keeps with the new approach. (If you are not automating your tests to build fast feedback loops its unlikely you really are doing Agile anyway.)
  • Some work may be required to make the section(s) of code testable, i.e. make it a module with a well defined interface. If the code is already a well defined module then good; if not then it should be. Going forward, in an Agile approach, requires good code so if an investment is needed then the investment is made.

Now one of two things will happen.

Possibly the lifted code will pass the tests, this is good and shows that the people who said we should build on the existing were right. We can take a quick look inside the code to make sure its good quality but it probably won’t need much work - after all it just passed the tests. If it happens that a bit of work, possibly refactoring is required then since there are now tests this is quite doable.

On the other hand, if the module fails the test… well, it is a good thing we found out now and didn’t leave it till later! (One wonders how the current system is working but lets not worry about that right now.)

The code has failed tests so obviously needs some work. Nobody wants to ship code which is known to be faulty.

Now we look inside the code, and we make a professional judgement: is it better to patch up this code and make do? Part of this judgement included remember the product is expected to continue for some time to come.

These decisions are made on a case-by-case basis. There is no blanket decision to move all the old system, nor is there a blanket decision to write everything from new. What is good is kept, what is OK is patched up and what is bad is thrown away.

The people to make the judgement call are the people who are going to be working on the code: not the managers, not the business analysts, not the project managers, not the product managers, not even the testers. All these people may have a view but there is one group of people who are recruited and employed because of their professional skills with code.

The programmers, aka software engineers, aka software developers.

Given a code module that is failing tests and is expected to have a long life these people need to make a professional decision on whether the better course of action is to patch and make do or to rewrite.

In making this decision we are accurately aware that sometimes writing from scratch can be faster than patching up something that already exists - faster both in the short run and in the long run when ongoing maintenance costs are considered.

This is especially true in software, especially true when the people who originally wrote the code are long gone and especially true when the original code was written without tests.

These decisions are made on a case-by-case basis. Where code can continue it is salvaged and reused. Where isn’t sensible then it isn’t.

So… no debate about legacy or new build: Opportunistic salvage driven by tests.

If those who believe the legacy product provides a solid base are right then there will be little new code written, sure you will need to write some tests but you will want to do that anyway.

If those who believe the legacy product should be rewritten are right then many tests will fail, code will be found to be crummy and it will be replaced.

Saturday, March 05, 2016

Non-Commissioned Managers

The last two blogs have all been about roles and people who are commonly thought of as “managers” in software development but who aren’t - Managers who are not managers and Analysts aren’t Managers - either because they happen to have the word “manager” in their title or because exhibit characteristics which programmers associate with managers.

Those blogs were written to prepare the way for this blog…

Non-Commissioned Managers are team members who fill a management role but aren’t usually recognised as managers. Borrowing a military term I think of these people as Non-Commissioned Managers. These are software team equivalents of a corporate or sergeant.

(I have to beg forgiveness for breaking one of my own rules: I’m making a military analogy. I’m very conscious that like so many people who make military analogies I have no direct first hand experience of the military and there is every chance I’m getting this wrong.)


These are people like: Team Leaders, Technical Leads, Architects, Scrum Masters and Coaches. Some of these people - Architects and Scrum Masters - have specialisations because of their specialisation they have some authority in a special area. Others like, Team Leaders, make the teams work day-to-day, they get a lot of the grief management do but few of the rewards. Such roles are akin to Sargent Majors of their teams.

On any software development teams there are a usually a group of people who are not consider managers but really do fill a management position. They may manage people, they may have authority, specialists skills or knowledge may give them authority and power, they may make decisions on behalf of the team, they may guide/coach/advise people who actually do the work, and they get listened to by the real management.

I’m including Scrum Masters and Agile Coaches here. There specialists skills give them some authority in particular areas. I know some Scrum Masters won’t like this but in many organizations the Scrum Masters is very much seen as the Sargent.

Last October I saw a presentation at a conference where the speaker talked of a company with just two managers - the CEO and the Sales Manager. Everyone else was some form of developer. But on closer examination, when you asked, the developers included technical specialists, team leads and others who filled a management role but weren’t seen as part of management.

This is akin to having an army unit with corporals, warrant officers and sergeants but no Lieutenants or Captains. Such units exist, they are usually small units. Larger units without commissioned officers exist too, perhaps only briefly when officers are killed in action. When commissioned officers are absent then non-commissioned offices fill the void. Even when there are fully fledged managers the NCO managers are necessary to make the teams work. They are on the ground, at the code face, with the team all the time.

On teams without a non-commissioned manager it is not uncommon to see a leader emerge, usually because of technical skills, sometimes because of charisma. In time these people may be recognised by the managers as the NCO/NCM, a kind of battlefield promotion. NCOs get some authority from the organization but most of their authority comes from the team because the team respect them.

(I’ve also NCOs imposed on teams who did not respect the chosen NCO. This is a recipe for trouble.)

Herein lies a lesson.

Very small army units, say a fire team, is commanded by an NCO. Fire teams form squads and squads too are commanded by NCOs. (I should say I’m getting this from Wikipedia, and the terms differ from army to army.)

Squads in turn form platoons, platoons are (according to Wikipedia) commanded by an officer, a Lieutenants. Platoons form companies which are commanded by a more senior officer, a Captain.

Do you see where this is going?

Command, management, is a question of scaling.

Small teams can be managed by non-commissioned managers but as you group into bigger units you might want commissioned managers. Or you might pretend that your non-commissioned manager is OK. If you do there will come a point where the non-commissioned manager will not be doing much except for managing.

One of the problems Agile has right now is everyone wants to know about “scaling” but a lot of Agile thinking and literature rejects management. This problem isn’t new…

During the French and Russian revolutions the bourgeoisie (managers) were shot at the start of the revolution. And now, like Napoleon and Stalin we now find that some of the things we want to do require managers. Without a respected command structure in place we have trouble enacting decisions and strategy.

One of Agile’s “scaling problems” is that we have a mixed up view of management.

Sunday, February 28, 2016

Analysts aren't managers

Continuing from my last blog, Managers who aren’t managers, I need to say a bit more about people who aren’t managers but get talked about managers.

This is a group of people who aren’t managers and wouldn’t consider themselves managers but programmers and testers consider to be managers. I’m thinking specifically about Business Analysts but there are others.

To a programmer, who rolls in at 10.30am wearing old jeans and a t-shirt to spend the whole day communing with a machine, well, a Business Analyst looks like a manager. The BA is smartly dressed, they meet “customers” and “stakeholders”, they write documents, they tend to keep business hours - because thats when the people they need to speak to are available!

OK, I’m pandering to the stereotypes but you get the message. In my experience a lot of programmers and testers wrongly consider Business Analysts to be Managers. They are not.


Interestingly if you hang around with Business Analysts and listen to them you will find that most of their concerns are the same as the programmers: not having enough time to do their job properly, being overloaded with work, not being listened to by their managers, and so on. But the two groups often end up antagonising each other.

What I’m getting at is this: there are a lot of people who are mistakenly thought of as “Managers” in a software organization.

This is important because when we start talking about self-managing teams and teams without managers these specialists often seen as part of the general problem with “managers.”

There may even be some people who are happy to make this mistake: some programmers I have know think they can do a better job than the business analysts or product manager they are working. Some of them may be right - they should switch professions. And a few of them would see these specialists wiped out at the same time as whip-cracking managers.

If we are to remove product managers just because these requirements specialists have the word “manager” in their title, and remove business analysts just because they dress smartly and go to lots of meetings, then why aren’t we removing JavaScript specialists too? For that matter database specialists and anyone who doesn’t write in the chosen language should go!

True, software development tends to work better when people are prepared to do what is needed - coding, testing, requirements gathering - rather than stand on demarcation lines and declare they won’t test because they are a programmer.

Staffing a team with people who have multiple skills, who are multi-functional and do what is needed to help the team is great. But…

It has its limits.

Few C++ programmers have the skills (or want) to code JavaScript and even fewer JavaScript programmers have the skills to code C++. The same is true when it comes to Testing, Business Analysis, Product Management and a host of other skill sets.

Just because someone’s skills set means they hold a job where they don’t code does not make them a manager.

Thursday, February 25, 2016

Managers who are not managers

I’m continuing my theme of management from my January blog (“It takes an engineer to manage engineering”) we need to clear up some terminology.

I often hear form people at Agile conferences that we should get rid of managers but they offer up no definition of manager. Let me suggest that the title “manager” is thrown around quite lightly these days, its probably just title inflation but it causes a lot of confusion. When people say “get rid of managers” I think they are usually referring to “people managers” specifically “managers” who take on positions of authority over others.

The problem is an awful lot of “managers” aren’t managers in this sense. Putting the word “manager” into a job title has a habit of making it ill defined. The same is true in code, a “SecurityManager” class or “LogManager” tend to be a dumping ground for all sorts of vaguely related functionality. Those who truly manager often find their job is a lot of vaguely related bits and pieces, thats the nature of managing.

But the title a lot of the people we call “manager” could more accurately be called “Specialist”. So you might have a “Product Specialist” or a “Release Specialists”

We have Product Managers - they don’t manage people they “manage” products. That means they talk to customers, analyse the market and, after some magic, decide what to build into a product. Its become a bit of a catch-all role. These people could better be called “Product Specialist” or still “Product Analyst.”

The same goes for “Release Managers” who don’t manage people, they administer release processes and do release engineering. They might be better titled “Release Specialists”, “Release Engineer” or “Release Administrator.”

Then there is that vague role of “Iteration Manager” I know they don’t manage people and frankly I don’t know what they do. The role only seems to exist at ThoughtWorks and former clients of ThoughtWorks but I bet it could be better called “Iteration Specialist” or “Iteration Administrator.”

To put this graphically: we can think of the set of all the people called “manager”, of these a significant portion aren’t really managers, they just use the title “manager.”


Specialists like this exercise power and make decisions not because the organization has endowed them with power but because their specialist knowledge and skills makes them the best person to do so. (Well, thats the theory, I’ve know a few who exercise power because the organization has endowed them rather than because they are particularly knowledgeable or skilled.)

Correctly naming these roles would help. Alternatively it might also help to abolish title altogether. I’m told that at the old AT&T Bell Labs everyone had the title “Member of Technical Staff.”

Harmonising title - “Team Member” or “Engineer” - appeals to me, it would break down some of the demarcation lines which inhibit people from doing what needs doing.

However people like job titles because titles form part of their identity, it describes how they see themselves and adding “Manager” to the title makes it sound more important, ones career has advanced when one has “Manager” in the job title!

(I’ve blogged about identity before, in the dim and distant past, but the two entries stand up “Who are you? - identity and change” and “The Dog and Duck is closing”).

Titles help people mark out the area they work in and the tools they bring to the job. It indicates who they associate with. However it sometimes seems that people are more concerned about proving that people in their role can save the day (another old blog “What you need is a…”).

So in summary… it is complicated, the title “Manager” does not mean someone manages anyone, anything or has any authority. Once again, look beyond the label.

Monday, February 08, 2016

Podcast with about Business Analysts in Agile

Alex Papworth runs a Facebook group (closed) called “Be a Brilliant Business Analyst.” He recorded an interview with me a few weeks back which is now available online.

Agile and the Business Analyst role

I should also point BAs and aspiring BAs at Alex’s newsletter.

And it would be a miss of me not to mention the “Agile for Business Analysts” course I’m running with Learning Connexions next month.

Thursday, January 28, 2016

It takes an engineer to manage engineering

I’ve been meaning to write about the managers and Agile software development for a long time. And, apart from a few asides, I haven’t.

Why not?

Well partly because the topic is difficult, or rather large, but mostly I’ve not written it because I’m fearful of the flames that will come down on me.

You see I think managers have a role to play in Agile, but I am acutely aware that many people don’t.

So am I steeling myself, I’d love to come up with a “grand theory of management” but I’ve been trying to do that for years! I think instead I’d start blogging about my thoughts on management, and hopefully a grand unified theory of management will emerge.

Still, I expect many people will not agree with me - there is one of them I can see right now, he’s almost standing in front of me. The funny thing is, I was a professional programmer, I got interested in management as a way of ensuring I didn’t become the type of poor manager I’d worked for.

I took time out of my programming career to study management. What nobody told me was that if you study management programmers are more suspicious of you than ever, non-developer management types will always see you as a programmer (perhaps a jumped up programmer) and programmers who have fallen into management (those with no qualification and probably no time to study the subject) don’t trust you. Add in the fact that the academic community is split over management qualifications and it’s a right mess.

Unfortunately managers and programmer are locked in a decades old existential fight.

Many on the management side of IT dream of a world where programmers can be replaced by a software tool. That isn’t going to happen, all it does it move the point at which the programming happens. If you replace a programmer with a software tool the person who uses the tool is now a programmer - whether you call them a programmer, analyst, consultant or serf.

On the other side programmers dream about replacing managers with “self organizing teams.”

Both sides want victory by proving the other need not exist - at which point they will disappear in a puff of smoke. (Sometimes it seem to be the old worker-capitalist class struggle.)

My logic is this:

  • Management is a skill like any other, like writing Java or like writing test scripts
  • Many people who find themselves managing don’t have the skill and some don’t bother to learn
  • Consequently many “managers” aren’t actually very good at managing
  • While there are a few “natural” managers - like there are natural Java developers(?) - one can learn to be a better manager

The state of management in the IT world is so bad that frequently removing the manager altogether makes things a better than they were.

Oh, and the misuse of the word “manager” doesn’t help.

The thing is…

I’m an ex-programmer, I still consider myself an engineer (another controversy) and I also think management can play a useful role in engineering software development.

It took me 10 years to become a software engineer and I never stopped learning, 34 years later I’m still learning to be a better programmer.

I also hold an MBA degree, it took me a year of hard work to get it.

1 year, not 10 years and certainly not 34 years.

Actually, it has taken three generations to make me an engineer: my farther was an engineer, and my grandfather too. I was going down engine rooms when I was 7 or 8, I’ve watched engines being overhauled. I know what being in dry dock means and I know commercial considerations and engineering considerations are often in conflict, but engineers not people in suits make it work.

Being an engineer and a manager is not a contradiction. I know that because my farther and grandfather were Chief Engineers: they took years to obtain that rank, and when they did they still went down the engine room, they still mucked in sometimes, but they also spent a lot of time “managing” the work in the engine room and on deck.

You see: it takes an engineer to manage engineering.


  • The general quality of management in the IT world is poor
  • Management itself is a skill, one which few take time to learn about
  • Managing software engineering well requires one to understand software engineering: it takes and engineer to manage engineering