When we want to encourage others to do something with us it’s natural to want to frame it positively. But it’s also important to be honest, and in particular to explicitly acknowledge any pain that people might be feeling—honest conversations tend to be more productive in the long run. Also, pretending the pain is not there distances us from those we want to bring along. I realised this forcibly several years ago when I was working with a tiny startup whose only client was refusing to pay their bills and, therefore, preventing us paying our developers. The client said they would pay if we did one small piece of work, but the developers had had enough and refused. They were already owed quite a bit of money, and they had run out of trust. I needed to persuade them to change their mind, so that all outstanding funds would be released. I realised the only way I could demonstrate any credibility was to acknowledge the injustice. This took a very long time, as we talked through every detail of the recent past and understood what it meant to people. The developers were outstanding individuals in so many ways. They did not deserve this. They did have every right to walk away. But in the end they did agree to do the extra work and—eventually—they were paid. Something that dramatic doesn’t happen too often to me, but even in lower stakes situations acknowledging pain is just sensible. Of course, not all pain should be accepted. I also worked with a company who had a client that consistently treated us very poorly. They always demanded more, never acknowledged our good work, and they consistently incentivised us through threat rather than reward. They brought in meaningful revenue for the company, but our senior leadership team worked to reduce that dependency and then finally terminated the contract. There was some celebration when that was announced. Recognising and talking about the unpleasant things in our work allows us to address the situation honestly, and find solutions together. That may require feeling the pain and doing it anyway, or realising that we don’t have to accept it after all. _Photo by Don Shrimpton_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

Someone was talking to me recently about process and how different functions do or don’t work successfully together in an organisation, and as part of that they talked about the need for fuzziness between functions. That is, if we are to work together successfully we need a bit of give and take—the ability to flex in what we’re able to do and say. Rigid processes too often lead to mechanical, robotic interactions, a loss of empathy, and a loss of respect for each other. This is detrimental to both the individuals and the work that needs to get done. If we were to ask our ourselves how much fuzz we need, a broad heuristic would be that it depends on the size of the organisation. In a tiny startup—say, four people—there needs to be a lot of fuzz, particularly internally. Everyone needs to help out with everything, and probably there is constant chatter that helps everyone keep up with each other’s world. At the other end of the spectrum an organisation with tens of thousands of people needs a lot of very clear process, just to avoid chaos from so much going on and so many people unaware of each other’s situation. As a first estimate it looks as though we need near-zero fuzziness. But there are a couple of other considerations. First, even in an large organisation some flexibility and understanding is welcome. When I’ve worked in large organisations and needed something from someone in a team I’ve never contacted before, if I don’t immediately get what I want it’s quite depressing to get just a No, or a “Please fill out this form” without any hint of what might happen beyond that. It’s much more encouraging to enter into a short dialogue, each of us learning about our mutual context, and some exploration of options, however brief. Even in a 10,000 person organisation that distant team might only be three or four people, and it’s good to get to know one of them by name and to make some contact on a human level. Second, we don’t always want to help every person—they might turn out to be fraudsters or otherwise not acting in good faith. SIM swap fraud happens too often because of social engineering, in which that human level contact is seen as a weakness to be exploited. In this case, at least, process that depends on people won’t work; protections need to be built into mechanical systems. One example would be a (computer) system that does not show the call centre agent the customer’s password (as was that case at one telco I used to be with) but instead simply confirms or denies three of its characters. So, not all organisational boundaries should be equal. But I do find it helpful recognising the need for and value of fuzzy organisational boundaries. _Photo by Pati_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

Last week I wrote about keeping the magic in a team—that when we introduce some process or framework it’s important to recognise the strength of our team, what makes us special, and ensure we maintain that, if not enhance it. But what if we’re starting from scratch? I was once asked to advise a startup on introducing Scrum. They were just assembling their development team, so there was no history of relationships or delivery, and the executive was mostly new to building digital products. They had one senior person who was experienced with Scrum, and who would lead the development team, but the exec wasn’t very comfortable with some of the Scrum concepts, particularly in terms of planning and decision making. I was invited in to give a slightly more independent view and answer questions. One of the discussion points was around how much of Scrum to implement. At one point I commented that I knew very few organisation that were doing Scrum by the book, even though many of them were doing 80% or so of it. The executives started debating which elements they would like to change. Maybe we should have a committee instead of a single product owner. Maybe the Scrum Master should be more of a manager. Maybe we should fix 6 months worth of backlog right at the start to ensure we get what we want. And so on. But I emphasised that while only 80% of the framework might be right for them, we didn’t yet know which 80%. Scrum in particular doesn’t have many moving parts; each element that’s there is powerful in its own right and supports other elements. Taking it apart before you’ve really experienced it and understood it first hand will inevitably lead to problems. Consider the concept of incremental planning—regularly reviewing and adjusting the list of forthcoming activities. It might be comforting to set a plan in stone right at the start, but the process of continually adjusting the plan forces a discipline that’s incredibly valuable, even if it’s uncomfortable at first. Shying away from this before we begin would deny us that experience and that capability. Sometimes we need to force ourselves to embrace a framework in its entirety to really understand it. That first hand experience gives us much more authority on the subject, particularly in regard to our own environment—our people, our org structure, our pressures, and so on. Once we have that we can make much more informed choices about how to adjust it. _Photo by Burnt Pixel_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

