About
What We Do
D’Mention Systems helps growing technology firms reorganize and evolve to achieve excellence in execution.
Our mission is to enable organizations to adopt and master a modern agile approach to product development and project-based work that results in outcomes in operational and development value streams that deliver long-term value and growth.
We accomplish this by providing business development consulting tailored for evolving and restructuring in ways that maximize performance, job satisfaction and retention of the key team members who deliver this value and growth.
Problem Space
Turnover, lack of continuity and inconsistent delivery flow comprise the breakdown of the problem space that we service. This leads to a disappointing statistic across our professional space: 70% of all tech initiatives are deemed a failure.
Turnover
IT startups commonly struggle with the inevitable consequences of continuous turnover, where the industry average is estimated at over 13% per year across our sector.
Often the organizational costs of losing key members of IT dev/engineering teams can amount to many times their base salary. A myriad of factors contribute to these loss estimates including technical debt, knowledge loss and the degradation of energy, morale and focus of those left behind with the continuous interviewing burden that constant turnover imposes.
Lack of Continuity
The effects of turnover (knowledge loss in particular) perpetuate a lack of continuity in today’s tech shop culture. One key contributor to this is an overemphasis in one direction of a widely embraced tenant of the agile manifesto: working software over comprehensive documentation.
Often, this principle is executed in reality like this: working software with no functional or technical documentation.
This means that when future practitioners arrive to join an organization, they are faced with the arduous task of reverse-engineering products and systems that are already in service, and in most cases are in need of immediate attention, progressively accruing functional and technical debt.
Inconsistent Delivery Flow
The lack of continuity leads to contributors having to go through periods of significant ramp-up, leading to productivity swings in the delivery of innovations and new products.
Solution Vectors
Our expertise that contributes to these solution vectors includes:
What is a Center of Excellence?
One modern label of a Center of Excellence is an ART (agile release train). An ART is often a virtual unit within an organization responsible for coordinating across domains and iterations to deliver continuous value.
A more traditional label of a center of excellence is referred to as a PMO. The “P” can stand for any one of the 4 P’s, (i.e. project, product, program or portfolio). We most often recommend establishing: a Portfolio Management Office.
Regardless of the label, these host leadership centers serve as a centralized center for organizational guidance on the approach to developing products, managing projects and operating programs. Often, these groups oversee the entire portfolio of these internal efforts org-wide.
While a center of excellence’s leadership in a tech firm typically possesses some technical knowledge, their core expertise lies in the strategy and tactics for defining, chartering and overseeing projects, programs and product development efforts. With that, these groups also champion the culture and career path of the functional middle managers who lead these kinds of efforts (e.g. project managers, product owners, scrum masters, agile coaches and program managers).
How does a center of excellence mitigate this problem space?
Like technical folks, functional team members also tend to seek other opportunities and become turnover statistics when reporting to under-qualified departmental, operational or technical management.
Establishing a center of excellence can reduce turnover by providing the organizational hub for functional career paths and culture.
What is a Cross-Functional Matrix?
Many of our clients are organized as a departmental or functional hierarchy at the outset of our engagements. In this scenario, product development and project-based work is overseen by leadership within a department, such that product owners/project managers report up to directors, who report up to the department’s VP, and so on. In these scenarios, product development and project management is done differently in each department, per the preference of leadership in that area and based on their respective expertise in overseeing development work.
In a cross-functional matrix, product owners and project managers report up to one center of excellence (often, a PMO), which enables the centralization of standards for how product development and project management is done across the organization.
How does a matrix mitigate this problem space?
A standardized way of doing things org-wide increases efficiency and scalability in many areas, including reduced time required for oncoming development team members to become productive on an effort. The cross-functional horizontal relationships between the PMO and the departmental units also enables ways to share the burdens of recruiting and interviewing oncoming team members.
These features of a cross-functional matrix contribute to resilience and mitigating loss in dealing with turnover.
What do you mean by “balance” between tech and functional?
By balancing between technical and functional, we mean a separation between the “what” and the “how” when developing any solution.
The “what,” along with the “when,” is the realm of the functional operative (i.e. the project manager/project owner). In this realm, objectives, requirements and designs are analyzed, understood and then broken down into work streams to be sequenced in some chronology for execution.
Meanwhile, the “how” is the realm of the technical operative (i.e. the developer/engineer). In this realm, the art of fashioning technology into the solution itself takes center stage.
Balancing these realms means managing rituals and meeting agendas to ensure that these two motions occur in the proper chronological order. When we are imbalanced in this realm, the “what” and the “how” tend to get mixed and muddied during which too much emphasis gets placed on one or the other. Team interactions such as business analysis meetings and technical solutioning rituals can then become unproductive. This can result in a myriad of issues including rework, introduction of technical debt and scope creep.
How does balance mitigate this problem space?
Balancing tech and functional realms minimizes the losses that result from turnover by reducing the ongoing need for rework, the introduction of technical debt, and by fostering rituals that continually and progressively elaborate and clarify scope.
Additionally, balance across the technical and functional realms can reduce the stress of context switching, which increases retention of both functional and technical team members. Finally, and perhaps most prominently, it results in a more controlled deliberate outcome in terms of the project or product, such that the chances of rendering a return on investment increase.
“Resist the Rush,” an article on the business analysis by D’Mention Systems founder Mike Liskow, published in PMI’s PM Network Magazine
What do you mean by “balance” between Ops and Dev?
In an IT shop, operational work (ops) entails tending to the needs of customers. By nature, these motions are responsive, and require a cognitive focus on the past. This is akin to playing defense in a sport like basketball – when the ball goes to one side of the court, so follows our focus.
Development work (dev) entails creating, configuring or building something to be used in the future. In contrast to ops, this effort is proactive, and requires a cognitive, creative and visionary focus on the future. This is akin to playing offense in basketball – we’ll fashion an offensive strategy to overcome the obstacles and achieve the sought objective to with the game.
A basketball player simply cannot play offense and defense at the same time. It is physically impossible – the body has to switch contexts and contort between these motions, and so a transition is required. Switching between dev and ops requires a similar cognitive contortion and transition, where context switching is required. In the typical startup IT shop, the lack of strategies to deal with context switching is simply a recipe for dev team burnout and turnover.
How can we mitigate this problem space?
Some tools and rituals are great for ops work (i.e. Slack, impromptu/off-calendar meetings, business-day flexibility to blow off scheduled meetings to deal with fires). These same tools are a detriment to dev work. Balancing dev and ops work in an IT shop means developing a strategy that takes into account dev tool usage, team member roles, team member allocation and even the personal nature of how any individual dev team member prepares to get into their creative zone. In the modern startup, strategies around these things are often overlooked due to the perception that there is not enough time to worry about these things. If you care about turnover in your startup – you do need to worry about it.
Developing strategies to balance ops and dev work is a direct contributor to reducing turnover.
What do you mean by “balance” between tactical and strategic?
When departmental leadership drives tactical rituals and motions, they cognitively focus on honing the tools and methods to obtain some result or end. This realm is most concerned with the how, and responsive to the past (i.e., these are the requirements that were given in the past, how should we proceed?). In a practical sense, tactics entail making sure direct reports are at the top of their game in terms of their skills, tools and environment and their fitness to accomplish what they need to in their jobs.
Conversely, when leadership acts strategically, they cognitively focus on determining the best approach to position a group, product, program, project or organization in the long-term. This realm is most concerned with the why, and requires deep thought and vision into the future. In a practical sense, strategy entails planning for interdependent business objectives along with considering priority, chronology and approach.
These two realms are vastly different from a cognitive perspective, yet the modern startup imposes both of these burdens upon departmental directors and VPs. This represents a massive context-switching burden for these roles, and is a direct contributor to burn-out and turnover, if not for the leaders themselves, for those that they manage.
How does balance mitigate this problem space?
Balancing tactical and strategic realms means separating tactical and strategic rituals, as well as spreading the strategic burden to functional leaders (i.e., project managers, product owners, program managers, portfolio managers) who report to a strategic center of excellence (e.g. the PMO or the Chief Strategy Officer).
Balancing tactical and strategic realms can directly mitigate burn-out and turnover of departmental leadership.
“Can Product Managers Also Be Product Owners?” blog post by D’Mention Systems founder Mike Liskow
“Product Management: 3 Ways to Balance Strategic and Tactical Focus,” blog post by D’Mention Systems founder Mike Liskow
What is a recruiting process that is consistent with culture, mission and values?
Have you ever applied for a job at a startup? When you read the job advertisement on Indeed, Dice, or LinkedIn, did it appear to be a boiler plate? If so, did it use all kinds of industry jargon and buzz words, such as requiring experience with frameworks like Scrum, SAFe, agile approaches to development, or attention to detail (to name a few)?
At first glance, we may all assume that these are reasonable qualifications to require for a dev team position. However, if your dev shop does not actually value/practice what is enumerated, it can create a false sense of your culture and values.
When oncoming team members have differing impressions between their interview and their first day of work, this inconsistency contributes to their propensity to leave at some point by opening that door early.
How does a recruiting process mitigate this problem space?
It is important to realize that acculturation begins before a recruit’s first day. It begins the day they read your job posting, and continues into their interview. The modern knowledge worker employee appreciates authenticity and transparency, and to the extent it is lacking when they onboard, it opens the door to turnover risk.
An authentic recruiting/interview process that highlights your strengths while being authentic about areas you are still improving contributes to longevity of employment.
Our Approach
We provide our solution through hands-on engagements, which are designed to provide deep understanding of your organization’s culture, values and core objectives, and from the perspective of what it is like to actually perform the work of projects, programs and product development from the inside.
By hands-on, we mean that we prefer to learn by doing. Our offerings entail one of us taking on a short-term role on a staff augmentation contract or short-term employment stint to run a project, charter a PMO, perform some recruiting or some combination of these services. During the engagement, we perform an analysis of your current capability and approach. At the end of the engagement, we provide an assessment, a set of recommendations for evolving and restructuring, followed by guidance for implementing whatever you choose to adopt.
Our Experience
To become adept at organizational development, we believe it is important to possess experience with many organizations, and among the many areas within an organization, and across many industries. Our unique journey that took unexpected turns has organically resulted in the broad resume you would expect from an organizational development firm.
Below is a timeline of our journey that featured a wide breadth of experience across the technology and small-medium business sectors.