I often find myself in organisations where digital teams don’t have product managers, or a product manager has been pushed to one side to act as something like a project manager. I want to fix these situations, and I typically explain the need for an empowered product manager as being about effectiveness and consistency. That is, it’s a way for a consistent product vision to be created and followed, rather than the alternative of decision by committee, in which each product iteration is just a bundle of the next compromises. This justification appeals to people’s logic, and is generally well understood. We can then go on to ensure that the product manager has access to all the key stakeholders, to hear all their needs and concerns before shaping the vision. But there’s something else that also emerges when the product manager is given a chance to do their job: trust. The product manager can build trust with their stakeholders, which in turn makes progress much easier and faster. This argument is not so well founded on hard logic, and is much more personal. People want to work with those they can trust, and their daily work and worries are much easier as a result of that. With an absent or weakened product manager decision making is about negotiation and compromise. With an effective product manager decision discussions are much more direct, and a single vision held by a single person (which is also communicated effectively) is easier to understand and work with. Even if a stakeholder doesn’t get exactly the feature the want every time, at least they understand the reasons and can see that the direction of the product has a pattern and a narrative. They can then shift their understanding to work with that. Another problem that I’ve seen with an absent or weakened product manager is that of circumvention. I’ve seen senior stakeholders go round a product manager to get what they want. And sometimes this disruption comes from the team themselves—if team members don’t respect the product manager’s role in decision making then they may alter product features independently. In both cases, a short term gain for an individual undermines the integrity and direction of the product, and therefore the value to the organisation. One note on the above. I’ve spoken a lot about stakeholders “wanting features”, which may ring alarm bells. The product team should be looking beyond “wants” and instead understand “needs”. And the focus for everyone should be on value (outcomes) rather than features. But due to the nature of my work I tend to work with organisations that, at least initially, mostly haven’t made that shift. A decent product manager will understand the difference, though, and so another benefit of having that single point-person is that they can help shift the narrative around the product to one about meeting needs and delivering outcomes. The best product managers I’ve worked with aren’t just good at the process, but they also cultivate strong trust relationships with their stakeholders, inside and outside the product team. It’s hugely rewarding to me, personally, when I hear those stakeholders speak highly of their product manager, particularly when they may have expressed doubts once before. In many ways a job that might be described as being about more effective process is actually more effective and durable because of the trust that stakeholders have in that person. _Photo by rené van haeften_ ### Share this: * Click to share on LinkedIn (Opens in new window) LinkedIn * Click to print (Opens in new window) Print * Click to email a link to a friend (Opens in new window) Email * Click to share on Tumblr (Opens in new window) Tumblr * Like Loading...

In all of the debates about the value of AI-assistance in software development there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of …

It’s a well-worn cliché that if you want to really learn something then you should get yourself a student. However, that’s quite a commitment. What’s much easier is to give a talk or a presentation. Very many places I’ve worked at have run internal “brown bag” or “lunch and learn” sessions—a regular slot where people take it in turns to present a topic while everyone else watches and eats lunch, before some discussion at the end. I’ve even organised some of these. But regular open presentation slots can happen in plenty of other places, too. It’s a great way to bring a team together and foster learning in a relatively informal or low-stakes setting. But it’s also a great opportunity for the presenter to expand their knowledge and experience. Here are two ways I’ve benefited from this from just one talk. Because it’s front of mind given the previous article, and the one before that, this is again about cybersecurity. I was overseeing a security audit, under an official framework, which was somewhat new to our organisation, so I was asked to give a short presentation in an all-hands meeting about what it meant and what it entailed. The audit framework was also new to me, but to some extent the presentation was very easy. I got to write the slides and to decide what I did and didn’t say; it’s a very controlled environment. The challenging part, though, is always the final slide, which says something like “Any questions?” I had no control over what questions might be asked, so I needed to be thoroughly versed in my subject, mostly to give confidence to my colleagues. And, of course, I would have to learn this stuff, too, sooner or later. So preparing the presentation wasn’t just about putting together a few slides. It was also about anticipating and having answers for a lot of “but what about…?” questions. It definitely forced my learning. Additionally, giving presentations on new subjects teaches us about communication. How we say something is often as important as what we say. In this presentation I was aware that the audit touched a lot of people in the organisation in small and large ways, and for most of them it would be an unwanted distraction from their main jobs. I wanted to emphasise the value to them, and so I spoke a lot about how evidence of a successful audit gave assurance to our customers; I was confident everyone from sales to tech did genuinely care about our customers. So I was slightly surprised at the end when someone asked, “But why are we doing this?” as I thought I’d covered that. I offered my response about assuring customers, and they said, “Yes, but why?” So I rephrased my answer, which obviously didn’t help, and the questioner asked their question again. This went round in circles for a while, as I struggled to connect to the questioner. Eventually a colleague chipped in and said, “Because if we do this audit once with a recognised authority then we can show the accreditation to any customer who wants it, rather than undergoing an audit for each customer individually.” The questioner was happy with this answer. It was a lesson to me about communication: what message resonated with the audience. And I think this is true for presenting all kinds of material that is slightly outside our comfort zone: we’re forced to learn a bit more about the subject, but we also learn about how to communicate it. _Photo by Neal Patel_ ### Share this: * Click to share on LinkedIn (Opens in new window) LinkedIn * Click to print (Opens in new window) Print * Click to email a link to a friend (Opens in new window) Email * Click to share on Tumblr (Opens in new window) Tumblr * Like Loading...