I’ve worked in a lot of places, and learned many things over the years. One of those things is what a typical successful digital product team looks like. This includes having a product manager, daily stand-up meetings, a carefully managed backlog, and so on. These things are fairly standard and unremarkable to many, but not everyone does them, and those that do don’t always do them effectively. So it can be fairly easy to identify gaps and help people made corrections. Doing these things certainly doesn’t guarantee success, but it does create a solid baseline to work from if things aren’t going too well. However, when we propose changes we need to be careful that we are aware of context. Most teams want to improve somehow, but many teams—and organisations—have their own unique strengths. It’s important to recognise those and make use of them, rather than thinking that every team needs to look and work the same. In one organisation I worked with people were encouraged to think broadly about their work, and while everyone did have a job title most team members were willing and able to pick up all kinds of tasks. This meant less specialism but more flexibility. Stand-up meetings and planning sessions were less systematic than I would have expected, as there was lots of discussion about who might do what, but it meant the team could work at a steady pace, even as one person left or another joined, and knowledge sharing came naturally. In contrast I was at another organisation in which the CEO sent in some business consultants who interviewed a lot of us and then proposed a change plan that didn’t seem to relate at all to who we were. It seemed like a rather generic proposal, and while there were certainly things we might have done better, the proposal didn’t obviously achieve that. Perhaps not surprisingly it didn’t take hold and we continued largely as we were. Every team or organisation has some magic about them, something that has seen them achieve the success they have to date, even if that success is simply survival in the face of competition. When we seek to change things or improve it’s important to keep that magic in mind and not lose it. _Photo by Mashthetics_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

Last week I wrote about product management without a product manager. That is, even if our team doesn’t have someone labelled as a product manager there are still lots of things that need to be done which would be done by a product manager if we had one. Someone has to take those on. One of those jobs relates to coordination—pulling many organisational threads together. But this is not confined to product management. It’s needed in any situation where there is some diversity of stakeholders and conversations. Nor is it necessarily project management. As an example, teams that deal successfully with security incidents typically assign a coordinator at the earliest opportunity after an incident is recognised. There are many avenues to investigate, theories to generate and test, actions to be decided, stakeholders to communicate to, and so on. This is not a project in any traditional sense, but many of those kinds of skills apply. Commercial agencies often have to respond to tenders. Again, this requires coordination as a small initial group sets an overall plan, various experts contribute their part, someone may return to the client to ask questions, and the whole thing is compiled, checked and submitted before a deadline. This is much more like a traditional project, though it’s rarely called that, and the coordinator in unlikely to be called a project manager. We can’t just wing it and rely on everyone’s dedication. Or at least, we can’t just wing it and expect good results efficiently. I’ve worked with a few teams that talk about self-organisation, but if that works it’s when it’s a small coherent group and everyone meets and talks together very frequently. If either of those conditions are not met then giving someone the coordination role will save a lot of time and miscommunication. _Photo by Lucía Mejuto_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

I’ve long-valued working with product managers, even though at first my understanding of the discipline wasn’t as deep as it is today. But some organisations or teams don’t have them. There are often good reasons for that. One reason is budget. Some organisations are just too small to hire another person. Another is that some teams benefit from being small, and involving another person would stretch communication unnecessarily. Early proponents of agile development advocated working directly with “the on-site customer”, and certainly at that time just delivering anything at all reasonably quickly was a huge trimiumph for many teams. There was no mention then of product managers, though we did have “product owners”. However, even if having a product manager on our team isn’t feasible, it’s still important to understand the things they do, because very often those things still need doing. There does need to be a coherent vision. We do need to listen to the people who use the product. We do need to distinguish between their needs and the wishes of the senior people with influence. We do need to balance what we hear against our organisation’s own needs. We do need to prioritise the top piece of work now from the 150 other things we might do, and make hard decisions around that. We do need to think about what this thing will look like in 12 months’ time and keep our eye on that even though we have to deal with the demands of today. For these reasons, I sometimes talk to people not about needing a product manager, but who will do the product management. On a small team that might not be too difficult, but those things do need to be done consciously. We might not have a product manager, but we likely still have a need for product management. _Photo by R.A. Killmer_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

Recently I’ve been thinking again about how we divide up work, and the choices between tackling it in horizontal or vertical slices. To recap, delivering in vertical slices is when each small step (a user story) adds a bit to each layer of the product to produce some incremental change that’s generally visible to the end user. Horizontal slicing is when each small step builds from the bottom up, starting with the foundations, and it’s only toward the end that end users see anything new. There are other ways to think about delivering incrementally, too, which are compatible with both these approaches. Delivering in vertical slices is certainly the more successful approach, but it’s important to recognise where it isn’t superior. I can think of a few ways. One is in the planning stage. I’ve found that many teams and individuals find horizontal slicing much easier to plan. If we have a picture of the whole system in our head then it’s quite natural to want to construct it starting with the foundations and building up from there. Even the word “foundations” suggests building a house, and it seems reckless to build a house without first making sure the foundations are sound. But that’s just an analogy; building software is not building a house. Software is soft, by definition, and code already written can be changed quite easily. However we do need the right scaffolding for that, including automated tests. Planning to build in vertical slices is less natural, and I’ve found that people who are used to the horizontal approach will often say that for their particular project it’s impossible to do otherwise. I’ve also found that persistence, patience and imagination proves otherwise. And it gets easier with practice, to the point where it even becomes natural. A second way in which vertical slicing isn’t superior is when the end state is unarguable or irrelevant. More specifically, if we are interested only in reaching some very specific target, then neither approach is faster than the other. In terms of time, vertical slicing is no faster than horizontal slicing, everything else being equal. But that phrase “everything else being equal” is doing a lot of work here, and it’s best explained by clarifying what I mean by the end state being “unarguable or irrelevant”. I mean that everyone agrees with all the details of what we’re building and that we won’t change our mind (unarguable) or that we don’t care about whether the end state is actually worthwhile (irrelevant). That last case might seem implausible, but it can happen if the build is being undertaken by a third party who simply wants to fulfil a contract and has no stake the value that the product will produce. That’s clearly not desirable, but it can happen. The problem with an “unarguable” goal is that our vision of a product at the start of a build is, in practice, imperfect. This is often captured by the acronym VUCA—volatility, uncertainty, complexity, ambiguity. We are imperfect, the world changes, our expectations may be confounded, and we can misunderstand each other. So we do get to our target end state at the same time with either approach, but the resulting product doesn’t produce the value we expected. If we use vertical slicing then each slice allows user feedback that we can use to check expectations, alter our plans and steer ourselves to a more successful outcome—a product that does produce the value we wanted. If our end state is unarguable or irrelevant then that feedback, and our ability to steer, isn’t needed. The third way in which horizontal slicing is just as good as vertical slicing is if we aren’t interested in delivering value early. If our stakeholders absolutely believe and insist that it has to be all or nothing, then no vertical slices are going to be released until everything comes together at the end. I’ve found many stakeholders do insist on all or nothing—they want to launch a product that they can shout about in its entirety, and are confident enough that smaller groups of early users won’t offer any real value to them. But I’ve also found that if delivery overruns, which is common, or pressure on them changes then they quickly change their minds. Suddenly, getting most of a product out by a deadline is more important than getting everything they wanted out much later. Unfortunately horizontal slicing doesn’t allow that option. So there are ways in which horizontal slicing is no worse than vertical slicing, and when it comes to ease of planning it’s actually better. In practice most people find the uncertainties of the world (VUCA) are far too great to ignore. If we can put in the initial effort and imagination to create a plan that vertically slices the work then that has significant benefits, and allows us to steer around many crises. That said, there are situations when the key stakeholders are quite relaxed. Perhaps the stakes are low, the goal really is clear and straightforward, and the timescales aren’t significant. In that case, either approach is fine. In practice vertical slicing is almost always the optimal approach. But we need to be honest about where it isn’t better, and recognise there can be situations where the difference doesn’t matter. _Photo by Indiana Public Media_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

