E.E. Grey
Founder and Principal Consultant
Founder and Principal Consultant
An engineer and engineering leader who has spent time on both sides of the whiteboard: writing and reviewing the code, and making the calls that determine whether the code gets written at all.
E.E. Grey Consulting was built around a simple observation: the organizations with the hardest technical problems rarely lack intelligence or effort. They lack clarity about what actually needs to be decided, who is supposed to decide it, and what happens after the decision is made.
The founder's background spans hands-on software engineering and senior engineering leadership, including work inside enterprise systems and bioinformatics-related environments where correctness and reliability are not negotiable. That work included leading growing engineering teams, operating across engineering and product organizations, and later returning to hands-on implementation after time in management, a deliberate choice made to stay close to how systems actually behave under real conditions.
That combination shapes how the consultancy works. Architecture recommendations are tested against what a team can realistically build and operate. Leadership recommendations are tested against what the technology actually supports. Neither is treated as more important than the other, because in practice they are the same problem viewed from different altitudes.
Between the code and the boardroom
An engagement is only as useful as its ability to move between altitudes: close enough to the implementation to know what is realistic, and clear enough in the boardroom to be acted on.
- Reviewing implementation details closely enough to know whether a plan is realistic
- Evaluating architecture against both technical soundness and organizational capacity
- Coaching engineering leaders through decisions they have not had to make before
- Structuring delivery so that ownership, sequencing, and risk are all explicit
- Communicating risks and tradeoffs to executives in terms tied to business outcomes
How this shapes the work
Good architecture must survive contact with organizational reality
A technically elegant design that ignores team structure, incentives, or delivery capacity is not a good design. It is a good diagram.
Clarity, not ceremony
Strong technical leadership reduces confusion. It does not require more meetings, more process, or more artifacts than the problem actually calls for.
The best solution is not always the most elaborate one
Complexity should be spent deliberately, on the parts of the problem that require it, not distributed evenly across the system out of habit.
AI should amplify expert judgment, not replace it
Used well, AI removes friction from analysis and execution. It is not a substitute for understanding the system, the organization, or the stakes involved.
Most failures are decisions, not intelligence
Difficult programs tend to fail because of unclear ownership and misaligned incentives, not because the people involved were unintelligent or unmotivated.
If this way of working sounds right for your situation, say so.
A short conversation is enough to tell whether this is a fit, in either direction.