software

Enterprise Software and Organizational Fear

I read this article today which is a very good look at some of the things that happen in IT organizations. I've worked in a couple of teams that operate this way, and it's absolutely a shock to the system.One key element for the author Ian Miell is that his experience and observations are driven by highly regulated financial institutions. Places where audits and regulatory compliance are baked in for good reason. I'm sure it's all true, and that even the horror stories in his story are gentle in comparison to some of the things he has seen.I've

  • Mark Thomas
    Mark Thomas
3 min read
Why

Time Spent Making vs. Time Spent on Process

I've spent a lot of time observing teams. At first glance almost every team I see is working hard, and trying to do the right thing the best they can. Sure they may not be super effective or efficient, but it's not for lack of trying, and often not their fault. One of the key things I look for is how a team works, and more specifically how they allocate their time. If you really think about it there are really only two things teams do: Productive work, making, building, etc. Communicating, estimating, justifying, and explaining the work, and status

  • Mark Thomas
    Mark Thomas
4 min read
Why

Organizational Methodology Adoption

How did your team end up using your current methodology? It's kind of a trick question, because if you are using a branded Agile methodology you have probably already made choices that are highly limiting to your teams empowerment, and the trust of the organization that's needed for long term success. Capital A Agile software development has fully infected many teams. There are so many lessons to be learned from software development history. We stand on the shoulders of giants; but the leadership at many companies are not part of that on-going conversation. This means that you must assume that

  • Mark Thomas
    Mark Thomas
1 min read
software

Problem Solving vs. Passing Through

It's a fine line for a lot of people, you get to be a manager and it sort of pushes you further away from the work, a few years go by and the time you had previously invested in staying up to date with the latest changes in languages, tools, etc., is now spent working with your team, or on manager problems. You can't contribute in the same way you used to. One of the most difficult challenges a manager faces is to figure out how to maintain the contribution that got you to this new management role. Where do

  • Mark Thomas
    Mark Thomas
2 min read
Why

Software Complexity and Leadership

I am of the school of thought that says software products are complex. Even, or perhaps especially, when you try and make them simple to your users. The technology is a part of it, but most of the complexity comes from the fact that you are designing and building something new. The work to understand the problem space, customer need, and how that intersects with the technology you need to build is all part of that. The most efficient process to implement something is usually not the most effective process to design that same thing. Properly done, teams are constantly

  • Mark Thomas
    Mark Thomas
2 min read
Why

Why Companies Fail at Software.

Companies big and small, especially ones that don't have software deep in their founding DNA tend to fail more than they succeed in their software projects. The fabled digital transformations are very expensive, but don't always end up the way people hope. I've seen a few of these, and there are some common factors and trends. Watch this space for more on how to spot things going wrong, and some of the things you could do to avoid the pitfalls.

  • Mark Thomas
    Mark Thomas
1 min read
Roadmaps

Roadmaps Complete: Final Artifacts

But how do I turn this into something I can send my executive team? Honestly you shouldn't have to. Your executive team should be smart enough to be involved in the motive creation, and be observing the approach definition process. Depending on the company they may be highly involved in that part of the process. The key to turning this material into something your less connected executives might recognize is in the early alignment stages. If you are actually executing against a model like this, you are producing at least one Rally Point per iteration to show your work. More

  • Mark Thomas
    Mark Thomas
3 min read
Roadmaps

Roadmaps Continued: Work

There is no fancy name for this. Your team may call them tasks, or stories, or really anything. But no need to get too abstract. It's just work. The difficult little things we all do every day to make something. Break down your Rally Points into individual work items for human people, use some sort of system to track them. Could be post-its, could be jira (if you really really have to). Try and come up with something that is optimized for makers, with a low overhead. In an ideal world you would extract these from the actual work of

  • Mark Thomas
    Mark Thomas
1 min read
Roadmaps

Roadmaps Continued: Rally Points

Complex software requires a lot of work to scale and stay aligned. Many companies who don't have software in their DNA think that software like many industries will go faster with more teams, more individuals working on those teams, and more people over all. Software development does not have economies of scale. Development has diseconomies of scale — Allan Kelly Communication might be the opposite of software development. It's hugely difficult and time consuming. People literally speak different languages. Rally Points are all about translating your now well understood approaches into work that can be done by small groups. Small groups

  • Mark Thomas
    Mark Thomas
3 min read
Roadmaps

Roadmaps Continued: Approach

We actually don't know enough yet to start fixing this problem, what we need is for the smart, creative, passionate people to start building out an approach, or better yet, multiple approaches. This is a thinking heavy exercise. A well crafted approach might be several pages, it has evidence, and it has context. To do this right you are going to need to: Research the problem, and identify things that might be causing it Identify key factors that could change to improve your problem Think through what levers you might pull to change something, and what might happen when you

  • Mark Thomas
    Mark Thomas
4 min read
Roadmaps

Roadmaps Continued: Motives

Instead of starting with goals, we will start with a motive. A long term why framed as a reason. This motive should be substantial enough that everyone can agree that there is a problem, and a good reason. A motive should avoid a solution, but instead articulate a measurable change and the reason why the team or company needs to make progress on this now. We lose 50% of customers between adding an item into their shopping cart and checkout. We need to reduce that to lower than 20% because it represents 50% of our potential revenue and turning more

  • Mark Thomas
    Mark Thomas
2 min read
software

Software Roadmaps

I've been working for a while on a new way of answering the roadmap question. Which for those of you who haven't worked in a company like this goes something like: Can you send me a copy of your roadmap? In it's first iteration it's always devoid of information, like why, what are you going to do with this. The assumption however is always, there is a single document called a roadmap, that I can use to do whatever I want with. Often these people will go away when you ask them any sort of question of your own, but

  • Mark Thomas
    Mark Thomas
3 min read
software

Transparency vs. Understanding

Today a seasoned executive talked criticized his own team about transparency. This is an area I see a lot of people messing up, much to their detriment. When a leader doesn't understand what their organization is doing it's hard to put the blame on the organization in that case, but weak managers tend to do so. The accusation is almost always that the team isn't being transparent. This is one of the great cop outs, and nine times out of ten the CEO should start a search for a new leader. The accusation is almost always that the team isn't

  • Mark Thomas
    Mark Thomas
4 min read
software

Making Space

Two Weeks ago I quit my job. A point comes when if you want to actually be open to doing something new, and be able to think about that thing for real, you need to make some real space for it. That's for me. For the organization I'm leaving behind, a medium to large software development shop at a mid-size public company, I'm making space of a different kind. Space to lead. This is my second senior leadership role in a company that needed to make a substantial transition; from an old business model where the market was shifting out

  • Mark Thomas
    Mark Thomas
4 min read