The other day I found myself reading about Cyber Essentials and Cyber Essentials Plus, two UK infosec standards, and was struck by the clearly stated difference between them. Cyber Essentials requires you to have certain security policies. CE+ requires that you also demonstrate them. This points at a common gap between infosec policy and reality—and probably any policy and reality. That is, it’s all very well writing down what people should do; what matters is whether they actually do it. And that gap can be very large indeed. It’s very easy to create policy that’s irrelevant. We just write it down and forget about it. On the other hand, if a policy is to be tested then it focuses the mind. Are we describing reality? If this is our intended reality, can we do it? Can we be confident _everyone_ will do it? What would it mean to demonstrate that? How would we gather the evidence? How much work would that be? Would the evidence be sufficient? And so on. A few years ago I created a number of infosec policies for an organisation, and it wasn’t trivial, because an audit would follow. I had to ask myself the questions above for almost every sentence, and of course these words were then reviewed and discussed with peers. For the most part the result reflected reality, but in some cases what we currently did wasn’t good enough, so we needed to introduce some changes to the way we worked, and those changes needed to be reasonable changes to everyone’s daily working lives. And, again, we needed to be sure those would stick without some clipboard-wielding manager (me) breathing down their neck every day. Additionally, we would sometimes find our reality shifted. We might find that an internal process was no longer practical, or we wanted to introduce some technology change that didn’t fit with our current policies but which we still considered secure. Then we would need to update some policy wording; sometimes we would need to check that a change in one document didn’t contradict another document. All this was slow, careful work, but our policies did reflect our practices, our practices weren’t disrupted, and our successful audits demonstrated that we passed the required security expectations. If policy is never tested, if it’s never demonstrated, and there are no consequences for failing to meet the test or the demonstration, then the policy is just a waste of words. If the test or demonstration is never experienced by those that write the policy, or if the writers’ motivations aren’t aligned with the motivations of those subjected to the policy, then it can be worse than a waste of words—it can be unhelpful. _Photo by Andrew Magill_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

As individuals and as teams, we sometimes say we want autonomy. But all things are on a spectrum, and autonomy is no exception. So it’s not a question of whether we have autonomy, it’s more how much autonomy we have—or want. Then when it comes to requesting or giving autonomy we have to ask how much is appropriate. How would it be if an individual or a team are allowed to make this kind of decision, or do that kind of thing, on their own? There are two dimensions to assessing this: context and capability. To make good use of their freedom, the individual or team needs to have context—to understand the issues, the environment and the consequences of their decisions and actions. In other words, to best understand their inputs and outputs. Then we need to be confident they also have the competence—the skills to execute their consequential actions successfully. Let’s consider two examples near either end of the autonomy spectrum. Many large consulting firms have a model in which they charge a lot of money for client account managers and hire large numbers of junior developers. A client recognises they are paying a lot for the impressive and dedicated managers, and a few other senior people such as technical architects, and are happy to be paying much less for the many developers they rarely see or interact with. The developers themselves are fed instructions by the senior people, have to do what they’re told, and are largely kept out of the way of the client. They are given little context to make their own decisions and, being junior (or at least paid and charged as such), are not considered to be that skilled relative to their colleagues. By contrast, many modern digital product organisations are structured to have smallish teams, each with a clear user-centred focus and a dedicated product manager. The focus, plus the work the product manager, ensure the developers on the team have very high context. They see product strategy and what the users do. They see the user research and may even participate in it. They have high context and, working as a team, are recognised as highly skilled. They can combine their technical expertise with the needs of the users and the product strategy to give new and valuable insight. As such they are key influencers in what product work gets defined and how it’s done. Gaining more autonomy is typically difficult in practice. One thing is to demonstrate good use of the context we have—for example by asking relevant questions, offering alternative solutions, recognising sensitive relationships, and so on. The other thing is to demonstrate high competence—showing that we can be trusted to make good technical judgement calls and deliver somewhat better than might have been expected. This is what one team and I did a while back. The limited autonomy wasn’t set by our organisational leaders; it was set by a client who insisted on a very specific list of features. This was, however, accepted by our own leaders. We found ourselves delivering something which, we felt, would not best achieve what the client wanted; and, it has to be said, we were doing that poorly. With significant effort we changed that. We changed our working practices to ensure we began to deliver what the client requested, more quickly and more reliably than we had before. Then using that recognition, and the increased trust that came with it, we began to suggest improvements to the things the client was asking. Gradually, these were accepted and then increasingly valued. Many people were involved in this shift, including product and project managers (who interfaced most with the client) and developers and team leads (who needed to shift their approach to the work). But together, by demonstrating a strong understanding of context plus high competence we achieved greater autonomy, an overall improved result, and a strong trust relationship with the people who had first determined that low-autonomy setting. _Photo by Michael Dain_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