Following on from last week’s post about cybersecurity, I wanted to write about a small practical security-related activity I was involved with as part of a regular security audit. Long-time readers will know that I have a deep dislike of the traditional “risk listing” approach to risk management. One problem is that it reduces complex issues to a misleading “point” score based on pseudo-scientific likelihood and impact. But also, simply listing things is too often a displacement activity for dealing with the underlying problems. There are better ways. In one organisation, as part of our general security stance we did have a large number of security-related worries we had written down. This was not in itself a bad thing. It demonstrated that our security-minded experts were actively thinking of possible attack vectors and vulnerabilities. However, this left us with three problems. First, as part of a practice security review it became clear that any auditor expected to see those pseudo-scientific likelihood and impact ratings. It would be no use trying to convince them of the error of their ways; an audit is not a time for a re-education programme. Second, it still left the problem of “so what?” Sure, we understood our failure modes and likely paths to exploitation, but what were we going to do about it? Third, it was a very, very long list of attack vectors and failure modes. Some of these might have been things might have just accepted, but our world constantly changes, so what we might accept today might not be what we accept in 3 or 12 months’ time. And some of these were things we needed to improve, possibly with non-trivial technical and organisational processes. In other words, going through the list with seriousness would require a good deal of time, and it felt rather overwhelming. The second and third of these were the most important ones. None of us on the team were doing this as a tick-box exercise. We wanted be as secure as we reasonably could, and we wanted to explain this with pride to customers as well as auditors. To tackle this, I introduced a combination of the near-obligatory likelihood and impact score with a time element, which was a date when the line item was last reviewed. I love a good spreadsheet, so these three variables combined to produce a priority rating. A higher priority was driven by the combination of a high likelihood and impact together with the age of the last review. Then a small team of us reviewed the spreadsheet monthly. We would examine all the Priority 1 items, and maybe some Priority 2 items, but we made sure we addressed them each thoroughly. For some we might agree that we were satisfied with the status quo, and noted that. For others we might take an action—for example, to update a configuration file, rework part of a system, look at a new product, and so on. In that case the person’s action would go into our overall task system where it would be part of our regular work. In all cases we updated the review date. We balanced the formula to ensure a couple of things. First, that low-level items were guaranteed to get a Priority 1 rating if they were left long enough—in our case a year. Second, that we wouldn’t be overwhelmed with Priority 1 items every month. In the end our monthly review meetings were quite straightforward—it was a routine we became practised at. We would go through all the Priority 1 items one by one, discuss each briefly, and update the spreadsheet. If we had enough energy we might then go through some Priority 2 items. When tackling large items we didn’t try to solve them all in one go; simply moving them a step forward was progress. Personally, I never looked forward to those meetings, but there was a real sense of achievement at the end. I still see no redemption for those impact-likelihood calculations. But when combined with a time factor and an imperative to review and maybe act we did make genuine incremental improvements to our situation, and were able to demonstrate that clearly. _Photo by Clint Gardner_ ### Share this: * Click to share on LinkedIn (Opens in new window) LinkedIn * Click to print (Opens in new window) Print * Click to email a link to a friend (Opens in new window) Email * Click to share on Tumblr (Opens in new window) Tumblr * Like Loading...