An old friend and former colleague and I were recently talking about SAFe, the scaled agile framework, and he asked me about a big project we’d both worked on many years ago: Did I think it was successful because we didn’t use a big methodology? Certainly there were many reasons it was successful—great people, an engaged programme board, the willingness to be flexible, trust in each other and our respective roles, pragmatic technology choices, everyone working in the same physical space, and probably more. But certainly having a simpler approach to delivery helped. There was just less to keep in our heads. We had people who acted in a project management-type role, facilitating the work, working tirelessly to remove blockers, and so on. And there was definitely some process in what they did, which was primarily around tracking the work, which enabled us all to work together better. But all of this work was value-add work. It clearly contributed directly to the end result. Administration-type work was minimal. Budget tracking was necessary but fairly simple. Risk management was mostly about raising concerns, keeping an eye on them, and having practical conversations. Written updates were minimal because the major mechanism of reporting consisted of demonstrations of working software. Senior people saw those and could therefore satisfy themselves about what was really being produced. What we created went into use immediately, so feedback from users was immediate. We were fortunate to be working in an organisation that didn’t impose a “standard” methodology. We created our own, based on past experience of what worked. I remember one senior stakeholder who came from a traditional project management background, and they did ask very difficult questions. But once we had got past the terminology barrier those questions were grounded in very sensible concerns, and in the end they just held us to a higher standard. Process is valuable—it ensures we have a common way of working. But if we define “culture” as “the way we do things around here” then much of what process achieves can instead be achieved through an appropriate culture. In our case much of our “way we do things around here” allowed us to think less about process and spend more of our time and effort focusing on what was really valuable. _Photo by UpChuck_Norris_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

Last week I talked about a time when the Facilities team in an organisation where I worked blocked the use of wheelie whiteboards to allow our tech teams to see and organise the work. That’s not the only time I’ve experienced it, and it was only on the second occasion that I understood the root of the problem: the Facilities team were not motivated by the same things we were. That’s not to say that I expect the Facilities people to be excited about software development, but we—them and the product teams—should always recognise that we are there for the same purpose, which is the purpose of the organisation itself. We are on the same side, and even though we each have our specialisms, skills and focus, we still need to be directing those to a common goal. Instead we are too often working in silos. I’ve written before about the security expert who seemed to be simply “requiring” difficult changes to our system, without apparent regard for the overall goal of our work. Silos are created for at least one sensible reason—they make the organisation much easier to manage. The CTO doesn’t want to be dealing with waste management, and the CMO doesn’t want to be thinking about infosec. Those functions are parcelled out to those who care about them and can manage them skilfully. We don’t call it “siloing” when we do this, we call it “division of labour”, but too often that’s what it ends up as. But this “sensible” division of labour often means we miss a more important point: the purpose of our organisation. The Facilities people think about the possibility of someone tripping over and hurting themselves; the software developers don’t pay too much attention to a physical environment that “just works” around them. However, I’ve also seen times when these potentially separate strands work together. In that article about the security expert I mentioned the second expert, a colleague of the first, who had a very different attitude. They recognised that security and delivery need to be balanced. They provided expert advice, not requirements, and we embraced them into the team much more as a result. Finance and HR are other areas where representatives of those functions can create barriers, often through inflexible or unhelpful process, sometimes with opaque language. But again I’ve seen cases where such people were consistently positive forces. This happened when our product function had a dedicated Finance or HR person allocated to us. In an office environment they sat close by. They got to know us personally, and our work and needs, and we got to know them. They were still formally part of Finance or HR, but their remit was to help us work successfully within the bigger machinery of the organisation. People in different functions can act in opposing directions, especially when their goals are not aligned. But this doesn’t need to be the case, and there are ways to enable those different functions to work together very successfully. _Photo by @shotbyrichie_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

I often work with teams that “know” that some particular thing should happen in or around their work, which needs the support of others, and they can’t get traction on it. They’ve tried to push the idea and it’s gone nowhere, so they’ve given up. But sometimes there’s someone who actually gets it done. That might be me, or it might be someone else. And often when it does happen it appears slightly miraculous. How has this person enabled this thing, which has seemed impossible for so long? The important thing to recognise is that there is a difference between “knowing” something needs to be done and convincing the relevant people to actually do what they have to do in order to enable it. One small but important example is from many years back when my teams wanted to use portable whiteboards to track their work on kanban-style boards. The Facilities team wouldn’t allow the boards anywhere near our desks on the grounds that their wheelie feet stuck out and caused a trip hazard. I therefore got pushback from the COO (under whose remit the Facilities team fell) and it was a great source of frustration for all of us who wanted easy and effective visibility of our work. Then one day I got a new boss, who heard about this frustration, and magically the whiteboards appeared. I have no idea how she did that, but it did seem miraculous. But I can say how I enabled one of my teams to refactor a major part of their codebase. It was created as a monolith—a single piece of software. There was poor structure, including poor separation of concerns, simply because the monolith design didn’t enforce such things. It was therefore a real pain to work with. I’m quite certain the structure was entirely appropriate for the time when it was created, but now things were different and it was a problem. The team “knew” it needed to be broken up, but they couldn’t get the time to do it. Instead they had a big product roadmap to work on, and that was only when they weren’t fixing urgent bugs. If there was any time left over (which was quite minimal) the next priority was client-specific features, and the very limited time for that frustrated the Customer Success team. Breaking up the monolith was a distant last on the priority list. The solution to the team’s problems was to align their needs with those of the other key stakeholders. I saw that the source of so many of the urgent bug fixes was the poor structure of the code. Additionally, the goal of the company was to grow, including adding more developers, and that would be untenable if we had all those developers working on the same monolithic codebase. So aligning everyone’s needs was a matter of demonstrating first that if we broke up the monolith we’d reduce the number of all those urgent bug fixes, and so allow more customer-specific work that the Customer Success team wanted so much. Breaking up the monolith also enabled the company’s overall goal, by getting to a software architecture that many more developers could work on at a faster pace. And because the product roadmap was derived from the company’s overall goal, breaking up the monolith aligned with and supported that. Identifying the problem and enabling the solution are not the same skill, and may not lie in the same person. I doubt my boss in the first example would have identified the wheelie whiteboards need herself. But when presented with it she convinced the right people. Equally, not every problem simply needs the right argument and action to solve it. Sometimes it also requires the right time. My team with the monolith shared with me all kinds of problems, but I identified that specific one as the priority and found a way to solve it. When I eventually left there were still other problems to solve, but I know they were in a much better position then when I started. As with so many things, this is also a matter of practice. By continually looking for opportunities to solve problems, and continually trying different ways to solve them, it becomes easier. _Photo by Tony Magliery_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

Kind of bummed that this petition against a monstrous AI data center has not yet broken 6,000 signatures. “One of the world’s largest AI data centres is being planned next to Auchtertool village in Fife, Scotland. The height of six double decker buses and length of 100 football pitches. An estimated 20% of Scotland’s energy will be consumed by this.” https://www.change.org/p/stop-the-proposed-ai-data-centre-near-auchtertool-fife

A short time ago I attended a presentation in which Dennis Stevens was saying that an organisation’s strategy should be “self-revealing”. That is, the strategy should be designed to provide both timely feedback on how successful it is, and options to steer and adapt it. I found this to be a hugely valuable idea, and want to expand on it a bit here. First, the “timely feedback on how successful it is”. This means that there should be frequent data generated about the value the strategy is delivering. Often a strategy is tracked by how far we are through our plan for it. This is not feedback on value, it’s just feedback on implementation progress. Implementation progress is interesting, but it doesn’t tell us whether our assumptions or suspicions (about whether the strategy would be successful) were correct. And even if they were correct at the start, things may have changed by the time we’re 3, 12 or 18 months into it. So feedback on current value actually being delivered is essential, for the purposes of… Second, “options to steer and adapt it”. The feedback data we get from our work allows us to make small but important changes that allow steering—a bit more funding here, a bit less emphasis there, and so on. But it should allow us to make more significant changes, too. The feedback data should allow us to spot new opportunities and follow them. It is generating options in an always-uncertain world. It’s important that the feedback mechanism is designed into the strategy. If it’s pasted on it’s likely too easily ignored—either by those producing the data or those doing the steering. One successful example is how agile software development designed risk out of the system. The entire approach is structured around responsiveness and optionality. Related, this model rejects any strategy that cannot be structured around timely feedback that allows steering and optionality. In retrospect, why would we choose a strategy that doesn’t allow effective steering? And a reminder that a progress report does not allow effective steering. It allows remediation—trying to make an unexpected event less bad than it might otherwise be—but not continual optimisation and the discovery and exploitation of new opportunities. A strategy whose plan doesn’t allow feedback on value delivered isn’t necessarily entirely bad, but if it’s to fit this model we would need to find a plan that does integrate such feedback. Having reflected on this, the whole model here is much like incremental product development but applied one or two levels up the org chart. To wrap up, let’s consider a fictional example. Suppose our organisational strategy is to use AI to improve our internal processes. (This is obviously totally made-up. I can’t imagine any organisation would adopt this strategy, but let’s roll with it for the sake of argument.) One way to approach this would be to budget for LLM licences for everyone and track how many people take them up. We might also track how many initiatives or teams or processes are using our new licences, and we may conclude that the more take-up there is the more progress we’ve made with our strategy. Is every team using AI? Mission accomplished! But of course this doesn’t track value at all (improved processes) and doesn’t allow us to steer. It doesn’t tell us where to put more or less of our money and effort as time goes on, it doesn’t at any point tell us about value delivered, and it doesn’t allow us to exploit successes. Another way to approach the same strategy is to first agree what we mean by “improve our internal processes” (total staff time? Cycle time? Cost? Something else?) and devise a way to measure that for any part of our organisation. We budget for LLM licences, and for anyone to take up such a licence they must first show that they are measuring the process, have registered a baseline measurement, and then report back regularly (if not automatically) what that measure is showing now. This is feedback on value. We’ll be able to see which initiatives are most successful and which are not working, and all of that allows us to respond positively and creatively. Dennis did cover more topics, but this is the core idea I wanted to draw out. Some time after that presentation, having thought about it and gone through the process of writing it up, this approach to devising, structuring and executing a strategy seems like it should be the natural default. I’ll be looking out for opportunities to use it. _Photo by herbrm_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

One of the challenges with software development is that the code tends to grow beyond the initial capacity of the team. The team builds more and more code over time, but the team grows only occasionally. Additionally, different kinds of teams build in different ways. Some focus on a core product, and continually refine it. Others—for example those in agencies or working for multiple clients—produce a series of one-off products with only partial or no overlap. The result of all of this is that the code becomes more difficult to manage over time. However, sometimes we have choices along the way. We may be able to choose between consolidating an existing product and building something entirely new. Generally product and software teams will prefer the first, but often it’s the second which is more likely to bring in revenue. There are also often options in between: a mixture of consolidation and bespoke. It gets more complicated if a bespoke build brings a budget for more people—is that better (because we’ve got more people) or worse (because we’ve got more code)? In these cases, how do we compare the options? I often push for agreeing a metric for a particular goal in order to eliminate ambiguity. This is often difficult at first, but it gets much easier with practice. The tactic, as Douglas Hubbard explains, is to picture what’s different between two situations. So let’s imagine two clearly different scenarios. In one scenario we have a couple of people who work on a codebase (a consolidated product), and in the other we have two people who work separately on two different codebases. Let’s assume each codebase is the same size—the one codebase in the first scenario is 100,000 lines and the two codebases in the second scenario are also 100,000 lines each. We’re looking at the cohesion between the team and the product. In terms of team-product cohesion, the first scenario is obviously preferable: we have the same number of people looking at a smaller total codebase. So: more people is better; more lines of code is worse. We might therefore create a metric of people divided by lines of code. Higher is better. We could see this as density of people to code. In the first scenario our measure is 2/100,000 which equates to 1/50,000. In the second scenario it’s 2/200,000, which equates to 1/100,000. This is a simple situation, but it allows us to compare things when our scenarios are not so neat, for example when the codebases are quite different in size, and the team options are also not easy multiples. I’ve chosen lines of code, by the way, rather than any other metric (e.g. cyclomatic complexity) because developers need to read and understand lines of code. That’s what takes time. We can refine it further, too. For example, we might add weighting factors for different languages—Python, C and Scala are not directly comparable in their lines of code or comprehensibility. Another factor we might consider is overlap—is it better for two people to be responsible for 100,000 lines each, or for both to be working on the combined 200,000? And we should remember that actually performing the measurement activity is not always necessary. Once we agree what the metric is it usually becomes obvious between two options which one would measure more or less. So, there there are ways to expand this if we want. But I hope the main lesson is that options which might be difficult measure can be captured with metrics with a bit of practice. _Photo by Mocosito_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