There’s a difference between believing something and experiencing it. In my case I think–I hope—I’ve always been supportive of cybersecurity and infosec protection. But I know I’ve also often been annoyed by the efforts of some security colleagues trying to enforce certain actions or processes in organisations that I’ve worked in. However, over the last few years that’s changed, thanks to having experienced some security lessons first hand. Here are the two that I think had the biggest impact. One is where I was managing a bug bounty programme. The organisation offered monetary rewards for anyone who could find security holes in its online software and services. It was my job to read the reports and evaluate them. Many of the reports were invalid—some fell outside the bounds of the programme (for example, finding problems with our email system, which was externally managed), and some had been previously reported (we only rewarded the first report of a problem, and we didn’t always get to fix them immediately). But a remarkable number were genuine security holes. One was actually a deliberate design feature which no-one had realised exposed personally identifiable information; it took an outsider to recognise that. Most of the others were just flaws. This was in an organisation with highly skilled developers and several security-conscious individuals, and which conducted regular pen testing, but there were still gaps and flaws that could be exploited. I had to marvel at the individuals who spent hours hypothesising and testing elaborate mechanisms to compromise confidentiality, data integrity, or system availability. But it showed me first hand that all but the most trivial systems have hidden complexities, and those complexities can be exploited. The second experience was during a security audit. Actually, I’ve been part of quite a few security and security-adjacent audits over the years, and this is a lesson from several. Manual processes will fail. In one example we failed to show that a problem revealed in a disaster recovery exercise had been followed up. We’d done the work, but we couldn’t show the link from uncovering the problem during the exercise. In another example, in an audit request to review the paperwork of a very small percentage of randomly-selected employees, we were unable to find one document for one of those employees. The half-joking lesson for future audits is: If there is some missing document or piece of data in any of your systems (organisational or technical) then your auditor will find it. The more realistic lesson is: any system which can fail, will fail somewhere along the way. We need processes which account for that. I still meet security experts who get in the way of progress, and prevent their organisations from making informed decisions about risk and uncertainty. But I’m also much more appreciative of those who try to ensure cybersecurity is taken more seriously, because much of the time their concerns are valid. And often in ways none of us understand until we see it first hand. _Photo by artmajor24_ ### Share this: * Click to share on LinkedIn (Opens in new window) LinkedIn * Click to print (Opens in new window) Print * Click to email a link to a friend (Opens in new window) Email * Click to share on Tumblr (Opens in new window) Tumblr * Like Loading...