As AI companies get ready to go public and we get a deeper look at their inner workings, it’s only natural to have questions about their finances, like “Do they make money?” and “How?” Here are a few examples to help the average layperson understand the business side of AI. **1.** Acquiring one grape costs Alex $2 billion. Alex offers to sell Mike one grape a month for the next 12 months for $1 billion per grape. Alex asks for the full $12 billion up front and provides Mike with one grape for the first month. Alex makes a $10 billion profit this month; his ARR is $120 billion, and his profits are trending up at an infinite rate. _The Wall Street Journal_ ’s business editor moves into Alex’s house, having accepted a part-time position as Alex’s human footstool. He never asks to see the books. **2.** Laura drives a taxi. Instead of charging her customers a fee for every ride, she charges them a $20/month subscription. Laura has 40 million paying customers, totaling roughly $13 billion in annual revenue. Laura spends $25 billion/year on gas. In a fit of late-capitalist bloodlust, hordes of tech and finance bros riot in the streets, firebombing every rideshare, bus, and pedicab they can find, declaring the transportation business officially “over.” Also, Laura’s taxi cost her $1 trillion to attain, and she’ll have to replace it in four to eight years. **3.** Jenny owns a crematorium. John’s propane company gives her a $20 billion investment in return for 5 percent of her operation. Jenny throws $10 billion into the incinerator, then pays John $10 billion to buy propane to burn that money to ashes. John reports that his AI investments have generated $10 billion in revenue this quarter and that he owns 5 percent of a $100 billion business. A reporter from _Forbes_ is assigned to profile John and Jenny, and over the course of his research, he becomes embroiled in a passionate but confusing three-way love affair with them, which eventually turns into a polyamorous common-law marriage. His profile is glowing, but light on financial details. **4.** Benjamin owns a farm. He employs 100 workers plowing his fields. His total payroll is $10 million/year. One day, he buys a mule, which provides the worker who uses it with a modest 10 percent productivity gain. Benjamin fires 99 of his workers and purchases 99 mules, expecting a 1,000 percent productivity gain. The driverless mules cause plow damage to his property in excess of $50 million. Benjamin loses another $5 million due to the loss of productivity from his one remaining employee, who no longer guides a plow but instead spends 100 percent of his time shoveling mule shit. Goldman Sachs builds an altar to Benjamin in their lobby and cuts out the heart of a junior analyst on it every Friday. They call it “Blood Sacrifice Friday.” The name isn’t catchy, but the event becomes a management favorite nonetheless. **5.** Xavier owns an apartment that he rents out at a loss of $1 billion/month. Seeing this success, he decides to make financial commitments to construct $850 billion in new apartments in places nobody wants them. He convinces Ted to leverage everything he owns to help him build the apartments, telling him that once they are built, every human being on Earth will live in them. Ted contributes $100 billion, part of which immediately goes toward paying off Xavier’s $1 billion/month loss. _Forbes_ gives Xavier and Ted a cover feature, likening their building project to God creating the Heavens and the Earth. Many Fortune 500 CEOs take this comparison literally and establish a new religion around Ted and Xavier, with themselves as high priests. Soon, they start a Holy War with the pope, declaring “Ted and Xavier the One True Gods on Earth” and promising to “purge the nonbelievers” in an official press release. They annex, then subsequently demolish, Vatican City, committing another $900 billion dollars to build new apartments in its place. _Forbes_ hails this as “disruptive,” though it’s not clear how Ted and Xavier plan to finance the project. We hope these examples help clarify the inner workings of AI economics. But if you’re still confused, all you really need to know is that everything is totally working and everyone is making a lot of money, and you should just stop asking questions, luddite.

Digital product people are used to the concept of technical debt. These are (typically conscious) decisions to take a technical shortcut, knowing it’s incredibly helpful now but will be increasingly problematic and costly to fix over the longer term. There is also the concept of organisational debt. These are (typically conscious) decisions to take an organisational shortcut—for example in team structure, reporting lines, etc—knowing it’s incredibly helpful now but will be increasingly problematic and costly to fix over the longer term. The link in the above paragraph talks about creating organisational debt in a startup, but I’ve also seen it happen in more mature organisations. At one, they had created a small skunkworks team a few years previously to help them out of a very difficult situation. The team needed to quickly assemble a new product in a very short space of time. They were incredibly successful. They broke some organisational rules to do so, and they used technology new to the organisation. But (or maybe that should be “And”) they delivered a product so much quicker and so much more usable than anyone there had seen for a long time—maybe forever. It was an unqualified success. As a result of this success this small team was given more funding to grow, and it became a significant part of the overall tech function. However, this was organisational debt. This was now a sizeable team, comparable to that of the original tech function (which still operated), that undertook significant projects with different technologies, a different culture, and different governance. Inevitably, work by the original tech function and the newer one could not be kept apart forever; there were plenty of occasions where programmes and products need to span systems and workflows from both. When I was there I had to manage challenges of bridging governance structures and role discrepancies. The culture gap led to slowness, confusion and distrust. It could be resolved, but it took a lot of time and effort. This was the debt coming due with interest. Whenever I’ve overseen small innovation-type teams in the past I’ve always asked myself “What happens when…?” What happens when the team is successful and the demands on their product grow? What happens when team members excited by innovation have to spend more time on maintenance, which is less exciting to them? What happens when one team member, who holds may be 25% or 33% of the team’s capability, chooses to leave? What happens when stakeholders say “We want more of this new stuff, not like that old stuff you used to produce”? For me, the key is often about breaking down barriers early on. The new team shares their knowledge through talks, demos, and writing. We consider early how to share the technical expertise and the product itself, and plot a path from “build” to “run”—where “run” means run in the long term. Maybe we cycle people through the new team to absorb some of the thinking and create personal connections across boundaries. These nimble teams are often a huge win for organisations, and are often a wonderful answer to an urgent need. But the urgent and the important are not always mutually exclusive. While some people are putting their effort into urgent innovation, others of us have an opportunity to do the important work for a sustainable future. _Philippa McKinlay_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

Our product and technology roadmaps can take us to all kinds of places. That’s almost true by definition. Every organisation or team has their own objective, and will therefore have their own roadmap which (hopefully) will get them there. But roadmaps can do something else, too: they can give our teams and people capabilities. If we plan poorly, or are very unlucky, then those capabilities are just some kind of compensation—we might have failed to reach our destination but we say to ourselves “well, at least we learned some lessons.” However, we can plan well and ensure we acquire capabilities of our choice, deliberately. And with a half-decent roadmap we can make sure we acquire those capabilities incrementally along the way. Our plan is more robust. If something goes wrong and we have to abort or reshape our roadmap early we’ve gained value that’s deliberately chosen by us, not accidental. We can go further, too. Sometimes those capabilities may be the main point of our roadmap. All that is very abstract, so here’s a concrete example. I once worked with a company whose core goal was to acquire more enterprise (and therefore higher value) customers, and the route for that was to expand the company, principally via the next round of investment. The destination was clear, certainly for the company. But what did this mean for the tech team? In fact the tech team was not well positioned for the end goal. The main problem was that the code was a large monolith, being worked on by too many teams. (The company’s goal included enlarging the team, but the current team was already too large for the codebase as it was currently structured.) Also as a result of this there was a large amount of technical debt. Engineering teams always complain about technical debt, of course, but in this case it was excessive due to the ease with which logic could leak from one area of the codebase to another. Our technical goal was to break up the monolith which—most importantly—would give us the capability to develop faster and more reliably. We created a mapping between items of technical debt and the architectural components they should move to. I worked with the Head of Product to make sure all the work on the product roadmap corresponded to some work on the technology roadmap. Our destination was to break up the monolith, but however much we might or might not have succeeded we were always increasing our capability to deliver more reliably and at greater scale. And this capability was exercised much earlier and more visibly than we might have liked—certainly long before we could honestly say there was no monolith. Some time into our journey along the roadmap a critical integration partner decided they could no longer work with us. It wasn’t a personal decision, just the result of some internal policy of theirs, of which their relationship with us was an unfortunate consequence. We had no choice but to switch to another partner, and we had a very, very short time to do that. That switch involved writing new code (of course) and one team worked with focus and fury to achieve that. And during this period the tech lead commented that they couldn’t be doing this so effectively if we hadn’t already migrated some of our monolith code into a separate component. They were able to work with relatively few dependencies, and therefore much faster and more reliably. Our roadmap did lead us to a destination, but it deliberately delivered us capabilities along the way. When life threw us a curveball our roadmap, and our increased capabilities, proved their value. _Photo by Nuno Nunes_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

I’ve always been wary of jumping on a bandwagon, including technical trends. Or more specifically, I’ve always been wary of associating myself with something that’s popular. If I was to conduct some ill-informed psychoanalysis, I’d say that was because I was never one of the cool kids at school, so avoiding anything popular acts as some kind of self-justification. But it’s better for all of us if we steer away from that and get back to the intended subject. Popularity is not in itself bad, but we need to ask ourselves why something is popular, what our own needs are, and how much the two things line up. One advantage of popularity of a technology or similar is that it’s easier for us to find support—people with expertise, advice, and so on. So why say “bandwagon”, which is, of course, a pejorative term? It implies that too many people are adopting the thing simply because others are adopting it; that they are not sufficiently considering its pros and cons or how well it matches their specific needs. Perhaps they are even labelling it “best practice” without too much thought. And if something isn’t a good match for our needs then perhaps all that readily available support and knowledge, which comes from the popularity, is a relatively minor advantage. This is important because when we introduce a technology or process into our team or organisation it comes with an initial learning curve and an on-going maintenance cost. If we also have an incumbent technology then there may be the added cost of migrating away from that. My go-to example of a bandwagon is microservices. These were all the rage a few years ago in the software world—tiny applications which a team could develop and reason about very easily, which run independently on their own servers, and which connect with each other to produce the overall product or service that the user wants. I’ve worked with at least two teams who embraced microservices, and it served neither of them well. One of the problems with microservices is that the overall application logic is distributed across a large number of independent systems. One user’s transaction runs through may tiny applications before it completes, so diagnosing a problem means capturing the right data from all of those systems and reassembling it to get the full picture. It’s not so much finding a needle in a haystack as finding all the fragments of the same needle scattered across a dozen haystacks. To do this with any ease we need to first have a pretty sophisticated infrastructure and the ability to manage that. Martin Fowler has written well about microservice prerequisites, but for me the zinger is embedded in that article’s graphic: “You need to be this tall to use microservices.” One of those “teams” I mentioned really consisted of several product teams, each developing one or two microservices. They fell into a pattern of each focusing too much their own system and not thinking about the whole. As a result, there were too often instances of one team making a change which broke another team’s integration and therefore the overall application. That can happen in other kinds of architectures, too, but is much easier to do with microservices and here it happened far too frequently. We hadn’t learned basic team communication before taking on this new approach. Bandwagons will always be with us. An obvious example today is AI, and in particular LLMs. I’ve seen people refer to the embracing of that as a pyschosis, which seems to be really just a more extreme version of a bandwagon. And this is not to say all bandwagons are bad, or don’t have some advantages. Devops took off very quickly, relatively speaking, but has been shown to be incredibly valuable, if not essential, for all kinds of successful digital product delivery. The same can be said of agile software development, which has evolved to embrace digital product delivery more generally. In the end we need to evaluate trends and technologies critically, and make sure we do that with reference to our own context and needs. _Photo by WhatsAllThisThen_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