Last week the Python Software Foundation (PSF), the group that oversees the development of the Python programming language, announced it had turned down a grant of $1.5m from the US government. This was something they had actively sought, having gone through a difficult months-long bureaucratic process, to improve the security of the Python ecosystem, with applications to other software environments. There would have benefited the software industry at large, and the sum is significant not just in itself (it buys a lot of time from a lot of people) but also relative to the PSF’s typical annual budget of $5m. The problem with the money was that there were strings attached. The PSF’s board discovered this only when they received acceptance of their bid. From their statement: > We became concerned, however, when we were presented with the terms and conditions we would be required to agree to if we accepted the grant. These terms included affirming the statement that we “do not, and will not during the term of this financial assistance award, operate any programs that advance or promote DEI, or discriminatory equity ideology in violation of Federal anti-discrimination laws.” This restriction would apply not only to the security work directly funded by the grant, **but to any and all activity of the PSF as a whole**. Further, violation of this term gave the NSF the right to “claw back” previously approved and transferred funds. This would create a situation where money we’d already spent could be taken back, which would be an enormous, open-ended financial risk. In case the rejection needed further justification, the PSF noted that “Diversity, equity, and inclusion are core to the PSF’s values” as written into their mission statement. I’ve written much about value before. When we build a product or embark on a programme or project it’s important to be very clear of the value we are seeking so that we can make decisions clearly, harmoniously, and more objectively. Typically we expect value to be obvious material things such as money, (increased) number of users, or retention. Something such as security is less tangible, but it also has a material impact on the real world. Receiving $1.5m is pretty material, too. But looking only at the immediate, obvious value can be looking at it through a very narrow lens. There are second order effects to what we do. Our work usually has some wider impact. This may be a social impact, but (or perhpas that should be “and”) our society is connected. People’s daily pressures and life quality influences how they spend their time, who they favour, how much money they have, what they spend that money on, what they say in public, how they act, and much more. Ensuring the PSF and its work encourages diversity of particiption and thought might be seen as an important boundary (or what I often call a constraint) within which it insists on working, or it might be seen as value for the wider Python project. But either way, they have consciously recognised it and insisted on it. And while the benefit of this diversity may not be obvious, it is material. Additionally, via their mission statement they previously set expectations that they would act in a certain way, and reversing that would also have consequences with their stakeholders and supporters. This reminds me of Hopper & Hopper’s excellent book “The Puritan Gift”, which traces the failures of the US business system. They highlight the shift in the 1980s and 1990s to the “doctrine” of “stockholder value” in which the idea “that the board must somehow balance the interests of stockholders against the interests of other stakeholders” is declared “unworkable”. It surprised me, when I originally read that, to understand that pure shareholder profit-seeking was not always a goal for companies. It was previously the norm for leaders of (even commercial) organisations to account for the wider societal impacts of their decision making. The Python Software Foundation has reminded us that looking only at obvious material value is narrow, and considering the wider impact of our decisions is not only possible but also easier than some might think—the PSF’s blog post notes that the decision to withdraw their bid was take unanimously. So not only have they taken a decision that might have been seen as difficult, they have set an example for the rest of us. From time to time we will leave our current role and go on to something else. We may then look back and see our earlier times more dispassionately. We may ask ourselves: did we make good decisions? The PSF shows we can. _Photo by Steven Severinghaus_ ### Share this: * Click to share on LinkedIn (Opens in new window) LinkedIn * Click to print (Opens in new window) Print * Click to email a link to a friend (Opens in new window) Email * Click to share on Tumblr (Opens in new window) Tumblr * Like Loading...

I recently spent a bit of time with some teenagers on a day of interview practice. The idea was to give them each an experience of being interviewed, whether for a job or a place at college. Overall I was very impressed with the confidence and experience of many of them—certainly much more than I’d have been able to demonstrate at that age. And one of the topics that came up was teamwork. If someone said they were good at teamwork, or they were looking for a job that needed good teamwork, I would ask what they thought that meant. What does a good team player do? How do they behave? In fact, some time before I had the privilege of working with one of the most cohesive teams I’d ever worked with. It’s true there were some people demonstrating leadership—the delivery manager orchestrated the work, the product manager made product decisions that everyone respected, and a technical lead acted similarly on the technical side. But together they demonstrated very impressive teamwork. When I commented on this to their managers I found myself using the word “egoless”. Everyone treated everyone else with respect, would listen to their thoughts and ideas, and was genuinely willing to try new things. But most of all everyone was unafraid of working beyond their job description, of helping others, and of being helped. The user researcher was very happy for anyone else to analyse and write summaries of (videoed) interviews, the designer was happy for others to create design ideas, and the delivery manager was very happy for any team member to design and run a group workshop. No-one let their ego get in the way of the work and their commitment to the team. I think most people regard developers as the heart of a digital product team. Certainly there are often more of them than of any other kind of person, and their work is hard for others to pick up. They are also often highly specialised. Many organisations have a career path for software development labelled “individual contributor”, in which as you become more senior you become more and highly specialised, contributing directly in ways that few others can, and without being a manager. Rightly or wrongly these people can be thought of as “more valuable”. But in the egoless team it was the less specialised, more general, individuals who demonstrated the most remarkable value. They came from operational business areas, so where experts in the business work, but not with the depth of the software people. And perhaps because of this they were even more willing and able to work more widely, stepping into others’ shoes if someone was away, working alongside someone, or learning new skills and tools. Being egoless meant an individual could have broad impact, beyond their job description on paper, and as a result the effectiveness of the whole team rose. When everyone acted like this it was notably impressive. Deep specialists can be hugely valuable and are often essential. But egoless individuals, of any background, also add remarkable power. _Photo by B. B._ ### Share this: * Click to share on LinkedIn (Opens in new window) LinkedIn * Click to print (Opens in new window) Print * Click to email a link to a friend (Opens in new window) Email * Click to share on Tumblr (Opens in new window) Tumblr * Like Loading...