Last week I talked about not getting all the resources we ask for, and that a constructive response to this is to change the environment in which we operate. This still has costs, but the costs are less financial and more organisational. I gave a brief example, in which we fiercely narrowed the scope of a project—it’s something the management team needed to accept as much as the product team. The cost was to change expectations (and possibly a cost to ego and pride, if anyone was expecting to use the original delivery to show off among their peers), and to put leadership effort into sticking to that more limited scope. At another organisation the challenge was that cost and time seemed to disappear inexplicably. The executive team reported that projects routinely flipped into a crisis. The executive still approved budget requests, but they were certainly getting increasingly nervous about it. As a response to this (and to several other related concerns from the executive team) we introduced a much clearer and shorter governance cycle. Within the cycle each product team was asked to state a business goal that they thought they could achieve within six weeks and then (assuming it was approved) return at the end of that period to demonstrate their progress. Teams which were failing to meet their goals wouldn’t be disbanded, of course, but there would be a conversation about what was happening and how to fix it. In any event a new goal would be set and the cycle would repeat. The focus on demonstrable business goals, aka outcomes, was much more reliable than their previous approach of just reading printed reports. The short cycle with demos of progress meant the executive team could understand their portfolio in detail and provide frequent, but light-touch, steering. The product teams had few surprises—they knew what they needed to achieve and demonstrate. If there was a consistent failure to meet meaningful goals then that would be evident over a period, and they could understand if their work was wound down. Overall the exec team could also prioritise their budget much more effectvely. They had visibility of the entire portfolio (on index cards, stuck to a whiteboard) and could assess products and projects together. Individual demonstrations of progress weren’t lengthy. To aid transparency, it wasn’t just a meeting between the executive and each product team individually; it was a meeting between the executive and leads from all product teams. Everyone would see everyone else’s work. This meant people learned from each other and understood organisational context better. It was another way to reduce surprises. So this executive team managed to get a better handle on their costs, with teams having a greater focus. Those two things are not unrelated, of course. The teams used their time much more effectively. _Photo by Elias Rovielo_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...

Last week I talked about a twin track approach to delivery: for some stakeholders focusing just on outputs, and for others focusing on outcomes. The latter is generally much more productive, but requires much more trust. It also changes the nature of the relationship, from customer/supplier to being much more of a partnership. When a product team is able to act as a partner with their stakeholders information flows more freely and problems are solved more easily. I was once invited into an organisation to diagnose a systemic delivery problem. One of the things I found was that while they acted to deliver a recurring product for a small number of major external stakeholders, those stakeholders we seen as being customers rather than partners. This is fine if the organisation was delivering a commodity product, but they weren’t. They were delivering something meaningfully different each time. Because of that they always encountered novel technical challenges, and because of the perceived customer/supplier relationship they felt they could never share these problems with their stakeholders. Instead, much time was spent working around internal problems alone while not telling their stakeholders. Could those stakeholders have helped, if the relationship was more like a partnership? In general, I think yes. The stakeholders’ worlds also change over time; their priorities shift in large and small ways. If there was a belief in shared success, rather than just fulfilling a predetermined contract, then they might have been able to offer advice or guidance that suggested new solutions. An open, two-way conversation would help both parties continually adjust their position for the better. When I spoke to that organisation about creating more of a partner relationship I had in mind a specific situation I’d encountered not long before. I was helping a product team elsewhere deliver for a client, and it was very much a customer/supplier relationship. But in the product team we didn’t like that; we genuinely wanted the product to be a success, we thought we could find solutions to emerging problems the client couldn’t see yet, and wanted to contribute. However, the client was focused on working through a list of predetermined features, some of which were (to our mind) of questionable value. We worked hard to change the relationship, and we had some success. Part of that work involved speaking to the clients’ representatives individually, suggesting there might be better ways to do things, to test reactions. Part of it involved personal introductions to our team members, so that people on both sides of the contract could see there were real people behind the lists and the charts and the spreadsheets. And this did help. We mutually agreed that some features were of low value after all, and should be replaced with features of much higher value. But the transparency also meant being honest about some of our internal problems. Most significant was replacing one (legacy) system component in our core platform with something more modern and which we believed would be much more reliable over the long term. The replacement was proving to be hugely problematic and was creating a drag on delivery. We wrestled with sticking to the legacy component, but we always felt we were so close to success. This was nothing related directly to the client’s feature list, but it did concern long term maintainability. Eventually it became enough of a problem that we had to share this internal struggle with our client-partner. They immediately cut through the doubt: forget about the new component, they said—stick to what you know, delivery is the priority. We should have been able to see this ourselves, but we were all too close to it. It took someone with a bit of distance to provide clarity. They weren’t exactly telling us how to do our job, but their push was what we needed. Creating an environment of mutual success allows more ideas, options and flexibility. Solutions to problems are found more easily, and everybody wins. As I wrote last week, this depends on trust, which takes time and effort. But there are meaningful rewards. _Photo by Ems& Ash_ ### Share this: * Share on LinkedIn (Opens in new window) LinkedIn * Print (Opens in new window) Print * Email a link to a friend (Opens in new window) Email * Share on Tumblr (Opens in new window) Tumblr * Like Loading...